Sicherheit für SQL Server: Fragen der Benutzeridentifikation

In diesem Artikel über Sicherheit von Microsoft SQL Server geht es darum, die nötigen Tools und Kenntnisse für ein sicheres Setup zu vermitteln und um wertvolle Daten vor Diebstahl und Schaden zu schützen. Es werden einige der grundlegenden Prinzipien erörtert, die bezüglich der Datenbankabsicherung relevant sind: Logins, Benutzer, Rollen und Gruppen. Alle diese Prinzipien sind an dem scheinbar simplen Vorgang der Zugriffsrechteverwaltung beteiligt.

Logins

Logins definieren die Benutzer, die Zugang zu einer SQL Server-Installation haben, also nicht auf eine bestimmte Datenbank, sondern auf den Server als ganzes.

Es gibt zwei Arten von Logins:

• Windows-integrierte Logins berechtigen bestimmte Windows-Benutzer oder -gruppen zum Zugriff unter Verwendung ihrer Windows-Kenndaten.
• SQL Server-Logins berechtigen dagegen einen Benutzer zum Zugriff unter Nutzung des von SQL Server gespeicherten Benutzernamens und Passworts.

Welcher Login wird verwendet?

Windows-integrierte Logins sind natürlich effizienter und praktischer als die SQL Server-Logins, da sich die Benutzer nur einmal auf Netzwerkebene anmelden. Separate Logins für den Server sind unnötig, da SQL Server (im Verborgenen) automatisch den Windows-Login verarbeitet, um den Zugriff zum Server zu gewähren. Diese Funktion steht nur bei Windows NT oder 2000 basierten Servern zur Verfügung. Auf Windows 98 gehostete Server müssen dagegen die SQL Server-Logins verwenden. Wenn man Windows 2000 verwendet und eine ältere Anwendung unterstützen möchte, sollte man daran denken, dass SQL Server-Logins nur im Mixed Mode verfügbar sind.

Design-Aspekte

Im Allgemeinen wird im Zuge des Designs einer Datenbank auch die Login-Methode festgelegt, d.h. lange bevor man mit der Einrichtung beginnt. Dazu muss man wissen, welche Autorisierungsverfahren der Server unterstützt. Wer mit Windows 98-Servern arbeitet, sollte aus Sicherheitsgründen an dieser Stelle vielleicht ein Upgrade in Erwägung ziehen, da nur so die integrierten Sicherheitsfunktionen von Windows NT oder 2000 genutzt werden können.

Eine weiterere Notwendigkeit beim Design besteht darin, festzulegen wer auf welche Daten Zugriff hat und ob Änderungen an Objekten und Daten vorgenommen werden dürfen. Dazu ist nicht unbedingt eine Liste aller einzurichtenden Nutzer erforderlich, es müssen lediglich verschiedene Benutzergruppen mit unterschiedlichen Rechten berücksichtigt werden. Hierzu dient die Verwaltung der Sicherheit mithilfe gespeicherter Systemprozeduren.

SQL Server bietet zwei gespeicherte Prozeduren zur Verwaltung von Logins:

• sp_addlogin – Diese gespeicherte Prozedur wird bei Verwendung von SQL Server Authentication zur Sicherung des Servers genutzt. Sie erstellt einen neuen SQL Server-Login, über den Benutzer mithilfe von SQL Server Authentication auf eine Instanz von SQL Server zugreifen können.
• sp_grantlogin – Diese gespeicherte Prozedur ermöglicht es Benutzer- oder Gruppenkonten unter Windows 2000, mithilfe von SQL Server Authentication auf Microsoft SQL Server zuzugreifen.

Nur Mitglieder der fest definierten Server-Rollen sysadmin oder securityadmin können diese gespeicherten Prozeduren ausführen.

Benutzer

Während die Logins zum Server gehören, sind die Benutzer Teil der Datenbank. Eine Benutzer-ID identifiziert den Benutzer einer Datenbank. Außerdem sind die Benutzer speziell für die jeweilige Datenbank definiert – der Benutzer Fred in der Datenbank A ist also nicht derselbe wie der Benutzer Fred der Datenbank B, obwohl beide Freds eventuell dem gleichen Login zugeordnet sind.

Beim Anlegen eines Benutzers in einer Datenbank wird diesem ein bestimmter Login zugewiesen. Für diese Datenbank besitzt der Login dann die Zugriffsrechte des jeweiligen Benutzers. Die Login-IDs müssen nicht zwangsläufig mit den Benutzer-IDs übereinstimmen, auch wenn dies der Einfachheit halber meist so gehandhabt wird. Wenn einem Login in einer Datenbank kein Benutzer zugewiesen wurde, können die Benutzer über ein Gastkonto auf die Datenbank zugreifen.

Spezielle Benutzer

Nicht alle Benutzer werden für eine Datenbank fest definiert oder rechtfertigen den Aufwand für ein eigenes Konto. Wenn also einem Benutzer nur ein zeitweiliger Zugriff auf eine Datenbank eingeräumt werden soll, kann man das Konto für Gastbenutzer verwenden, über das auch ohne ein speziell eingerichtetes Benutzerkonto der Zugang zur Datenbank möglich ist. Der Login des Gastbenutzers muss Zugriff auf den Server haben und die Datenbank muss über ein Konto für Gastbenutzer verfügen. Innerhalb der Datenbank kann der Gastbenutzer nur die für das Gastkonto zugelassenen Aktivitäten ausführen. Ein solches Konto für Gastbenutzer ist in einer neu erstellten Datenbank allerdings nicht bereits standardmäßig vorhanden, es muss erst vom Datenbankeigentümer oder Systemadministrator eingerichtet werden.

Neben den Gastbenutzern gibt es noch den Datenbankeigentümer (DBO). Dies ist der Benutzer, der die Datenbank erstellt. Der Datenbankeigentümer oder Systemadministrator muss die Schaffung weiterer Objekte in der Datenbank genehmigen.

Um einen Benutzer zu einer Datenbank hinzuzufügen, muss sp_grantdbaccess ausgeführt werden. Diese gespeicherte Prozedur erstellt einen Benutzer in der dem jeweils angegebenen Login entsprechenden Datenbank. Nur Mitglieder der fest definierten Systemadministrator-Server-Rolle (db_accessadmin) und der fest definierten Datenbank-Rolle (db_owner) können sp_grantdbaccess ausführen.