Azure Synapse Studioの開発者RBAC設計｜パイプライン実行は許可しつつLinked ServiceをUAMIで限定する最小権限ガイド

開発者に自由なブランチ運用とパイプラインの実行を許しつつ、実行に使える Linked Service をユーザー割り当てマネージド ID（UAMI）で厳密に限定したい——そのとき最も副作用が少ないのが「Synapse RBAC × Credential 単位の許可」を基軸にした最小権限アプローチです。本記事では、Synapse Studio での具体設定・運用設計・落とし穴・検証方法までを、一気通貫で解説します。

前提とゴール

本記事のユースケースは次のとおりです。

• 開発者には ブランチ作成／コード編集／削除 を許可し、Git ブランチでの開発を行う。
• パイプラインの実行（デバッグ／手動実行） も許可する。
• ただし、実行時に利用できる Linked Service は UAMI‑2 に紐づくものだけに限定し、UAMI‑1 に紐づく接続は使わせない。

ありがちな失敗は、ワークスペース全体に Synapse Artifact Publisher を付与してしまい、Credential レベルの制御が上書きされて すべての Linked Service が実行可能 になることです。ここを避ける設計が本記事の肝です。

解の全体像（最小権限アプローチ）

結論から言うと、次の 3 ロールを使い分けます。

目的	付与する RBAC ロール	スコープ	ポイント
Synapse Studio へのログインとプール参照	Synapse User	Workspace	画面閲覧・参照のみ。運用メンバー共通の最小ロール
コードの作成・編集・削除（Publish 権なし）	Synapse Artifact User	Workspace	Git ブランチでの開発用。Publish は CI/CD または管理者が実施
指定 Credential のみ実行可	Synapse Credential User	Workspace item → Credential → UAMI‑CRED‑2	UAMI‑CRED‑2 以外の Credential を使う接続は実行不可

Publish が必要な場合
・CI/CD 用サービス プリンシパルに Synapse Artifact Publisher を付与して自動 Publish。
・または カスタム ロール を作り、Artifact User に「Publish」相当の権限だけを粒度小さく追加。

役割分担と責務（組織設計に落とす）

チーム／プリンシパル	付与ロール	できること	できないこと
Developers（人）	Synapse User, Synapse Artifact User, Synapse Credential User（UAMI‑CRED‑2 スコープ）	Git での編集・Debug 実行・手動実行（UAMI‑2 のみ）	Publish、UAMI‑1 Credential の利用、ワークスペース MSI の濫用
CI/CD（SPN）	Synapse Artifact Publisher	PR マージ後に自動 Publish、リリースの反映	開発ブランチの編集、デバッグ実行
管理者	必要に応じて Synapse Administrator 等	ロール設計・監査・例外対応	日常の開発タスク

Linked Service 側の準備（データプレーン分離）

1. UAMI‑1 と UAMI‑2 を作成し、アクセス先を完全に分離します。たとえば UAMI‑1 は「広範」なストレージ、UAMI‑2 は「検証用コンテナー」のみにアクセス。
2. UAMI‑2 にのみ、ADLS Gen2 の対象コンテナー（またはフォルダー）へ Storage Blob Data Contributor など必要最小限の RBAC を付与します。
   アカウント全体ではなくコンテナー（あるいはパス）スコープに絞り、最小権限を徹底します。
3. Synapse Studio の Manage → Credentials で UAMI‑CRED‑2 を作成し、Linked Service を「ユーザー割り当てマネージド ID＝UAMI‑2」＋Credential＝UAMI‑CRED‑2 で構成します。

RBAC 設定の手順（ポータル／Studio での実装）

開発者グループへのロール付与

1. ワークスペースの Access control (IAM) で、開発者グループに Synapse User と Synapse Artifact User を付与します。
2. Credential UAMI‑CRED‑2 のスコープで、同グループに Synapse Credential User を付与します。
   （Synapse Studio から該当 Credential の権限設定画面で付与しても、Azure Portal の IAM からサブリソースとして付与しても構いません。）
3. Synapse Artifact Publisher を開発者に付与しないことを確認します。

CI/CD 用サービス プリンシパルへのロール付与

1. ワークスペースの Access control (IAM) で CI/CD の SPN に Synapse Artifact Publisher を付与します。
2. Publish は PR マージ時などに自動実行させ、責務分離とトレーサビリティを確保します。

なぜこの構成で動くのか（実行時の判定ロジック）

Synapse では、Credential は「実行時の最終ゲート」として動作します。つまり、パイプラインやノートブックが Linked Service を使って外部リソースへ接続するとき、呼び出し側にその Credential の Use（利用） 権限がなければ実行は失敗します。

局面	必要権限	判定	結果
Studio へのサインイン／参照	Synapse User	あり	OK（参照可）
ブランチでの編集・デバッグ	Synapse Artifact User	あり	OK（編集・Debug 実行可）
UAMI‑CRED‑2 を使う Linked Service での実行	Synapse Credential User（UAMI‑CRED‑2 スコープ）	あり	OK（実行可）
UAMI‑1 側 Credential を使う実行	Synapse Credential User（UAMI‑CRED‑1 スコープ）	なし	NG（認可エラーで失敗）
Publish（Live 反映）	Synapse Artifact Publisher など	開発者はなし／CI に付与	開発者は不可、CI が自動実施

逆に、開発者に Synapse Artifact Publisher をワークスペースで付与すると、Credential の参照権限まで広く与えられ、Credential レベルの制限が事実上無効化 されます。これが「全部の Linked Service が使えてしまう」根本原因です。

落とし穴と対処（チェックリスト）

• WorkspaceSystemIdentity にデータプレーン権限を付けない。 既定のワークスペース マネージド ID に広範なストレージ権限があると、Notebook やスクリプトから直接 ABFS でアクセスされる抜け道になります。
• Managed VNet＋データ流出防止を有効化し、許可された Managed Private Endpoint 以外へのアウトバウンドを遮断します。
• Storage 側はコンテナー／パス単位の RBAC＋ACL を併用。LS では防げないフォルダー粒度の制御を補完します。
• 「Trigger Now」は Live（発行済み）を実行。 開発者に Publish を与えない場合、Trigger Now は発行済みの接続だけを参照します。Debug 実行と使い分けを周知しましょう。
• Notebook／Spark の直書き認証を禁止。 共有キーや SAS を配布しない、ストレージの共有キー無効化、公開アクセス無効化など、データプレーンの抜け道を塞ぎます。

検証シナリオ（動作確認のすすめ）

1. テスト用 Linked Service を 2 つ作成：
   
   • LS‑UAMI2 … Credential＝UAMI‑CRED‑2、UAMI‑2 を使用（許可対象）
   • LS‑UAMI1 … Credential＝UAMI‑CRED‑1、UAMI‑1 を使用（禁止対象）
2. 同一パイプラインに 2 つの Copy Activity を置き、それぞれの Linked Service を参照。
3. 開発者権限で Debug 実行：LS‑UAMI2 のアクティビティのみ成功し、LS‑UAMI1 側は credential not authorized 系のエラーで失敗することを確認。
4. Publish は CI のみ可能であることを確認（開発者は Publish ボタンでエラー／権限不足）。

設定手順（詳細ガイド）

1. UAMI の作成とデータプレーン権限の分離

UAMI‑1／UAMI‑2 を作成し、ADLS Gen2 などのデータソースで UAMI‑2 のみ対象コンテナーに Storage Blob Data Contributor を割り当てます。可能であればフォルダー単位の ACL を追加し、不要なパスを閉じます。

2. Credential と Linked Service の作成

1. Synapse Studio の Manage → Credentials から UAMI‑CRED‑2 を追加（ユーザー割り当て ID＝UAMI‑2）。
2. Linked Service（例：ADLS2 への接続）で Authentication＝Managed Identity を選び、Credential＝UAMI‑CRED‑2 を指定。

3. RBAC の付与

1. Workspace に対し、開発者グループへ Synapse User と Synapse Artifact User を割り当て。
2. Credential UAMI‑CRED‑2 へ、同グループに Synapse Credential User を割り当て。

4. CI/CD と Publish 運用

AzDO／GitHub Actions 等のパイプラインで Publish を自動化し、人手での誤発行を排除します。ブランチポリシー（必須レビュー、ビルド検証）を組み合わせ、発行物の品質とトレーサビリティを担保します。

コマンド例（Azure CLI／PowerShell）

以下は代表的なコマンド例です。環境に合わせてリソース ID を置き換えてください。

Azure CLI

# 変数
SUB=<subscriptionId>
RG=<resourceGroup>
WS=<synapseWorkspaceName>
DEV_GROUP_OBJECT_ID=<developersGroupObjectId>
CI_SPN_OBJECT_ID=<ciServicePrincipalObjectId>

# ワークスペースのリソースID取得

WS_ID=$(az synapse workspace show -n $WS -g $RG --query id -o tsv)

# 開発者に Synapse User / Artifact User を付与（Workspace スコープ）

az role assignment create --assignee $DEV_GROUP_OBJECT_ID --role "Synapse User" --scope $WS_ID
az role assignment create --assignee $DEV_GROUP_OBJECT_ID --role "Synapse Artifact User" --scope $WS_ID

# Credential スコープで Synapse Credential User を付与

CRED_SCOPE="/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Synapse/workspaces/$WS/credentials/UAMI-CRED-2"
az role assignment create --assignee $DEV_GROUP_OBJECT_ID --role "Synapse Credential User" --scope $CRED_SCOPE

# CI/CD サービスプリンシパルに Artifact Publisher を付与

az role assignment create --assignee $CI_SPN_OBJECT_ID --role "Synapse Artifact Publisher" --scope $WS_ID

# ADLS Gen2 の対象コンテナーに UAMI‑2 を付与（例）

SA=
CONTAINER=
UAMI2_PRINCIPAL_ID=$(az identity show -g $RG -n UAMI-2 --query principalId -o tsv)
CONTAINER_SCOPE="/subscriptions/$SUB/resourceGroups/$RG/providers/Microsoft.Storage/storageAccounts/$SA/blobServices/default/containers/$CONTAINER"
az role assignment create --assignee-object-id $UAMI2_PRINCIPAL_ID --assignee-principal-type ServicePrincipal 
--role "Storage Blob Data Contributor" --scope $CONTAINER_SCOPE 

PowerShell

$sub = "<subscriptionId>"
$rg  = "<resourceGroup>"
$ws  = "<synapseWorkspaceName>"
$devGroup = "<developersGroupObjectId>"
$ciSpn    = "<ciServicePrincipalObjectId>"

$wsObj = Get-AzSynapseWorkspace -Name $ws -ResourceGroupName $rg
$wsId  = $wsObj.Id

# Workspace ロール

New-AzRoleAssignment -ObjectId $devGroup -RoleDefinitionName "Synapse User" -Scope $wsId
New-AzRoleAssignment -ObjectId $devGroup -RoleDefinitionName "Synapse Artifact User" -Scope $wsId

# Credential ロール

$credScope = "/subscriptions/$sub/resourceGroups/$rg/providers/Microsoft.Synapse/workspaces/$ws/credentials/UAMI-CRED-2"
New-AzRoleAssignment -ObjectId $devGroup -RoleDefinitionName "Synapse Credential User" -Scope $credScope

# CI/CD ロール

New-AzRoleAssignment -ObjectId $ciSpn -RoleDefinitionName "Synapse Artifact Publisher" -Scope $wsId 

「Publish せずに実行だけ」させる運用のポイント

• Debug を主に使わせる：ブランチ上のパイプラインをデバッグ実行。Credential の「Use」判定は Debug 実行でも適用されるため、UAMI‑CRED‑2 のみ通過します。
• 手動実行（Trigger Now）の扱い：Publish 済みオブジェクトが対象。開発者が Publish 権を持たなければ、誤発行や意図しない接続の Live 実行を防げます。
• 環境分離：同一ワークスペースでも UAMI と Credential の分離で制御可能ですが、リリースフローが重くなる場合は Dev / Test / Prod でワークスペース自体を分離し、CI/CD で横展開する設計が堅牢です。

セキュリティ強化のベストプラクティス

• WorkspaceSystemIdentity へ付与しない：既定 MSI にストレージや Key Vault のデータ権限を与えない。Notebook 経由の直アクセス防止に有効です。
• Managed Private Endpoint のみ許可：Managed VNet 化して、データソースへの到達経路を MPE に限定。未知の外部宛てアウトバウンドは禁止。
• Storage の共有キー無効化・SAS 発行の統制：共有キー／アカウントキーを使う認証経路を遮断し、Azure AD（RBAC）に一本化します。
• フォルダー ACL の併用：RBAC で「どの ID が使えるか」を縛り、ACL で「どのパスに触れるか」を二段階で縛ると強い。
• ロール付与の自動化：CLI／IaC でロールを一貫適用。手作業での付与漏れ・過剰付与を避けます。

よくある質問（FAQ）

Q. パイプラインやノートブック単位で RBAC は設定できる？ A. 現状は不可です。Git ブランチ運用＋Artifact User でコード領域を分離し、実行時は Credential の Use 権限 で接続先を制御するのが実践解です。

<dt>Q. 開発者が新しい Linked Service を勝手に作り、UAMI‑2 を指定してしまったら？</dt>
<dd>A. UAMI‑2 側のデータプレーン権限を必要最小に絞り、Publish を CI のみ許可することで、Live への混入を防げます。Debug 実行は通過しますが、触れるデータは RBAC/ACL で限定されています。</dd>

<dt>Q. Synapse Artifact Publisher を付けると何が危ない？</dt>
<dd>A. Publisher には広い参照権限が含まれ、<strong>Credential レベルの制限が上書き</strong>されやすくなります。運用上は CI/CD のみへ付与し、人には付けないのが鉄則です。</dd>

<dt>Q. Notebook から ABFS 直打ちでデータに触られない？</dt>
<dd>A. 既定 MSI に権限を付けない、Managed VNet＋MPE、ストレージ側の共有キー無効化・SAS 統制で実質的な抜け道を封鎖できます。</dd>

<dt>Q. Data Flow でも同じ制御は効く？</dt>
<dd>A. はい。Data Flow も接続は Linked Service 経由です。実行時に Credential の Use 権限が検査されます。</dd>

<dt>Q. さらに細かく制御したい</dt>
<dd>A. フォルダー ACL の併用、環境ごとの UAMI／Credential を増やす、パスごとに Linked Service を分けるなどのパターンで粒度を下げられます。</dd>

運用テンプレート（サンプル）

ブランチ／ロール運用の一例

ブランチ	誰が作業	権限	Publish
feature/*	開発者	Synapse Artifact User + Credential User（UAMI‑CRED‑2）	不可（Debug のみ）
develop	開発リード	同上	不可（CI のみ）
main	CI	Artifact Publisher（SPN）	自動（PR マージ時）

CI/CD の概念 YAML（疑似例）

trigger:
  branches: [ main ]

stages:

* stage: Build
  jobs:

  * job: Validate
    steps:

    * script: echo "Validate Synapse artifacts (lint/test)"
* stage: Release
  jobs:

  * job: PublishToSynapse
    steps:

    * task: SynapseWorkspaceDeployment@1
      inputs:
      workspaceName: $(SYNAPSE_WS)
      environment: 'prod'
      overrideArmTemplateParameters: '-workspaceName $(SYNAPSE_WS)'
      authenticationType: 'spnKey' # SPN は Artifact Publisher 付与 

監査とガバナンスのヒント

• 権限差分の定期棚卸し：開発者グループや SPN に意図しない Publisher や管理者ロールが付いていないか点検します。
• 発行トレースの可視化：Publish を CI 経由に限定すると、誰が・いつ・何を反映したかがログで明確になります。
• 命名規約：UAMI-<env>-<purpose>、UAMI-CRED-<env>-<purpose> のように揺れない命名で把握性を上げます。

まとめ

Synapse Studio で「開発は自由、実行は制限付き」を成立させる鍵は、Artifact User で開発面を開きつつ、Credential（UAMI‑CRED‑2）への Use 権限だけを開発者に与えるという分離にあります。Publish は CI/CD に集約し、Synapse Artifact Publisher を人に配らない。さらにワークスペース既定の MSI はデータプレーン権限を持たせず、Managed VNet／MPE、Storage RBAC＋ACL を組み合わせることで、不要なデータソース接触のリスクを実用的に排除できます。

付録：運用チェックリスト

• 開発者：Synapse User／Artifact User（Workspace）＋ Credential User（UAMI‑CRED‑2）
• CI（SPN）：Artifact Publisher（Workspace）
• WorkspaceSystemIdentity：データプレーン権限なし
• UAMI‑2：対象コンテナーの最小権限のみ
• Managed VNet＋MPE：有効
• Storage：共有キー無効化、SAS 統制、パス ACL 適用
• Publish：CI のみ、PR ベース、ログ保全