Bewährte Sicherheitsmethoden für SQL Server

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

Dieser Artikel enthält Informationen zu bewährten Methoden und Richtlinien, die das Einrichten der Sicherheit für SQL Server unterstützen. Eine umfassende Übersicht über SQL Server-Sicherheitsfeatures finden Sie unter Sichern von SQL Server.

Spezifische bewährte Methoden für die Produktsicherheit finden Sie unter Playbook für den Umgang mit allgemeinen Sicherheitsanforderungen für Azure SQL-Datenbank und Azure SQL Managed Instance und Überlegungen zur Sicherheit von SQL Server auf Azure Virtual Machines.

Übersicht

Eine mehrschichtige Sicherheitsmethodik bietet eine Lösung zur tiefgehenden Verteidigung, indem mehrere Sicherheitsfunktionen für verschiedene Sicherheitsbereiche genutzt werden. Die in SQL Server 2016 verfügbaren und in nachfolgenden Releases verbesserten Sicherheitsfeatures unterstützen die Beseitigung von Sicherheitsbedrohungen und sorgen für gut gesicherte Datenbankanwendungen.

Azure erfüllt mehrere Branchenvorgaben und Standards, mit denen Sie eine konforme Lösung mit SQL Server auf einem virtuellen Computer erstellen können. Weitere Informationen zur Einhaltung von Vorschriften durch Azure finden Sie unter Azure Trust Center.

Schutz auf Spaltenebene

Organisationen müssen häufig Daten auf Spaltenebene schützen, da Daten zu Kunden, Mitarbeitern, Geschäftsgeheimnissen, Produktdaten, Gesundheitswesen, Finanzen und andere sensiblen Daten häufig in SQL Server-Datenbanken gespeichert werden. Sensible Spalten enthalten häufig Identifikations-/Sozialversicherungsnummern, Mobiltelefonnummern, Vorname, Familienname, Finanzkontoidentifikation und alle anderen Daten, die als personenbezogene Informationen angesehen werden können.

Die in diesem Abschnitt erwähnten Methoden und Features erhöhen das Schutzniveau auf Spaltenebene mit minimalem Mehraufwand und ohne umfangreiche Änderungen am Anwendungscode.

Verwenden Sie Always Encrypted, um ruhende Daten und Daten während der Übertragung zu verschlüsseln. Verschlüsselte Daten werden nur von Clientbibliotheken auf der Clientebene der Anwendung entschlüsselt. Verwenden Sie nach Möglichkeit die zufällige Verschlüsselung statt der deterministischen. Always Encrypted (mit sicheren Enclaves) kann die Leistung für Vergleichsvorgänge wie BETWEEN, IN, LIKE, DISTINCT, Joins und mehr für zufällige Verschlüsselungsszenarien verbessern.

Verwenden Sie die dynamische Datenmaskierung (DDM), um Daten auf Spaltenebene zu verschleiern, wenn Always Encrypted keine verfügbare Option ist. Dynamische Datenmaskierung (DDM) ist nicht kompatibel mit Always Encrypted. Nutzen Sie nach Möglichkeit Always Encrypted statt der dynamischen Datenmaskierung.

Sie können auch GRANT-Berechtigungen auf Spaltenebene für eine Tabelle, Sicht oder Tabellenwertfunktion erteilen. Beachten Sie Folgendes: - Nur SELECT, , REFERENCESund UPDATE Berechtigungen können für eine Spalte erteilt werden. Eine DENY auf Tabellenebene hat keinen Vorrang vor einer GRANT auf Spaltenebene.

Schutz auf Zeilenebene

Sicherheit auf Zeilenebene (Row-Level Security, RLS) ermöglicht die Nutzung des Benutzerausführungskontexts, um den Zugriff auf Zeilen in einer Datenbanktabelle zu steuern. RLS stellt sicher, dass Benutzer nur den Datensatz sehen können, der sich auf sie bezieht. Dies bietet Ihrer Anwendung die Sicherheit auf Datensatzebene, ohne dass Sie erhebliche Änderungen an Ihrer Anwendung vornehmen müssen.

Die Geschäftslogik ist in Tabellenwertfunktionen gekapselt, die von einer Sicherheitsrichtlinie gesteuert werden, die die RLS-Funktionalität ein- und ausschaltet. Die Sicherheitsrichtlinie steuert auch die FILTER- und BLOCK-Prädikate, die an die Tabellen-RLS gebunden sind. Verwenden Sie Sicherheit auf Zeilenebene (RLS), um die Datensätze zu beschränken, die an den Benutzer zurückgegeben werden, der den Aufruf vornimmt. Nutzen Sie SESSION_CONTEXT (T-SQL) für Benutzer, die über eine Anwendung der mittleren Ebene eine Verbindung mit der Datenbank herstellen, bei der Anwendungsbenutzer dasselbe SQL Server-Benutzerkonto verwenden. Befolgen Sie die bewährten Methoden für die Sicherheit auf Zeilenebene, um eine optimale Leistung und Verwaltbarkeit zu erzielen.

Dateien-Verschlüsselung

Transparent Data Encryption (TDE) schützt die Daten auf Dateiebene durch die Verschlüsselung ruhender Daten für die Datenbankdateien. Transparent Data Encryption (TDE) stellt sicher, dass Datenbankdateien, Sicherungsdateien und tempdb-Dateien nicht angefügt und gelesen werden können, ohne dass ordnungsgemäße Zertifikate Datenbankdateien entschlüsseln. Ohne Transparent Data Encryption (TDE) kann ein Angreifer die physischen Medien (Laufwerke oder Sicherungsbänder) verwenden und die Datenbank wiederherstellen oder anfügen, um den Inhalt zu lesen. Transparent Data Encryption (TDE) wird für die Arbeit mit allen anderen Sicherheitsfunktionen in SQL Server unterstützt. Transparent Data Encryption (TDE) führt die E/A-Verschlüsselung und -Entschlüsselung der Daten und der Protokolldateien in Echtzeit durch. Bei der TDE-Verschlüsselung wird ein Datenbankverschlüsselungs-Schlüssel (Database Encryption Key, DEK) verwendet, der in der Benutzerdatenbank gespeichert ist. Der Verschlüsselungsschlüssel für die Datenbank kann auch mithilfe eines Zertifikats geschützt werden, das mit dem Datenbankhauptschlüssel der master-Datenbank geschützt wird.

Verwenden Sie TDE, um ruhende Daten, Sicherungen und tempdb zu schützen.

Überwachung und Berichterstellung

Um SQL Server zu überwachen, erstellen Sie eine Überwachungsrichtlinie auf Server- oder Datenbankebene. Eine Serverrichtlinie wird auf alle vorhandenen und neu erstellten Datenbanken auf dem Server angewendet. Aktivieren Sie der Einfachheit halber die Überwachung auf Serverebene, und lassen Sie zu, dass die Überwachung auf Datenbankebene die Eigenschaft auf Serverebene für alle Datenbanken erbt.

Überwachen Sie Tabellen und Spalten mit sensiblen Daten, auf die Sicherheitsmaßnahmen angewendet werden. Wenn eine Tabelle oder Spalte so wichtig ist, dass sie Schutz durch eine Sicherheitsfunktion benötigt, sollte sie als wichtig genug angesehen werden, um überwacht zu werden. Es ist besonders wichtig, Tabellen zu überwachen und regelmäßig zu überprüfen, die vertrauliche Informationen enthalten, bei denen es aber aufgrund einer Anwendungs- oder Architekturbeschränkung nicht möglich ist, die gewünschten Sicherheitsmaßnahmen anzuwenden.

Identitäten und Authentifizierung

SQL Server unterstützt zwei Authentifizierungsmodi: Windows-Authentifizierungsmodus und „SQL Server- und Windows-Authentifizierungsmodus“ (gemischter Modus).

Anmeldungen sind nicht mit Datenbankbenutzern identisch. Sie müssen Anmeldungen oder Windows-Gruppen separat Datenbankbenutzern oder -rollen zuordnen. Erteilen Sie als Nächstes Benutzern, Serverrollen und/oder Datenbankrollen Berechtigungen für den Zugriff auf Datenbankobjekte.

SQL Server unterstützt die folgenden Anmeldungstypen:

• Ein lokales Windows-Benutzerkonto oder Active Directory-Domänenkonto: SQL Server verwendet Windows zum Authentifizieren der Windows-Benutzerkonten.
• Windows-Gruppe: Wenn Sie einer Windows-Gruppe Zugriff gewähren, wird der Zugriff für alle Windows-Benutzeranmeldungen gewährt, die Mitglieder der Gruppe sind. Durch das Entfernen eines Benutzers aus einer Gruppe werden die Rechte für den Benutzer entfernt, der aus der Gruppe stammt. Gruppenmitgliedschaft ist die bevorzugte Strategie.
• SQL Server-Anmeldung: SQL Server speichert den Benutzernamen und einen Hash des Kennworts in der master-Datenbank.
• Benutzer eigenständiger Datenbanken authentifizieren SQL Server-Verbindungen auf Datenbankebene. Eine eigenständige Datenbank ist eine Datenbank, die von anderen Datenbanken und der SQL Server-Instanz (und der master-Datenbank), die die Datenbank hostet, isoliert ist. SQL Server unterstützt eigenständige Datenbankbenutzer sowohl für die Windows- als auch für die SQL Server-Authentifizierung.

Die folgenden Empfehlungen und bewährten Methoden tragen zum Schutz Ihrer Identitäten und Authentifizierungsmethoden bei:

• Verwenden Sie rollenbasierte Sicherheitsstrategien mit den geringsten Rechten, um die Sicherheitsverwaltung zu verbessern.

  • Es ist üblich, Active Directory-Benutzer in AD-Gruppen zu platzieren, AD-Gruppen sollten in SQL Server-Rollen vorhanden sein, und SQL Server-Rollen sollten die für die Anwendung erforderlichen Mindestberechtigungen gewährt werden.

• Nutzen Sie in Azure die Sicherheit mit den geringsten Rechten, indem Sie rollenbasierte Zugriffssteuerungen (Role-Based Access, RBAC) verwenden.

• Wählen Sie nach Möglichkeit Active Directory anstelle der SQL Server-Authentifizierung und insbesondere Active Directory anstelle der Festlegung der Sicherheit auf Anwendungs- oder Datenbankebene aus.

  • Wenn ein Benutzer das Unternehmen verlässt, ist es einfach, das Konto zu deaktivieren.
  • Es ist auch einfach, Benutzer aus Gruppen zu entfernen, wenn Benutzer Rollen wechseln oder die Organisation verlassen. Die Gruppensicherheit wird als bewährte Methode betrachtet.

• Nutzen Sie Multi-Faktor-Authentifizierung für Konten mit Zugriff auf Computerebene, einschließlich Konten, die RDP für die Anmeldung beim Computer verwenden. Dies trägt zum Schutz vor Diebstahl oder Verlust von Anmeldeinformationen bei, da die kennwortbasierte Single-Factor-Authentifizierung eine schwächere Form der Authentifizierung ist, bei der das Risiko besteht, dass Anmeldeinformationen kompromittiert oder fälschlicherweise weitergegeben werden.

• Setzen Sie sicherere und komplexe Kennwörter voraus, die nicht leicht zu erraten sind und nicht für andere Konten oder Zwecke verwendet werden. Aktualisieren Sie Kennwörter regelmäßig, und erzwingen Sie Active Directory-Richtlinien.

• Gruppenverwaltete Dienstkonten (Group-Managed Service Accounts, gMSA) bieten eine automatische Kennwortverwaltung, eine einfachere Verwaltung des SPN-Namens (Service Principal Name, Dienstprinzipalname) und die Möglichkeit, die Verwaltung an andere Administratoren zu delegieren.

  • Mit gSMA verwaltet das Windows-Betriebssystem Kontokennwörter, sodass dies nicht dem Administrator obliegt.
  • gMSA aktualisiert die Kontokennwörter automatisch, ohne Dienste neu zu starten.
  • gMSA reduziert die Verwaltungsoberfläche und verbessert die Aufgabentrennung.

• Minimieren sie die Rechte, die dem AD-Konto des DBA gewährt werden. Erwägen Sie eine Aufgabentrennung, die den Zugriff auf den virtuellen Computer, die Möglichkeit, sich beim Betriebssystem anzumelden, die Fähigkeit, Fehler- und Überwachungsprotokolle zu ändern, und die Möglichkeit, Anwendungen und/oder Features zu installieren einschränkt.

• Erwägen Sie, DBA-Konten aus der Systemadministratorrolle zu entfernen und CONTROL SERVER DBA-Konten zu gewähren, anstatt sie zu Mitgliedern der sysadmin-Rolle zu machen. Die Systemadministratorrolle beachtet DENY nicht, während CONTROL SERVER dies tut.

Datenherkunft und Datenintegrität

Das Speichern historischer Aufzeichnungen von Datenänderungen im Laufe der Zeit kann von Vorteil sein, um versehentliche Änderungen an den Daten zu behandeln. Es kann auch für die Überwachung von Anwendungsänderungen nützlich sein und die Möglichkeit bieten, Datenelemente wiederherzustellen, wenn ein böswilliger Akteur nicht autorisierte Datenänderungen vorgenommen hat.

• Nutzen Sie temporale Tabellen, um Datensatzversionen im Laufe der Zeit beizubehalten und Daten in allen Phasen des Lebenszyklus des Datensatzes sehen zu können und so eine Verlaufsansicht der Daten Ihrer Anwendung zu erhalten.
• Temporale Tabellen können verwendet werden, um jederzeit eine Version der aktuellen Tabelle zu liefern.

Sicherheitsbewertungstools und Auswertung

Die unten angegebenen Konfigurations- und Bewertungstools ermöglichen, oberflächenspezifische Sicherheit zu verwalten, Möglichkeiten zur Datensicherheit zu identifizieren und bieten eine Best Practice-Bewertung der Sicherheit Ihrer SQL Server-Umgebung auf Instanzebene.

• Oberflächenkonfiguration: Sie sollten nur die Features aktivieren, die für Ihre Umgebung erforderlich sind, um die Anzahl der Features zu minimieren, die von einem böswilligen Benutzer angegriffen werden können.
• Sicherheitsrisikobewertung für SQL Server (SSMS): Die SQL-Sicherheitsrisikobewertung ist ein Tool in SSMS v17.4+, mit dem potenzielle Sicherheitsrisiken in der Datenbank gefunden, nachverfolgt und beseitigt werden können. Die Sicherheitsrisikobewertung ist ein wertvolles Tool zur Verbesserung der Datenbanksicherheit und wird auf Datenbankebene pro Datenbank ausgeführt.
• SQL Datenermittlung und -klassifizierung (SSMS): Es ist üblich, dass DBAs Server und Datenbanken ohne Berücksichtigung der Vertraulichkeit der in der Datenbank enthaltenen Daten verwalten. Die Datenermittlung und -klassifizierung fügt die Funktion zum Erkennen, Klassifizieren, Bezeichnen und Melden der Vertraulichkeitsstufe Ihrer Daten hinzu. Die Datenermittlung und -klassifizierung wird ab SSMS 17.5 unterstützt.

Allgemeine SQL-Bedrohungen

Es ist hilfreich zu wissen, welchen Bedrohungen SQL Server häufig ausgesetzt sein kann:

• Einschleusung von SQL-Befehlen: Eine Einschleusung von SQL-Befehlen ist ein Angriffstyp, bei dem Schadcode in Zeichenfolgen eingefügt wird, die später zur Ausführung an eine Instanz von SQL Server übergeben werden.
  • Beim Einschleusungsprozesses wird eine Textzeichenfolge beendet und ihr ein neuer Befehl angehängt. Da vor der Ausführung des eingefügten Befehls möglicherweise weitere Zeichenfolgen daran angehängt wurden, beendet der Angreifer die eingefügte Zeichenfolge durch eine Kommentarmarkierung --.
  • SQL Server führt alle empfangenen syntaktisch gültigen Abfragen aus.
• Beachten Sie Seitenkanalangriffe, Schadsoftware und andere Bedrohungen.

SQL-Einschleusungsrisiken

Um das Risiko einer SQL-Einschleusung zu minimieren, berücksichtigen Sie folgende Punkte:

• Überprüfen Sie alle SQL-Prozesse, die SQL-Anweisungen erstellen, auf Einschleusungsrisiken.
• Erstellen Sie dynamisch generierte SQL-Anweisungen parametrisiert.
• Entwickler und Sicherheitsadministratoren sollten den gesamten Code überprüfen, der EXECUTE, EXEC, oder sp_executesql aufruft.
• Die folgenden Eingabezeichen nicht zulassen:
  • ;: Abfragetrennzeichen
  • ': Trennzeichen für Datenzeichenfolgen
  • --: Einzeiliges Kommentartrennzeichen.
  • /* ... */: Kommentartrennzeichen.
  • xp_: Katalogerweiterte gespeicherte Prozeduren, z. B. xp_cmdshell.
    • Es wird nicht empfohlen, in einer SQL Server-Umgebung xp_cmdshell zu verwenden. Verwenden Sie stattdessen SQLCLR, oder suchen Sie aufgrund der Risiken, die xp_cmdshell mit sich bringen kann, nach anderen Alternativen.
• Überprüfen Sie immer Benutzereingaben und verhindern Sie, dass Fehlerausgaben für den Angreifer verfügbar gemacht werden.

Seitenkanalrisiken

Beachten Sie Folgendes, um das Risiko eines Seitenkanalangriffs zu minimieren:

• Stellen Sie sicher, dass die neuesten Anwendungs- und Betriebssystempatches angewendet werden.
• Stellen Sie bei Hybridworkloads sicher, dass die neuesten Firmwarepatches auf jede lokale Hardware angewendet werden.
• In Azure können Sie für hochsensible Anwendungen und Workloads zusätzlichen Schutz vor Seitenkanalangriffen mit isolierten virtuellen Computern, dedizierten Hosts oder durch die Nutzung von VMs, die vertrauliche Computerressourcen sind, wie die DC-Serie und VMs, die AMD EPYC-Prozessoren der dritten Generation nutzen, hinzufügen.

Infrastrukturbedrohungen

Berücksichtigen Sie die folgenden allgemeinen Infrastrukturbedrohungen:

• Brute-Force-Zugriff: Der Angreifer versucht, sich mit mehreren Kennwörtern bei verschiedenen Konten zu authentifizieren, bis ein korrektes Kennwort gefunden wird.
• Knacken des Kennworts/Kennwortspray: Angreifer versuchen ein einzelnes sorgfältig erstelltes Kennwort für alle bekannten Benutzerkonten zu verwenden (ein Kennwort für viele Konten). Wenn der anfängliche Kennwortspray erfolglos ist, versuchen sie es erneut, indem sie ein anderes sorgfältig erstelltes Kennwort verwenden und normalerweise eine festgelegte Zeitspanne zwischen Versuchen verstreichen lassen, um die Erkennung zu vermeiden.
• Ransomwareangriffe sind eine Art von gezielten Angriffen, bei denen Schadsoftware zum Verschlüsseln von Daten und Dateien verwendet wird, wodurch der Zugriff auf wichtige Inhalte verhindert wird. Die Angreifer versuchen dann, im Austausch für den Entschlüsselungsschlüssel Geld von den Geschädigten zu erpressen – normalerweise in Form von Kryptowährungen. Die meisten Ransomware-Infektionen beginnen mit E-Mail-Nachrichten mit Anlagen, die versuchen, Ransomware zu installieren, oder Websites, die Exploit Kits hosten, die versuchen, Sicherheitsrisiken in Webbrowsern und anderer Software zu verwenden, um Ransomware zu installieren.

Kennwortrisiken

Da Sie nicht möchten, dass Angreifer Kontonamen oder Kennwörter leicht erraten können, tragen die folgenden Schritte dazu bei, das Risiko zu verringern, dass Kennwörter erkannt werden:

• Erstellen Sie ein eindeutiges lokales Administratorkonto, das nicht den Namen Administratorhat.
• Verwenden Sie komplexe, sichere Kennwörter für alle Konten. Weitere Informationen zum Erstellen eines sicheren Kennworts finden Sie im Artikel Erstellen eines sicheren Kennworts.
• Standardmäßig wird für Azure während des Einrichtens von virtuellen Computern mit SQL Server die Windows-Authentifizierung ausgewählt. Aus diesem Grund wird beim Einrichten die SA -Anmeldung deaktiviert und ein Kennwort zugewiesen. Es wird empfohlen, die SA-Anmeldung nicht zu verwenden oder zu aktivieren. Verwenden Sie eine der folgenden Strategien, falls Sie eine SQL-Anmeldung benötigen:

  • Erstellen Sie ein SQL-Konto mit einem eindeutigen Namen, das über eine sysadmin-Mitgliedschaft verfügt. Hierfür können Sie das Portal verwenden, indem Sie während der Bereitstellung die Option SQL-Authentifizierung aktivieren.

    Tipp

    Wenn Sie die SQL-Authentifizierung während der Bereitstellung nicht aktivieren, müssen Sie den Authentifizierungsmodus manuell in SQL Server- und Windows-Authentifizierungsmodus ändern. Weitere Informationen finden Sie unter Ändern des Serverauthentifizierungsmodus.

  • Falls Sie die SA-Anmeldung verwenden müssen, sollten Sie die Anmeldung nach der Bereitstellung aktivieren und ein neues sicheres Kennwort zuweisen.

Ransomwarerisiken

Beachten Sie Folgendes, um Ransomwarerisiken zu minimieren:

• Die beste Strategie zum Schutz vor Ransomware ist, besonders auf RDP- und SSH-Sicherheitsrisiken zu achten. Beachten Sie zusätzlich die folgenden Empfehlungen:
  • Nutzen Sie Firewalls und Sperren Sie Ports
  • Stellen Sie sicher, dass die neuesten Sicherheitsupdates für Betriebssysteme und Anwendungen angewendet werden
  • Verwenden von gruppenverwalteten Dienstkonten (Group managed service accounts, gMSAs)
  • Beschränken des Zugriffs auf VMs
  • Just-in-Time-Zugriff (JIT) und Azure Bastion voraussetzen
  • Verbessern der Oberflächensicherheit durch Vermeiden der Installation von Tools einschließlich Sysinternals und SSMS auf dem lokalen Computer
  • Vermeiden Sie die Installation von Windows-Features, Rollen und das Aktivieren von Diensten, die nicht erforderlich sind
  • Darüber hinaus sollte eine regelmäßige vollständige Sicherung geplant werden, die getrennt von einem allgemeinen Administratorkonto gesichert ist, damit keine Kopien der Datenbanken gelöscht werden können.

Zugehöriger Inhalt

• Sichern von SQL Server
• Azure SQL-Datenbank und SQL Managed Instance
• SQL Server auf Azure VMs