-
Notifications
You must be signed in to change notification settings - Fork 0
MS_AzureKeyVault
- 戻る(Azure)
- Azure Key Vault
- Azure Managed Identity
- Azure Service Principal
OneDrive でも使えるアレ。
移行メモ(正式名称): Azure Key Vault。
「シークレット・キー・証明書」を安全に保管し、
アクセスを制御・監査するためのマネージド サービスである。
保管対象 用途 シークレット 接続文字列、API キー、パスワード キー(暗号鍵) 暗号化・署名。鍵は取り出さず、Key Vault 内で演算する 証明書 TLS 証明書。自動更新も可能 2 番目が重要で、鍵そのものをアプリに渡さないという点が
単なる「設定の保管庫」との決定的な違いである。
- Key Vault を構築
- アクセス方法
- Azure サービス プリンシパルでアクセス
- Managed IDでアクセス
補足(マネージド ID を使うべき理由): 2 つの方式には
決定的な差がある。
サービス プリンシパル マネージド ID 資格情報 シークレット or 証明書が必要 不要 有効期限の管理 自分で更新する 不要(Azure が管理) 置き場所 どこかに保存しなければならない 存在しない サービス プリンシパルを使うと、
「Key Vault にアクセスするためのシークレット」をどこに置くかという
循環した問題("secret zero" 問題)が生じる。マネージド ID なら、Azure のリソース自身が ID を持つため、
アプリのどこにも秘密が存在しない構成にできる。// 資格情報を一切コードに書かない var client = new SecretClient( new Uri("https://myvault.vault.azure.net/"), new DefaultAzureCredential()); var secret = await client.GetSecretAsync("DbConnectionString");
DefaultAzureCredentialは、ローカル開発時は
Azure CLIのログイン、Azure 上ではマネージド ID を
自動的に使い分けるため、同じコードのまま両方で動く。
Azure Kubernetes Service (AKS)から使う場合は、
Pod に対して ID を割り当てる。
補足(AKS からの利用方法): 現在の推奨は
Workload Identity + Secrets Store CSI Driver である。
方式 状態 Pod Identity(AAD Pod Identity) 非推奨(2024年に廃止) Workload Identity 現行。Kubernetes ServiceAccount と Entra ID を連携 Secrets Store CSI Driver Key Vault のシークレットをボリュームとしてマウント 後者を使うと、アプリからはただのファイルとして読めるため、
アプリ側の実装を変えずに済む。
Key Vault のアクセス制御には 2 方式がある。
| 方式 | 内容 |
|---|---|
| アクセス ポリシー(従来) | Vault 単位で「誰に何の操作を許すか」を列挙 |
| Azure RBAC(推奨) | RBACの仕組みに統一。シークレット単位の制御も可能 |
補足(RBAC を選ぶ): 新規構築では Azure RBAC 方式が推奨されている。
アクセス ポリシーは Vault 内の全シークレットに一律で効くうえ、
Azure の他のリソースと権限管理の仕組みが分かれてしまう。
RBACなら、PIM(Privileged Identity Management)による
期限付き権限昇格とも組み合わせられる。
- 論理削除(Soft Delete) は既定で有効。削除しても保持期間中は復元できる。
-
消去保護(Purge Protection) を有効にすると、
保持期間中は完全削除できなくなる(誤削除・攻撃対策)。 -
SDK の呼び出し回数に制限がある(スロットリング)。
シークレットは起動時に一度読んでメモリに保持し、
リクエストごとに取得しない設計にする。
補足(.NET からの利用): ASP.NET Coreでは、
構成プロバイダーとして組み込める(.NET configを参照)。builder.Configuration.AddAzureKeyVault( new Uri("https://myvault.vault.azure.net/"), new DefaultAzureCredential());こうすると、
IConfiguration["DbConnectionString"]で
appsettings.jsonと同じ書き方のまま Key Vault から読める。
既存コードの変更が最小で済むため、移行時に有効な手である。
-
Azure Key Vault
https://azure.microsoft.com/ja-jp/products/key-vault/ -
Azure Key Vault (1) 基礎 - Logico Inside
https://logico-jp.io/2019/09/19/azure-key-vault-1/
-
Azure Key Vault の基本的な概念
https://learn.microsoft.com/azure/key-vault/general/basic-concepts -
Azure RBAC を使用したアクセス権の付与
https://learn.microsoft.com/azure/key-vault/general/rbac-guide -
ASP.NET Core の Azure Key Vault 構成プロバイダー
https://learn.microsoft.com/aspnet/core/security/key-vault-configuration
Tags: 移行, クラウド, Azure, セキュリティ
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。