Använd virtual network service endpoints och regler för Azure Synapse Analytics

Gäller för: Dedikerade SQL-pooler i Azure Synapse Analytics

Regler för virtuella nätverk är en brandväggssäkerhetsfunktion som styr om den logiska servern för din dedikerade SQL-pool (tidigare SQL DW) databaser i Azure Synapse Analytics accepterar kommunikation som skickas från särskilda subnät i virtuella nätverk. Den här artikeln förklarar varför regler för virtuella nätverk ibland är ditt bästa alternativ för att säkert möjliggöra kommunikation till din dedikerade SQL-pool.

För att skapa en virtuell nätverksregel måste det först finnas en virtuell nätverkstjänstslutpunkt som regeln ska referera till.

Skapa en regel för virtuellt nätverk

Om du bara vill skapa en virtuell nätverksregel kan du hoppa vidare till stegen och förklaringen senare i denna artikel.

Detaljer om regler för virtuella nätverk

Detta avsnitt beskriver flera detaljer om regler för virtuella nätverk.

Endast en geografisk region

Varje slutpunkt för virtuella nätverkstjänster gäller endast för en Azure-region. Slutpunkten gör det inte möjligt för andra regioner att acceptera kommunikation från undernätet.

Varje virtuell nätverksregel är begränsad till det område som dess underliggande endpoint gäller för.

Servernivå, inte databasnivå

Varje virtuell nätverksregel gäller hela din server, inte bara en specifik databas på servern. Med andra ord gäller reglerna för virtuella nätverk på servernivå, inte på databasnivå.

Roller inom säkerhetsadministration

Det finns en separation av säkerhetsroller vid administrationen av virtuella nätverkstjänstslutpunkter. Åtgärder krävs från var och en av följande roller:

• Nätverksadministratör (Nätverksdeltagare): Slå på slutpunkt.
• Databasadministratör (SQL Server Contributor-roll): Uppdatera åtkomstkontrolllistan (ACL) för att lägga till det givna subnätet till servern.

Azure RBAC alternative

Rollerna som nätverksadministratör och databasadministratör har fler funktioner än vad som behövs för att hantera virtuella nätverksregler. Endast en delmängd av deras förmågor behövs.

Du har möjlighet att använda rollbaserad åtkomstkontroll (RBAC) i Azure för att skapa en enda anpassad roll som endast har den nödvändiga deluppsättningen av funktioner. Den anpassade rollen kan användas istället för att involvera antingen nätverksadministratören eller databasadministratören. Angreppsytan är mindre om du lägger till en användare i en anpassad roll jämfört med att lägga till användaren i de andra två stora administratörsrollerna.

Limitations

För fristående dedikerade SQL-pooler har funktionen för virtuella nätverksregler följande begränsningar:

• I brandväggen för din logiska server refererar varje virtuell nätverksregel till ett subnät. Alla refererade subnät måste vara hostade i samma geografiska region som den dedikerade SQL-poolen.
• Varje server kan ha upp till 128 ACL-poster för valfritt virtuellt nätverk.
• Reglerna för virtuella nätverk gäller endast för virtuella nätverk i Azure Resource Manager och inte för nätverk med klassisk distributionsmodell.
• På brandväggen gäller IP-adressintervall för följande nätverkselement, men virtuella nätverksregler gör det inte:
  • Site-to-site (S2S) virtuellt privat nätverk (VPN)
  • Lokalt via Azure ExpressRoute
• Båda prenumerationerna måste finnas i samma Microsoft Entra-tenant.

Överväganden när du använder tjänstslutpunkter

När du använder service-endpoints för en dedikerad SQL-pool, granska följande överväganden:

• Outbound access to Azure Synapse Analytics public IPS krävs. Nätverkssäkerhetsgrupper (NSG) måste tillåta anslutning till tjänstens IP-adresser. Du kan använda NSG:s Sql.

ExpressRoute

Om du använder ExpressRoute från din lokal, för offentlig peering eller Microsoft-peering, behöver du identifiera de NAT-IP-adresser som används. För publik peering använder varje ExpressRoute-krets som standard två NAT-IP-adresser som appliceras på Azure-tjänstetrafik när trafiken går in i Microsoft Azure-nätverksryggraden. För Microsoft-peering tillhandahålls de använda NAT-IP-adresserna antingen av kunden eller tjänsteleverantören. Om du vill tillåta åtkomst till dina tjänstresurser måste du tillåta dessa offentliga IP-adresser i resursens IP-brandväggsinställning. För att hitta dina IP-adresser för din publika peering ExpressRoute-krets, öppna ett supportärende hos ExpressRoute via Azure-portalen. För att lära dig mer om NAT för ExpressRoute public och Microsoft peering, se NAT-krav för Azure public peering.

För att tillåta kommunikation från din anslutning till Azure Synapse Analytics måste du skapa IP-nätverksregler för de publika IP-adresserna till din NAT.

Påverkan av att använda virtuella nätverksservice-endpoints med Azure Storage

Azure Storage har implementerat samma funktion som gör att du kan begränsa anslutningen till ditt Azure Storage-konto. Om du använder denna funktion med ett Azure Storage-konto som Azure Synapse Analytics använder kan du stöta på problem.

Följande avsnitt diskuterar de berörda funktionerna i Azure Synapse Analytics.

Azure Synapse Analytics PolyBase och COPY-instruktion

PolyBase och COPY-satsen används ofta för att ladda data till Azure Synapse Analytics från Azure Storage-konton för dataintag med hög genomströmning. Om Azure Storage-kontot som du laddar data från begränsar åtkomsten endast till en uppsättning virtuella nätverkssubnät, kommer anslutningen att brytas när du använder PolyBase och COPY-satsen mot lagringskontot. För att aktivera import- och exportscenarier genom att använda COPY och PolyBase med Azure Synapse Analytics som ansluter till Azure Storage som är säkrat i ett virtuellt nätverk, följ stegen i detta avsnitt.

Prerequisites

• Installera Azure PowerShell. Mer information finns i Installera Azure Az PowerShell-modulen.
• Om du har ett konto för generell användning v1 eller ett Azure Blob Storage-konto måste du först uppgradera till ett konto för generell användning v2 genom att följa stegen i Uppgradera till ett lagringskonto för generell användning v2.
• Du måste ha aktiverat Tillåt betrodda Microsoft-tjänster att komma åt detta lagringskonto under inställningsmenyn för Azure Storage-kontots brandväggar och virtuella nätverk. Att aktivera denna konfiguration gör att PolyBase och COPY-satsen kan ansluta till lagringskontot genom att använda stark autentisering där nätverkstrafiken finns kvar på Azure-ryggraden. För mer information, se denna guide.

Steps

1. Om du har en fristående dedikerad SQL-pool (tidigare SQL DW), registrera din SQL-server hos Microsoft Entra ID genom att använda PowerShell:

   Connect-AzAccount
   Select-AzSubscription -SubscriptionId <subscriptionId>
   Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
   

   Detta steg krävs inte för dedikerade SQL-pooler inom en Azure Synapse Analytics-arbetsyta. Den systemtilldelade hanterade identiteten (SA-MI) för arbetsytan är medlem i Synapse-administratörsrollen och har därmed utökade privilegier på arbetsytans dedikerade SQL-pooler.

2. Skapa ett General-purpose v2-lagringskonto genom att följa stegen i Skapa ett lagringskonto.

   • Om du har ett allmänt v1- eller Blob Storage-konto måste du först uppgradera till v2 genom att följa stegen i Uppgradera till ett allmänt v2-lagringskonto.
   • För kända problem med Azure Data Lake Storage Gen2, se Kända problem med Azure Data Lake Storage Gen2.

3. På din lagringskontosida, välj Access Control (IAM).

4. Välj Lägg till>rolltilldelning för att öppna sidan Lägg till rolltilldelning .

5. Tilldela följande roll. Detaljerade steg finns i Tilldela Azure-roller med hjälp av Azure-portalen.

   Setting	Value
   Role	Storage Blob Data-bidragsgivare
   Tilldela åtkomst till	Användaren, gruppen eller tjänstens huvudnamn
   Members	Server eller arbetsyta som är värd för din dedikerade SQL-pool som du har registrerat med Microsoft Entra ID

   

   Note

   Endast medlemmar med ägarbehörighet på lagringskontot kan utföra detta steg. För olika inbyggda roller i Azure, se Azure inbyggda roller.

6. För att möjliggöra PolyBase-anslutning till Azure Storage-kontot:

   1. Skapa en master key om du inte har gjort det tidigare.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];
      

   2. Skapa en autentiseringsuppgift med databasomfång med IDENTITY = 'Managed Service Identity'.

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      • Det finns inget behov av att specificera SECRET med en Azure Storage-åtkomstnyckel eftersom denna mekanism använder Managed Identity i bakgrunden. Detta steg krävs inte för dedikerade SQL-pooler inom en Azure Synapse Analytics-arbetsyta. Den systemtilldelade hanterade identiteten (SA-MI) för arbetsytan är medlem i Synapse-administratörsrollen och har därmed utökade privilegier på arbetsytans dedikerade SQL-pooler.

      • IDENTITY-namnet måste vara 'Managed Service Identity' för att PolyBase-anslutning ska fungera med ett Azure Storage-konto som är säkrat i ett virtuellt nätverk.

   3. Skapa en extern datakälla med schemat abfss:// för att ansluta till ditt lagringskonto av generell användning v2 med PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      • Om du redan har externa tabeller kopplade till ett allmänt v1-konto eller Blob Storage-konto, bör du först släppa dessa externa tabeller. Sedan tar du bort motsvarande externa datakälla. Därefter skapar du en extern datakälla med protokollet abfss:// som ansluter till ett allmänt v2-lagringskonto, som tidigare visats. Skapa sedan om alla externa tabeller med denna nya externa datakälla. Du kan använda Generate and Publish Scripts-guiden för att skapa skript för alla externa tabeller för enkelhet.
      • För mer information om abfss://URI-schemat, se Använd Azure Data Lake Storage Gen2-URI:n.
      • För mer information om T-SQL-kommandon, se CREATE EXTERNAL DATA SOURCE.

   4. Sök som vanligt genom att använda externa tabeller.

Azure Synapse Analytics granskning till Blob Storage

Azure Synapse Analytics auditing kan skriva SQL-granskningsloggar till ditt eget lagringskonto. Om detta lagringskonto använder funktionen virtuella nätverkstjänstslutpunkter, se hur man skriver granskningsloggar till ett lagringskonto bakom VNet och brandväggen.

Lägg till en virtuell nätverksbrandväggsregel i din dedikerade SQL-pool SQL-server

För länge sedan, innan denna funktion förbättrades, var du tvungen att aktivera tjänstslutpunkter för virtuella nätverk innan du kunde implementera en aktiv virtuell nätverksregel i brandväggen. Slutpunkterna kopplar ett givet virtuellt nätverkssubnät till en dedikerad SQL-pool. Från och med januari 2018 kan du kringgå detta krav genom att sätta IgnoreMissingVNetServiceEndpoint-flaggan . Nu kan du lägga till en brandväggsregel för virtuellt nätverk på din server utan att aktivera tjänstslutpunkter för virtuella nätverk.

Att bara sätta en brandväggsregel hjälper inte till att säkra servern. Du måste också aktivera virtuella nätverkstjänstslutpunkter för att säkerheten ska träda i kraft. När du aktiverar tjänstslutpunkter upplever undernätet i ditt virtuella nätverk driftstopp tills övergången från av till på är klar. Denna period av driftstopp stämmer särskilt i sammanhanget av stora virtuella nätverk. Du kan använda flaggan IgnoreMissingVNetServiceEndpoint för att minska eller eliminera driftstopp under övergången.

Du kan sätta flaggan IgnoreMissingVNetServiceEndpoint genom att använda PowerShell. För mer information, se New-AzSqlServerVirtualNetworkRule.

Använd Azure portal för att skapa en virtuell nätverksregel

I detta avsnitt får du lära dig hur du kan använda Azure-portalen för att skapa en virtuell nätverksregel för en fristående dedikerad SQL-pool. Regeln säger åt den logiska servern att acceptera kommunikation från ett visst subnät som har taggats som en virtuell nätverkstjänstslutpunkt.

Prerequisites

Du måste redan ha ett subnät som är taggat med den virtuella nätverkstjänstslutpunktens typnamn som används av Azure Synapse Analytics.

• Det relevanta ändpunktstypnamnet är Microsoft.Sql.
• Om ditt undernät kanske inte är taggat med typnamnet, se Verifiera att service-endpointen är aktiverad.

Steg i Azure-portalen

1. Logga in på Azure-portalen.

2. Sök efter och välj SQL-servrar, och välj sedan din server. Under Securityväljer du Nätverk.

3. På fliken Offentlig åtkomst, se till att Offentlig nätverksåtkomst är inställd på Välj nätverk, annars är inställningarna för virtuella nätverk dolda. Välj + Lägg till befintligt virtuellt nätverk i avsnittet Virtuella nätverk .

4. I det nya Skapa/Uppdatera-panelen, fyll i rutan med namnen på dina Azure-resurser.

   Tip

   Du måste inkludera rätt adressprefix för ditt subnät. Du kan hitta värdet adressprefix i portalen. Gå till Alla resurser>Alla typer>Virtuella nätverk. Filtret visar dina virtuella nätverk. Välj ditt virtuella nätverk och välj sedan Subnät. Kolumnen ADDRESS RANGE har adressprefixet du behöver.

5. Se den resulterande regeln för virtuellt nätverk på panelen Firewall.

6. Ställ in Tillåt Azure-tjänster och resurser att komma åt denna server till Nej.

   Important

   Om du låter Tillåt Azure-tjänster och resurser att komma åt denna server markerat, accepterar din server kommunikation från vilket subnät som helst inom Azure:s gräns. Det är kommunikation som kommer från en av IP-adresserna som känns igen som de inom intervall definierade för Azure-datacenter. Att lämna kontrollen aktiverad kan ge alltför omfattande åtkomst ur säkerhetssynpunkt. Funktionen för tjänstslutpunkter i Microsoft Azure Virtual Network kan tillsammans med virtuella nätverksregler i Azure Synapse Analytics minska din säkerhetsyta.

7. Välj OK-knappen nära botten av panelen.

Använd PowerShell för att skapa en virtuell nätverksregel

Ett skript kan också skapa virtuella nätverksregler genom att använda PowerShell-cmdlet New-AzSqlServerVirtualNetworkRule eller az network vnet create. För mer information, se New-AzSqlServerVirtualNetworkRule.

Använd REST API för att skapa en virtuell nätverksregel

Internt anropar PowerShell-cmdletarna för Synapse SQL:s virtuella nätverksåtgärder REST-API:er. Du kan anropa REST-API:erna direkt. För mer information, se Virtuella nätverksregler: Operationer.

Felsök fel 40914 och 40615

Anslutningsfel 40914 avser virtuella nätverksregler, som specificeras i brandväggspanelen i Azure-portalen.
Fel 40615 är liknande, förutom att det gäller IP-adressregler på brandväggen.

Fel 40914

Meddelandetext: "Kan inte öppna servern '[server-name]' som begärs av inloggningen. Klienten har inte tillstånd att ansluta till servern.”

Felbeskrivning: Klienten befinner sig i ett subnät som har virtuella nätverksserver-endpoints. Men servern har ingen virtuell nätverksregel som ger subnätet rätt att kommunicera med databasen.

Fellösning: På brandväggspanelen i Azure-portalen, använd kontrollen för virtuella nätverksregler för att lägga till en virtuell nätverksregel för subnätet.

Fel 40615

Meddelandetext: "Kan inte öppna server '{0}' som begärdes vid inloggningen. Klienten med IP-adress ‘{1}’ har inte tillstånd att ansluta till servern.”

Felbeskrivning: Klienten försöker ansluta från en IP-adress som inte är auktoriserad att ansluta till servern. Serverbrandväggen har ingen IP-adressregel som tillåter en klient att kommunicera från den givna IP-adressen till databasen.

Fellösning: Ange klientens IP-adress som en IP-regel. Använd Firewall-panelen i Azure-portalen för att göra detta steg.

Relaterat innehåll

• Tjänstslutpunkter för virtuellt nätverk i Azure
• Azure Synapse IP-brandväggsregler
• Använd New-AzSqlServerVirtualNetworkRule för att skapa en virtuell nätverksregel
• Regler för virtuellt nätverk: Operationer