Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

13 Best Practices für die SQL Server-Sicherheit

Daten sind ein kritisches Gut jeder Organisation, und schlecht gesicherte Datenbanken sind allzu oft für Sicherheitsverletzungen verantwortlich. In diesem Artikel werden Best Practices für die Sicherheit von SQL-Servern sowie wichtige Sicherheitsüberlegungen zum Schutz Ihrer Datenbanken vor böswilligen Angriffen beschrieben.

Datensicherheit besteht aus drei wesentlichen Säulen – Vertraulichkeit, Integrität und Verfügbarkeit (CIA) und befasst sich mit spezifischen Prozessen zum Schutz von Daten vor beabsichtigtem und versehentlichem Zugriff. Lassen Sie uns die verschiedenen Bereiche und Schritte aufschlüsseln, die Sie unternehmen müssen, wenn Sie sich der SQL Server-Sicherheit nähern, einer der beliebtesten relationalen Datenbanken, die heute verwendet werden.

Best Practices für SQL Server-Sicherheit

1. Sorgen Sie für die physische Sicherheit Ihres SQL-Servers

Wenn es um die Sicherheit von SQL Server geht, darf die physische Sicherheit nicht übersehen werden. Physische Sicherheit bezieht sich auf die Einschränkung des unbefugten Zugriffs auf Rechenzentren oder andere physische Serverkomponenten. So können Sie beispielsweise einen verschlossenen Raum mit eingeschränktem Zutritt per Smartcard, Fingerabdruck oder Gesichtserkennung realisieren. Sie können auch ein eingeschränktes Netzwerksegment für SQL Server konfigurieren.

Rechenzentren beherbergen die Infrastruktur eines Unternehmens wie Router, Switches, Server, Firewalls und Speichergeräte. Physische Sicherheit befasst sich mit dem Schutz von Hardware, Software und dem Netzwerk vor unbefugtem Zugriff oder Naturkatastrophen. Dabei kann es sich um folgende Bereiche handeln:

  • Sicherung der Räumlichkeiten und des Zugangs zur Ausrüstung nur für autorisiertes Personal
  • Wartung von Zutrittskontrollsystemen
  • 24x7x365 Wachsamkeit durch Sicherheitspersonal vor Ort oder CCTV-Überwachung
  • Unterbrechungsfreie Stromversorgung (USV)
  • Ein Brandmeldesystem und ein Ansaugrauchmeldesystem haben
  • Mit einem aktiven Wasserleck-Detektorfeld
  • Nagetierabwehrsysteme
  • Feuerlöschsysteme
  • Steuerung und Überwachung von Temperatur und Luftfeuchtigkeit
  • Regelmäßige Hardwarewartung

2. Schützen Sie Ihr Betriebssystem

SQL Server wird auf einem vorhandenen Betriebssystem wie Windows oder Linux installiert. Daher spielt die Sicherheit des Betriebssystems eine entscheidende Rolle bei der Sicherheit von SQL Server. Nachfolgend finden Sie einige Empfehlungen zum Schutz Ihres Betriebssystems:

  • Regelmäßige Sicherheitspatches und Service Packs für das Betriebssystem anwenden
  • Definieren Sie eine Betriebssystem-Patch-Richtlinie, die Patches auf niedrigere Umgebungen anwendet, gefolgt von Produktions-Patching
  • Verwenden Sie immer stabile und unterstützte Produktbetriebssystemversionen. Beispielsweise hat Microsoft die Unterstützung für Windows Server 2003 eingestellt, daher sollten Sie es nicht für das Datenbank-Hosting verwenden
  • Gestatten Sie keinen Internetzugang auf Ihren Datenbankservern
  • Sie sollten ungenutzte Anwendungen und Laufwerke deinstallieren, stoppen oder deaktivieren, um weniger Möglichkeiten für potenzielle Angriffe zu schaffen
  • Implementieren Sie eine Firewall mit eingeschränktem Zugriff auf Datenbankserver, sodass nur Anwendungsserver, die Zugriff auf den Datenbankserver benötigen, Datenverkehr von den Firewalls durchlassen dürfen
  • Öffnen Sie bestimmte Ports in der Firewall. Beispielsweise wird SQL Server standardmäßig auf Port 1433 ausgeführt. Daher können Sie die TCP-Ports 1433 und 3389 für den Remoteserverzugriff zulassen, wenn keine andere Anwendung auf dem Server ausgeführt wird. Ebenso verwendet der Analysedienst den Standardport 2383 als Standardport. Eine vollständige Liste der Ports in SQL Server finden Sie in dieser Dokumentation zu den von SQL Server verwendeten Ports. Sie können auch SSL- oder TLS-Zertifikate verwenden, um den Zugriff auf SQL Server zu sichern. Diese Zertifikate können die Datenübertragung zwischen SQL Server und Clientanwendungen verschlüsseln. Für ein selbstsigniertes Zertifikat oder das von der Zertifizierungsstelle (CA) ausgestellte Zertifikat ist eine SQL Server-Konfiguration erforderlich. Weitere Informationen finden Sie in folgendem Artikel: Einrichten und Verwenden verschlüsselter SQL Server-Verbindungen.
  • Nutzen Sie die Option „Erweiterter Schutz für die Authentifizierung“, um einen Authentifizierungs-Relay-Angriff mithilfe der Dienstbindung und der Kanalbindung zu verhindern. Um den erweiterten Schutz zu aktivieren, gehen Sie zum SQL Server Configuration Manager, erweitern Sie den Bildschirm, klicken Sie mit der rechten Maustaste auf Protokolle und gehen Sie dann zu Erweiterter, erweiterter Schutz. Beachten Sie, dass dies standardmäßig deaktiviert ist.

Auf ähnliche Weise können Sie die verschlüsselte Verbindung zu SQL Server mit der folgenden Option erzwingen.

Weitere Einzelheiten finden Sie auch unter „Erweiterter Schutz“.

3. Reduzieren Sie Ihre Oberfläche

Die SQL Server-Oberfläche besteht aus Datenbank-Engine-Features, die zusätzliche Funktionen wie das Senden von E-Mails bereitstellen. Diese Komponenten könnten ein potenzielles Ziel sein, um sich für böswillige Aktivitäten Zugriff auf SQL Server zu verschaffen. Daher sollten Sie die nicht verwendeten Komponenten und Funktionen in SQL Server deaktivieren, da dies die Wahrscheinlichkeit eines potenziellen Angriffs einschränkt. Die wichtigsten Komponenten, die Sie überprüfen und deaktivieren können, sind unten aufgeführt.

  • Nach Startprozessen suchen
  • OLE-Automatisierungsverfahren
  • CLR aktiviert
  • DB-übergreifende Eigentumsverkettung
  • xp_cmdshell
  • Datenbank-E-Mail-XPs

Ausführliche Informationen zu Serverkonfigurationsoptionen finden Sie in diesem Artikel.

4. Konfigurieren Sie einen Server so, dass er auf einem anderen Port lauscht

Microsoft SQL Server verwendet den Standardport 1433 für alle Datenbankverbindungen. Dies ist ein häufiges Sicherheitsrisiko in vielen Datenbankumgebungen, da Datenbankprofis den Standardport normalerweise nicht ändern. Es ist ein bekannter Port, und Eindringlinge können diese Gelegenheit nutzen, um auf SQL Server zuzugreifen. Daher sollten Sie einen nicht standardmäßigen Port verwenden, um Ihre SQL Server-Sicherheit zu verstärken. Sie können dies mit dem SQL Server Configuration Manager ändern.

5. Passen Sie die SQL Server-Authentifizierung an

Der Schutz Ihrer Daten hängt von der Möglichkeit ab, den Zugriff auf bestimmte Daten zu authentifizieren. SQL Server bietet zwei Optionen für die Datenbankauthentifizierung.

  • Windows-Authentifizierung
  • Windows- und SQL-Authentifizierung (gemischter Modus)

Um das Serverauthentifizierungsmodell zu überprüfen, klicken Sie mit der rechten Maustaste auf die SQL Server-Instanz und navigieren Sie zu Sicherheit.

Die Windows-Authentifizierung verwendet Active Directory-Konten für Authentifizierungen. Sie können eine zentralisierte Richtliniensteuerung für Kennwortkomplexität, Kennwortablauf, Kontosperrung und Active Directory-Gruppen im Active Directory haben. Daher sollten Sie die Windows-Authentifizierung anstelle der SQL Server-Authentifizierung verwenden. Hier stellt der Benutzer eine Verbindung mit einem Windows-Konto her, und SQL Server validiert die Anmeldeinformationen mit dem Windows-Principal-Token. Es verwendet das Kerberos-Sicherheitsprotokoll für Authentifizierungen. Weitere Informationen finden Sie unter Authentifizierungsmodus.

Wenn Sie jedoch die SQL Server-Anmeldungen verwenden müssen, können Sie dennoch die Kennwortrichtlinie erzwingen, wie unten hervorgehoben.

6. Dienstkontoberechtigungen merken

SQL Services verwendet ein Windows-Konto, um seine Dienste auszuführen. Sie sollten keine hochprivilegierten, integrierten Konten wie Netzwerkdienst oder Lokales System verwenden. Ebenso sollten Sie einem Domänendienstkonto rollengerechte Berechtigungen zuweisen.

Daher würde ich empfehlen, für weitere Einzelheiten zu Berechtigungen für SQL Server-Dienstkonten auf Konfigurieren von Windows-Dienstkonten und -Berechtigungen zu verweisen.

7. Wenden Sie SQL Server-Patching in der Produktion an

Microsoft veröffentlicht reguläre Service Packs (SQL Server 2016 oder früher) und kumulative Packs (SQL Server 2017 und höher) zum Beheben bekannter Probleme und Sicherheitsprobleme. Daher sollten Sie immer planen, SQL Server-Patches auf den Produktionsinstanzen zu implementieren. Wenden Sie Patches jedoch nicht direkt auf Produktionsinstanzen an. Wenden Sie sie immer zuerst in der Testumgebung an, validieren und planen Sie die Bereitstellung in der Produktion.

Einzelheiten zu den neuesten Service Packs und kumulativen Packs finden Sie in den neuesten Updates für Microsoft SQL Server.

8. Sichern Sie Ihre Backups

Wenn es um die Sicherheit von SQL Server geht, ist die Sicherung Ihrer Backups von entscheidender Bedeutung. Typischerweise berücksichtigen Datenbankexperten nicht alle Anforderungen zum Sichern von Datenbanksicherungen. Datenbanksicherung ist der Prozess der Erstellung einer Kopie des Betriebszustands, der Architektur und der gespeicherten Daten einer Datenbank. Daher ist es ebenso wichtig, sie zu schützen. Es bedeutet, den Zugriff auf Sicherungsdateien einzuschränken und sie ordnungsgemäß zu verschlüsseln. Hier einige Hinweise zur Sicherung von Backups.

  • Geben Sie nicht jedem die Rechte für den Backup-Ordner, um Backup-Dateien zu erstellen, anzuzeigen, zu ändern und zu löschen
  • Verwenden Sie Datenbanksicherungen mit Verschlüsselung; Weitere Informationen finden Sie in diesem Artikel zur Sicherungsverschlüsselung

9. Denken Sie an die Verschlüsselungs- und Datenmaskierungstechniken von SQL Server

Ein wichtiger Bereich der SQL Server-Sicherheit ist die Verschlüsselung. Sie können verschiedene Verschlüsselungsmechanismen verwenden, um vertrauliche Daten in Ihrer SQL Server-Datenbank zu schützen. Die verschiedenen Verschlüsselungsoptionen sind wie folgt.

  • Always Encrypted:Die Always-Encrypted-Technik hilft, vertrauliche Daten innerhalb der Client-Anwendungen zu verschlüsseln. Der stets verschlüsselte Treiber verschlüsselt und entschlüsselt automatisch vertrauliche Daten in den Client-Anwendungen. Die Verschlüsselungsschlüssel werden dem SQL Server-Datenbankmodul niemals offengelegt. Es schützt vertrauliche Daten.
  • Transparente Datenverschlüsselung (TDE):Die TDE verschlüsselt ruhende Daten. Es hilft, die Datendateien, Protokolldateien und Sicherungsdateien zu sichern.
  • Verschlüsselung auf Spaltenebene:Die Verschlüsselung auf Spaltenebene hilft bei der Verschlüsselung bestimmter Spaltendaten, z. B. Kreditkartennummern und Sozialversicherungsnummern.
  • Statische Datenmaskierung:Die statische Datenmaskierung ersetzt die sensiblen Daten mithilfe der definierten Datentransformationsregeln.
  • Dynamische Datenmaskierung:Dynamische Datenmaskierung hilft, die Offenlegung sensibler Daten für nicht privilegierte Benutzer zu begrenzen.
  • Sicherheit auf Zeilenebene:Die Sicherheit auf Zeilenebene schränkt den Zugriff auf Datenzeilen ein.

10. Machen Sie das Passwort des Systemadministrators kompliziert

Wenn Sie die SQL-Authentifizierung verwenden, wird eine Anmelde-SA mit den Sysadmin-Berechtigungen erstellt. Gehen Sie wie folgt vor, um Ihren SQL Server zu schützen.

  • Benennen Sie das Login mit dem Namen SA in einen anderen Namen um
  • Deaktivieren Sie das Konto, wenn Sie es nicht verwenden möchten
  • Verwenden Sie ein komplexes Passwort
  • Erlauben Sie Anwendungen nicht, das SA-Konto in den Verbindungszeichenfolgen zu verwenden

11. Datenbankanmeldungen prüfen

Auditing wird oft übersehen, wenn es um die Sicherheit von SQL Server geht. Sie sollten eine regelmäßige SQL Server-Prüfung auf fehlgeschlagene Anmeldungen durchführen. Sie können den standardmäßigen Login-Audit-Mechanismus zum Überprüfen der Konten verwenden. Angenommen, ein Benutzer versucht, sich mit einem Konto mit hohen Berechtigungen mit SQL Server zu verbinden. In diesem Fall können Sie den Anmeldefehler und die IP-Adresse der eingehenden Anfrage (Client) sehen. Dies kann Ihnen dabei helfen, verdächtige Aktivitäten zu erfassen und zu beseitigen.

Sie können die erweiterten Ereignisse, SQL-Ablaufverfolgung, Änderungsdatenerfassung, Trigger (DDL, DML oder Logon), Datenbank- oder Serverebenen-Audit-Spezifikationen für das SQL Server-Audit verwenden.

12. Achten Sie auf Server- und Datenbankberechtigungen

Datenbankexperten sollten beim Zuweisen von Berechtigungen auf Server- oder Datenbankebene vorsichtig sein. Manchmal sehen wir, dass Entwickler Sysadmin auf Serverebene oder die Berechtigungen des Datenbankbesitzers auf Datenbankebene erhalten. Dies sind die höchsten Berechtigungen, die ein Benutzer auf Instanz- bzw. Datenbankebene haben kann.

  • Weitere Informationen zu festen Rollen auf Serverebene und ihren Funktionen finden Sie unter Feste Rollen auf Serverebene.
  • Beziehen Sie sich auf Rollen auf Datenbankebene, um feste Rollen auf Datenbankebene besser zu verstehen.

13. Deaktivieren Sie den SQL Server-Browserdienst

SQL Server verwendet den Browserdienst für die benannte Instanz. Es überwacht alle eingehenden Anforderungen für SQL Server-Verbindungen. Es verwendet den UDP-Port 1434 und antwortet auf die Anforderungen mit der TCP/IP-Portnummer, die für die Verbindung mit SQL Server erforderlich ist. Daher können Sie den Browserdienst deaktivieren und die Portnummer explizit in den Anwendungszeichenfolgen definieren. Dies vermeidet, dass die Portnummer den eingehenden Verbindungsanforderungen ausgesetzt wird, und trägt zur Sicherheit von SQL Server bei.

Weitere Informationen zum SQL Server-Browserdienst finden Sie im Artikel Funktionsweise des SQL Server-Browsers.

Weitere Überlegungen zur SQL Server-Sicherheit

Wie bereits erwähnt, ist die SQL Server-Sicherheit ein fortlaufender Prozess mit verschiedenen Faktoren und Schritten. Sie müssen SQL Server-Instanzen und Sicherheitsrichtlinien regelmäßig überprüfen und sie sowohl auf Betriebssystem- als auch auf SQL Server-Ebene routinemäßig aktualisieren. Durch die regelmäßige Anwendung dieser Best Practices tragen Sie dazu bei, einen sichereren und unterbrechungsfreien Datenbankdienst für Ihr Unternehmen zu erstellen.