Ein ISO 27001-zertifizierter mittelständisch geprägter Kunde in Bonn mit etwa 300 Mitarbeitern im Bereich Förderung im Sozialwesen, welcher bereits längere Zeit eine hybride Infrastruktur mit starkem SaaS-Fokus nutzt.

Zeitraum:

2024

Geleistete Personentage:

30 PT

Projekt:

In einem ersten Anforderungsworkshop und unter Berücksichtigung der Ergebnisse aus dem Pentesting ergaben sich folgende Maßnahmen/Vorgaben:

• Trennung der regulären Admin-Accounts von den regulären Accounts
• Verweigerung der Anmeldung an Domaincontrollern
• Festlegung maximale Sitzungszeiten
• Härtung der Server- und Clientinfrastruktur
• Einführung Ebenenmodell der Administration
• Trennung der Berechtigungen auf Dienstebene
• Rechtevergabe nach Notwendigkeit
• Einführung Jumphost-Topologie
• Einführung zentraler Logging-Server für Active Directory-Domänencontroller
• Automatisierung regelmäßiger Prozesse mit PowerShell
• spätere Anbindbarkeit an eine Identity Access Management-Lösung
• Betrieb der Umgebung durch den Kunden

Das Konzept sollte für den Auditor prüfbar und die technische Umsetzung für die einzelnen Forderungen dokumentiert werden.

Perspektivisch soll eine Identity- und Access Management-Lösung integriert werden, welche aber ebenfalls nur die Rechte erhalten soll, welche notwendig sind.

Der Kunde verfügt über ein Change Advisory Board (CAB). Dies bedingt eine Beschreibung der einzelnen Maßnahmen, eine Risikoanalyse und einen dokumentierten Rollback-Plan (sofern die Umsetzung scheitert) sowie eine Prüfung der genannten Punkte und Freigabe durch das CAB.

Im ersten Schritt wurden die Objektarten im Verzeichnisdienst definiert, sowie die für die administrativen Tätigkeiten notwendigen Attribute, Administrationsbereiche und Administrationsanwender.

Unterschieden wird zwischen Dienstadministration, Benutzeradministration und globalen Administrationsrechten.

Die neue Service-Struktur wurde definiert und die Berechtigungen hier entsprechend im Detail abgestimmt. Dienstadministratoren sollen folgende Tätigkeiten unter der jeweiligen Dienststruktur vornehmen können:

• Dienstaccount–Passwörter setzen
• Dienstaccounts deaktivieren
• Dienst-Computeraccounts zurücksetzen
• Dienst-Computeraccount deaktivieren
• Pflege der Ressourcengruppen-Mitgliedschaften

Auf Basis der Administrationsrollen und der Administrationsbereiche wurden die Schreibrechte für die ermittelten Attribute an Berechtigungsgruppen delegiert. Für verschiedene Dienste wurden die notwendigen Rechte auf Verzeichnisdienstattribute ermittelt und an Berechtigungsgruppen delegiert (z. B. Ferrari Fax, Tenfold IAM, Telefonie-Lösung, Local Administrator Password Solution, BitLocker-Management), sodass hier nicht domainweite Administrationsrechte notwendig werden.

Parallel wurden zu Beginn die Administratorrechte von den regulären Benutzeraccounts entfernt und die bisherigen Berechtigungen auf T0-Admin– (globale Administratorrechte im Verzeichnisdienst) oder sofern bereits anwendbar auf T1-Admin-Accounts (Dienstadministratoren) überführt.

Alle Services, auch organisatorische Services wurden erfasst und die Zuständigkeiten (technische/fachliche Zuständigkeit) dokumentiert. Ebenso wurden unternehmensweit gültige Dienstkürzel pro Dienst festgelegt.

Der Benutzer-Lifecycle wurde erarbeitet vom Onboarding bis zur Löschung und den Stakeholdern zur Freigabe vorgelegt und abschließend beschlossen.

Um eine einheitliche Verwaltung durch Skripte oder für das künftig einzuführende IAM-Produkt zu ermöglichen, ist eine einheitliche Namensstuktur notwendig, daher wurden die Namenskonventionen für die folgenden Objekte entsprechend definiert und dokumentiert:

• Dienste
• Benutzerkonten
• Dienstkonten
• Funktionsbenutzerkonten
• Ressourcengruppen
• Administrationsgruppen
• Rollengruppen
• Gruppenrichtlinien

Nach Festlegung der Parameter wurde ein Service-Onboarding-Skript erstellt, welches:

• die OU-Struktur
• Standard-Administrations-Gruppen (lokale Administratoren, Remotedesktopbenutzer, etc.)
• Gruppenrichtlinien
• Berechtigungen innerhalb der Unter-OU-Struktur
• Standard-Gruppenberechtigungen
  
  

anlegt bzw. vergibt. Das Skript erstellt die Objekte auf Basis der definierten Namenskonvention.
Hierdurch ist das Erstellen neuer Dienste binnen 10 Sekunden erledigt und standardisiert.

Die neue Servicestruktur stellt sicher, dass Ressourcenadministratoren über Gruppenrichtlinien innerhalb ihrer Service-Struktur über lokale Administratorrechte verfügen. Alle anderen Rechte werden regelmäßig automatisch entfernt oder müssen durch Delta-Richtlinien hinzugefügt werden.

Lokale Benutzerkonten sollen als Dienst- oder Funktionskonto aus dem Verzeichndisdienst in den Diensten neu referenziert werden. Lokale Benutzerkonten können vom zentralen Verzeichnisdienst nicht ausgewertet werden und sind daher nur in begründeten Ausnahmefällen erlaubt.

Nach Durchführung mehrerer Testszenarien für Service-Onboardings mit unkritischen Server-Diensten, wurde begonnen die Services in die neue Struktur umzuziehen. Hierfür wurden die lokal vergebenen Berechtigungen durch Verzeichnisdienstgruppen ersetzt und lokale Konfigurationen über Gruppenrichtlinien gesetzt. Die Tier1-Admin-Accounts der jeweiligen Service-Administratoren wurden als Ressourcenadministratoren definiert und die Handhabung der Administration geschult. Alle Maßnahmen wurden durch Changes über das CAB entsprechend eingereicht und dokumentiert, sodass alle Querschnittsdienstnutzer über mögliche Auswirkungen informiert waren.

Für das Logging der Änderungen im Active Directory wurde ein Logging-Server installiert und die Ereignisse entsprechend von den Domaincontrollern abonniert. Zur Wahrung der maximalen Vorhaltezeiten wurde ein PowerShell-Script für den automatischen Rollover entwickelt.
Der Logserver dient im Falle eines erfolgreichen Angriffs als Logbuch für den Angriffsverlauf auf die Identity-Systeme und kann hierdurch IT-Forensikern ermöglichen, die Qualität und vorallem die Quantität des Datenverlustes zu definieren.

Zusätzlich wurde Microsoft Defender for Identity nach Durchführung eines PoC flächendeckend ausgerollt um proaktiv Angriffe auf die Identity-Ressourcen erkennen zu können.

Von den Clients soll künftig keine Administration mehr erfolgen. Ein administrativer Zugriff muss künftig immer zwingend über eine Jumphost-Topologie erfolgen.

Nach Abwägung der Empfehlung von Nutzung Privileged Administration Workstations (PAW) gegenüber Remotedesktop-Server als Jumphosts, wurden die Fähigkeiten und Einschränkungen der Remotedesktop-Server festgelegt.

• keine lokalen Administratorrechte
• Remotedesktop-Sitzungsbeschränkungen
• Netzwerkeinschränkungen
• Jumphost pro Tierlevel
  
  

Auf den Jumphosts wurden die notwendigen Administrationswerkzeuge (z. B. Remote Server Administration Tools, Druckerverwaltung, Exchange Management Shell, DNS-, DHCP-Konsole) bereitgestellt, so dass eine einheitliche Administration erfolgen kann.

Der Datenaustausch zwischen den Servern erfolgt über einen Transfer-Fileserver, welcher ausnahmsweise von mehreren Tierleveln adressiert werden kann. Der Datenaustausch über die Remotedesktop-Zwischenablage ist grundsätzlich untersagt.

Die Umgebung wurde zum Abschluss nochmals von einem anderen Pentesting-Team über interne Ressource ausgehend „angegriffen„. Der Verzeichnisdienst hielt dem Angriff stand und der Umgebung wurde ein gutes Zeugnis ausgestellt.