Sicherheitsfunktionen und -aufgaben
SQL Server und Azure SQL-Dienste sind dafür bekannt, besonders der Sicherheit auf Unternehmensniveau eine große Bedeutung beizumessen. In dieser Lektion erfahren Sie mehr über die verschiedenen Sicherheitsfunktionen im Zusammenhang mit Netzwerksicherheit und Zugriffsverwaltung. In den folgenden Lektionen machen Sie sich mit einigen dieser Funktionen vertraut.
Netzwerksicherheit
Die erste Sicherheitsebene bezieht sich auf das Netzwerk. Die Netzwerkfunktionen und -aufgaben in Azure SQL-Datenbank und Azure SQL Managed Instance unterscheiden sich. Informationen zu Netzwerkfunktionen von Azure SQL Managed Instance finden Sie unter Konnektivitätsarchitektur für Azure SQL Managed Instance.
Netzwerksicherheit in Azure SQL-Datenbank
Wenn Sie Ihr Netzwerk für Azure SQL-Datenbank sichern, stehen Ihnen vier Möglichkeiten zur Verfügung:
- Zugriff auf Azure-Dienste erlauben
- Verwenden von Firewallregeln
- Verwenden von VNET-Regeln
- Verwenden von Azure Private Link
Zusätzlich zu diesen wichtigen Optionen haben Sie die Möglichkeit, den gesamten öffentlichen Zugriff (nur mit Azure Private Link) und die Option zum Erzwingen einer minimalen TLS-Version (Transport Layer Security) zu blockieren. Die am wenigsten sichere, aber am einfachsten zu konfigurierende Methode ist das Zulassen des Zugriffs auf Azure-Dienste. Die sicherste Methode ist die Verwendung von Private Link. In den folgenden Abschnitten werden die Möglichkeiten sowie das Konfigurieren und Warten der einzelnen Optionen beschrieben.
Zugriff auf Azure-Dienste erlauben
Während der Bereitstellung von Azure SQL-Datenbank können Sie die Option Anderen Azure-Diensten und -Ressourcen den Zugriff auf diesen Server gestatten auf Ja festlegen. Wenn Sie diese Option auswählen, kann aus allen Regionen und Abonnements auf Ihre Ressourcen zugegriffen werden. Diese Option erleichtert das Einrichten und Ausführen von Azure SQL-Datenbank mit anderen Diensten wie Azure Virtual Machines oder Azure App Service oder sogar Azure Cloud Shell, da Sie zulassen, dass alle anderen Dienste im Zusammenhang mit Azure eine Verbindung herstellen können.
Das Zulassen des Zugriffs auf Azure-Dienste bedeutet jedoch nicht, dass jede beliebige Komponente außerhalb von Azure (z. B. Ihre lokale Umgebung) Zugriff hat.
Wenn die sicherste Konfiguration darin besteht, Azure-Diensten und -Ressourcen den Zugriff auf den Server erlauben auf Nein festzulegen, werden alle Verbindungen und Netzwerke mit derjenigen blockiert, die Sie explizit mithilfe der verschiedenen Optionen hinzugefügt haben, die in den nächsten Abschnitten folgen.
Firewallregeln
Ihre nächste Option ist die Anwendung von Firewallregeln. Ihre Ergebnisse sind möglicherweise denen von Anderen Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben ähnlich, außer dass Sie für jeden Dienst (im folgenden Bild ein virtueller Computer [VM]) eine eindeutige Firewallregel hinzufügen müssen, um die Verbindung zu erlauben. Firewallregeln ermöglichen es auch Ihrer lokalen Umgebung, sich mit der Azure SQL-Datenbank-Ressource zu verbinden, da Sie die Regeln für Computer und Anwendungen in Ihrer lokalen Umgebung hinzufügen können.
Sie können auch den Zugriff auf Azure-Dienste zulassen, damit Sie Konnektivität in Azure erhalten, und dann Firewallregeln nur für Ihre lokale Konnektivität hinzufügen. Wie bereits erwähnt, ist Anderen Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben nicht so sicher, da damit der gesamte Azure-Datenverkehr zugelassen wird. Daher wird empfohlen, ausschließlich Firewallregeln zu verwenden.
Betrachten wir das vorhergehende Beispiel mit konfigurierten Firewallregeln. Mithilfe eines Tools, das Transact-SQL (T-SQL) unterstützt, wie z. B. SQL Server Management Studio (SSMS), können Sie auf Ihrer Azure-VM im virtuellen Netzwerk SQLDBVNET-EUS die folgende Abfrage ausführen:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Das Ergebnis wäre 174.17.218.16. Dies ist die öffentliche IP-Adresse der Azure-VM. Obwohl Sie Firewallregeln verwenden, sind alle Verbindungen öffentlich.
VNET-Regeln
Wenn Sie nur Firewallregeln verwenden möchten, kann die Einrichtung kompliziert sein. Wenn Sie nur Firewallregeln verwenden, müssen Sie einen Bereich von IP-Adressen für alle Ihre Verbindungen angeben, die mitunter dynamische IP-Adressen aufweisen können. Eine wesentlich einfachere Alternative sind VNET-Regeln zur Einrichtung und Verwaltung des Zugriffs aus bestimmten Netzwerken mit VMs oder anderen Diensten, die auf die Daten zugreifen müssen.
Wenn Sie den Zugriff von einem virtuellen Netzwerk mit einer VNET-Regel konfigurieren, können alle Ressourcen in diesem virtuellen Netzwerk auf den logischen Server der Azure SQL-Datenbank zugreifen. Dies kann die Herausforderung der Konfiguration des Zugriffs auf alle statischen und dynamischen IP-Adressen, die auf die Daten zugreifen müssen, vereinfachen. Durch die Verwendung von VNET-Regeln können Sie ein oder mehrere virtuelle Netzwerke angeben, die alle Ressourcen innerhalb dieser Netzwerke umfassen. Sie können auch damit beginnen, virtuelle Netzwerktechnologien anzuwenden, um Netzwerke regionsübergreifend sowohl in Azure als auch lokal zu verbinden.
In diesem Beispiel können Sie wie im vorherigen Abschnitt dieselbe Abfrage von Ihrer Azure-VM im virtuellen Netzwerk SQLDBVNET-EUS ausführen:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Das Ergebnis wäre jetzt 10.0.0.2, die private IP-Adresse des virtuellen Azure-Computers. Dieses Ergebnis bringt Sie Ihrem Ziel näher, private Verbindungen mit Ihrem logischen Azure SQL-Datenbank-Server herzustellen, da Ressourcen jetzt über das virtuelle Netzwerk verbunden werden.
Eine weitere gängige Strategie zum Analysieren der Verbindung ist die Untersuchung der DNS-Hierarchie (Domain Name System). Auf derselben Azure-VM können Sie mithilfe einer Eingabeaufforderung den folgenden Befehl ausführen:
nslookup aw-server.database.windows.net
Mit diesem Befehl können Sie Details abrufen, die sich auf die DNS-Infrastruktur beziehen. Ihre Ergebnisse ähneln den folgenden:
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
Unter „Nicht-autoritative Antwort“ sind einige wichtige Punkte zu beachten:
- Name: Der Endpunkt, der mit
cr2beginnt, ist Teil der öffentlichen DNS-Hierarchie. Ohne hinsichtlich der Hierarchie zu sehr ins Detail zu gehen, istcr2der Steuerring 2, unter dem mehrere „Datenslices“ vorhanden sind. - Adresse: Die hier zurückgegebene IP-Adresse sollte der öffentlichen IP-Adresse Ihres virtuellen Azure-Computers entsprechen. Obwohl ein Tool wie der endgültige Hop von SSMS die private IP-Adresse Ihrer VM durchlaufen kann, wird beim Herstellen von Verbindungen in gewissem Maße weiterhin die öffentliche IP-Adresse Ihres virtuellen Computers verwendet.
- Aliase: Aliase sind verschiedene Punkte in der DNS-Hierarchie, in diesem Fall der spezifische „Datenslice“ und Endpunkt, mit dem Sie eine Verbindung herstellen.
Hinweis
Im vorherigen Ausgabeblock Adresse: 168.63.129.16 eine virtuelle öffentliche IP-Adresse, die verwendet wird, um einen Kommunikationskanal zu Azure-Plattformressourcen zu unterstützen. Sie gilt für alle Regionen und alle nationalen Clouds und wird sich nicht ändern.
Obwohl die Verbindung über SSMS mithilfe der privaten IP-Adresse der Azure-VM erfolgt, stellen Sie letztendlich dennoch eine Verbindung über einen öffentlichen Endpunkt her.
Private Link für eine Azure SQL-Datenbank-Instanz
Sie haben erfahren, wie Sie das sicherste Netzwerk konfigurieren können, indem Sie Ihre Datenbank in Azure SQL-Datenbank mit dem öffentlichen Endpunkt verwenden. Diese Methode zum Schützen einer Datenbank in SQL-Datenbank wurde jahrelang verwendet. Im Jahr 2019 wurde jedoch ein neues Konzept für Azure eingeführt: Private Link. Diese Methode ähnelt der Bereitstellung von Azure SQL Managed Instance noch mehr. Mit Azure Private Link können Sie über einen privaten Endpunkt eine Verbindung mit Ihrer Datenbank in SQL-Datenbank und verschiedenen anderen Platform-as-a-Service-Angeboten (PaaS) herstellen. Dies bedeutet, dass es über eine private IP-Adresse innerhalb eines bestimmten virtuellen Netzwerks verfügt.
Im vorherigen Beispiel sehen Sie, dass die allgemeine Netzwerkinfrastruktur sich nicht verändert hat. Sie können weiterhin die Konnektivitätsmethoden in den VNET-Regeln anwenden. Sie müssen jedoch keine VNET-Regeln erstellen. Die Ressourcen, die eine Verbindung mit dem Datenbankserver herstellen müssen, erfordern den Zugriff auf das virtuelle Netzwerk, in dem sich der Endpunkt befindet. In diesem Beispiel ist der Endpunkt SQLDBVNet-EUS. Nur Verbindungen über den privaten Endpunkt haben Zugriff und alle anderen Verbindungen (z. B. über das Internet) werden verweigert.
Wenn Sie mit diesem Beispiel fortfahren, können Sie auf der Azure-VM im virtuellen Netzwerk SQLDBVNet-EUS noch einmal folgenden T-SQL-Befehl ausführen:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Das Ergebnis ist nun 10.0.0.2 und entspricht der privaten IP-Adresse der Azure-VM in diesem Beispiel. Durch das Hinzufügen des Zugriffs über Ihr virtuelles Netzwerk werden Verbindungen mit Azure SQL-Datenbank anscheinend über die private IP-Adresse Ihrer VM hergestellt. Dieses Ergebnis konnten Sie auch bei VNET-Regeln beobachten.
Möglicherweise möchten Sie jedoch die Eingabeaufforderung verwenden, um mit dem folgenden Befehl einen Blick auf die DNS-Hierarchie zu werfen:
nslookup aw-server.database.windows.net
Wenn Sie den vorhergehenden Befehl verwenden, werden Ihre Ergebnisse mit dem konfigurierten privaten Endpunkt etwas anders ausfallen:
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
Unter „Nicht-autoritative Antwort“ sind einige wichtige Punkte zu beachten:
- Name: Beachten Sie, dass Sie nicht mehr auf die öffentliche DNS-Hierarchie verweisen, sondern nur auf den Private Link-DNS. Das bedeutet, dass weniger Informationen über den Datenbankserver preisgegeben werden.
- Addresses: Bei VNET-Regeln entspricht die zurückgegebene Adresse der öffentlichen IP-Adresse Ihrer VM. Jetzt sollte jedoch mindestens eine private IP-Adresse in der Private Link-Hierarchie vorhanden sein, wobei eine den privaten Endpunkt Ihrer Azure SQL-Datenbank-Instanz darstellt.
- Aliase: Wie beim Feld „Name“ besteht nur noch der Bezug zur DNS-Hierarchie, dass Sie eine Verbindung mit dem Servernamen (z. B.
aw-server.database.windows.net) herstellen können.
Sie fragen sich möglicherweise, warum bei einer Verbindung über den privaten Endpunkt der gleiche Servername verwendet wird. Wenn Sie im Back-End nur die Private Link-Methode für die Verbindung mit Azure SQL-Datenbank verwenden (also keine Firewall oder VNET-Regeln), werden Informationen folgendermaßen verarbeitet:
aw-server.database.windows.net- Wird vom Dienst zu
aw-server.privatelink.database.netaufgelöst- Wird vom Dienst zu
10.0.0.5(IP-Adresse Ihres privaten Endpunkts) aufgelöst
- Wird vom Dienst zu
- Wird vom Dienst zu
Außerdem blockiert der Dienst eine direkte Verbindung mit anderen Komponenten, wenn eine andere Methode als aw-server.database.windows.net verwendet wird.
Zugriffsverwaltung
Nachdem Sie den Netzwerkzugriff eingerichtet haben, müssen Sie sich um die Zugriffsverwaltung kümmern.
Rollenbasierte Zugriffssteuerung
Sämtliche Azure-Vorgänge für Azure SQL-Datenbank werden über die rollenbasierte Zugriffsteuerung (Role-Based Access Control, RBAC) gesteuert. RBAC ist aktuell von der Azure SQL-Sicherheit entkoppelt. Sie können sich diese jedoch als Sicherheitsrechte außerhalb Ihrer Datenbank in SQL-Datenbank vorstellen, die Abonnements, Ressourcengruppen und Ressourcen umfassen. Die Rechte gelten für Vorgänge im Azure-Portal, in der Azure CLI und in Azure PowerShell. RBAC ermöglicht die Aufgabentrennung zwischen Bereitstellung, Verwaltung und Verwendung.
Integrierte Rollen sind verfügbar, um den Bedarf an übergeordneten RBAC-Rollen wie Besitzer oder Mitwirkender zu reduzieren. Sie können diese Rollen effektiv nutzen, um bestimmten Personen die Bereitstellung von Azure SQL-Ressourcen (oder verwalteten Sicherheitsrichtlinien) zu ermöglichen, aber anderen Benutzern den tatsächlichen Zugriff zur Nutzung oder Verwaltung der Datenbank zu gewähren. Ein SQL Server-Mitwirkender kann beispielsweise einen Server bereitstellen und einem Benutzer die Administratorrolle für den Server und die Datenbanken zuweisen. Es folgen die integrierten Rollen in Azure SQL Datenbank:
- SQL-DB-Mitwirkender: Kann Datenbanken erstellen und verwalten, aber nicht auf die Datenbank zugreifen (z. B. keine Verbindung herstellen und Daten lesen)
- SQL-Sicherheits-Manager: Kann Sicherheitsrichtlinien für Datenbanken und Instanzen (z. B. Auditing) verwalten, aber nicht darauf zugreifen
- SQL Server-Mitwirkender: Kann Server und Datenbanken verwalten, aber nicht darauf zugreifen
Authentifizierung
Während der Bereitstellung eines logischen Azure SQL-Datenbank-Servers können Sie die folgende Authentifizierungsmethode angeben:
- Nur Microsoft Entra-Authentifizierung verwenden
- Sie können sowohl die SQL- als auch die Microsoft Entra-Authentifizierung verwenden
- Verwenden der SQL-Authentifizierung
Der Serveradministrator muss während der Bereitstellung festgelegt werden. Bei Datenbanken in Azure SQL Datenbank ist der Serveradministrator ein Prinzipal auf Serverebene für den logischen Azure SQL-Datenbank-Server.
Wenn Sie eine Workload migrieren, die die Windows-Authentifizierung benötigt oder Ihre Organisation Microsoft Entra-ID verwendet, können Sie Microsoft Entra ID verwenden. Sie können einen Microsoft Entra-Serveradministrator mithilfe des Portals oder der Befehlszeilentools zuweisen.
Die reine Microsoft Entra-Authentifizierung ist die Standardoption beim Konfigurieren eines neuen Servers. Serveranmeldungen wurden eingeführt, um Microsoft Entra-Serverprinzipale zuzulassen, bei denen es sich um Anmeldungen in der virtuellen master-Datenbank einer SQL-Datenbank-Instanz handelt. Sie können Microsoft Entra-Anmeldungen aus Microsoft Entra-Benutzern, -Gruppen und -Dienstprinzipalen erstellen. Bei Verwendung der reinen Microsoft Entra-Authentifizierung können Sie SQL-Authentifizierungsanmeldungen erstellen, wobei vorhandene Anmeldungen erhalten bleiben. Allerdings können nur Microsoft Entra-Authentifizierungsanmeldungen und -Benutzer eine Verbindung mit dem logischen Server herstellen. Weitere Informationen zur reinen Microsoft Entra-Authentifizierung finden Sie unter Reine Microsoft Entra-Authentifizierung bei Azure SQL.
Je nachdem, wie Ihre Organisation die Microsoft Entra-Instanz konfiguriert hat, können Sie mithilfe einer der folgenden drei Methoden eine Verbindung mit ihr herstellen (z. B. in SSMS):
Microsoft Entra ID – Integrierte: Eine nicht interaktive Methode, die Sie verwenden können, wenn Sie mit Ihren Microsoft Entra-Anmeldeinformationen aus einer Verbunddomäne bei Windows angemeldet sind.
Microsoft Entra ID – Kennwort: Eine nicht interaktive Methode, mit der Sie eine Verbindung mit einem Microsoft Entra-Prinzipalnamen mithilfe der von Microsoft Entra ID verwalteten Domäne herstellen können. Aus der Dokumentation:
Dies kann für native oder verbundene Microsoft Entra-Benutzer gelten. Ein systemeigener Benutzer wird explizit in der Microsoft Entra-ID erstellt und mithilfe von Benutzername und Kennwort authentifiziert, während ein Verbundbenutzer ein Windows-Benutzer ist, dessen Domäne mit Microsoft Entra-ID verbunden ist. Die Methode mit Benutzernamen und Kennwort kann verwendet werden, wenn Benutzer ihre Windows-Anmeldeinformationen nutzen möchten, aber der lokale Computer nicht mit der Domäne verbunden ist (z. B. im Fall eines Remotezugriffs). In diesem Fall kann ein Windows-Benutzer sein Domänenkonto und das zugehörige Kennwort angeben, um sich bei SQL-Datenbank oder Azure Synapse Analytics (vormals SQL DW) mit Verbundanmeldeinformationen zu authentifizieren.
Microsoft Entra ID – Universell mit mehrstufiger Authentifizierung (MFA): Eine interaktive Methode, die den Zugriff auf Daten schützt, während die Anforderung einer Organisation nach einem einmaligen Anmeldeprozess mit mehrstufiger Microsoft Entra-Authentifizierung erfüllt wird.
Bei Azure SQL-Datenbank gibt es einige Abweichungen. Sie können Anmeldungen haben, die in der virtuellen master Datenbank, Datenbankbenutzern und sogar Datenbankbenutzern für Microsoft Entra-Konten vorhanden sind (empfohlen). Obwohl der Serveradministrator für Azure SQL-Datenbank im Prinzip sysadmin-Berechtigungen besitzt, können Sie weitere eingeschränkte Administratoren mithilfe von Rollen auf Server- oder Datenbankebene erstellen. Für Azure SQL-Datenbank sind zwei Rollen auf Datenbankebene verfügbar, die nur in der virtuellen master-Datenbank vorhanden sind:
- loginmanager: Hierbei handelt es sich um eine Rolle auf Datenbankebene, die es Mitgliedern ermöglicht, Konten für den Datenbankserver zu erstellen.
- dbmanager: Hierbei handelt es sich um eine Rolle auf Datenbankebene, die es Mitgliedern ermöglicht, Datenbanken für den Datenbankserver zu erstellen und zu löschen.
Es folgt eine Liste der Rollen auf Serverebene in Azure SQL-Datenbank:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
Beim Einrichten und Konfigurieren der Authentifizierung und Autorisierung müssen Sie schließlich vier Richtlinien befolgen:
- Bereitstellen eines Serveradministrators
- Erstellen weiterer Administratoren nach Bedarf
- Erstellung von Benutzern durch Administratoren
- Gewährung des Zugriffs wie in SQL Server
Weitere Features
Nachdem Sie sich mit einigen Netzwerk- und Authentifizierungsfeatures vertraut gemacht haben, lernen Sie im Verlauf des Moduls weitere Features (oder zugehörige Aufgaben) für den Schutz von Daten, die Überwachung, die Protokollierung und das Auditing kennen.