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
- Signatur för delad åtkomst
- Tjänstens huvud
- Hanterad tjänstidentitet
- Anonym åtkomst
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 |
- Användaridentitet
- Signatur för delad åtkomst
- Tjänstens huvud
- Hanterad tjänstidentitet
- Anonym åtkomst
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
- Sök efter ditt lagringskonto i Azure-portalen.
- I huvudnavigeringsmenyn går du till Nätverk under Inställningar.
- I avsnittet Resursinstanser lägger du till ett undantag för din Azure Synapse-arbetsyta.
- Välj
Microsoft.Synapse/workspaces
som resurstyp. - Välj namnet på arbetsytan som instansnamn.
- 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.
Öppna PowerShell eller installera PowerShell.
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
Anslut till din Azure-klientorganisation:
Connect-AzAccount
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 .Lägg till en nätverksregel för Azure Storage-konto:
$parameters = @{ ResourceGroupName = $resourceGroupName Name = $accountName TenantId = $tenantId ResourceId = $resourceId } Add-AzStorageAccountNetworkRule @parameters
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-identitet
- Signatur för delad åtkomst
- Tjänstens huvud
- Hanterad identitet
- Offentlig åtkomst
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: