Steuern des Speicherkontozugriffs für einen serverlosen SQL-Pool in Azure Synapse Analytics

Die Benutzeridentität (auch „Microsoft Entra-Passthrough“ genannt) ist ein Autorisierungstyp, bei dem die Identität der bei einem serverlosen SQL-Pool angemeldeten Microsoft Entra-Benutzer*innen verwendet wird, um den Datenzugriff zu autorisieren. Vor dem Zugriff auf die Daten muss der Azure Storage-Administrator oder die Azure Storage-Administratorin den Microsoft Entra-Benutzer*innnen die erforderlichen Berechtigungen erteilen. Wie in der Tabelle Unterstützte Autorisierungstypen für Datenbankbenutzer angegeben, wird dies für den SQL-Benutzertyp nicht unterstützt.

Sie müssen Mitglied der Rolle „Besitzer von Speicherblobdaten“, „Mitwirkender an Speicherblobdaten“ oder „Leser von Speicherblobdaten“ sein, um Ihre Identität für den Zugriff auf die Daten verwenden zu können. Alternativ können Sie differenzierte ACL-Regeln für den Zugriff auf Dateien und Ordner angeben. Auch wenn Sie Besitzer eines Speicherkontos sind, müssen Sie sich selbst zu einer der Rollen für den Zugriff auf Storage-Blobdaten hinzufügen. Weitere Informationen zur Zugriffssteuerung in Azure Data Lake Storage Gen2 finden Sie im Artikel Zugriffssteuerung in Azure Data Lake Storage Gen2.

Shared Access Signature (SAS) bietet delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS kann ein Kunde Clients Zugriff auf Ressourcen in einem Speicherkonto gewähren, ohne dafür Kontoschlüssel weitergeben zu müssen. Eine SAS bietet die Möglichkeit, präzise zu steuern, welche Art von Zugriff Sie Clients gewähren möchten, die über eine SAS verfügen. Dazu stehen Parameter wie Gültigkeitsintervall, erteilte Berechtigungen, zulässiger IP-Adressbereich und zulässiges Protokoll (HTTPS/HTTP) zur Verfügung.

Um ein SAS-Token abzurufen, navigieren Sie zu Azure-Portal -> Speicherkonto -> Shared Access Signature -> Berechtigungen konfigurieren -> SAS und Verbindungszeichenfolge generieren.

Um Zugriff über ein SAS-Token zu ermöglichen, müssen Sie datenbankbezogene oder serverbezogene Anmeldeinformationen erstellen.

Ein Dienstprinzipal ist die lokale Darstellung eines globalen Anwendungsobjekts in einem bestimmten Microsoft Entra-Mandanten. Diese Authentifizierungsmethode eignet sich für den Fall, dass der Speicherzugriff für eine Benutzeranwendung, einen Dienst oder ein Automatisierungstool autorisiert werden muss. Weitere Informationen zu Dienstprinzipalen in Microsoft Entra ID finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.

Die Anwendung, die bei Microsoft Entra ID registriert werden muss. Weitere Informationen zum Registrierungsprozess finden Sie unter Schnellstart: Registrieren einer Anwendung bei Microsoft Identity Platform. Sobald die Anwendung registriert worden ist, kann ihr Dienstprinzipal für die Autorisierung verwendet werden.

Der Dienstprinzipal sollte den Rollen „Besitzer von Speicherblobdaten“, Mitwirkender an Speicherblobdaten“ und „Leser von Speicherblobdaten“ zugewiesen werden, damit die Anwendung auf die Daten zugreifen kann. Selbst wenn der Dienstprinzipal der Besitzer eines Speicherkontos ist, muss ihm die entsprechende Rolle für Speicherblobdaten zugewiesen werden. Als Alternative zur Gewährung des Zugriffs auf Speicherdateien und -ordner können differenzierte ACL-Regeln für den Dienstprinzipal definiert werden.

Weitere Informationen zur Zugriffssteuerung in Azure Data Lake Storage Gen2 finden Sie unter Zugriffssteuerung in Azure Data Lake Storage Gen2.

Die verwaltete Dienstidentität oder verwaltete Identität wird auch als MSI bezeichnet. Eine MSI ist ein Feature von Microsoft Entra ID, das Azure-Dienste für einen Azure-Dienst bereitstellt, in diesem Fall für Ihren serverlosen SQL-Pool. Die MSI wird automatisch in Microsoft Entra ID erstellt. Diese Identität kann verwendet werden, um eine Anforderung für den Datenzugriff in Azure Storage zu autorisieren.

Vor dem Zugriff auf die Daten muss der Azure Storage-Administrator der verwalteten Dienstidentität Berechtigungen zum Zugriff auf die Daten erteilen. Das Erteilen von Berechtigungen für eine MSI erfolgt auf die gleiche Weise wie das Erteilen von Berechtigungen für jeden anderen Microsoft Entra-Benutzer bzw. jede andere Microsoft Entra-Benutzerin auch.

Sie können auf öffentlich verfügbare Dateien in Azure-Speicherkonten zugreifen, die anonymen Zugriff zulassen.

Für den Zugriff auf den durch die Firewall geschützten Speicher über die Benutzeridentität können Sie die Benutzeroberfläche des Microsoft Azure-Portals oder das PowerShell-Modul „Az.Storage“ verwenden.

Azure Storage-Firewallkonfiguration über das Azure-Portal

1. Suchen Sie Ihr neues Speicherkonto im Azure-Portal.
2. Wechseln Sie im Hauptnavigationsmenü unter Einstellungen zu Netzwerk.
3. Fügen Sie im Abschnitt Ressourceninstanzen eine Ausnahme für Ihren Azure Synapse-Arbeitsbereich hinzu.
4. Wählen Sie Microsoft.Synapse/workspaces als Ressourcentyp aus.
5. Wählen Sie den Namen des Arbeitsbereichs als Instanznamen aus.
6. Wählen Sie Speichern aus.

Azure Storage-Firewallkonfiguration über das PowerShell

Führen Sie diese Schritte aus, um das Speicherkontozu konfigurieren und eine Ausnahme für den Azure Synapse-Arbeitsbereich hinzuzufügen.

1. Öffnen Sie PowerShell, oder installieren Sie PowerShell.

2. Installieren Sie die neuesten Versionen des Moduls „Az.Storage“ und des Moduls „Az.Synapse“, z. B. im folgenden Skript:

   Install-Module -Name Az.Storage -RequiredVersion 3.4.0
   Install-Module -Name Az.Synapse -RequiredVersion 0.7.0
   

   Wichtig

   Stellen Sie sicher, dass Sie mindestens Version 3.4.0 verwenden. Ihre Az.Storage-Version können Sie mithilfe des folgenden Befehls überprüfen:

   Get-Module -ListAvailable -Name Az.Storage | Select Version
   

3. Stellen Sie eine Verbindung mit Ihrem Azure-Mandanten her:

   Connect-AzAccount
   

4. Definieren Sie Variablen in PowerShell:

   • Ressourcengruppenname: Sie finden diesen Namen im Azure-Portal in der Übersicht Ihres Speicherkontos.
   • Kontoname: Name des Speicherkontos, das durch Firewallregeln geschützt wird
   • Mandanten-ID: Sie finden diese ID im Azure-Portal in Microsoft Entra ID unter Eigenschaften in Mandanteneigenschaften.
   • Arbeitsbereichname: Name des Azure Synapse-Arbeitsbereichs.

       $resourceGroupName = "<resource group name>"
       $accountName = "<storage account name>"
       $tenantId = "<tenant id>"
       $workspaceName = "<Azure Synapse workspace name>"
   
       $workspace = Get-AzSynapseWorkspace -Name $workspaceName
       $resourceId = $workspace.Id
       $index = $resourceId.IndexOf("/resourceGroups/", 0)
       # Replace G with g - /resourceGroups/ to /resourcegroups/
       $resourceId = $resourceId.Substring(0,$index) + "/resourcegroups/" ` 
           + $resourceId.Substring($index + "/resourceGroups/".Length)
   
       $resourceId
   

   Wichtig

   Der Wert von $resourceid, der vom PowerShell-Skript zurückgegeben wird, muss dieser Vorlage entsprechen: /subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Synapse/workspaces/{name-of-workspace} Es ist wichtig, resourcegroups in Kleinbuchstaben zu schreiben.

5. Fügen Sie eine Netzwerkregel für das Azure-Speicherkonto hinzu:

       $parameters = @{
           ResourceGroupName = $resourceGroupName
           Name = $accountName
           TenantId = $tenantId 
           ResourceId = $resourceId
       }
   
       Add-AzStorageAccountNetworkRule @parameters
   

6. Vergewissern Sie sich, dass die Netzwerkregel des Speicherkontos in Ihrer Speicherkontofirewall angewendet wurde. Das folgende PowerShell-Skript vergleicht die Variable $resourceid aus den vorherigen Schritten mit der Ausgabe der Netzwerkregel des Speicherkontos.

       $parameters = @{
           ResourceGroupName = $resourceGroupName
           Name = $accountName
       }
   
       $rule = Get-AzStorageAccountNetworkRuleSet @parameters
       $rule.ResourceAccessRules | ForEach-Object { 
           if ($_.ResourceId -cmatch "\/subscriptions\/(\w\-*)+\/resourcegroups\/(.)+") { 
               Write-Host "Storage account network rule is successfully configured." -ForegroundColor Green
               $rule.ResourceAccessRules
           } else {
               Write-Host "Storage account network rule is not configured correctly. Remove this rule and follow the steps in detail." -ForegroundColor Red
               $rule.ResourceAccessRules
           }
       }
   

Shared Access Signatures können nicht für den Zugriff auf Speicher verwendet werden, der per Firewall geschützt ist.

Ein Dienstprinzipal kann nicht für den Zugriff auf Speicher verwendet werden, der durch eine Firewall geschützt ist. Verwenden Sie stattdessen eine verwaltete Dienstidentität.

Sie müssen die Einstellung Vertrauenswürdige Microsoft-Dienste zulassen aktivieren und der systemseitig zugewiesenen verwalteten Identität für diese Ressourceninstanz eine Azure-Rolle zuweisen.

In diesem Fall entspricht der Zugriffsbereich für die Ressourceninstanz der Azure-Rolle, die der verwalteten Identität zugewiesen worden ist.

Für Sie ist es nicht möglich, anonym auf Speicher zuzugreifen, der per Firewall geschützt ist.

Microsoft Entra-Benutzer*innen können auf jede Datei in Azure Storage zugreifen, wenn sie Mitglieder der Rollen „Besitzer von Speicherblobdaten“, „Mitwirkender an Storage-Blobdaten“ oder „Storage-Blobdatenleser“ sind. Microsoft Entra-Benutzer*innen benötigen keine Anmeldeinformationen für den Zugriff auf den Speicher.

Authentifizierte SQL-Benutzer*innen können die Microsoft Entra-Authentifizierung nicht für den Zugriff auf den Speicher verwenden. Sie können mithilfe von verwalteter Identität, SAS-Schlüssel oder Dienstprinzipal über Datenbankanmeldeinformationen auf den Speicher zugreifen oder wenn der Speicher öffentlich zugänglich ist.

Mit dem folgenden Skript werden Anmeldeinformationen auf Serverebene erstellt, die von der OPENROWSET-Funktion für den Zugriff auf eine beliebige Datei im Azure-Speicher mit dem SAS-Token verwendet werden können. Erstellen Sie diese Anmeldeinformationen, damit ein SQL-Prinzipal die OPENROWSET-Funktion zum Lesen von Dateien verwenden kann, die durch einen SAS-Schlüssel im Azure-Speicher geschützt sind. Der Name der Anmeldeinformationen muss der URL entsprechen.

Ersetzen Sie in der folgenden Beispielabfrage <mystorageaccountname> durch den Namen Ihres tatsächlichen Speicherkontos und <mystorageaccountcontainername> durch den tatsächlichen Containernamen:

CREATE CREDENTIAL [https://<mystorageaccountname>.dfs.core.windows.net/<mystorageaccountcontainername>]
WITH IDENTITY='SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-04-18T20:42:12Z&st=2019-04-18T12:42:12Z&spr=https&sig=lQHczNvrk1BrIPBNJ3VYEIq78%3D';
GO

Optional können Sie einfach nur die Basis-URL des Speicherkontos ohne den Containernamen verwenden.

Mit dem folgenden Skript werden Anmeldeinformationen auf Serverebene erstellt, die verwendet werden können, um unter Verwendung des Dienstprinzipals für die Authentifizierung und Autorisierung auf Dateien in einem Speicher zuzugreifen. Die App-ID finden Sie in den App-Registrierungen im Azure-Portal. Wählen Sie dazu die Anwendung aus, die Speicherzugriff anfordert. Das Geheimnis wird während der App-Registrierung abgerufen. AuthorityUrl ist die URL der Oauth2.0-Autorität von Microsoft Entra ID.

CREATE CREDENTIAL [https://<storage_account>.dfs.core.windows.net/<container>]
WITH IDENTITY = '<AppID>@<AuthorityUrl>' 
, SECRET = '<Secret>'

Mit dem folgenden Skript wird eine Anmeldeinformation auf Serverebene erstellt, die von der OPENROWSET-Funktion für den Zugriff auf eine beliebige Datei im Azure-Speicher mit der verwalteten Identität eines Azure Synapse-Arbeitsbereichs, einem speziellen Typ von verwalteter Identität, verwendet werden kann.

CREATE CREDENTIAL [https://<storage_account>.dfs.core.windows.net/<container>]
WITH IDENTITY='Managed Identity'

Optional können Sie einfach nur die Basis-URL des Speicherkontos ohne den Containernamen verwenden.

Es ist keine Anmeldeinformation auf Serverebene für den Zugriff auf öffentlich verfügbare Dateien erforderlich. Erstellen Sie eine Datenquelle ohne Anmeldeinformation, um auf öffentlich verfügbare Dateien im Azure-Speicher zuzugreifen.

Microsoft Entra-Benutzer*innen können auf jede Datei in Azure Storage zugreifen, wenn sie Mitglieder der Rollen „Besitzer von Speicherblobdaten“, „Mitwirkender an Storage-Blobdaten“ oder „Storage-Blobdatenleser“ sind. Microsoft Entra-Benutzer*innen benötigen keine Anmeldeinformationen für den Zugriff auf den Speicher.

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
)

Authentifizierte SQL-Benutzer*innen können die Microsoft Entra-Authentifizierung nicht für den Zugriff auf den Speicher verwenden. Sie können mithilfe von verwalteter Identität, SAS-Schlüssel oder Dienstprinzipal über Datenbankanmeldeinformationen auf den Speicher zugreifen oder wenn der Speicher öffentlich zugänglich ist.

Mit dem folgenden Skript wird eine Anmeldeinformation erstellt, die für den Zugriff auf Dateien im Speicher mit dem in der Anmeldeinformation angegebenen SAS-Token verwendet wird. Mit dem Skript wird eine externe Beispieldatenquelle erstellt, die dieses SAS-Token für den Zugriff auf Speicher verwendet.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>'
GO
CREATE DATABASE SCOPED CREDENTIAL [SasToken]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
     SECRET = 'sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-04-18T20:42:12Z&st=2019-04-18T12:42:12Z&spr=https&sig=lQHczNvrk1KEIq78%3D';
GO
CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = SasToken
)

Mit dem folgenden Skript werden Anmeldeinformationen auf Datenbankebene erstellt, die verwendet werden können, um unter Verwendung des Dienstprinzipals für die Authentifizierung und Autorisierung auf Dateien in einem Speicher zuzugreifen. Die App-ID finden Sie in den App-Registrierungen im Azure-Portal. Wählen Sie dazu die Anwendung aus, die Speicherzugriff anfordert. Das Geheimnis wird während der App-Registrierung abgerufen. AuthorityUrl ist die URL der Oauth2.0-Autorität von Microsoft Entra ID.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>

CREATE DATABASE SCOPED CREDENTIAL [<CredentialName>] WITH
IDENTITY = '<AppID>@<AuthorityUrl>' 
, SECRET = '<Secret>'
GO
CREATE EXTERNAL DATA SOURCE MyDataSource
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = CredentialName
)

Mit dem folgenden Skript wird eine datenbankbezogene Anmeldeinformation erstellt, mit der der aktuelle Microsoft Entra-Benutzer oder die aktuelle Microsoft Entra-Benutzerin die verwaltete Identität des Diensts annehmen kann. Mit dem Skript wird eine externe Beispieldatenquelle erstellt, die die Arbeitsbereichsidentität für den Zugriff auf einen Speicher verwendet.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>
CREATE DATABASE SCOPED CREDENTIAL SynapseIdentity
WITH IDENTITY = 'Managed Identity';
GO
CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = SynapseIdentity
)

Die datenbankbezogene Anmeldeinformation muss nicht mit dem Namen des Speicherkontos übereinstimmen, da sie explizit in der Datenquelle verwendet wird, die den Speicherort des Speichers definiert.

Es ist keine datenbankbezogene Anmeldeinformation für den Zugriff auf öffentlich verfügbare Dateien erforderlich. Erstellen Sie eine Datenquelle ohne Anmeldeinformationen, um auf öffentlich verfügbare Dateien im Azure-Speicher zuzugreifen.

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.blob.core.windows.net/<container>/<path>'
)