本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Microsoft FabricからAzure Key Vaultへのセキュア接続：RBACモデル移行ガイド
【導入】 Azure RBACへの一本化が進むKey VaultとMicrosoft Fabricの連携を、最小権限の原則に基づきモダンに構成する方法を解説します。
【アーキテクチャ設計】 本設計では、従来の「アクセスポリシー」を廃止し、Azure RBACによる一元的な権限管理を採用します。Microsoft Fabricのデータパイプラインやノートブックが、Entra ID認証を介してKey Vaultから認証情報を安全に取得するフローを構築します。
graph TD
subgraph mermaid_group_1["Microsoft Fabric"]
A["Notebook / Pipeline"] --> B["Managed Identity / SPN"]
end
subgraph mermaid_group_4["Azure Key Vault(#quot;RBAC Mode#quot;)"]
B -->|"Entra ID Token"| C{"RBAC Check"}
C -->|"Authorized"| D["Secret / Key / Cert"]
end
subgraph mermaid_group_8["Identity & Governance"]
E["Entra ID"] --- B
E --- C
end【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultのデプロイと、Fabricからのアクセス許可設定をBicepおよびCLIで実施します。
- 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モデルを強制
networkAcls: {
defaultAction: 'Deny'
bypass: 'AzureServices' // Fabric等の信頼されたサービスを許可
}
}
}
- ロールの割り当て（Azure CLI） Fabricが利用するマネージドID等に対し、「Key Vault シークレット ユーザー」権限を付与します。
# マネージドIDのオブジェクトIDを取得
ASSIGNEE_ID=$(az identity show --name "id-fabric-app" --resource-group "rg-shared" --query principalId -o tsv)
# Key VaultのリソースIDを取得
KV_ID=$(az keyvault show --name "kv-fabric-prod-001" --query id -o tsv)
# 「Key Vault シークレット ユーザー」ロールを割り当て
az role assignment create \
--role "Key Vault Secrets User" \
--assignee-object-id $ASSIGNEE_ID \
--scope $KV_ID \
--assignee-principal-type ServicePrincipal
【アイデンティティとセキュリティ】
最小権限の原則 (PoLP): 「Key Vault 管理者」ではなく、参照専用の「Key Vault シークレット ユーザー (Key Vault Secrets User)」を使用します。
ネットワーク分離: Key Vaultのファイアウォールで「信頼されたMicrosoftサービスによるバイパス」を有効にし、Fabricからの通信を許可しつつ、パブリックアクセスを制限します。
条件付きアクセス: 必要に応じて、サービスプリンシパルに対する場所制限や、マネージドIDの使用を強制するポリシーを適用します。
【運用・コスト最適化】
可観測性: Azure Monitorの診断設定で
AuditEventを有効化し、Log Analyticsへ転送します。Fabricからのアクセス試行をリアルタイムで監査可能です。コスト最適化: Key Vault Standard SKU（トランザクション課金）を選択します。Fabric側でシークレットをキャッシュするロジック（ノートブック内など）を実装することで、APIコール数とコストを抑制できます。
ライフサイクル管理:
enablePurgeProtectionを有効にし、誤削除によるデータ損失を防止します。
【まとめ】
RBACへの完全移行: 従来のアクセスポリシーは非推奨であり、新設するKey Vaultでは
enableRbacAuthorization: trueを必須とすべきです。Fabricの認証方式: Fabricノートブックでは
mssparkutils.credentials.getSecret()を利用し、コード内にシークレットをハードコードしない運用を徹底してください。落とし穴（権限反映の遅延）: Azure RBACの変更は反映まで最大10分程度かかる場合があります。デプロイ直後の接続エラー時は、この伝搬時間を考慮したリトライ設計が必要です。
