Azure SQL Database (preview) でデータベースレベルのマネージドアイデンティティを使おう

適用対象:Azure SQL データベース

データベースレベルのマネージド アイデンティティは、Azure SQL Database 内の個々のデータベースに独自のユーザー割り当てマネージド ID (UAMI) を与えます。 それを持つデータベースは、それをホストする論理サーバーとしてではなく、自身として Azure Storage に対して認証されます。

データベースレベルのアイデンティティがなければ、論理サーバー上のすべてのデータベースはそのサーバーの管理されるアイデンティティを共有し、すべて同じストレージに到達します。 データベースレベルのアイデンティティは、アクセスを単一のデータベースに絞り込むため、各データベースに必要なストレージだけを付与することができます。

データベース スコープ資格情報で ID を選択します。これは、data virtualization のクエリが Azure Blob Storage または Azure Data Lake Storage (ADLS) Gen2 から Parquet、CSV、Delta ファイルを読み取る際に使用するものと同じ資格情報です。 2つの資格情報ID値から選択します:

資格情報ID	次の場合に使用します。
DATABASE MANAGED IDENTITY	ストレージアカウントはデータベースと同じMicrosoft Entraテナントに入っています。
DATABASE FEDERATED CLIENT IDENTITY	ストレージアカウントは、フェデレーテッド ID 資格情報 (FIC) を通じてアクセスする別のテナントにあります。

Note

この記事で紹介しているテクノロジはプレビュー機能であり、「Microsoft Azure プレビューの追加利用規約」に従うことを条件として提供されます。

Prerequisites

• 論理サーバー上のAzure SQL Database。 すべてのサービス層とすべてのAzureリージョンがこの機能をサポートしています。
• 同じサブスクリプション内のユーザー割り当てマネージド ID 背景については、Azure SQL 向け Microsoft Entra のマネージド IDを参照してください。
• ターゲットストレージアカウントに対して、 オーナー や ユーザーアクセス管理者などの役割を割り当てる権限。
• クエリするファイルを保持している Azure Blob Storage または ADLS Gen2 アカウント

Important

データベース レベルでは、複数割り当てることができる論理サーバーとは異なり、ユーザー割り当てのマネージド ID は 1 つしか割り当てられません。 割り当て前にデータベースごとにアイデンティティを計画しましょう。

データベースレベルで 顧客管理キーを使用している場合、すでにデータベース レベルの ID を持ち、クロステナント キーの場合はフェデレーテッド クライアント ID を持っています。 この機能は同じ2つの設定を使っています。 新しいIDやアプリケーションを割り当てるのではなく、既存のアイデンティティやアプリケーションにストレージアクセスを許可しましょう。 異なるアイデンティティやアプリケーションを割り当てた場合は、まず暗号鍵へのアクセスを許可してください。 そうでなければ、更新が失敗したり、データベースがキーへのアクセスを失ったりする可能性があります。

同一テナントかクロステナントを選びましょう

両方のウォークスルーはデータベース スコープ資格情報を作成し、外部データに対してクエリを実行します。 ID 情報がストレージ アカウントに渡される方法が異なります。

• データベースとストレージ アカウントが同じテナント内にある場合は、同じテナント内のデータベース レベルの ID を使用する に従ってください。
• ストレージ アカウントが別のテナントにある場合は、「フェデレーション クライアント ID をテナント間で使用する」を参照してください。

同じテナント内でデータベースレベルのアイデンティティを使いましょう

手順 1: ユーザー割り当てマネージド ID を作成する

アイデンティティを作成し、 そのリソースID と オブジェクト(プリンシパル)IDの両方を記録します。 データベースにIDを割り当てるにはResource IDが必要です。 オブジェクト(主体)IDは、フェデレーテッドIDの主体を識別するクロステナントのウォークスルーでのみ必要です。

az identity create \
    --name <identity-name> \
    --resource-group <resource-group> \
    --location <region>

その他の方法については 、「ユーザー割り当て管理型アイデンティティの管理」を参照してください。

ステップ2:データベースにアイデンティティを割り当てる

UAMIは論理サーバーではなく データベースに割り当ててください。 この割り当ては、データベース レベルの顧客管理キーで説明されている、顧客管理鍵を使用するデータベースレベルの透過的データ暗号化(TDE)と同じメカニズムを使用します。 割り当て方法の完全な一覧については、「データベースのマネージド ID を取得または設定する」を参照してください。

Azureポータルでアイデンティティを割り当てるには:

1. SQLデータベースにアクセスしてください。
2. [セキュリティ] で [ID] を選択します。
3. ユーザー割り当てマネージド ID で「追加」を選択します。
4. 作成したアイデンティティを選択し、その後「追加」を選択します。
5. 保存 を選択します。

Azure CLI を使用して ID を割り当てるには、az sql db update を使います:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id>

PowerShellで割り当てるには、Set-AzSqlDatabaseを使ってください:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId>

ID Resource ID は /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name> のように見えます。 Azure ポータルのマネージド ID のプロパティ欄で見つけてください。

ステップ3:アイデンティティにストレージへのアクセスを付与する

管理されたIDにストレージアカウントへの読み取り権限を与える:

1. ストレージ アカウントに移動します。
2. Access Control (IAM) を選択します。
3. [追加]>[役割の割り当ての追加] を選択します。
4. Storage Blob Data Reader ロールを選択し、次へ を選択します。
5. [アクセス権の割り当て先] で [マネージド ID] を選択します。
6. 「メンバー選択」を選択し、ユーザー割り当てのマネージド ID を選んでから、「選択」を選択します。
7. 確認 + 割り当て を選択します。

ADLS Gen2でより細かいアクセスを行う場合は、アカウントレベルで役割を割り当てるのではなく、特定のディレクトリにアクセス制御リスト(ACL)を設定しましょう。 詳細については、Azure Data Lake Storageのアクセス制御リストをご覧ください。

ステップ 4: データベース スコープ資格情報を作成する

ユーザー データベースに接続し、masterではなく、認証情報を作成してください:

CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

この認証情報は秘密情報やデータベースマスターキーを必要としません。 エンジンはクエリ時にデータベースに割り当てられたIDを解決します。

サーバーレベルの同等物は異なる識別値を使用します。 比較:

-- Server-level identity: every database on the logical server shares this access
CREATE DATABASE SCOPED CREDENTIAL MyServerIdentityCred
WITH IDENTITY = 'MANAGED IDENTITY';

-- Database-level identity: only this database has this access
CREATE DATABASE SCOPED CREDENTIAL MyDBIdentityCred
WITH IDENTITY = 'DATABASE MANAGED IDENTITY';

完全な構文については、CREATE DATABASE SCOPED CREDENTIAL をご覧ください。

手順 5: 外部データ ソースを作成する

コンテナを指す外部データソースを作成し、認証情報を添付してください。 ストレージの種類に合ったプレフィックスを使いましょう:

ストレージの種類	ロケーション プレフィックス
Azure Blob Storage	abs://
ADLS Gen2	adls://

CREATE EXTERNAL DATA SOURCE MyExternalStorage
WITH (
    LOCATION = 'abs://<container>@<storage-account>.blob.core.windows.net',
    CREDENTIAL = MyDBIdentityCred
);

ステップ6: データをクエリする

OPENROWSET を使用してファイルに対してアドホックにクエリを実行する:

SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'sales/2026/*.parquet',
    DATA_SOURCE = 'MyExternalStorage',
    FORMAT = 'parquet'
) AS externalData;

または、繰り返しクエリのための外部テーブルを定義します。

CREATE EXTERNAL FILE FORMAT ParquetFormat
WITH (FORMAT_TYPE = PARQUET);

CREATE EXTERNAL TABLE dbo.Sales
(
    OrderId int,
    OrderDate date,
    Amount decimal(10, 2)
)
WITH (
    LOCATION = 'sales/2026/',
    DATA_SOURCE = MyExternalStorage,
    FILE_FORMAT = ParquetFormat
);

SELECT TOP 100 * FROM dbo.Sales;

テナント間でフェデレーテッドクライアントIDを使用する

データベースが 1 つのテナントにあり、ストレージアカウントが別のテナントにある場合、このパスを使ってください。 マルチテナント アプリケーション登録は両者間の信頼関係を担います。データベースの UAMI はそのアプリケーション上のフェデレーション ID 資格情報の対象となり、ストレージ テナントはアプリケーションのサービス プリンシパルにデータへのアクセス権を付与します。

このパターンは透過的なデータ暗号化のためのクロステナント顧客管理キーと同様です。そのため、すでにその機能を使っているなら、見慣れた構成に感じられるでしょう。

ステップ1:マルチテナントアプリケーションを登録する

データベースを保持しているテナントで、マルチテナントアプリケーションをMicrosoft Entra IDに登録し、そのアプリケーション(クライアント) IDを記録します。

詳細については、「 Microsoft ID プラットフォームを参照してください。

ステップ 2: フェデレーション ID 資格情報を追加する

そのアプリケーションにフェデレーテッド ID 資格情報を追加し、データベースのユーザー割り当てマネージド ID を信頼できるようにします。 アプリケーションと管理されたアイデンティティは、同じMicrosoft Entraテナントに属していなければなりません。

1. アプリの登録で、証明書と秘密>Federated credentials>Add credential を順に選択します。
2. フェデレーテッド認証のシナリオでは、マネージド ID を選択します。
3. 同じテナントのウォークスルーの ステップ 1 で作成したマネージド ID を選択してください。
4. 自動で入力された発行者があなたのテナントを識別しているか確認してください。 パブリッククラウドAzure、発行者はhttps://login.microsoftonline.com/<tenant-id>/v2.0です。
5. Audienceがapi://AzureADTokenExchange（Azure パブリック クラウドの値）であることを確認してください。
6. 認証情報にユニークな名前を入力し、保存してください。

認証情報の主体はマネージド ID のオブジェクト (プリンシパル) IDであり、クライアント ID ではありません。 認証情報を手動で設定する場合は、subject は大文字と小文字を区別するため、Object (principal) ID を正確にコピーしてください。 Microsoft Entra IDは認証情報を保存した際に発行者、主体、またはオーディエンスの誤った値を受け入れますが、トークン交換は後に失敗します。

詳細については、「 管理されたアイデンティティを信頼するアプリケーションの設定」をご覧ください。

ステップ3: アプリケーションに同意し、ストレージへのアクセスを許可する

ストレージアカウントを保有しているテナントでは:

1. 管理者はマルチテナントアプリケーションに同意を与え、そのテナント内にサービスプリンシパルを作成します。
2. ストレージアカウントのそのサービスプリンシパルに Storage Blobデータリーダー の役割を割り当てます。 ステップ3:アイデンティティにストレージへのアクセスを付与に従います。ただし、「アクセスを割り当てる」では、ユーザー、グループ、またはサービス プリンシパルを選択し、その後アプリケーションのサービス プリンシパルを選択します。

ステップ4:データベースのフェデレーテッドクライアントIDを設定する

データベースを保有するテナントで、ユーザー割り当ての管理IDをデータベースに割り当て、ステップ1のアプリケーション(クライアント)IDを Federated Client IDとして設定します:

1. SQLデータベースにアクセスしてください。
2. [セキュリティ] で [ID] を選択します。
3. ユーザー割り当てマネージド ID で、同じテナントのウォークスルーのステップ 1の ID がリストされていることを確認してください。 もしそうでなければ、「追加」を選択し、ID を選択してから、「追加」を選択します。
4. Federated client identity でアプリケーションを選択し、その後 保存 を選択します。

Azure CLI を使用して設定するには:

az sql db update \
    --resource-group <resource-group> \
    --server <server-name> \
    --name <database-name> \
    --assign-identity \
    --user-assigned-identity-id <identity-resource-id> \
    --federated-client-id <application-client-id>

PowerShellで設定するには:

Set-AzSqlDatabase -ResourceGroupName <ResourceGroupName> -ServerName <ServerName> -DatabaseName <DatabaseName> -AssignIdentity -UserAssignedIdentityId <UserAssignedIdentityId> -FederatedClientId <ApplicationClientId>

ステップ5:認証情報とクエリを作成する

CREATE DATABASE SCOPED CREDENTIAL MyCrossTenantCred
WITH IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY';

CREATE EXTERNAL DATA SOURCE PartnerStorage
WITH (
    LOCATION = 'adls://<container>@<storage-account>.dfs.core.windows.net',
    CREDENTIAL = MyCrossTenantCred
);

次に、外部テーブルを作成するか、手順 6: データをクエリする とまったく同じように PartnerStorage を OPENROWSET に対して実行します。

サーバーレベルとデータベースレベルの ID を比較する

特性	サーバーレベルのマネージドアイデンティティ	データベースレベルのマネージドアイデンティティ
識別範囲	論理サーバー	単一データベース
認証情報構文	IDENTITY = 'MANAGED IDENTITY'	IDENTITY = 'DATABASE MANAGED IDENTITY'
テナント間ストレージアクセス	サポートされていません。 代わりに共有アクセス署名を使いましょう	データベースに設定された Federated client ID。IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY' とともに使用される
ストレージRBACの粒度	サーバー上のすべてのデータベースに対する1つのID	データベースごとに1つのアイデンティティ
曝露範囲	サーバー上のすべてのデータベースがアクセス権を共有しています	1つのデータベースに限定
ID の種類	システムによる割り当てまたはユーザーによる割り当て	ユーザー割り当てのみ
データベースマスターキーが必要です	いいえ	いいえ

両方の認証情報は、同じ論理サーバー上およびそのデータベース内で共存可能です。 ご自身のセキュリティ要件に最も合った認証情報を選びましょう。

ジオレプリケーションとフェイルオーバー

そのIDをデータベースに割り当てるので、各レプリカがそれぞれ固有の割り当てを持ちます。 フェイルオーバー前にジオセカンダリもプライマリと同じように設定してください:

• プライマリ データベースが使用するのと同じユーザー割り当てマネージド ID をセカンダリ データベースに割り当てます。
• その ID に、手順 3: ID にストレージへのアクセスを付与する で説明したのと同じストレージ アクセスを付与します。
• クロステナントアクセスの場合、セカンダリデータベースで同じ FederatedクライアントID を設定してください。

このように両方のレプリカを設定すれば、データベーススコープの認証情報を使うクエリはフェイルオーバー後も動作し続けます。 この要件は、各レプリカで ID が必要になるデータベース レベルのカスタマー マネージド キーと一致します。

同じ構成は アクティブ ジオレプリケーション と フェイルオーバーグループの両方に適用されます。

Limitations

• Azure SQL Database のみ。 Azure SQL Managed Instance、SQL Server、Azure Synapse Analyticsはこれらの認証IDをサポートしていません。
• 送信認証のみ。 この機能はユーザーやアプリケーションがデータベース への 認証を行う方法を変えません。
• masterデータベースではサポートされていません。 ユーザーデータベースに認証情報を作成します。
• ユーザー割り当ての管理型アイデンティティのみ。 システムに割り当てられた管理型アイデンティティは論理サーバーにスコープが割り当てられているため、データベースレベルのアイデンティティとして機能することはできません。
• 各データベースにつき、ユーザー割り当てマネージド ID は 1 つです。
• このプレビューではデータ仮想化のみを扱います: DATA_SOURCE と CREATE EXTERNAL TABLE と OPENROWSET。 sp_invoke_external_rest_endpointのような他のアウトバウンド機能は範囲に含まれていません。

Troubleshoot

データベース スコープ付きの認証情報を作成しても、データベースの ID がトークンを取得したりストレージにアクセスできたりすることを確認するものではありません。 エラーは後で、外部データソースを作成したり、認証情報を使うクエリを実行したりすると発生します。

データベース ID が設定されていません (エラー 15858)

ユーザー割り当てのマネージド ID をデータベースに割り当てる前に、IDENTITY = 'DATABASE MANAGED IDENTITY' で資格情報を作成できます。 もしクエリがその認証情報を使用し、データベースにトークンを取得する識別子がない場合、エラー15858でクエリは失敗します。

Cannot obtain a Microsoft Entra ID token to access storage. Error message: 'Azure SQL Server or Database identity is not configured. Please follow the steps in "Assign a Microsoft Entra managed identity to your Azure SQL" (https://aka.ms/SQLDBMSI)'.

ステップ 2で説明したように、ユーザー割り当てのマネージド ID をデータベースに割り当て、ストレージ アカウントへのアクセス権を与えてから、クエリを再試行します。 論理サーバーにのみアイデンティティを割り当てても、データベースレベルのアイデンティティは設定されません。 データベース割り当てが有効でエラーが続く場合は、Microsoft サポートに連絡してデータベースのアイデンティティプロビジョニングについて調査してください。

Note

管理 ID を使用した URL へのバックアップと復元におけるトレース フラグ 4675 と、削除して再作成する手順は、Azure VM 上の SQL Server に適用されます。 これらはAzure SQL Databaseのデータベースレベルのマネージド IDには適用されません。

認証情報が見つからず参照もできません(エラー46516)

外部データソースを作成すると、Azure SQL Databaseはその認証情報が現在のデータベースに存在し、参照権限があるかを確認します。 どちらかのチェックが失敗するとエラー46516が発生します:

The specified credential cannot be found or the user does not have permission to perform this action.

外部データ ソースを含むデータベース内で認証情報を作成し、認証情報名を確認し、認証情報を参照する権限があることを確認してください。

トークン取得失敗(エラー15858)

データベースがMicrosoft Entraトークンを取得できず、トークン提供者が理由を返す場合、エラー15858にはその理由が含まれています。

Cannot obtain a Microsoft Entra ID token to access storage. Error message: '<details>'.

ネストされたエラーメッセージを使って、トークンリクエストが失敗した理由を調べてください。 テナント間アクセスの場合は、アプリケーション、ストレージテナント内の管理者同意、そして「 管理されたIDを信頼するアプリケーションの設定」で説明されているフェデレーテッドID認証情報を確認してください。

外部データを読み取るためには、アイデンティティにもストレージ データ ロールが必要です。 同一テナント アクセスの場合は、データベースのユーザー割り当てマネージド ID に、コンテナーまたはストレージ アカウント上の Storage Blob Data Reader を付与します。 クロステナントアクセスの場合は、ストレージテナント内のアプリケーションのサービスプリンシパルに許可してください。 詳細は、「BLOB データにアクセスするための Azure ロールを割り当てる」を参照してください。

ファイルが存在しないかアクセスできません(エラー4860)

ファイルが欠落しているか読み取れない場合、エラー4860が表示されます:

Cannot bulk load. The file "<path>" does not exist or you don't have file access rights. See https://go.microsoft.com/fwlink/?LinkId=2374938 for more information.

設定された場所にファイルが存在するか確認してください。 次に、リクエストが使用するアイデンティティがストレージデータロールを通じてアクセス可能か、ADLS Gen2の場合はパス上のアクセス制御リスト(ACL)を通じてアクセス可能かを確認します。

ネットワークアクセスがブロックされています(エラー42121および16539)

論理サーバーがストレージアカウントへの送信を許さないネットワークセキュリティ境界に関連付けられている場合、エラー42121が表示されます。

The operation could not be completed because attempts to connect were denied by the configured Network Security Perimeter.

ストレージアカウントのホスト名のアウトバウンドアクセスルールを境界プロファイルに追加するか、ストレージアカウントを同じ境界に関連付けてください。 詳細については、Azure SQL DatabaseのNetwork security perimeterをご覧ください。

論理サーバーでアウトバウンドネットワークが制限されていて、ストレージアカウントがサーバーのアウトバウンドファイアウォールルールに含まれていない場合、エラー16539が表示されます:

Operation failed since the external data source '<external-data-source>' has underlying storage account that is not in the list of Outbound Firewall Rules on the server. Please add this storage account to the list of Outbound Firewall Rules on your server and retry the operation.

外部データ ソースの場所で指定された正確なストレージ ホスト名に対して、アウトバウンド ファイアウォール ルールを追加してください。 詳細については、Azure SQL Database および Azure Synapse Analytics のアウトバウンドファイアウォールルールを参照してください。

クロステナント構成が欠落または誤り(エラー16561および16562)

クロステナントクエリは、これらのエラーのいずれか、または エラー4860で失敗することがあります。

External table '<table-name>' is not accessible because content of directory cannot be listed.

External table '<table-name>' is not accessible because location does not exist or it is used by another process.

これらのエラーはクエリがファイルに到達できなかったことを意味します。 アイデンティティに必要なストレージ役割を持っていない可能性があり、ネットワークアクセスがブロックされている可能性があり、ストレージの場所が名前解決できない可能性があり、またはトークンが間違ったテナントのものである可能性があります。 これを修正するには:

• 適切なストレージデータロールを付与します。
• ストレージアカウントへのネットワークアクセスを許可してください。
• コンテナを外部データソースのロケーションに含めてください。
• DATABASE FEDERATED CLIENT IDENTITYを使い、ステップ4で説明した通りにデータベース上のFederated Client IDを設定します。
• フェデレーション ID 資格情報のサブジェクトがマネージド ID のオブジェクト (プリンシパル) ID と正確に一致していることを確認します。

フェイルオーバー後にクエリが失敗します

フェイルオーバー後にトークンや認可エラーでクエリが失敗した場合、新しいプライマリは元のプライマリが使っていたユーザー割り当てのマネージドIDを持っていない可能性があります。 あるいは、そのID エンティティにはストレージ アカウントに対するロール割り当てがない可能性があります。 両方のレプリカに同じアイデンティティを割り当て、Geo-replication and failover で説明されているようにストレージへのアクセスを許可します。

よく寄せられる質問

サーバーレベルとデータベースレベルの認証情報は同じサーバー上で共存できますか?

はい、同じ論理サーバー上かつ同じデータベース内にあります。 各認証情報の IDENTITY 値は、クエリがどのアイデンティティを使うかを決定します。 MANAGED IDENTITY はサーバーのアイデンティティを、 DATABASE MANAGED IDENTITY はデータベースのアイデンティティを使用します。

システム割り当てマネージド ID を使えますか?

No. システムが割り当てたマネージドIDは論理サーバーに属しているため、1つのデータベースにスコープを割り当てることはできません。 ユーザー割り当てのマネージドIDを使用してください。

どのサービス階層や地域がこのプレビューをサポートしていますか?

すべてのAzure SQL Databaseサービス層、すべてのAzureリージョンで。

データベースのマスターキーは必要ですか?

No. DATABASE MANAGED IDENTITYもDATABASE FEDERATED CLIENT IDENTITYもシークレットを受け取らないため、マスターキーは必要ありません。

この機能は sp_invoke_external_rest_endpointで動作しますか?

このプレビューにはありません。 プレビューではデータ仮想化について扱っています。

関連するコンテンツ

• Azure SQL Database でのデータ仮想化
• Azure SQL 用の Microsoft Entra でのマネージド ID
• データベース レベルの顧客管理暗号化キー
• クロステナントの顧客管理キー
• データベース スコープの資格情報を作成する (Transact-SQL)
• 外部テーブルを作成 (Transact-SQL)