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ノートブック内では取得したシークレットを短時間キャッシュする実装が推奨されます。

まとめ

1. RBAC移行の必須性: 今後のAzure標準はRBACモデルです。アクセスポリシーから移行する際は、既存の権限が漏れなくロールにマッピングされているか確認してください。
2. Fabricアイデンティティの活用: Fabricワークスペースごとにアイデンティティを構成し、環境（Dev/Prod）ごとに異なるKey Vaultを参照させる設計がベストプラクティスです。
3. 伝播遅延の考慮: RBACのロール割り当ては反映までに最大数分かかる場合があるため、自動デプロイ直後のFabricジョブ実行時にはリトライロジックを含めるのが安全です。