[PLAN]

シナリオ：Microsoft FabricからAzure Key Vault (AKV) のシークレットを安全に取得するため、従来の「アクセスポリシー」から「Azure RBAC」への完全移行を前提とした設計。
技術スタック：Azure Key Vault (RBAC有効), Microsoft Fabric (Managed Identity), Bicepによるプロビジョニング。
セキュリティ：最小権限の原則（PoLP）に基づき、特定のシークレット参照権限のみをFabricのワークスペースIDに付与。
運用：Azure Monitorとの統合によるシークレットへのアクセス監査。

[RESEARCH]

Azure Key Vaultは現在、新規作成時にAzure RBACを推奨。
Microsoft Fabricはワークスペースレベルで「Managed Identity」をサポートしており、これを用いてAKVへの認証を行うのがベストプラクティス。
RBACモデルでは「Key Vault Secrets User」ロールが必要。

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

Fabric×Key Vault：Azure RBACモデルによる次世代シークレット管理の実装ガイド

【導入】 FabricワークスペースのマネージドIDとAzure RBACを統合し、レガシーなアクセスポリシーを排除したセキュアな認証基盤を構築します。

【アーキテクチャ設計】本構成では、Microsoft FabricのワークスペースIDを信頼されたエンティティとしてAzure Key Vaultに登録します。従来のアクセスポリシーモデルとは異なり、Azureの共通管理プレーン（RBAC）で権限を一元化することで、ガバナンスの向上と設定ミスによる露出リスクを低減します。

graph TD
    subgraph Microsoft Fabric
        A["Data Factory / Notebook"] --> B["Workspace Managed Identity"]
    end
    subgraph Azure Platform
        B -->|Entra ID Auth| C["Azure Key Vault"]
        C -->|RBAC Check| D{"Key Vault Secrets User"}
        D -->|Allow| E["Secret Value"]
    end
    F[Admin/Dev] -->|Control Plane| C

【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultの作成と、Fabricへの権限割当をBicepで自動化します。

Azure 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 // RBACモデルを強制
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
    }
  }
}

FabricマネージドIDへのロール割当 (CLI) FabricワークスペースのID（Principal ID）に対し、「Key Vault シークレットユーザー」ロールを付与します。

# FabricワークスペースのIDを変数に格納

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

# ロール割り当ての実行 (Key Vault Secrets User)

az role assignment create \
    --role "Key Vault Secrets User" \
    --assignee $FABRIC_ID \
    --scope $KV_SCOPE

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

認証モデルの移行: 従来の「Vaultアクセスポリシー」を無効化（enableRbacAuthorization: true）し、Entra IDによる一元的な監査を可能にします。
最小権限の原則: Fabric側には「Key Vault Secrets User」のみを付与し、シークレットの削除や管理権限（Admin）を分離します。
条件付きアクセス: 信頼された場所からのアクセスのみを許可するポリシーをEntra ID側で適用し、Fabricの実行環境以外からのトークン利用を制限します。

【運用・コスト最適化】

可観測性: Azure Monitor の診断設定で AuditEvent を有効化し、Log Analytics ワークスペースへ転送します。誰が、いつ、どのシークレットを取得したかをリアルタイムで監視します。
コスト:
- SKU選択: Fabricからの参照頻度が低い（バッチ処理等）場合は「Standard」SKUで十分です。HSM（FIPS 140-2 Level 3）が必要な要件のみ「Premium」を選択してください。
- トランザクションコスト: Key Vaultはリクエスト数に応じた課金であるため、Fabric Notebook内での頻繁なループ内取得を避け、キャッシュ戦略（Lazy Load）を推奨します。

【まとめ】

RBACへの完全移行: Fabricとの連携ではアクセスポリシーを「オフ」にし、Azure RBACを「オン」にすることがセキュリティ標準。
ワークスペースIDの活用: 個人のユーザーアカウントではなく、Fabricワークスペース固有のマネージドIDに権限を紐付ける。
落とし穴の回避: RBAC反映には数分の遅延があるため、デプロイ直後のFabricジョブ実行エラーにはリトライ処理を組み込むこと。

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

Fabric×Key Vault：Azure RBACモデルによる次世代シークレット管理の実装ガイド

Fabric×Key Vault：Azure RBACモデルによる次世代シークレット管理の実装ガイド

いいね:

コメント

Fabric×Key Vault：Azure RBACモデルによる次世代シークレット管理の実装ガイド

共有:

いいね:

コメント