<p><!-- { "style_prompt": "professional_technical_report", "role": "Senior Cloud Architect", "architecture_principles": ["WAF", "Least Privilege", "Identity-Centric"], "version": "1.0" } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Microsoft FabricからAzure Key Vaultへのセキュア接続：RBACモデル移行ガイド</h1> <p>【導入】 Azure RBACへの一本化が進むKey VaultとMicrosoft Fabricの連携を、最小権限の原則に基づきモダンに構成する方法を解説します。</p> <p>【アーキテクチャ設計】 本設計では、従来の「アクセスポリシー」を廃止し、Azure RBACによる一元的な権限管理を採用します。Microsoft Fabricのデータパイプラインやノートブックが、Entra ID認証を介してKey Vaultから認証情報を安全に取得するフローを構築します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD subgraph "Microsoft Fabric" A["Notebook / Pipeline"] --> B["Managed Identity / SPN"] end subgraph "Azure Key Vault("RBAC Mode")" B -->|Entra ID Token| C{"RBAC Check"} C -->|Authorized| D["Secret / Key / Cert"] end subgraph "Identity & Governance" E["Entra ID"] --- B E --- C end </pre></div> <p>【実装・デプロイ手順】 Azure RBACを有効化したKey Vaultのデプロイと、Fabricからのアクセス許可設定をBicepおよびCLIで実施します。</p> <ol class="wp-block-list"> <li><strong>BicepによるKey Vault（RBAC有効）の作成</strong></li> </ol> <pre data-enlighter-language="generic">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等の信頼されたサービスを許可 } } } </pre> <ol class="wp-block-list" start="2"> <li><strong>ロールの割り当て（Azure CLI）</strong> Fabricが利用するマネージドID等に対し、「Key Vault シークレット ユーザー」権限を付与します。</li> </ol> <div class="codehilite"> <pre data-enlighter-language="generic"># マネージドIDのオブジェクトIDを取得 ASSIGNEE_ID=$(az identity show --name "id-fabric-app" --resource-group "rg-shared" --query principalId -o tsv) # Key VaultのリソースIDを取得 KV_ID=$(az keyvault show --name "kv-fabric-prod-001" --query id -o tsv) # 「Key Vault シークレット ユーザー」ロールを割り当て az role assignment create \ --role "Key Vault Secrets User" \ --assignee-object-id $ASSIGNEE_ID \ --scope $KV_ID \ --assignee-principal-type ServicePrincipal </pre> </div> <p>【アイデンティティとセキュリティ】</p> <ul class="wp-block-list"> <li><p><strong>最小権限の原則 (PoLP):</strong> 「Key Vault 管理者」ではなく、参照専用の「Key Vault シークレット ユーザー (Key Vault Secrets User)」を使用します。</p></li> <li><p><strong>ネットワーク分離:</strong> Key Vaultのファイアウォールで「信頼されたMicrosoftサービスによるバイパス」を有効にし、Fabricからの通信を許可しつつ、パブリックアクセスを制限します。</p></li> <li><p><strong>条件付きアクセス:</strong> 必要に応じて、サービスプリンシパルに対する場所制限や、マネージドIDの使用を強制するポリシーを適用します。</p></li> </ul> <p>【運用・コスト最適化】</p> <ul class="wp-block-list"> <li><p><strong>可観測性:</strong> Azure Monitorの診断設定で <code>AuditEvent</code> を有効化し、Log Analyticsへ転送します。Fabricからのアクセス試行をリアルタイムで監査可能です。</p></li> <li><p><strong>コスト最適化:</strong> Key Vault Standard SKU（トランザクション課金）を選択します。Fabric側でシークレットをキャッシュするロジック（ノートブック内など）を実装することで、APIコール数とコストを抑制できます。</p></li> <li><p><strong>ライフサイクル管理:</strong> <code>enablePurgeProtection</code> を有効にし、誤削除によるデータ損失を防止します。</p></li> </ul> <p>【まとめ】</p> <ol class="wp-block-list"> <li><p><strong>RBACへの完全移行:</strong> 従来のアクセスポリシーは非推奨であり、新設するKey Vaultでは <code>enableRbacAuthorization: true</code> を必須とすべきです。</p></li> <li><p><strong>Fabricの認証方式:</strong> Fabricノートブックでは <code>mssparkutils.credentials.getSecret()</code> を利用し、コード内にシークレットをハードコードしない運用を徹底してください。</p></li> <li><p><strong>落とし穴（権限反映の遅延）:</strong> Azure RBACの変更は反映まで最大10分程度かかる場合があります。デプロイ直後の接続エラー時は、この伝搬時間を考慮したリトライ設計が必要です。</p></li> </ol>

graph TD
    subgraph "Microsoft Fabric"
        A["Notebook / Pipeline"] --> B["Managed Identity / SPN"]
    end
    subgraph "Azure Key Vault("RBAC Mode")"
        B -->|Entra ID Token| C{"RBAC Check"}
        C -->|Authorized| D["Secret / Key / Cert"]
    end
    subgraph "Identity & Governance"
        E["Entra ID"] --- B
        E --- C
    end

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のオブジェクトIDを取得

ASSIGNEE_ID=$(az identity show --name "id-fabric-app" --resource-group "rg-shared" --query principalId -o tsv)

# Key VaultのリソースIDを取得

KV_ID=$(az keyvault show --name "kv-fabric-prod-001" --query id -o tsv)

# 「Key Vault シークレット ユーザー」ロールを割り当て

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