Använda tjänstslutpunkter för virtuellt nätverk och regler för servrar i Azure SQL Database

  • Artikel

Gäller för:Azure SQL DatabaseAzure Synapse Analytics

Regler för virtuella nätverk är en brandväggssäkerhetsfunktion som styr om servern för dina databaser och elastiska pooler i Azure SQL Database eller för dina dedikerade SQL-pooldatabaser (tidigare SQL DW) i Azure Synapse Analytics accepterar kommunikation som skickas från vissa undernät i virtuella nätverk. Den här artikeln förklarar varför regler för virtuella nätverk ibland är det bästa alternativet för att på ett säkert sätt tillåta kommunikation till databasen i SQL Database och Azure Synapse Analytics.

Kommentar

Den här artikeln gäller både SQL Database och Azure Synapse Analytics. För enkelhetens skull refererar termen databas till båda databaserna i SQL Database och Azure Synapse Analytics. På samma sätt refererar alla referenser till servern till den logiska server som är värd för SQL Database och Azure Synapse Analytics.

Om du vill skapa en regel för virtuellt nätverk måste det först finnas en tjänstslutpunkt för virtuellt nätverk som regeln ska referera till.

Kommentar

Microsoft Entra-ID är det nya namnet för Azure Active Directory (Azure AD). Vi uppdaterar dokumentationen just nu.

Skapa en regel för virtuellt nätverk

Om du bara vill skapa en regel för virtuellt nätverk kan du gå vidare till stegen och förklaringen senare i den här artikeln.

Information om regler för virtuellt nätverk

Det här avsnittet beskriver flera detaljer om regler för virtuella nätverk.

Endast en geografisk region

Varje tjänstslutpunkt för virtuellt nätverk 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.

Alla regler för virtuella nätverk är begränsade till den region som dess underliggande slutpunkt gäller för.

Servernivå, inte databasnivå

Varje regel för virtuellt nätverk gäller för hela servern, inte bara för en viss databas på servern. Med andra ord gäller regler för virtuella nätverk på servernivå, inte på databasnivå.

IP-regler kan däremot tillämpas på båda nivåer.

Roller för säkerhetsadministration

Det finns en uppdelning av säkerhetsroller i administrationen av tjänstslutpunkter för virtuella nätverk. Åtgärden krävs från var och en av följande roller:

Alternativ för Azure RBAC

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

Du har möjlighet att använda rollbaserad åtkomstkontroll (RBAC) i Azure för att skapa en enda anpassad roll som bara har den nödvändiga delmängden av funktionerna. Den anpassade rollen kan användas i stället för att involvera antingen nätverksadministratören eller databasadministratören. Säkerhetsexponeringens yta är lägre 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å större administratörsrollerna.

Kommentar

I vissa fall finns databasen i SQL Database och undernätet för det virtuella nätverket i olika prenumerationer. I dessa fall måste du se till att följande konfigurationer:

  • Båda prenumerationerna måste finnas i samma Microsoft Entra-klientorganisation.
  • Användaren har de behörigheter som krävs för att initiera åtgärder, till exempel att aktivera tjänstslutpunkter och lägga till ett virtuellt nätverksundernät till den angivna servern.
  • Båda prenumerationerna måste ha Microsoft.Sql-providern registrerad.

Begränsningar

För SQL Database har funktionen regler för virtuella nätverk följande begränsningar:

  • I brandväggen för databasen i SQL Database refererar varje regel för virtuella nätverk till ett undernät. Alla dessa refererade undernät måste finnas i samma geografiska region som är värd för databasen.
  • Varje server kan ha upp till 128 ACL-poster för valfritt virtuellt nätverk.
  • Regler för virtuella nätverk gäller endast för virtuella Azure Resource Manager-nätverk och inte för klassiska distributionsmodellnätverk .
  • Om du aktiverar tjänstslutpunkter för virtuella nätverk till SQL Database kan du även aktivera slutpunkterna för Azure Database for MySQL och Azure Database for PostgreSQL. När slutpunkterna är inställda på PÅ kan försök att ansluta från slutpunkterna till Azure Database for MySQL- eller Azure Database for PostgreSQL-instanser misslyckas.
    • Den underliggande orsaken är att Azure Database for MySQL och Azure Database for PostgreSQL sannolikt inte har någon konfigurerad regel för virtuellt nätverk. Du måste konfigurera en regel för virtuellt nätverk för Azure Database for MySQL och Azure Database for PostgreSQL.
    • Om du vill definiera brandväggsregler för virtuella nätverk på en logisk SQL-server som redan har konfigurerats med privata slutpunkter anger du Neka åtkomst till offentligt nätverk till Nej.
  • I brandväggen gäller IP-adressintervall för följande nätverksobjekt, men regler för virtuella nätverk gör det inte:

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

När du använder tjänstslutpunkter för SQL Database läser du följande överväganden:

  • Utgående till offentliga IP-adresser i Azure SQL Database krävs. Nätverkssäkerhetsgrupper (NSG:er) måste öppnas för SQL Database-IP-adresser för att tillåta anslutning. Du kan göra detta med hjälp av NSG-tjänsttaggar för SQL Database.

ExpressRoute

Om du använder ExpressRoute från din lokala plats, för offentlig peering eller Microsoft-peering, måste du identifiera de NAT IP-adresser som används. För offentlig peering, använder varje ExpressRoute-krets som standard två NAT IP-adresser, som används för Azure-tjänsttrafik när trafiken kommer till Microsoft Azure-stamnätverket. För Microsoft-peering tillhandahålls DE NAT IP-adresser som används av antingen kunden eller tjänstleverantö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 kunna hitta ExpressRoute-kretsens IP-adresser för offentlig peering öppnar du en supportbegäran hos ExpressRoute via Azure-portalen. Mer information om NAT för offentlig ExpressRoute- och Microsoft-peering finns i NAT-krav för offentlig Azure-peering.

Om du vill tillåta kommunikation från kretsen till SQL Database måste du skapa IP-nätverksregler för nat-adressens offentliga IP-adresser.

Effekten av att använda tjänstslutpunkter för virtuellt nätverk 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 väljer att använda den här funktionen med ett Azure Storage-konto som SQL Database använder kan du stöta på problem. Nästa är en lista och diskussion om SQL Database- och Azure Synapse Analytics-funktioner som påverkas av detta.

Azure Synapse Analytics PolyBase- och COPY-instruktion

PolyBase och COPY-instruktionen används ofta för att läsa in data i Azure Synapse Analytics från Azure Storage-konton för datainmatning med högt dataflöde. Om Azure Storage-kontot som du läser in data från begränsar åtkomsten endast till en uppsättning virtuella nätverksundernät bryts anslutningen när du använder PolyBase och COPY-instruktionen till lagringskontot. Följ stegen i det här avsnittet för att aktivera import- och exportscenarier med COPY och PolyBase med Azure Synapse Analytics som ansluter till Azure Storage som är skyddat i ett virtuellt nätverk.

Förutsättningar

  • Installera Azure PowerShell. Mer information finns i Installera Azure Az PowerShell-modulen.
  • Om du har ett v1- eller Azure Blob Storage-konto för generell användning måste du först uppgradera till generell användning v2 genom att följa stegen i Uppgradera till ett allmänt v2-lagringskonto.
  • Du måste aktivera Tillåt betrodda Microsoft-tjänster för att få åtkomst till det här lagringskontot under inställningsmenyn Brandväggar och virtuella nätverk för Azure Storage-kontot. Om du aktiverar den här konfigurationen kan PolyBase och COPY-instruktionen ansluta till lagringskontot med hjälp av stark autentisering där nätverkstrafiken finns kvar i Azure-stamnätet. Mer information finns i den här guiden.

Viktigt!

PowerShell Azure Resource Manager-modulen stöds fortfarande av Azure SQL Database, men all framtida utveckling gäller för modulen Az.Sql . AzureRM-modulen fortsätter att ta emot felkorrigeringar fram till åtminstone december 2020. Argumenten för kommandona i Az-modulen och i AzureRm-modulerna är väsentligen identiska. Mer information om deras kompatibilitet finns i Introduktion till den nya Azure PowerShell Az-modulen.

Steg

  1. Om du har en fristående dedikerad SQL-pool (tidigare SQL DW) registrerar du DIN SQL-server med Microsoft Entra-ID med hjälp av PowerShell:

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

    Det här steget krävs inte för de dedikerade SQL-poolerna i 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 generellt v2-lagringskonto genom att följa stegen i Skapa ett lagringskonto.

  3. Välj Åtkomstkontroll (IAM) på sidan för lagringskontot.

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

  5. Tilldela följande roll. Läs mer om att tilldela roller i Tilldela Azure-roller via Azure Portal.

    Inställning Värde
    Role Storage Blob datadeltagare
    Tilldela åtkomst till Användaren, gruppen eller tjänstens huvudnamn
    Medlemmar Server eller arbetsyta som är värd för din dedikerade SQL-pool som du har registrerat med Microsoft Entra-ID

    Screenshot that shows Add role assignment page in Azure portal.

    Kommentar

    Endast medlemmar med ägarbehörighet på lagringskontot kan utföra det här steget. Olika inbyggda Azure-roller finns i Inbyggda Azure-roller.

  6. Så här aktiverar du PolyBase-anslutning till Azure Storage-kontot:

    1. Skapa en huvudnyckel för databasen om du inte har skapat en tidigare.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];

    2. Skapa en databasomfattande autentiseringsuppgift med IDENTITY = "Hanterad tjänstidentitet".

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

      • Du behöver inte ange SECRET med en Azure Storage-åtkomstnyckel eftersom den här mekanismen använder hanterad identitet under täcket. Det här steget krävs inte för de dedikerade SQL-poolerna i 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.

      • Identitetsnamnet måste vara "Hanterad tjänstidentitet" för att PolyBase-anslutningen ska fungera med ett Azure Storage-konto som är skyddat i ett virtuellt nätverk.

    3. Skapa en extern datakälla med abfss:// schemat för att ansluta till ditt allmänna v2-lagringskonto med hjälp av 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 som är associerade med ett allmänt v1- eller Blob Storage-konto bör du först släppa de externa tabellerna. Släpp sedan motsvarande externa datakälla. Skapa sedan en extern datakälla med schemat abfss:// som ansluter till ett generellt v2-lagringskonto, som tidigare visats. Återskapa sedan alla externa tabeller med hjälp av den här nya externa datakällan. Du kan använda guiden Generera och publicera skript för att generera create-scripts för alla externa tabeller för enkelhetens skull.
      • Mer information om schemat finns i abfss:// Använda Azure Data Lake Storage Gen2 URI.
      • Mer information om T-SQL-kommandona finns i SKAPA EXTERN DATAKÄLLA.

    4. Fråga som vanligt med hjälp av externa tabeller.

GRANSKNING av SQL Database-blob

Azure SQL-granskning kan skriva SQL-granskningsloggar till ditt eget lagringskonto. Om det här lagringskontot använder funktionen för tjänstslutpunkter för virtuella nätverk kan du läsa om hur du skriver granskning till ett lagringskonto bakom VNet och brandväggen.

Lägga till en brandväggsregel för virtuellt nätverk på servern

För länge sedan, innan den här funktionen förbättrades, var du skyldig att aktivera tjänstslutpunkter för virtuella nätverk innan du kunde implementera en regel för virtuellt nätverk i brandväggen. Slutpunkterna relaterade ett visst virtuellt nätverksundernät till en databas i SQL Database. Från och med januari 2018 kan du kringgå det här kravet genom att ange flaggan IgnoreMissingVNetServiceEndpoint . Nu kan du lägga till en brandväggsregel för virtuellt nätverk till servern utan att aktivera tjänstslutpunkter för virtuella nätverk.

Att bara ange en brandväggsregel hjälper inte till att skydda servern. Du måste också aktivera tjänstslutpunkter för virtuella nätverk för att säkerheten ska börja gälla. När du aktiverar tjänstslutpunkter upplever ditt virtuella nätverksundernät driftstopp tills övergången har slutförts från inaktiverad till på. Den här stilleståndstiden gäller särskilt i samband med stora virtuella nätverk. Du kan använda flaggan IgnoreMissingVNetServiceEndpoint för att minska eller eliminera stilleståndstiden under övergången.

Du kan ange flaggan IgnoreMissingVNetServiceEndpoint med hjälp av PowerShell. Mer information finns i PowerShell för att skapa en tjänstslutpunkt och regel för virtuellt nätverk för SQL Database.

Kommentar

Liknande instruktioner i Azure Synapse Analytics finns i Ip-brandväggsregler för Azure Synapse Analytics

Använda Azure-portalen för att skapa en regel för virtuellt nätverk

Det här avsnittet visar hur du kan använda Azure-portalen för att skapa en regel för virtuellt nätverk i databasen i SQL Database. Regeln instruerar din databas att acceptera kommunikation från ett visst undernät som har taggats som en tjänstslutpunkt för virtuellt nätverk.

Kommentar

Om du tänker lägga till en tjänstslutpunkt i brandväggsreglerna för det virtuella nätverket på servern kontrollerar du först att tjänstslutpunkter är aktiverade för undernätet.

Om tjänstslutpunkter inte är aktiverade för undernätet ber portalen dig att aktivera dem. Välj knappen Aktivera i samma fönster där du lägger till regeln.

Förutsättningar

Du måste redan ha ett undernät som är taggat med det specifika namnet på tjänstslutpunkten för virtuellt nätverk som är relevant för SQL Database.

Steg i Azure-portalen

  1. Logga in på Azure-portalen.

  2. Sök efter och välj SQL-servrar och välj sedan servern. Under Säkerhet väljer du Nätverk.

  3. Under fliken Offentlig åtkomst kontrollerar du att Åtkomst till offentligt nätverk är inställt 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 .

    Screenshot that shows logical server properties for Networking.

  4. I det nya fönstret Skapa/uppdatera fyller du i rutorna med namnen på dina Azure-resurser.

    Dricks

    Du måste inkludera rätt adressprefix för undernätet. Du hittar värdet för adressprefixet 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 Undernät. Kolumnen ADRESSINTERVALL har det adressprefix du behöver.

    Screenshot that shows filling in boxes for the new rule.

  5. Se den resulterande regeln för virtuellt nätverk i fönstret Brandvägg .

    Screenshot that shows the new rule on the Firewall pane.

  6. Ange Tillåt Att Azure-tjänster och resurser får åtkomst till den här servern till Nej.

    Viktigt!

    Om du låter Tillåt Azure-tjänster och resurser att komma åt den här servern är markerat accepterar servern kommunikation från alla undernät inom Azure-gränsen. Det är kommunikation som kommer från en av de IP-adresser som identifieras som de inom de intervall som definierats för Azure-datacenter. Att lämna kontrollen aktiverad kan vara överdriven åtkomst ur säkerhetssynpunkt. Tjänstens slutpunktsfunktion i Microsoft Azure Virtual Network i samordning med funktionen för regler för virtuella nätverk i SQL Database tillsammans kan minska din säkerhetsyta.

  7. Välj knappen OK längst ned i fönstret.

Kommentar

Följande statusar eller tillstånd gäller för reglerna:

  • Klar: Anger att åtgärden som du initierade har slutförts.
  • Misslyckades: Anger att åtgärden som du initierade misslyckades.
  • Borttagen: Gäller endast för åtgärden Ta bort och anger att regeln har tagits bort och inte längre gäller.
  • InProgress: Anger att åtgärden pågår. Den gamla regeln gäller när åtgärden är i det här tillståndet.

Använda PowerShell för att skapa en regel för virtuellt nätverk

Ett skript kan också skapa regler för virtuella nätverk med hjälp av PowerShell-cmdleten New-AzSqlServerVirtualNetworkRule eller az network vnet create. Mer information finns i PowerShell för att skapa en tjänstslutpunkt och regel för virtuellt nätverk för SQL Database.

Använda REST API för att skapa en regel för virtuellt nätverk

Internt anropar PowerShell-cmdletar för SQL-åtgärder för virtuella nätverk REST-API:er. Du kan anropa REST-API:erna direkt. Mer information finns i Regler för virtuellt nätverk: Åtgärder.

Felsöka felen 40914 och 40615

Anslut ionsfel 40914 gäller regler för virtuella nätverk enligt beskrivningen i fönstret Brandvägg i Azure-portalen. Fel 40615 liknar det, förutom att det gäller IP-adressregler i brandväggen.

Fel 40914

Meddelandetext: "Det går inte att öppna servern [servernamn] som begärdes vid inloggningen. Klienten har inte tillstånd att ansluta till servern.”

Felbeskrivning: Klienten finns i ett undernät som har serverslutpunkter för virtuellt nätverk. Men servern har ingen regel för virtuellt nätverk som ger undernätet rätt att kommunicera med databasen.

Felmatchning: I fönstret Brandvägg i Azure-portalen använder du kontrollen regler för virtuellt nätverk för att lägga till en regel för virtuellt nätverk för undernätet.

Fel 40615

Meddelandetext: "Det går inte att öppna servern"{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 har behörighet att ansluta till servern. Serverbrandväggen har ingen IP-adressregel som gör att en klient kan kommunicera från den angivna IP-adressen till databasen.

Felmatchning: Ange klientens IP-adress som en IP-regel. Använd fönstret Brandvägg i Azure-portalen för att göra det här steget.

Nästa steg