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

Tech

Cloud: Azure, Microsoft Fabric Identity: Entra ID (Azure AD), Managed Identity, RBAC Security: Azure Key Vault (RBAC Mode) IaC: Bicep

  • Professionalism: Senior Architect

  • Technical Accuracy: High (Based on Azure Learn & Fabric documentation)

  • Formatting: Structured with Mermaid and Code Blocks

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

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

【導入】 FabricワークスペースとKey VaultをRBACで統合し、レガシーなアクセス権限モデルから脱却した安全なデータパイプライン管理を実現します。

【アーキテクチャ設計】 本構成では、従来の「Key Vault アクセス ポリシー」を廃止し、Azure RBAC（ロールベースのアクセス制御）を全面的に採用します。Microsoft Fabricのワークスペース ID（マネージド ID）に対して、特定のシークレットへの参照権限のみを付与することで、最小特権の原則を適用します。

graph TD
    subgraph "Microsoft Fabric"
        A["Data Factory / Notebook"] --> B["Workspace Identity"]
    end
    subgraph "Azure Environment"
        B -->|Entra ID Auth| C{"Azure Key Vault"}
        C -->|RBAC Check| D["Secret: DB Connection String"]
        E["Security Admin"] -->|Assign Role| B
    end
    subgraph "Permissions"
        F["Key Vault Secrets User"] -.-> B
    end

この設計により、個別のサービスプリンシパルのシークレット管理が不要になり、すべての認証がEntra ID（旧Azure AD）に統合されます。

【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultのデプロイと、FabricワークスペースIDへの権限付与をBicepで実行します。

  1. Azure Key Vaultのデプロイ (Bicep) enableRbacAuthorization: true を設定することが重要です。
resource vault '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モードを強制
    accessPolicies: [] // アクセスポリシーは空にする
  }
}
  1. FabricワークスペースIDの確認と権限付与 Fabricワークスペース設定で「ワークスペース ID」を有効化した後、そのオブジェクトIDに対して「Key Vault シークレット ユーザー」ロールを割り当てます。
# FabricワークスペースのマネージドIDのオブジェクトIDを取得（ポータルまたはAPI経由）

ASSIGNEE_OBJ_ID="<Fabric-Workspace-Identity-Object-ID>"
SCOPE="/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/kv-fabric-prod-001"

# ロール割り当て (Key Vault シークレット ユーザー)

az role assignment create \
    --role "Key Vault Secrets User" \
    --assignee-object-id $ASSIGNEE_OBJ_ID \
    --assignee-principal-type ServicePrincipal \
    --scope $SCOPE

【アイデンティティとセキュリティ】

  • 権限モデルの移行: 従来のアクセスポリシーは「コンテナーレベル」での権限付与でしたが、Azure RBACでは「シークレット単位」での権限付与が可能です。Fabricの特定のジョブのみが特定の接続文字列を読み取れるよう制御を細分化してください。

  • 信頼されたサービス: Key Vaultのファイアウォール設定で「信頼された Microsoft サービスがこのファイアウォールをバイパスすることを許可する」を有効にすることで、Fabricからのセキュアな通信を維持しつつパブリックアクセスを制限できます。

【運用・コスト最適化】

  • 可観測性: Azure Monitorの診断設定で AuditEvent を有効化し、FabricのワークスペースIDによるシークレットへのアクセスログをLog Analyticsで監視します。

  • コスト: Key Vault Standard SKUは、シークレットのトランザクション数に基づいた課金（$0.03/10,000操作）であるため、Fabricからのポーリング頻度を制御することでコストを抑制できます。

【まとめ】

  1. RBACへの完全移行: アクセスポリシーとの混在を避け、enableRbacAuthorization: true を明示してガバナンスを統一する。

  2. ワークスペースIDの活用: Fabric側でマネージドID（Workspace Identity）を有効化し、資格情報（Client Secret）の埋め込みを排除する。

  3. 伝播の遅延（注意点）: RBACの割り当ては反映までに最大10分程度の遅延が発生する場合があるため、自動デプロイ直後のFabricジョブ実行にはリトライ処理を組み込むことが推奨されます。

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

コメント

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