CREATE DATABASE SCOPED CREDENTIAL (Transact-SQL)
Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) SQL-Datenbank in Microsoft Fabric
Erstellt Datenbank-Anmeldeinformationen. Datenbank-Anmeldeinformationen werden nicht einer Serveranmeldung oder einem Datenbankbenutzer zugeordnet. Stattdessen werden sie von der Datenbank verwendet, damit immer dann der Zugriff auf den externen Speicherort gestattet wird, wenn die Datenbank einen Vorgang ausführt und hierfür eine Zugriffsberechtigung benötigt.
Transact-SQL-Syntaxkonventionen
Syntax
CREATE DATABASE SCOPED CREDENTIAL credential_name
WITH IDENTITY = 'identity_name'
[ , SECRET = 'secret' ]
[ ; ]
Argumente
credential_name
Gibt den Namen für die datenbankweit gültigen Anmeldeinformationen an, die erstellt werden sollen. credential_name kann nicht mit dem Nummernzeichen (#
) beginnen. Systemanmeldeinformationen beginnen mit ##
. Die maximale Länge von credential_name beträgt 128 Zeichen.
IDENTITY = 'identity_name'
Gibt den Namen des Kontos an, das beim Herstellen einer Verbindung außerhalb des Servers verwendet wird.
- Der Identitätsname muss
SHARED ACCESS SIGNATURE
sein, um eine Datei aus Azure Blob Storage oder Azure Data Lake Storage mithilfe eines freigegebenen Schlüssels zu importieren. Weitere Informationen zu SAS finden Sie unter Verwenden von Shared Access Signatures (SAS). Verwenden Sie für eine Shared Access Signature ausschließlichIDENTITY = SHARED ACCESS SIGNATURE
. - Der Identitätsname muss
MANAGED IDENTITY
lauten, um eine Datei aus Azure Blob Storage mithilfe einer verwalteten Identität zu importieren. - Verwenden Sie den Domänennamen nicht im IDENTITY-Argument, wenn Sie Kerberos (Active Directory oder MIT KDC) verwenden. Sie sollten lediglich den Kontonamen verwenden.
- Wenn Sie in einer SQL Server-Instanz datenbankbezogene Anmeldeinformationen mit einem Speicherzugriffsschlüssel erstellen, der als SECRET verwendet wird, wird IDENTITY ignoriert.
- WITH IDENTITY ist nicht erforderlich, wenn der Container in Azure Blob Storage für anonymen Zugriff aktiviert ist. Ein Beispiel für das Abfragen von Azure Blob Storage finden Sie unter Importieren in eine Tabelle aus einer Datei, die in Azure Blob Storage gespeichert ist.
Wichtig
Die einzige externe PolyBase-Datenquelle, die die Kerberos-Authentifizierung unterstützt, ist Hadoop. Alle anderen externen Datenquellen (SQL Server, Oracle, Teradata, MongoDB, generisches ODBC) unterstützen nur die Standardauthentifizierung.
- Wenn Sie Daten in Azure Synapse Analytics laden möchten, kann jeder gültige Wert für IDENTITY verwendet werden.
- In einem serverlosen SQL-Pool von Azure Synapse Analytics können Anmeldeinformationen mit Datenbankbereich eine verwaltete Arbeitsbereichsidentität, einen Dienstprinzipalnamen oder ein SAS-Token (Shared Access Signature) angeben. Der Zugriff über eine Benutzeridentität, die durch die Pass-Through-Authentifizierung von Microsoft Entra aktiviert wird, ist auch mit einer datenbankbezogenen Anmeldeinformationen möglich, wie anonymer Zugriff auf öffentlich verfügbaren Speicher. Weitere Informationen finden Sie unter Unterstützte Speicherautorisierungstypen.
- In einem dedizierten SQL-Pool von Azure Synapse Analytics können Anmeldeinformationen mit Datenbankbereichssignatur (Shared Access Signature, SAS), benutzerdefinierte Anwendungsidentität, verwaltete Arbeitsbereichsidentität oder Speicherzugriffsschlüssel angeben.
SECRET = 'secret'
Gibt den geheimen Bereich an, der für die ausgehende Authentifizierung erforderlich ist. SECRET
ist erforderlich, um eine Datei aus Azure Blob Storage zu importieren. Das Geheimnis muss der Azure-Speicherschlüssel sein, um aus Azure Blob Storage in Azure Synapse Analytics oder Parallel Data Warehouse zu laden.
Warnung
Der SAS-Schlüssel beginnt mit einem Fragezeichen (?). Wenn Sie den SAS-Schlüssel verwenden, müssen Sie das vorangestellte Fragezeichen entfernen. Andernfalls funktioniert der Vorgang nicht.
Bemerkungen
Datenbezogene Anmeldeinformationen sind in einem Datensatz gespeichert, in dem die Authentifizierungsinformationen enthalten sind, die zum Herstellen einer Verbindung mit einer Ressource außerhalb von SQL Server erforderlich sind. Die meisten Anmeldeinformationen schließen einen Windows-Benutzer und ein Kennwort ein.
Um die vertraulichen Informationen innerhalb der Anmeldeinformationen im Datenbankbereich zu schützen, ist ein Datenbankmasterschlüssel (DMK) erforderlich. Das DMK ist ein symmetrischer Schlüssel, der den geheimen Schlüssel in den Anmeldeinformationen des Datenbankbereichs verschlüsselt. Die Datenbank muss über ein DMK verfügen, bevor datenbankbezogene Anmeldeinformationen erstellt werden können. Ein DMK sollte mit einem sicheren Kennwort verschlüsselt werden. Azure SQL-Datenbank erstellt ein DMK mit einem starken, zufällig ausgewählten Kennwort als Teil der Erstellung der Anmeldeinformationen mit Datenbankbereich oder als Teil der Erstellung einer Serverüberwachung. Benutzer können das DMK nicht in einer logischen master
Datenbank erstellen. Das Hauptschlüsselkennwort ist microsoft unbekannt und kann nach der Erstellung nicht gefunden werden. Aus diesem Grund wird das Erstellen eines DMK vor dem Erstellen von Anmeldeinformationen mit Datenbankbereich empfohlen. Weitere Informationen finden Sie unter CREATE MASTER KEY (Transact-SQL).
Falls für IDENTITY ein Windows-Benutzer angegeben ist, kann der geheime Bereich das Kennwort enthalten. Der geheime Schlüssel wird mit dem Dienstmasterschlüssel (SMK) verschlüsselt. Wenn die SMK neu generiert wird, wird das Geheimnis mit dem neuen SMK erneut verschlüsselt.
Bei der Erteilung von Berechtigungen für eine Shared-Access-Signatur (SAS) zur Verwendung mit einer externen PolyBase-Tabelle wählen Sie sowohl Container als auch Objekt als zulässige Ressourcentypen aus. Wenn diese Berechtigungen nicht gewährt werden, erhalten Sie möglicherweise den Fehler 16535 oder 16561, wenn Sie versuchen, auf die externe Tabelle zuzugreifen.
Informationen zu datenbankweit gültigen Anmeldeinformationen werden in der sys.database_scoped_credentials-Katalogsicht angezeigt.
Im Folgenden werden einige Anwendungen datenbankweit gültiger Anmeldeinformationen aufgezeigt:
SQL Server verwendet datenbankweit gültige Anmeldeinformationen, um auf den nicht öffentlichen Blobspeicher von Azure Blob Storage oder auf durch Kerberos gesicherte Hadoop-Cluster mit PolyBase zuzugreifen. Weitere Informationen finden Sie unter CREATE EXTERNAL DATA SOURCE (Transact-SQL).
Azure Synapse Analytics verwendet datenbankweit gültige Anmeldeinformationen, um mit PolyBase auf den nicht öffentlichen Blobspeicher von Azure Blob Storage zuzugreifen. Weitere Informationen finden Sie unter CREATE EXTERNAL DATA SOURCE (Transact-SQL). Weitere Informationen über die Azure Synapse-Speicherauthentifizierung finden Sie unter Verwendung externer Tabellen mit Synapse SQL.
SQL-Datenbank verwendet Datenbankanmeldeinformationen für das elastische Abfragefeature. Dadurch können Abfragen für mehrere Datenbank-Shards gestellt werden.
SQL-Datenbank verwendet datenbankweit gültige Anmeldeinformationen, um Dateien für erweiterte Ereignisse in den Blobspeicher von Azure Blob Storage zu schreiben.
SQL-Datenbank verwendet datenbankweit gültige Anmeldeinformationen für Pools für elastische Datenbanken. Weitere Informationen finden Sie unter Tame explosive growth with elastic databases (Verwenden von elastischen Datenbanken zum Abfangen von Lastspitzen).
BULK INSERT und OPENROWSET verwenden datenbankweit gültige Anmeldeinformationen, um auf Daten aus dem Blobspeicher von Azure Blob Storage zuzugreifen. Weitere Informationen finden Sie unter Beispiele für Massenzugriff auf Daten in Azure Blob Storage.
Verwenden Sie datenbankbezogene Anmeldeinformationen mit PolyBase und Azure SQL verwaltete Instanz Datenvirtualisierungsfeatures.
Verwenden Sie für BACKUP TO URL und RESTORE FROM URL stattdessen eine Anmeldeinformation auf Serverebene über CREATE CREDENTIAL (Transact-SQL).
Berechtigungen
Erfordert die CONTROL-Berechtigung für die Datenbank.
SQL Server 2022
Ab SQL Server 2022 (16.x) wurde ein neuer Connectortyp eingeführt, wobei REST-API-Aufrufe verwendet wurden, die HADOOP ersetzen. Für Azure Blob Storage und Azure Data Lake Gen 2 wird nur die Authentifizierungsmethode SHARED ACCESS SIGNATURE
unterstützt.
Weitere Informationen finden Sie unter CREATE EXTERNAL DATA SOURCE (CREATE EXTERNAL DATA SOURCE).
Beispiele
A. Erstellen von datenbankweit gültigen Anmeldeinformationen für eine Anwendung
Im folgenden Beispiel werden datenbankweit gültige Anmeldeinformationen mit der Bezeichnung AppCred
erstellt. Die datenbankweit gültigen Anmeldeinformationen enthalten den Windows-Benutzer Mary5
und ein Kennwort.
-- Create a db master key if one does not already exist, using your own password.
CREATE MASTER KEY ENCRYPTION BY PASSWORD='<EnterStrongPasswordHere>';
-- Create a database scoped credential.
CREATE DATABASE SCOPED CREDENTIAL AppCred WITH IDENTITY = 'Mary5',
SECRET = '<EnterStrongPasswordHere>';
B. Erstellen von datenbankweit gültigen Anmeldeinformationen für eine Shared Access Signature
Im folgenden Beispiel werden datenbankweit gültige Anmeldeinformationen erstellt, durch die sich eine externe Datenquelle erstellen lässt. Mit dieser können Massenvorgänge wie BULK INSERT und OPENROWSET ausgeführt werden.
-- Create a db master key if one does not already exist, using your own password.
CREATE MASTER KEY ENCRYPTION BY PASSWORD='<EnterStrongPasswordHere>';
-- Create a database scoped credential.
CREATE DATABASE SCOPED CREDENTIAL MyCredentials
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'QLYMgmSXMklt%2FI1U6DcVrQixnlU5Sgbtk1qDRakUBGs%3D';
C. Erstellen von datenbankweit gültigen Anmeldeinformationen für PolyBase-Konnektivität mit Azure Data Lake Store
Im folgenden Beispiel werden datenbankweit gültige Anmeldeinformationen erstellt, die zum Erstellen einer externen Datenquelle verwendet werden können, die wiederum von PolyBase in Azure Synapse Analytics verwendet werden kann.
Azure Data Lake Store verwendet eine Microsoft Entra-Anwendung für die Dienstauthentifizierung.
Erstellen Sie eine Microsoft Entra-Anwendung , und dokumentieren Sie Ihre client_id, OAuth_2.0_Token_EndPoint und Key, bevor Sie versuchen, anmeldeinformationen mit Datenbankbereich zu erstellen.
-- Create a db master key if one does not already exist, using your own password.
CREATE MASTER KEY ENCRYPTION BY PASSWORD='<EnterStrongPasswordHere>';
-- Create a database scoped credential.
CREATE DATABASE SCOPED CREDENTIAL ADL_User
WITH
IDENTITY = '<client_id>@<OAuth_2.0_Token_EndPoint>',
SECRET = '<key>'
;