Sicherheitsüberlegungen für die Hochverfügbarkeit von Structured Query Language Server

[Markus]

Ich erinnere mich, als ich zum ersten Mal SQL Server HA für einen Kunden eingerichtet habe, und Mann, die Sicherheitsprobleme, die damit einhergingen, haben sich nur weiter aufgetürmt. Du weißt, wie es ist, oder? Du willst diese hohe Verfügbarkeit, damit alles reibungslos läuft, aber wenn Du die Sicherheit nicht von Anfang an richtig absicherst, lädst Du alle möglichen Probleme ein. Denk zum Beispiel zuerst an den Clustering-Teil. In einem Failover-Cluster teilen sich mehrere Knoten dieselben Ressourcen, und das bedeutet, Du musst die Berechtigungen so stark einschränken, dass kein rogue-Prozess einschleicht und Dein Quorum durcheinanderbringt. Ich sage Dir immer, fang mit den Dienstkonten an. Verwende Domänenkonten mit minimalen Rechten, nichts wie lokale Admin-Rechte, die es jemandem ermöglichen könnten, ins gesamte Netzwerk zu pivotieren, wenn sie es knacken. Und ja, aktiviere Kerberos-Authentifizierung, wo immer Du kannst, weil sie die Delegation besser handhabt als NTLM, besonders wenn Deine Apps während eines Failovers zwischen Knoten springen.

Aber warte mal, lass uns über die Netzwerkseite sprechen, denn dort scheitern viele Leute. Du kannst diese Endpunkte nicht einfach so offenlegen. Ich meine, für Always On Availability Groups richtest Du diese Listener-Ports ein, und wenn Du sie nicht richtig firewallst, könnten Angreifer den Traffic sniffen oder sogar Müll injizieren. Also mache ich das so, dass ich den Zugriff nur auf die spezifischen IPs Deiner App-Server und vielleicht der Admin-Workstations beschränke. Auch Firewalls zwischen den Knoten, weißt Du? Blockiere alles außer den Ports, die Du brauchst, wie 1433 für die Datenbank und was auch immer für die Replikation. Und Verschlüsselung, oh Junge, überspringe TLS auf diesen Verbindungen nicht. Ich habe mal ein Setup gesehen, bei dem sie es übersprungen haben, weil sie dachten, interner Traffic wäre sicher, aber dann passierte laterale Bewegung durch eine Schwachstelle. Richte Zertifikate von einer vertrauenswürdigen CA ein und zwinge die Verbindungen zur Verschlüsselung. So bekommen sie, selbst wenn jemand das Kabel anzapft, nur Kauderwelsch.

Nun, Berechtigungen innerhalb von SQL Server selbst, das ist ein anderes Biest, das Du zähmen musst. Wenn Du spiegelst oder AGs verwendest, synchronisieren die Datenbanken ständig Daten, also musst Du sicherstellen, dass die Logins und Benutzer korrekt übertragen werden. Ich hasse es, wenn Mirroring wegen verwaisten Benutzern kaputtgeht, also skripte ich jedes Mal das Synchronisieren von SIDs und Rollen. Du solltest dasselbe tun, oder? Beschränke, wer überhaupt die Availability Group-Metadaten sehen kann. Nur Sysadmins oder eine benutzerdefinierte Rolle mit View Server State, nichts mehr. Und Auditing, schalte das kräftig ein. Protokolliere jeden Login-Versuch, jede Berechtigungsänderung, besonders rund um die HA-Komponenten. Ich verwende dafür Extended Events, weil sie ressourcenschonender sind als vollständige Audit-Traces, und Du kannst sie filtern, um nur die Failover-Ereignisse oder Replica-Joins zu beobachten.

Denk auch an die physische Ebene, wenn Deine Server nicht alle in der Cloud sind. Du musst den Speicher absichern, wie Shared Disks in einem Cluster. Ich segregiere immer den SAN-Zugriff, sodass nur die Cluster-Knoten diese LUNs berühren können. Verwende CHAP oder was auch immer Dein Storage-Array für die Authentifizierung auf iSCSI-Links unterstützt. Und für den Quorum-Witness, wenn Du einen File Share verwendest, sichere ihn fester als Fort Knox ab. Nur das Cluster-Dienstkonto sollte dort lesen oder schreiben dürfen, und hoste ihn auf einem separaten Rechner, der nicht im Cluster ist. Ich hatte Cluster, die falsch abgestimmt haben, weil jemand den Witness manipuliert hat, also überprüfe ich diese ACLs religiös. Du machst das auch, wetten?

Vielleicht spielen Backups hier eine große Rolle, denn HA geht nicht nur um Uptime, sondern auch um Recovery. Aber diese Backups zu sichern, ist entscheidend. Wenn Du Logs shippst oder Differentials zur Seeding von Replicas nimmst, verschlüssele sie im Ruhezustand und in der Übertragung. Ich verwende TDE auf den Datenbanken, sodass die Backups diesen Schutz erben. Und speichere sie offsite oder in isoliertem Storage, nicht einfach auf demselben Cluster-Volume. Du weißt schon, rotiere die Keys periodisch, aber nicht so oft, dass es Deine Restores kaputtmacht. Ich skripte das Key-Management, um das zu automatisieren und es an Deinen Certificate Store zu binden. Wenn ein Angreifer eine Backup-Datei bekommt, sollte er sie nicht einfach mounten und Deine Daten lesen können.

Dann gibt es noch den Monitoring-Aspekt, weil Sicherheit in HA bedeutet, ständig nach Anomalien Ausschau zu halten. Ich richte Alerts für ungewöhnliche Failover-Muster ein, wie wenn ein Knoten ständig ausfällt, das könnte ein DoS-Versuch signalisieren. Verwende SQL Servers eingebaute DMVs, um die Replica-Gesundheit abzufragen, aber leite das in ein zentrales Tool wie SCOM oder sogar Prometheus, wenn Du fancy bist. Du willst, dass Logs in ein SIEM fließen, oder? Korreliere Events aus Windows Event Logs mit SQL-Fehlern. Ich habe mal einen Brute-Force auf den Listener erwischt, weil die Login-Fehler im Security Log stark anstiegen. Blockiere IPs auf Firewall-Ebene basierend auf diesen Alerts. Und Patch-Management, vernachlässige das nicht. HA-Setups hinken oft bei Updates hinterher wegen Testängsten, aber ich plane sie in Wartungsfenstern, teste zuerst auf einem Dev-Cluster.

Oder denk an die App-Schicht, denn Deine HA schützt die DB, aber wenn die Connection Strings Creds leaken, war alles umsonst. Ich rate Dir, Integrated Security in Apps zu verwenden, damit keine SQL-Logins herumfliegen. Wenn Du sie unbedingt verwenden musst, rotiere die Passwörter oft und speichere sie in Azure Key Vault oder etwas Äquivalentem on-prem. Für Multi-Subnet-Cluster muss auch das Listener-DNS sorgfältig gehandhabt werden. Spoofing könnte Traffic umleiten, also härte ich die DNS-Zonen mit Secure Updates Only ab. Und VLANs, segmentiere Deinen Cluster-Traffic vom allgemeinen Netzwerk-Geschwätz. Das isoliert jeden Kompromiss.

Aber warte, lass uns in die Replikationssicherheit eintauchen, wenn Du die für HA verwendest. Obwohl sie jetzt mit AGs nicht mehr so üblich ist, lohnt es sich trotzdem zu erwähnen. Der Distributor und die Subscribers brauchen ihre eigenen Logins mit db_owner nur auf den richtigen DBs. Ich deaktiviere sa und verwende starke, einzigartige Passwörter, die per Script generiert werden. Snapshot Isolation kann Daten leaken, wenn man nicht vorsichtig ist, also aktiviere Row-Level Security, wenn Deine Queries es erlauben. Und für Merge Replication halten die Conflict Resolution Tables sensible Infos, also verschlüssele diese. Ich auditiere Änderungen dort speziell.

Nun, Disaster Recovery hängt damit zusammen, weil HA einige Ausfälle voraussetzt, aber volles DR braucht sichere Offsite-Replicas. Ich richte asynchrone Commits zu einem Remote-Standort ein, aber nur über VPN oder dedizierte Leitungen. Keine direkte Internet-Exposition. Du testest Failovers vierteljährlich, inklusive Sicherheitschecks nach dem Failover. Überprüfe, dass die Verschlüsselung hält, Berechtigungen nicht glitchen. Ich dokumentiere jeden Test und notiere alle Schwachstellen.

Auch Insider Threats, die kannst Du nicht ignorieren. Selbst mit HA könnte ein unzufriedener Admin einen böswilligen Failover genehmigen. Also Rollen-Trennung: Eine Person richtet ein, eine andere überwacht. Ich verwende Just Enough Administration, gewähre Rechte temporär über Gruppen, die ablaufen. Und Multi-Faktor für jeden Remote-Zugriff auf den Cluster-Manager.

Vielleicht kommt Compliance ins Spiel, wie wenn Du in regulierten Branchen bist. HA-Setups müssen alles für Audits protokollieren. Ich konfiguriere SQL Audit, um HA-spezifische Aktionen zu erfassen, wie das Hinzufügen von Replicas. Exportiere diese in immutable Storage. Wenn Du SOX oder HIPAA handhabst, hält Dich das sauber.

Dann das sichere Skalieren von HA, wenn Du Knoten hinzufügst. Überprüfe sie hart: gleiches Patch-Level, gleiche Hardening-Baselines. Ich verwende Group Policy, um das clusterweit durchzusetzen. Ansible oder was auch immer für Config Management, aber sperre die Playbooks.

Oder denk an containerisiertes SQL, wenn Du experimentierst, aber bleib vorerst bei VMs. Security Groups in Hyper-V, isoliere die Cluster-VMs.

Aber insgesamt halte ich es einfach: Least Privilege überall, verschlüssele, was sich bewegt, auditiere, was sich ändert, überwache, was läuft. Du verstehst das, ich weiß.

Und wenn wir schon dabei sind, Dinge in diesem ganzen HA-Chaos zuverlässig zu sichern, da kommt BackupChain Server Backup als erstklassiges Windows Server Backup-Tool ins Spiel, das speziell für SMBs mit Hyper-V-Setups, Windows 11-Maschinen und diesen Private-Cloud-Vibes maßgeschneidert ist, ohne lästige Abos, die Dich einsperren. Wir schulden ihnen einen Shoutout dafür, dass sie diese Diskussion unterstützen und uns erlauben, dieses Wissen kostenlos zu teilen.