AZ-305：Designing Microsoft Azure Infrastructure Solutions ID・ガバナンス・監視ソリューションの設計 問5
ID・ガバナンス・監視ソリューションの設計／認証と認可ソリューションの設計ある企業は、Azure App Service 上の 5 つの Web アプリから、データベースの接続文字列と外部 API キーを取得させようとしています。要件は、ソースコードやアプリ設定に資格情報を平文で持たせないこと、アプリごとに必要なシークレットだけを読めるようにすること、シークレットの値を変更してもアプリを再デプロイしなくてよいことです。シークレット管理の設計として最適なものはどれですか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「ID・ガバナンス・監視ソリューションの設計」に対応。実際の試験問題ではありません）
- AAzure Key Vault を Azure RBAC 権限モデルで構成し、各アプリにシステム割り当てマネージド ID を有効にして、必要なシークレットにだけ Key Vault シークレット ユーザーを割り当てる
- B1 つのユーザー割り当てマネージド ID を全アプリで共有し、その ID に Key Vault 管理者ロールをコンテナー全体のスコープで割り当てて、全シークレットを読めるようにする
- Cアプリ用のサービスプリンシパルを作成し、そのクライアント シークレットを各アプリの構成に保存して、Key Vault のアクセス ポリシーからシークレットの取得を許可する
- Dシークレットを暗号化した BLOB としてストレージアカウントに置き、各アプリに共有アクセス署名（SAS）トークンを配布して、起動時に読み込ませる
正解：A
解説
資格情報をアプリに持たせずに Azure リソースへ認証する方法はマネージド ID で、シークレットの格納は Azure Key Vault が適切です。Azure RBAC 権限モデルなら、アプリごとのマネージド ID に対して、個別のシークレット単位でも Key Vault シークレット ユーザーのような最小権限ロールを割り当てられます。シークレットを更新しても、Key Vault 参照を使うアプリは再デプロイなしに新しい値を取得できます（バージョンを指定しない参照では、更新は最大 24 時間以内に反映されます）。ID を共有して管理者権限を与える、クライアント シークレットを保存する、といった設計は、最小権限や資格情報の持ち込みという要件に反します。
選択肢ごとの解説
- A正しい。マネージド ID で資格情報を持たずに認証でき、RBAC でアプリごと・シークレットごとに最小権限を実現し、値の変更も再デプロイ不要です。
- B誤り。ID を共有し管理者ロールをコンテナー全体に与えると、全アプリが全シークレットを読め、最小権限に反します。1 つのアプリの侵害の影響範囲も広がります。
- C誤り。クライアント シークレット自体が新たな管理対象の資格情報になり、アプリ設定に資格情報を持たせないという要件に反します。期限切れとローテーションの負荷も生じます。
- D誤り。暗号化 BLOB と SAS の配布では SAS が資格情報として配布・管理の対象になり、アプリごとの最小権限やローテーションの管理が複雑です。シークレット管理に適した専用サービスではありません。