SQL Server-Härtung Teil 2: So optimieren Sie Anmeldeinformationen und Berechtigungen

In Teil 2 unserer SQL Server-Härtungsreihe liegt unser Fokus auf der Optimierung von SQL Server-Berechtigungen und Anmeldeinformationen. Die Sicherheit Ihrer SQL Server-Instanz ist maßgeblich von der korrekten Konfiguration dieser beiden Elemente abhängig. Erfahren Sie in diesem Beitrag detaillierte Einblicke und profitieren Sie von praxisnahen Beispielen für eine effektive Härtung auf SQL Server-Ebene.

Überprüfung und Behebung von „Orphaned Users“ in SQL Server

Um die Sicherheit Ihrer SQL Server-Instanz zu gewährleisten, ist es entscheidend, Orphaned Users zu identifizieren und zu entfernen. Orphaned Users sind Benutzer, die keine zugehörigen Anmeldeinformationen haben und potenzielle Sicherheitsrisiken darstellen können. Durch ihre Beseitigung verhindern Sie möglichen Missbrauch dieser defekten Benutzer in Ihrer Datenbankumgebung.

Um Orphaned Users zu erkennen, führen Sie die folgende T-SQL-Abfrage in jeder Datenbank aus. Idealerweise sollten keine Zeilen zurückgegeben werden, was darauf hinweist, dass keine Orphaned Users vorhanden sind.

-- Beispiel für die Überprüfung und Behebung von "Orphaned Users"
exec master.sys.sp_MSforeachdb 'use [?]; PRINT ''Databasename : ?''; EXEC sp_change_users_login @Action=''Report''';

Sollte ein Orphaned User nicht mit einem bestehenden oder neuen Login gemäß dem von Microsoft dokumentierten Verfahren zugeordnet werden können, empfiehlt es sich, den Benutzer zu entfernen. Führen Sie dazu die folgende T-SQL-Abfrage in der entsprechenden Datenbank aus:

-- T-SQL-Abfrage zur Entfernung eines Orphaned Users
USE [IhreDatenbank];
EXEC sp_dropuser 'IhrOrphanedUser';

Durch diese proaktiven Maßnahmen minimieren Sie potenzielle Risiken und tragen dazu bei, die Integrität Ihrer SQL Server-Umgebung aufrechtzuerhalten. Bleiben Sie sicher und behalten Sie die bewährten Praktiken für eine optimale Datenbanksicherheit im Blick.

Sicherheitsüberprüfung der SQL Agent Proxies-Berechtigungen

Um die Sicherheit Ihrer SQL Server-Instanz zu gewährleisten, ist es wichtig sicherzustellen, dass die öffentliche Rolle in der msdb-Datenbank keinen Zugriff auf SQL Agent Proxies hat. Die öffentliche Datenbankrolle enthält jeden Benutzer in der msdb-Datenbank, während SQL Agent Proxies einen Sicherheitskontext definieren, in dem ein Job-Schritt ausgeführt werden kann.

Die Gewährung von Zugriff auf SQL Agent Proxies für die öffentliche Rolle würde es allen Benutzern ermöglichen, den Proxy zu nutzen, der möglicherweise hohe Privilegien hat. Dies könnte das Prinzip der geringsten Privilegien wahrscheinlich verletzen.

Verwenden Sie die folgende Syntax, um festzustellen, ob der msdb-Datenbankrolle öffentlicher Zugriff auf Proxies gewährt wurde.

-- T-SQL-Abfrage zur Überprüfung von Zugriffen auf Proxies für die öffentliche Rolle
USE [msdb];
SELECT sp.name AS proxyname
FROM dbo.sysproxylogin spl
JOIN sys.database_principals dp
ON dp.sid = spl.sid
JOIN sysproxies sp
ON sp.proxy_id = spl.proxy_id
WHERE principal_id = USER_ID('public');

Diese Abfrage sollte keine Zeilen zurückgeben, was darauf hindeutet, dass der öffentlichen Rolle kein Zugriff auf Proxies gewährt wurde.

Um sicherzustellen, dass die erforderlichen Sicherheitsprinzipien explizit Zugriff auf den Proxy erhalten, verwenden Sie sp_grant_login_to_proxy. Widerrufen Sie dann den Zugriff für die öffentliche Rolle auf den entsprechenden Proxy.

-- T-SQL-Abfrage zur Widerrufung des Zugriffs für die öffentliche Rolle auf den Proxy
USE [msdb];
EXEC dbo.sp_revoke_login_from_proxy @name = N'public', @proxy_name = N'<proxyname>';

Durch die Umsetzung dieser Maßnahmen minimieren Sie potenzielle Risiken und tragen dazu bei, die Integrität Ihrer SQL Server-Umgebung aufrechtzuerhalten. Beachten Sie dabei die bewährten Praktiken für eine optimale Datenbanksicherheit.

SQL Authentication in contained Datenbanken: Eine kritische Überprüfung

Die Verwendung von sogenannten „Contained Databases“ bietet zwar Flexibilität beim Verschieben von Datenbanken zwischen verschiedenen Instanzen und Umgebungen, bringt jedoch eine potenzielle Sicherheitsherausforderung mit sich. In Contained Databases werden keine Richtlinien zur Komplexität von Passwörtern für SQL-authentifizierte Benutzer durchgesetzt.

Das Fehlen einer durchgesetzten Passwortrichtlinie kann die Wahrscheinlichkeit erhöhen, dass schwache Anmeldeinformationen in einer Contained Database etabliert werden.

Um festzustellen, welche Datenbankbenutzer SQL-Authentifizierung verwenden und möglicherweise unsichere Passwörter haben, führen Sie die folgende T-SQL-Abfrage in jeder Contained Database aus:

-- T-SQL-Abfrage zur Überprüfung von SQL-authentifizierten Benutzern in Contained Databases
SELECT name AS DBUser
FROM sys.database_principals
WHERE name NOT IN ('dbo','Information_Schema','sys','guest')
AND type IN ('U','S','G')
AND authentication_type = 2;

Diese Abfrage gibt Benutzer zurück, die SQL-Authentifizierung verwenden und möglicherweise einer unsicheren Passwortrichtlinie unterliegen.

Um dieses Sicherheitsrisiko zu minimieren, empfehlen wir die Verwendung von Windows-authentifizierten Benutzern in Contained Databases. Dies gewährleistet eine bessere Einhaltung von Passwortrichtlinien und erhöht die Sicherheit der Authentifizierung.

Standardmäßig sind SQL-authentifizierte Benutzer (USER WITH PASSWORD-Authentifizierung) in Contained Databases erlaubt.

Standardberechtigungen für die öffentliche Serverrolle: Das sollten Sie wissen

Die Verwendung der öffentlichen Serverrolle sollte im Einklang mit dem Prinzip der geringsten Privilegien erfolgen. Die öffentliche Serverrolle sollte nicht dazu verwendet werden, Berechtigungen auf Serverebene zu erteilen, da diese von allen Benutzern geerbt werden würden.

Jeder SQL Server-Login gehört zur öffentlichen Rolle und kann nicht aus dieser Rolle entfernt werden. Daher stehen alle Berechtigungen, die dieser Rolle erteilt wurden, allen Logins zur Verfügung, es sei denn, sie wurden explizit für bestimmte Logins oder benutzerdefinierte Serverrollen verweigert.

Wenn überflüssige Berechtigungen von der öffentlichen Serverrolle widerrufen werden, kann der Zugriff verloren gehen, es sei denn, die Berechtigungen werden explizit für bestimmte Logins oder benutzerdefinierte Serverrollen erteilt, die den Zugriff benötigen.

Verwenden Sie die folgende Syntax, um festzustellen, ob zusätzliche Berechtigungen für die öffentliche Serverrolle erteilt wurden.

-- T-SQL-Abfrage zur Überprüfung von Berechtigungen für die öffentliche Serverrolle
SELECT * 
FROM master.sys.server_permissions
WHERE (grantee_principal_id = SUSER_SID(N'public') and state_desc LIKE 'GRANT%')
AND NOT (state_desc = 'GRANT' and [permission_name] = 'VIEW ANY DATABASE' and class_desc = 'SERVER')
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and class_desc = 'ENDPOINT' and major_id = 2)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and class_desc = 'ENDPOINT' and major_id = 3)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and class_desc = 'ENDPOINT' and major_id = 4)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and class_desc = 'ENDPOINT' and major_id = 5);

Diese Abfrage sollte keine Zeilen zurückgeben, was darauf hinweist, dass keine zusätzlichen Berechtigungen für die öffentliche Serverrolle erteilt wurden.

Um dieses Sicherheitsrisiko zu beheben, sollten Sie die überflüssigen Berechtigungen, die in den Audit-Ergebnissen gefunden wurden, den spezifischen Logins oder benutzerdefinierten Serverrollen hinzufügen, die den Zugriff benötigen. Widerrufen Sie dann die entsprechende Berechtigung von der öffentlichen Rolle.

-- T-SQL-Abfrage zum Widerrufen der Berechtigung von der öffentlichen Rolle
USE [master];
REVOKE <permission_name> FROM public;

Standardmäßig wird der öffentlichen Serverrolle die Berechtigung VIEW ANY DATABASE und die CONNECT-Berechtigung für die Standardendpunkte (TSQL Local Machine, TSQL Named Pipes, TSQL Default TCP, TSQL Default VIA) erteilt. Die VIEW ANY DATABASE-Berechtigung ermöglicht es allen Logins, Metadaten von Datenbanken zu sehen, sofern dies nicht explizit verweigert wird.

Administratorrechte der SQL Server-Servicekonten im Fokus

Es ist wichtig sicherzustellen, dass die SQL Server-Servicekonten nicht als Administrator agieren. Dies muss manuell überprüft werden. Bitte überprüfen Sie die Benutzerrechte der SQL Server-Servicekonten und stellen Sie sicher, dass keine Administratorrechte zugewiesen sind.

Bestätigung der SQL Server-Härtungsmaßnahmen: Ein Überblick

Nachdem Sie die oben genannten Maßnahmen implementiert haben, ist es entscheidend, die Wirksamkeit der Härtungsmaßnahmen zu überprüfen. Hier sind einige Schritte, die Sie durchführen können:

• Führen Sie regelmäßige Audits durch, um sicherzustellen, dass „Orphaned Users“ behoben sind und keine unberechtigten Zugriffe vorliegen.
• Überwachen Sie SQL Agent Proxies, um sicherzustellen, dass nur autorisierte Benutzer darauf zugreifen können.
• Prüfen Sie regelmäßig, ob SQL Authentication in enthaltenen Datenbanken vermieden wird.
• Überprüfen Sie, ob die öffentliche Serverrolle nur die von Microsoft vorgesehenen Standardberechtigungen hat.
• Manuell überprüfen Sie die Administratorrechte der SQL Server-Servicekonten.

Fortlaufende Sicherheit: Best Practices für SQL Server

Um die Sicherheit Ihrer SQL Server-Instanz aufrechtzuerhalten, sollten Sie einige bewährte Praktiken beachten:

• Halten Sie Ihre SQL Server-Instanz und alle Datenbanken auf dem neuesten Stand, indem Sie regelmäßig Sicherheitspatches und Updates einspielen.
• Implementieren Sie starke Passwörter für alle Benutzer und Servicekonten.
• Sichern Sie regelmäßig Ihre Datenbanken und führen Sie Wiederherstellungstests durch.
• Aktivieren Sie die Überwachung und Benachrichtigungen für verdächtige Aktivitäten.

Indem Sie diese bewährten Praktiken befolgen und die erforderlichen Härtungsmaßnahmen implementieren, tragen Sie dazu bei, die Sicherheit Ihrer SQL Server-Umgebung zu erhöhen und potenzielle Sicherheitslücken zu minimieren.

Bleiben Sie dran für den nächsten Teil unserer SQL Server-Härtungsreihe, in dem wir uns auf die Härtung auf der Datenbankebene konzentrieren und Ihnen praktische Tipps zur Optimierung Ihrer Datenbanksicherheit geben werden.

Björn Peters

Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.