クラウドサービス

Microsoft Entra ID + RBAC

誰が何にアクセスできるかを一元管理。Microsoft Entra ID(旧 Azure AD)が認証を、Azure RBAC が認可を担い、Azure 全体のアクセス制御の土台になる。

中級セキュリティ運用上の優秀性信頼性
最終更新: 2026-06-13公式ドキュメント
3つの要点
TL;DR
  1. Azure の認証を担うクラウド ID 基盤(旧 Azure AD)。
  2. リソースへの認可は Azure RBAC が別系統で担当。
  3. AWS の IAM 相当だが認証と認可が分離している点が違い。

解決する課題

  • 全員に所有者権限を配る運用は事故のもと → 必要な人に必要なスコープだけを渡したい
  • アプリにパスワードや接続文字列を埋め込みたくない → マネージド 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 とは別系統で、テナント/ディレクトリそのものの管理権限(グローバル管理者、ユーザー管理者など)を表す
Entra ロールと Azure RBAC は別物

Entra ロール(例: グローバル管理者)は Entra ID テナントの管理用、Azure RBAC ロール(例: 共同作成者)は Azure リソースの操作用で、評価系統がまったく別です。 グローバル管理者でも、Azure サブスクリプションへの RBAC 割り当てが無ければリソースは触れません(昇格操作で自身に割り当てることは可能)。

仕様・制限・クォータ

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

内部の仕組み

認証(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)があれば、許可より優先して拒否

横にスクロール

利用者またはAzureワークロードがMicrosoft Entra IDからアクセストークンを取得し、Azure RBACがトークン、主体、ロール割り当て、スコープ継承、拒否割り当てを評価して許可または拒否する流れ
Entra IDは主体を認証して対象を限定したトークンを発行し、Azure RBACはAPI要求ごとにロール割り当てとスコープ継承を評価します。認証失敗と権限不足では確認するログが異なるため、401と403を分けて切り分けます。
RBAC は「加算」、IAM の評価ロジックとは異なる

Azure RBAC は基本的に許可の足し算(和集合)で、ロール定義に一般的な「Deny」文は書けません(NotActions は「このロールでは許可しない」の意味で、明示的拒否ではない)。 明示的な拒否は拒否割り当てという別概念で、AWS IAM の Effect: Deny のように誰でも自由に書けるものではない点に注意。

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

  • 最小権限の原則: 「所有者」を安易に配らず、閲覧者 / 共同作成者や、できる限りスコープを絞った(リソースグループ単位の)割り当てにする
  • グループにロールを割り当てる: 個人ではなく 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 ライセンスが必要です。

プラン / 機能料金の考え方主な対象機能
Free(Azure に付帯)無料ユーザー/グループ管理・SSO・Azure RBAC・マネージド ID・セルフサービスパスワードリセット(クラウド)
Microsoft Entra ID P1ユーザー単位の月額条件付きアクセス・グループベースのアプリ割り当て・高度なハイブリッド
Microsoft Entra ID P2ユーザー単位の月額(P1 上位)PIM・Identity Protection(リスクベース)・アクセスレビュー
Azure RBAC無料Azure リソースへのロール割り当て全般

セキュリティ

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

「所有者(Owner)」ロールをサブスクリプションスコープで広く配るのは典型的な事故要因。 所有者は他人へのロール割り当て権限まで持つため、権限のなし崩し的な拡大(権限クリープ)を招きます。 原則は閲覧者 / 共同作成者、付与もできる限りリソースグループ以下のスコープに絞り、特権は PIM で時間制限付きにしましょう。

関連サービス・比較(AWS との対応)

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

観点Azure(Entra ID + RBAC)AWS(IAM)
全体の位置づけID は Entra ID、認可は Azure RBAC に分離IAM が認証・認可を一体で担う
人の IDEntra ID ユーザー / グループIAM ユーザー / グループ
アプリ / ワークロードの IDサービスプリンシパル / マネージド IDIAM ロール
権限の表現ロール定義(Actions/NotActions/DataActions)JSON ポリシー(Effect/Action/Resource/Condition)
明示的な拒否拒否割り当て(ユーザーは直接作成不可)ポリシーの Effect: Deny(自由に記述可)
権限の適用範囲スコープ階層(管理グループ→サブスク→RG→リソース)で継承リソース ARN とポリシーで指定
一時的な特権昇格PIM(Just-In-Time)AssumeRole / 権限境界 など

ハンズオン / 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

Azure Service

Microsoft Entra ID + RBACを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

セキュリティ・ID

比較で見る軸

クラウド: Azure / カテゴリ: セキュリティ・ID / 難易度: intermediate

導入後に効く点

リソースへの認可は Azure RBAC が別系統で担当。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
セキュリティ・ID
難易度
intermediate
関連資格
設計柱
security / operational / reliability

判断チェックリスト

  • 自社の用途が「セキュリティ・ID / security」に近いか確認する。
  • 強みである「Azure の認証を担うクラウド ID 基盤(旧 Azure AD)。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

セキュリティ・IDsecurityoperationalreliability

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。