Azure Key Vault RBAC移行への対応：Microsoft Fabric連携におけるシークレット管理の最適化

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Key Vault RBAC移行への対応：Microsoft Fabric連携におけるシークレット管理の最適化

【導入】

Azure Key Vaultのアクセス制御が「アクセスポリシー」から「Azure RBAC」へ既定化される中、Microsoft Fabricからのセキュアなシークレット取得を実現する権限設計と実装手法を提示します。

【アーキテクチャ設計】

Microsoft Fabric（Data Factory/Spark）がAzure Key Vault（AKV）にアクセスする際、従来の「アクセスポリシー」ではなく、Azure RBACモデルを利用することで、Entra IDに基づいた一元的な権限管理が可能になります。Fabricの「ワークスペース管理 ID（Workspace Managed Identity）」を活用し、最小権限（Least Privilege）を適用したデータパイプラインを構築します。

graph TD
    subgraph "Microsoft Fabric"
        A["Fabric Workspace"] --> B["Managed Identity"]
        B --> C["Data Factory / Notebook"]
    end

    subgraph "Azure Environment"
        D["Entra ID"] -.->|Role Assignment| E
        E["Azure Key Vault"]
        F[Networking] ---|Private Link| E
    end

    C -->|Authenticate| D
    C -->|Get Secret| E
    E -->|Return Secret| C

構成のポイント:

  1. RBACの有効化: Key Vault作成時に enableRbacAuthorization: true を設定。

  2. ワークスペース管理 ID: Fabricのワークスペース単位で発行されるIDを認証主体として利用。

  3. ロール割り当て: 従来の「Get/List」ポリシーの代わりに「Key Vault Secrets User」ロールを付与。

【実装・デプロイ手順】

1. BicepによるAzure Key Vault（RBACモード）のプロビジョニング

アクセスポリシーを排除し、RBACを強制する構成です。

resource vault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-fabric-prod-001'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true // RBACモデルを強制
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

2. Azure CLIによるFabric管理IDへのロール割り当て

Fabricワークスペースの管理IDに対し、シークレット参照権限のみを付与します。

# Fabricワークスペースの管理IDオブジェクトIDを取得（事前にFabric側で有効化済みとする）

PRINCIPAL_ID="<Fabric-Workspace-Identity-Object-ID>"
KV_RESOURCE_ID=$(az keyvault show --name kv-fabric-prod-001 --query id -o tsv)

# 「Key Vault Secrets User」ロールをスコープ限定で付与

az role assignment create \
    --role "Key Vault Secrets User" \
    --assignee-object-id $PRINCIPAL_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $KV_RESOURCE_ID

【アイデンティティとセキュリティ】

  1. ゼロトラスト原則の適用:

    • 認証: Microsoft Fabricのワークスペース管理IDを使用することで、コード内へのシークレット埋め込みを完全に排除します。

    • 認可: Key Vault Administrator ではなく Key Vault Secrets User を使用し、読み取り専用権限に限定します。

  2. ネットワーク境界の保護:

    • Key Vaultの「信頼されたMicrosoftサービスによるバイパス」を有効化しつつ、パブリックアクセスを制限します。Fabricからのアクセスには、ワークスペースの「Managed Private Endpoint」の利用が推奨されます。

  3. 条件付きアクセス:

    • ワークロードアイデンティティに対して条件付きアクセスを適用し、特定の場所やデバイス以外からのトークン発行を制限する構成を検討してください。

【運用・コスト最適化】

  1. 可観測性（Log Analytics）:

    • Azure Monitorの診断設定で AuditEvent を有効化。Fabric側のどのノートブックが、いつシークレットを取得したかを完全に監査可能にします。

  2. コスト削減:

    • SKU選択: HSM（ハードウェア・セキュリティ・モジュール）が必要ない場合は Standard SKUを選択。シークレットの読み取りトランザクション（10,000件あたり約$0.03）を監視し、不要なループ処理内での取得を避ける（キャッシュの活用）。

  3. ガバナンス:

    • Azure Policyを使用して、enableRbacAuthorization が false のKey Vault作成を拒否するガードレールを設置します。

【まとめ】

  1. RBACへの完全移行: 従来のアクセスポリシーは「誰が」を管理できても「どのリソース範囲で」の制御が困難でした。RBAC移行により、Azure全体での一貫したガバナンスが可能になります。

  2. Fabric管理IDの活用: 認証情報の管理をプラットフォーム側に委ねることで、資格情報の漏洩リスクを最小化できます。

  3. 移行時の注意点（落とし穴）: 既存のアクセスポリシーからRBACに切り替えた瞬間、既存のすべてのポリシーが無効化されます。移行前に必ずロール割り当てを完了させてから切り替えを実施してください。

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

コメント

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