Azure Key Vault RBAC移行とMicrosoft Fabricによるセキュアなシークレット取得構成

Tech

{ “profile”: “senior_cloud_architect”, “topic”: “AKV_RBAC_Migration_Fabric_Integration”, “status”: “draft”, “framework”: “Azure_Well_Architected”, “tooling”: [“Azure CLI”, “Bicep”, “Microsoft Fabric”] }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

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ジョブ実行時にはリトライロジックを含めるのが安全です。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました