DBA ist der Hüter der Daten, und es gibt zwei Aspekte, ein Hüter zu sein. Der erste ist Integrität. Es umfasst Aufgaben wie das Überprüfen der Datenbankkonsistenz, das Erstellen von Sicherungen und, falls Probleme auftreten, einen gut durchdachten, umfassenden Datenbankwiederherstellungsplan.
Der zweite Aspekt ist die Sicherheit. Es wird empfohlen sicherzustellen, dass nur autorisierte Benutzer Zugriff auf die Daten haben und nur auf die Daten, die sie benötigen.
Im Internet finden Sie zahlreiche Ressourcen zum Thema Sicherheit. Allerdings denke ich, dass einigen wichtigen Dingen die angemessene Aufmerksamkeit fehlt. In diesem Artikel möchte ich auf diese Optionen eingehen und aufzeigen, warum es wichtig ist, sie zu kennen und richtig damit umzugehen.
Eine Mission zur Kompromittierung eines SQL-Servers
Lassen Sie uns ein Rollenspiel haben, in dem Sie ein Geheimagent sind und Ihre Mission, falls Sie sie annehmen, darin besteht, sehr wichtige Daten aus der TargetDB zu stehlen Datenbank, die von einem SQL Server gehostet wird. Sie müssen diese Daten abrufen und löschen.
Es ist möglich, ein Login für Sie zu erhalten, aber jedes Login auf dem Server hat explizite DENIED-Berechtigungen für die Zieldatenbank und -daten. Die einzigen Informationen, die unser Agent Ihnen zur Verfügung stellen kann, sind diejenigen, die zur Überprüfung durch das Sicherheitsprotokoll während der Erstellung Ihres Logins generiert wurden.
Datenbankinformationen vom Zielserver.
Serverberechtigungen:
Datenbankberechtigungen:
Lassen Sie uns wie jeder anständige Agent die Hausaufgaben machen und prüfen, womit Sie es zu tun haben.
Sie können sich nicht einfach anmelden und eine Verbindung zu TargetDB herstellen , da jede einzelne Berechtigung für Ihre Anmeldung und den zugeordneten Benutzer explizit verweigert wird. Sie müssen von einer anderen Datenbank aus zugreifen.
Eine verschlossene Tür
Datenbankübergreifende Aktionen sind nicht einfach. Betrachten Sie es als eine geschlossene Tür mit zwei Schlössern. Wir werden uns hier nicht auf die technischen Details konzentrieren, aber Sie können sich auf den MSDN-Artikel Extending Database Impersonation by Using EXECUTE AS beziehen (ich empfehle dies sehr).
Die erste Sperre ist dem Authentifikator vertrauen , und die zweite ist Der Datenbank vertrauen .
Beginnen wir mit dem ersten Schloss. Dem Authentifikator zu vertrauen bedeutet, dass für den Zugriff auf eine andere Datenbank B dem Eigentümer der Datenbank A (explizit oder implizit) das AUTHENTICATE gewährt werden muss Berechtigung in Datenbank B.
Warte eine Minute! Der Authentifikator auf Datenbankebene ist der Eigentümer der Datenbank selbst (Verwechseln Sie ihn nicht mit db_owner Datenbankrolle!).
Überprüfen Sie die Datenbankbesitzer:
Obwohl sie einer ziemlich guten Praxis folgen, indem sie ein Konto pro Server verwenden, das nicht SA ist , auf diese Weise haben sie freundlicherweise das erste Schloss für Sie geöffnet.
Konzentrieren wir uns auf das zweite Schloss.
Irgendwie müssen Sie auf dem Server eine Datenbank mit TRUSTWORTHY erstellen lassen Eigenschaft EIN . Die bewährte Methode hier ist, die TRUSTWORTHY-Datenbankeigenschaft auf OFF zu setzen .
Dies ist der Zeitpunkt, an dem wir sagen sollten:Was ist, wenn Sie bereits eine solche Datenbank haben?
Es ist die MSDB-Datenbank.
Die zweite Sperre ist fertig. Sie mussten nicht einmal eine der Sperren aufbrechen.
Die Bedeutung der Rolle db_owner
Im Moment müssen Sie sich mit einer Herausforderung auseinandersetzen. Irgendwie müssen Sie mit db_owner in die MSDB-Datenbank gelangen Datenbankrolle, da sie über implizite Berechtigungen zum Imitieren verfügt.
Da MSDB normalerweise nicht im Fokus der Datenbankadministratoren steht, ist diese Mission nicht mehr unmöglich. Mal sehen, was Sie tun können, nur weil Sie einen Benutzer mit db_owner haben Datenbankrolle in der MSDB-Datenbank:
Versuchen Sie, eine Verbindung zur TargetDB herzustellen :
Dies ist ein erwarteter Fehler. Denken Sie an das Sicherheitsprotokoll, das auf das bereitgestellte Login angewendet wird. Fangen wir an.
Versuchen Sie, eine Verbindung zur TargetDB herzustellen und zur Auswahl der Zieldaten:
Es klappt! Lassen Sie uns es ändern und danach die Aktion überprüfen.
Das ist alles.
Mission erfüllt.
Wie Sie gesehen haben, habe ich mich auf eine bestimmte Sicherheitsdatenbank-Konfigurationskombination konzentriert. Das waren der Besitzer der Datenbank und die TRUSTWORTHY Datenbankoption mit besonderem Augenmerk auf MSDB. Das vorgestellte Szenario war nur eines, in dem sensible Daten auf die gleiche Weise kompromittiert werden können. Sehen wir uns jetzt ein weiteres mögliches Szenario an.
Datenbankbesitzer + VERTRAUENSWÜRDIG
Lassen Sie uns die Hintergrunddetails überprüfen, beginnend mit dem bekannten Problem:Datenbankbesitz. Welche Anmeldedaten sollte der Eigentümer Ihrer Datenbank(en) verwenden? Viele Leute sagen, dass SA ist eine geeignete Wahl.
Ich habe eine schnelle Google-Suche durchgeführt und Antworten wie die folgenden gefunden:
„Ich kann mich nicht erinnern, dass mich das jemals beunruhigt hat. Abgesehen davon, dass es in Berichten lästig aussieht oder den Benutzer nicht entfernen kann, wenn er eine Datenbank besitzt, glaube ich nicht, dass dies Auswirkungen auf den Serverbetrieb hat. Sie können einfach sa auswählen für Einheitlichkeit.“
Oder
„Ich denke nicht, dass der Besitz einer Datenbank durch SA oder einen anderen Benutzer von Bedeutung sein sollte. Entscheidend ist, wer „was“ in Ihrer Datenbank ausführt. Daher ist es eine gute Idee, Benutzer mit gültigen Berechtigungen zu erstellen. Der Einfachheit halber können Sie den Eigentümer als SA angeben.“
Die aktuelle Situation ist, dass die Verwendung des SA-Kontos als Datenbankbesitzer die SCHLECHTESTE Praxis ist . Ich persönlich denke, dass dies in jedem Blog und in jeder Dokumentation zu diesem Thema hervorgehoben werden sollte.
Wenn wir Benutzer nur mit gültigen Berechtigungen erstellen, würde das ausreichen, aber leider funktioniert das normalerweise nicht so. Sie müssen auf die „möglichst schlimmsten“ Szenarien vorbereitet sein. Überlegen Sie nur, was wir in unseren früheren Beispielen tun könnten, wenn der standardmäßige Datenbankbesitzer SA wäre !
Fahren wir mit der zweiten Option fort, der TRUSTWORTHY Datenbankoption. Die Situation ist ein bisschen besser, aber es gibt immer noch ein gemeinsames Problem. Wie allgemein angenommen, besteht die beste Vorgehensweise hier darin, die Datenbankeigenschaft „Vertrauenswürdig“ auf „Aus“ zu setzen . Wir haben gerade gesehen, warum diese Option schlecht ist .
Aber das ist nicht alles. Wenn Sie versuchen, einige Skripte zu finden, um diese Eigenschaft zu überprüfen, werden Sie wahrscheinlich ein ähnliches Skript wie dieses finden:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'Der sp_Blitz Das Skript, das den SQL Server-Zustand überprüft, überprüft auch die Standardeinstellungen der Datenbanken (einschließlich TRUSTWORTHY als Standardwert von 0) und meldet jede Datenbank, die nicht standardmäßige Einstellungen hat. Das Skript überspringt jedoch die Systemdatenbanken.
Darüber hinaus gibt es einen MS KB-Artikel, der sich diesem Thema widmet. Beachten Sie die Richtlinien zur Verwendung der TRUSTWORTHY-Datenbankeinstellungen in SQL Server:
Der Artikel enthält ein Codebeispiel, das die Datenbanken auflistet, bei denen das TRUSTWORTHY-Bit aktiviert ist und deren Datenbankbesitzer zur Serverrolle sysadmin gehören:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Was ist in diesen Skripten gemeinsam? Jedes Skript schließt die MSDB aus, aber wie der MS KB-Artikel anmerkt, haben Sie es gerade in unserer „Mission“ gesehen:
Hinweis :Standardmäßig ist die Einstellung TRUSTWORTHY für die MSDB-Datenbank auf ON gesetzt. Das Ändern dieser Einstellung gegenüber dem Standardwert kann zu unerwartetem Verhalten von SQL Server-Komponenten führen, die die MSDB-Datenbank verwenden.
Ich möchte betonen, dass das Hauptaugenmerk dieses Abschnitts weder auf der Datenbankoption TRUSTWORTHY noch auf der Eigenschaft des Datenbankbesitzers selbst liegt, sondern auf der Kombination dieser beiden Optionen. Ich habe mich hauptsächlich auf MSDB konzentriert, da die Einstellung TRUSTWORTHY für die MSDB-Datenbank standardmäßig auf ON gesetzt ist.
Schlussfolgerung
Das ist alles für jetzt. Wir haben die praktischen Szenarien, die sich auf die Sicherheit von SQL Server beziehen, durchgespielt und überprüft. Wir haben auch so wichtige Datenbankoptionen überprüft, wie den Eigentümer der Datenbank und die Datenbankeinstellung TRUSTWORTHY.
Ich wollte diese Optionen nur ins Rampenlicht rücken, da sie von entscheidender Bedeutung sind, insbesondere wenn wir über sie in Kombination sprechen.
