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

GÄLLER FÖR: Azure SQL Database Azure 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 specifika 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 din databas i SQL Database och Azure Synapse Analytics.

Anteckning

Den här artikeln gäller både för 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 SQL 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.

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

I det här avsnittet beskrivs 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 virtuellt 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.

Säkerhetsadministrationsroller

Det finns en uppdelning av säkerhetsroller i administrationen av tjänstslutpunkter för virtuella nätverk. Åtgärd 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 funktioner. Den anpassade rollen kan användas i stället för att involvera antingen nätverksadministratören eller databasadministratören. Ytan för din säkerhetsexponering är lägre om du lägger till en användare i en anpassad roll jämfört med om du lägger till användaren i de andra två större administratörsrollerna.

Anteckning

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

  • Båda prenumerationerna måste finnas i samma Azure Active Directory (Azure AD) 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 undernät för virtuellt nätverk på 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 virtuellt 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 alla virtuella nätverk.
  • Regler för virtuellt nätverk gäller endast Azure Resource Manager virtuella nätverk och inte på klassiska distributionsmodellnätverk.
  • Om du aktiverar tjänstslutpunkter för virtuellt SQL Database aktiveras även 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 förmodligen inte har någon konfigurerad regel för virtuellt nätverk. Du måste konfigurera en regel för virtuellt Azure Database for MySQL och Azure Database for PostgreSQL så att anslutningen lyckas.
    • Om du vill definiera brandväggsregler för virtuella nätverk SQL en logisk server som redan har konfigurerats med privata slutpunkter anger du Neka offentlig nätverksåtkomst till Nej.
  • IP-adressintervall i brandväggen gäller för följande nätverksobjekt, men inte regler för virtuellt nätverk:

Att tänka på när du använder tjänstslutpunkter

När du använder tjänstslutpunkter för SQL Database bör du tänka på följande:

  • Utgående till Azure SQL Database offentliga IP-adresser krävs. Nätverkssäkerhetsgrupper (NSG: er) måste öppnas för att 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 lokalt 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 Azures offentliga peering.

Om du vill tillåta kommunikation från kretsen till SQL Database måste du skapa IP-nätverksregler för de offentliga IP-adresserna för din NAT.

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 Azure Storage konto som SQL Database använder kan du få 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 till Azure Synapse Analytics från Azure Storage-konton för datainmatning med högt dataflöde. Om det Azure Storage-konto som du läser in data från begränsar endast åtkomst till en uppsättning virtuella nätverksundernät, bryts anslutningen när du använder PolyBase och COPY-instruktionen till lagringskontot. Om du vill aktivera import- och exportscenarier genom att använda COPY och PolyBase med Azure Synapse Analytics som ansluter till Azure Storage som är skyddade i ett virtuellt nätverk följer du stegen i det här avsnittet.

Förutsättningar

  • Installera Azure PowerShell med hjälp av den här guiden.
  • Om du har ett konto för generell användning v1 eller Azure Blob Storage måste du först uppgradera till generell användning v2 genom att följa stegen i Uppgradera till ett v2-lagringskontoför generell användning.
  • Du måste ha Tillåt betrodda Microsoft-tjänster åtkomst till det här lagringskontot aktiverat under inställningsmenyn för Azure Storage-kontoBrandväggen och virtuella nätverk. 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ätverket. Mer information finns i den här guiden.

Viktigt

PowerShell Azure Resource Manager modulen stöds fortfarande av SQL Database, men all framtida utveckling är för Az.Sql-modulen. 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 betydligt 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 registrerar du din SQL med Azure AD 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 dedikerade SQL i en Azure Synapse Analytics arbetsyta.

  2. Om du har en Azure Synapse Analytics arbetsyta registrerar du arbetsytans system hanterade identitet:

    1. Gå till Azure Synapse Analytics arbetsyta i Azure Portal.
    2. Gå till fönstret Hanterade identiteter.
    3. Kontrollera att alternativet Tillåt pipelines är aktiverat.
  3. Skapa ett v2-konto för generell Storage genom att följa stegen i Skapa ett lagringskonto.

    Anteckning

  4. Under ditt lagringskonto går du till Access Control (IAM) och väljer Lägg till rolltilldelning. Tilldela Azure Storage-rollen Blob Data-deltagare till den server eller arbetsyta som är värd för din dedikerade SQL-pool, som du har registrerat med Azure AD.

    Anteckning

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

  5. Så här aktiverar du PolyBase-anslutning till Azure Storage konto:

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

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
      
    2. Skapa databasomfångsbaserade autentiseringsuppgifter med IDENTITY = "Hanterad tjänstidentitet".

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

      Anteckning

      • Du behöver inte ange SECRET med en Azure Storage åtkomstnyckel eftersom den här mekanismen använder hanterad identitet under omslaget.
      • Identitetsnamnet ska 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 schemat abfss:// för att ansluta till ditt allmänna v2-lagringskonto med PolyBase.

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

      Anteckning

      • Om du redan har externa tabeller som är associerade med ett konto för generell användning v1 eller Blob Storage bör du först ta bort dessa externa tabeller. Ta sedan bort motsvarande externa datakälla. Skapa sedan en extern datakälla med schemat som ansluter till ett abfss:// v2-lagringskonto för generell användning, som tidigare visats. Skapa sedan om alla externa tabeller med hjälp av den nya externa datakällan. Du kan enkelt generera create-scripts för alla externa tabeller med hjälp av guiden Generera och publicera skript.
      • Mer information om schemat abfss:// finns i Använda Azure Data Lake Storage Gen2 URI.
      • Mer information om HUR DU SKAPAR EXTERN DATAKÄLLA finns i den här guiden.
    4. Fråga som vanligt med hjälp av externa tabeller.

SQL Database blobgranskning

Azure SQL-granskning kan skriva SQL till ditt eget lagringskonto. Om det här lagringskontot använder funktionen tjänstslutpunkter för virtuellt 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, behövde du aktivera tjänstslutpunkter för virtuellt nätverk innan du kunde implementera en regel för virtuellt nätverk i brandväggen. Slutpunkterna relaterar 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 på servern utan att aktivera tjänstslutpunkter för virtuellt nätverk.

Att bara ange en brandväggsregel hjälper inte att skydda servern. Du måste också aktivera tjänstslutpunkter för virtuellt nätverk för att säkerheten ska gälla. När du aktiverar tjänstslutpunkter har det virtuella nätverkets undernät stilleståndstid tills övergången från avstängd till på är klar. Den här stilleståndstiden gäller särskilt för stora virtuella nätverk. Du kan använda flaggan IgnoreMissingVNetServiceEndpoint för att minska eller eliminera avbrottstiden 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 regelför virtuellt nätverk för SQL Database .

Felen 40914 och 40615

Anslutningsfel 40914 relaterar till regler för virtuellt nätverk som anges i brandväggsfönstret i Azure Portal. Fel 40615 är liknande, 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 åtkomst till servern."

Felbeskrivning: Klienten finns i ett undernät som har serverslutpunkter för virtuellt nätverk. Servern har dock ingen regel för virtuellt nätverk som ger undernätet behörighet att kommunicera med databasen.

Fellösning: I fönstret Brandvägg i fönstret Azure Portal du kontrollen för 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-adressen {1} " " får inte åtkomst 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.

Fellösning: Ange klientens IP-adress som en IP-regel. Använd brandväggsfönstret i fönstret Azure Portal att göra det här steget.

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

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

Anteckning

Om du planerar att lägga till en tjänstslutpunkt i brandväggsreglerna för det virtuella nätverket på servern måste du först se till att tjänstslutpunkter är påslagna för undernätet.

Om tjänstslutpunkter inte är aktiverat 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.

PowerShell-alternativ

Ett skript kan också skapa regler för virtuellt nätverk med hjälp av PowerShell-cmdleten New-AzSqlServerVirtualNetworkRule eller az network vnet create. Om du är intresserad kan du gå till PowerShell för att skapa en tjänstslutpunkt och regelför virtuellt nätverk för SQL Database .

REST API alternativ

Internt anropar PowerShell-cmdlets för SQL virtuella nätverk REST API:er. Du kan anropa REST-API:erna direkt.

Förutsättningar

Du måste redan ha ett undernät som är taggat med det specifika tjänstslutpunktsnamnet för det virtuella nätverket som är relevant för SQL Database.

Azure Portal steg

  1. Logga in på Azure-portalen.

  2. Sök efter och välj SQL servrar och välj sedan din server. Under Säkerhet väljer du Brandväggar och virtuella nätverk.

  3. Ställ in Tillåt åtkomst till Azure-tjänsterAV.

    Viktigt

    Om du lämnar kontrollen inställd på 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 intervall som definierats för Azure-datacenter. Att lämna kontrollen på kan vara för hög åtkomst ur säkerhetssynpunkt. Funktionen Microsoft Azure Virtual Network tjänstslutpunkt tillsammans med funktionen för regler för virtuellt nätverk i SQL Database tillsammans kan minska din säkerhetsyta.

  4. Välj + Lägg till befintlig i avsnittet Virtuella nätverk.

    Skärmbild som visar hur du väljer + Lägg till befintlig (undernätsslutpunkt som en SQL regel).

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

    Tips

    Du måste inkludera rätt adressprefix för ditt undernät. Du hittar värdet för Adressprefix i portalen. Gå till Alla resurser Alla typer > av 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 som du behöver.

    Skärmbild som visar hur du fyller i rutor för den nya regeln.

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

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

    Skärmbild som visar den nya regeln i fönstret Brandvägg.

Anteckning

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

  • Klar: Anger att åtgärden som du initierade har lyckats.
  • Misslyckades: Anger att åtgärden som du initierade har misslyckats.
  • Borttagna: Gäller endast för borttagningsåtgärden 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.

Nästa steg