Microsoft verfügt in SQL Server 2017 über eine Reihe von Sicherheitsfunktionen, die für verschiedene Zwecke nützlich sind, je nachdem, was Sie schützen möchten und vor welchen Bedrohungen Sie sich schützen möchten. Einige dieser Sicherheitsfunktionen können Auswirkungen auf die Leistung haben, die Sie berücksichtigen sollten, wenn Sie entscheiden, welche Sie implementieren möchten. Als Einführung werde ich einige der Highlights einiger dieser Sicherheitsfunktionen behandeln.
Transparente Datenbankverschlüsselung (TDE)
Transparent Data Encryption (TDE) ist die Form der SQL Server-Verschlüsselung im Ruhezustand, was bedeutet, dass Ihre Datendateien, Protokolldateien, tempdb-Dateien und Ihre vollständigen, differenziellen und Protokollsicherungen von SQL Server verschlüsselt werden, wenn Sie TDE für eine Benutzerdatenbank aktivieren . Dies schützt Ihre Daten davor, dass jemand Zugriff auf diese Datenbank oder Datenbank-Sicherungsdateien erhält, solange diese Person nicht auch Zugriff auf Ihre Verschlüsselungszertifikate und Schlüssel hat.
Der anfängliche TDE-Verschlüsselungsscan für eine Benutzerdatenbank verwendet einen Hintergrund-CPU-Thread pro Datendatei in der Datenbank (wenn sich die Datendateien auf separaten logischen Laufwerken befinden), um den gesamten Inhalt der Datendatei mit einer Geschwindigkeit von langsam in den Arbeitsspeicher einzulesen etwa 52 MB/Sekunde pro Datendatei (wenn sich die Datendateien auf separaten logischen Laufwerken befinden).
Die Daten werden dann mit dem von Ihnen gewählten Verschlüsselungsalgorithmus verschlüsselt und dann mit etwa 55 MB/Sekunde (pro Datendatei, wenn sie sich auf separaten logischen Laufwerken befinden) wieder in die Datendatei geschrieben. Diese sequentiellen Lese- und Schreibraten scheinen absichtlich gedrosselt zu sein und sind in meinen Tests auf mehreren Systemen mit verschiedenen Speichertypen konsistent.
Der anfängliche TDE-Verschlüsselungsprozess findet auf Seitenebene unterhalb von SQL Server statt, sodass keine Sperren verursacht oder Transaktionsprotokollaktivitäten generiert werden, wie dies bei der Neuerstellung eines Index der Fall wäre. Sie können einen TDE-Verschlüsselungsscan anhalten, indem Sie globales TF 5004 aktivieren, und ihn wieder anhalten, indem Sie TF 5004 deaktivieren und Ihren Befehl ALTER DATABASE dbNAME SET ENCRYTION ON erneut ausführen, ohne dass der Fortschritt verloren geht.
Die CPU-Auswirkung der Verschlüsselung/Entschlüsselung wird auf SQL Server 2016 und neuer stark reduziert, wenn Sie über einen Prozessor verfügen, der AES-NI-Hardwareanweisungen unterstützt. Im Serverbereich wurden diese in der Produktfamilie Intel Xeon 5600 (Westmere-EP) für Server mit zwei Sockeln und der Produktfamilie Intel Xeon E7-4800/8800 (Westmere-EX) für Server mit vier und acht Sockeln eingeführt. Jede neuere Intel-Produktfamilie wird auch AES-NI-Unterstützung haben. Wenn Sie sich nicht sicher sind, ob Ihr Prozessor AES-NI unterstützt, können Sie im Befehlsfeld, das von CPU-Z ausgegeben wird, nach „AES“ suchen, wie Sie in Abbildung 1 sehen.
Abbildung 1:CPU-Z-Ausgabe mit AES-Befehlsunterstützung
Nachdem Sie eine Datenbank mit TDE verschlüsselt haben, ist die Laufzeitauswirkung von TDE schwer vorhersagbar zu quantifizieren, da sie absolut von Ihrer Arbeitslast abhängt. Wenn Ihre Arbeitsauslastung beispielsweise vollständig in den SQL Server-Pufferpool passt, würde TDE im Wesentlichen keinen Overhead verursachen. Wenn Ihre Arbeitslast andererseits ausschließlich aus Tabellenscans bestünde, bei denen die Seite gelesen und dann fast sofort geleert wird, würde dies die maximale Strafe bedeuten. Die maximale Strafe für eine flüchtige E/A-Workload beträgt bei moderner Hardware und mit SQL Server 2016 oder höher in der Regel weniger als 5 %.
Die zusätzliche Arbeit der TDE-Entschlüsselung erfolgt, wenn Sie Daten aus dem Speicher in den Pufferpool lesen, und die zusätzliche Arbeit der TDE-Verschlüsselung erfolgt, wenn Sie die Daten wieder in den Speicher schreiben. Stellen Sie sicher, dass Sie nicht unter Speicherdruck stehen, indem Sie über einen ausreichend großen Pufferpool verfügen und Index- und Abfrageoptimierungen durchführen, um die Auswirkungen von TDE auf die Leistung zu verringern. TDE verschlüsselt keine FILESTREAM-Daten, und eine mit TDE verschlüsselte Datenbank verwendet keine sofortige Dateiinitialisierung für ihre Datendateien.
Vor SQL Server 2016 funktionierten TDE und native Sicherungskomprimierung nicht gut zusammen. Mit SQL Server 2016 und höher können Sie TDE und native Sicherungskomprimierung zusammen verwenden, solange Sie im Sicherungsbefehl eine MAXTRANSFERSIZE angeben, die größer als 64 KB ist. Es ist auch sehr wichtig, dass Sie mit Ihren kumulativen Updates auf dem neuesten Stand sind, da es mehrere wichtige TDE-bezogene Hotfixes für SQL Server 2016 und SQL Server 2017 gab. Schließlich ist TDE auch nach SQL Server 2016 immer noch eine einzige Funktion der Enterprise Edition SP1 (das der Standard Edition viele nur für Unternehmen verfügbare Funktionen hinzufügte).
Sicherheit auf Zeilenebene (RLS)
Row-Level Security (RLS) schränkt den Lesezugriff und die meisten Schreibzugriffe basierend auf Attributen des Benutzers ein. RLS verwendet eine sogenannte prädikatbasierte Zugriffskontrolle. SQL Server wendet die Zugriffsbeschränkungen in der Datenbankschicht an, und sie werden jedes Mal angewendet, wenn versucht wird, auf Daten von irgendeiner Schicht zuzugreifen.
RLS funktioniert, indem es eine Prädikatfunktion erstellt, die die Zeilen begrenzt, auf die ein Benutzer zugreifen kann, und dann eine Sicherheitsrichtlinie und ein Sicherheitsprädikat verwendet, um diese Funktion auf eine Tabelle anzuwenden.
Es gibt zwei Arten von Sicherheitsprädikaten, nämlich Filterprädikate und Blockprädikate. Filterprädikate filtern im Hintergrund die Zeilen, die für Lesevorgänge (SELECT, UPDATE und DELETE) verfügbar sind, indem sie im Wesentlichen eine WHERE-Klausel hinzufügen, die verhindert, dass die gefilterten Zeilen in der Ergebnismenge angezeigt werden. Filterprädikate werden angewendet, während die Daten aus der Basistabelle gelesen werden, und der Benutzer oder die Anwendung weiß nicht, dass Zeilen aus den Ergebnissen gefiltert werden. Aus Leistungssicht ist es wichtig, einen Zeilenspeicherindex zu haben, der Ihr RLS-Filterprädikat abdeckt.
Blockiert Prädikate explizit (mit einer Fehlermeldung) Blockschreiboperationen (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE und BEFORE DELETE), die das Blockprädikat verletzen würden.
Filter- und Blockprädikate werden als Inline-Tabellenwertfunktionen erstellt. Sie müssen auch die T-SQL-Anweisung CREATE SECURITY POLICY verwenden, um die Filterfunktion auf die relevante Basistabelle anzuwenden und zu aktivieren
RLS wurde in SQL Server 2016 hinzugefügt und ist in allen Editionen von SQL Server 2016 und höher verfügbar. RLS funktioniert nicht mit Filestream, Polybase und indizierten Ansichten. RLS kann die Leistung der Volltextsuche beeinträchtigen und Abfragen von Columnstore-Indizes dazu zwingen, den Zeilenmodus anstelle des Stapelmodus zu verwenden. Dieser Microsoft-Blogbeitrag enthält weitere Informationen zu den Auswirkungen von RLS auf die Leistung. Ein gutes Beispiel für die Verwendung des Abfragespeichers zur Optimierung der RLS-Leistung finden Sie hier.
Dynamische Datenmaskierung (DDM)
Dynamische Datenmaskierung (DDM) kann dazu beitragen, die Offenlegung sensibler Daten zu begrenzen, indem sie für nicht privilegierte Benutzer maskiert wird. DDM wird auf Tabellenebene angewendet, sodass alle Abfragen von der Datenmaskierung betroffen sind, während die eigentlichen Maskierungsregeln auf einzelne Spalten in der Tabelle angewendet werden.
Es gibt vier Arten von Datenmasken, die Sie verwenden können, darunter Standard, E-Mail, benutzerdefinierte Zeichenfolge und zufällig. Eine Standardmaske bietet je nach Datentyp eine vollständige Standardmaskierung der Daten. Beispielsweise würde ein String-Datentyp anstelle der eigentlichen Daten die Maske „XXXX“ erhalten. Eine E-Mail-Maske gibt den ersten Buchstaben der tatsächlichen E-Mail-Adresse zurück, gefolgt von [email protected], unabhängig vom tatsächlichen Domain-Suffix. Eine benutzerdefinierte Zeichenfolgenmaske zeigt den ersten und letzten Buchstaben der Zeichenfolge mit einer benutzerdefinierten Auffüllung in der Mitte. Schließlich wird eine Zufallsmaske verwendet, um numerische Daten zu maskieren und einen Zufallswert in einem definierten Bereich bereitzustellen. Datenmasken können in einer CREATE TABLE-Anweisung oder mit einer ALTER COLUMN-Anweisung erstellt werden.
Die dynamische Datenmaskierung bietet keine Maskierung für privilegierte Benutzer, die Ihre Tabellen dennoch direkt abfragen und die nicht maskierten Daten anzeigen können. Maskierungsregeln können nicht mit verschlüsselten Spalten (Always Encrypted), berechneten Spalten oder mit Filestream-Daten verwendet werden. Wenn es vorhandene Indizes für eine Spalte gibt, die Sie maskieren möchten, müssen Sie den Index löschen, die Maske für die Spalte erstellen und dann den Index neu erstellen. Es ist auch möglich, die Werte für maskierte Datenspalten abzuleiten, indem Sie Abfragen schreiben, die es dem Benutzer ermöglichen, schließlich einen Wert für eine maskierte Spalte zu erraten.
Dynamische Datenmaskierung wurde in SQL Server 2016 eingeführt und ist in allen Editionen von SQL Server verfügbar. DDM ist nicht als starke Sicherheitsmaßnahme wie die tatsächliche Verschlüsselung gedacht, aber andererseits scheint seine Auswirkung auf die Leistung ziemlich vernachlässigbar zu sein.
