Microsoft Entra ID + RBAC

解決する課題

• 全員に所有者権限を配る運用は事故のもと → 必要な人に必要なスコープだけを渡したい
• アプリにパスワードや接続文字列を埋め込みたくない → マネージド ID で資格情報レスにしたい
• オンプレ AD と SaaS（Microsoft 365 / 数千の SaaS）をバラバラに管理したくない → シングル サインオン（SSO） で一元化したい
• 監査で「誰が・どのリソースに・何の権限を持つか」を説明したい → ロール割り当ての一覧とサインインログで示したい

主要概念と用語

• テナント（ディレクトリ）: Entra ID の組織の単位。1 つの組織＝1 テナントが基本。AWS の「アカウント／組織」に近いが、ID 専用の境界
• ユーザー / グループ: 人を表す ID と、その束。グループ単位でロールを割り当てると管理が楽
• アプリ登録 / サービスプリンシパル: アプリを表す ID。アプリ登録がアプリの定義（グローバル）、サービスプリンシパルが各テナント内の実体（＝そのアプリのアカウント）
• マネージド ID（Managed Identity）: Azure リソース（VM / App Service / Functions 等）に付与する、自動管理されるサービスプリンシパル。システム割り当て（リソースと一蓮托生）とユーザー割り当て（独立して使い回せる）の 2 種類。AWS の IAM ロール に相当
• Azure RBAC: Azure リソースへの認可。セキュリティプリンシパル × ロール定義 × スコープの 3 点セットで「ロール割り当て」を作る
• ロール定義: 許可する操作（Actions / NotActions / DataActions）の集合。組み込みロール（所有者 / 共同作成者 / 閲覧者など）とカスタムロール
• スコープ: 権限が効く範囲。管理グループ → サブスクリプション → リソースグループ → 個別リソースの階層で継承される
• Entra ロール（ディレクトリロール）: Azure RBAC とは別系統で、テナント／ディレクトリそのものの管理権限（グローバル管理者、ユーザー管理者など）を表す

仕様・制限・クォータ

• グローバルサービス（テナント単位。特定リージョンに縛られない。データ所在地はテナント作成時の地域で決まる）
• RBAC のロール割り当て上限: 1 サブスクリプションあたり既定 2,000 件（条件付きで最大 4,000 件まで拡張可）、1 管理グループあたり 500 件
• カスタムロール: 1 テナントあたり最大 5,000 件
• スコープの継承: 上位スコープ（管理グループ／サブスクリプション）の割り当ては下位に自動継承される。複数割り当ては加算（許可の和集合）
• 拒否割り当て（Deny Assignment）: 明示的に操作を禁止する仕組み。ただしユーザーが直接は作成できず、Azure Blueprints / マネージド アプリ等が内部的に使う
• マネージド ID: トークンは IMDS（インスタンスメタデータサービス, 169.254.169.254） 経由で取得。アプリ側に資格情報は一切置かない

内部の仕組み

認証（Entra ID）と認可（RBAC）は別レイヤーで動きます。

認証フロー（Entra ID）

1. クライアント／アプリが Entra ID に対し OAuth 2.0 / OpenID Connect でトークンを要求
2. 必要に応じて 条件付きアクセス（場所・デバイス・リスク等の条件）と MFA を評価
3. 条件を満たせば アクセストークン（JWT） を発行。トークンには対象リソース（aud）やスコープが入る

認可フロー（Azure RBAC）

Azure Resource Manager（ARM）へリクエストが来ると、次のように評価されます。

1. 既定はすべて拒否（どのロールも割り当てられていなければ何もできない）
2. リクエスト対象スコープに継承されるすべてのロール割り当てを集計し、許可（Action）の和集合を取る
3. 拒否割り当て（Deny Assignment）があれば、許可より優先して拒否

設計パターン / ベストプラクティス

• 最小権限の原則: 「所有者」を安易に配らず、閲覧者 / 共同作成者や、できる限りスコープを絞った（リソースグループ単位の）割り当てにする
• グループにロールを割り当てる: 個人ではなく Entra グループに RBAC を付け、入退社はグループメンバーシップで管理する
• マネージド ID を使う: VM / Functions / App Service からのアクセスは資格情報をハードコードせず、マネージド ID＋RBAC で
• 特権は PIM で Just-In-Time 化: Privileged Identity Management（PIM） で、管理者ロールを常時付与せず承認付き・時間制限付きで一時昇格させる
• 管理グループで統制を継承: 組織共通のポリシー／RBAC は管理グループの階層で一元的に設計する

運用・監視

• サインインログ / 監査ログ: Entra ID の「誰がいつサインインしたか」「ロール割り当て等の変更」を追跡。Log Analytics / Microsoft Sentinel に流して長期保管・相関分析
• Azure アクティビティログ: Azure リソース側の「誰がいつ何の操作をしたか」（RBAC を通った操作の記録）
• アクセス レビュー（Access Reviews）: グループ／ロールのメンバーを定期的に棚卸しし、不要権限を自動で剥がす
• az role assignment list / ポータルの「アクセス制御(IAM)」: 付与済みの権限を確認。権限エラー時はスコープ・ロール定義・拒否割り当ての順で切り分け

コスト

Entra ID と Azure RBAC のコア機能（基本的なディレクトリ・SSO・Azure RBAC・マネージド ID）は追加料金なしで使えます。条件付きアクセスや PIM などの高度なガバナンス機能は P1 / P2 ライセンスが必要です。

セキュリティ

• MFA を必須化: 特に管理者ロールには条件付きアクセスで MFA を強制。理想はフィッシング耐性のある方式（パスキー / FIDO2 / 証明書）
• 特権ロールは PIM で JIT 化: グローバル管理者・所有者などは常時保持させず、必要時のみ承認付きで昇格
• マネージド ID 優先: アクセスキーや接続文字列より、資格情報を持たないマネージド ID を使う
• 緊急アクセスアカウント（Break-glass）: 条件付きアクセスから除外した非常用グローバル管理者を 2 つ用意し、厳重に保管

関連サービス・比較（AWS との対応）

AWS では IAM が「認証＋認可」を一手に担いますが、Azure では Entra ID（認証・ID） と Azure RBAC（Azure リソースの認可） に分離されています。

ハンズオン / CLI例

# サインインして対象サブスクリプションを選択
az login
az account set --subscription "<subscription-id>"

# リソースグループを作成
az group create --name demo-rg --location japaneast

# ユーザー(またはグループ)に「閲覧者」ロールをリソースグループスコープで割り当て
az role assignment create \
  --assignee "user@example.com" \
  --role "Reader" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/demo-rg"

# VM にシステム割り当てマネージド ID を有効化し、そのプリンシパル ID を取得
PRINCIPAL_ID=$(az vm identity assign \
  --resource-group demo-rg --name demo-vm \
  --query systemAssignedIdentity -o tsv)

# そのマネージド ID にストレージ Blob 読み取り権限を付与（資格情報レスでアクセス可能に）
az role assignment create \
  --assignee-object-id "$PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/demo-rg/providers/Microsoft.Storage/storageAccounts/<account>"

# 付与済みのロール割り当てを確認（トラブル時の切り分けに便利）
az role assignment list --scope "/subscriptions/<subscription-id>/resourceGroups/demo-rg" -o table