SQL-Server-Berechtigungen: Benutzer, Rollen und Rechte verstehen

Das SQL Server Berechtigungsmodell legt fest, wer sich mit dem Server verbinden darf und auf welche Daten und Funktionen ein Konto zugreifen kann. Dabei hilft es, Logins, Datenbankbenutzer, Rollen und Berechtigungen auseinanderzuhalten. So lassen sich Zugriffe gezielt einrichten und unnötige Rechte vermeiden.

Dieser Leitfaden erklärt die wichtigsten Begriffe und zeigt die Einrichtung anhand einer Bestell-Anwendung. Wenn Sie zuerst die Abfragesprache kennenlernen möchten, lesen Sie auch die Einführung in SQL.

Wie funktioniert das SQL Server Berechtigungsmodell?

Bei jedem Zugriff prüft SQL Server zunächst, mit welcher Identität sich jemand verbindet. Anschließend wird geprüft, ob diese Identität die gewünschte Aktion auf dem betreffenden Objekt ausführen darf. Identitäten, denen Berechtigungen erteilt werden können, heißen Principals. Datenbanken, Schemas, Tabellen und gespeicherte Prozeduren sind Beispiele für geschützte Objekte, sogenannte Securables.

Berechtigungen lassen sich auf verschiedenen Ebenen vergeben. Ein Recht auf Datenbankebene kann sich deshalb auf viele darunterliegende Objekte auswirken. Dagegen gilt ein Recht auf eine einzelne Tabelle oder Prozedur nur für dieses Objekt. Die Microsoft-Dokumentation zur Berechtigungshierarchie beschreibt diese Ebenen im Detail.

Server-Logins: Wer darf sich anmelden?

Ein Login ist eine Identität auf der SQL-Server-Instanz. Es wird bei der Anmeldung verwendet und beantwortet zunächst die Frage, ob eine Verbindung mit dem Server authentifiziert werden kann. SQL Server unterstützt unter anderem Windows- und SQL-Server-Authentifizierung.

Welche Methode passt, hängt von der Installation und der Anwendungsumgebung ab. Eine erfolgreiche Anmeldung allein gewährt jedoch noch nicht automatisch die gewünschten Rechte in einer Anwendungsdatenbank. Dafür wird das Login üblicherweise einem Datenbankbenutzer zugeordnet. Wie Sie ein SQL-Server-Login erstellen, zeigt die Dokumentation zu CREATE LOGIN.

Datenbankbenutzer: Welche Identität gilt in der Datenbank?

Der Datenbankbenutzer ist die Identität innerhalb einer bestimmten Datenbank. Bei einer klassischen SQL-Server-Anmeldung wird dieser Benutzer mit dem Login verknüpft. Dafür können Sie zum Beispiel CREATE USER ... FOR LOGIN ... verwenden.

Ein Benutzer gehört jeweils zu einer Datenbank. Soll das Login auf mehrere Datenbanken zugreifen, benötigt es daher in jeder Datenbank einen passenden Benutzer. Die Namen müssen nicht übereinstimmen; eine eindeutige und verständliche Benennung erleichtert jedoch die Verwaltung. Weitere Varianten, darunter enthaltene Datenbankbenutzer, beschreibt Microsoft in der Dokumentation zu CREATE USER.

Rollen: Berechtigungen sinnvoll bündeln

Eine Rolle fasst Berechtigungen zusammen. Anstatt jedem Benutzer dieselben Rechte einzeln zuzuweisen, können Sie ihn einer passenden Rolle hinzufügen. Ändern sich später die Aufgaben der Anwendung, passen Sie dadurch die Rolle an, statt jeden Benutzer einzeln zu bearbeiten.

SQL Server kennt Serverrollen und Datenbankrollen. Serverrollen gelten für die gesamte Instanz und können weitreichende administrative Aufgaben umfassen. Im Gegensatz dazu gelten Datenbankrollen nur innerhalb einer einzelnen Datenbank. Für Anwendungszugriffe bietet sich deshalb häufig eine eigene Datenbankrolle an.

Feste Datenbankrollen wie db_datareader, db_datawriter und db_owner bringen vordefinierte Rechte mit. Beispielsweise können Mitglieder von db_datareader Daten aus allen Benutzertabellen und -sichten der Datenbank lesen. Eine eigene Rolle lässt sich dagegen genauer auf die benötigten Objekte zuschneiden. Weitere Informationen finden Sie in der Dokumentation zu Datenbankrollen und Serverrollen.

Berechtigungen: Welche Aktion ist erlaubt?

Berechtigungen erlauben oder verweigern konkrete Aktionen. Mit SELECT lassen sich Daten lesen, während INSERT neue Datensätze einfügt. Zusätzlich erlaubt UPDATE Änderungen, DELETE das Löschen und EXECUTE das Ausführen einer gespeicherten Prozedur.

Mit GRANT erteilen Sie ein Recht. Dagegen entfernt REVOKE eine zuvor erteilte Berechtigung, während DENY ein Recht ausdrücklich verweigert. Die effektiven Rechte können sich aus mehreren Rollen und direkten Berechtigungen zusammensetzen. Außerdem gibt es Ausnahmen, etwa bei Mitgliedern von sysadmin oder beim Zugriff über eine sogenannte Ownership Chain. Planen Sie Rechte daher von den benötigten Aktionen und Objekten aus.

Beispiel: Eine Anwendung mit minimalen Rechten einrichten

Im folgenden Beispiel verbindet sich eine Bestell-Anwendung mit der Datenbank OrdersDb. Sie soll die Bestellungen eines Kunden über eine gespeicherte Prozedur lesen. Deshalb erhält die Anwendung keine direkten Leserechte auf die Tabelle. Stattdessen darf sie nur die benötigte Prozedur ausführen.

Führen Sie die Einrichtung mit einem dafür berechtigten Administrations- oder Bereitstellungskonto aus. Ersetzen Sie vorher den Datenbanknamen und den Passwort-Platzhalter. Ein echtes Produktionspasswort sollte in einem dafür vorgesehenen Secret Store liegen und nicht dauerhaft in einem SQL-Skript gespeichert werden.

-- Auf Serverebene: Login für die Anwendung anlegen.
USE master;
GO

CREATE LOGIN [app_orders_login]
WITH PASSWORD = 'REPLACE_WITH_SECRET_FROM_SECRET_STORE',
     CHECK_POLICY = ON;
GO

-- In der Anwendungsdatenbank: Benutzer zuordnen und Rolle erstellen.
USE [OrdersDb];
GO

CREATE USER [app_orders_user] FOR LOGIN [app_orders_login];
GO

CREATE ROLE [app_orders_runtime] AUTHORIZATION [dbo];
GO

ALTER ROLE [app_orders_runtime] ADD MEMBER [app_orders_user];
GO

-- Beispielobjekte: Daten liegen im data-Schema,
-- die Anwendungsschnittstelle im api-Schema.
CREATE SCHEMA [data] AUTHORIZATION [dbo];
GO

CREATE SCHEMA [api] AUTHORIZATION [dbo];
GO

CREATE TABLE [data].[Orders]
(
    [OrderId] int NOT NULL PRIMARY KEY,
    [CustomerId] int NOT NULL,
    [OrderDate] date NOT NULL,
    [TotalAmount] decimal(12, 2) NOT NULL
);
GO

CREATE PROCEDURE [api].[GetOrdersForCustomer]
    @CustomerId int
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        [OrderId],
        [OrderDate],
        [TotalAmount]
    FROM [data].[Orders]
    WHERE [CustomerId] = @CustomerId;
END;
GO

-- Nur die benötigte Prozedur freigeben.
GRANT EXECUTE ON OBJECT::[api].[GetOrdersForCustomer]
TO [app_orders_runtime];
GO

Damit folgt die Rechtezuordnung der Kette Login → Datenbankbenutzer → Datenbankrolle. Die Rolle darf nur die angegebene Prozedur ausführen. Da Prozedur und Tabelle in diesem Beispiel denselben Datenbankbesitzer haben und die Prozedur statisches SQL verwendet, kann SQL Server den Tabellenzugriff über eine Ownership Chain prüfen.

Der Benutzer braucht in diesem Fall kein direktes SELECT-Recht auf data.Orders. So bleibt die Datenbanktabelle vor direkten Abfragen geschützt, während die Anwendung die vorgesehene Funktion verwenden kann. Die Microsoft-Anleitung zu Ownership Chains zeigt dieses Prinzip anhand eines Beispiels.

Geben Sie der Anwendung nur Prozeduren frei, die sie tatsächlich benötigt. Eine Prozedur zum Anlegen oder Ändern von Bestellungen können Sie ebenfalls gezielt freigeben, zum Beispiel mit GRANT EXECUTE ON OBJECT::[api].[CreateOrder] TO [app_orders_runtime];. Dieses Recht gilt dann nur für die angegebene Prozedur. Ein Recht auf ein ganzes Schema kann zwar die Verwaltung vereinfachen, umfasst aber auch passende Objekte, die später dort hinzukommen.

Ownership Chains setzen voraus, dass die beteiligten Objekte dieselben Besitzer haben und die Prozedur keinen dynamischen SQL-Code verwendet, der die Berechtigungsprüfung verändert. Prüfen Sie daher die tatsächlichen Rechte in Ihrer Datenbank. Muss eine Anwendung Tabellen direkt abfragen, vergeben Sie nur die dafür nötigen Rechte auf den benötigten Tabellen oder Sichten.

Warum sysadmin kein Anwendungsrecht ist

Mitglieder der festen Serverrolle sysadmin können jede Aktivität auf der SQL-Server-Instanz ausführen. Zudem können Berechtigungen dieser Rolle nicht verweigert werden. Sie ist deshalb für administrative Aufgaben gedacht und nicht für den normalen Datenzugriff einer Anwendung. Der genaue Umfang ist in der Dokumentation zu Serverrollen beschrieben.

Wird das Konto einer Anwendung kompromittiert oder enthält die Anwendung eine Sicherheitslücke, können überzählige Rechte den möglichen Schaden vergrößern. Mit sysadmin könnte ein Angreifer weit über die Bestelldaten hinaus auf den Server zugreifen. Ein Anwendungslogin mit eng begrenzten Rechten schränkt dagegen ein, was über diese Verbindung möglich ist.

Vergeben Sie sysadmin daher nur an wenige Personen, die tatsächlich Serveradministration leisten müssen. Für den alltäglichen Anwendungszugriff genügen meist die Rechte auf den benötigten Prozeduren, Tabellen oder Sichten. Auch db_owner ist für ein reines Laufzeitkonto normalerweise zu weitreichend.

Rechte regelmäßig prüfen

Prüfen Sie nach der Einrichtung, ob die Anwendung ihre vorgesehenen Aufgaben ausführen kann. Gleichzeitig sollte der Zugriff auf nicht benötigte Objekte scheitern. Kontrollieren Sie außerdem regelmäßig, wer Mitglied der Anwendungsrollen ist und ob alle gewährten Rechte noch gebraucht werden.

Wenn Sie Funktionen ergänzen oder entfernen, passen Sie die Berechtigungen entsprechend an. Verwenden Sie für Anwendungen eigene Konten und vermeiden Sie gemeinsam genutzte Administrationszugänge. Kann die Anwendung mit Windows-, Microsoft-Entra- oder einer anderen unterstützten Identität arbeiten, richten Sie die Anmeldung passend zu Ihrer Umgebung ein.

Beachten Sie außerdem, dass sich Login- und Benutzerverwaltung bei Azure SQL Database teilweise von einer klassischen SQL-Server-Instanz unterscheidet. Passen Sie die Beispiele deshalb an, wenn Sie eine Azure-Variante verwenden.

Häufige Fragen zum SQL Server Berechtigungsmodell

Kann sich ein Login ohne Datenbankbenutzer anmelden?

Ein Login kann sich am Server authentifizieren. Der Zugriff auf eine bestimmte Datenbank hängt jedoch zusätzlich von einem passenden Datenbankbenutzer oder einer anderen ausdrücklich eingerichteten Zugriffsform ab. Verlassen Sie sich für ein Anwendungslogin deshalb nicht auf einen unbeabsichtigten Zugriff über guest.

Reicht db_datareader für eine Lese-Anwendung?

Die Rolle erlaubt das Lesen aus allen Benutzertabellen und -sichten der Datenbank. Benötigt die Anwendung nur wenige Objekte, ist eine gezielte Freigabe auf bestimmte Sichten oder gespeicherte Prozeduren enger begrenzt.

Wann sollte eine Anwendung sysadmin erhalten?

Für alltägliche Anwendungszugriffe sollte sie diese Rolle nicht erhalten. sysadmin ist für administrative Aufgaben vorgesehen und umfasst weitreichende Rechte auf der gesamten Instanz.

Weiterführende Informationen

• Einführung in SQL
• Berechtigungshierarchie in SQL Server
• CREATE LOGIN und CREATE USER
• Datenbankrollen und Serverrollen
• Google Search Central: ausgehende Links kennzeichnen

Werbung / Affiliate-Links: Die mit einem Sternchen (*) gekennzeichneten Links sind Amazon-Partnerlinks. Wenn du darüber etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich entstehen dadurch keine zusätzlichen Kosten. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.