Azure SQL Database (preview)에서 데이터베이스 수준 관리 ID를 사용하세요

적용 대상:Azure SQL 데이터베이스

데이터베이스 수준 관리 ID는 Azure SQL Database 내 개별 데이터베이스에 자체 사용자 할당 관리 ID(UAMI)를 부여합니다. 하나가 있는 데이터베이스는 Azure Storage를 호스팅하는 논리적 서버가 아니라 자기 자신으로 인증합니다.

데이터베이스 수준의 신원이 없으면, 논리 서버의 모든 데이터베이스는 해당 서버의 관리 신원을 공유하여 모두 같은 저장소에 도달합니다. 데이터베이스 수준의 ID는 그 접근을 단일 데이터베이스로 좁혀 각 데이터베이스에 필요한 저장 공간만 부여할 수 있습니다.

데이터베이스 범위가 지정된 자격 증명에서 신원을 선택하는데, 이 자격 증명은 데이터 가상화 쿼리가 Azure Blob Storage 또는 Azure Data Lake Storage (ADLS) Gen2에서 Parquet, CSV, Delta 파일을 읽는 데 사용하는 동일한 자격 증명입니다. 두 가지 자격 증명 신원 값 중 하나를 선택하세요:

자격 증명 식별자	사용해야 하는 경우
`DATABASE MANAGED IDENTITY`	스토리지 계정은 데이터베이스와 동일한 Microsoft Entra 테넌트에 속해 있습니다.
`DATABASE FEDERATED CLIENT IDENTITY`	스토리지 계정은 다른 테넌트에 있으며, 연합 신원 자격 증명(FIC)을 통해 접근됩니다.

Note

미리 보기 기능으로, 이 문서에 제시된 기술에는 Microsoft Azure 미리 보기에 대한 보충 사용 약관이 적용됩니다.

Prerequisites

논리 서버 위의 Azure SQL Database. 모든 서비스 계층과 모든 Azure 지역이 이 기능을 지원합니다.
동일한 구독의 사용자 할당 관리 ID 배경 설명은 Managed identities in Microsoft Entra for Azure SQL 참조하세요.
대상 스토리지 계정에 대해 소유자 또는 사용자 접근 관리자와 같은 역할을 할당할 수 있는 권한.
쿼리하려는 파일을 보관하는 Azure Blob Storage 또는 ADLS Gen2 계정.

Important

데이터베이스는 데이터베이스 수준에서 사용자 할당 관리 신원이 하나만 할당될 수 있으며, 논리 서버는 여러 개를 가질 수 있습니다. 할당하기 전에 데이터베이스별로 ID를 계획하세요.

데이터베이스가 데이터베이스 수준에서 고객 관리 키를 사용한다면, 이미 데이터베이스 수준 ID를 가지고 있으며, 크로스 테넌트 키의 경우 연합된 클라이언트 ID가 있습니다. 이 기능은 같은 두 가지 설정을 사용합니다. 기존 신원이나 애플리케이션에 저장 권한을 부여하세요. 새로운 신원이나 애플리케이션을 할당하는 대신에요. 다른 신원이나 애플리케이션을 할당했다면, 먼저 암호화 키에 대한 접근 권한을 부여하세요. 그렇지 않으면 업데이트가 실패하거나 데이터베이스가 해당 키에 액세스할 수 없게 될 수 있습니다.

동일 임차인(동일 임차인) 또는 교차 임차인을 선택하세요

두 워크스루 모두 데이터베이스 범위 자격 증명을 생성하고 외부 데이터를 조회합니다. 신원이 스토리지 계정에 도달하는 방식이 다릅니다.

데이터베이스와 스토리지 계정이 같은 테넌트에 있다면 같은 테넌트 내에서 데이터베이스 수준 신원을 사용을 따르세요.
스토리지 계정이 다른 테넌트에 있다면, ' 테넌트 간 연합 클라이언트 신원 사용'을 따르세요.

같은 테넌트 내에서 데이터베이스 수준의 아이덴티티를 사용하세요

1단계: 사용자 할당 관리 ID 만들기

식별자를 만들고 리소스 ID 와 객체(주체) ID를 모두 기록하세요. 데이터베이스에 관리 ID를 할당하려면 Resource ID가 필요합니다. 객체(주체) ID는 연합 신원 자격 증명의 주체를 식별하는 크로스 테넌트 워크스루에만 필요합니다.

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

다른 방법에 대해서는 사용자 할당 관리 ID 관리를 참조하세요.

2단계: 데이터베이스에 ID 할당

UAMI를 논리 서버가 아닌 데이터베이스에 할당하세요. 이 할당은 데이터베이스 수준 고객 관리 키에서 설명된, 고객 관리 키를 사용하는 데이터베이스 수준 투명한 데이터 암호화(TDE)와 동일한 메커니즘을 사용합니다. 전체 할당 방법에 대해서는 데이터베이스에 대한 관리 ID 가져오기 또는 설정 문서를 참조하세요.

Azure 포털에서 신원을 할당하려면:

SQL 데이터베이스로 이동하세요.
보안 아래에서 ID를 선택합니다.
사용자 할당 관리 ID 아래에서 추가를 선택하세요.
생성한 신원을 선택한 후 추가를 선택하세요.
저장을 선택합니다.

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>

Resource ID는 /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity-name>와 같이 표시됩니다. Azure 포털에서 관리 ID의 속성 아래에서 찾으세요.

3단계: ID에 저장 공간 접근 권한 부여

관리 ID에 스토리지 계정에 대한 읽기 권한을 부여합니다:

스토리지 계정으로 이동합니다.
액세스 제어(IAM)를 선택합니다.
추가>역할 할당 추가를 선택합니다.
스토리지 블롭 데이터 리더 역할을 선택한 후 다음을 선택하세요.
액세스 할당에서 관리 ID를 선택합니다.
멤버 선택을 선택한 후, 사용자 할당 관리 ID를 선택한 다음 선택하세요.
검토 + 할당을 선택합니다.

ADLS Gen2에서 더 세밀한 접근을 원한다면, 계정 단위에서 역할을 할당하는 대신 특정 디렉터리에 접근 제어 목록(ACL)을 설정하세요. 자세한 내용은 Azure Data Lake Storage의 접근 제어 목록을 참조하세요.

4단계: 데이터베이스 범위 자격 증명 생성

master가 아니라 사용자 데이터베이스에 연결하고 자격 증명을 생성하세요:

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

이 자격 증명은 비밀이나 데이터베이스 마스터키가 필요 없습니다. 엔진은 쿼리 시점에 데이터베이스에 할당된 ID를 확인합니다.

서버 수준의 대응은 다른 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;

테넌트 간 연합 클라이언트 신원 사용

데이터베이스가 한 테넌트에 있고 스토리지 계정이 다른 테넌트에 있을 때 이 경로를 사용하세요. 다중 테넌트 애플리케이션 등록은 이들 간의 신뢰를 유지합니다: 데이터베이스의 UAMI는 해당 애플리케이션의 연합 신원 자격 증명의 주체이고, 스토리지 테넌트는 애플리케이션의 서비스 주체에 데이터에 대한 접근 권한을 부여합니다.

이 패턴은 투명한 데이터 암호화를 위한 크로스 테넌트 고객 관리 키와 같은 방식이므로, 이미 이 기능을 사용하고 있다면 익숙한 설정처럼 보입니다.

1단계: 다중 테넌트 애플리케이션 등록

데이터베이스를 보유한 테넌트에서 Microsoft Entra ID에 멀티테넌트 애플리케이션을 등록하고 Application (client) ID를 기록하세요.

자세한 내용은 Microsoft ID 플랫폼을 사용하여 애플리케이션 등록을 참조하세요.

2단계: 연합 신원 자격 증명 추가

해당 애플리케이션에 연합 신원 자격 증명을 추가하여 데이터베이스의 사용자 할당 관리 신원을 신뢰하게 하세요. 애플리케이션과 관리 신원은 동일한 Microsoft Entra 테넌트에 속해야 합니다.

앱 등록에서 '인증서 및 비밀'을선택하세요. >연합 자격 증명>자격 증명 추가.
연합 자격 증명 시나리오에서는 관리 신원(Managed Identity)을 선택하세요.
동일 테넌트 워크스루 1단계에서 만든 관리 ID를 선택하세요.
자동으로 입력된 Issuer가 귀하의 테넌트를 식별하는지 확인하세요. Azure 퍼블릭 클라우드의 경우 발급자는 https://login.microsoftonline.com/<tenant-id>/v2.0.
Audience가 Azure 퍼블릭 클라우드용 값인 api://AzureADTokenExchange인지 확인하세요.
자격 증명에 고유한 이름을 입력한 후 저장하세요.

자격 증명의 주체는 관리 신원의 객체(주체) ID이지 클라이언트 ID가 아닙니다. 자격 증명을 수동으로 설정할 경우, 객체(주체) ID를 정확히 복사하세요. 주체는 대소문자를 구분합니다. Microsoft Entra ID는 자격 증명을 저장할 때 잘못된 발행자, 주체 또는 대상 값을 허용하지만, 토큰 교환은 나중에 실패합니다.

자세한 내용은 애플리케이션이 관리 ID를 신뢰하도록 구성을 참조하세요.

스토리지 계정을 보유한 테넌트에서:

관리자가 멀티테넌트 애플리케이션에 관리자 동의를 제공하면 해당 테넌트에 서비스 주체가 생성됩니다.
스토리지 계정의 해당 서비스 주체에게 Storage Blob Data Reader 역할을 할당하세요. 3단계: 신원에 스토리지 액세스 권한 부여를 따르되, 액세스 권한 할당 대상에서는 User, group, 또는 service principal을 선택한 후 애플리케이션의 서비스 principal을 선택합니다.

4단계: 데이터베이스에 페더레이티드 클라이언트 ID 설정

데이터베이스를 보유한 테넌트에서 사용자가 할당한 관리 신원을 데이터베이스에 할당하고, 1단계의 애플리케이션(클라이언트) ID를 연합 클라이언트 ID로 설정하세요:

SQL 데이터베이스로 이동하세요.
보안 아래에서 ID를 선택합니다.
User-Assigned Managed Identity 아래에서 동일 테넌트 워크스루의 Step 1에 있는 ID가 목록에 있는지 확인하세요. 만약 그렇지 않다면, 추가를 선택하고 ID를 선택한 다음 추가를 선택하세요.
페더레이션된 클라이언트 ID에서 애플리케이션을 선택한 후 저장을 선택하세요.

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
);

그 다음 외부 테이블을 만들거나 PartnerStorage에서와 정확히 같이 을(를) OPENROWSET에 대해 실행합니다.

서버 수준과 데이터베이스 수준 ID 비교

특성	서버 수준 관리 ID	데이터베이스 수준의 관리 ID
ID 범위	논리 서버	단일 데이터베이스
자격 증명 구문	`IDENTITY = 'MANAGED IDENTITY'`	`IDENTITY = 'DATABASE MANAGED IDENTITY'`
테넌트 간 스토리지 액세스	지원되지 않습니다. 대신 공유 액세스 서명(SAS)을 사용하세요	데이터베이스에 설정된 연합 클라이언트 ID, `IDENTITY = 'DATABASE FEDERATED CLIENT IDENTITY'`와 함께 사용되는
스토리지 RBAC 세분화	서버의 모든 데이터베이스에 대한 하나의 아이덴티티	데이터베이스당 하나의 아이덴티티
노출 범위	서버의 모든 데이터베이스가 이 접근 권한을 공유합니다	하나의 데이터베이스로 제한됩니다
ID 유형	시스템 지정 또는 사용자 지정	사용자 할당 전용
데이터베이스 마스터 키가 필요합니다	No	No

두 유형의 자격 증명은 동일한 논리 서버와 그 데이터베이스 내에서 공존할 수 있습니다. 보안 요구에 가장 적합한 자격 증명을 선택하세요.

지리 복제 및 장애 조치

데이터베이스에 아이덴티티를 할당하면 각 복제본이 자체 할당을 갖게 됩니다. 장애 조치(failover)하기 전에 지오세컨더리를 주와 동일하게 설정하세요:

주 데이터베이스가 사용하는 동일한 사용자 지정 관리 ID를 보조 데이터베이스에 할당합니다.
3단계: 신원에 저장소 접근 권한 부여에 설명된 것과 동일한 저장소 접근 권한을 해당 신원에 부여합니다.
크로스 테넌트 접근을 위해서는 보조 데이터베이스에 동일한 Federated client ID를 설정하세요.

이렇게 두 복제본을 구성하면, 데이터베이스 범위 자격 증명을 사용하는 쿼리는 장애 조치 후에도 계속 작동합니다. 이 요구사항은 각 복제본에 신원이 설정되어 있어야 하는 데이터베이스 수준 고객 관리 키와도 일치합니다.

동일한 구성은 활성 지리 복제와 장애 조치 그룹 모두에 적용됩니다.

Limitations

Azure SQL Database만 해당. Azure SQL Managed Instance, SQL Server 및 Azure Synapse Analytics는 이러한 자격 증명 ID를 지원하지 않습니다.
아웃바운드 인증만 이 기능은 사용자와 애플리케이션이 데이터베이스에 인증하는 방식을 변경하지 않습니다.
master 데이터베이스에서는 지원되지 않습니다. 사용자 데이터베이스에 자격 증명을 생성하세요.
사용자 할당 관리 ID만 가능합니다. 시스템 할당 관리 신원은 논리 서버에 스코프가 지정되어 있어 데이터베이스 수준의 신원으로 동작할 수 없습니다.
데이터베이스당 사용자 할당 관리 ID 하나.
이 미리보기는 데이터 가상화만을 다룹니다: OPENROWSET 및 CREATE EXTERNAL TABLE, DATA_SOURCE 다른 아웃바운드 기능, 예를 들어 sp_invoke_external_rest_endpoint는 범위에 포함되지 않습니다.

Troubleshoot

데이터베이스 범위 인증 증명을 생성한다고 해서 데이터베이스 신원이 토큰을 받거나 스토리지에 액세스할 수 있는지 확인하지는 않습니다. 오류는 나중에 외부 데이터 소스를 생성하거나 자격 증명을 사용하는 쿼리를 실행할 때 발생합니다.

데이터베이스 신원이 설정되지 않았습니다 (오류 15858)

사용자 지정 관리 신원을 데이터베이스에 할당하기 전에 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를 할당한다고 해서 데이터베이스 수준의 관리 ID가 구성되지는 않습니다. 데이터베이스 할당이 완료되었음에도 오류가 계속된다면, Microsoft 지원에 연락하여 데이터베이스 ID 프로비저닝을 조사하세요.

Note

트레이스 플래그 4675와 관리 ID를 이용한 URL 백업 및 복원의 삭제 후 재생성 단계가 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의 네트워크 보안 경계를 참조하세요.

논리 서버에서 아웃바운드 네트워킹이 제한되고 저장소 계정이 서버의 아웃바운드 방화벽 규칙에 포함되지 않으면, 오류 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의 Outbound 방화벽 규칙을 참조하세요.

크로스 테넌트 구성이 누락되었거나 잘못되었습니다(오류 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.

이 오류들은 쿼리가 파일에 도달할 수 없었다는 뜻입니다. ID에 필요한 저장소 역할이 없거나, 네트워크 접속이 차단될 수 있고, 저장소 위치를 확인할 수 없거나, 토큰이 잘못된 테넌트용일 수 있습니다. 이 문제를 해결하려면 다음을 수행합니다.

적절한 스토리지 데이터 역할을 부여하세요.
스토리지 계정에 네트워크 접근 권한을 허용하세요.
컨테이너를 외부 데이터 소스 위치에 포함하세요.
를 사용하고, 4단계에 설명된 대로 데이터베이스에서 DATABASE FEDERATED CLIENT IDENTITY를 설정하세요.
연합 신원 자격 증명의 주체가 관리 신원의 객체(주체) ID와 정확히 일치하는지 확인하세요.

페일오버 후 쿼리가 실패합니다

장애 조치 후 토큰 또는 권한 부여 오류로 쿼리가 실패하면, 새 주 서버에 원래 주 서버가 사용하던 것과 동일한 사용자 할당 관리 ID가 없을 수 있습니다. 또는 그 신원이 저장소 계정에 역할 할당이 없을 수도 있습니다. 지리 복제 및 장애 조치에 설명된 대로 두 복제본에 동일한 신원을 할당하고 스토리지에 대한 액세스 권한을 부여하세요.

자주 묻는 질문

서버 수준과 데이터베이스 수준의 자격 증명이 같은 서버에서 공존할 수 있나요?

네, 같은 논리 서버와 같은 데이터베이스에서입니다. 각 자격 증명의 IDENTITY 값은 쿼리가 사용할 신원을 결정합니다: DATABASE MANAGED IDENTITY 서버의 신원을 사용하고, MANAGED IDENTITY 데이터베이스의 신원을 사용합니다.

시스템 할당 관리 ID를 사용할 수 있나요?

No. 시스템이 할당한 관리 신원은 논리 서버에 속하기 때문에 하나의 데이터베이스에 스코핑할 수 없습니다. 사용자 할당 관리 ID를 사용하세요.

이 프리뷰를 지원하는 서비스 계층과 지역은 무엇인가요?

모든 Azure 지역의 모든 Azure SQL Database 서비스 티어.

데이터베이스 마스터 키가 필요한가요?

No. DATABASE MANAGED IDENTITY와 DATABASE FEDERATED CLIENT IDENTITY 모두 비밀을 사용하지 않으므로 마스터 키가 필요하지 않습니다.

이 기능이 sp_invoke_external_rest_endpoint와 함께 작동하나요?

이 미리보기에는 없습니다. 미리보기는 데이터 가상화를 다룹니다.

피드백

이 페이지가 도움이 되었나요?

2026-10-30 에 마지막으로 업데이트됨