{ “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 またはシークレット単位でスコープを絞り込み、爆発半径を最小化してください。

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

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

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

いいね:

コメント

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

共有:

いいね:

コメント