In diesem Teil unserer ESAE-Blogserie nehmen wir die Anforderungen aus dem ersten Teil auf. Wir zeigen, welche Maßnahmen konkret getroffen wurden, um die kritischen Systeme zu schützen.
Ein Gastbeitrag der Teal Technology Consulting
Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie alle Teile nacheinander lesen.
-
- Teil 1: Basics & Architekturplanung
- Teil 2: Privileged Access Management & Shadow Principals
- Teil 3: Schutzmaßnahmen für die Umgebung (dieser Beitrag)
- Teil 4: Windows IPSec im Detail erklärt
- Teil 5: Die ESAE-Architektur von Microsoft
- Teil 6: ESAE ist tot, lang lebe SAE!
Das bietet dieser Teil der ESAE-Serie:
Die Tier-Klassifizierungen
Bevor wir mit den Anforderungen loslegen, muss klar sein, welche Systeme als Tier 0, Tier 1 und Tier 2 klassifiziert sind. Diese Definition kann je nach Kunde und Situation unterschiedlich ausfallen.
Der Scope des konkreten Kunden-Szenarios war der Global Authentication Service (GAS), nicht direkt alle Kunden-Systeme. Deshalb haben wir eine etwas von der Microsoft-Definition abweichende Einteilung gewählt:
Hier als kleinen Recap noch einmal die Anforderungen aus Teil 1:
Schichtentrennung und Least Privilege Administration
-
-
- Physische und logische Trennung der Tier-0-Systeme von Tier 1 und 2
- Keine Nutzung von Tier-1- und Tier-2-Services, die ein Tier-0-System kompromittieren könnten (bspw. Monitoring-Agent)
- Zugriffsbeschränkung auf Konten: Administration nur auf gleichem Tier, kein Log-in auf niedrigerem Tier.
-
-
-
- Principle of Least Privilege mit Just in Time Administration
-
Härtung
-
-
- Hardening aller Systeme nach Best Practice
- Administrativen Zugriff nur über gehärtete Privilege-Admin-Workstations mit Multi-Faktor- Authentifizierung
- Verschlüsselung der Festplatten
- Installation nur von vertrauenswürdigen Quellen (Hash-Kontrolle)
- Lange Passwörter mit kurzen Laufzeiten. Für Dienst-Konten möglichst Group Managed Service Accounts
-
Prozesse und Betrieb
-
-
- Reduktion der Tier-0-Administratoren auf ein Minimum
- Gut ausgebildetes Personal mit positivem Führungszeugnis
-
Anforderungen und Maßnahmen
Nachfolgend werden die Anforderungen und Maßnahmen dargestellt, aus Gründen der Übersichtlichkeit in tabellarischer Form. Da sich aus einigen Formulierungen mehrere Anforderungen ableiten und auch einige kundenspezifische Rahmenbedingungen gegeben waren, sind es schlussendlich mehr Anforderungen als die Anzahl von Bulletpoints oben.
A1: Physische Trennung
M 1: Die Systeme müssen in einem eigenen Datacenter/Raum/Rack mit entsprechender Zugangskontrolle aufgebaut werden. Im konkreten Kundenszenario wurde das Hosting bei einem Co-Location-Anbieter vorgegeben. Zugang zum Rack haben nur Tier-0-Administratoren.
Aus der Entscheidung, die Systeme bei einem Co-Location-Anbieter zu hosten (der naturgemäß physischen Zugang zu den Systemen hat), ergibt sich eine weitere Anforderung.
A2: Verschlüsselung aller Festplatten der Hyper-V-Hosts
M2: Glücklicherweise liefert Microsoft mit Bitlocker direkt das passende Tool als Teil des Betriebssystems mit. Die Recovery Keys wurden zur Sicherheit im AD und in einem Passwortsafe gespeichert.
A3: Logische Trennung
M3: Aufgrund der im Projekt getroffenen Einteilung in die Tiers wurde die Anforderung wie folgt umgesetzt: Tier-0- und Tier-1-Systeme sind durch eine Firewall von allen anderen Systemen getrennt. Die Firewall darf natürlich auch nur durch einen Tier-0-Administrator betrieben werden.
Bei unserem Kunden war allerdings die Entscheidung gesetzt, das komplette Netzwerk für GAS von einem Provider betreiben zu lassen. Damit dieser keine sensiblen Daten abgreifen oder die Systeme kompromittieren kann, ergeben sich weitere Anforderungen.
A4: Verschlüsselung von jeglichem Netzwerkverkehr innerhalb der GAS-Umgebung
M4: Um sich nicht mit den verschiedenen Verschlüsselungsmöglichkeiten auf Applikationsebene auseinandersetzen zu müssen, wurde die Anforderung durch Windows-IPSec-Verschlüsselung konfiguriert und per Gruppenrichtlinien umgesetzt.
A5: Keine Nutzung von Tier-1- und Tier-2-Services, die ein Tier-0-System kompromittieren könnten
M5: Diese Anforderung hat dazu geführt, dass eigens für GAS ein WSUS und ein SCOM implementiert wurden.
A6: Zugriffsbeschränkung der Konten (Administration nur auf gleichem Tier. Kein Log-in auf niedrigerem Tier)
M6: Für jedes Tier wurden entsprechende Admin-User angelegt. Darf eine Person (aufgrund des kleinen Scopes) sowohl CSI-Tier-0- als auch CSI-Tier-1-Systeme administrieren, wurden für diese Person entsprechend zwei Konten angelegt.
A7: Principle of Least Privilege mit Just in Time Administration
M7: Hierfür wurde der in Teil 1 unserer Blog-Serie ausführlich beschriebene Admin Forest mit MIM-PAM und entsprechenden Berechtigungsrollen aufgebaut.
A8: Härtung aller Systeme nach Best Practice
M8.1: Wann immer möglich wurden die Systeme in der Core Variante installiert.
M8.2: Es wurden die GPOs der Security Baseline für Windows Server 2016 implementiert. Schon in der Baseline wurden einige Services deaktiviert. Nachfolgende, ebenfalls nicht benötigte Services, mussten per Registry Key deaktiviert werden:
HKLM\System\CurrentControlSet\Services\CDPUserSvc HKLM\System\
HKLM\System\CurrentControlSet\Services\OneSyncSvc
HKLM\System\CurrentControlSet\Services\OneSyncSvc<random number>CurrentControlSet\Services\CDPUserSvc<random number>
HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc
HKLM\System\CurrentControlSet\Services\PimIndexMaintenance
HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc
HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc<random number>eSvc<random number>
A9: Administrativer Zugriff nur über gehärtete Privilege Admin Workstations mit Multi-Faktor- Authentifizierung
M9.1: Es wurden eigens für den Zweck der Administration der GAS-Umgebung Notebooks angeschafft
M9.2: Es wurden die GPOs der Security Baseline für Windows 10 implementiert.
M9.3: In unserem Kundenszenario dient ein Zertifikat plus Username/Passwort, welches von der VPN Appliance in GAS überprüft wird, als zweiter Faktor.
A10: Verschlüsselung der Festplatten
M10: Alle Festplatten (OS plus Daten) aller Systeme (Hosts, VMs, PAWs) wurden mittels Bitlocker verschlüsselt.
A11: Installation nur von vertrauenswürdigen Quellen (Hash Kontrolle)
M11: Bei der Installation aller Komponenten wurde das Clean Source Prinzip angewandt. Das heißt, entweder wurde der vom Hersteller veröffentlichte Hash überprüft; oder die Datei wurde zwei Mal über unterschiedliche Netzwerkstrecken auf verschiedenen Endgeräten heruntergeladen und der Hash verglichen. Letzteres bietet natürlich keinen Schutz vor bereits kompromittierten Dateien auf dem Quellserver, verhindert aber zumindest eine Kompromittierung auf der Wegstrecke.
A12: Lange Passwörter mit kurzen Laufzeiten. Für Dienstkonten möglichst Group Managed Service Accounts
M12:
-
-
- CSI Tier 0 Accounts: 20 Zeichen, 60 Tage Laufzeit
- CSI Tier 1 Accounts: 15 Zeichen, 60 Tage Laufzeit
- Service Accounts: 30 Zeichen, 200 Tage Laufzeit
-
A13: Reduktion der Tier-0-Administratoren auf ein Minimum
M13: Es wurde ein virtuelles Team aus mehreren Organisationseinheiten gebildet, welches vollumfänglich für die GAS-Umgebung zuständig ist. Dadurch wird vermieden, dass durch die klassische Trennung der Verantwortlichkeit – bspw. in Betriebssystem-, Datenbank- und Applikationsadministratoren – zu viele Personen zu Tier-0-Administratoren werden.
A14: Gut ausgebildetes Personal mit positivem Führungszeugnis
M14: Für das virtuelle Team hat man nur langjährige Mitarbeiter ausgewählt, welche speziell für die Administration der GAS-Umgebung geschult wurden.
Nachfolgend listen wir noch einige weitere Anforderungen und Maßnahmen auf, die wir aus Gründen der Übersicht in Teil 1 unserer Blog-Serie nicht genannt haben, hier aber nicht fehlen dürfen.
A15: Weiterleitung relevanter Logs in das zentrale Log-Management-System zur Auswertung mittels des Security Information and Event Management (SIEM)
M15: Um die Logs innerhalb von GAS zu sammeln, werden diese per Windows EventLog Forwarding an einen NXLog Server innerhalb von GAS geschickt (Source Computer initiated), welcher die Logs gesammelt an das zentrale Log-Management weiterleitet. Die Logging-Policy wird zentral mittels Group Policy / Subscription Manager konfiguriert.
A16: Backup RTO sind 4 Stunden, RPO für das AD ist 1 Tag, für alle anderen Systeme eine Woche
M16: Als Anforderung nicht sonderlich spannend, jedoch in der Umsetzung im Kontext CSI nicht trivial. Die Enterprise-Backup-Lösung ist kein CSI-Tier-0-System. Es ist nicht in der Lage, die Backups so zu verschlüsseln, dass die Schlüssel nur den CSI-Tier-0-Administratoren bekannt sind.
Eine eigene Backup-Infrastruktur nur für GAS aufzubauen war aus Kostengründen nicht möglich. Gelöst wurde die Fragestellung durch ein Scheduled Task. Dieser führt ein Script aus, das die Server mittels Windows-Server-Backup in eine VHD sichert, die VHD mittels Bitlocker verschlüsselt und auf einen Fileserver außerhalb der GAS Umgebung kopiert.
Die Anzahl der lokalen und entfernten Kopien ist natürlich konfigurierbar. Die Schlüssel werden durch die Administratoren der jeweiligen Komponente gemanagt und sind für jeden Server unterschiedlich.
A17: Installation aller Security-Patches innerhalb von 14 Tagen
M17: Da auch hier aus Kostengründen keine Management-Lösung ähnlich SCCM nur für GAS aufgebaut werden konnte, dient ein WSUS als Updatequelle. Die Server sind so konfiguriert, dass Updates automatisch heruntergeladen werden. So ist eine schnelle Installation durch die Administratoren möglich.
Die Updates der anderen Soft- und Hardwarehersteller müssen derzeit noch manuell geprüft und installiert werden.
Fazit
Die Liste der Maßnahmen zeigt, wie vielschichtig die Implementierung einer sicheren ESAE-ähnlichen Umgebung ist. Im nächste Teil der Serie schauen wir uns eine Maßnahme genauer an: die Verschlüsselung des Netzwerkverkehrs mittels IPSec.
Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie auch die folgenden Teile lesen:
Über den Autor:
Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.
Bilder: Pixabay, Microsoft, TEAL