SQL Server absichern: Berechtigungen, Verschlüsselung und Härtung

Warum SQL-Server-Härtung meistens zu kurz kommt

Der SQL Server läuft, die Applikation funktioniert, das Backup läuft nachts durch – und genau an diesem Punkt hört die Beschäftigung mit Sicherheit in vielen KMU auf. Das Problem: Ein Datenbankserver ist in fast jeder Umgebung der Ort, an dem die eigentlich wertvollen Daten liegen – Kundendaten, Löhne, ERP-Bewegungsdaten, manchmal Gesundheitsdaten. Wer als Angreifer einmal Zugriff auf die Applikationsebene hat (kompromittierter Webserver, gestohlene Connection-String-Datei, SQL-Injection), trifft in der Praxis erstaunlich oft auf eine Instanz, auf der der Applikationsuser db_owner ist, sa kein Passwort-Ablaufdatum hat und die Datenbankdateien unverschlüsselt auf einem Fileshare liegen, der auch übers Netz erreichbar ist.

Dieser Artikel setzt bei SQL Server – Grundlagen für den Support auf und geht in die Tiefe: Wie du Logins und Rollen nach Least Privilege aufbaust, wann Windows- und wann SQL-Authentifizierung sinnvoll ist, wie TDE und Always Encrypted sich unterscheiden und ergänzen, wie SQL Server Audit lückenlose Nachweise liefert und wie du die Angriffsfläche der Instanz systematisch reduzierst.

Least Privilege bei Logins und Server-Rollen

Die häufigste Schwachstelle in gewachsenen SQL-Server-Umgebungen ist nicht ein fehlendes Sicherheits-Patch, sondern zu grosszügig vergebene Rechte. Ein Applikationskonto, das aus Bequemlichkeit sysadmin bekommen hat “damit es einfach läuft”, hebelt jede andere Sicherheitsmassnahme aus.

Die Rechte-Hierarchie verstehen

SQL Server kennt zwei Ebenen von Prinzipalen (Principals) und Rechten:

Ein Login ohne explizite Datenbank-Zuordnung sieht standardmässig gar nichts – erst durch das Mapping auf einen Datenbank-User und eine Rollenzuweisung entstehen konkrete Rechte. Genau hier liegt der Hebel für Least Privilege: Fast keine Applikation braucht db_owner, geschweige denn sysadmin.

Server-Rollen richtig einsetzen

Seit SQL Server 2022 gibt es zusätzlich zu den klassischen fixen Serverrollen zehn neue, feingranulare Rollen mit dem Präfix ##MS_ (z. B. ##MS_DefinitionReader##, ##MS_ServerStateReader##), die genau für Least-Privilege-Szenarien gedacht sind – etwa ein Monitoring-Tool, das nur Server-Zustand lesen, aber nichts ändern soll.

-- Applikationslogin anlegen: SQL-Authentifizierung, kein sysadmin, kein dbcreator
CREATE LOGIN [app_erp_svc] WITH PASSWORD = 'K9#mP2$vL8xQ!nR4', CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

-- Datenbank-User mappen und minimale Rollen zuweisen
USE ERP_Produktion;
CREATE USER [app_erp_svc] FOR LOGIN [app_erp_svc];
ALTER ROLE db_datareader ADD MEMBER [app_erp_svc];
ALTER ROLE db_datawriter ADD MEMBER [app_erp_svc];

-- Feingranular statt db_owner: nur EXECUTE auf Stored Procedures
CREATE ROLE app_erp_exec;
GRANT EXECUTE ON SCHEMA::dbo TO app_erp_exec;
ALTER ROLE app_erp_exec ADD MEMBER [app_erp_svc];

-- Monitoring-Tool: nur Server-Zustand lesen (SQL Server 2022+)
CREATE LOGIN [monitoring_svc] WITH PASSWORD = 'M0n!t0r$2026#Pw';
ALTER SERVER ROLE [##MS_ServerStateReader##] ADD MEMBER [monitoring_svc];

Für Datenbank-Reports oder BI-Tools, die nur lesen sollen, reicht db_datareader – für Migrations-Tools, die Schemaänderungen brauchen, db_ddladmin zusätzlich zu Read/Write, aber ausdrücklich ohne db_owner. Wenn eine Applikation wirklich granularere Kontrolle braucht (z. B. nur bestimmte Tabellen), nutze GRANT/DENY direkt auf Objektebene statt pauschaler Rollen.

Regelmässige Rechte-Audits

Rechte, die einmal vergeben wurden, bleiben in der Praxis meist für immer bestehen (“der Ex-Mitarbeiter hatte das mal gebraucht”). Baue dir eine wiederkehrende Kontrolle:

-- Alle Server-Logins mit sysadmin-Mitgliedschaft auflisten
SELECT sp.name AS login_name, sp.type_desc, sp.is_disabled
FROM sys.server_principals sp
WHERE sp.principal_id IN (
    SELECT member_principal_id
    FROM sys.server_role_members srm
    JOIN sys.server_principals r ON srm.role_principal_id = r.principal_id
    WHERE r.name = 'sysadmin'
);

-- Alle Datenbank-User mit db_owner je Datenbank (via sp_MSforeachdb)
EXEC sp_MSforeachdb 'USE [?]; SELECT DB_NAME() AS db, dp.name AS user_name
FROM sys.database_role_members drm
JOIN sys.database_principals dp ON drm.member_principal_id = dp.principal_id
JOIN sys.database_principals r ON drm.role_principal_id = r.principal_id
WHERE r.name = ''db_owner'' AND dp.name NOT IN (''dbo'')';

Windows- vs. SQL-Authentifizierung

SQL Server unterstützt zwei Authentifizierungsmodi, die sich fundamental in ihrer Sicherheitsarchitektur unterscheiden.

Der Mixed Mode (beide Verfahren aktiv) ist in der Praxis fast immer nötig, weil viele ERP- und Fachanwendungen SQL-Logins verlangen. Wichtig ist dann, die SQL-Logins konsequent mit Passwort-Policy zu betreiben:

-- SQL-Login mit erzwungener Passwort-Policy und Ablauf
CREATE LOGIN [app_crm_svc]
    WITH PASSWORD = 'Xk7!qR3$vN9pL2#w',
    CHECK_EXPIRATION = ON,
    CHECK_POLICY = ON;

-- sa-Konto deaktivieren, sobald ein alternativer sysadmin-Login existiert
ALTER LOGIN [sa] DISABLE;
ALTER LOGIN [sa] WITH NAME = [sa_renamed_do_not_use];

Für Umgebungen mit strengeren Anforderungen (Multi-Faktor, bedingter Zugriff) lässt sich SQL Server zudem an Microsoft Entra ID anbinden (Azure AD Authentication für SQL Server, verfügbar ab SQL Server 2022 mit Entra-Integration) – das bringt MFA und Conditional Access auch für Datenbank-Logins.

Transparent Data Encryption (TDE)

TDE verschlüsselt die physischen Datendateien (.mdf, .ndf) und Transaktionsprotokolle (.ldf) auf Blockebene, in Echtzeit, ohne Änderungen an der Applikation. Das schützt gegen ein sehr konkretes Szenario: Jemand kopiert die Datenbankdatei von einem gestohlenen Backup-Band, einem falsch konfigurierten Fileshare oder einer entwendeten Festplatte und versucht, sie an einer anderen Instanz anzuhängen. Ohne den passenden Zertifikat-/Schlüsselmaterial bleibt die Datei unlesbarer Binärmüll.

Funktionsweise und Schlüsselhierarchie

TDE arbeitet mit einer mehrstufigen Schlüsselkette:

Service Master Key (SMK, automatisch beim Setup erzeugt)
  └── Database Master Key (DMK) in master-Datenbank
        └── Zertifikat (durch DMK geschützt)
              └── Database Encryption Key (DEK) je verschlüsselter DB

-- 1. Master Key in master-Datenbank erzeugen (falls noch nicht vorhanden)
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Tr3z0r!K3y$2026#Master';

-- 2. Zertifikat für TDE erzeugen
CREATE CERTIFICATE TDE_Cert_ERP
    WITH SUBJECT = 'TDE-Zertifikat fuer ERP-Produktion';

-- 3. Database Encryption Key in der Zieldatenbank anlegen
USE ERP_Produktion;
CREATE DATABASE ENCRYPTION KEY
    WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE TDE_Cert_ERP;

-- 4. TDE einschalten
ALTER DATABASE ERP_Produktion SET ENCRYPTION ON;

-- Fortschritt prüfen
SELECT DB_NAME(database_id) AS db, encryption_state, percent_complete
FROM sys.dm_database_encryption_keys;

TDE schützt Data at Rest – also Dateien, Backups und Snapshots. Sie schützt nicht gegen Angriffe über eine gültige Datenbankverbindung: Ein Applikationsuser mit db_datareader sieht die Daten weiterhin im Klartext, weil SQL Server sie beim Lesen automatisch entschlüsselt. Für diesen Schutzbedarf – Daten auch vor privilegierten DB-Usern und Admins verbergen – ist Always Encrypted das richtige Werkzeug.

Seit SQL Server 2022 gibt es zudem Force Strict Encryption für TDS-Verbindungen (TLS 1.2/1.3 über TDS 8.0), das die ältere Force Encryption-Option ablöst und Verbindungsverschlüsselung ohne Zertifikatstricks erzwingt – relevant für Encryption in Transit, ergänzend zu TDE.

Always Encrypted für sensible Spalten

Während TDE die ganze Datenbank auf Dateiebene schützt, verschlüsselt Always Encrypted gezielt einzelne Spalten – und zwar clientseitig im Treiber, bevor die Daten überhaupt beim SQL Server ankommen. Das bedeutet: Selbst ein sysadmin-Login auf dem Server sieht in diesen Spalten nur Chiffretext, nicht den Klartext. Das ist der entscheidende Unterschied zu TDE und macht Always Encrypted zur richtigen Wahl für Kreditkartennummern, Sozialversicherungsnummern (AHV-Nummer) oder Gehaltsdaten.

Grundmodus vs. Secure Enclaves

Einrichtung im Grundmodus

Always Encrypted braucht zwei Schlüsseltypen: einen Column Master Key (CMK), der typischerweise in einem externen Schlüsselspeicher liegt (Windows-Zertifikatspeicher, Azure Key Vault, HSM), und einen Column Encryption Key (CEK) je Spaltengruppe, der durch den CMK geschützt in der Datenbank liegt.

-- Spalte fuer Always Encrypted vorbereiten (vereinfachtes Beispiel via T-SQL,
-- produktiv meist ueber SSMS-Wizard oder PowerShell-Modul SqlServer)
CREATE TABLE dbo.Mitarbeiter (
    MitarbeiterId INT IDENTITY PRIMARY KEY,
    Name NVARCHAR(100) NOT NULL,
    AHV_Nummer CHAR(13) COLLATE Latin1_General_BIN2
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Mitarbeiter,
            ENCRYPTION_TYPE = DETERMINISTIC,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ) NOT NULL,
    Lohn DECIMAL(10,2)
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = CEK_Mitarbeiter,
            ENCRYPTION_TYPE = RANDOMIZED,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ) NULL
);

DETERMINISTIC erlaubt Gleichheitsabfragen und Joins auf der Spalte (z. B. Suche nach exakter AHV-Nummer), gibt aber bei gleichen Klartextwerten immer denselben Chiffretext zurück – ein Angreifer mit Datenbankzugriff kann so Muster erkennen (welche Zeilen denselben Wert haben), auch ohne den Klartext zu kennen. RANDOMIZED ist sicherer, erlaubt aber keinerlei Vergleiche oder Sortierung mehr auf dieser Spalte in T-SQL. Die Wahl ist also ein Kompromiss zwischen Abfragbarkeit und Schutzniveau.

Alternative für weniger kritische Fälle: Dynamic Data Masking

Wenn der Anspruch “nur Blickschutz vor normalen Usern in SSMS-Abfragen” statt echter kryptografischer Absicherung ist, reicht oft Dynamic Data Masking (DDM) – deutlich einfacher einzurichten, aber kein Ersatz für Always Encrypted, da Nutzer mit UNMASK-Recht oder cleveren Abfragen (z. B. Brute-Force über WHERE-Bedingungen) die Maskierung umgehen können:

ALTER TABLE dbo.Kunden
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

ALTER TABLE dbo.Kunden
ALTER COLUMN Kreditkartennummer ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)');

SQL Server Audit

Ohne Audit-Trail lässt sich im Ernstfall (Datenleck, Compliance-Anfrage, interner Verdacht) nicht rekonstruieren, wer wann auf welche Daten zugegriffen oder was geändert hat. SQL Server Audit protokolliert serverweite und datenbankspezifische Ereignisse zuverlässig und performant (basierend auf Extended Events) und ist seit SQL Server 2016 SP1 in allen Editionen inklusive Standard verfügbar.

Architektur: Server Audit, Server- und Database Audit Specification

SERVER AUDIT (definiert WOHIN geloggt wird: Datei, Windows-Ereignisanzeige)
  ├── SERVER AUDIT SPECIFICATION (serverweite Events: Logins, Rollenaenderungen)
  └── DATABASE AUDIT SPECIFICATION (je Datenbank: SELECT/UPDATE auf bestimmte Objekte)

-- 1. Server Audit anlegen: Ziel = Datei mit Rotation
CREATE SERVER AUDIT Audit_ERP_Produktion
    TO FILE (
        FILEPATH = 'D:\SQLAudit\',
        MAXSIZE = 256 MB,
        MAX_ROLLOVER_FILES = 50
    )
    WITH (ON_FAILURE = CONTINUE);

ALTER SERVER AUDIT Audit_ERP_Produktion WITH (STATE = ON);

-- 2. Serverweite sicherheitsrelevante Ereignisse erfassen
CREATE SERVER AUDIT SPECIFICATION Audit_Spec_Server_Security
    FOR SERVER AUDIT Audit_ERP_Produktion
    ADD (FAILED_LOGIN_GROUP),
    ADD (SUCCESSFUL_LOGIN_GROUP),
    ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
    ADD (SERVER_PERMISSION_CHANGE_GROUP)
    WITH (STATE = ON);

-- 3. Datenbank-Audit: gezielt Zugriffe auf sensible Tabelle protokollieren
USE ERP_Produktion;
CREATE DATABASE AUDIT SPECIFICATION Audit_Spec_Loehne
    FOR SERVER AUDIT Audit_ERP_Produktion
    ADD (SELECT, UPDATE, DELETE ON dbo.Loehne BY [public])
    WITH (STATE = ON);

Audit-Log auswerten

-- Fehlgeschlagene Logins der letzten 24 Stunden auslesen
SELECT event_time, server_principal_name, client_ip, statement
FROM sys.fn_get_audit_file('D:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT)
WHERE action_id = 'LGIF' AND event_time > DATEADD(HOUR, -24, SYSUTCDATETIME())
ORDER BY event_time DESC;

Für granularere, entwicklerfreundlichere Ereignisverfolgung ohne den vollen Audit-Objektbaum eignen sich zusätzlich Extended Events (sys.dm_xe_*), etwa um kurzfristig Performance-Probleme mit Security-Bezug (z. B. verdächtig viele SELECT * auf Kreditkartentabellen) zu debuggen.

Surface Area reduzieren: ungenutzte Features deaktivieren

Jedes aktivierte Feature, jeder laufende Dienst und jedes offene Protokoll ist potenzielle Angriffsfläche. SQL Server installiert seit Version 2005 standardmässig die meisten riskanten Features deaktiviert – trotzdem werden viele im Betrieb aus Bequemlichkeit wieder eingeschaltet und nie zurückgesetzt.

Die wichtigsten Stellschrauben über sp_configure

-- Aktuellen Status aller (auch versteckten) Konfigurationsoptionen anzeigen
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure;

-- xp_cmdshell deaktivieren (Kommandozeilen-Ausfuehrung ueber SQL)
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

-- Ad-hoc-Distributed-Queries (OPENROWSET/OPENDATASOURCE) deaktivieren
EXEC sp_configure 'Ad Hoc Distributed Queries', 0;
RECONFIGURE;

-- CLR-Integration nur aktivieren, wenn wirklich benoetigt
EXEC sp_configure 'clr enabled', 0;
RECONFIGURE;

-- Remote Access nur wenn Linked-Server-Funktionalitaet gebraucht wird
EXEC sp_configure 'remote access', 0;
RECONFIGURE;

-- Datenbank-Mail nur aktivieren, wenn tatsaechlich genutzt
EXEC sp_configure 'Database Mail XPs', 0;
RECONFIGURE;

Entscheidungsablauf für neue Features

Bevor du ein Feature aktivierst (CLR, xp_cmdshell, Linked Server, Database Mail), lohnt sich eine kurze Checkliste:

1. Gibt es eine Alternative ohne erweiterte Rechte (z. B. SQL Server Agent Job statt xp_cmdshell-Aufruf)?
2. Wird das Feature dauerhaft gebraucht oder nur für eine einmalige Migration?
3. Wer genau braucht Zugriff darauf – lässt sich das über eine granulare Rolle statt eines pauschalen Rechts abbilden?
4. Ist die Aktivierung dokumentiert (wann, warum, von wem – siehe IT-Dokumentation und Inventar)?
5. Gibt es einen Reminder, das Feature wieder zu deaktivieren, falls es nur temporär gebraucht wurde?

Nur wenn alle vier Fragen sauber beantwortet sind, aktivierst du das Feature – befristet, dokumentiert und mit Wiedervorlage.

Row-Level Security und weitere ergänzende Mechanismen

Zwei Bausteine, die häufig übersehen werden, aber in KMU-Szenarien mit Mandantentrennung oder abteilungsspezifischen Sichten wertvoll sind:

• Row-Level Security (RLS): Filtert Zeilen serverseitig automatisch nach dem angemeldeten User, ohne dass die Applikation WHERE-Klauseln pflegen muss – etwa damit ein Vertriebsmitarbeiter nur “seine” Kunden sieht.
• Certificate-based Login Mapping: Für Szenarien, in denen sich Applikationen gegenseitig per Zertifikat statt Passwort authentifizieren sollen (z. B. Cross-Datenbank-Zugriffe zwischen getrennten Instanzen).

-- Row-Level Security: Sicherheitsfunktion und Policy
CREATE FUNCTION dbo.fn_SecurityPredicate(@VerkaeuferId INT)
    RETURNS TABLE
    WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS Result
    WHERE @VerkaeuferId = CAST(SESSION_CONTEXT(N'VerkaeuferId') AS INT)
        OR IS_MEMBER('db_owner') = 1;

CREATE SECURITY POLICY dbo.KundenFilterPolicy
    ADD FILTER PREDICATE dbo.fn_SecurityPredicate(VerkaeuferId)
    ON dbo.Kunden
    WITH (STATE = ON);

Entscheidungsbaum: Welche Verschlüsselung für welchen Fall?

Brauchst du Schutz gegen gestohlene Backups/Festplatten (Data at Rest)?
├── Ja → TDE aktivieren (immer, geringer Aufwand, kein Applikationseingriff)
└── Nein/reicht nicht → weiter

Müssen einzelne Spalten auch vor DB-Admins/sysadmin verborgen bleiben?
├── Ja, und Abfragen wie Bereichsvergleiche/LIKE noetig → Always Encrypted mit Secure Enclaves
├── Ja, nur Gleichheitsvergleiche/keine Abfragen noetig → Always Encrypted (Basis)
└── Nein, nur "Sichtschutz" vor normalen Usern in Tools → Dynamic Data Masking reicht

Brauchst du lückenlosen Nachweis, wer wann auf was zugegriffen hat?
└── Ja (praktisch immer im regulierten/KMU-Kontext) → SQL Server Audit einrichten,
    zentral sammeln, regelmässig auswerten

Checkliste: SQL-Server-Härtung Schritt für Schritt

1. sa deaktivieren/umbenennen, dedizierten sysadmin-Login mit starkem Passwort im Tresor anlegen.
2. Alle Applikationslogins auf minimale Rollen (db_datareader/db_datawriter statt db_owner) zurückstufen.
3. Windows-Authentifizierung bevorzugen, SQL-Logins nur wo zwingend nötig, mit CHECK_POLICY = ON.
4. TDE für alle Produktionsdatenbanken aktivieren, Zertifikat sofort extern sichern.
5. Für hochsensible Spalten (AHV-Nummer, Löhne, Kreditkarten) Always Encrypted einrichten.
6. SQL Server Audit für Logins, Rollenänderungen und sensible Tabellen aktivieren, Logs zentral sammeln.
7. xp_cmdshell, Ad-hoc Distributed Queries, CLR, Database Mail deaktivieren, wenn ungenutzt.
8. Port 1433 hinter Firewall isolieren, keine direkte Internet-Exposition.
9. Regelmässiges Rechte-Audit (mindestens halbjährlich) gegen Rollen-Wildwuchs.
10. Patch-Stand der Instanz (Cumulative Updates) im gleichen Rhythmus wie Betriebssystem-Patches pflegen.

Weiterlernen

• Transparent Data Encryption (TDE) – Microsoft Learn
• Always Encrypted (Database Engine) – Microsoft Learn
• Always Encrypted with secure enclaves – Microsoft Learn
• SQL Server Audit (Database Engine) – Microsoft Learn
• SQL Server Security Best Practices – Microsoft Learn
• Server-Level Roles – Microsoft Learn
• CIS Microsoft SQL Server Benchmarks

Videos

YouTube