Key VaultのSoft Delete・Purge Protection・ローテーションを標準化する

山崎行政書士事務所
7月8日
読了時間: 7分

秘密情報の削除・漏えい・期限切れを防ぐ鍵・証明書・シークレット運用規程

確認日：2026年7月8日対象読者：情シス担当者、Azure運用担当者、セキュリティ担当者、監査対応担当者、経営層対象領域：Azure Key Vault、Secrets管理、証明書管理、暗号鍵管理、ゼロトラスト、クラウドガバナンス

結論

Azure Key Vaultは、単にパスワードや証明書を保存する「安全な箱」ではありません。

本番環境では、以下を標準化しなければ、重大事故につながる可能性があります。

Soft Deleteによる誤削除対策
Purge Protectionによる完全削除防止
シークレット・証明書・鍵のローテーション管理
RBACによるアクセス制御
有効期限管理
利用状況監査
例外管理

重要なのは、

「秘密情報を保存している」

ではなく、

「秘密情報を誰が、いつ、どの目的で利用し、期限切れや漏えい時にどう対応するか説明できる」

状態を作ることです。

理由

クラウド環境では、秘密情報がシステム停止や情報漏えいの直接原因になります。

例えば、以下のような事故があります。

事故例	発生する影響
Key Vault Secretを誤削除	アプリケーション停止
証明書期限切れ	HTTPS通信停止
接続文字列漏えい	データアクセス被害
古い秘密情報を放置	攻撃経路になる
管理者が直接秘密値を閲覧	内部統制違反
ローテーション未実施	長期間リスク継続

特に危険なのは、

「秘密情報はKey Vaultに入れているから安全」

という考え方です。

Key Vaultを導入していても、

誰がアクセスできるか
期限管理されているか
古い秘密情報は削除されているか
削除事故から復旧できるか
利用履歴を確認できるか

が整理されていなければ、十分な統制とは言えません。

数字で見る：Key Vault運用で管理すべき10項目

No	管理項目	内容
1	Secret一覧	接続文字列、APIキー等
2	Key一覧	暗号鍵、署名鍵
3	Certificate一覧	TLS証明書等
4	所有者	システム責任者
5	利用サービス	App Service、AKS等
6	有効期限	Expiration Date
7	ローテーション周期	更新頻度
8	権限管理	RBAC・PIM
9	削除保護	Soft Delete/Purge Protection
10	監査ログ	利用履歴

1. Azure Key Vaultとは

Azure Key Vaultは、秘密情報、暗号鍵、証明書を安全に保存・管理するためのAzureサービスです。

管理対象は大きく3種類あります。

図1：Key Vault管理対象

                 Azure Key Vault

        ┌─────────────────────┐
        │                     │
        │  Secrets            │
        │  ─────────────      │
        │  パスワード         │
        │  接続文字列         │
        │  APIキー            │
        │                     │
        ├─────────────────────┤
        │                     │
        │  Keys               │
        │  ─────────────      │
        │  暗号化鍵           │
        │  署名鍵             │
        │                     │
        ├─────────────────────┤
        │                     │
        │  Certificates       │
        │  ─────────────      │
        │  TLS証明書          │
        │  サーバー証明書     │
        │                     │
        └─────────────────────┘

2. Soft Deleteとは何か

Soft Deleteは、Key Vaultのオブジェクトを削除しても、一定期間復元可能にする機能です。

つまり、

通常削除

↓

完全消去

ではなく、

削除

↓

論理削除状態

↓

保持期間終了後に完全削除

という流れになります。

図2：Soft Deleteの動作

通常削除

Secret
  │
  ▼
削除実行
  │
  ▼
┌─────────────┐
│ Deleted     │
│ 復元可能     │
└─────────────┘
  │
  ▼
保持期間終了
  │
  ▼
完全削除

実務メリット

リスク	Soft Deleteによる対策
操作ミスでSecret削除	復元可能
証明書削除	復元可能
アプリ停止	復旧時間短縮
誤操作	安全網になる

3. Purge Protectionとは何か

Soft Deleteだけでは不十分な場合があります。

なぜなら、権限を持つ管理者は削除済みオブジェクトを完全削除（Purge）できる可能性があるためです。

そこで利用するのがPurge Protectionです。

図3：Soft DeleteとPurge Protectionの違い

Soft Deleteのみ

管理者
 │
 ▼
Secret削除
 │
 ▼
Deleted状態
 │
 ▼
Purge実行
 │
 ▼
完全削除


────────────────


Soft Delete
+
Purge Protection

管理者
 │
 ▼
Secret削除
 │
 ▼
Deleted状態
 │
 ▼
Purge禁止
 │
 ▼
保持期間終了まで保護

Microsoft公式では、Purge ProtectionはKey VaultまたはManaged HSMの削除されたオブジェクトを保持期間中に完全削除できないようにする機能として説明されています。

出典：Microsoft LearnAzure Key Vault の回復可能な削除と消去保護https://learn.microsoft.com/ja-jp/azure/key-vault/general/soft-delete-overview

4. 本番環境ではPurge Protectionを必須化する

表1：環境別推奨設定

環境	Soft Delete	Purge Protection
開発	推奨	要件次第
検証	必須推奨	推奨
本番	必須	必須

理由は、本番環境では、

暗号鍵
DB接続情報
API認証情報
TLS証明書

が削除されると、復旧が困難になるためです。

5. Secretローテーション管理

秘密情報は、一度設定したら終わりではありません。

長期間同じSecretを利用すると、漏えい時の影響範囲が拡大します。

図4：Secretライフサイクル

作成
 │
 ▼
利用開始
 │
 ▼
監視
 │
 ▼
期限確認
 │
 ▼
ローテーション
 │
 ▼
旧Secret無効化
 │
 ▼
削除

推奨ローテーション対象

対象	推奨管理
DBパスワード	定期変更
APIキー	定期更新
OAuth Secret	有効期限管理
証明書	期限前更新
暗号鍵	ローテーション

6. 証明書期限切れ事故を防ぐ

証明書事故は、非常に多いクラウド障害原因です。

例：

証明書期限
2026/08/01

管理者
「まだ先だから大丈夫」

↓

2026/08/02

HTTPS通信停止

↓

サービス停止

表2：証明書管理台帳

項目	内容
証明書名	api-prod-cert
利用サービス	Application Gateway
発行者	CA
有効期限	YYYY/MM/DD
更新方法	自動/手動
担当者	情シス
通知期限	30日前
更新結果	成功/失敗

7. Managed IdentityでSecret利用を減らす

現在のAzure設計では、アプリケーションへ固定パスワードを埋め込む方式は避ける方向が推奨されています。

悪い例

アプリ
 │
 ├─ config.json
 │
 └─ password=xxxxxx

問題：

ソース漏えい
Git流出
配布ミス

推奨例

App Service
Container Apps
AKS

     │

Managed Identity

     │

     ▼

Azure Key Vault

     │

Secret取得

8. RBAC設計

Key Vaultでは「誰でもSecretを見る」状態を避ける必要があります。

図5：権限分離

              Entra ID

                 │

     ┌───────────┴───────────┐

     ▼                       ▼

アプリID                管理者

Secret取得             管理操作

     │                       │

     ▼                       ▼

        Azure Key Vault

表3：推奨権限

利用者	権限
アプリManaged Identity	Secret Get
開発者	原則不可
運用担当	必要最小限
Key Vault管理者	管理操作
監査担当	Read Only

9. Key Vault運用規程

技術設定だけでは監査対応できません。

必要なのは運用規程です。

表4：Key Vault運用規程項目

項目	内容
目的	秘密情報保護
対象	Secret、Key、Certificate
登録ルール	命名規則
権限管理	RBAC/PIM
削除	Soft Delete/Purge Protection
更新	ローテーション周期
監査	利用ログ確認
例外	承認フロー
廃止	削除手順

10. 証跡管理

Key Vaultでは、操作履歴を残す必要があります。

保存対象

ログ	内容
Azure Activity Log	管理操作
Key Vault診断ログ	Secretアクセス
Entra IDログ	認証
Defender通知	リスク検知

図6：監査証跡

ユーザー
  │
  ▼
Entra ID認証

  │

  ▼

Key Vaultアクセス

  │

  ▼

Diagnostic Logs

  │

  ▼

Log Analytics
/
Storage
/
Sentinel

11. Azure Policyで標準化する

個別設定では漏れます。

Azure Policyで以下を強制します。

表5：Policy例

Policy	目的
Soft Delete有効	削除事故防止
Purge Protection有効	完全削除防止
Public Network Access制限	外部公開防止
Diagnostic Settings必須	ログ取得
RBAC利用	権限制御

12. 事故パターンと対策

表6：Key Vault事故分析

事故	原因	対策
Secret削除	操作ミス	Soft Delete
完全削除	Purge実行	Purge Protection
証明書期限切れ	台帳なし	期限監視
APIキー漏えい	固定値管理	Managed Identity
過剰権限	RBAC不足	最小権限
利用者不明	ログ不足	Diagnostic設定

13. 経営層への説明ポイント

図7：秘密情報管理の考え方

秘密情報

 ↓

漏えい防止

 ↓

削除事故防止

 ↓

期限切れ防止

 ↓

利用履歴管理

 ↓

監査・説明責任

経営層に説明すべき内容は、

「Key Vaultを導入しています」

ではありません。

説明すべきなのは、

秘密情報はどこにあるか
誰が利用できるか
期限切れをどう防ぐか
削除事故から復旧できるか
漏えい時に追跡できるか

です。

14. 山崎行政書士事務所としての支援領域

Key Vault管理は、Azure設定だけでは完成しません。

必要なのは、

技術設定
権限設計
運用規程
監査証跡
例外管理
経営説明

を一体化することです。

支援内容

領域	支援内容
Azure設計	Key Vault構成レビュー
セキュリティ	RBAC、PIM、Managed Identity設計
秘密管理	Secret・Key・Certificate管理
ローテーション	更新ルール設計
監査対応	ログ・証跡整理
規程整備	秘密情報管理規程
経営説明	リスク説明資料
委託管理	責任分界整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

まとめ

Key Vaultで重要なのは、

「秘密情報を保存すること」