Die Sicherheit ihres Datenbankensystems sollte immer höchste Priorität haben. Denn dieses System ist das Herz Ihres Unternehmens und sollte deshalb vor ungewollten Eingriffen geschützt sein. Darum zählt zu einer guten Planung eines solchen Systems ebenfalls ein gutes Sicherheitskonzept. Darin sollten Lösungen enthalten sein, welche Maßnahmen ergreifen, wenn beispielsweise das Eindringen einer fremden Instanz erkannt wird. Es ist aber wichtig hinzuzufügen, dass es nicht die eine initiale Lösung für Sicherheit gibt. Jedes System sollte an seine eigenen Anforderungen und Sicherheitsbedürfnisse angepasst werden. Das übergeordnete Ziel sollte sein, das Sicherheitskonzept so aufzuziehen, dass es einer Ummauerung der Daten gleicht, die Gefahren jeglicher Art aussperrt.
Viele Nutzer vertrauen aus diesem Grund auf Microsoft SQL Server. Hier sind bereits sehr nützliche Tools und Funktionen zum Schutze Ihrer Datenbanken enthalten. Im weiteren Artikel gehen wir darauf ein, wie das Vorgehen eines Eindringlings aussieht und welche Maßnahmen an welcher Stelle getroffenen werden können, um dies zu verhindern oder zu erschweren.
Wie sehen Angriffe aus?
Als erstes muss der Angreifer einen Weg in Ihr Netzwerk finden. Hierfür gibt es mehrere Ansätze, die verfolgt werden können. Der Erste wäre, sich bereits bekannte Sicherheitslücken in alter Software oder Firewalls zu Nutze zu machen. Deswegen sollte darauf geachtet werden, dass verwendete Software und Firewalls auf dem aktuellen Stand sind. Das Internet verändert sich ständig und es werden immer wieder neue Lücken entdeckt. Darum wird es hier immer wieder Updates geben, um diese Lücken zu füllen. Aber wie es häufig der Fall ist, ist ein menschlicher Fehler meistens Grund für das Eindringen eines Angreifers. Bekannte Beispiele sind:
- Phishing Mails
Hier versucht der Angreifer einen Zugriff über infizierte Mails zu erhalten. - Schwache Passwörter
Ein einfaches Passwort kann schnell geknackt werden. Somit hätte ein Angreifer einen einfachen Weg ins System - Geklonte Schein-WLAN-Zugangspunkte
Sobald sich hier angemeldet wird, kann ein Angreifer Informationen abfangen. Darum sollte immer sicher gestellt sein, in einem bekannten Netzwerk zu sein. - Social Engineering
Wahrscheinlich die trickreichste Art und Weise an Informationen zu gelangen. Hier wir versucht, in Gesprächen mehr über den Aufbau des Systems zu erhalten, um damit vermeintliche Schwachstellen ausnutzen zu können
Damit diese Ansätze für einen Angreifer keine Option darstellen, sollten Mitarbeiter auf genau diese Bedrohungen geschult werden. Denn wenn man weiß, worauf man achten muss, werden diese Fehler weniger verursacht.
Scouting
Aber wir wollen im Weiteren davon ausgehen, dass ein Angreifer sich Zugriff zu dem Netzwerk verschafft hat. Sein nächster Schritt wird sein, mögliche Beute zu identifizieren und einen Überblick zu verschaffen, welche Geräte im Netzwerk sind. Da wir uns auf Datenbanken spezialisieren wollen, besitzt unser System eine Datenbank, auf die es der Angreifer abgesehen hat. Darum wird der erste Schritt in einem neuen Netzwerk sein, einen Portscan durchzuführen. Damit soll herausgefunden werden, wo sich die Datenbank befindet und wie der Server heißt.
Wie kann man das verhindern?
Eine mögliche Option ist die Veränderung des Standard-Ports auf einen beliebig anderen. Zu dieser Thematik gibt es viele Diskussionen. Die beiden Seiten, die sich hier gebildet haben, befinden sich aber eher in einem kleinen Glaubenskrieg. Das eine Lager, ist der Meinung, man verkompliziert nur die Umgebung - denn für jede SQL Instanz muss sich ein anderer Port gemerkt werden. Dagegen behauptet das andere Lager, dass es hierfür Tools gibt, die das vereinfachen können. Wobei auch hier die Sicherheit der Tools wieder in Frage gestellt werden sollte.
Das nächste Argument ist, dass mit einem Portscan auch der zufällig gewählte Port herausgefunden werden kann. Häufig werden Skripte aus dem Internet verwendet, um einen Portscan durchzuführen. Diese Skripte suchen in erster Linie nach dem Standard-Port. Das bedeutet, dass man sich gegen die meisten Angriffe mit solchen Skripten durch das Ändern des Standard-Ports schützen kann.
Ist der Angreifer jedoch hartnäckig und von der erfahrenen Sorte, wird dies für ihn keine große Hürde darstellen.
Abschließend lässt sich sagen, es ist eine kleine und vor allem einfache Änderung, die vor Angriffen aus der breiten Masse schützt und dabei vielleicht auch hartnäckige Angriffe zumindest verlangsamt.
Connecting
Hat der Angreifer trotzdem einen Weg gefunden, den Namen und die IP des Hosts herauszufinden, wäre der nächste Schritt eine erfolgreiche Verbindung mit dem Server herzustellen. Eine große Schwachstelle stellt hier die SQL Authentifikation dar. Denn in Sachen Sicherheit, kommt diese nicht an die von Microsoft heran. Wir empfehlen daher dringend, jeglichen Zugriff nur über die Microsoft Authentifikation laufen und überprüfen zu lassen. Ergänzend dazu sollten Sie sich eine eigene starke Passwortpolicy einrichten und durchführen. Darüberhinaus ist auch eine weitere mögliche Angriffsfläche nicht außer Acht zu lassen. Die Rede ist von der SQL Injection. Es ist möglich, über Eingaben in die Datenbank auch Code einzuspeisen. Wenn dieser ausgeführt wird, kann er Daten verändern oder zerstören und es gibt die Möglichkeit, sensitive Daten auszugeben. Darum sollte unbedingt jede Eingabe kontrolliert und validiert werden, damit es dazu nicht kommt.
Accessing
Gehen wir nun davon aus, dass es dem Angreifer dennoch gelungen ist, sich erfolgreich auf dem Server einzuloggen. Sein nächstes Ziel wird voraussichtlich sein, sich ausreichend Rechte zu verschaffen. Als erstes wird hierbei nach einer TRUSTWORTHY Datenbank geschaut, deren Besitzer die Rolle sysadmin hat. Damit können stored procedures erstellt werden, die als owner, also als sysadmin, ausgeführt werden. Somit kann man sich über die Prozedur selbst die Rolle des sysadmin zuweisen. Das kann verhindert werden, indem erst keine Datenbank als TRUSTWORTHY markiert wird. Will man trotzdem Zugriff auf externe Daten haben empfiehlt es sich, dies über Zertifikate zu machen. Hat der Angreifer Glück, hat er einen Login erwischt, der die Rolle securityadmin hat. Die Rolle securityadmin ist dafür gedacht, bestehende Logins zu verwalten. Das kann dann ausgenutzt werden, indem neue Logins mit hohen Rechten vergeben werden. In erster Linie lässt sich das nicht verhindern. Darum sollte man sehr vorsichtig mit der Verteilung einer Rolle sein.
Die Rollenverteilung ist auch für den späteren Fall wichtig, wenn der Angreifer sich einen Login mit vielen Rechten erstellt hat. Es sollte auf jeden Fall mit dem “Principle of Least Privilege” gearbeitet werden. Das bedeutet, jeder User erhält nur so viele Rechte, dass er:sie gerade noch seine:ihre Arbeit erledigen kann. Als Beispiel: Jemand aus Human Ressources braucht keinen Zugriff auf Daten der Produktion, wenn man sich das Beispiel einer AdventureWorks Datenbank anschaut. Es bietet sich an der Stelle natürlich an, eigene Rollen zu erstellen, damit die Verteilung der Rechte vereinfacht wird. Man muss jedoch beachten, dass es bei zu vielen Rollen schnell zu Chaos kommen kann. Wenn man die Übersicht verliert kann es passieren, dass ein User über mehrere Rollen verfügt und Zugriffe hat, die er erst gar nicht haben sollte. Darum sollte dringend auf eine übersichtliche und unkomplizierte Rollenverteilung geachtet werden. Denn auch das macht es schwerer für einen Angreifer, wenn er sich für jeden Bereich einen neuen Login besorgen muss.
Looting/Destroying
Hat sich ein Angreifer nun einen Login mit ausreichend Rechten verschafft, macht er sich an die Umsetzung seiner eigentlichen Ziele. Das kann zum einen der Diebstahl oder die Zerstörung von Daten, aber auch ein Angriff auf das Netzwerk sein. Backups können gelöscht oder Datenbanken verschlüsselt werden, sodass nur noch der Angreifer Zugriff auf diese hat und sich gegebenenfalls eine “Hintertür” einbauen kann. Das sind nur wenige Beispiele, die ein Angreifer in einem Netzwerk anstellen kann. Es stellt sich natürlich die Frage, wie man das zu diesem Zeitpunkt verhindern kann.
Die Antwort ist, mit den richtigen vorbereitenden Maßnahmen. Sobald es einem Angreifer gelungen ist, so weit in das System vorzudringen, steht ihm nicht mehr viel im Weg. Es bleibt nur noch übrig, vorher regelmäßig gründliche Backups zu machen und sicherzustellen, dass ein Restore auch richtig funktioniert. Zudem sollten verdächtige Aktivitäten überwacht werden, um entsprechende Maßnahmen ergreifen zu können. So wird verhindert, dass ein Angreifer zu viel Zeit in dem System verbringen kann.
Built-In Sicherheit von Microsoft
Während wir einen Blick auf den Ablauf eines möglichen Angriffs geworfen haben, sind wir bereits auf ein paar Maßnahmen eingegangen, wie Sie Ihr System schützen können. Wir schauen uns jetzt aber ein wenig genauer an, welche Tools von Microsoft bereitgestellt werden. Unterscheiden wollen wir das in Zugriffsbeschränkungen, Verschlüsselung und Audit.
Zugriffsbeschränkungen
Wie bereits häufig angesprochen, sollte nicht jeder Nutzer auf alle Daten Zugriff haben. Das ist aus Sicht der Datensicherheit ein Thema, als auch gegen einen potenziellen Angreifer. Aus diesem Grund bietet Microsoft mehrere Möglichkeiten an, den Zugriff und die Sichtbarkeit der Daten zu beschränken.
Verteilung von Rollen
Dies stellt wahrscheinlich die erste Lösung dar, an die man denkt und ist dabei ein essenzieller Teil für ein sicheres System. Wie bereits bekannt, kann man verschiedenen Logins oder Usern unterschiedliche Rollen zuweisen. Hierbei wird zwischen Server- und Datenbankebene unterschieden und geht sogar auf Tabellenebene. Jede Rolle hat auf ihrer Ebene unterschiedlich Rechte.
Data Masking
Neben einem eingeschränkten Zugriff, können Daten ebenfalls maskiert werden. Hier unterscheidet man zwischen statischem und dynamischen Maskieren. Beim statischen Maskieren werden echte Daten durch realistische, aber gefälschte Daten ersetzt. Damit können Datenbanken ohne Probleme für Testumgebungen oder andere Zwecke kopiert werden. Das dynamische Maskieren hat dagegen wieder ein Rollensystem. Dabei werden die Daten nur für bestimmte Nutzer oder Rollen maskiert, bzw. sichtbar gelassen.
Row-level Security & Column-level Security
Eine weitere Möglichkeit, den Zugriff auf Daten zu beschränken, bietet die RLS und CLS. Hierbei kann an einer Tabelle eingestellt werden, ob ein User alle Daten sieht, oder nur entweder bestimmte Reihen oder bestimmte Spalten. Ein User kann z.B. damit nur die Daten sehen, die er selbst eingetragen hat.
Verschlüsselung
Ein weiterer wichtiger Teil ist die Verschlüsselung. Microsoft bietet hier verschiedene Lösungen an, die sowohl Daten als auch die Kommunikation zwischen Datenbank und User verschlüsseln. Wir wollen einige Funktionen aufzählen, ohne dabei zu sehr ins Detail zu gehen.
- SSL und TLS
Der Transfer von Daten läuft über das Tabular Data Stream Protokoll (TDS). Dieses ist standardmäßig unverschlüsselt. Jedoch können Admins eine Verschlüsselung mit SSL und TSL ermöglichen. - Windows Data Protection API (DPAPI)
Ein Feature, das auf Windows 2000 eingeführt wurde. Hiermit können Schlüssel, Logins und weitere Objekte verschlüsselt und gesichert werden. Der verwendete Algorithmus ist dabei abhängig von der Windows Version, auf der das System läuft. - SQL Server Service Key
Dieser Schlüssel wird bei dem ersten Starten von SQL Server erzeugt. Er wird dazu benutzt die Daten in SQL Server zu verschlüsseln. Zudem wird er von der DPAPI beschützt. - Master Key
Ein weiterer optionaler Key, mit dem Datenbanken gesichert werden können. Der Master Key kann entweder über den Service Key oder über ein Passwort gesichert sein. Ein Reset des Service Key, hat auch einen Reset des Master Key zufolge. - Transparent Data Encryption (TDE)
Hier werden Datenbanken transparent verschlüsselt. Das heißt, autorisierte Benutzer sehen die Daten unverschlüsselt, wobei sie im System verschlüsselt gespeichert sind. Dabei kann aus verschiedenen Verschlüsselungsalgorithmen gewählt werden.
Audit
Mit SQL Server Audit gibt uns Microsoft ein Tool, um Vorgänge innerhalb der Datenbank zu überwachen. Dabei werden die Transaction Logs ausgewertet, um Informationen zu Änderungen von Daten und Objekten der Datenbank zu erhalten. Darüber hinaus können weitere Events definiert werden. Diese können entweder auf Server- oder auf Datenbankebene laufen. Diese Events sammeln Informationen zu angegebenen Aktionen. All diese Informationen werden in einem angegebenen Pfad gespeichert. Wenn es bei einem Event zu einem auffälligem Ereignis kommt, kann ebenfalls eine Maßnahme angegeben werden, die ergriffen werden soll.
Best Practices
Nachdem wir nun wissen, welche Mittel zur Sicherheit uns Microsoft an die Hand gibt, wollen wir uns konkret anschauen, wie einige Best Practices aussehen.
Verhärten der Umgebung
Das bezieht sich nicht direkt auf SQL Server, ist aber dennoch sehr wichtig. Um ein System sicher zu machen, wollen wir so wenig Angriffsfläche bieten wie möglich. Dazu zählt auch die Maschine, sei es eine VM oder ein tatsächlicher physischer Server, auf der unsere Datenbank läuft. Denn diese Maschine ist das Fundament unserer Datenbank. Ist das Fundament instabil, bricht alles darüber zusammen. Wenn die Umgebung nicht sicher ist, könnten Angreifer unter Umständen einfach die Datenbank kopieren und auf einem eigenen Server mit brute-force ganz in Ruhe knacken. Darum sollte darauf geachtet werden, dass die Maschine ein eigenes Sicherheitskonzept besitzt. Dabei lassen sich Punkte, die wir noch ansprechen werden, einfach übertragen.
Regelmäßige Updates
Das ist eine Maßnahme, die sich auch auf alle anderen Systeme übertragen lässt. Wir hatten bereits im ersten Abschnitt über Updates gesprochen. Es werden immer wieder neue Sicherheitslücken in Software entdeckt. Darum werden regelmäßig Updates rausgebracht, die diese Lücken wieder schließen sollen. Deshalb sollte darauf geachtet werden, dass alle Updates ohne große Verzögerung installiert werden.
Starke Passwörter
Ebenfalls ein Punkt, der im Allgemeinen sehr wichtig ist. Kurze und einfache Passwörter ohne Zahlen und Sonderzeichen oder häufige Buchstabenketten lassen sich recht schnell knacken. Aus diesem Grund sind starke Passwörter essenziell für ein gutes Sicherheitskonzept. Man kann eine Festung so gut schützen wie man will. Es bringt alles nicht, wenn man den Schlüssel zu Haustür unter der Fußmatte versteckt. Noch besser wäre eine Zwei-Faktor Authentifizierung. Aber der zusätzliche Aufwand sollte gegen den gewonnen Nutzen abgewogen werden.
Nur benötigte Komponenten installieren
Hier trifft wieder das Prinzip der kleinen Angriffsfläche zu. Wenn es alte Software oder Komponenten gibt, die nicht mehr gebraucht werden, sollte das vom System entfernt werden. Wenn sich darum nicht mehr gekümmert wird, kann das eine Sicherheitslücke darstellen. Genauso sollte nicht unnötig weitere Dinge installiert werden, die nicht genutzt werden.
Lange Liste der Best Practices
- Limit the Permissions of Service Accounts
Jeder Service Account sollte nur so viele Rechte erhalten, wie er zum ausführen seiner Rolle benötigt. Accounts die beschränkt werden sollten sind: Active Directory managed service account, domain user account, local user account, local system account, netweork service account, virtual service account - Disable the SQL Server Browser Service
über diesen kann ein Angreifer leicht Informationen über verfügbare Ressourcen erhalten - Use Groups and Roles to Simplify Management of Effective Permissions
Role-Based Access Control - Follow the Principle of Least Privilege When Assgning SQL Server Roles
neun default SQL Server Rollen. Beim Zuweisen dieser Rollen sollte wie weiter oben schon mit dem Prinzip des geringsten Privilegs gehandelt werden. Es können custom Rollen über TSQL angelegt werden - Use Windows Authentication Mode
ist meist die sicherste Variante, da hier die Actice Directory Policies ausgeübt werden können - Configure Password Options for Logins
MUST_CHANGE(nach erstem Login neues Passwort vergeben),CHECK_POLICY(überprüft die Passwort Policies des Computers),CHECK_EXPIRATION(User muss nach einer Weile das Passwort resetten) - Purge any Unused Logins
selbsterklärend; weniger Möglichkeiten sich in das System einzuklinken - Use a Robust Database Backup Strategy
für große Datenbanken eine file und filegroup Strategie; es werden immer nur spezielle Daten gesichert - Monitor Activity on Your SQL Server
kann einen Alert senden, wenn zu viele nicht normale Aktionen passieren - Protect against SQL Injection Attacks
alle Queries sollten nach fremden Code gecheckt werden und z.B. nur vordefinierte commands benutzen dürfen - User Encryption Whenever Possible
transparent data encryption (TDE), column level encryption, alwas encrypted
Fazit
In diesem Artikel sind wir umfassend auf mögliche Sicherheitslücken in der täglichen Arbeit mit Datenbanken eingegangen. Dabei haben wir Ihnen Hilfestellungen zum Schutz vor möglichen Angreifern an die Hand gegeben. Wenn Sie mehr darüber erfahren möchten oder ganz speziell auf ihre Umgebung in Sachen Sicherheit Fragen haben, kontaktieren Sie gerne unsere Expert:innen über unser Kontaktformular und lassen sich umfassend beraten.
Wir freuen uns von Ihnen zu hören!
