Instiq
第3章 · Azure セキュリティの実装·v2.0.0·更新 2026/6/16·読了目安 約8分

変更要約: AZ-204 第3章を Associate 級に深掘り(比較表・シナリオ・FAQ・ひっかけ+深掘り段落、図を日本語化)

3.2シークレット管理(Key Vault・マネージド ID)

この節の要点

Azure Key Vault によるシークレット/キー/証明書の管理、マネージド ID によるキー不要の認証、App Service/Functions からの Key Vault 参照といった実装を理解します。

パスワードや API キーはコードに書かず Azure Key Vault に保管します。アクセスには資格情報を持たない マネージド ID を使うのがベストプラクティスです。

3.2.1Key Vault とマネージド ID

アプリ/Function(マネージド ID)→Microsoft Entra ID(保存する秘密なし・ID 用のトークン)→Key Vault(シークレット/キー/証明書・RBAC/ポリシーでアクセス)という流れを示し、保存シークレットを持たないマネージド ID が Entra ID で認証して Key Vault のシークレットを読む旨を表した図。
Key Vault とマネージド ID
  • Key Vaultシークレット・キー・証明書を安全に保管し、アクセスを RBAC/アクセスポリシーで制御・監査する。
  • マネージド ID:Entra ID が自動管理する ID。資格情報を保存せずに Key Vault 等へアクセスできる。
  • Key Vault 参照:App Service/Functions のアプリ設定から @Microsoft.KeyVault(...) でシークレットを直接参照できる。
試験ポイント

「シークレットの安全な保管=Key Vault」「資格情報を保存せずアクセス=マネージド ID」「アプリ設定からシークレット参照=Key Vault 参照」 は AZ-204 で頻出です。接続文字列をコードに直書きするのは誤りです。

シークレットはコードに書かず Key Vault に保管し、アクセスは マネージド ID で行うのが鉄則です。Key Vault は シークレット(接続文字列等)・キー(暗号化/署名・HSM 保護も)・証明書 を保管し、アクセス制御は RBAC(推奨) または アクセスポリシー、操作は監査ログに残ります。マネージド ID は資格情報を保存しない Entra ID の ID で、システム割り当て(リソースに1:1・ライフサイクル連動)と ユーザー割り当て(独立リソースで複数に共有)があります。App Service/Functions では Key Vault 参照(アプリ設定に @Microsoft.KeyVault(...))でコード変更なしにシークレットを注入でき、内部でマネージド ID が解決します。誤削除/復旧のために 論理削除(soft delete)+purge protection、キーの定期更新は ローテーション。判断軸は「機密の保管=Key Vault」「キーレスでアクセス=マネージド ID」「設定から直接参照=Key Vault 参照」「リソース専用=システム割り当て/共有=ユーザー割り当て」。接続文字列やキーをコード/平文環境変数に置くのは誤り。

やりたいこと使うもの
機密(接続文字列等)の保管Key Vault シークレット
資格情報を持たずにアクセスマネージド ID
設定から直接シークレット注入Key Vault 参照
複数リソースで ID 共有ユーザー割り当てマネージド ID

シナリオ:複数の Functions/App Service が同じ DB 資格情報と暗号鍵を安全に使いたい。 資格情報・鍵は Key Vault に集約。複数リソースで使うので ユーザー割り当てマネージド ID を作り各リソースに割り当て、Key Vault に RBAC で読み取り権限を付与。アプリ設定は Key Vault 参照でコード変更なしに注入。誤削除対策に soft delete+purge protection、鍵は定期 ローテーションします。

補足

Q. 機密の保管は? Key Vault。Q. キーレスでアクセス? マネージド ID。Q. 設定から直接参照? Key Vault 参照。Q. 複数リソースで共有する ID? ユーザー割り当て。Q. リソース連動の ID? システム割り当て。Q. 誤削除復旧? soft delete+purge protection。

注意

混同に注意:
システム割り当て(リソース1:1)とユーザー割り当て(共有可)は別物——複数リソースで共有なら後者。
②マネージド ID には Key Vault 側でアクセス権(RBAC/ポリシー)付与が必要——ID を有効化しただけでは読めない。
③接続文字列/キーをコード・平文環境変数に置かない(Key Vault 参照を使う)。
④purge protection 有効時は完全削除に待機期間がある。

コツ

システム割り当てマネージド ID はリソースのライフサイクルに紐づき、ユーザー割り当ては複数リソースで共有できます。要件で選びます。

3.2.2この節のまとめ

  • Key Vault(保管)+マネージド ID(キー不要アクセス)
  • アプリ設定からKey Vault 参照で直接取得

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. パスワードや API キー、証明書を安全に保管する Azure のサービスはどれですか?

Q2. アプリが資格情報を保存せずに Key Vault へアクセスする最も推奨される方法はどれですか?

Q3. App Service のアプリ設定から Key Vault のシークレットを直接参照する仕組みはどれですか?

理解度を確認第3章「Azure セキュリティの実装」の問題を解く