[PLAN]
シナリオ：Microsoft FabricからAzure Key Vault (AKV) のシークレットを安全に取得するため、従来の「アクセスポリシー」から「Azure RBAC」への完全移行を前提とした設計。
技術スタック：Azure Key Vault (RBAC有効), Microsoft Fabric (Managed Identity), Bicepによるプロビジョニング。
セキュリティ：最小権限の原則（PoLP）に基づき、特定のシークレット参照権限のみをFabricのワークスペースIDに付与。
運用：Azure Monitorとの統合によるシークレットへのアクセス監査。
[RESEARCH]
Azure Key Vaultは現在、新規作成時にAzure RBACを推奨。
Microsoft Fabricはワークスペースレベルで「Managed Identity」をサポートしており、これを用いてAKVへの認証を行うのがベストプラクティス。
RBACモデルでは「Key Vault Secrets User」ロールが必要。
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Fabric×Key Vault：Azure RBACモデルによる次世代シークレット管理の実装ガイド
【導入】 FabricワークスペースのマネージドIDとAzure RBACを統合し、レガシーなアクセスポリシーを排除したセキュアな認証基盤を構築します。
【アーキテクチャ設計】 本構成では、Microsoft FabricのワークスペースIDを信頼されたエンティティとしてAzure Key Vaultに登録します。従来のアクセスポリシーモデルとは異なり、Azureの共通管理プレーン（RBAC）で権限を一元化することで、ガバナンスの向上と設定ミスによる露出リスクを低減します。
graph TD
subgraph Microsoft Fabric
A["Data Factory / Notebook"] --> B["Workspace Managed Identity"]
end
subgraph Azure Platform
B -->|Entra ID Auth| C["Azure Key Vault"]
C -->|RBAC Check| D{"Key Vault Secrets User"}
D -->|Allow| E["Secret Value"]
end
F[Admin/Dev] -->|Control Plane| C
【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultの作成と、Fabricへの権限割当をBicepで自動化します。
- Azure 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 // RBACモデルを強制
networkAcls: {
defaultAction: 'Deny'
bypass: 'AzureServices'
}
}
}
- FabricマネージドIDへのロール割当 (CLI) FabricワークスペースのID（Principal ID）に対し、「Key Vault シークレット ユーザー」ロールを付与します。
# FabricワークスペースのIDを変数に格納
FABRIC_ID="<Fabric-Workspace-Identity-Object-ID>"
KV_SCOPE="/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/kv-fabric-prod-001"
# ロール割り当ての実行 (Key Vault Secrets User)
az role assignment create \
--role "Key Vault Secrets User" \
--assignee $FABRIC_ID \
--scope $KV_SCOPE
【アイデンティティとセキュリティ】
認証モデルの移行: 従来の「Vaultアクセスポリシー」を無効化（
enableRbacAuthorization: true）し、Entra IDによる一元的な監査を可能にします。最小権限の原則: Fabric側には「Key Vault Secrets User」のみを付与し、シークレットの削除や管理権限（Admin）を分離します。
条件付きアクセス: 信頼された場所からのアクセスのみを許可するポリシーをEntra ID側で適用し、Fabricの実行環境以外からのトークン利用を制限します。
【運用・コスト最適化】
可観測性: Azure Monitor の診断設定で
AuditEventを有効化し、Log Analytics ワークスペースへ転送します。誰が、いつ、どのシークレットを取得したかをリアルタイムで監視します。コスト:
SKU選択: Fabricからの参照頻度が低い（バッチ処理等）場合は「Standard」SKUで十分です。HSM（FIPS 140-2 Level 3）が必要な要件のみ「Premium」を選択してください。
トランザクションコスト: Key Vaultはリクエスト数に応じた課金であるため、Fabric Notebook内での頻繁なループ内取得を避け、キャッシュ戦略（Lazy Load）を推奨します。
【まとめ】
RBACへの完全移行: Fabricとの連携ではアクセスポリシーを「オフ」にし、Azure RBACを「オン」にすることがセキュリティ標準。
ワークスペースIDの活用: 個人のユーザーアカウントではなく、Fabricワークスペース固有のマネージドIDに権限を紐付ける。
落とし穴の回避: RBAC反映には数分の遅延があるため、デプロイ直後のFabricジョブ実行エラーにはリトライ処理を組み込むこと。
