{ “focus”: “Azure Key Vault RBAC transition & Microsoft Fabric Integration”, “architect_level”: “Senior”, “tech_stack”: [“Azure Key Vault”, “Microsoft Fabric”, “Azure RBAC”, “Bicep”, “Entra ID”], “compliance”: “Well-Architected Framework”, “style”: “Technical/Professional” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure RBAC 統合による Microsoft Fabric のセキュアな Key Vault シークレット取得構成
【導入】 Fabric から Key Vault へのシークレット取得を、Azure RBAC 統合モデルで安全かつ一元的に管理する構成を解説します。
【アーキテクチャ設計】 本構成では、従来の Key Vault アクセスポリシー（Vault-local）を廃止し、Azure のコントロールプレーンと統合された RBAC（役割ベースのアクセス制御）を使用します。これにより、Microsoft Fabric のマネージド ID やユーザー ID に対して、特定のシークレットのみを読み取る権限を Entra ID 経由で動的に付与・監査することが可能になります。
graph TD
subgraph "Microsoft Fabric (SaaS)"
A["Data Factory / Notebook"] --> B["Managed Identity / User Token"]
end
subgraph "Azure Resource (PaaS)"
B -->|OAuth2 / RBAC| C["Azure Key Vault"]
C -->|Audit Logs| D["Log Analytics"]
end
subgraph "Identity Provider"
E["Microsoft Entra ID"] -.->|Check Role Assignment| C
end
【実装・デプロイ手順】 Azure RBAC モデルを有効にした Key Vault のデプロイと、Fabric 側からアクセスするための最小権限割り当てを Bicep で実行します。
1. Azure RBAC 統合を有効にした Key Vault の作成 (Bicep)
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 // Azure RBAC 統合を有効化
enabledForDeployment: false
enabledForDiskEncryption: false
enabledForTemplateDeployment: false
}
}
2. 権限の割り当て (Azure CLI) Microsoft Fabric のワークスペース ID または実行ユーザーに対して「Key Vault Secrets User（キー コンテナー シークレット ユーザー）」ロールを付与します。
# 特定のシークレットに対する読み取り権限のみを付与（最小権限の原則）
scope="/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/kv-fabric-prod-001"
assignee_id="<fabric-identity-object-id>"
az role assignment create \
--role "Key Vault Secrets User" \
--assignee-object-id $assignee_id \
--scope $scope \
--assignee-principal-type ServicePrincipal
【アイデンティティとセキュリティ】
認証の近代化: アクセスポリシーモデルでは「Vault 全体」の権限になりがちでしたが、RBAC ではシークレット単位での詳細な Scope（スコープ）設定が可能です。
マネージド ID の活用: Fabric の Data Factory 等で「信頼できるサービス」として Key Vault に接続する場合、資格情報のハードコーディングを完全に排除できます。
条件付きアクセス: Entra ID の条件付きアクセスを組み合わせ、特定の IP 範囲または準拠デバイスからの Fabric 経由のアクセスのみを許可する境界設計が推奨されます。
【運用・コスト最適化】
可観測性: Azure RBAC へ移行することで、
Microsoft.Authorization/roleAssignmentsのログが Azure Activity Log に統合され、誰が権限を付与したかの追跡が容易になります。SKU 選択: 一般的なシークレット管理であれば「Standard」SKU で十分ですが、FIPS 140-2 Level 3 準拠が必要な場合は「Premium」を選択し、マネージド HSM を検討してください。
ガバナンス: Azure Policy を使用して
Key Vaults should use Azure RBACを強制し、レガシーなアクセスポリシーの新規作成を禁止します。
【まとめ】
RBAC 移行の必須性: Fabric 等の最新 SaaS 統合では、管理の一貫性と監査性の観点からアクセスポリシーではなく Azure RBAC 統合が推奨されます。
伝搬遅延の考慮: RBAC のロール割り当ては反映までに最大 5〜10 分程度の遅延が発生する可能性があるため、CI/CD パイプライン設計時にはリトライ処理を含める必要があります。
最小権限の徹底: Fabric ワークスペース全体に権限を与えるのではなく、可能な限り特定の Key Vault またはシークレット単位でスコープを絞り込み、爆発半径を最小化してください。
