SQL Server Sicherheit, Logins und Compliance mit PowerShell automatisieren

10 PowerShell-Funktionen fuer alle sicherheitsrelevanten Aspekte der SQL Server Administration: Login-Audit, SA-Haertung, SPN-Reports, Firewall-Tests und Policy-Based Management fuer Compliance in regulierten Umgebungen.

10 Funktionen Compliance & Audit Active Directory Integration

Sicherheit & Logins - Funktionen im Ueberblick

Invoke-sqmLoginAudit - SQL Server Login-Audit PowerShell: Typ, Status, letzte Anmeldung, fehlende AD-Konten

Was macht die Funktion?

Erstellt einen umfassenden Audit-Bericht aller SQL Server Logins: Typ (SQL/Windows), Status (aktiviert/deaktiviert), letzte erfolgreiche Anmeldung, Rollenzugehoerigkeit und AD-Kontostatus. Fehlende oder deaktivierte AD-Konten hinter Windows-Logins werden automatisch identifiziert und markiert.

Wann nutzt man sie?

Fuer regelmaessige Compliance-Audits nach MaRisk, BAIT oder internen Sicherheitsrichtlinien. Nach Mitarbeiterfluktuation um verwaiste Logins von ausgeschiedenen Mitarbeitern zu finden. Als Basis fuer Zugriffsbereinigungsaktionen in Vorbereitung auf externe Audits.

Typische Probleme

  • Windows-Logins von ausgeschiedenen Mitarbeitern bleiben in SQL Server aktiv
  • Keine Uebersicht ueber Logins die sich seit Monaten nicht angemeldet haben
  • SQL-Logins mit schwachen Passwoertern oder ohne Passwortablauf nicht identifizierbar

Vorteile

  • Vollstaendiger Ueberblick aller Logins in einer strukturierten Ausgabe
  • Automatische AD-Statuspruefung identifiziert sofort Risiko-Logins
  • Direkte CSV-Ausgabe fuer Audit-Dokumentation und Change-Requests
# Vollstaendiger Login-Audit mit AD-Statuspruefung
Invoke-sqmLoginAudit -SqlInstance "SQL01" -CheckADStatus | Export-Csv "Login-Audit.csv" -NoTypeInformation

# Nur inaktive Logins (letzte Anmeldung aelter als 90 Tage)
Invoke-sqmLoginAudit -SqlInstance "SQL01" -InactiveDays 90

Get-sqmSysadminAccounts - SQL Server Sysadmin-Konten auflisten PowerShell inkl. inaktiver und Windows-Gruppen

Was macht die Funktion?

Listet alle SQL Server Logins mit Sysadmin-Berechtigung auf - inklusive deaktivierter Konten, Dienstkonten und Windows-Gruppen deren Mitglieder indirekt Sysadmin-Rechte erhalten. Die Ausgabe zeigt Typ, Status, letzte Anmeldung und ob das zugrundeliegende AD-Konto aktiv ist.

Wann nutzt man sie?

Vor externen Sicherheitsaudits zur Dokumentation aller privilegierten Konten. Nach Personalwechsel um sicherzustellen dass ausgeschiedene Administratoren keine Sysadmin-Rechte mehr haben. Als Teil eines regelmaessigen Privileged-Access-Reviews.

Typische Probleme

  • Windows-Gruppen in der Sysadmin-Rolle - indirekte Mitglieder werden oft uebersehen
  • Deaktivierte SQL-Logins mit Sysadmin-Rechten erscheinen als harmlos
  • Dienstkonten mit unnoetigem Sysadmin - Least-Privilege-Prinzip verletzt

Vorteile

  • Zeigt auch indirekte Sysadmin-Mitglieder durch Windows-Gruppen
  • Status-Ampel: sofortige visuelle Kennzeichnung kritischer Konten
  • Pipeline-faehig: direkte Weiterverarbeitung fuer Reporting und Alerting
# Alle Sysadmin-Konten auf einer Instanz auflisten
Get-sqmSysadminAccounts -SqlInstance "SQL01"

# Mehrere Instanzen, Ausgabe als HTML
@("SQL01","SQL02","SQL03") | Get-sqmSysadminAccounts | ConvertTo-Html | Out-File "Sysadmins.html"

Get-sqmADAccountStatus - AD-Kontostatus fuer SQL Service Accounts und Logins pruefen PowerShell

Was macht die Funktion?

Prueft den Active Directory Status aller Windows-Logins und SQL Server Service Accounts: deaktiviert, gesperrt, Passwort abgelaufen, Konto abgelaufen oder Passwortaenderung erzwungen. Die Funktion fragt direkt gegen Active Directory ab und gibt strukturierte Ergebnisse zurueck.

Wann nutzt man sie?

Zur proaktiven Ueberwachung von Service Account Passwort-Ablaufdaten. Bei unerklaerlichen SQL Server Verbindungsproblemen zur schnellen Diagnose ob AD-Konten gesperrt sind. Im Rahmen von Zugriffs-Reviews zur Ueberpruefung aller Windows-Logins gegen AD.

Typische Probleme

  • SQL Server Dienst startet nicht weil das Service-Account-Passwort abgelaufen ist
  • Gesperrte AD-Konten durch Passwort-Failover-Policies werden nicht rechtzeitig bemerkt
  • Abgelaufene Benutzerkonten hinter aktiven Windows-Logins sind ohne AD-Check unsichtbar

Vorteile

  • Fruehzeitige Warnung vor Passwortablauf - verhindert ungeplante Dienstausfaelle
  • Ueberprueft sowohl Logins als auch SQL Server Service Accounts in einem Durchgang
  • Konfigurierbare Warnschwelle fuer baldigen Passwortablauf (z.B. 14 Tage)
# AD-Status aller Windows-Logins und Service Accounts pruefen
Get-sqmADAccountStatus -SqlInstance "SQL01"

# Warnung wenn Passwort in weniger als 14 Tagen ablaeuft
Get-sqmADAccountStatus -SqlInstance "SQL01" -WarnDaysBeforeExpiry 14

Copy-sqmLogins - SQL Server Logins mit Passwort-Hash und Rollen kopieren PowerShell fuer Migration und DR

Was macht die Funktion?

Kopiert SQL Server Logins inklusive Passwort-Hash, SID und Rollenzugehoerigkeit von einer Quellinstanz auf eine Zielinstanz. Unterstuetzt Windows-Logins, SQL-Logins und Server-Rollen. Optional koennen bestehende Logins auf dem Ziel uebersprungen oder ueberschrieben werden.

Wann nutzt man sie?

Bei der Migration einer SQL Server Instanz auf neue Hardware oder in die Cloud. Beim Aufbau einer Disaster Recovery Instanz um Logins konsistent zu halten. Als Teil der AlwaysOn-Einrichtung fuer die initiale Login-Synchronisierung auf alle Secondaries.

Typische Probleme

  • Neu angelegte Logins ohne SID-Kopie erzeugen Orphaned Users in den Datenbanken
  • Manuelles Skripten von Logins kopiert nicht den Passwort-Hash - Passwort muss neu gesetzt werden
  • Fehlende Rollenmitgliedschaften nach Migration - Applikationen erhalten unzureichende Rechte

Vorteile

  • Korrekte SID-Kopie verhindert Orphaned-User-Probleme nach der Migration
  • Passwort-Hash wird korrekt uebertragen - keine Passwort-Resets notwendig
  • Protokoll aller kopierten und uebersprungenen Logins fuer das Change-Management
# Alle Logins von SQL01 nach SQL02 kopieren
Copy-sqmLogins -Source "SQL01" -Destination "SQL02"

# Nur bestimmte Logins kopieren, andere ausschliessen
Copy-sqmLogins -Source "SQL01" -Destination "SQL02" -ExcludeLogin "OldApp*"

Invoke-sqmSaObfuscation - SA-Konto haerten PowerShell: Umbenennung und Deaktivierung nach Sicherheitsrichtlinien

Was macht die Funktion?

Haertet das SA-Konto gemaess Best Practices: Umbenennung auf einen nicht-erratbaren Namen, Deaktivierung des Kontos und optionale Passwortaenderung auf ein zufaelliges Passwort. Alle Aenderungen werden protokolliert und koennen mit einem WhatIf-Modus vorab simuliert werden.

Wann nutzt man sie?

Bei der Ersteinrichtung neuer SQL Server Instanzen als Pflicht-Haertungsschritt. In Vorbereitung auf externe Penetrationstests um bekannte Standard-Angriffsvektoren zu schliessen. Als Teil eines standardisierten Hardening-Skripts fuer alle neuen SQL Server Installationen.

Typische Probleme

  • Das SA-Konto mit bekanntem Namen ist das primaere Ziel von Brute-Force-Angriffen
  • Aktiviertes SA-Konto verstosst gegen CIS-Benchmark und interne Security-Policies
  • Kein Nachweis dass SA-Haertung auf allen Instanzen durchgefuehrt wurde

Vorteile

  • WhatIf-Modus zeigt was geaendert wuerde ohne tatstaechliche Aenderungen
  • Protokoll der Aenderungen als Compliance-Nachweis fuer Audits
  • Zufaelliges neues Passwort eliminiert Passwort-Rate-Angriffe
# SA-Haertung simulieren (WhatIf)
Invoke-sqmSaObfuscation -SqlInstance "SQL01" -NewSaName "sql_svc_disabled" -WhatIf

# SA-Haertung ausfuehren: umbenennen, deaktivieren, Passwort aendern
Invoke-sqmSaObfuscation -SqlInstance "SQL01" -NewSaName "sql_svc_disabled" -Disable -RandomizePassword

Set-sqmDatabaseOwner - Einheitlichen Datenbank-Owner PowerShell setzen auf allen SQL Server Datenbanken

Was macht die Funktion?

Setzt einen einheitlichen Datenbank-Owner (typischerweise SA oder ein dediziertes Dienstkonto) auf allen oder ausgewaehlten Datenbanken einer Instanz. Zeigt vorher den aktuellen Owner jeder Datenbank und protokolliert alle Aenderungen. Unterstuetzt Whitelist fuer Ausnahmen.

Wann nutzt man sie?

Bei der Abloesung von Mitarbeitern die Datenbanken als persoenliches Benutzerkonto besitzen. Im Rahmen von Standardisierungsprojekten fuer einheitliche Owner-Konfiguration. Nach Migrationen wenn Datenbanken den Owner der Quellinstanz mitgebracht haben.

Typische Probleme

  • Datenbanken mit persoenlichem Mitarbeiterkonto als Owner - nach Austritt entstehen Probleme
  • Inkonsistente Owner-Konfiguration erschwert automatisierte Maintenance-Jobs
  • Datenbank-Owner-Wechsel ohne Protokoll nicht nachvollziehbar fuer den Audit

Vorteile

  • Einheitlicher Owner auf allen Datenbanken vereinfacht Wartung und Automatisierung
  • Whitelist-Option schluetzt bestimmte Datenbanken von der Aenderung aus
  • Vollstaendiges Protokoll aller Owner-Aenderungen fuer den Audit
# Owner aller User-Datenbanken auf SA setzen
Set-sqmDatabaseOwner -SqlInstance "SQL01" -Owner "sa"

# Owner setzen, bestimmte Datenbanken ausnehmen
Set-sqmDatabaseOwner -SqlInstance "SQL01" -Owner "DOMAIN\sql_svc" -ExcludeDatabase @("ReportServer","SSISDB")

Set-sqmSqlPolicyState - SQL Server Policy-Based Management PowerShell aktivieren fuer Compliance-Rollouts

Was macht die Funktion?

Aktiviert oder deaktiviert Policy-Based Management Policies auf einer SQL Server Instanz. Unterstuetzt sowohl einzelne Policies als auch Policy-Kategorien und kann ueber mehrere Instanzen gleichzeitig ausgefuehrt werden. Zustandsaenderungen werden protokolliert.

Wann nutzt man sie?

Beim Rollout neuer Compliance-Anforderungen die als PBM-Policies implementiert wurden. Bei der Deaktivierung von Policies die in Wartungsfenstern temporaer nicht gelten sollen. Als Teil der Ersteinrichtung neuer SQL Server Instanzen mit Unternehmens-Compliance-Policies.

Typische Probleme

  • Manuelle Policy-Aktivierung auf vielen Instanzen fehleranfaellig und zeitintensiv
  • Kein Nachweis welche Policies auf welchen Instanzen aktiviert sind
  • Unterschiedliche Policy-Zustaende auf verschiedenen Instanzen erschweren Compliance

Vorteile

  • Konsistenter Policy-Zustand auf allen Instanzen in einem Befehl
  • Unterstuetzt Policy-Kategorien fuer thematische Gruppierung
  • Audit-faehiges Protokoll aller Policy-Zustandsaenderungen
# Policy-Kategorie "Security" auf SQL01 aktivieren
Set-sqmSqlPolicyState -SqlInstance "SQL01" -PolicyCategory "Security" -State "Enabled"

# Einzelne Policy deaktivieren
Set-sqmSqlPolicyState -SqlInstance "SQL01" -PolicyName "SA Account Disabled" -State "Disabled"

Test-sqmSQLFirewall - SQL Server Port-Erreichbarkeit PowerShell testen: TCP 1433, Named Pipes, dynamische Ports

Was macht die Funktion?

Testet die Netzwerkerreichbarkeit einer SQL Server Instanz von einem Client-System aus: TCP-Port 1433, Named Pipes, UDP-Port 1434 (SQL Browser) und dynamisch zugewiesene Ports. Zeigt detaillierte Diagnoseinformationen bei Verbindungsfehlern und unterstuetzt Tests von mehreren Quell-IPs.

Wann nutzt man sie?

Bei der Ersteinrichtung neuer SQL Server Instanzen zur Verifikation der Firewall-Regeln. Bei Applikations-Verbindungsproblemen zur schnellen Diagnose ob ein Netzwerkproblem vorliegt. Nach Firewall-Aenderungen zur Bestaetigung dass SQL Server weiterhin erreichbar ist.

Typische Probleme

  • SQL Server laeuft aber Firewall blockiert Port 1433 - Verbindungsfehler ohne klare Ursache
  • SQL Browser-Dienst gestoppt - Named Instances nicht erreichbar
  • Dynamisch zugewiesener Port aendert sich nach Neustart - Firewall-Regel veraltet

Vorteile

  • Schnelle Diagnose ob Verbindungsproblem Netzwerk, Firewall oder SQL Server ist
  • Zeigt dynamisch zugewiesene Ports zur Validierung von Firewall-Regeln
  • Unterstuetzt Tests von mehreren Client-IPs gleichzeitig
# Firewall-Test fuer SQL Server Instanz
Test-sqmSQLFirewall -SqlInstance "SQL01"

# Test mit spezifischem Port und Named Instance
Test-sqmSQLFirewall -SqlInstance "SQL01\INSTANZ01" -Port 1433 -TestNamedPipes

Get-sqmSpnReport - SQL Server SPN-Bericht PowerShell: fehlende, falsche und doppelte SPNs identifizieren

Was macht die Funktion?

Erstellt einen vollstaendigen SPN-Bericht fuer SQL Server Service Accounts: fehlende SPNs (Kerberos schlaegt fehl), falsche SPNs (falscher Account oder Port) und doppelte SPNs (Authentifizierungsprobleme). Zeigt auch welche SPNs gesetzt werden muessen und mit welchem SETSPN-Befehl.

Wann nutzt man sie?

Bei Kerberos-Authentifizierungsfehlern zur Diagnose ob SPNs korrekt gesetzt sind. Nach dem Wechsel von SQL Server Service Accounts wenn alte SPNs geloescht und neue gesetzt werden muessen. Bei der Einrichtung neuer SQL Server Instanzen zur Verifikation der SPN-Konfiguration.

Typische Probleme

  • Kerberos-Fehler in Event Log ohne klare Ursache - SPNs fehlen oder sind falsch
  • Service Account Wechsel ohne SPN-Cleanup - doppelte SPNs fuehren zu Authentifizierungsfehlern
  • Linked Server Verbindungen schlagen fehl weil Kerberos-Delegation nicht funktioniert

Vorteile

  • Vollstaendige SPN-Analyse in einem Bericht statt manueller SETSPN-Abfragen
  • Zeigt direkt den korrekten SETSPN-Befehl zur Behebung jedes Problems
  • Erkennt doppelte SPNs die zu intermittierenden Authentifizierungsfehlern fuehren
# SPN-Report fuer alle SQL-Instanzen auf einem Server
Get-sqmSpnReport -ComputerName "SQL01"

# SPN-Report fuer spezifischen Service Account
Get-sqmSpnReport -ServiceAccount "DOMAIN\sql_svc_prod"

Get-sqmHpuAllowGroup - HPU-Allow-Gruppe fuer SQL Server aus Domain-Mapping ermitteln PowerShell

Was macht die Funktion?

Ermittelt die korrekte HPU-Allow-Gruppe (High Privileged User) fuer einen SQL Server aus einem konfigurierten Domain-Server-Mapping. Die Funktion liest das Mapping aus der sqmSQLTool-Konfiguration und gibt die zustaendige AD-Gruppe zurueck, die fuer den Server Sysadmin-Zugang hat.

Wann nutzt man sie?

Bei der Einrichtung neuer SQL Server Instanzen um die korrekte HPU-Gruppe automatisch zuzuweisen. Im Rahmen von Login-Audits zur Verifikation ob die richtigen AD-Gruppen in der Sysadmin-Rolle sind. Als Bestandteil von Onboarding-Skripten fuer neue SQL Server.

Typische Probleme

  • Falsche HPU-Gruppe zugewiesen - Admins haben keinen Zugang oder zu viele Personen haben Zugang
  • Manuelles Nachschlagen im Domain-Mapping fehleranfaellig bei vielen Domains
  • Keine automatisierte Pruefung ob die richtige HPU-Gruppe gesetzt ist

Vorteile

  • Automatisches Lookup eliminiert manuelle Fehler bei der Gruppenzuweisung
  • Konsistente Zuordnung in Multi-Domain-Umgebungen
  • Integrierbar in automatisierte Onboarding-Workflows fuer neue Instanzen
# HPU-Allow-Gruppe fuer SQL01 ermitteln
Get-sqmHpuAllowGroup -ComputerName "SQL01"

# HPU-Gruppe ermitteln und direkt als Login hinzufuegen
$hpuGroup = Get-sqmHpuAllowGroup -ComputerName "SQL01"
Add-DbaServerRoleMember -SqlInstance "SQL01" -ServerRole "sysadmin" -Login $hpuGroup
Zurueck zum Index