Azure Key VaultとManaged Identityによるセキュアなシークレット管理

Tech

本記事は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で示します。

  1. リソースグループの作成

    az group create --name myResourceGroup --location japaneast

  2. 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

  3. シークレットの保存

    az keyvault secret set \
  --vault-name myKeyVault12345 \
  --name myDbConnectionString \
  --value "Server=tcp:mydb.database.windows.net,1433;Database=mydb;User ID=user;Password=password;"

  4. 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を有効化

  5. 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が必要ない場合は、Standard SKUを選択します。

  • アクセスパターンの最適化: 不要なシークレットへのアクセスを減らし、アプリケーションがシークレットをキャッシュするなどの戦略を検討し、トランザクション数を最小限に抑えます。

  • モニタリング: 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上で動作するアプリケーションのシークレット管理において、最も推奨されるベストプラクティスです。このアプローチにより、開発者はシークレット管理の複雑さから解放され、セキュリティチームは一元化されたシークレット管理と監査機能により、堅牢なセキュリティ体制を維持できます。アーキテクチャ設計、設定、運用監視、セキュリティ、コスト最適化の各側面で適切な考慮を行うことで、安全で効率的なクラウド環境を実現できます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました