Key Vaultを「入れた」だけで安心していませんか？

期限切れ・過剰権限・委託先/CI-CDで“秘密情報の事故”が起きる組織の共通点（情シス向け）

※本記事は一般的な情報提供を目的としており、個別案件の法的助言・紛争対応を行うものではありません。個別事情に踏み込む判断が必要な場合は、内容に応じて弁護士等の専門家と連携して検討してください。

情シスが本当に怖いのは「侵害」より「期限切れ＋説明不能」

Azure Key Vaultを導入している企業でも、事故の引き金はだいたい次の3つです。

• 期限切れ（証明書/シークレットが切れて“業務停止”）

• 過剰権限（開発・委託先・CIが“読める/書ける/消せる”）

• 属人化（誰が更新するか、誰が承認するか、誰が監査に出すかが曖昧）

山崎行政書士事務所の「Key Vault運用設計」ページでも、Key Vaultは「入れているか」ではなく、期限切れ・過剰権限・属人運用で事故を起こさないために、運用と説明責任（証跡）まで含めて設計できているかが重要、と整理しています。さらに、Secrets/Keys/Certificatesをアクセス統制・ローテーション・監査ログ・例外運用・委託先統制まで一体で整理する方針が明記されています。

まず“技術の事実”を揃える：Key Vaultは論点が多層

Key Vault運用で揉めるのは、**データプレーン（秘密情報そのもの）**と、**統制（権限/ネットワーク/監査）**が分離しているからです。情シス目線で最低限そろえるべき「技術の柱」はこの5つ。

1. アクセス制御モデル（RBACか、Access Policyか）

2. 特権の扱い（常設か、JIT/承認/期限か）

3. ローテーション（通知/自動化/失敗時のロールバック）

4. 監査ログ（誰がいつ何を参照・変更したかの証跡）

5. ネットワーク境界（Publicか、Private Linkか、境界ログは残るか）

1) アクセス制御は「RBAC前提」が今の標準（職務分離がやりやすい）

Azure Key Vaultは Azure RBAC と Access Policy の2モデルがありますが、Microsoftは Azure RBACが“既定かつ推奨”であること、そして移行手順も公式に用意しています。

RBACを前提にすると、情シスが監査で説明しやすくなる理由は3つです。

• アクセス管理がAzure全体で一元化され、誰に何を付与したか追いやすい

• 権限付与（Grant）の権限がより制御され、Owner / User Access Administratorの関与が前提になる（＝職務分離の線を引きやすい）

• PIM（特権の期限付き付与）と統合しやすい（“常設強権限”を減らせる）

「Key Vault管理者を増やして回す」ではなく、“必要な人が必要なときだけ強くなる”（JIT＋承認＋期限）へ寄せると、事故も監査も強くなります。（この“常時付与ではなく必要時昇格で統制”という発想自体も、事務所ページで明確に打ち出されています）

2) 期限切れ事故を潰す：Event Gridで「30日前に確実に燃やす」

「更新担当者のカレンダー頼み」が一番危険です。Key Vaultは Event Grid連携で、シークレット/キー/証明書の状態変化をイベントとして通知できます。

Microsoft公式の定義では、たとえばSecretは以下がイベント化されます。

• 期限が近い（SecretNearExpiry）：有効期限の 30日前 に発火

• 期限切れ（SecretExpired）

• 新バージョン作成（SecretNewVersionCreated） 

このイベントを「メール通知」で終わらせず、情シスの現場ではこう繋ぐのが実務的です。

• Key Vault → Event Grid →（Function/Logic Apps/Automation）→ チケット発行（担当者/期限/影響範囲/ロールバック手順の紐づけ）

• 期限切れリスクが高いものは、自動ローテーションまで視野に入れる

実際、Microsoft Learnのチュートリアルでも、Event Gridトリガーを起点にAzure Functions等でシークレットの定期ローテーションを組む流れが示されています（例：SQLパスワード、ストレージアカウントキーなど）。

3) “削除”が事故になる：Soft deleteとPurge protectionは「仕様として扱う」

Key Vaultの運用で見落とされがちなのが「削除の挙動」です。Microsoft Learnでは、Soft deleteにより削除されたKey Vaultやオブジェクト（キー/シークレット/証明書）を復旧できること、さらに Purge protectionはSoft delete有効化が前提で、暗号化キー用途では推奨され、統合する多くのAzureサービスがデータ損失防止のためにPurge protectionを要求する、と説明されています。

つまり情シスの実務では、

• 「消せない（消せない期間がある）」ことを運用と契約の前提として扱う

• 環境廃止・更改時に「いつ消せるか」「誰が消すか」を事前に決める

ここが曖昧だと、更新・更改プロジェクトの終盤で詰みます。

4) 監査ログは“後からON”が最悪：Diagnostic settingsで証跡を残す

Key Vaultは**診断設定（Diagnostic settings）**でログとメトリックを外に出せます。 Microsoft Learnの「Key Vault logging」では、ポータルの診断設定で Category groupsとして audit と allLogs を選ぶ手順が明記されています。

ここで情シスが設計すべきポイントは「設定手順」よりも、次です。

• 誰がログを“閲覧”できるか（日常運用）

• 誰がログを“抽出・提出”できるか（監査/取引先/インシデント）

• ログ保全（凍結・提出）の承認ルートは誰か

この「閲覧・抽出・提出の分離」も、事務所のKey Vault運用設計で強調されている観点です。

5) ネットワークは“Public可”が一番揉める：Private Link前提へ

Key Vaultはネットワーク面でも設計論点が増えています。Microsoft Learnの「Secure your Azure Key Vault」では、ベストプラクティスの1つとして Public network accessを無効化し、Private Endpointのみでアクセスさせる（Azure Private Link）ことが明記されています。

さらに最近のドキュメントでは、Key Vaultのネットワークセキュリティとして firewall / Private Link / Network Security Perimeter といった選択肢が整理されており、境界の取り方（Transition/Enforcedなど）にも言及されています。

監査・取引先審査で刺さるのは、**「どこからKey Vaultに到達できるのか」**を図と設定根拠で説明できるかです。

6) 委託先・CI/CDで破綻するポイント： “秘密を渡さない”設計へ

委託開発やCI/CDが絡むと、Key Vaultは「便利な秘密金庫」から「責任分界の火種」になります。事務所ページでも、委託先・CI/CDが関与する場合の境界（作業・権限・証跡提出）を契約と運用で整合させる重要性が明記されています。

技術側の要点はシンプルで、Microsoftが繰り返し示す方向性は、

• Microsoft Entra IDで認証し

• Managed IdentityでKey Vaultにアクセスして、アプリ側に資格情報を持たせない

「委託先にシークレットを配る」のではなく、委託先の作業はCI/CDや実行環境のIDで制御し、証跡を残す方向に寄せると事故が減ります。

“クラウド法務”として、情シスに刺さるのは「成果物化」

構築代行・設定代行ではなく、情シスが監査・取引先・委託先調整で詰まらないための**文書化（成果物）**に落とすのが、行政書士としての支援領域です（個別紛争や訴訟対応は弁護士連携の範囲）。

山崎行政書士事務所のKey Vault運用設計が「手順書ではなく、統制方針と“出せる形”の成果物」を重視しているのも、まさにここです。

情シス向けに刺さる成果物の例：

• 秘密情報台帳（Secrets/Keys/Certs）：所有者、用途、利用サービス、ローテーション周期、例外の有無

• 権限マトリクス（RBAC/職務分離）：運用・開発・監査・委託先・CI/CDの境界

• ローテーション運用骨子：通知→作業→検証→切替→ロールバック、緊急更新の事後レビュー

• 監査・取引先向け1枚説明資料：どこに証跡があり、誰が出すか

• 委託仕様（SOW等）の整理：委託先の作業範囲・権限・証跡提出（形式/頻度）の“主語”を固定

※「クラウド時代の責任分界」の記事でも、ID/権限/ログなどは“責任のなすりつけ合い”が起きやすく、発注側が本当に知りたいのは「誰が主導し、どこまでやるか」だと整理されています。

最後に：情シス向けセルフチェック（Yesが揃わないと監査で詰む）

• □ Key Vaultのアクセス制御はRBAC前提で、付与権限（Grant）も職務分離できている

• □ 期限切れをEvent Grid等で“仕組みとして”検知できる（30日前通知を含む）

• □ ローテーションは「担当者の気合」ではなく、手順と証跡が残る運用になっている

• □ Soft delete / Purge protection の仕様を前提に、削除・更改の運用計画がある

• □ 診断設定でaudit/allLogs等を収集し、監査提出に耐える形で保管・抽出できる

• □ Publicアクセスを許す/許さないの判断と根拠が説明でき、Private Link前提で整理されている

• □ 委託先・CI/CDの境界（権限・証跡提出）が契約と運用で整合している