SQL Server Sicherheitskonzepte: Logins, Benutzer, Rollen & Berechtigungen

📅 13. Mai 2025 ✍️ Von einem erfahrenen SQL Server DBA ⏱ 10 Min. Lesezeit

Einleitung: Die Grundlage jeder sicheren Datenbank

Die Sicherheit Ihrer SQL Server Datenbanken steht und fällt mit einem durchdachten Berechtigungskonzept. Doch gerade hier passieren viele Fehler: Zu weitreichende Rechte, fehlende Trennung von Instanz- und Datenbankebene, undurchschaubare Rollenstrukturen. In diesem Artikel erläutern wir die grundlegenden Bausteine – von Logins über Benutzer bis hin zu Rollen und Schemata – und zeigen praxisnahe Konzepte für eine sichere, wartbare Berechtigungsstruktur.

🏢 1. Login vs. Benutzer – Der Unterschied, den viele nicht kennen

Eine der ersten Hürden im SQL Server Sicherheitsmodell ist die Unterscheidung zwischen Login (Instanz-Ebene) und Benutzer (Datenbank-Ebene).

Login: Berechtigt zum Verbinden mit der SQL Server-Instanz. Existiert auf Server-Ebene (sys.server_principals).
Benutzer: Repräsentiert ein Login innerhalb einer bestimmten Datenbank. Existiert in jeder Datenbank separat (sys.database_principals).

-- Login auf Instanz-Ebene erstellen
CREATE LOGIN AppUser WITH PASSWORD = 'SecurePw123!';

-- In der Datenbank "MyDB" einen Benutzer für dieses Login anlegen
USE MyDB;
CREATE USER AppUser FOR LOGIN AppUser;

💡 Merksatz: Ein Login allein erlaubt keinen Zugriff auf Datenbankinhalte. Erst der Datenbank-Benutzer verknüpft das Login mit den Rechten in der Datenbank.

Windows-Logins funktionieren analog: Der Windows-Benutzer oder die Gruppe wird als Login angelegt und in den Datenbanken als Benutzer zugeordnet.

🔐 2. Authentifizierungsmodi: Windows vs. SQL Server

SQL Server unterstützt zwei Authentifizierungsmodi – beide haben ihre Berechtigung.

Windows-Authentifizierung (integrierte Sicherheit): Nutzt Active Directory, keine Passwörter in Anwendungen, zentrales Identity Management. Empfohlen für interne Netzwerke und Domänenumgebungen.
SQL Server-Authentifizierung: Login/Passwort wird von SQL Server verwaltet. Erforderlich für Legacy-Anwendungen oder wenn keine Domäne verfügbar ist. Weniger sicher, daher mit starken Passwortrichtlinien kombinieren.

⚠️ Wichtige Sicherheitseinstellung: Der sa-Account sollte umbenannt und deaktiviert werden, es sei denn, es gibt zwingende Gründe. Verwenden Sie stattdessen dedizierte SQL-Logins mit minimalen Rechten.

-- Überprüfung des Authentifizierungsmodus
SELECT SERVERPROPERTY('IsIntegratedSecurityOnly'); -- 1 = nur Windows, 0 = gemischt

-- Deaktivierung des sa-Logins (empfohlen)
ALTER LOGIN sa DISABLE;

👥 3. Serverrollen – Berechtigungen auf Instanz-Ebene

Serverrollen bündeln Berechtigungen auf der gesamten SQL Server-Instanz. Sie werden einem Login zugewiesen.

sysadmin: Unbeschränkte Rechte auf der Instanz (nur für Kernadministratoren).
securityadmin: Verwaltung von Logins und Berechtigungen auf Server-Ebene.
serveradmin: Server-weite Konfiguration, Shutdown, etc.
setupadmin: Verwaltung von Linked Servern und erweiterten gespeicherten Prozeduren.
processadmin: Beenden von Prozessen.
diskadmin: Verwaltung von Datenträgerdateien.
dbcreator: Erstellen, Ändern und Löschen von Datenbanken.
bulkadmin: Ausführen von BULK INSERT.

-- Login einer Serverrolle zuweisen
ALTER SERVER ROLE dbcreator ADD MEMBER AppUser;

🚨 Achtung: Die Rolle sysadmin gewährt vollständige Kontrolle. Vergeben Sie sie nur im absoluten Ausnahmefall und dokumentieren Sie dies.

📚 4. Datenbankrollen – Berechtigungen innerhalb einer Datenbank

Innerhalb jeder Datenbank gibt es feste und benutzerdefinierte Rollen. Sie erleichtern die Rechteverwaltung erheblich.

Feste Datenbankrollen (vordefiniert):

db_owner: Vollzugriff auf die Datenbank (vergleichbar mit sysadmin auf Datenbankebene).
db_securityadmin: Verwaltung von Rollen und Berechtigungen in der Datenbank.
db_accessadmin: Verwaltung von Datenbank-Benutzern.
db_backupoperator: Erstellen von Sicherungen.
db_ddladmin: Ausführen von DDL-Anweisungen (CREATE, ALTER, DROP).
db_datawriter: INSERT, UPDATE, DELETE auf alle Benutzertabellen.
db_datareader: SELECT auf alle Benutzertabellen.
db_denydatawriter/reader: Explizite Verweigerung von Schreib-/Lesezugriffen.

-- Datenbankbenutzer einer festen Rolle zuweisen
USE MyDB;
ALTER ROLE db_datareader ADD MEMBER AppUser;

Benutzerdefinierte Datenbankrollen:

Für feingranulare Berechtigungen (z. B. nur Zugriff auf bestimmte Tabellen) erstellen Sie eigene Rollen.

CREATE ROLE SalesReporting;
GRANT SELECT ON Sales.Orders TO SalesReporting;
ALTER ROLE SalesReporting ADD MEMBER AppUser;

💡 Best Practice: Verwenden Sie nach Möglichkeit Rollen statt direkter Berechtigungen pro Benutzer. Das vereinfacht Auditierung und spätere Änderungen.

🧩 5. Schemata zur logischen Gruppierung

Schemata sind Container für Tabellen, Sichten und andere Objekte. Sie erleichtern die Strukturierung (z. B. Sales, HR, Logging) und dienen auch der Berechtigungsvergabe: Man kann einer Rolle Rechte auf ein gesamtes Schema erteilen, statt auf jedes Objekt einzeln.

-- Schema erstellen und einer Rolle SELECT-Rechte geben
CREATE SCHEMA HR AUTHORIZATION dbo;
GRANT SELECT ON SCHEMA::HR TO HRReader;

⚠️ Wichtiger Sicherheitsaspekt: Standardmäßig ist das Standardschema eines Benutzers dbo. Wenn ein Benutzer Objekte ohne Schemaqualifikation erstellt, landen sie im Standardschema. Daher sollte man das Standardschema gezielt setzen.

⚙️ 6. Berechtigungsarten: GRANT, DENY, REVOKE

Die drei grundlegenden Anweisungen steuern Zugriffe auf Objekte.

GRANT: Erteilt eine Berechtigung (z. B. SELECT, INSERT, UPDATE, DELETE, EXECUTE, ALTER, CONTROL).
DENY: Verweigert eine Berechtigung explizit – hat Vorrang vor GRANT (auch über Rollen). Verwenden Sie DENY sparsam, da es leicht zu Verwirrung führt.
REVOKE: Entfernt eine zuvor erteilte oder verweigerte Berechtigung (neutralisiert GRANT/DENY).

GRANT SELECT, INSERT ON dbo.Customers TO SalesRole;
DENY DELETE ON dbo.Customers TO SalesRole;
REVOKE INSERT ON dbo.Customers TO SalesRole; -- INSERT wird neutral, SELECT bleibt

🚨 Häufiger Irrtum: REVOKE ist nicht gleich DENY. DENY blockiert – REVOKE hebt eine explizite Berechtigung lediglich auf.

📐 7. Ein durchdachtes Sicherheitskonzept – Schritt für Schritt

Ein robustes Berechtigungskonzept folgt diesen Prinzipien:

Minimum Viable Privileges (MVP): Jeder Benutzer/Prozess erhält nur die minimal nötigen Rechte.
Trennung von Instanz- und Datenbankadministration: Nicht jeder DBA benötigt sysadmin-Rechte. Oft reicht db_owner in bestimmten Datenbanken.
Rollenbasierte Zugriffskontrolle (RBAC): Berechtigungen werden Rollen zugeordnet, Benutzer werden Mitglied von Rollen.
Verwendung von Schemata: Gruppieren Sie Objekte logisch und vergeben Sie Rechte auf Schemaebene.
Regelmäßige Überprüfungen: Mit Berichten über Benutzerrechte und Rollenzugehörigkeiten.

-- Beispiel für eine rollenbasierte Struktur in einer Anwendungsdatenbank
CREATE ROLE AppReader;
CREATE ROLE AppWriter;
CREATE ROLE AppAdmin;

GRANT SELECT ON SCHEMA::Sales TO AppReader;
GRANT INSERT, UPDATE, DELETE ON SCHEMA::Sales TO AppWriter;
GRANT ALTER, CONTROL ON SCHEMA::Sales TO AppAdmin;

ALTER ROLE AppReader ADD MEMBER ReportingUser;
ALTER ROLE AppWriter ADD MEMBER ApplicationLogin;
ALTER ROLE AppAdmin ADD MEMBER SeniorDBA;

🛠️ 8. Nützliche Abfragen für das Berechtigungsmanagement

Die folgenden Abfragen helfen Ihnen, den Überblick zu behalten.

-- Alle Logins auf Instanzebene mit ihren Serverrollen
SELECT p.name AS LoginName, r.name AS ServerRole
FROM sys.server_principals p
LEFT JOIN sys.server_role_members rm ON p.principal_id = rm.member_principal_id
LEFT JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
WHERE p.type IN ('S', 'U'); -- SQL Login, Windows Login

-- Benutzer und Datenbankrollen in einer Datenbank
USE MyDB;
SELECT u.name AS UserName, r.name AS DatabaseRole
FROM sys.database_principals u
LEFT JOIN sys.database_role_members rm ON u.principal_id = rm.member_principal_id
LEFT JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id
WHERE u.type IN ('S', 'U'); -- SQL User, Windows User

-- Explizite Berechtigungen eines Benutzers auf Objekte
SELECT class_desc, object_name(major_id) AS ObjectName, permission_name, state_desc
FROM sys.database_permissions
WHERE grantee_principal_id = DATABASE_PRINCIPAL_ID('AppUser');

🎓 9. Häufige Fehler und wie man sie vermeidet

Jeder Benutzer bekommt sysadmin / db_owner: Führt zu Sicherheitslücken und unbeabsichtigten Änderungen. → Statten Sie nur Administratoren mit diesen Rollen aus.
Direkte Berechtigungen auf Benutzer statt Rollen: Erschwert die Wartung und erhöht Fehleranfälligkeit. → Definieren Sie Rollen nach Aufgabenprofilen.
Vergessen des Schemabesitzers: Wenn ein Benutzer Objekte in einem falschen Schema erstellt, kann die Berechtigungssteuerung versagen. → Setzen Sie das Standardschema explizit.
Login ohne Datenbankbenutzer angelegt: Der Benutzer kann sich zwar verbinden, hat aber keinen Zugriff auf Datenbanken. → Den Benutzer immer in den benötigten Datenbanken anlegen.
Verwendung von guest in Datenbanken: Das Gastkonto gewährt anonymen Zugriff. Standardmäßig ist es deaktiviert – lassen Sie es deaktiviert, es sei denn, Sie benötigen explizit öffentlichen Zugriff.

💡 Profi-Tipp: Erstellen Sie eine Checkliste für neue Berechtigungen: Welche Datenbank, welche Rollen, welche Schemata benötigt der Benutzer? Vermeiden Sie so "Überberechtigungen".

📋 Fazit

Ein sicheres SQL Server Berechtigungskonzept basiert auf dem Zusammenspiel von Logins, Datenbankbenutzern, Rollen und Schemata. Die klare Trennung von Instanz- und Datenbankebene, das Prinzip der minimalen Rechte und die Nutzung von Rollen sind die Schlüssel zu wartbaren, sicheren Systemen. Nehmen Sie sich die Zeit, ein passendes Rollenmodell zu entwerfen – Ihre Auditoren und zukünftigen Administratoren werden es Ihnen danken.