top of page
検索

Key VaultのAzure RBAC既定化から考える秘密情報管理

2026年2月1日API以降、新規Key Vaultのアクセス制御設計を見直す

秘密情報管理ルールを「保存」から「統制」へ

確認日：2026年7月8日対象読者：情シス担当者、Azure管理者、クラウド設計担当者、セキュリティ担当者、監査対応担当者対象領域：Azure Key Vault、Azure RBAC、アクセス制御、Secrets管理、ゼロトラスト、クラウドガバナンス

結論

Azure Key Vaultのアクセス制御設計は、単に「Secretを保存する場所を決める」だけでは不十分です。

今後の新規Key Vault設計では、Azure RBACを前提とした権限管理、最小権限設計、Managed Identity活用、アクセスレビュー、証跡管理を標準化する必要があります。

Microsoftは、Key Vaultのアクセス制御方式として、

  • Azure RBAC（推奨）

  • Key Vaultアクセスポリシー

の2方式を提供しています。

2026年2月1日以降のAPIバージョンでは、新規Key Vault作成時の既定のアクセス制御方式がAzure RBACになる変更が予定されています。

そのため、既存環境と新規環境でアクセス制御方式が混在しないよう、企業として秘密情報管理ルールを見直す必要があります。

理由

Key Vaultの事故原因は、「暗号化されていない秘密情報」だけではありません。

実際の運用事故では、以下のような問題が発生します。

問題

リスク

Secretへの過剰アクセス

内部不正・情報漏えい

管理者が直接Secret値を見る

職務分離違反

アクセスポリシー乱立

権限棚卸し困難

RBAC設計不足

意図しないアクセス許可

アプリにパスワード埋込

Git流出リスク

所有者不明Secret

更新漏れ

期限管理不足

サービス停止

つまり重要なのは、

「Key Vaultに入れているか」

ではなく、

「誰が、何の目的で、どの権限で利用できるか説明できるか」

です。

数字で見る：秘密情報管理で標準化すべき9項目

No

管理項目

内容

1

Key Vault一覧

環境・用途管理

2

アクセス方式

RBAC / アクセスポリシー

3

権限一覧

誰が何をできるか

4

Secret一覧

用途・所有者

5

Managed Identity

利用アプリ

6

有効期限

Expiration管理

7

ローテーション

更新周期

8

監査ログ

利用履歴

9

例外管理

特別権限・期限

1. Key Vaultのアクセス制御方式

Azure Key Vaultでは、アクセス制御方式として2つのモデルがあります。

表1：アクセス制御方式比較

項目

Azure RBAC

Key Vaultアクセスポリシー

管理基盤

Azure Resource Manager RBAC

Key Vault独自設定

権限管理

Entra IDロール

Vault単位設定

標準化

◎

△

権限レビュー

◎

△

大規模環境

◎

△

推奨度

推奨

既存互換用途

Microsoft公式では、Azure RBACはKey Vaultのリソース、サブスクリプション、管理グループなどAzure全体で一貫したアクセス制御モデルを提供し、最小権限アクセス管理に利用できる方式として説明されています。

出典：Microsoft LearnAzure Key Vault のアクセス制御https://learn.microsoft.com/ja-jp/azure/key-vault/general/rbac-guide

2. なぜAzure RBACが重要なのか

従来のアクセスポリシー方式では、Key Vault単位で、

「このユーザーはSecret取得可能」

という設定を直接持っていました。

しかし、大規模環境では問題が発生します。

図1：アクセスポリシー方式の課題

Key Vault A
 ├─ 山田さん Get Secret
 ├─ 鈴木さん Get Key
 └─ 開発チーム Certificate管理


Key Vault B
 ├─ 山田さん Get Secret
 ├─ 佐藤さん Get Secret
 └─ 開発チーム Get Key


Key Vault C
 └─ ...

結果：

  • 誰がどこに権限を持つか分からない

  • 異動時の削除漏れ

  • 棚卸し困難

Azure RBAC方式

Entra ID

     │

     ▼

Azure RBAC Role

     │

     ▼

Subscription
    │
    ├─ Resource Group
    │
    └─ Key Vault

Azure標準のRBAC階層で管理できます。

3. 2026年2月1日API以降で注意すべき点

Microsoft公式ドキュメントでは、Key Vault作成APIのバージョン変更に伴い、既定のアクセス制御方式に関する動作変更が案内されています。

2026年2月1日以降のAPIバージョンでは、新規Key Vault作成時の既定動作がAzure RBACになります。

この変更で重要なのは、

既存Key Vaultが自動的にRBACへ変更されるわけではない

という点です。

つまり企業環境では、

既存環境
↓
アクセスポリシー方式

新規環境
↓
Azure RBAC方式

という混在状態になる可能性があります。

4. 混在環境が危険な理由

図2：アクセス制御方式混在リスク

                 企業Azure環境

        ┌────────────────┐
        │ Key Vault A     │
        │ RBAC            │
        └────────────────┘


        ┌────────────────┐
        │ Key Vault B     │
        │ Access Policy   │
        └────────────────┘


        ┌────────────────┐
        │ Key Vault C     │
        │ RBAC            │
        └────────────────┘

運用者：

「このKey VaultはRBAC？」

「こっちはアクセスポリシー？」

「誰がSecretを見る権限を持つ？」

という確認が必要になります。

5. 推奨する企業標準設計

表2：推奨標準

項目

推奨

新規Key Vault

Azure RBAC

権限付与

グループ単位

個人直接付与

原則禁止

アプリ利用

Managed Identity

管理者操作

PIM利用

Secret取得

Get権限のみ

管理操作

分離

監査

Diagnostic Logs取得

6. Managed Identityを基本にする

悪い設計：

アプリ
 |
 | password=xxxx
 |
DB

問題：

  • ソース流出

  • 設定ファイル漏えい

  • 更新作業増加

推奨：

Container Apps
App Service
AKS

       │

Managed Identity

       │

       ▼

Azure Key Vault

アプリケーション自身にIDを持たせ、Key Vaultから必要な秘密情報だけ取得します。

7. RBACロール設計

Key Vaultでは、役割を分離します。

表3：推奨RBAC設計

利用者

ロール例

目的

アプリManaged Identity

Key Vault Secrets User

Secret取得

運用担当

Key Vault Secrets Officer

更新作業

管理者

Key Vault Administrator

管理

監査担当

Reader

確認

開発者

原則なし

不要アクセス防止

8. 最小権限設計

避けるべき設計：

全員

Key Vault Administrator

これは管理しやすいですが、リスクが高いです。

推奨：

開発者
 ↓
Secret閲覧不可

アプリ
 ↓
必要Secretのみ取得

運用者
 ↓
期限付き管理権限

9. Secret管理ルール

表4：Secret管理台帳

項目

内容

Secret名

DB-CONNECTION

利用システム

顧客管理API

所有者

システム責任者

利用者

Managed Identity

作成日

YYYY/MM/DD

有効期限

YYYY/MM/DD

更新周期

90日

ローテーション方法

自動/手動

廃止予定

YYYY/MM/DD

10. ローテーション設計

秘密情報は永久利用してはいけません。

図3：ローテーションサイクル

Secret作成

 ↓

利用開始

 ↓

期限監視

 ↓

新Secret発行

 ↓

アプリ切替

 ↓

旧Secret無効化

 ↓

削除

表5：推奨周期例

種類

管理例

APIキー

定期更新

DBパスワード

定期変更

証明書

有効期限前更新

OAuth Secret

期限管理

暗号鍵

Key Rotation

※実際の周期はサービス要件、規制、運用負荷により決定します。

11. Soft Delete・Purge Protectionとの組み合わせ

RBACだけでは不十分です。

削除事故対策も必要です。

図4：Key Vault防御モデル

              Key Vault

       ┌────────────────┐
       │ RBAC           │
       │ 権限制御       │
       └────────────────┘

              +

       ┌────────────────┐
       │ Soft Delete    │
       │ 復元保護       │
       └────────────────┘

              +

       ┌────────────────┐
       │ Purge Protect  │
       │ 完全削除防止   │
       └────────────────┘

12. 監査ログ設計

Key Vaultでは、

  • 誰がSecretを取得したか

  • 誰が削除したか

  • 誰が権限変更したか

を追跡できる必要があります。

表6：取得すべきログ

ログ

内容

Azure Activity Log

管理操作

Key Vault Audit Logs

Secretアクセス

Entra ID Audit Logs

権限変更

Defender for Cloud

リスク検知

13. Azure Policyによる標準化

大規模環境では、人による確認だけでは漏れます。

Azure Policyで標準化します。

Policy例

Policy

目的

RBAC利用必須

権限統一

Public Access禁止

外部露出防止

Soft Delete有効

削除対策

Purge Protection有効

完全削除防止

Diagnostic設定必須

監査対応

14. 秘密情報管理規程に必要な項目

表7：規程項目

項目

内容

目的

秘密情報保護

対象

Key、Secret、Certificate

保存場所

Key Vault

権限管理

Azure RBAC

利用者管理

Entra ID

取得方法

Managed Identity

更新

ローテーション

削除

Soft Delete/Purge

監査

ログ確認

例外

承認制

15. 監査で聞かれる質問

表8：監査質問

質問

必要資料

誰がSecretを取得できますか

RBAC一覧

なぜその権限がありますか

権限申請

削除事故対策はありますか

Soft Delete設定

完全削除できますか

Purge Protection設定

期限管理していますか

Secret台帳

漏えい時対応できますか

ローテーション手順

利用履歴がありますか

Audit Log

16. 経営層へ説明するポイント

Key Vault管理は技術問題ではなく、企業リスク管理です。

図5：経営説明モデル

秘密情報

 ↓

認証情報保護

 ↓

不正利用防止

 ↓

サービス停止防止

 ↓

情報漏えいリスク低減

 ↓

事業継続

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

Key VaultのRBAC化は、単なるAzure設定変更ではありません。

必要なのは、

  • 技術設計

  • 権限管理

  • 社内ルール

  • 監査証跡

  • 責任分界

  • 経営説明

を統合することです。

支援内容

領域

内容

Azure設計

Key Vault RBAC設計

権限管理

Entra ID/RBAC/PIM整理

秘密管理

Secret台帳整備

ローテーション

更新ルール設計

セキュリティ

Managed Identity設計

監査対応

証跡・説明資料

規程整備

秘密情報管理規程

ガバナンス

例外管理・承認フロー

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

まとめ

Azure Key Vaultの本質は、

「秘密情報を置く場所」

ではありません。

本当に必要なのは、

秘密情報を適切な人・サービスだけが利用し、削除事故・漏えい・期限切れを防ぎ、監査で説明できる状態を作ること

です。

2026年2月1日以降の新規Key Vault設計では、Azure RBACを前提とした標準化が重要になります。

企業として整備すべき項目は、

✅ Azure RBAC標準化✅ Managed Identity利用✅ 最小権限設計✅ Soft Delete✅ Purge Protection✅ Secretローテーション✅ 証跡管理✅ 例外管理✅ 秘密情報管理規程

です。

Key Vaultは、クラウドセキュリティの入口です。

秘密情報管理を「保存」から「統制」へ。

Azure Key Vault RBAC設計、秘密情報管理規程、監査対応資料、クラウドガバナンス整備は、山崎行政書士事務所へご相談ください。

出典

確認日：2026年7月8日

 
 
 

コメント

Instagram​​

​LINE公式

x

note

You Tube

info@shizuoka-yamazaki-jimusho.com

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地：静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page