{ “profile”: “senior_cloud_architect”, “topic”: “AKV_RBAC_Migration_Fabric_Integration”, “status”: “draft”, “framework”: “Azure_Well_Architected”, “tooling”: [“Azure CLI”, “Bicep”, “Microsoft Fabric”] }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key Vault RBAC移行とMicrosoft Fabricによるセキュアなシークレット取得構成
【導入】 Azure RBACによるKey Vaultの権限管理一本化と、Microsoft FabricからのワークスペースIDを用いたセキュアな認証統合を解説します。
【アーキテクチャ設計】 従来の「アクセスポリシー」モデルから「Azure RBAC」モデルへ移行することで、コントロールプレーンとデータプレーンの権限管理をEntra IDで一元化します。Microsoft Fabric側では「ワークスペースID（マネージドID）」を利用することで、ノートブックやデータパイプラインからコード内に資格情報を記述することなく、安全にシークレットを読み取ります。
graph TD
subgraph "Microsoft Fabric"
A["Fabric Workspace"] -->|Managed Identity| B["Fabric Notebook/Pipeline"]
end
subgraph "Azure Environment"
B -->|Entra ID Auth| C["Azure Key Vault"]
C -->|RBAC: Key Vault Secrets User| B
D[Admin/Dev] -->|RBAC: Key Vault Administrator| C
end
subgraph "Identity Provider"
E["Microsoft Entra ID"] -.->|Token Issue| B
end
この構成では、Fabricの各ワークスペースに割り当てられたシステム割り当てマネージドIDに対し、Key Vault側の「キー コンテナー シークレット ユーザー」ロールを最小権限で割り当てます。
【実装・デプロイ手順】 Azure RBACを有効にしたKey Vaultの作成と、Fabricからの接続を想定したBicepコードの例です。
1. Azure CLI によるRBAC有効化Key Vaultの作成
# RBAC許可を有効にしたKey Vaultの作成 az keyvault create \ --name "kv-fabric-prod-001" \ --resource-group "rg-shared-infra" \ --location japaneast \ --enable-rbac-authorization true
2. IaC (Bicep) によるロール割り当ての自動化
// Key Vaultの定義
resource kv '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'
}
}
}
// FabricワークスペースIDへのロール割り当て（シークレット参照のみ）
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(kv.id, 'Key Vault Secrets User')
scope: kv
properties: {
roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '4633458b-17de-408a-b874-0445c86b69e6') // Key Vault Secrets User
principalId: 'fabric-workspace-identity-guid' // FabricのワークスペースIDを指定
principalType: 'ServicePrincipal'
}
}
【アイデンティティとセキュリティ】
最小権限の原則 (PoLP): Fabric側には
Key Vault Secrets Userのみを付与し、シークレットの管理権限（作成・削除）は分離します。ネットワーク境界: Fabricはマネージドネットワークサービスを介してAKVにアクセスします。AKV側で「信頼されたMicrosoftサービスを許可」を有効にしつつ、パブリックアクセスを制限します。
条件付きアクセス: Key Vaultへのアクセスに対し、FabricのワークスペースIDの場所や認証強度を制限するポリシーの適用を検討してください。
【運用・コスト最適化】
可観測性: Azure Monitorで
SecretGetイベントを監視します。RBACに移行することで、監査ログには「誰が」だけでなく「どのRBACロールで」アクセスしたかが明確に記録されます。SKU選択: Fabricからの頻繁なシークレット取得が発生する場合、Standard SKUで十分ですが、HSMによる保護が必要な法規制対象データの場合は Premium SKU を選択します。
コスト: Key Vaultのコストはトランザクション数（10,000操作単位）に依存するため、Fabricノートブック内では取得したシークレットを短時間キャッシュする実装が推奨されます。
【まとめ】
RBAC移行の必須性: 今後のAzure標準はRBACモデルです。アクセスポリシーから移行する際は、既存の権限が漏れなくロールにマッピングされているか確認してください。
Fabricアイデンティティの活用: Fabricワークスペースごとにアイデンティティを構成し、環境（Dev/Prod）ごとに異なるKey Vaultを参照させる設計がベストプラクティスです。
伝播遅延の考慮: RBACのロール割り当ては反映までに最大数分かかる場合があるため、自動デプロイ直後のFabricジョブ実行時にはリトライロジックを含めるのが安全です。
