Freigeben über


Sichern eines dedizierten SQL-Pools (früher SQL DW) in Azure Synapse Analytics

In diesem Artikel werden Sie durch die Grundlagen der Sicherung Ihres dedizierten SQL-Pools (vormals SQL DW) geführt. Insbesondere dieser Artikel beginnt mit Ressourcen zum Einschränken des Zugriffs, zum Schutz von Daten und zur Überwachung von Aktivitäten mit dediziertem SQL-Pool (vormals SQL DW).

Verbindungssicherheit

Die Verbindungssicherheit bezieht sich darauf, wie Sie Verbindungen mit Ihrer Datenbank mithilfe von Firewallregeln und Verbindungsverschlüsselung einschränken und sichern.

Firewallregeln werden sowohl vom logischen SQL-Server als auch seinen Datenbanken verwendet, um Verbindungsversuche von IP-Adressen abzulehnen, die nicht explizit genehmigt wurden. Um Verbindungen von der öffentlichen IP-Adresse Ihrer Anwendung oder Ihres Clientcomputers zuzulassen, müssen Sie zunächst eine Firewallregel auf Serverebene mithilfe des Azure-Portals, der REST-API oder der PowerShell erstellen.

Als bewährte Methode sollten Sie die ip-Adressbereiche, die über Ihre Firewall auf Serverebene zulässig sind, so weit wie möglich einschränken. Um von Ihrem lokalen Computer aus auf Ihren dedizierten SQL-Pool (ehemals SQL DW) zuzugreifen, stellen Sie sicher, dass die Firewall auf Ihrem Netzwerk und dem lokalen Computer ausgehende Kommunikation über TCP-Port 1433 ermöglicht.

Dedizierter SQL-Pool (früher SQL DW) verwendet IP-Firewallregeln auf Serverebene. IP-Firewallregeln auf Datenbankebene werden nicht unterstützt. Weitere Informationen finden Sie unter Azure SQL-Datenbankfirewallregeln

Verbindungen mit Ihrem dedizierten SQL-Pool (vormals SQL DW) werden standardmäßig verschlüsselt. Das Ändern der Verbindungseinstellungen zum Deaktivieren der Verschlüsselung wird ignoriert.

Authentifizierung

Die Authentifizierung bezieht sich darauf, wie Sie Beim Herstellen einer Verbindung mit der Datenbank Ihre Identität nachweisen. Dedizierter SQL-Pool (früher SQL DW) unterstützt derzeit die SQL Server-Authentifizierung mit einem Benutzernamen und Kennwort und mit Microsoft Entra ID.

Wenn Sie den Server für Ihre Datenbank erstellt haben, haben Sie einen "Serveradministrator"-Anmeldenamen und ein Kennwort angegeben. Mithilfe dieser Anmeldeinformationen können Sie sich bei jeder Datenbank auf diesem Server als Datenbankbesitzer oder "dbo" über die SQL Server-Authentifizierung authentifizieren.

Als bewährte Methode sollten die Benutzer Ihrer Organisation jedoch ein anderes Konto verwenden, um sich zu authentifizieren. Auf diese Weise können Sie die Berechtigungen einschränken, die der Anwendung gewährt werden, und die Risiken bösartiger Aktivitäten verringern, falls Ihr Anwendungscode anfällig für einen SQL-Einfügungsangriff ist.

Um einen authentifizierten SQL Server-Benutzer zu erstellen, stellen Sie eine Verbindung mit der Masterdatenbank auf Ihrem Server mit Der Serveradministratoranmeldung her, und erstellen Sie eine neue Serveranmeldung. Es ist ratsam, auch einen Benutzer in der Masterdatenbank zu erstellen. Das Erstellen eines Benutzers im Master ermöglicht es einem Benutzer, sich mit Tools wie SSMS anzumelden, ohne einen Datenbanknamen anzugeben. Außerdem können sie den Objekt-Explorer verwenden, um alle Datenbanken auf einem Server anzuzeigen.

-- Connect to master database and create a login
CREATE LOGIN ApplicationLogin WITH PASSWORD = 'Str0ng_password';
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Stellen Sie dann eine Verbindung mit Ihrem dedizierten SQL-Pool (vormals SQL DW) mit Ihrer Serveradministratoranmeldung her, und erstellen Sie einen Datenbankbenutzer basierend auf der serverbasierten Anmeldung, die Sie erstellt haben.

-- Connect to the database and create a database user
CREATE USER ApplicationUser FOR LOGIN ApplicationLogin;

Um einem Benutzer zusätzliche Vorgänge wie das Erstellen von Logins oder das Erstellen neuer Datenbanken zu ermöglichen, weisen Sie den Benutzer den Rollen Loginmanager und dbmanager in der Masterdatenbank zu.

Weitere Informationen zu diesen zusätzlichen Rollen und zur Authentifizierung bei einer SQL-Datenbank finden Sie unter Verwalten von Datenbanken und Anmeldungen in azure SQL-Datenbank. Weitere Informationen zum Herstellen einer Verbindung mithilfe der Microsoft Entra-ID finden Sie unter Herstellen einer Verbindung mithilfe der Microsoft Entra-Authentifizierung.

Autorisierung

Autorisierung bezieht sich darauf, was Sie innerhalb einer Datenbank tun können, sobald Sie authentifiziert und verbunden sind. Autorisierungsberechtigungen werden durch Rollenmitgliedschaften und Berechtigungen bestimmt. Als bewährte Methode sollten Sie Benutzern die geringsten Berechtigungen gewähren. Zum Verwalten von Rollen können Sie die folgenden gespeicherten Prozeduren verwenden:

EXEC sp_addrolemember 'db_datareader', 'ApplicationUser'; -- allows ApplicationUser to read data
EXEC sp_addrolemember 'db_datawriter', 'ApplicationUser'; -- allows ApplicationUser to write data

Das Serveradministratorkonto, mit dem Sie eine Verbindung herstellen, ist mitglied von db_owner, das über die Berechtigung verfügt, alles innerhalb der Datenbank zu erledigen. Speichern Sie dieses Konto für die Bereitstellung von Schemaupgrades und anderen Verwaltungsvorgängen. Verwenden Sie das Konto "ApplicationUser" mit eingeschränkteren Berechtigungen, um eine Verbindung von Ihrer Anwendung mit der Datenbank mit den geringsten Berechtigungen herzustellen, die von Ihrer Anwendung benötigt werden.

Es gibt Möglichkeiten, die Aktionen, die ein Benutzer innerhalb der Datenbank ausführen kann, weiter einzuschränken:

  • Mit granularen Berechtigungen können Sie steuern, welche Vorgänge Sie für einzelne Spalten, Tabellen, Ansichten, Schemas, Prozeduren und andere Objekte in der Datenbank ausführen können. Verwenden Sie granulare Berechtigungen, um die meisten Kontrolle zu haben und die erforderlichen Mindestberechtigungen zu erteilen.
  • Andere Datenbankrollen als db_datareader und db_datawriter können verwendet werden, um leistungsfähigere Anwendungsbenutzerkonten oder weniger leistungsfähige Verwaltungskonten zu erstellen. Die integrierten festen Datenbankrollen bieten eine einfache Möglichkeit zum Erteilen von Berechtigungen, können aber dazu führen, dass mehr Berechtigungen gewährt werden, als erforderlich sind.
  • Gespeicherten Prozeduren können verwendet werden, um die Aktionen zu begrenzen, die in der Datenbank ausgeführt werden können.

Im folgenden Beispiel wird Lesezugriff auf ein benutzerdefiniertes Schema gewährt.

--CREATE SCHEMA Test
GRANT SELECT ON SCHEMA::Test to ApplicationUser

Das Verwalten von Datenbanken und Servern über das Azure-Portal oder die Verwendung der Azure Resource Manager-API wird durch die Rollenzuweisungen Ihres Portalbenutzerkontos gesteuert. Weitere Informationen finden Sie unter Weisen Sie Azure-Rollen über das Azure-Portal zu.

Verschlüsselung

Transparente Datenverschlüsselung (Transparent Data Encryption, TDE) schützt vor der Bedrohung bösartiger Aktivitäten, indem sie ruhende Daten verschlüsselt und entschlüsselt. Wenn Sie Ihre Datenbank verschlüsseln, werden zugeordnete Sicherungen und Transaktionsprotokolldateien verschlüsselt, ohne dass Änderungen an Ihren Anwendungen erforderlich sind. TDE verschlüsselt den Speicher einer gesamten Datenbank mithilfe eines symmetrischen Schlüssels, der als Datenbankverschlüsselungsschlüssel bezeichnet wird.

In der SQL-Datenbank wird der Datenbankverschlüsselungsschlüssel durch ein integriertes Serverzertifikat geschützt. Das integrierte Serverzertifikat ist für jeden Server eindeutig. Microsoft erneuert diese Zertifikate automatisch mindestens alle 90 Tage. Der verwendete Verschlüsselungsalgorithmus ist AES-256. Eine allgemeine Beschreibung von TDE finden Sie unter Transparent Data Encryption.

Sie können Ihre Datenbank über das Azure-Portal oder T-SQL verschlüsseln.

Nächste Schritte

Ausführliche Informationen und Beispiele zum Herstellen einer Verbindung mit Ihrem Lager mit verschiedenen Protokollen finden Sie unter Connect to dedicated SQL pool (früher SQL DW).For details and examples on connecting to your warehouse with different protocols, see Connect to dedicated SQL pool (formerly SQL DW).