【Azure】Key Vault（キーコンテナー）作成からキー生成までの手順まとめ（RBAC対応）

はじめに

Azureで機密情報（パスワード、接続文字列、証明書など）を管理する Azure Key Vault。
今回は、Key Vaultリソースを作成し、その中に暗号化や署名に使用する 「キー (Key)」 を作成するまでの手順をまとめました。

本記事では、アクセス許可モデルとして現在Azureで推奨されている Azure RBAC (ロールベースのアクセス制御) を使用して構築を行います。

アクセス許可モデルについて

Key Vaultには大きく分けて2つのアクセス制御方式があります。

• Azure RBAC (推奨): Azureの他のリソースと同様に、IAMロールを使って「誰が何をできるか」を一元管理する方式です。
• コンテナーのアクセス ポリシー: Key Vault独自のポリシー設定で権限を管理する方式です。

今回は、管理の一貫性とセキュリティの観点から推奨されている Azure RBAC を選択します。

参考 (公式ドキュメント):
Azure Key Vault の基本的な概念

前提条件

• 有効なAzureサブスクリプションを持っていること

---

1. Key Vault (キーコンテナー) の作成

まず、環境構築の最初のステップとしてKey Vaultリソースを作成します。

1. Azure Portalの上部検索バーに「Key Vault」と入力し、サービスから [キー コンテナー] を選択します。

2. [作成] をクリックします。

3.[基本] タブの設定

• サブスクリプション: KeyVaultを作成するサブスクリプションを選択
• リソースグループ: 新規作成（例: rg-keyvault-demo）または既存を選択
• キーコンテナー名: Azure全体で一意の名前を入力（例: kv-test-demo-01）
  ※この名前はAzure全体で一意である必要があります。（グローバル一意）
• 地域: Japan East (東日本) など
• 価格層: 標準(Standard) または プレミアム(Premium)
  

💡 補足1：価格層で 標準(Standard) と プレミアム(Premium) の違い
Key Vault作成時に迷いやすいのが Standard と Premium の違いです。
最大の違いは、キーを保護するバックエンドが「ソフトウェア」か「物理ハードウェア (HSM)」かという点です。

特徴	標準(Standard)	プレミアム(Premium)
キーの保護方法	ソフトウェア保護 (Azure基盤側では暗号化されていますが、論理的にはソフトウェアキー扱いです)	HSM保護 (専用の物理的なハードウェアセキュリティモジュール内で保護されます)
コンプライアンス	FIPS 140-2 Level 1 相当	FIPS 140-2 Level 2 準拠
用途	一般的なWebアプリ、開発環境、コスト重視のプロジェクト	金融系システム、高度なセキュリティ要件、規制によりHSM利用が義務付けられている場合

参考 (公式ドキュメント):
Key Vault のサービス レベルについて

💡 補足2：回復オプションの設定（論理的な削除・消去保護）
基本タブの下部には、誤削除を防ぐための重要な設定があります。

• 論理的な削除 (Soft Delete)
  • 常に有効 です（無効化できません）。
  • キーコンテナーを削除しても、PCの「ゴミ箱」に入ったような状態となり、
    指定した保持期間内であれば、当該キーコンテナーを復元可能です。
• 削除されたコンテナーを保持する日数
  • デフォルトは 90日 です（7〜90日で設定可能）。
• 消去保護 (Purge Protection)
  • 消去保護を無効にする (推奨・開発時): 保持期間中であっても、ユーザーが明示的に「完全削除（パージ）」を実行できます。
    • ※開発中に「同じ名前ですぐ作り直したい」場合はこちらを選びます。
  • 消去保護を有効にする: 保持期間が経過するまで、誰も（Microsoftであっても）強制削除ができなくなります。
    • ※本番環境では誤操作防止のため有効化が推奨されます。

参考 (公式ドキュメント):
Azure Key Vault の論理的な削除の概要

4. [アクセス構成] タブの設定

ここがポイントです。

• アクセス許可モデル: [Azure ロールベースのアクセス制御 (推奨)] を選択します。

Note: 以前は「コンテナーのアクセス ポリシー」が主流でしたが、現在は権限管理を一元化できるRBACが推奨されています。

• リソース アクセス
  特定のAzureサービスからKey Vaultへのアクセスを許可するかどうかの設定です。今回はすべてオフ（デフォルト）のままで問題ありませんが、用途に応じてチェックを入れます。

項目	説明
Azure Virtual Machines (展開用)	VMが証明書としてKey Vault内のシークレットを取得することを許可します。
Azure Resource Manager (テンプレートの展開用)	ARMテンプレートのデプロイ時に、Key Vault内の値を参照することを許可します。
Azure Disk Encryption (ボリューム暗号化用)	VMのディスク暗号化（ADE）でこのKey Vaultを使用する場合に必要です。

参考 (公式ドキュメント):
Azure RBAC を使用して Key Vault へのアクセス権を付与する

5.確認と作成

他のタブ（ネットワーク、タグは必要に応じて設定可能）はデフォルトのままで [確認と作成] タブへ進みます。
検証に成功したことを確認し、[作成] をクリックします。

---

2. アクセス権（ロール）の割り当て（★重要）

Azure Key Vaultの権限管理は、以下の2つの階層（レイヤー）に分かれているのが特徴です。

1. 管理層（リソースの管理）
   • Key Vaultそのものの作成や削除、アクセス権の設定などを行う権限。
   • ロール例：所有者、貢献者
2. データ層（中身の操作）
   • 保管されているキー・シークレット・証明書の読み書きを行う権限。
   • ロール例：キー コンテナー管理者、キー コンテナー暗号化責任者

下図のように、Key Vaultの作成者には、デフォルトで所有者権限が付与されています。

しかし、実はこのままでは作成者本人でも「キー」の作成や閲覧ができません。
（所有者権限は「リソース自体の管理」はできますが、「中のデータ（キーやシークレット）の操作」権限を持たないためです）

※「キー」の中身を閲覧・操作できない状態↓

どのような権限が必要なのか？

キーを作成するには、前述したデータ層に対する操作として Microsoft.KeyVault/vaults/keys/create/action の権限が必要です。
この権限を含む、以下のいずれかの組み込みロールを自分に割り当てる必要があります。

• キー コンテナー暗号化責任者 (Key Vault Crypto Officer)
  • キーの作成・管理が可能。
• キー コンテナー管理者 (Key Vault Administrator)
  • キーだけでなく、シークレットや証明書も含めたすべての管理が可能。

今回はキー操作に特化した「キー コンテナー暗号化責任者」を使用します。

設定手順

1.「ロールの割り当ての追加」タブをクリックします。

1. 作成したKey Vaultのリソースへ移動します。
2. 左メニューの [アクセス制御 (IAM)] を選択します。
3. [追加] → [ロールの割り当ての追加] をクリックします。

2.ロールの選択

• ロール: キー コンテナー暗号化責任者 を検索して選択し、「次へ」をクリックします。

参考 (公式ドキュメント):
Azure 組み込みロール - Key Vault Crypto Officer

キーの管理を実行します。 シークレットの管理は許可しません。

3.メンバーの選択

ここが少し分かりにくい箇所です。

1. [メンバーを選択] のリンクをクリックします。
2. 右側に出てくる画面で、自分の名前（または対象のユーザー）を検索して選択します。
3. 下部の [選択] ボタンを押します。

メンバー欄に自分のアカウントが表示されていることを確認し、[レビューと割り当て] をクリックして完了させます。

※権限が反映されるまで1〜2分かかる場合があります。

---

3. キー (Key) の作成

権限が付与されたので、実際にキーを作成します。

1. 左メニューの「オブジェクト」セクションにある [キー] を選択します。
2. [生成/インポート] をクリックします。
   ※もしここで「権限がありません」と出る場合は、前の手順のロール割り当てが反映されるまで少し待ってからリロードしてください。

キーの作成設定

• オプション: 生成
• 名前: 任意のキー名（例: app-test-key-01）
• キーの種類: RSA (用途に応じてECも選択可)
  • Premiumの場合: ここで RSA-HSM や EC-HSM を選択できます。ハードウェア保護を利用する場合は必ず HSM 付きを選択してください。
• RSA キー サイズ: 2048 (より強度が必要な場合は3072や4096を選択)
• 有効: はいを選択

  その他の設定は今回デフォルトのままで設定します
  必要に応じて設定可能

参考 (公式ドキュメント):
キーについて - Azure Key Vault

Key Vault では RSA キーと EC キーがサポートされています。
参考：RSAとECの違い

[作成] をクリックします。

---

4. 確認

一覧に作成したキーが表示されていれば成功です。

作成されたキー (今回は「app-test-key-01」) をクリックし、さらに「現在のバージョン」をクリックすると、キー識別子（Key Identifier）や公開鍵のダウンロードなどが確認できます。
アプリケーションからこのキーを参照して暗号化/復号化を行う場合は、この識別子（URL）を使用することになります。

---

まとめ

以上、RBACモデルを利用したAzure Key Vaultとキーの作成手順でした。

ポイントは、「リソースを作成した人（管理層の権限を持つ人）であっても、自動的に中身を触る権限（データ層の権限）を持っているわけではない」 という点です。

そのため、作成手順の途中で 「自分自身に対して、明示的にデータ操作用のロールを付与する」 という作業が必要でした。
ここで躓くことが多いので、忘れずに設定しておきましょう。

今後の展望：キーのローテーションについて

実運用では、セキュリティ要件として「定期的なキーの交換（ローテーション）」が求められることがよくあります。
現在「自動ローテーション」の設定や構成を検証中ですので、知見が溜まり次第、また次回の記事で共有できればと思います。

We Are Hiring!