[STYLE: PROFESSIONAL_ARCHITECT] [TONE: LOGICAL] [TARGET: DEVOPS_ENGINEER] [TECH: AZURE_FABRIC_RBAC]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Azure Key Vault RBAC移行に伴うMicrosoft Fabricからのセキュアなシークレット統合設計
Azure RBAC移行による権限管理の統合と、Microsoft Fabricからのシークレット取得における最小権限原則の実装を解説します。
【アーキテクチャ設計】
Azure Key Vault (AKV) のアクセス制御モデルを従来の「アクセスポリシー」から「Azure RBAC」に移行することで、コントロールプレーンとデータプレーンの権限を一元管理できます。Microsoft Fabricからのアクセスでは、ワークスペース ID (Workspace Identity) または サービスプリンシパル を使用し、AKVに対して特定のロールを割り当てます。
graph TD
subgraph "Microsoft Fabric"
A["Notebook / Data Factory"] --> B["Workspace Identity"]
end
subgraph "Azure Environment"
B -->|Authentication| C["Microsoft Entra ID"]
C -->|Access Token| D["Azure Key Vault"]
subgraph "Access Control (RBAC)"
E["Key Vault Secrets User"] -.->|Assign to| B
end
D -->|Secret Value| A
end
style E fill:#f9f,stroke:#333,stroke-width:2px
構成コンポーネントの役割
Microsoft Fabric ワークスペース ID: 各ワークスペースに紐づくマネージド ID。外部リソースへの認証に使用します。
Azure Key Vault (RBACモード):
Microsoft.KeyVault/vaults/secrets/getSecret/actionなどのアクションをRBACで制御。Key Vault Secrets User: シークレットの読み取りのみを許可する最小権限ロール。
【実装・デプロイ手順】
1. Azure Key Vault の RBAC 有効化と作成
Azure CLI を使用して、RBAC 認証を既定とした Key Vault を作成します。
# 変数定義 RESOURCE_GROUP="rg-fabric-prod" LOCATION="japaneast" KV_NAME="kv-fabric-secrets-001" # RBAC 認証モデルを有効にして Key Vault を作成 az keyvault create \ --name $KV_NAME \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --enable-rbac-authorization true
2. Fabric ワークスペース ID への権限付与
Fabric ワークスペースの設定から「ワークスペース ID」を有効化した後、その ID に対してロールを割り当てます。
# Fabric ワークスペース ID (ObjectId) の取得 # ※実際には Fabric 管理画面または API から取得した ID を使用 FABRIC_WS_ID="<Fabric-Workspace-Identity-Object-ID>" # Key Vault Secrets User ロールの割り当て az role assignment create \ --role "Key Vault Secrets User" \ --assignee $FABRIC_WS_ID \ --scope "/subscriptions/<Sub-ID>/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KV_NAME"
3. Fabric Notebook でのシークレット取得 (PySpark)
mssparkutils を使用して、安全にシークレットを呼び出します。
# Fabric Notebook 内での実装例 from notebookutils import mssparkutils key_vault_name = "kv-fabric-secrets-001" secret_name = "db-password" # RBAC 権限がある場合、このメソッドでシークレットを取得可能 # ※バックエンドでワークスペース ID のトークンが使用される secret_value = mssparkutils.credentials.getSecret(key_vault_name, secret_name) print(f"Secret retrieved successfully.")
【アイデンティティとセキュリティ】
最小権限原則の徹底: 開発者には
Key Vault Secrets Officerを付与せず、実行環境（Fabric ID）にのみKey Vault Secrets Userを付与します。条件付きアクセス (CA): Fabric からのアクセスを特定のネットワーク（信頼された Microsoft サービス）または特定の IP 範囲に制限するよう、Microsoft Entra ID 側で構成します。
シークレットの有効期限: 全てのシークレットに
exp(有効期限) を設定し、Azure Advisor または Microsoft Defender for Cloud で期限切れ間近の通知を構成します。
【運用・コスト最適化】
可観測性:
- Azure Monitor の診断設定で「AuditEvent」を Log Analytics に送信します。誰が（Fabric ID）いつシークレットにアクセスしたかをクエリ可能です。
SKU選択:
- 通常のシークレット管理であれば Standard SKU で十分です。HSM による物理的な保護が必要な場合のみ Premium を選択しますが、トランザクションあたりのコストが増加するため注意が必要です。
スロットリング対策:
- Fabric の大規模な並列ジョブから同時にアクセスする場合、Key Vault のサービス制限（10秒あたり最大2,000トランザクション）に達する可能性があります。リトライロジックの実装を検討してください。
【まとめ】
RBAC への完全移行: 従来のアクセスポリシーは、リソースレベルでの一括権限付与しかできず、管理が煩雑でした。RBAC 移行により、シークレット個別の細かな制御が可能になります。
ワークスペース ID の活用: サービスプリンシパルのシークレット（Client Secret）を Fabric 側に持たせる必要がなくなり、認証情報の管理漏洩リスクを排除できます。
ネットワーク境界の注意点: Fabric はマルチテナントサービスであるため、Key Vault のファイアウォールで「信頼された Microsoft サービスによるこのファイアウォールのバイパスを許可する」を有効にする必要があります。
