Azure Key Vault は、アプリケーションが使用する「秘密の情報」を安全に保管し、一元管理するためのクラウドサービスです。
簡単に言うと、**「システム専用の、非常に頑丈なデジタル金庫」**のようなものです。
なぜ必要なのか？（ビフォー・アフター）
以前は、データベースのパスワードや API キーを「ソースコード」や「設定ファイル」に直接書き込んでしまうことがありました（ハードコーディング）。しかし、これには大きなリスクがあります。
- ビフォー（危険）: コードが漏洩すると、パスワードもすべて漏れてしまう。
- アフター（安全）: コードには「Key Vault のここを見て」という指示（識別子）だけを書き、実際のパスワードは Key Vault の中で厳重に守る。
主な 3 つの管理機能
Azure Key Vault では、主に以下の 3 種類のリソースを管理します。
| 種類 | 内容（例） | 主な用途 |
| シークレット (Secrets) | パスワード、DB 接続文字列、API キー | アプリが外部サービスに接続するための情報 |
| キー (Keys) | 暗号化用の鍵（公開鍵・秘密鍵） | データの暗号化、復号、デジタル署名 |
| 証明書 (Certificates) | SSL/TLS 証明書 | Web サイトの HTTPS 化や認証 |
5 つの大きなメリット
- 機密情報の一元管理あちこちに散らばっていたパスワードを 1 箇所にまとめられるため、管理漏れや更新忘れを防げます。
- アクセスの厳重な制御「誰が（どのアプリが）どの情報にアクセスできるか」を細かく設定できます。Microsoft Entra ID (旧 Azure AD) と連携し、なりすましを防ぎます。
- セキュリティの向上 (HSM)Premium ティアを選択すると、HSM (ハードウェア セキュリティ モジュール) という物理デバイス内で鍵を生成・保護でき、最高レベルの安全性を確保できます。
- 監査ログの記録「いつ、誰が、どのパスワードを読み取ったか」をすべてログに残せるため、不正アクセスの検知やコンプライアンス対応が可能です。
- シークレットの自動更新（ローテーション）パスワードを定期的に自動で書き換える仕組みを作れるため、万が一漏洩しても被害を最小限に抑えられます。
どうやって使うの？（利用イメージ）
- 作成: Azure 上に Key Vault インスタンスを作成し、パスワードを保存する。
- 権限付与: アプリ（Azure App Service など）に対し、「この Key Vault の値を読み取って良い」という権限を与える（マネージド ID を使うのが推奨です）。
- 取得: アプリが実行時に Key Vault へ問い合わせに行き、パスワードを受け取って DB などに接続する。
[!TIP]
**「マネージド ID」**を併用することで、アプリ側に Key Vault へアクセスするためのパスワードすら持たせる必要がなくなります。これが現在の Azure 開発におけるベストプラクティスです。
Azure Key Vaultをチームで運用
する際、セキュリティの確保と業務効率のバランスを取ることは非常に重要です。特に複数のエンジニアやプロジェクトが関わる場合、**「最小権限の原則」と「責任の分離」**を軸にした設計が求められます。
以下に、実務で推奨されるベストプラクティスを整理しました。
1. アクセス制御モデルの選択
現在は、従来の「アクセスポリシー」ではなく、**「Azure RBAC（ロールベースのアクセス制御）」**を使用することが強く推奨されています。
- Azure RBACを推奨する理由:
- コントロールプレーン（管理操作）とデータプレーン（秘密情報の参照・更新）を一元管理できる。
- 特定の秘密情報（シークレット、キー、証明書）単位できめ細かな権限設定が可能。
- 主な役割（ロール）の使い分け:
- Key Vault 管理者: 権限設定や設定変更を行う（セキュリティ担当者など）。
- Key Vault シークレット利用者: 秘密情報を読み取る（アプリケーションの実行アカウントなど）。
- Key Vault クリプト担当者: 鍵の作成や暗号化操作を行う（開発リーダーなど）。
2. 環境の分離と命名規則
一つのKey Vaultにすべての環境（開発・検証・本番）を詰め込むのは避けましょう。
- 環境ごとの分離:
kv-project-dev、kv-project-prodのように、環境ごとに個別のインスタンスを作成します。 - 命名規則の統一: *
kv-[プロジェクト名]-[環境]-[リージョン]- タグ機能を活用し、
Owner（所有者）、CostCenter（コストセンター）、ExpirationDate（棚卸し予定日）などを付与しておくと運用管理が容易になります。
- タグ機能を活用し、
3. 秘密情報のライフサイクル管理
「作りっぱなし」を防ぐためのルール作りが必要です。
- 有効期限の設定: すべてのシークレットに有効期限（Expiration Date）を設定し、期限切れ前に通知が飛ぶように構成します（Azure Event Grid + Logic Appsなど）。
- ローテーションの自動化: 可能であれば、Azure AutomationやGitHub Actionsを使用して、パスワードやキーを定期的に自動更新する仕組みを構築します。
- 直接参照の禁止: ソースコードや設定ファイルに値を書かず、Managed Identity（マネージドID）を使用してアプリケーションがKey Vaultから直接取得するようにします。
4. 誤操作・削除への対策
チーム運用では、誤ってシークレットを削除してしまうリスクが常にあります。
- 論理削除（Soft Delete）の有効化: 削除しても一定期間（既定は90日）は復元可能な状態にします（現在はデフォルトで有効です）。
- パージ保護（Purge Protection）の有効化: 管理者であっても、保持期間が経過するまで完全に削除できないようにします。これはランサムウェア対策としても有効です。
- リソースロック: Key Vaultリソース自体に「削除不可」のロックをかけることで、インフラごと消してしまうミスを防ぎます。
5. 監査とモニタリング
「誰が」「いつ」「どの秘密情報に」アクセスしたかを記録し、異常を検知できる状態にします。
- 診断設定の構成: ログを Azure Log Analytics または Storage Account に転送します。
- アラートの設定: * 「権限設定が変更されたとき」
- 「削除操作が行われたとき」
- 「短時間に大量のシークレットが読み取られたとき（漏洩の兆候）」これらを検知して、SlackやTeamsに通知が飛ぶようにします。
運用チェックリスト（サマリー）
| 項目 | 推奨アクション |
| 権限管理 | Azure RBACを使用し、個人アカウントに過剰な権限を与えない |
| 認証 | アプリケーションには「マネージドID」を使用させる |
| 保護 | 論理削除とパージ保護を有効にする |
| 監視 | ログを収集し、重要な操作にはアラートを設定する |
| 整理 | タグを活用し、定期的な秘密情報の棚卸しを行う |
このように、技術的な設定（RBACやパージ保護）と、運用ルール（命名規則や有効期限設定）の両面からアプローチすることが、安全なチーム運用の鍵となります。
コメント