Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:SQL Server unter Linux
Wenn Sie ein Linux-Benutzer sind, der noch nicht mit SQL Server vertraut ist, lernen Sie mit den folgenden Aufgaben einige der Sicherheitsaufgaben kennen. Diese Features gelten nicht ausschließlich und speziell nur für Linux, aber mit diesem Artikel können Sie sich eine Übersicht über die Bereiche verschaffen, die Sie näher untersuchen sollten. In jedem Beispiel wird ein Link zu der ausführlichen Dokumentation für diesen Bereich bereitgestellt.
Die Codebeispiele in diesem Artikel verwenden die AdventureWorks2025- oder AdventureWorksDW2025 Beispieldatenbank, die Sie von der Microsoft SQL Server Samples and Community Projects Homepage herunterladen können.
Erstellen Sie eine Anmeldung und einen Datenbankbenutzer
Gewähren Sie anderen Benutzern Zugriff auf SQL Server, indem Sie mithilfe der master Anweisung eine Anmeldung in der CREATE LOGIN Datenbank erstellen. Beispiel:
CREATE LOGIN Larry
WITH PASSWORD = '<password>';
Caution
Ihr Kennwort sollte der standardmäßigen Kennwortrichtlinie von SQL Server folgen. Standardmäßig muss das Kennwort mindestens acht Zeichen lang sein und Zeichen aus drei der folgenden vier Sätze enthalten: Großbuchstaben, Kleinbuchstaben, Basis-10 Ziffern und Symbole. Kennwörter können bis zu 128 Zeichen lang sein. Verwenden Sie möglichst lange und komplexe Kennwörter.
Anmeldenamen können eine Verbindung mit SQL Server herstellen und Zugriff (mit eingeschränkten Berechtigungen) auf die master-Datenbank haben. Um eine Verbindung mit einer Benutzerdatenbank herzustellen, benötigt ein Login eine entsprechende Identität auf der Datenbankebene, die als Datenbankbenutzer bezeichnet wird. Benutzer sind für jede Datenbank spezifisch und müssen separat in jeder Datenbank erstellt werden, um Ihnen Zugriff zu gewähren. Das folgende Beispiel verschiebt Sie in die AdventureWorks2025 Datenbank und verwendet dann die CREATE USER Anweisung, um einen Benutzer namens Larry zu erstellen, der dem Anmeldenamen Larryzugeordnet ist. Obwohl Anmeldename und Benutzer miteinander verknüpft sind (einander zugeordnet), handelt es sich dabei um unterschiedliche Objekte. Der Anmeldename ist ein Prinzipal auf Serverebene. Der Benutzer ist ein Prinzipal auf Datenbankebene.
USE AdventureWorks2022;
GO
CREATE USER Larry;
GO
- Mit einem SQL Server-Administratorkonto kann eine Verbindung mit einer beliebigen Datenbank hergestellt werden, und es können mehr Anmeldenamen und Benutzer in einer beliebigen Datenbank erstellt werden.
- Eine Person, die eine Datenbank erstellt, wird zum Datenbankbesitzer, der eine Verbindung mit der Datenbank herstellen kann. Datenbankbesitzer können mehr Benutzer erstellen.
Später können Sie anderen Anmeldungen erlauben, weitere Anmeldungen zu erstellen, indem Sie ihnen die Berechtigung ALTER ANY LOGIN erteilen. Innerhalb einer Datenbank können Sie andere Benutzer*innen dazu autorisieren, weitere Benutzer*innen zu erstellen, indem Sie ihnen die Berechtigung ALTER ANY USER erteilen. Beispiel:
GRANT ALTER ANY LOGIN TO Larry;
GO
USE AdventureWorks2022;
GO
GRANT ALTER ANY USER TO Jerry;
GO
Nun kann der Anmeldename Larry weitere Anmeldungen erstellen, und der Benutzer Jerry kann weitere Benutzer erstellen.
Gewähren von Zugriff mit geringsten Rechten
Die ersten Personen, die eine Verbindung mit einer Benutzerdatenbank herstellen, sind die Administrator- und Datenbankbesitzerkonten. Diese Benutzer verfügen jedoch über alle Berechtigungen, die für die Datenbank verfügbar sind. Dies sind mehr Berechtigungen, als die meisten Benutzer haben sollten.
Wenn Sie gerade erst beginnen, können Sie mithilfe der integrierten festen Datenbankrollen allgemeine Kategorien von Berechtigungen zuweisen. Beispielsweise kann die feste Datenbankrolle db_datareader alle Tabellen in der Datenbank lesen, aber keine Änderungen vornehmen. Gewähren Sie eine Mitgliedschaft in einer festen Datenbankrolle mit der Anweisung ALTER ROLE. Im folgenden Beispiel wird der Benutzer Jerry der db_datareader festen Datenbankrolle hinzugefügt.
USE AdventureWorks2022;
GO
ALTER ROLE db_datareader ADD MEMBER Jerry;
Eine Liste der festen Datenbankrollen finden Sie unter Rollen auf Datenbankebene.
Wenn Sie später den präziseren Zugriff auf Ihre Daten konfigurieren möchten (dringend empfohlen), erstellen Sie ihre eigenen benutzerdefinierten Datenbankrollen mithilfe einer CREATE ROLE Anweisung. Weisen Sie dann Ihren benutzerdefinierten Rollen bestimmte präzise Berechtigungen zu.
Die folgenden Anweisungen erstellen z.B. eine Datenbankrolle mit dem Namen Sales und geben der Sales-Gruppe die Möglichkeit, Zeilen der Orders-Tabelle anzuzeigen, zu aktualisieren und zu löschen, und anschließend wird der Benutzer Jerry der Sales-Rolle hinzugefügt.
CREATE ROLE Sales;
GRANT SELECT ON OBJECT::Sales TO Orders;
GRANT UPDATE ON OBJECT::Sales TO Orders;
GRANT DELETE ON OBJECT::Sales TO Orders;
ALTER ROLE Sales ADD MEMBER Jerry;
Weitere Informationen zum Berechtigungssystem finden Sie unter Erste Schritte mit Berechtigungen für die Datenbank-Engine.
Konfigurieren der Sicherheit auf Zeilenebene
Mit der Sicherheit auf Zeilenebene können Sie in einer Datenbank den Zugriff auf Zeilen für den Benutzer einschränken, der eine Abfrage ausführt. Dieses Feature ist sehr nützlich, wenn Sie beispielsweise sicherstellen möchten, dass Kunden nur auf ihre eigenen Daten oder Mitarbeiter nur auf Daten zugreifen können, die für ihre eigene Abteilung relevant sind.
In den folgenden Schritten erfahren Sie, wie Sie zwei Benutzer mit unterschiedlichen Zugriffsrechten auf Zeilenebene für die Tabelle Sales.SalesOrderHeader einrichten.
Erstellen Sie zwei Benutzerkonten, um die Sicherheit auf Zeilenebene zu testen:
USE AdventureWorks2022;
GO
CREATE USER Manager WITHOUT LOGIN;
CREATE USER SalesPerson280 WITHOUT LOGIN;
Erteilen Sie beiden Benutzern Leseberechtigung für die Tabelle Sales.SalesOrderHeader:
GRANT SELECT ON Sales.SalesOrderHeader TO Manager;
GRANT SELECT ON Sales.SalesOrderHeader TO SalesPerson280;
Erstellen Sie ein neues Schema und eine Inline-Tabellenwertfunktion. Die Funktion gibt 1 zurück, wenn eine Zeile in der Spalte SalesPersonID der ID einer SalesPerson-Anmeldung entspricht oder wenn der Benutzer, der die Abfrage ausführt, der Managerbenutzer ist.
CREATE SCHEMA Security;
GO
CREATE FUNCTION Security.fn_securitypredicate
(@SalesPersonID INT)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
SELECT 1 AS fn_securitypredicate_result
WHERE ('SalesPerson' + CAST (@SalesPersonId AS VARCHAR (16)) = USER_NAME())
OR (USER_NAME() = 'Manager')
Erstellen Sie eine Sicherheitsrichtlinie, und fügen Sie der Tabelle diese Funktion als FILTER- und BLOCK-Prädikat hinzu:
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader,
ADD BLOCK PREDICATE Security.fn_securitypredicate(SalesPersonID) ON Sales.SalesOrderHeader
WITH (STATE = ON);
Führen Sie den folgenden Code aus, um die Tabelle SalesOrderHeader mit jedem Benutzer abzufragen. Überprüfen Sie, dass SalesPerson280 nur die 95 Zeilen aus dem eigenen Vertrieb sehen kann und dass Manager alle Zeilen in der Tabelle sehen kann.
EXECUTE AS USER = 'SalesPerson280';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
EXECUTE AS USER = 'Manager';
SELECT *
FROM Sales.SalesOrderHeader;
REVERT;
Ändern Sie die Sicherheitsrichtlinie, um die Richtlinie zu deaktivieren. Nun können beide Benutzer alle Zeilen anzeigen.
ALTER SECURITY POLICY SalesFilter
WITH (STATE = OFF);
Aktivieren des dynamischen Datenmaskierens
Mithilfe der dynamischen Datenmaskierung kann der Zugriff auf vertrauliche Daten auf die Benutzer einer Anwendung beschränkt werden, indem bestimmte Spalten vollständig oder teilweise maskiert werden.
Führen Sie eine ALTER TABLE-Anweisung aus, um der Spalte EmailAddress in der Tabelle Person.EmailAddress eine Maskierungsfunktion hinzuzufügen:
USE AdventureWorks2022;
GO
ALTER TABLE Person.EmailAddress
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'email()');
Erstellen Sie den neuen Benutzer TestUser mit der SELECT-Berechtigung für die Tabelle, und führen Sie dann eine Abfrage als TestUser aus, um die maskierten Daten anzuzeigen:
CREATE USER TestUser WITHOUT LOGIN;
GRANT SELECT
ON Person.EmailAddress TO TestUser;
EXECUTE AS USER = 'TestUser';
SELECT EmailAddressID,
EmailAddress
FROM Person.EmailAddress;
REVERT;
Überprüfen Sie, ob die Maskierungsfunktion die E-Mail-Adresse im ersten Datensatz wie folgt ändert. Von:
| EmailAddressID | E-Mail-Adresse |
|---|---|
| 1 | ken0@adventure-works.com |
in
| EmailAddressID | E-Mail-Adresse |
|---|---|
| 1 | kXXX@XXXX.com |
Aktivieren von Transparent Data Encryption
Ein Risiko von Datenbanken ist, dass die Datenbankdateien von Ihrem Festplattenlaufwerk gestohlen werden. Dies kann passieren, wenn ein Angreifer aufgrund der Handlungen eines unvorsichtigen Mitarbeiters oder durch Diebstahl des Computers (z. B. eines Laptops), auf dem die Dateien gespeichert sind, erhöhten Zugriff auf Ihr System erhält.
Mit Transparent Data Encryption (TDE) werden die Datendateien verschlüsselt, wenn sie auf dem Festplattenlaufwerk gespeichert werden. Die master-Datenbank der SQL Server-Datenbank-Engine verfügt über den Verschlüsselungsschlüssel, sodass die Datenbank-Engine die Daten bearbeiten kann. Ohne den Schlüssel können die Datenbankdateien nicht gelesen werden. Höherrangige Administratoren können den Schlüssel verwalten, sichern und neu erstellen. Dies bedeutet, dass die Datenbank verschoben werden kann, jedoch nur von ausgewählten Personen. Wenn TDE konfiguriert ist, wird die Datenbank tempdb ebenfalls automatisch verschlüsselt.
Da die Datenbank-Engine die Daten lesen kann, schützt TDE weder vor unbefugtem Zugriff durch Administratoren des Computers, der Arbeitsspeicher direkt auslesen kann, noch vor unbefugtem Zugriff auf SQL Server über ein Administratorkonto.
Konfigurieren von TDE
- Erstellen Sie einen Hauptschlüssel
- Erstellen oder beziehen Sie ein vom Hauptschlüssel geschütztes Zertifikat
- Erstellen Sie einen Verschlüsselungsschlüssel für die Datenbank, und schützen Sie ihn durch das Zertifikat
- Legen Sie fest, dass für die Datenbank Verschlüsselung verwendet wird
Zum Konfigurieren von TDE ist die CONTROL-Berechtigung für die master-Datenbank und die CONTROL-Berechtigung für die Benutzerdatenbank erforderlich. TDE wird in der Regel von einem Administrator konfiguriert.
Im folgenden Beispiel wird die Verschlüsselung und Entschlüsselung der AdventureWorks2025 -Datenbank gezeigt, wobei ein auf dem Server MyServerCertinstalliertes Zertifikat verwendet wird.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO
CREATE CERTIFICATE MyServerCert
WITH SUBJECT = 'My Database Encryption Key Certificate';
GO
USE AdventureWorks2022;
GO
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2022
SET ENCRYPTION ON;
Führen Sie den folgenden Befehl aus, um TDE zu entfernen:
ALTER DATABASE AdventureWorks2022
SET ENCRYPTION OFF;
Die Verschlüsselungs- und Entschlüsselungsvorgänge werden von SQL Server in geplanten Hintergrundthreads ausgeführt. Sie können den Status dieser Vorgänge mithilfe der in der Liste weiter unten in diesem Artikel genannten Katalogsichten und dynamischen Verwaltungssichten anzeigen.
Warning
Sicherungsdateien von Datenbanken, für die TDE aktiviert wurde, werden ebenfalls mithilfe des Verschlüsselungsschlüssels für die Datenbank verschlüsselt. Darum muss bei der Wiederherstellung dieser Sicherungen das Zertifikat, das zum Verschlüsseln des Verschlüsselungsschlüssels für die Datenbank verwendet wurde, verfügbar sein. Dies bedeutet, dass Sie zusätzlich zur Sicherung der Datenbank auch Sicherungskopien der Serverzertifikate aufbewahren müssen, um einem Datenverlust vorzubeugen. Ist das Zertifikat nicht mehr verfügbar, kann es zu einem Datenverlust kommen. Weitere Informationen finden Sie unter SQL Server Certificates and Asymmetric Keys.
Weitere Informationen zu TDE finden Sie unter Transparent Data Encryption (TDE).
Konfigurieren der Sicherungsverschlüsselung
In SQL Server können die Daten während der Erstellung einer Sicherung verschlüsselt werden. Indem der Verschlüsselungsalgorithmus und der Verschlüsseler (ein Zertifikat oder ein asymmetrischer Schlüssel) beim Erstellen einer Sicherung angegeben werden, können Sie eine verschlüsselte Sicherungsdatei erstellen.
Warning
Sichern Sie immer das Zertifikat oder den asymmetrischen Schlüssel – vorzugsweise an einem anderen Speicherort als die Sicherungsdatei, die zum Verschlüsseln verwendet wurde. Ohne das Zertifikat oder den asymmetrischen Schlüssel können Sie keine Sicherung wiederherstellen, sodass die Sicherungsdatei unbrauchbar ist.
Im folgenden Beispiel werden ein Zertifikat und anschließend eine durch das Zertifikat geschützte Sicherung erstellt.
USE master;
GO
CREATE CERTIFICATE BackupEncryptCert
WITH SUBJECT = 'Database backups';
GO
BACKUP DATABASE [AdventureWorks2022]
TO DISK = N'/var/opt/mssql/backups/AdventureWorks2022.bak'
WITH COMPRESSION,
ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupEncryptCert),
STATS = 10;
GO
Weitere Informationen finden Sie unter Sicherungsverschlüsselung.