Beveiligingsmogelijkheden en -taken
SQL Server en Azure SQL-services zijn bekend vanwege het belang dat zij hechten aan beveiliging, die van bedrijfsklasse is. In deze les krijgt u informatie over de verschillende beveiligingsmogelijkheden met betrekking tot netwerkbeveiliging en toegangsbeheer. In de volgende lessen krijgt u praktische ervaring met een aantal van deze mogelijkheden.
Netwerkbeveiliging
De eerste beveiligingslaag omvat het netwerk. De netwerkmogelijkheden en -taken verschillen tussen Azure SQL Database en Azure SQL Managed Instance. Zie Verbinding maken iviteitsarchitectuur voor Azure SQL Managed Instance voor meer informatie over de netwerkmogelijkheden van Azure SQL Managed Instance.
Azure SQL Database-netwerkbeveiliging
Wanneer u uw netwerk wilt beveiligen voor Azure SQL Database, beschikt u over vier hoofdopties:
- Toegang tot Azure-services toestaan
- Firewallregels gebruiken
- Regels voor virtuele netwerken gebruiken
- Azure Private Link gebruiken
Naast deze belangrijkste keuzes kunt u alle openbare toegang blokkeren (alleen met Azure Private Link) en de optie om een minimale TLS-versie (Transport Layer Security) af te dwingen. De minst veilige methode, maar de methode die het eenvoudigste is te configureren, is om toegang tot Azure-services toe te staan. De veiligste methode is om Private Link te gebruiken. In de volgende secties vindt u informatie over de mogelijkheden voor elke optie, en over hoe u elke optie kunt configureren en onderhouden.
Toegang tot Azure-services toestaan
Tijdens de implementatie van Azure SQL Database hebt u de mogelijkheid om Azure-services en -resources toegang tot deze server in te stellen op Ja. Als u deze optie kiest, staat u resources uit elke regio of elk abonnement toe om toegang te krijgen tot uw resource. Met deze optie kunt u gemakkelijk aan de slag gaan en Azure SQL Database verbinden met andere services, zoals virtuele Azure-machines, Azure App Service of zelfs de Azure Cloud Shell, omdat u alles dat via Azure komt toestaat om verbinding te kunnen maken.
Het toestaan van toegang tot Azure-services betekent echter niet dat iets buiten Azure (bijvoorbeeld uw on-premises omgeving) toegang heeft.
De veiligste configuratie is het instellen van toegang tot Azure-services en -resources tot deze server tot Nee, waardoor alle verbindingen en netwerken worden geblokkeerd, afgezien van de verbindingen en netwerken die u expliciet hebt toegevoegd met de verschillende opties die in de volgende secties worden gevolgd.
Firewallregels
Uw volgende optie bestaat uit het toepassen van firewallregels. Uw resultaten zijn mogelijk vergelijkbaar met die van Azure-services en -resources toegang tot deze server toestaan, behalve dat u voor elke service (in de volgende afbeelding, een virtuele machine (VM)) een unieke firewallregel moet toevoegen om verbinding te kunnen maken. Met firewallregels kan uw on-premises omgeving ook verbinding maken met de Azure SQL Database-resource, omdat u de regels voor machines en toepassingen in uw on-premises omgeving kunt toevoegen.
Om verbinding te krijgen in Azure, kunt u ook toegang tot Azure-services toestaan en vervolgens firewallregels toevoegen voor alleen uw on-premises verbinding. Zoals eerder vermeld, is Azure-services en -resources toegang tot deze server niet zo veilig, omdat hiermee al het Azure-verkeer wordt toegestaan. U wordt aangeraden uitsluitend firewallregels te gebruiken.
Laten we eens kijken naar het voorgaande voorbeeld met de firewallregels die zijn geconfigureerd. Vanuit een hulpprogramma dat Transact-SQL (T-SQL) ondersteunt, zoals SQL Server Management Studio (SSMS), kunt u de volgende query uitvoeren vanuit uw Azure-VM in het virtuele netwerk SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Het resultaat wordt 174.17.218.16. Dit is het openbare IP-adres van de Virtuele Azure-machine. Hoewel we firewallregels gebruiken, zijn alle verbindingen openbaar.
Regels voor virtuele netwerken
Als u alleen firewallregels wilt gebruiken, kan het ingewikkeld zijn om in te stellen. Als u alleen firewallregels gebruikt, moet u een bereik van IP-adressen opgeven voor al uw verbindingen, die soms dynamische IP-adressen kunnen hebben. Een veel eenvoudiger alternatief is het gebruik van regels voor virtuele netwerken om toegang tot specifieke netwerken met VM's of andere services die toegang nodig hebben tot de gegevens tot stand te brengen en te beheren.
Als u de toegang vanaf een virtueel netwerk met een regel voor het virtuele netwerk configureert, hebben alle bronnen in dat virtuele netwerk toegang tot de logische server van Azure SQL Database. Dit kan de uitdaging van het configureren van toegang tot alle vaste en dynamische IP-adressen die toegang nodig hebben tot de gegevens vereenvoudigen. Met regels voor virtuele netwerken kunt u een of meerdere virtuele netwerken opgeven, die alle resources binnen de netwerken omvatten. U kunt ook gebruikmaken van virtuele netwerktechnologieën om netwerken te verbinden tussen regio's in zowel Azure als on-premises.
In dit voorbeeld kunt u dezelfde query uitvoeren als in de vorige sectie van uw Azure-VM in het virtuele netwerk SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Het resultaat wordt nu 10.0.0.2. Dit is het privé-IP-adres van de virtuele Azure-machine. Hiermee komt u een stap dichter bij het maken van privéverbindingen met de logische server van Azure SQL Database, omdat resources nu verbinding maken via het virtuele netwerk.
Een andere algemene strategie voor het analyseren van uw verbinding is het onderzoeken van de DNS-hiërarchie (Domain Name System). Op dezelfde Azure-VM kunt u in een opdrachtprompt de volgende opdracht uitvoeren:
nslookup aw-server.database.windows.net
Met deze opdracht kunt u details ophalen die betrekking hebben op de DNS-infrastructuur. Uw resultaten zijn vergelijkbaar met het volgende:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
Onder het niet-bindende antwoord zijn enkele belangrijke dingen die u moet bekijken:
- Naam: Het eindpunt dat begint met
cr2, maakt deel uit van de openbare DNS-hiërarchie. Zonder te veel in de hiërarchie te komen, laten we zeggen datcr2het besturingsring 2 is en dat er meerdere gegevens 'segmenten' eronder staan. - Adres: het IP-adres dat hier wordt geretourneerd, moet overeenkomen met het openbare IP-adres van uw Azure-VM. Hoewel een hulpprogramma zoals de laatste hop van SSMS zich mogelijk via het privé-IP-adres van uw VIRTUELE machine bevindt, wordt het openbare IP-adres van uw VIRTUELE machine nog steeds gebruikt om verbinding te maken in een bepaalde capaciteit.
- Aliassen: Aliassen zijn verschillende punten in de DNS-hiërarchie; in dit geval het specifieke gegevenssegment en eindpunt waarmee u verbinding maakt.
Notitie
In het voorgaande uitvoerblok is Adres: 168.63.129.16 een virtueel openbaar IP-adres dat wordt gebruikt om een communicatiekanaal naar Azure-platformbronnen te vergemakkelijken. Het is van toepassing op alle regio's en alle nationale clouds, en verandert niet.
Hoewel de verbinding via SSMS afkomstig is van het privé-IP-adres van de Azure-VM, maakt u uiteindelijk nog steeds verbinding via een openbaar eindpunt.
Private Link voor een Azure SQL Database
U hebt gezien hoe u het veiligste netwerk configureert met behulp van uw database in Azure SQL Database met het openbare eindpunt. Deze methode voor het beveiligen van een database in SQL Database is jarenlang gebruikt. In 2019 ging Azure echter in de richting van het concept van een Private Link. Dit is meer vergelijkbaar met de manier waarop Azure SQL Managed Instance wordt geïmplementeerd. Met Azure Private Link kunt u verbinding maken met uw database in SQL Database en verschillende andere PaaS-aanbiedingen (Platform as a Service) met behulp van een privé-eindpunt. Dit betekent dat het een privé-IP-adres binnen een specifiek virtueel netwerk heeft.
In het vorige voorbeeld ziet u dat de algemene netwerkinfrastructuur niet is gewijzigd en u kunt nog steeds de strategieën voor virtuele netwerkconnectiviteit toepassen op basis van de regels voor virtuele netwerken. U hoeft echter geen regels voor virtuele netwerken te maken. Resources die verbinding moeten maken met de databaseserver moeten toegang hebben tot het virtuele netwerk waarin het eindpunt zich bevindt. In het voorbeeld is SQLDBVNet-EUShet eindpunt . Alleen verbindingen die via het privé-eindpunt gaan hebben toegang, en alle andere verbindingen (bijvoorbeeld van internet) worden geweigerd.
Terwijl u doorgaat met dit voorbeeld, kunt u op de Virtuele Azure-machine in het virtuele netwerk SQLDBVNet-EUSde volgende T-SQL-opdracht opnieuw uitvoeren:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Het resultaat is 10.0.0.2nu: het privé-IP-adres van de Azure-VM in dit voorbeeld. Als u toegang vanuit uw virtuele netwerk toevoegt, worden verbindingen met Azure SQL Database vanaf uw VIRTUELE machine weergegeven via het privé-IP-adres van uw VIRTUELE machine. Dit heeft hetzelfde resultaat als dat u hebt gezien met regels voor virtuele netwerken.
Mogelijk wilt u gebruikmaken van de opdrachtprompt om de DNS-hiërarchie te bekijken. Gebruik hiervoor de volgende opdracht:
nslookup aw-server.database.windows.net
Als u de voorgaande opdracht gebruikt, zijn de resultaten iets anders als het privé-eindpunt is geconfigureerd:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
Onder het niet-bindende antwoord zijn enkele belangrijke dingen die u moet bekijken:
- Naam: Houd er rekening mee dat u niet langer verwijst naar de openbare DNS-hiërarchie, alleen naar de Private Link DNS. Dit betekent dat er minder informatie wordt weergegeven over uw databaseserver.
- Adressen: Voor regels voor virtuele netwerken is het adres dat wordt geretourneerd het openbare IP-adres van uw VIRTUELE machine, maar dit moet nu een of meer privé-IP-adressen zijn binnen de Private Link-hiërarchie (een is het privé-eindpunt van uw Azure SQL Database).
- Aliassen: Zoals in het veld Naam is er niets gerelateerd aan de DNS-hiërarchie, behalve dat u nog steeds verbinding kunt maken met de servernaam (bijvoorbeeld
aw-server.database.windows.net).
Een ding dat u zich misschien afvraagt of u verbinding maakt met het privé-eindpunt, is waarom gebruikt u nog steeds dezelfde servernaam? Wanneer u in de back-end alleen de Private Link-methode gebruikt om verbinding te maken met Azure SQL Database (dat wil gezegd, geen firewall- of virtuele netwerkregels), wordt de informatie als volgt verwerkt:
aw-server.database.windows.net- Door service omgezet naar
aw-server.privatelink.database.net- Door service omgezet naar
10.0.0.5(het IP-adres van uw privé-eindpunt)
- Door service omgezet naar
- Door service omgezet naar
Daarnaast blokkeert de service dat u rechtstreeks verbinding maakt met behulp van iets anders dan aw-server.database.windows.net.
Toegangsbeheer
Nadat u de netwerktoegang hebt uitgewerkt, is toegangsbeheer de volgende laag die u moet overwegen.
Op rollen gebaseerd toegangsbeheer
Alle Azure-typen bewerkingen voor Azure SQL Database worden beheerd via op rollen gebaseerd toegangsbeheer (RBAC). RBAC is momenteel losgekoppeld van Azure SQL-beveiliging, maar u kunt het beschouwen als beveiligingsrechten buiten uw database in SQL Database, met een bereik dat abonnement, resourcegroep en resource omvat. De rechten zijn van toepassing op bewerkingen in Azure Portal, de Azure CLI en Azure PowerShell. Met op rollen gebaseerd toegangsbeheer (RBAC) kunt u taken scheiden tussen implementatie, beheer en gebruik.
Ingebouwde rollen zijn beschikbaar om de behoefte aan RBAC-rollen op een hoger niveau te verminderen, zoals Eigenaar of Inzender. In feite kunt u deze rollen gebruiken om bepaalde personen Azure SQL-resources te laten implementeren (of beveiligingsbeleid te beheren), maar andere gebruikers daadwerkelijk toegang verlenen om de database te gebruiken of te beheren. Een INzender voor SQL Server kan bijvoorbeeld een server implementeren en een gebruiker toewijzen aan de beheerder van de server en databases. De ingebouwde rollen voor Azure SQL Database omvatten:
- Inzender voor SQL DB: kan databases maken en beheren, maar heeft geen toegang tot de database (kan bijvoorbeeld geen verbinding maken en gegevens lezen)
- SQL Security Manager: kan beveiligingsbeleid voor databases en exemplaren (zoals controle) beheren, maar heeft geen toegang tot deze beleidsregels
- Inzender voor SQL Server: kan servers en databases beheren, maar heeft geen toegang tot deze servers.
Verificatie
Tijdens de implementatie van een logische Azure SQL Database-server kunt u de volgende verificatiemethode opgeven:
- Alleen Microsoft Entra-verificatie gebruiken
- Sql- en Microsoft Entra-verificatie gebruiken
- SQL-verificatie gebruiken
De serverbeheerder moet worden ingesteld tijdens de implementatie. Voor databases in Azure SQL Database is de serverbeheerder een principal op serverniveau voor de logische Server van Azure SQL Database.
Als u een workload migreert waarvoor Windows-verificatie is vereist of als uw organisatie Gebruikmaakt van Microsoft Entra-id, kunt u Microsoft Entra-id gebruiken. U kunt een Microsoft Entra-serverbeheerder toewijzen met behulp van de portal of opdrachtregelprogramma's.
Microsoft Entra-only-verificatie is de standaardoptie bij het configureren van een nieuwe server. Serveraanmelding is geïntroduceerd om Microsoft Entra-server-principals toe te staan. Dit zijn aanmeldingen in de virtuele master database van een SQL Database. U kunt Microsoft Entra-aanmeldingen maken van Microsoft Entra-gebruikers , -groepen en -service-principals. Wanneer u alleen Microsoft Entra-verificatie gebruikt, kunt u SQL-verificatieaanmelding maken en blijven bestaande aanmeldingen behouden. Alleen aanmeldingen bij Microsoft Entra-verificatie en gebruikers kunnen echter verbinding maken met de logische server. Zie Microsoft Entra-only-verificatie met Azure SQL voor meer informatie over Microsoft Entra-only-verificatie.
Afhankelijk van hoe uw organisatie het Microsoft Entra-exemplaar heeft geconfigureerd, kunt u er verbinding mee maken met behulp van een van de volgende drie methoden (bijvoorbeeld in SSMS):
Microsoft Entra ID - Geïntegreerd: een niet-interactieve methode die u kunt gebruiken als u bent aangemeld bij Windows met uw Microsoft Entra-referenties vanuit een federatief domein.
Microsoft Entra ID - Wachtwoord: een niet-interactieve methode waarmee u verbinding kunt maken met een Microsoft Entra-principalnaam met behulp van het door Microsoft Entra ID beheerde domein. Uit de documentatie:
Dit kan van toepassing zijn op systeemeigen of federatieve Microsoft Entra-gebruikers. Een systeemeigen gebruiker is een gebruiker die expliciet is gemaakt in Microsoft Entra-id en wordt geverifieerd met gebruikersnaam en wachtwoord, terwijl een federatieve gebruiker een Windows-gebruiker is waarvan het domein is gefedereerd met Microsoft Entra-id. De laatste methode (met gebruikersnaam en wachtwoord) kan worden gebruikt wanneer een gebruiker zijn windows-referenties wil gebruiken, maar de lokale computer niet is gekoppeld aan het domein (bijvoorbeeld via een externe toegang). In dit geval kan een Windows-gebruiker zijn of haar domeinaccount en wachtwoord aangeven en zich verifiëren bij SQL Database of Azure Synapse Analytics (voorheen SQL DW) met behulp van federatieve referenties.
Microsoft Entra ID - Universeel met meervoudige verificatie (MFA):een interactieve methode waarmee de toegang tot gegevens wordt beveiligd terwijl wordt voldaan aan de vraag van een organisatie naar een proces voor eenmalige aanmelding met Microsoft Entra multifactor-verificatie.
Voor Azure SQL Database zijn er enkele nuances. U kunt aanmeldingen hebben die aanwezig zijn in de virtuele master database, databasegebruikers en zelfs ingesloten databasegebruikers voor Microsoft Entra-accounts (aanbevolen). Hoewel de serverbeheerder voor Azure SQL Database in wezen rechten heeft sysadmin , kunt u beperktere beheerders maken met behulp van server- of databaseniveaurollen. Er zijn twee rollen op databaseniveau beschikbaar voor SQL Database die alleen aanwezig zijn in de virtuele master database:
- loginmanager: een rol op databaseniveau waarmee leden aanmeldingen voor de databaseserver kunnen maken
- dbmanager: een rol op databaseniveau waarmee leden databases voor de databaseserver kunnen maken en verwijderen
Hier volgt een lijst met functies op serverniveau in Azure SQL Database:
- ##MS_DatabaseVerbinding maken or##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Tot slot, wanneer u verificatie en autorisatie instelt en configureert, zijn er vier richtlijnen die u kunt volgen:
- Implementeren met een serverbeheerder
- Indien nodig andere beheerders maken
- Beheerders kunnen gebruikers maken
- Toegang verlenen op dezelfde manier als in SQL Server
Andere mogelijkheden
Nadat u zich hebt verder hebt verdiept in een aantal netwerk- en verificatiemogelijkheden, gaat u verderop in de module andere mogelijkheden (en de bijbehorende taken) onderzoeken om gegevens te beveiligen, te bewaken, te registreren en te controleren.