SQL Server: Sicherheit von Anfang an im Blick

Der Designprozess ist der beste Ort, um festzulegen, was abgesichert werden muss und wie. Dabei sollte man vor allem zwei Kriterien im Blick haben:

• Vertrauliche Daten
• Wer hat Einblick in vertrauliche Daten?

Vertrauliche Daten können alle möglichen Daten sein, sogar der gesamte Datenbestand. Es gibt einige Datenbanken, die so vertraulich sind, dass der Zugriff auf alle Daten beschränkt ist, aber diese Sicherheitsstufe dürfte nicht so häufig vorkommen. Die Aufgabe besteht darin, diejenigen Daten zu schützen, die innerhalb des Kontextes eines Unternehmens und der Datenbank als vertraulich definiert wurden.

Der gewählte Authentifizierungsmodus und die erstellten Benutzerkonten sorgen für die erste Sicherheitsstufe, indem die Zahl der Benutzer, die Zugriff auf die Datenbank haben, begrenzt wird. Manchmal reicht dies als Sicherheitsmaßnahme bereits aus.

Der nächste Schritt besteht darin, alle Benutzer aufzulisten, die Zugriff zu der Datenbank erhalten sollen, und dann zu entscheiden, ob alle Benutzer auch wirklich auf alle Daten zugreifen müssen. Oft gibt es Daten, wie z.B. Gehälter oder andere persönliche Daten, die man schützen möchte. Man muss außerdem entscheiden, wer Daten ändern darf, was u.U. zu zwei völlig unterschiedlichen Benutzergruppen führt.

Eine der wichtigsten Regeln, die man dabei im Hinterkopf behalten sollte, ist das Prinzip des „Least Privilege“: Falls jemand bestimmte Daten nicht zur Erledigung seiner Aufgaben benötigt, sollte er auf diese auch nicht zugreifen dürfen. Man sollte der Versuchung widerstehen, allen Benutzern dieselben Rechte wie dem System-Administrator sa einzuräumen, nur weil dies einem die Arbeit als Entwickler leichter macht. Benutzer sollten Daten nur in dem Umfang sehen und ändern können, wie es die Geschäftsabläufe erfordern.

Konkrete Tipps
Erfahrung ist der beste Lehrmeister, wenn es um Sicherheit geht, aber es gibt einige Richtlinien, die sich auf fast jede Datenbank anwenden lassen:

• Von Anfang an die Eigentümerschaft von Datenbanken und Objekten sichern. Wenn man eine neue Datenbank erstellt, wird man zum Besitzer der Datenbank und kann alles bestimmen, was mit dieser Datenbank passiert. Idealerweise sollte man für diese Aufgabe ein Benutzerkonto verwenden, dass ausschließlich administrativen Zwecken dient, keines für den täglichen Gebrauch. Auf ähnliche Weise sind Objekte im Besitz desjenigen Benutzers, der sie erstellt hat. Es ist zwar möglich, die Eigentümerschaft zu übertragen, jedoch einfacher sicherzustellen, dass zur Erzeugung aller Objekte ein spezielles Administrator-Konto verwendet wird.
• Verstehen, wie Besitzerketten funktionieren. Diese Sicherheitsfunktion verhindert, dass Benutzer eigene Views erstellen, um sich so Zugang zu vertraulichen Daten zu verschaffen, deren Besitzer sie nicht sind. Ein Beispiel: Man erstellt einen View, der Daten aus zwei Tabellen zusammenfasst. Ist man Besitzer beider Tabellen, wird SQL Server nicht die Zugriffsrechte für die Tabellen überprüfen, wenn man jemand anderem die Verwendung des Views erlaubt. Befindet sich jedoch eine der Tabellen im Besitz eines anderen Entwicklers, wird SQL Server zusätzlich zur Berechtigung für den View auch die der Tabelle überprüfen.
• Man sollte Views und gespeicherte Abfragen verwenden, um Benutzern Zugriff auf Daten zu gewähren, anstatt sie zu zwingen, jedes Mal ihre eigenen Abfragen zu schreiben, mit denen sie direkt auf Tabellen zugreifen. Auf diese Weise braucht man Benutzern keine Zugriffsrechte auf die zugrunde liegenden Tabellen einzuräumen. Views und gespeicherte Abfragen können außerdem die Menge der Daten begrenzen, die die Benutzer betrachten können. Falls z.B. die Tabelle mit den Mitarbeiterdaten vertrauliche Gehaltsinformationen enthält, kann man einen View erstellen, der diese Spalte einfach auslässt.
• Falls Benutzer von bestimmten Anwendungen aus auf die Datenbank zugreifen, kann man auch Anwendungsrollen erstellen. Eine Anwendungsrolle ist so etwas wie ein Benutzer, der einer bestimmten Anwendung zugeordnet ist. Sie kann ihre eigenen Berechtigungen erhalten. Bei Anwendungsrollen authentifizieren sich Benutzer nicht direkt gegenüber der Datenbank, sondern gegenüber ihrer eigenen Anwendung, die dann entscheidet, welche Anwendungsrolle sie dem Server präsentiert.
• Immer aktuelle Service Packs einspielen. Zugegebenermaßen sind Service Packs eine zweischneidige Sache. Service Releases, Patches und sonstige Updates führen oft zu neuen Problemen. Trotzdem ist es wahrscheinlich die beste und einfachste Möglichkeit, seine Daten vor unberechtigtem Zugriff zu schützen, wenn man mit Service Packs immer auf dem Laufenden ist. Das aktuellste Service Pack findet man auf der Download-Seite von Microsoft für SQL Service Packs.

Fazit
Sicherheit geht jeden Entwickler etwas an. Man sollte damit nicht warten, bis die Datenbank fertiggestellt und in Benutzung ist. Vielmehr gehört Sicherheit als integraler Bestandteil zum Designprozess. Man sollte aber nicht einfach willkürlich einzelne Sicherheitsmaßnahmen ergreifen und hoffen, dass alles gut geht. Besser ist es, sich mit den unterschiedlichen Sicherheitsmodellen vertraut zu machen und sie entsprechend anzuwenden.