Microsoft AZ-500: ID とアクセス管理 — 学習ガイド

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Security Engineer Associate AZ-500 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Microsoft AzureにおけるIDおよびアクセス管理 (IAM) は、Microsoft Entra ID (旧 Azure AD) を中心に構成されます。これは、誰が、どのような条件下で、どのリソースに、どのような権限でアクセスできるかを管理します。効果的なIAMアーキテクチャは、常時存在する特権を最小限に抑え、条件付きおよびリスクベースのアクセスを強制し、人間とワークロードの両方に最新の認証を採用すると同時に、ハイブリッドおよび外部コラボレーションのシナリオをサポートします。

Microsoft EntraのID構成要素とスコープ

テナント、ユーザー、グループ
- テナントは、組織のID境界と信頼の基盤を表します。ユーザーには、メンバーアカウントまたはゲスト (B2B) アカウントがあります。認可にはセキュリティグループを、コラボレーション機能にはMicrosoft 365 グループを使用します。手動でのメンバーシップ管理を減らすために、動的グループの使用が推奨されます。
管理単位 (AU)
- AUを使用すると、ユーザー/デバイスのサブセットに対してディレクトリロールを委任できます (例: 地域のヘルプデスクはヨーロッパのユーザーのみを管理できる)。これにより、ディレクトリタスクに対する最小特権がサポートされます。
ディレクトリロールとロール割り当てスコープ
- ディレクトリロール (例: Global Administrator、User Administrator) は、Microsoft Entraのリソースに適用されます。影響範囲を限定するために、可能な場合はディレクトリロールのスコープをAUに設定します。Privileged Identity Management (PIM) を初期設定するには、Global Administratorロールが必要です。
Azure ロールベースのアクセス制御 (Azure RBAC) のスコープ
- Azure RBACは、Azureリソースへのアクセスを管理します。ロールは、管理グループ、サブスクリプション、リソースグループ、またはリソーススコープで割り当てます。継承は下位に流れます。過剰な特権を減らすために、常に実用的な最も狭いスコープを選択してください。
運用の観点
- ディレクトリロール (Entra) とAzure RBAC (リソース認可) を分離します。AUと厳密なRBACスコープを使用して、管理範囲を限定し、ラテラルムーブメントの機会を減らし、アクセスレビューを簡素化します。

Azure RBACと最小特権によるアクセス制御

組み込みロールと最小特権
- タスクに適合する最も具体的な組み込みロールを選択することが推奨されます。例: 広範なContributorロールの代わりに、コンテナイメージのプル専用アクセスにはAcrPullを、アップロード/プッシュアクセスにはAcrPushを付与します。Key Vaultの場合、RBACによる管理制御はコンテナー管理者のみに付与し、証明書管理などの特定のオブジェクト操作には詳細なアクセスポリシーを使用します。
ロール割り当ての継承
- 可能な限り低いスコープで割り当てます。管理グループまたはサブスクリプションの割り当てはカスケードします。意図的でない限り、広範な継承権限は避けてください。複数のサブスクリプションにわたって一貫したRBACが必要な場合は、手動のPIM割り当てではなく、Azure Blueprints (または最新のIaC代替手段) を通じて一貫したロール割り当てを適用します。
拒否割り当て
- 拒否割り当ては、許可割り当てに関係なくアクションを明示的にブロックし、通常はAzure PolicyやBlueprintsなどのAzureサービスによって作成されます。これらを使用して、交渉の余地のないガードレール (例: 機密リソースに対するパブリックネットワークルールの防止) を強制します。
カスタムロール
- 組み込みロールが広すぎる場合は、必要なアクションのみを含むカスタムロールを定義します。最小特権のテストとアクセスレビューを通じて検証します。

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

運用の観点
- RBACのスコープ設定とカスタムロールは、過剰なエンタイトルメントと監査対象を削減します。拒否割り当ては、誤って広範な「許可」が付与されてもバイパスできない「厳格な」コンプライアンス制約をエンコードし、ポスチャの回復性を向上させます。

特権アクセス、条件付きアクセス、ID保護

Privileged Identity Management (PIM)
- 資格あり vs アクティブ: 「資格あり」の割り当ては常時存在するアクセス許可を付与しません。ユーザーはアクティブになるためにJITでアクティブ化する必要があります。アクティブ化時に承認、正当な理由、MFAを強制します。期間を限定し、トレーサビリティのためにチケット参照を要求します。まず特権ロールを検出して現在の露出状況を理解することから始めます。定期的なアクセスレビューを使用し、理想的にはリソースまたはグループの所有者をレビュー担当者として、継続的な必要性を検証します。
条件付きアクセス (CA)
- 割り当ては、ユーザー/グループ、ワークロードID、クラウドアプリ、アクションを対象とします。条件には、サインインリスク、デバイスのプラットフォーム/状態、場所、クライアントアプリ、デバイスとアプリのフィルターが含まれます。許可制御では、MFA、準拠しているかハイブリッドAzure AD参加済みのデバイス、アプリ保護ポリシー、または利用規約を要求できます。セッション制御は、サインイン頻度、永続的なセッション、アプリによって強制される制限 (例: SharePointのWebのみアクセス) を制約します。ポリシーを適用する前に、レポート専用モードを使用してポリシーの影響を安全に検証します。ロックアウトを防ぐために、緊急アクセス用アカウントの除外と段階的な展開を維持します。
Identity Protection
- ユーザーリスクはアカウントが侵害されている可能性を反映し、サインインリスクは特定のセッションが危険である可能性を反映します。安全な修復を要求するようにポリシーを構成します。
  - 漏洩した資格情報を持つユーザー: 高いユーザーリスクとして扱い、パスワードのリセットを強制し、修復されるまでブロックします。
  - 不審なアクティビティのあるIPからのサインイン: 少なくとも中程度のサインインリスクとして扱い、MFAでチャレンジするか、機密性の高いアプリへのアクセスをブロックします。
- CAと統合して、信頼をリアルタイムで適応させます。リスク履歴と修復を追跡して、有効性を測定します。
運用の観点
- PIMは常時存在する特権を排除し、強力で監査可能なアクティブ化を強制します。CAとIdentity Protectionはゼロトラストを適用し、ユーザー、デバイス、セッション、リスクに基づいて各アクセス試行を検証することで、資格情報の盗難やトークンリプレイの成功を減らします。

ハイブリッド ID とワークロード ID

ハイブリッド ID のオプション
- パスワードハッシュ同期 (PHS): パスワードハッシュを Entra ID に同期します。シンプルで回復性がありますが、認証時にオンプレミスのサインインポリシーは適用されません。
- パススルー認証 (PTA): 軽量なコネクタを介してオンプレミスの DC に対してパスワードを検証します。AD FS を使用せずに、オンプレミスのパスワードポリシーとアカウント制限をリアルタイムで適用します。
- フェデレーション (例: AD FS): 認証をオンプレミスの STS に移行します。複雑なクレームやレガシーシナリオで必要な場合にのみ使用します。サーバーの数と運用オーバーヘッドが増加します。
- シームレスシングルサインオン (シームレス SSO): 社内ネットワーク内のドメイン参加済みデバイス上のユーザーを、最小限のプロンプトでサインインさせます。
- 運用上の選択: サーバーを最小限に抑えつつ、オンプレミスのパスワードポリシーとアカウント制限を適用するには、PTA とシームレス SSO をデプロイし、PTA に依存しないシナリオの回復性/フェイルオーバーのために PHS も有効にします。フェデレーションだけでは複雑さが増し、「サーバーを最小限に抑える」という目標を達成できません。
ハイブリッド参加済みの Windows デバイスから Azure SQL へのアプリ認証
- プロンプトを最小限に抑え、該当する場合には Kerberos/SSO を活用するために、Active Directory 統合認証を使用します。
マネージド ID とサービスプリンシパル
- マネージド ID (システム割り当てまたはユーザー割り当て) は、シークレットを排除し、資格情報を自動的にローテーションするため、Azure でホストされるワークロードの第一選択です。リソーススコープで、ID に最小権限の RBAC を割り当てます。
- サービスプリンシパルはアプリの登録を支えます。クライアントシークレットよりも証明書資格情報を使用し、実現可能な限り短い有効期間を設定します。
ワークロード ID フェデレーション
- OIDC フェデレーションを使用して、外部のワークロード ID (例: GitHub Actions, Kubernetes) がシークレットを保存することなく Entra アプリのトークンを取得できるようにします。トークンを交換できるユーザーを制約するために、発行者 (issuer)、サブジェクト (subject)、および対象者 (audience) のクレームを正確に定義します。

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

AKS から ACR へのアクセス
- attach-acr フローを使用して、ターゲットレジストリに対して AKS クラスターのマネージド ID に AcrPull 権限を付与します。これにより、適切なスコープ設定が自動化され、誤った割り当てを回避できます。

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

運用上の論理的根拠
- PTA+PHS+シームレス SSO は、クラウドの回復性を維持しつつ、リアルタイムのオンプレミスコントロールを適用します。マネージド ID とフェデレーションは、パイプラインとランタイムから静的なシークレットを削除し、頻繁に発生する資格情報盗難の経路を閉じます。

外部コラボレーション、認証方法、アプリへのアクセス

外部IDとB2Bコラボレーション
- テナント間アクセス設定、利用規約、ゲストを対象とするCAを使用してB2Bゲストアカウントを利用します。招待できるユーザーを制限し、エンタイトルメント管理によるジャストインタイムアクセスを推奨します。
エンタイトルメント管理とアクセスパッケージ
- グループ、アプリ、SharePointサイトをアクセスパッケージにバンドルし、誰が要求できるか（外部ユーザーを含む）、承認フロー、割り当て期間、アクセスレビューを定義するポリシーを設定します。レビュー担当者の選択には、リソースの管理者にビジネス上の責任を持たせるため、「グループの所有者」を使用します。
認証方法とパスワードレス
- 強力な方法に標準化します：FIDO2セキュリティキー、Windows Hello for Business、Microsoft Authenticatorの電話によるサインイン。統合されたセキュリティ情報登録（SSPR + MFA）を使用し、すべてのユーザーにMFA登録ポリシーを強制します。必要に応じてオンプレミスへのライトバックを有効にしたSSPRを有効にし、安全な方法を要求し、可能な限り企業が管理する要素に限定します。レガシー/基本認証プロトコルを無効にし、リスクが許容できない場合は脆弱なSMSのみのMFAをブロックします。
Microsoft Entra application proxy
- 受信ファイアウォールポートを開けることなく、オンプレミスのWebアプリを公開します。HAのためにコネクタグループを使用し、Entra IDで事前認証を行い、レガシーアプリにゼロトラストを適用するためにCA、デバイスコンプライアンス、Identity Protectionを階層化します。
アプリケーション登録のセキュリティ
- 管理者の同意ワークフローを要求し、アプリを作成できるユーザーを制限し、アクセス許可を分類します。ユーザーコンテキストが不要な場合にのみアプリケーションの許可を優先し、APIのスコープを最小限に設定します。可能な場合は暗黙的な許可フローを無効にし、エンタープライズアプリへの割り当てを要求し、シークレットよりも証明書を優先して自動ローテーションさせます。

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

運用の観点からの理由
- アクセスパッケージとアプリプロキシは、ガバナンスの効いた、監査可能な外部アクセスを提供します。強力なパスワードレス方式はフィッシング耐性を高めます。厳格なアプリ登録制御は、過剰な同意を防ぎ、アプリの偽装の可能性を低減します。

実践的な問題シナリオ

Adobe Inc.は、サードパーティベンダーに対し、Azureリソースのサブセットへの一時的な管理者アクセスを許可し、社内のレガシーWebアプリをそのベンダーに公開する必要があります。その際、強力な認証を強制し、恒久的な特権を排除（ゼロスタンディング特権）します。

アクセスのスコープ設定とモデル化

リソースグループ rg-vendor-ops を作成し、必要なリソースのみをその中に移動します。最小限のAzure RBACロール（例：rg-vendor-ops に対する共同作成者、診断用リソースグループに対する閲覧者）を割り当てます。
理由：スコープを絞り込むことで、ラテラルムーブメント（横方向の移動）を防ぎます。ロールの継承は rg-vendor-ops に限定され、影響範囲（ブラスト半径）を抑制します。

PIMによるIDとアクティベーションの管理

ベンダーの管理者を、必要なロールに対して永続的ではなく「資格あり（eligible）」の状態にします。アクティベーション時に承認、チケットID、MFAを要求し、アクティベーションを4時間に制限します。まずPIMの「特権ロールの検出」を実行して、既存の割り当てをベースライン化します。
理由：「資格あり」の割り当ては、恒久的な特権を排除します。承認とMFAは、サポート時間帯に合わせたJITアクセスを強制し、監査可能な制御を提供します。

条件付きアクセスとリスクポリシーの強制

ベンダーグループ、Azureポータル、ARM APIを対象とするCAポリシーを作成し、MFA、準拠/ハイブリッド参加済みデバイスを要求し、危険な場所からのアクセスをブロックします。最初にレポート専用モードで有効にし、その後、強制します。Identity Protectionを設定します：高いユーザーリスク（漏洩した資格情報）はパスワードリセットまでブロックし、中程度のサインインリスク（疑わしいIP）にはMFAを要求します。
理由：CAは、アクセスをデバイスの信頼性とリスクにリアルタイムで結びつけます。レポート専用モードは、展開中のサービス停止を防ぎます。リスクポリシーは、侵害されたセッションやアカウントを自動修復します。

Microsoft Entra application proxyでレガシーアプリを公開

HAのために、ベンダーに公開された別々のサブネットに2つのコネクタを展開します。Entra IDによる事前認証を設定し、エンタープライズアプリへの割り当てを要求し、同じCAポリシーを適用します。アクセスパッケージを使用して、ベンダーユーザーにエンタープライズアプリとRGロールの両方への期間限定アクセスを許可し、グループの所有者をレビュー担当者として設定します。
理由：アプリプロキシは、受信方向の公開をなくし、認証を一元化します。エンタイトルメント管理は、オンボーディング/オフボーディングを標準化し、リソース所有者による定期的なレビューを保証します。

ワークロードとアプリの資格情報を保護

サービスプリンシパルのクライアントシークレットを証明書の資格情報に置き換えます。CI/CDでは、シークレットを保存する代わりにワークロードIDフェデレーションを使用します。イメージを必要とするAKSワークロードの場合、ACRをクラスターにアタッチして、マネージドIDに AcrPull を許可します。
理由：静的なシークレットを削除することで、一般的な侵害ベクトルを閉じます。フェデレーションとマネージドIDは、最小権限で自動ローテーションされるアクセスを提供します。

緊急アクセスアカウントの保護と監視

2つの緊急アクセス用アカウント（ブレークグラスアカウント）をCAから除外しますが、オフラインで保存された長いランダムなパスワードで保護します。四半期ごとにアクセスレビューを有効にし、PIMとCAのログをLog Analyticsワークスペースにエクスポートして、異常なアクティベーションに関するアラートを設定します。
理由：緊急アクセス用アカウントは、運用上の安全性を確保しつつ、テナントのロックアウトを防ぎます。継続的な監視により、不正使用を迅速に検出し、コンプライアンスとインシデント対応の準備態勢を維持します。

すべてのドメイン · ネットワークセキュリティアーキテクチャ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →