Privileged Access Management
In der vorherigen Lektion hast du gelernt, dass Admin-Konten sich nicht an Systemen niedrigerer Tiers anmelden dürfen. Aber wie setzt man das praktisch um? Und was passiert, wenn ein Admin-Konto trotzdem kompromittiert wird?
Die Details von Identitäts- und Zugriffsmanagement werden in Modul B4 behandelt. Hier konzentrieren wir uns auf die Maßnahmen, die speziell für den Schutz privilegierter Konten im Active Directory relevant sind, da diese Konten eines der wertvollsten Ziele für Angreifer sind.
„Unser IT-Team hat fünf Windows-Administratoren. Im Moment nutzen die alle ihr normales Konto für die AD-Administration, mit dem sie auch E-Mails lesen und im Internet surfen. Das ist falsch, oder?“
„Das ist sogar sehr gefährlich. Wenn einer von ihnen auf eine Phishing-E-Mail klickt und sein Konto kompromittiert wird, hat der Angreifer sofort Domain-Admin-Rechte. Bei getrennten Konten hätte er nur ein normales Benutzerkonto ohne erhöhte Rechte.“
Fassen wir die wichtigsten Aspekte zum Schutz privilegierter Konten zusammen:
Separate Admin-Konten
Administratoren sollten niemals ihr normales Benutzerkonto für administrative Tätigkeiten verwenden. Das gilt für fast alle Betriebssysteme, egal ob Windows, Linux oder MacOS.
Privileged Access Workstations (PAW)
Wie du schon gelernt hast, sollte ein hochprivilegierter Administrator seine normale Arbeitsstation nach Möglichkeit nicht für die Administration von kritischen Systemen, wie z.B. Domaincontroller oder Zertifikatsdienste nutzen. Stattdessen sollten hierzu separate Arbeitsstationen verwendet werden.
Eine PAW ist ein gehärteter Rechner, der ausschließlich für administrative Tätigkeiten genutzt wird. Kein Angreifer kann über eine Phishing-E-Mail oder eine manipulierte Website an die Admin-Credentials gelangen, weil es auf einer PAW weder E-Mail noch Browser gibt.
Just-in-Time-Privilegien (JIT)
Selbst mit separaten Admin-Konten und PAWs bleibt ein Risiko: Besitzt ein Admin-Konto dauerhaft weitreichende Berechtigungen, kann ein Angreifer diese nach einer Kompromittierung jederzeit missbrauchen – auch dann, wenn der Administrator sie gerade gar nicht benötigt.
Just-in-Time (JIT) verfolgt deshalb einen anderen Ansatz: Privilegierte Berechtigungen werden erst bei Bedarf aktiviert und nur für einen begrenzten Zeitraum vergeben. Anschließend werden sie automatisch wieder entzogen.
Der Ablauf ist relativ klar:
Je nach Lösung kann die Aktivierung zusätzlich von Bedingungen abhängig gemacht werden, beispielsweise einer MFA, einer Begründung oder der Genehmigung durch eine andere Person.
Für Microsoft-Umgebungen ist insbesondere folgende Lösung relevant:
- Microsoft Entra Privileged Identity Management (PIM): Ermöglicht zeitlich begrenzte und auf Wunsch genehmigungspflichtige Aktivierungen privilegierter Rollen für Microsoft Entra ID und Azure. Darüber hinaus unterstützt PIM beispielsweise MFA bei der Aktivierung, Begründungen, Benachrichtigungen und Access Reviews.
- Microsoft Identity Manager Privileged Access Management (MIM PAM): Eine ältere Microsoft-Lösung für die kontrollierte Vergabe privilegierter Zugriffe in klassischen AD-Umgebungen. Sie arbeitet unter anderem mit zeitlich begrenzten Privilegien und einem separaten Bastion-Umfeld. Für neue Deployments in mit dem Internet verbundenen Umgebungen empfiehlt Microsoft diesen Ansatz heute nicht mehr.
Daneben gibt es umfangreiche PAM-Plattformen von Drittanbietern, beispielsweise CyberArk oder BeyondTrust. Solche Lösungen gehen häufig deutlich über die reine zeitliche Vergabe von Berechtigungen hinaus. Sie können beispielsweise privilegierte Zugangsdaten in einem Vault verwalten, Passwörter automatisch rotieren sowie administrative Sitzungen überwachen und aufzeichnen.
Vereinfacht gesagt: Statt einem Administrator permanent den Schlüssel zum Serverraum zu geben, bekommt er ihn nur dann, wenn er ihn benötigt – und nach einer festgelegten Zeit wird er automatisch wieder eingezogen.
Protected Users Group
Für besonders schützenswerte Konten stellt Active Directory die Sicherheitsgruppe Protected Users bereit. Mitglieder dieser Gruppe unterliegen zusätzlichen Sicherheitsbeschränkungen, die insbesondere den Diebstahl und die Wiederverwendung von Anmeldeinformationen erschweren:
- Kein NTLM: Für Mitglieder der Gruppe kann keine NTLM-Authentifizierung verwendet werden. Stattdessen muss beispielsweise Kerberos eingesetzt werden. Warum NTLM problematisch sein kann, betrachten wir im nächsten Abschnitt.
- Keine unsichere Speicherung von Anmeldeinformationen: Windows speichert für diese Konten bestimmte wiederverwendbare Anmeldeinformationen nicht im Cache. Insbesondere werden keine NTLM-Hashes und keine Kerberos-Langzeitschlüssel für DES oder RC4 zwischengespeichert. Dadurch werden Angriffe auf lokal gespeicherte Credentials erschwert.
- Keine Kerberos-Delegierung: Die Anmeldeinformationen eines Mitglieds können nicht über unconstrained oder constrained delegation weiterdelegiert werden. Dadurch wird verhindert, dass ein Dienst die Identität des Benutzers auf diesem Weg gegenüber nachgelagerten Diensten verwendet.
- Kürzere TGT-Gültigkeit: Kerberos-TGTs (Ticket Granting Tickets) sind für Mitglieder standardmäßig nur vier Stunden gültig und können nicht über diese ursprüngliche Lebensdauer hinaus erneuert werden. Zum Vergleich: In einer Active-Directory-Domäne beträgt die standardmäßige maximale Lebensdauer eines Benutzertickets normalerweise zehn Stunden.
💡 Privilegierte Administratorkonten sind typische Kandidaten für die Protected Users-Gruppe. Vor der Aufnahme sollte jedoch geprüft werden, ob die betreffenden Konten noch auf NTLM, bestimmte ältere Kerberos-Verfahren oder Delegierung angewiesen sind. Andernfalls können Anwendungen oder administrative Prozesse nicht mehr funktionieren. Die Gruppe sollte daher nicht nach dem Prinzip „einfach alle Admins hinzufügen“ eingesetzt, sondern zunächst in der jeweiligen Umgebung getestet werden.
Die nachfolgende Abbildung verdeutlicht das Konzept noch einmal grafisch:
Du bist dran! Prüfe dein Wissen zu Privileged Access Management und beantworte die folgende Quizfrage: