Microsoft AZ-204: Azure の認証、承認、およびセキュリティ — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

概要

Azureの認証と認可は、Microsoft Identity Platformを基盤としています。このプラットフォームは、ID（ユーザー、アプリ、ワークロード）にトークンを発行し、APIやリソースへのアクセスを強制します。アプリケーションはOAuth 2.0とOpenID Connectを介して統合し、MSALを使用してトークンを取得し、Azure ADのアプリ登録で宣言されたアクセス許可を要求します。Azure上で実行されるワークロードは、マネージドIDを使用することで資格情報を完全に排除し、Azure RBACを利用してKey Vault、Storage、Microsoft Graphなどのサービスにアクセスできます。シークレット管理はAzure Key Vaultが中心となり、コンテナーのデータプレーンアクセスと管理プレーン制御が明確に分離されています。また、論理的な削除（soft delete）と消去保護（purge protection）により、強力な回復性が保証されます。ストレージについては、Shared Access Signatures (SAS) が、アカウントキーを公開することなく、クライアントに対してスコープが限定され、時間制限のある委任を提供します。

Microsoft Identity Platform、OAuth 2.0、MSAL、およびアプリ登録

Microsoft Identity Platformは、さまざまなアプリケーションタイプに最適化された複数のOAuth 2.0フローをサポートしています。

• 認可コードフロー: Webアプリ、SPA、ネイティブアプリの標準的なフローです。パブリッククライアントは、認可コードを保護するためにPKCEを使用する必要があります。アプリはユーザーを認可エンドポイントにリダイレクトし、リダイレクトURIで認可コードを受け取り、それをトークンエンドポイントでアクセストークン（およびオプションでリフレッシュトークン）と交換します。SPAの場合、認可コード + PKCEは、従来のインプリシットフローを置き換え、トークンの漏洩を軽減します。
• クライアント資格情報フロー: ユーザーが介在しないデーモンやサーバー間サービスで使用されます。アプリケーションは、クライアントアサーション（証明書）またはクライアントシークレットを使用してトークンを要求します。ここではアプリケーションのアクセス許可（アプリロール）のみが利用可能で、そのほとんどは管理者の同意が必要です。このフローでは、静的に構成されたアプリケーションのアクセス許可セットを要求するために、/.defaultスコープを使用します。
• デバイスコードフロー: 組み込みブラウザを持たないデバイスや環境向けに設計されています。アプリはIDプラットフォームからユーザーコードと確認用URLを取得し、ユーザーは別のデバイスで認証を行い、アプリはトークンエンドポイントをポーリングします。ユーザーがサインインするため、委任されたアクセス許可が適用されます。
• インプリシットグラントフロー: かつてSPAが認可エンドポイントから直接トークンを受け取るために使用されていました。現在では、PKCE付きの認可コードフローの使用が推奨されており、このフローは非推奨です。使用する場合でも、アプリ登録時にリダイレクトURIが必要です。

MSAL (Microsoft Authentication Library) は、言語やプラットフォームを問わず、一貫したトークン取得方法を提供します。パブリッククライアントアプリケーション（デスクトップ、モバイル、SPA）は、AcquireTokenInteractiveとAcquireTokenSilentを使用してトークンを取得・キャッシュします。ネイティブアプリは、デバイスコードフローのためにAcquireTokenByDeviceCodeを、また、コンフィデンシャルクライアントのコンテキストで認可コードを交換するためにAcquireTokenByAuthorizationCodeも使用します。コンフィデンシャルクライアント（Webアプリ/API/デーモン）は、クライアント資格情報を使用する場合はAcquireTokenForClientで、APIがユーザーの委任されたコンテキストでダウンストリームAPIを呼び出すOBOシナリオではAcquireTokenOnBehalfOfでトークンを取得します。

トークンキャッシュはMSALに不可欠な機能です。アカウント、クライアント、スコープをキーとしてアクセストークンとリフレッシュトークンを保存し、AcquireTokenSilentが不要な対話型プロンプトを回避できるようにします。複数のインスタンスで実行されるWebアプリやAPIは、共有された暗号化ストア（例：保存時および転送時に適切に暗号化された分散キャッシュ）を使用して、トークンキャッシュを永続化し保護する必要があります。MSALのキャッシュシリアル化フックにより、安全な永続化が可能になります。スコープは、アプリが要求するアクセス許可を識別します。委任されたアクセス許可の場合、最小限のリソース固有のスコープ（例：https://graph.microsoft.com/User.Read）を要求します。クライアント資格情報の場合、リソースベースの/.defaultを要求します。これは、アプリに静的に付与されたアプリケーションのアクセス許可にマッピングされます（例：scope = https://graph.microsoft.com/.default）。段階的な同意（incremental consent）を利用して、スコープを段階的に要求し、ユーザーの手間を減らします。

Azure ADのアプリ登録は、アプリケーションのID、資格情報、リダイレクトURI、およびアクセス許可を定義します。委任されたアクセス許可はサインインしたユーザーを必要とし、多くの場合、ユーザー自身のデータに対してユーザー自身が同意できます。一方、アプリケーションのアクセス許可はアプリ自体に付与され、テナント全体または広範囲に適用されるため、ほとんどの場合、管理者の同意が必要です。APIを公開するアプリは、「APIの公開」セクションでスコープ（委任されたアクセス許可の場合）とアプリロール（アプリケーションのアクセス許可の場合）を宣言します。信頼の境界に応じてシングルテナントまたはマルチテナントアクセスを構成し、より強力な資格情報と容易なローテーションのために、クライアントシークレットよりも証明書を使用します。

Microsoft Graphも同じトークン発行メカニズムを使用します。MSALでGraphリソースをターゲットとして認証し、最小権限のスコープを要求します。一般的なエンドポイントには以下が含まれます。

• GET https://graph.microsoft.com/v1.0/me: 委任されたトークン（例：User.Read）を使用してユーザープロファイルを取得
• GET https://graph.microsoft.com/v1.0/users および /groups: ディレクトリオブジェクトを取得（User.Read.AllやGroup.Read.Allなど、適切な委任されたアクセス許可またはアプリケーションのアクセス許可が必要）
• GET https://graph.microsoft.com/v1.0/sites または /drives: SharePoint/OneDriveの操作を実行 クライアント資格情報を使用する場合、/.defaultスコープを要求し、必要なアプリケーションのアクセス許可に対して管理者の同意が存在することを確認します。適切なauthority（テナント固有か、common/organizationsか）を選択して、ユーザーがサインインできる場所とトークンが発行される場所を制御します。

マネージドIDとAzureリソースへのセキュアなアクセス、およびKey Vault参照

AzureリソースのマネージドIDは、Azureがサービスプリンシパルの資格情報を管理できるようにすることで、シークレットを不要にします。システム割り当てマネージドIDは、リソース（App Service、Function App、VM、VMSS、Logic Appなど）と1対1で結び付けられ、そのライフサイクルを共有します。リソースが削除されると、IDも削除されます。ユーザー割り当てマネージドIDは、スタンドアロンのAzureリソースとして作成され、複数のコンピューティングリソースにアタッチでき、特定のワークロードのライフサイクルとは独立して存在します。このモデルは、IDの再利用と職務の分離をサポートします。

マネージドIDを使用してAzureリソースにアクセスするには、適切なスコープで適切なAzure RBACロールを付与します。

• Azure ADを利用したAzure Storageデータプレーンの場合、ストレージアカウント、コンテナー、またはRG/サブスクリプションのスコープで、Storage Blob Data Reader/Contributorなどのロールを割り当てます。
• Key Vault（RBACデータプレーンモデル）の場合、Key Vault Secrets UserやKey Vault Crypto Officerなどのロールを割り当てます。
• アプリケーションのアクセス許可を介したMicrosoft Graphの場合、マネージドIDは、アプリの登録が関連付けられた後にのみダウンストリームAPIを呼び出すことができます。必要に応じて、ワークロードIDフェデレーションを使用するか、エンタープライズアプリのアクセス許可と管理者の同意を構成します。

実行時には、VM上のインスタンスメタデータサービス（IMDS）またはApp Serviceが管理するエンドポイントを使用してトークンを取得します。Azure IdentityのDefaultAzureCredentialのようなSDKは、利用可能な場合、自動的にマネージドIDエンドポイントを使用します。これにより、シークレットを保存する必要がなくなり、プラットフォームによるローテーションがサポートされます。

App ServiceおよびAzure FunctionsのKey Vault参照を使用すると、コードを変更することなく、アプリケーション設定にシークレットを安全に取得できます。アプリケーション設定の値には、@Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version})という参照構文を使用します。プラットフォームは、起動時にアプリのマネージドIDを使用してこの参照を解決し、定期的に更新します。マネージドIDが、Key Vaultアクセスポリシーを介してシークレットに対するGet権限を持っているか、RBACデータプレーンモデルを使用している場合はKey Vault Secrets Userロールを持っていることを確認してください。Key Vault参照は、アプリの構成ストア内に平文で保存すべきではない構成値に最適であり、アプリケーションコードからシークレット処理ロジックを排除します。

Azure Key Vault: シークレット、キー、証明書、およびアクセス制御

Azure Key Vaultは3種類のオブジェクトを格納します。

• シークレット: パスワード、接続文字列、APIキーなどの不透明な文字列。バージョン管理され、クライアントは通常、GetおよびSet操作を実行します。
• キー: 署名/検証、暗号化/復号化、およびラップ/アンラップ操作に使用される暗号化キー（RSA、EC）。キーマテリアルはHSMで保護されたサービスによって保護されます。クライアントは、秘密キーマテリアルをエクスポートするのではなく、サービスを介して暗号化操作を呼び出します。
• 証明書: ライフサイクル管理機能を備えたX.509オブジェクトで、オプションでパートナーCAと統合できます。証明書は、証明書とそれに対応するシークレット（PFX）、およびオプションでマネージドキーとして具体化されます。

論理的な削除はデフォルトで有効になっており、削除されたオブジェクトを保持期間中保存します。消去保護を有効にすると、保持期間内の回復不可能な削除を防ぎ、回復の保証（多くの場合、90日間の保持要件）を強制できます。論理的な削除と消去保護を組み合わせて、厳格な回復ポリシーに対応します。さらに、プライベートエンドポイントでコンテナーのネットワークアクセスを保護し、可能な場合はパブリックネットワークアクセスを無効にします。

アクセス制御には、従来のコンテナーアクセスポリシーまたはデータプレーン用のAzure RBACを使用できます。アクセスポリシーはコンテナーごとに構成され、プリンシパルに明示的に権限（Get、List、Set、Sign、Wrap）を付与します。これらは継承されず、大規模になると運用上の負担が大きくなる可能性があります。RBACデータプレーンモデルは、Azureロール（例: Key Vault Administrator、Key Vault Secrets Officer、Key Vault Secrets User、Key Vault Crypto Officer）を使用し、Azure RBACに統合された監査機能とともに、サブスクリプション、リソースグループ、またはコンテナーレベルでのスコープ設定をサポートします。どちらか一方のモデルを選択します。データプレーンに対してRBACが有効になっている場合、アクセスポリシーは無視されます。管理プレーンの操作（コンテナーの作成/更新）は、常にAzure RBACを使用します。

Azure SDK（例: SecretClient、KeyClient、CertificateClient）とDefaultAzureCredentialを使用して、Key Vaultをアプリケーションと統合します。認証にはマネージドIDを使用し、資格情報の埋め込みを避け、Vault APIを呼び出す際には再試行およびスロットリングポリシーを実装することが推奨されます。

Azure Storage SAS と保存されたアクセス ポリシー

共有アクセス署名 (SAS) は、アカウントキーを公開することなく、Azure Storage へのきめ細かく、時間制限のあるアクセスを委任します:

• ユーザー委任 SAS (Blob のみ): Azure AD によってサポートされます。アプリケーションは Azure AD の資格情報を使用して Blob サービスからユーザー委任キーを取得し、クライアント用の SAS トークンを作成します。これは、アカウントキーの使用を避け、ロールベースの認可と整合するため、ユーザー中心のシナリオで最も安全なアプローチです。
• サービス SAS: 特定のリソース (blob、コンテナー、キューメッセージ、テーブルエンティティ、ファイル) にスコープが限定されます。アカウントキーで署名されます。サービスに応じて、読み取り、書き込み、追加、作成、削除、一覧表示、不変性の設定、タグなどのアクセス許可をサポートします。
• アカウント SAS: 複数のサービス (Blob、Queue、Table、File) とリソースタイプにわたる最も広いスコープを持ちます。影響範囲が広いため、使用は控えめにしてください。

SAS トークンには、有効期限 (se)、開始時刻 (st)、アクセス許可 (sp)、IP 範囲 (sip)、許可されるプロトコル (spr)、署名付きリソース (sr)、そして保存されたアクセス ポリシーにバインドされている場合は署名付き識別子 (si) などの制約が含まれます。必要なアクセス許可のみを付与し、有効期限を短く設定し、HTTPS (spr=https) を強制することで、最小権限の原則に従ってください。可能な限りユーザー委任 SAS を優先し、それ以外の場合は、失効のために保存されたアクセス ポリシーを持つサービス SAS を使用してください。

保存されたアクセス ポリシーは、コンテナー、ファイル共有、キュー、またはテーブル上に存在し、再利用可能な制約 (アクセス許可、開始時刻、有効期限) のセットを定義します。SAS を作成する際に、その識別子によってポリシーを参照します。これにより、すべての SAS トークンを再発行することなく、一元的に失効させたり、スコープを厳格化したりできます。ポリシーを更新または削除すると、それにリンクされているすべての SAS トークンに即座に影響が及びます。サービス SAS またはアカウント SAS を使用する場合は、アカウントキーを定期的にローテーションし、診断設定と Azure Monitor ログを通じて使用状況を監視してください。

実践的な問題シナリオ

Adobe は、Azure 上でマルチテナントのメディア処理ポータルを展開しています。顧客は自身の Microsoft Entra ID テナントでサインインし、大きなメディアファイルを Blob ストレージに直接アップロードし、処理ステータスを追跡します。このソリューションでは、シークレットの保存を避け、権限を一元管理し、シークレットを少なくとも 90 日間回復可能にすることが求められます。

1. Microsoft Entra ID にアプリケーションを登録します:

   • ポータル UI 用の SPA と、バックエンド API 用の Confidential Client を作成します。委任されたアクセス用に API スコープを公開し、バックグラウンドジョブ用にアプリロールを定義します。SPA が正確なリダイレクト URI を使用して認可コード + PKCE を使用するように構成します。これにより、各クライアントが正しい OAuth フローに準拠し、最小権限の同意境界が強制されます。

2. SPA とバックエンドに MSAL を実装します:

   • SPA は、増分同意 (incremental consent) を用いて AcquireTokenInteractive/AcquireTokenSilent を使用し、バックエンド API 用のトークンを取得します。バックエンドは AcquireTokenOnBehalfOf を使用して Microsoft Graph を呼び出し、サインインしているユーザーの基本プロファイルを読み取ります。これにより、ユーザーコンテキストがエンドツーエンドで維持され、トークンキャッシングによってプロンプトが最小限に抑えられます。

3. App Service (API) と Azure Functions (メディアプロセッサ) でシステム割り当てマネージド ID を有効にします:

   • メディアコンテナーに Storage Blob Data Contributor ロールを、Key Vault に Key Vault Secrets User ロールを割り当てます。マネージド ID はシークレットの拡散をなくし、プラットフォームが資格情報を自動的にローテーションできるようにすると同時に、Azure RBAC を介した Storage と Key Vault への安全なアクセスを可能にします。

4. RBAC データプレーン、論理削除 (soft delete)、消去保護 (purge protection) を使用して Azure Key Vault を構成します:

   • バックエンドアサーション用の署名証明書、サードパーティ API キー、および AAD に置き換えることのできない接続シークレットを保存します。消去保護と論理削除を強制して、90 日間の回復を保証します。RBAC は、コンテナーごとのアクセス ポリシーと比較して、監査を簡素化し、環境全体でスケーリングできます。

5. 構成に Key Vault 参照を使用します:

   • App Service と Functions のアプリ設定で、@Microsoft.KeyVault(SecretUri=…) を使用してシークレットを参照します。プラットフォームはマネージド ID を使用して値を解決および更新するため、コードの変更が不要になり、シークレットが平文の構成に保存されるのを防ぎます。

6. SAS を使用してブラウザからの直接アップロードを委任します:

   • バックエンドは、IP と HTTPS でスコープが限定された特定の Blob パスへの短期間の書き込み専用アクセス用に、ユーザー委任 SAS トークンを発行します。運用バッチツール用には、コンテナー上の保存されたアクセス ポリシーに関連付けられたサービス SAS を作成し、ポリシーを更新または削除することでトークンを一元的に失効できるようにします。これにより、アカウントキーを公開することなく、高スループットのクライアントアップロードが可能になり、緊急時の失効もサポートされます。

7. Microsoft Graph を最小限に統合します:

   • SPA でプロファイル表示用に https://graph.microsoft.com/User.Read を要求し、バックエンドでは (事前の管理者同意を得て) アプリケーションのアクセス許可が必要な場合に https://graph.microsoft.com/.default を使用します。/.default を使用することで、バックエンドは一元的に付与されたアプリケーションのアクセス許可を尊重し、実行時にスコープを過剰に要求することを回避します。

この設計では、認可コード + PKCE を使用して SPA を保護し、OBO を使用して下流のユーザーコンテキストを維持し、マネージド ID と RBAC を使用してシークレットを排除し、強力な回復保証を持つ Key Vault を使用し、クリーンな構成管理のために Key Vault 参照を使用し、最小権限のスコープで Graph を使用し、安全で失効可能なクライアントアップロードのために保存されたアクセス ポリシーを持つ SAS を使用します。

← Azure コンテナーソリューション · すべてのドメイン · Azure API Management →

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

Microsoftを閲覧 →