META
version: 1.0
context: Senior Cloud Architect
target: Azure/Fabric Administrators
key_elements: Azure RBAC, Microsoft Fabric, Azure Key Vault, Managed Identity
delivery_style: Technical Solution Architect Document
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure RBAC移行に伴うMicrosoft FabricからのKey Vaultシークレット取得構成ガイド
【導入】 Azure Key Vaultのアクセス制御をRBACへ統合し、Microsoft Fabricのデータパイプラインにおけるセキュアな認証管理を実現します。
【アーキテクチャ設計】 本構成では、従来の「アクセスポリシー」モデルから、より粒度の細かい制御が可能な「Azure RBAC」モデルへ移行します。Microsoft FabricのワークスペースID（Managed Identity）に対して、Key Vault内の特定のシークレットに対する「Key Vault Secrets User」ロールを付与することで、セキュアな資格情報取得を可能にします。
graph LR
subgraph mermaid_group_1["Microsoft Fabric"]
A["Notebook / Data Factory"] --> B["Workspace Managed Identity"]
end
subgraph mermaid_group_4["Azure Entra ID"]
B --> C["Token Request"]
end
subgraph mermaid_group_7["Azure Key Vault(#quot;RBAC Model#quot;)"]
C --> D["Role Check: Key Vault Secrets User"]
D --> E["Secret Value"]
end
E --> A【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultのデプロイと、Fabricからのアクセス権限付与の手順を示します。
- BicepによるKey Vaultのデプロイ（RBAC有効化）
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
}
}
- Azure CLIによるロール割り当て FabricのワークスペースManaged Identityに対して権限を付与します。
# 変数設定
KV_NAME="kv-fabric-prod-001"
ASSIGNEE_ID="<Fabric-Workspace-Identity-ID>"
ROLE="Key Vault Secrets User"
# ロール割り当ての実行
az role assignment create \
--role "$ROLE" \
--assignee-object-id "$ASSIGNEE_ID" \
--scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/$KV_NAME" \
--assignee-principal-type ServicePrincipal
【アイデンティティとセキュリティ】
認証モデルの統一: アクセスポリシー（Vault全体への権限）ではなく、RBACを使用することで「特定のシークレットのみ」へのアクセス許可を付与する最小権限の原則（PoLP）を適用します。
ネットワークセキュリティ: FabricからKey Vaultへのアクセスは、Fabricの「信頼されたサービス」設定または「Managed Private Endpoint」を使用して、パブリックインターネットを経由しない通信経路を確立することを推奨します。
条件付きアクセス: サービスプリンシパルに対する場所制限などの条件付きアクセスポリシーを適用し、認証の境界を強化します。
【運用・コスト最適化】
可観測性: Azure Monitorの診断設定を有効にし、
AuditEventをLog Analyticsへ送信します。RBAC移行後は、誰がどの権限でシークレットにアクセスしたかが「AzureActivity」ログおよびKey Vaultログの両面から追跡可能になります。コスト最適化: Key VaultのStandard SKUはトランザクションベースの課金です。Fabricの各ノードが個別にシークレットを取得するのではなく、トークンのキャッシュや、Fabric環境変数への一時的な保持を検討し、APIコール数を抑制します。
【まとめ】
RBAC反映の遅延: ロール割り当て後、反映までに最大5〜10分程度のキャッシュ遅延が発生する可能性があるため、CI/CDパイプライン設計時に注意が必要です。
アクセスポリシーの廃止: RBACモデルに切り替えると、既存のアクセスポリシーは無視されます。移行時は既存アプリケーションの権限不足が発生しないよう、事前に一括でロール割り当てを行う必要があります。
Fabric IDの特定: Microsoft FabricのManaged Identityはワークスペースごとに作成されるため、環境（Dev/Prod）ごとに適切な識別子をKey Vault側に登録する運用フローを確立してください。
