Kontrollera åtkomsten till lagringskontot för serverlös SQL-pool i Azure Synapse Analytics

En fråga för en serverlös SQL-pool läser filer direkt från Azure Storage. Behörigheter för åtkomst till filerna i Azure Storage styrs på två nivåer:

  • Lagringsnivå – Användaren bör ha behörighet att komma åt underliggande lagringsfiler. Lagringsadministratören bör tillåta att Microsoft Entra-huvudkontot läser/skriver filer eller genererar en SAS-nyckel (signatur för delad åtkomst) som ska användas för åtkomst till lagring.
  • SQL-tjänstnivå – Användaren bör ha beviljat behörighet att läsa data med hjälp av en extern tabell eller att köra OPENROWSET funktionen. Läs mer om de behörigheter som krävs i det här avsnittet.

I den här artikeln beskrivs vilka typer av autentiseringsuppgifter du kan använda och hur sökning efter autentiseringsuppgifter utförs för SQL- och Microsoft Entra-användare.

Lagringsbehörigheter

En serverlös SQL-pool i Synapse Analytics-arbetsytan kan läsa innehållet i filer som lagras i Azure Data Lake Storage. Du måste konfigurera behörigheter för lagring för att en användare som kör en SQL-fråga ska kunna läsa filerna. Det finns tre metoder för att aktivera åtkomsten till filerna:

  • Med rollbaserad åtkomstkontroll (RBAC) kan du tilldela en roll till vissa Microsoft Entra-användare i klientorganisationen där lagringen finns. En läsare måste vara medlem i rollen Storage Blob Data Reader, Storage Blob Data Contributor eller Storage Blob Data Owner för lagringskontot. En användare som skriver data i Azure Storage måste vara medlem i rollen Storage Blob Data Contributor eller Storage Blob Data Owner. Rollen Lagringsägare innebär inte att en användare också är lagringsdataägare.
  • Med åtkomstkontrollistor (ACL) kan du definiera en detaljerad behörighet för Läs(R), Skriv(W) och Kör(X) på filerna och katalogerna i Azure Storage. ACL kan tilldelas till Microsoft Entra-användare. Om läsare vill läsa en fil på en sökväg i Azure-lagringen måste de ha ACL:en X (köra) för varje mapp i filsökvägen och ACL:en R (läsa) för filen. Läs mer om att ställa in ACL-behörigheter för lagringslagret.
  • Signatur för delad åtkomst (SAS) gör det möjligt för en läsare att komma åt filerna i Azure Data Lake Storage med hjälp av den tidsbegränsade token. Läsaren behöver inte ens autentiseras som Microsoft Entra-användare. SAS-token innehåller de behörigheter som beviljats läsaren samt under vilken period som token är giltig. SAS-token är ett bra val för tidsbegränsad åtkomst till alla användare som inte ens behöver vara i samma Microsoft Entra-klientorganisation. En SAS-token kan definieras för lagringskontot eller för specifika kataloger. Läs mer om att ge begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).

Alternativt kan du göra dina filer offentligt tillgängliga genom att tillåta anonym åtkomst. Den här metoden ska INTE användas om du hanterar känsliga data.

Lagringsauktoriseringstyper som stöds

En användare som har loggat in i en serverlös SQL-pool måste ha behörighet att komma åt och köra frågor mot filerna i Azure Storage om filerna inte är offentligt tillgängliga. Du kan använda fyra auktoriseringstyper för att komma åt icke-offentlig lagring: användaridentitet, signatur för delad åtkomst, tjänstens huvudnamn och hanterad identitet.

Kommentar

Microsoft Entra-direkt är standardbeteendet när du skapar en arbetsyta.

Användaridentitet, även kallat "Microsoft Entra-genomströmning", är en auktoriseringstyp där identiteten för Den Microsoft Entra-användare som loggade in i en serverlös SQL-pool används för att auktorisera dataåtkomst. Innan du kommer åt data måste Azure Storage-administratören bevilja behörigheter till Microsoft Entra-användaren. Som anges i tabellen Auktoriseringstyper som stöds för databasanvändare stöds den inte för SQL-användartypen.

Viktigt!

En Microsoft Entra-autentiseringstoken kan cachelagras av klientprogrammen. Power BI cachelagrar till exempel Microsoft Entra-token och återanvänder samma token i en timme. Långvariga frågor kan misslyckas om token upphör att gälla mitt i frågekörningen. Om du upplever frågefel som orsakas av Microsoft Entra-åtkomsttoken som upphör att gälla mitt i frågan kan du överväga att byta till tjänstens huvudnamn, hanterade identitet eller signatur för delad åtkomst.

Du måste vara medlem i rollen Storage Blob Data Owner, Storage Blob Data Contributor eller Storage Blob Data Reader för att kunna använda din identitet för att komma åt data. Alternativt kan du ange detaljerade ACL-regler för åtkomst till filer och mappar. Även om du är ägare till ett lagringskonto måste du fortfarande lägga till dig själv i någon av lagringsblobdatarollerna. Mer information om åtkomstkontroll i Azure Data Lake Store Gen2 finns i artikeln Åtkomstkontroll i Azure Data Lake Storage Gen2 .

Scenarier mellan klientorganisationer

I de fall då Azure Storage finns i en annan klientorganisation än synapse-serverlös SQL-pool är auktorisering via tjänstens huvudnamn den rekommenderade metoden. SAS-auktorisering är också möjligt, medan hanterad identitet inte stöds.

Typ av auktorisering Brandväggsskyddad lagring icke-brandväggsskyddad lagring
SAS Stöds Stöds
Tjänsthuvudnamn Stöds inte Stöds

Kommentar

Om Azure Storage skyddas av en Azure Storage-brandvägg stöds inte tjänstens huvudnamn.

Auktoriseringstyper som stöds för databasanvändare

Följande tabell innehåller tillgängliga Azure Storage-auktoriseringstyper för olika inloggningsmetoder i en serverlös SQL-slutpunkt i Azure Synapse Analytics:

Auktoriseringstyp SQL-användare Microsoft Entra-användare Tjänstens huvud
Användaridentitet Stöds inte Stöds Stöds
SAS Stöds Stöds Stöds
Tjänstens huvud Stöds Stöds Stöds
Hanterad identitet Stöds Stöds Stöds

Lagrings- och auktoriseringstyper som stöds

Du kan använda följande kombinationer av auktoriseringstyper och Azure Storage-typer:

Auktoriseringstyp Blob Storage ADLS Gen1 ADLS Gen2
SAS Stöds Stöds inte Stöds
Tjänstens huvud Stöds Stöds Stöds
Hanterad identitet Stöds Stöds Stöds
Användaridentitet Stöds Stöds Stöds

Scenarier mellan klientorganisationer

Om Azure Storage finns i en annan klientorganisation än den serverlösa SQL-poolen i Azure Synapse Analytics är auktorisering via tjänstens huvudnamn den rekommenderade metoden. Signaturauktorisering för delad åtkomst är också möjlig. Hanterad tjänstidentitet stöds inte.

Typ av auktorisering Brandväggsskyddad lagring icke-brandväggsskyddad lagring
SAS Stöds Stöds
Tjänstens huvud Stöds inte Stöds

Kommentar

Om Azure Storage skyddas av en Azure Storage-brandvägg och finns i en annan klientorganisation stöds inte tjänstens huvudnamn. Använd i stället en signatur för delad åtkomst (SAS).

Brandväggsskyddad lagring

Du kan konfigurera lagringskonton för att tillåta åtkomst till en specifik serverlös SQL-pool genom att skapa en resursinstansregel. När du kommer åt lagring som skyddas med brandväggen använder du Användaridentitet eller Hanterad identitet.

Kommentar

Brandväggsfunktionen i Azure Storage är i offentlig förhandsversion och är tillgänglig i alla offentliga molnregioner.

Följande tabell innehåller tillgängliga brandväggsskyddade Azure Storage-auktoriseringstyper för olika inloggningsmetoder i en serverlös SQL-slutpunkt i Azure Synapse Analytics:

Auktoriseringstyp SQL-användare Microsoft Entra-användare Tjänstens huvud
Användaridentitet Stöds inte Stöds Stöds
SAS Stöds inte Stöds inte Stöds inte
Tjänstens huvud Stöds inte Stöds inte Stöds inte
Hanterad identitet Stöds Stöds Stöds

Om du vill komma åt lagring som skyddas med brandväggen via en användaridentitet kan du använda Azure-portalen eller Az.Storage PowerShell-modulen.

Azure Storage-brandväggskonfiguration via Azure-portalen

  1. Sök efter ditt lagringskonto i Azure-portalen.
  2. I huvudnavigeringsmenyn går du till Nätverk under Inställningar.
  3. I avsnittet Resursinstanser lägger du till ett undantag för din Azure Synapse-arbetsyta.
  4. Välj Microsoft.Synapse/workspaces som resurstyp.
  5. Välj namnet på arbetsytan som instansnamn.
  6. Välj Spara.

Azure Storage-brandväggskonfiguration via PowerShell

Följ de här stegen för att konfigurera ditt lagringskonto och lägga till ett undantag för Azure Synapse-arbetsytan.

  1. Öppna PowerShell eller installera PowerShell.

  2. Installera de senaste versionerna av Az.Storage-modulen och Az.Synapse-modulen, till exempel i följande skript:

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

    Viktigt!

    Kontrollera att du använder minst version 3.4.0. Du kan kontrollera din Az.Storage-version genom att köra det här kommandot:

    Get-Module -ListAvailable -Name Az.Storage | Select Version
    
  3. Anslut till din Azure-klientorganisation:

    Connect-AzAccount
    
  4. Definiera variabler i PowerShell:

    • Resursgruppsnamn – du hittar detta i Azure-portalen i Översikt över ditt lagringskonto.
    • Kontonamn – namnet på lagringskontot som skyddas av brandväggsregler.
    • Klientorganisations-ID – du hittar detta i Azure-portalen i Microsoft Entra-ID, under Egenskaper, i Klientegenskaper.
    • Arbetsytans namn – Namnet på Azure Synapse-arbetsytan.
        $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
    

    Viktigt!

    Värdet för det $resourceid som returneras av PowerShell-skriptet ska matcha den här mallen: /subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Synapse/workspaces/{name-of-workspace} Det är viktigt att skriva resursgrupper i gemener .

  5. Lägg till en nätverksregel för Azure Storage-konto:

        $parameters = @{
            ResourceGroupName = $resourceGroupName
            Name = $accountName
            TenantId = $tenantId 
            ResourceId = $resourceId
        }
    
        Add-AzStorageAccountNetworkRule @parameters
    
  6. Kontrollera att nätverksregeln för lagringskontot tillämpades i brandväggen för lagringskontot. Följande PowerShell-skript jämför variabeln $resourceid från föregående steg med utdata från nätverksregeln för lagringskontot.

        $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
            }
        }
    

Autentiseringsuppgifter

För att köra frågor mot en fil i Azure Storage behöver din serverlösa SQL-poolslutpunkt en autentiseringsuppgift som innehåller autentiseringsinformationen. Två typer av autentiseringsuppgifter används:

  • Autentiseringsuppgifter på servernivå används för ad hoc-frågor som körs med hjälp av OPENROWSET funktionen. Namnet på autentiseringsuppgifterna måste matcha lagrings-URL:en.
  • En databasomfattande autentiseringsuppgift används för externa tabeller. Externa tabellreferenser DATA SOURCE med de autentiseringsuppgifter som ska användas för åtkomst till lagring.

Bevilja behörigheter för att hantera autentiseringsuppgifter

Så här beviljar du möjligheten att hantera autentiseringsuppgifter:

  • För att en användare ska kunna skapa eller ta bort autentiseringsuppgifter på servernivå måste en administratör ge behörighet till inloggningen ALTER ANY CREDENTIAL i huvuddatabasen. Till exempel:

    GRANT ALTER ANY CREDENTIAL TO [login_name];
    
  • Om du vill tillåta att en användare skapar eller släpper en databasomfattande autentiseringsuppgifter måste en administratör bevilja behörigheten CONTROL för databasen till databasanvändaren i användardatabasen. Till exempel:

    GRANT CONTROL ON DATABASE::[database_name] TO [user_name];
    

Bevilja behörigheter för att använda autentiseringsuppgifter

Databasanvändare som har åtkomst till extern lagring måste ha behörighet att använda autentiseringsuppgifter. Om du vill använda autentiseringsuppgifterna måste en användare ha behörigheten REFERENCES för en specifik autentiseringsuppgift.

Om du vill bevilja behörighet för REFERENCES en autentiseringsuppgift på servernivå för en inloggning använder du följande T-SQL-fråga i huvuddatabasen:

GRANT REFERENCES ON CREDENTIAL::[server-level_credential] TO [login_name];

Om du vill bevilja en REFERENCES behörighet för en databasomfattande autentiseringsuppgift för en databasanvändare använder du följande T-SQL-fråga i användardatabasen:

GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL::[database-scoped_credential] TO [user_name];

Autentiseringsuppgifter på servernivå

Autentiseringsuppgifter på servernivå används när en SQL-inloggning anropar OPENROWSET funktionen utan DATA_SOURCE att läsa filer på ett lagringskonto.

Namnet på autentiseringsuppgifter på servernivå måste matcha bas-URL:en för Azure Storage, eventuellt följt av ett containernamn. En autentiseringsuppgift läggs till genom att skapa autentiseringsuppgifter. Du måste ange CREDENTIAL NAME argumentet.

Kommentar

Argumentet FOR CRYPTOGRAPHIC PROVIDER stöds inte.

Credential-namnet på servernivå måste matcha följande format: <prefix>://<storage_account_path>[/<container_name>]. Sökvägar för lagringskonton beskrivs i följande tabell:

Extern datakälla Prefix Sökväg för lagringskonto
Azure Blob Storage https <storage_account>.blob.core.windows.net
Azure Data Lake Storage Gen1 https <storage_account>.azuredatalakestore.net/webhdfs/v1
Azure Data Lake Storage Gen2 https <storage_account>.dfs.core.windows.net

Autentiseringsuppgifter på servernivå kan sedan komma åt Azure Storage med hjälp av följande autentiseringstyper:

Microsoft Entra-användare kan komma åt valfri fil i Azure Storage om de är medlemmar i rollen Storage Blob Data Owner, Storage Blob Data Contributor eller Storage Blob Data Reader. Microsoft Entra-användare behöver inte autentiseringsuppgifter för att komma åt lagring.

SQL-autentiserade användare kan inte använda Microsoft Entra-autentisering för att få åtkomst till lagring. De kan komma åt lagring via en databasautentiseringsuppgift med hjälp av hanterad identitet, SAS-nyckel, tjänstens huvudnamn eller om det finns offentlig åtkomst till lagringen.

Databasomfattande autentiseringsuppgifter

Autentiseringsuppgifter med databasomfattning används när huvudnamn anropar OPENROWSET funktionen med DATA_SOURCE eller väljer data från en extern tabell som inte har åtkomst till offentliga filer. Databasens begränsade autentiseringsuppgifter behöver inte matcha namnet på lagringskontot. Det refereras till i DATA SOURCE som definierar lagringsplatsen.

Autentiseringsuppgifter med databasomfattning ger åtkomst till Azure Storage med hjälp av följande autentiseringstyper:

Microsoft Entra-användare kan komma åt valfri fil i Azure Storage om de är medlemmar i rollerna Storage Blob Data Owner, Storage Blob Data Contributor eller Storage Blob Data Reader. Microsoft Entra-användare behöver inte autentiseringsuppgifter för att komma åt lagring.

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

SQL-autentiserade användare kan inte använda Microsoft Entra-autentisering för att få åtkomst till lagring. De kan komma åt lagring via en databasautentiseringsuppgift med hjälp av hanterad identitet, SAS-nyckel, tjänstens huvudnamn eller om det finns offentlig åtkomst till lagringen.

Autentiseringsuppgifter med databasomfattning används i externa datakällor för att ange vilken autentiseringsmetod som ska användas för att komma åt den här lagringen:

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = <name of database scoped credential> 
)

Exempel

Få åtkomst till en offentligt tillgänglig datakälla

Använd följande skript för att skapa en tabell som har åtkomst till offentligt tillgänglig datakälla.

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat]
       WITH ( FORMAT_TYPE = PARQUET)
GO
CREATE EXTERNAL DATA SOURCE publicData
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<public_container>/<path>' )
GO

CREATE EXTERNAL TABLE dbo.userPublicData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [publicData],
       FILE_FORMAT = [SynapseParquetFormat] )

Databasanvändaren kan läsa innehållet i filerna från datakällan med hjälp av den externa tabellen eller funktionen OPENROWSET som refererar till datakällan:

SELECT TOP 10 * FROM dbo.userPublicData;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet',
                                DATA_SOURCE = 'mysample',
                                FORMAT='PARQUET') as rows;
GO

Få åtkomst till en datakälla med autentiseringsuppgifter

Ändra följande skript för att skapa en extern tabell som har åtkomst till Azure Storage med hjälp av SAS-token, Microsoft Entra-identitet för användare eller hanterad identitet för arbetsytan.

-- Create master key in databases with some password (one-off per database)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong password>'
GO

-- Create databases scoped credential that use Managed Identity, SAS token or service principal. User needs to create only database-scoped credentials that should be used to access data source:

CREATE DATABASE SCOPED CREDENTIAL WorkspaceIdentity
WITH IDENTITY = 'Managed Identity'
GO
CREATE DATABASE SCOPED CREDENTIAL SasCredential
WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'sv=2019-10-1********ZVsTOL0ltEGhf54N8KhDCRfLRI%3D'
GO
CREATE DATABASE SCOPED CREDENTIAL SPNCredential WITH
IDENTITY = '**44e*****8f6-ag44-1890-34u4-22r23r771098@https://login.microsoftonline.com/**do99dd-87f3-33da-33gf-3d3rh133ee33/oauth2/token' 
, SECRET = '.7OaaU_454azar9WWzLL.Ea9ePPZWzQee~'
GO
-- Create data source that one of the credentials above, external file format, and external tables that reference this data source and file format:

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat] WITH ( FORMAT_TYPE = PARQUET)
GO

CREATE EXTERNAL DATA SOURCE mysample
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
-- Uncomment one of these options depending on authentication method that you want to use to access data source:
--,CREDENTIAL = WorkspaceIdentity 
--,CREDENTIAL = SasCredential 
--,CREDENTIAL = SPNCredential
)

CREATE EXTERNAL TABLE dbo.userData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [mysample],
       FILE_FORMAT = [SynapseParquetFormat] );

Databasanvändaren kan läsa innehållet i filerna från datakällan med hjälp av den externa tabellen eller funktionen OPENROWSET som refererar till datakällan:

SELECT TOP 10 * FROM dbo.userdata;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet', DATA_SOURCE = 'mysample', FORMAT='PARQUET') as rows;
GO

Nästa steg

De här artiklarna hjälper dig att lära dig hur du frågar efter olika mapptyper, filtyper och skapar och använder vyer: