本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key VaultとManaged Identityによるセキュアなシークレット管理
クラウドアプリケーションにおいて、データベース接続文字列、APIキー、証明書といったシークレット情報の管理はセキュリティ上極めて重要です。Azure Key Vaultはこれらのシークレットを安全に保管し、Azure Managed Identityと組み合わせることで、アプリケーションからの安全なアクセスを実現します。これにより、コード内にシークレットをハードコードしたり、構成ファイルに平文で保存したりするリスクを排除し、セキュリティ体制を大幅に強化できます。
アーキテクチャ
Azure Key VaultとManaged Identityを組み合わせた基本的なアーキテクチャは以下のフローで構成されます。アプリケーションは自身のマネージドIDを介してAzure Entra ID（旧 Azure Active Directory）で認証され、Key Vaultへのアクセス権限を取得します。これにより、アプリケーションが直接シークレットを知ることなく、安全に取得できるようになります。
flowchart TD
A["Azure Application"]|認証要求| -- Azure Entra ID --> B("Managed Identity")
B -- アクセストークン取得 --> C("Azure Entra ID")
C -- アクセストークン返却 --> B
B -- |アクセストークン付与| --> D["Azure Key Vault"]
D -- |シークレット取得| --> A
構成要素:
Azure Application (A): Azure App Service, Azure Functions, Azure VM, Azure Container Appsなど、マネージドIDをサポートするあらゆるAzureサービス。
Managed Identity (B): Azure Entra IDによって管理される、Azureサービス用の自動管理されるID。システム割り当てマネージドIDとユーザー割り当てマネージドIDの2種類があります。
Azure Entra ID (C): AzureのIDおよびアクセス管理サービス。マネージドIDの認証、アクセストークンの発行を行います。
Azure Key Vault (D): シークレット、キー、証明書を一元的に安全に管理するサービス。FIPS 140-2 Level 2検証済みのHSMで保護されます。
設定手順
ここでは、Azure App Serviceがシステム割り当てマネージドIDを使用してAzure Key Vaultからシークレットを取得する手順をAzure CLIで示します。
リソースグループの作成
az group create --name myResourceGroup --location japaneast
Azure Key Vaultの作成 Standard SKUで、ソフトデリートとパージ保護を有効にします。
az keyvault create \ --name myKeyVault12345 \ --resource-group myResourceGroup \ --location japaneast \ --sku Standard \ --enable-soft-delete true \ --enable-purge-protection true
シークレットの保存
az keyvault secret set \ --vault-name myKeyVault12345 \ --name myDbConnectionString \ --value "Server=tcp:mydb.database.windows.net,1433;Database=mydb;User ID=user;Password=password;"
Azure App Serviceの作成とマネージドIDの有効化 システム割り当てマネージドIDを有効にしてApp Serviceを作成します。
az appservice plan create \ --name myAppServicePlan \ --resource-group myResourceGroup \ --sku B1 \ --is-linux az webapp create \ --name myWebApp12345 \ --resource-group myResourceGroup \ --plan myAppServicePlan \ --runtime "DOTNET|6.0" \ --assign-identity # システム割り当てマネージドIDを有効化
Key Vaultへのアクセス権限付与 App ServiceのマネージドIDにKey Vaultの「Key Vault シークレットユーザー」ロールを付与します。
# App ServiceのマネージドIDのプリンシパルIDを取得 PRINCIPAL_ID=$(az webapp identity show --name myWebApp12345 --resource-group myResourceGroup --query principalId --output tsv) # Key Vaultにロール割り当て az role assignment create \ --role "Key Vault シークレットユーザー" \ --assignee $PRINCIPAL_ID \ --scope /subscriptions/$(az account show --query id -o tsv)/resourceGroups/myResourceGroup/providers/Microsoft.KeyVault/vaults/myKeyVault12345
これで、myWebApp12345 は自身のマネージドIDを使用して myKeyVault12345 から myDbConnectionString シークレットを安全に取得できるようになります。
運用監視
可観測性: Azure Monitor for Key Vaultは、メトリック（トランザクション数、レイテンシなど）と診断ログを提供します。これらを活用し、Key Vaultへのアクセス状況、エラー発生、レート制限状況を監視します。
ログ: Key Vaultの診断設定を有効にし、監査ログ、アクセスログをAzure Log Analytics Workspaceへ送信します。これにより、誰が、いつ、どのシークレットにアクセスしたか、あるいは失敗したかを詳細に追跡できます。
SLA: Azure Key Vaultは、99.99%のSLAを提供しており、高可用性が保証されています。
バックアップとDR: Key Vault自体はAzureプラットフォームによる冗長性を持っています。ソフトデリートとパージ保護を有効にすることで、偶発的な削除や悪意のある削除からシークレットを保護し、DR戦略の一部とすることができます。これにより、削除されたシークレットを一定期間内に回復可能です。Key Vault自体に対するバックアップ機能はありませんが、必要に応じてシークレットの内容を安全な場所にエクスポート・インポートする運用も検討可能です（ただし、これは推奨されるベストプラクティスではありません）。
セキュリティ
アイデンティティと権限境界 (Azure Entra ID):
Managed Identity: Azure Entra IDによって管理され、リソースに割り当てられたIDであり、パスワード管理が不要です。システム割り当てIDはリソースのライフサイクルに結合し、ユーザー割り当てIDは独立して管理され複数のリソースに割り当て可能です。
Azure RBAC: Key Vaultへのアクセス制御はAzureロールベースアクセス制御（RBAC）を使用します。
Key Vault シークレットユーザーロール（シークレットの読み取り）やKey Vault 管理者ロール（シークレットの管理）など、最小権限の原則に基づき必要な権限のみを付与します。Key Vaultのデータプレーンへのアクセスは、Key VaultアクセスポリシーではなくRBACで管理することが推奨されます。条件付きアクセス (Conditional Access): Key Vaultへの管理者アクセス（ポータルやCLIからの管理操作）に対して、多要素認証（MFA）の強制、特定のIP範囲からのアクセス制限、デバイス準拠の要求など、Entra IDの条件付きアクセス ポリシーを適用することで、管理者のセキュリティを強化できます。アプリケーションのマネージドIDはEntra IDで認証されますが、条件付きアクセスはユーザーベースの認証に適用されるため、マネージドIDには直接適用されません。
ネットワーク分離: Azure Private EndpointをKey Vaultに構成することで、仮想ネットワーク内のプライベートIPアドレスを介してのみKey Vaultにアクセスさせ、パブリックインターネットからのアクセスを完全にブロックできます。
Azure Defender for Key Vault (Microsoft Defender for Cloud): Key Vaultを保護するためにDefender for Cloudを有効化することで、異常なシークレットアクセスパターン、不審なVault構成変更などの脅威を検出し、アラートを発します。
暗号化: Key Vaultに保存されるシークレットは、Azure Key Vaultによって管理されるキーで暗号化されます。プレミアムSKUを選択すれば、FIPS 140-2 Level 2検証済みのハードウェアセキュリティモジュール (HSM) によって保護されたキーを使用できます。
コスト
Azure Key Vaultのコストは、主に利用するSKUとトランザクション数によって決定されます。
Key Vault SKU:
Standard: ソフトウェアキーとシークレットを保護し、トランザクションあたりの料金が発生します。ほとんどの一般的なユースケースに適しています。
Premium: HSM（Hardware Security Module）で保護されたキーとシークレットを使用でき、Standardよりも高価です。FIPS 140-2 Level 2の要件がある場合に選択します。
トランザクション料金: キーの作成/取得、シークレットの保存/取得、証明書の操作など、Key Vaultに対する各操作に対して料金が発生します。
マネージドID: マネージドID自体には料金は発生しません。
関連サービス: 診断ログを送信するLog Analytics Workspace、Private Endpointの料金などが別途発生します。
コスト最適化:
SKUの適切な選択: HSMが必要ない場合は、
StandardSKUを選択します。アクセスパターンの最適化: 不要なシークレットへのアクセスを減らし、アプリケーションがシークレットをキャッシュするなどの戦略を検討し、トランザクション数を最小限に抑えます。
モニタリング: Azure Monitorでトランザクション数を監視し、想定外のコスト増加がないか確認します。
リザーブドインスタンス/ライセンス: Key Vaultにはリザーブドインスタンスや、特別なライセンスモデルはありません。
落とし穴
RBACの不備: マネージドIDにKey Vaultへの適切なRBACロール（例:
Key Vault シークレットユーザー）が割り当てられていないと、シークレットの取得に失敗します。ネットワーク設定の誤り: Private Endpointを使用している場合、VNetからの名前解決が正しく行われているか、またはKey Vaultファイアウォールで送信元IPアドレスが許可されているか確認が必要です。
パージ保護の無効化: ソフトデリートは有効でもパージ保護が無効な場合、悪意のあるユーザーがKey Vaultを即座に削除できてしまいます。常に両方を有効にしてください。
Key Vaultのレート制限: 大量のシークレットアクセスが発生すると、Key Vaultはレート制限を適用することがあります。アプリケーション側でリトライロジックを実装するか、Key Vaultの利用設計を見直す必要があります。
シークレットのローテーション戦略の欠如: シークレットは定期的にローテーションする必要があります。これに対応する自動化されたプロセスがないと、セキュリティリスクが増大します。
過剰な権限付与: 最小権限の原則に反して、マネージドIDに必要以上の権限（例: Key Vault管理者）を付与すると、潜在的なセキュリティリスクとなります。
まとめ
Azure Key VaultとManaged Identityの組み合わせは、Azure上で動作するアプリケーションのシークレット管理において、最も推奨されるベストプラクティスです。このアプローチにより、開発者はシークレット管理の複雑さから解放され、セキュリティチームは一元化されたシークレット管理と監査機能により、堅牢なセキュリティ体制を維持できます。アーキテクチャ設計、設定、運用監視、セキュリティ、コスト最適化の各側面で適切な考慮を行うことで、安全で効率的なクラウド環境を実現できます。
コメント