本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key Vault RBAC移行に伴うMicrosoft Fabricからのセキュアなシークレット連携
【導入】 Azure Key VaultのRBACモデル移行に対応し、Microsoft Fabricからシークレットを最小特権原則で安全に取得するための統合設計を解説します。
【アーキテクチャ設計】 従来の「アクセスポリシー」モデルは、ボルト単位の粗い権限管理でしたが、Azure RBACモデルへの移行により、シークレット単位の制御やEntra IDとの深い統合が可能になります。Microsoft Fabric側では、ワークスペースのマネージドIDを使用して、このRBAC権限を介して資格情報を取得します。
graph TD
subgraph mermaid_group_1["Microsoft Fabric"]
A["Data Factory / Spark"] --> B["Workspace Identity"]
end
subgraph mermaid_group_4["Azure Environment"]
B -->|"Entra ID Token"| C["Azure Key Vault"]
subgraph mermaid_group_6["Access Control(#quot;Azure RBAC#quot;)"]
C --- D["Key Vault Secrets User"]
end
end
D -.->|"Grant Access"| Bこの構成では、Fabricワークスペースに割り当てられたシステム割り当てマネージドID（またはユーザー割り当てマネージドID）に対し、Azure Key Vaultのリソーススコープで「Key Vault Secrets User」ロールを付与します。これにより、コード内に資格情報を埋め込むことなく安全なアクセスが実現します。
【実装・デプロイ手順】 Azure CLIを使用して、RBACを有効化したKey Vaultの作成と、FabricマネージドIDへの権限付与を行います。
# 1. RBACを有効にしたKey Vaultの作成 az keyvault create \ --name "kv-fabric-prod-001" \ --resource-group "rg-data-platform" \ --location japaneast \ --enable-rbac-authorization true # 2. FabricワークスペースのマネージドIDを取得 (Fabric側で有効化済み前提) # 注意: Fabricの管理画面からワークスペースIDを確認してください # 3. 特定のシークレットに対する「Key Vault Secrets User」ロールの割り当て # スコープをシークレット単位に絞ることで最小特権を適用 az role assignment create \ --role "Key Vault Secrets User" \ --assignee-object-id "<Fabric-Workspace-Identity-ID>" \ --assignee-principal-type ServicePrincipal \ --scope "/subscriptions/<Sub-ID>/resourceGroups/rg-data-platform/providers/Microsoft.KeyVault/vaults/kv-fabric-prod-001/secrets/sql-password"
Bicepによる宣言的定義（Key Vault構成部分）:
resource keyVault '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モデルを強制
enabledForDeployment: false
enabledForDiskEncryption: false
enabledForTemplateDeployment: false
}
}
【アイデンティティとセキュリティ】
最小特権原則の徹底: 「Key Vault Administrator」や「Contributor」ではなく、「Key Vault Secrets User」を使用します。読み取りが必要なIDには、シークレットの取得権限のみを与えます。
ネットワーク境界の保護: Key Vaultの「ファイアウォールと仮想ネットワーク」設定で、公衆ネットワークからのアクセスを制限し、「信頼された Microsoft サービス」を許可することで、Fabricからの通信経路をセキュアに保ちます。
条件付きアクセス: サービスプリンシパル（FabricマネージドID）に対しても、場所やリスクベースの条件付きアクセスポリシーを検討してください。
【運用・コスト最適化】
可観測性: Azure Monitorの診断設定で、Key Vaultの「AuditEvent」をLog Analyticsワークスペースへ転送します。誰がいつシークレットにアクセスしたかをリアルタイムで監視可能です。
SKU選択: 通常の運用では「Standard」SKUで十分です。HSMによる保護（FIPS 140-2 Level 3）が必要なコンプライアンス要件がある場合のみ「Premium」を選択してください。
キャパシティ管理: Key Vaultはスループット制限（サービス制限）があります。Fabricの大量の並列Sparkジョブから頻繁にアクセスする場合は、シークレットのキャッシュ戦略を検討してください。
【まとめ】
アクセスポリシーからRBACへの完全移行: 新規デプロイではアクセスポリシーを避け、一貫性のあるAzure RBACモデルを採用すること。
FabricマネージドIDの活用: サービスプリンシパルのシークレット管理（有効期限等）のオーバーヘッドを避けるため、FabricワークスペースIDを優先的に使用すること。
落とし穴（注意点）: RBAC変更の反映には最大10分程度の遅延が発生する場合があります。デプロイ直後のテスト失敗時は、この伝搬時間を考慮してください。
