Azure RBAC移行に伴うMicrosoft FabricからのKey Vaultシークレット取得構成ガイド

Tech

META

  • version: 1.0

  • context: Senior Cloud Architect

  • target: Azure/Fabric Administrators

  • key_elements: Azure RBAC, Microsoft Fabric, Azure Key Vault, Managed Identity

  • delivery_style: Technical Solution Architect Document

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

Azure RBAC移行に伴うMicrosoft FabricからのKey Vaultシークレット取得構成ガイド

【導入】 Azure Key Vaultのアクセス制御をRBACへ統合し、Microsoft Fabricのデータパイプラインにおけるセキュアな認証管理を実現します。

【アーキテクチャ設計】 本構成では、従来の「アクセスポリシー」モデルから、より粒度の細かい制御が可能な「Azure RBAC」モデルへ移行します。Microsoft FabricのワークスペースID（Managed Identity）に対して、Key Vault内の特定のシークレットに対する「Key Vault Secrets User」ロールを付与することで、セキュアな資格情報取得を可能にします。

graph LR
    subgraph "Microsoft Fabric"
        A["Notebook / Data Factory"] --> B["Workspace Managed Identity"]
    end
    subgraph "Azure Entra ID"
        B --> C["Token Request"]
    end
    subgraph "Azure Key Vault("RBAC Model")"
        C --> D["Role Check: Key Vault Secrets User"]
        D --> E["Secret Value"]
    end
    E --> A

【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultのデプロイと、Fabricからのアクセス権限付与の手順を示します。

  1. BicepによるKey Vaultのデプロイ（RBAC有効化）
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モデルを強制
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
  }
}
  1. Azure CLIによるロール割り当て FabricのワークスペースManaged Identityに対して権限を付与します。
# 変数設定

KV_NAME="kv-fabric-prod-001"
ASSIGNEE_ID="<Fabric-Workspace-Identity-ID>"
ROLE="Key Vault Secrets User"

# ロール割り当ての実行

az role assignment create \
    --role "$ROLE" \
    --assignee-object-id "$ASSIGNEE_ID" \
    --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/$KV_NAME" \
    --assignee-principal-type ServicePrincipal

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

  • 認証モデルの統一: アクセスポリシー（Vault全体への権限）ではなく、RBACを使用することで「特定のシークレットのみ」へのアクセス許可を付与する最小権限の原則（PoLP）を適用します。

  • ネットワークセキュリティ: FabricからKey Vaultへのアクセスは、Fabricの「信頼されたサービス」設定または「Managed Private Endpoint」を使用して、パブリックインターネットを経由しない通信経路を確立することを推奨します。

  • 条件付きアクセス: サービスプリンシパルに対する場所制限などの条件付きアクセスポリシーを適用し、認証の境界を強化します。

【運用・コスト最適化】

  • 可観測性: Azure Monitorの診断設定を有効にし、AuditEventをLog Analyticsへ送信します。RBAC移行後は、誰がどの権限でシークレットにアクセスしたかが「AzureActivity」ログおよびKey Vaultログの両面から追跡可能になります。

  • コスト最適化: Key VaultのStandard SKUはトランザクションベースの課金です。Fabricの各ノードが個別にシークレットを取得するのではなく、トークンのキャッシュや、Fabric環境変数への一時的な保持を検討し、APIコール数を抑制します。

【まとめ】

  1. RBAC反映の遅延: ロール割り当て後、反映までに最大5〜10分程度のキャッシュ遅延が発生する可能性があるため、CI/CDパイプライン設計時に注意が必要です。

  2. アクセスポリシーの廃止: RBACモデルに切り替えると、既存のアクセスポリシーは無視されます。移行時は既存アプリケーションの権限不足が発生しないよう、事前に一括でロール割り当てを行う必要があります。

  3. Fabric IDの特定: Microsoft FabricのManaged Identityはワークスペースごとに作成されるため、環境（Dev/Prod）ごとに適切な識別子をKey Vault側に登録する運用フローを確立してください。

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

コメント

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