Privileged Access Management (PAM): Admin-Konten unter Kontrolle

Warum privilegierte Accounts besondere Aufmerksamkeit verdienen

Nicht alle Benutzerkonten sind gleich. Ein normaler Mitarbeiteraccount hat Zugriff auf E-Mails, Dokumente und die Fachanwendungen, die er für seine tägliche Arbeit braucht. Wenn dieser Account kompromittiert wird, ist der Schaden begrenzt. Ein Domain-Admin-Account hingegen hat Zugriff auf das gesamte Active Directory, kann Benutzer anlegen und löschen, Gruppenrichtlinien ändern und auf jeden Server im Netzwerk zugreifen. Wenn dieser Account kompromittiert wird, hat der Angreifer die vollständige Kontrolle über die gesamte IT-Infrastruktur.

Diese Asymmetrie macht privilegierte Accounts zum bevorzugten Ziel von Angreifern. Der typische Angriffsverlauf beginnt mit einem kompromittierten Standardaccount, etwa über Phishing oder gestohlene Zugangsdaten. Von dort aus bewegt sich der Angreifer lateral durch das Netzwerk und sucht gezielt nach privilegierten Zugangsdaten. Techniken wie Pass-the-Hash, Kerberoasting oder die Extraktion von Credentials aus dem Speicher (Mimikatz) ermöglichen es, Admin-Rechte zu erlangen – ein typisches Szenario, das im Artikel zum kompromittierten Admin-Account detailliert beschrieben wird – ohne das eigentliche Passwort zu kennen. Sobald der Angreifer Domain-Admin-Rechte hat, kann er Backdoors einrichten, Daten exfiltrieren und Ransomware ausrollen.

Laut dem Verizon Data Breach Investigations Report involvieren über 80 Prozent aller Sicherheitsvorfälle, bei denen ein Angreifer tiefen Zugang erlangt, kompromittierte privilegierte Zugangsdaten. CrowdStrike berichtet, dass die durchschnittliche Breakout-Time, also die Zeit vom initialen Zugang bis zur lateralen Bewegung, bei unter 80 Minuten liegt. In dieser kurzen Zeit muss der Angreifer erkannt und gestoppt werden, bevor er privilegierte Rechte erlangt.

Was sind privilegierte Accounts?

Bevor du PAM einführen kannst, musst du verstehen, welche Accounts in deinem Unternehmen als privilegiert gelten. Die Liste ist oft länger als erwartet.

Domain-Administratoren haben vollständige Kontrolle über das Active Directory und damit über die gesamte Windows-Infrastruktur. Das umfasst die Mitglieder der Gruppen Domain Admins, Enterprise Admins und Schema Admins sowie den Built-in Administrator-Account.

Lokale Administratoren haben vollständige Kontrolle über einen einzelnen Server oder Arbeitsplatz. Der Built-in lokale Administrator-Account existiert auf jedem Windows-System und hat oft dasselbe Passwort auf vielen Systemen, was ihn zu einem besonders attraktiven Ziel macht.

Root-Accounts auf Linux- und Unix-Systemen haben uneingeschränkte Rechte auf dem jeweiligen System. Dazu gehören sowohl der direkte Root-Login als auch Accounts mit sudo-Rechten ohne Einschränkung.

Datenbank-Administratoren haben Zugriff auf die Datenbanken und damit auf die sensitivsten Daten des Unternehmens: Kundendaten, Finanzdaten, Personaldaten. Ein kompromittierter DBA-Account ermöglicht die Exfiltration ganzer Datenbanken.

Cloud-Administratoren verwalten die Cloud-Infrastruktur in Azure, AWS oder Google Cloud. Ein kompromittierter Cloud-Admin-Account kann virtuelle Maschinen erstellen, Daten kopieren oder die gesamte Cloud-Umgebung löschen.

Netzwerk-Administratoren konfigurieren Firewalls, Switches und Router. Mit diesen Rechten kann ein Angreifer Firewall-Regeln ändern, Traffic umleiten oder Netzwerksegmente zusammenlegen.

Anwendungs-Administratoren verwalten geschäftskritische Anwendungen wie ERP-Systeme, CRM-Plattformen oder HR-Software. Diese Accounts haben oft weitreichende Rechte innerhalb der Anwendung, einschließlich des Zugriffs auf alle Datensätze.

Service Accounts sind technische Konten, die von Anwendungen und Diensten für die Authentifizierung gegenüber anderen Systemen verwendet werden. Sie haben oft privilegierte Rechte, laufen rund um die Uhr und werden selten überprüft.

Die vier Säulen von PAM

Privileged Access Management ist kein einzelnes Tool, sondern ein Konzept, das mehrere Maßnahmen kombiniert. Die vier Säulen bilden zusammen einen umfassenden Schutz für privilegierte Zugänge.

Passwort-Vaulting

Die erste Säule ist die sichere Aufbewahrung privilegierter Zugangsdaten in einem zentralen, verschlüsselten Tresor (Vault). Statt Passwörter in Excel-Tabellen, Textdateien oder Notizzetteln zu speichern, werden sie in einem System abgelegt, das Zugriffskontrollen, Verschlüsselung und Audit-Logging bietet.

Das Prinzip ist einfach: Kein Administrator kennt das tatsächliche Passwort eines privilegierten Accounts. Wenn er Zugriff benötigt, checkt er das Passwort aus dem Vault aus, verwendet es für die Aufgabe und checkt es wieder ein. Der Vault protokolliert, wer wann welches Passwort ausgecheckt hat und wie lange es verwendet wurde.

In der einfachsten Form kann ein Passwort-Manager wie KeePass (lokal) oder Bitwarden (zentral) als Vault dienen. Für kleinere Unternehmen ist das ein akzeptabler Einstieg. Enterprise-PAM-Lösungen bieten darüber hinaus automatische Checkout/Checkin-Workflows, Genehmigungs-Workflows für den Zugriff und die Integration mit dem Ticketsystem.

Automatische Passwort-Rotation

Die zweite Säule ist die regelmäßige, automatische Änderung privilegierter Passwörter. Manuelle Passwortänderungen werden in der Praxis vergessen, verschoben oder mit vorhersehbaren Mustern durchgeführt. Automatische Rotation eliminiert diese menschlichen Schwächen.

Eine PAM-Lösung ändert das Passwort eines privilegierten Accounts nach einem definierten Zeitplan oder nach jeder Nutzung. Das Passwort wird automatisch generiert (lang, komplex, zufällig), im Vault gespeichert und auf dem Zielsystem geändert. Der Administrator muss nichts tun, weil er das Passwort ohnehin nicht kennt, sondern es bei Bedarf aus dem Vault auscheckt.

Für lokale Administrator-Accounts auf Windows-Systemen bietet Microsoft mit LAPS (Local Administrator Password Solution) eine kostenlose Lösung, die keine separate PAM-Software erfordert. LAPS generiert ein einzigartiges, zufälliges Passwort für den lokalen Administrator auf jedem System und speichert es im Active Directory (oder in Entra ID bei der neueren Version). Das Passwort wird regelmäßig automatisch rotiert, und der Zugriff auf die gespeicherten Passwörter wird über AD-Berechtigungen gesteuert.

Session Recording

Die dritte Säule ist die lückenlose Aufzeichnung privilegierter Sessions. Wenn ein Administrator eine Aufgabe auf einem kritischen System durchführt, wird die gesamte Session aufgezeichnet: Tastatureingaben, Bildschirminhalt und ausgeführte Befehle. Diese Aufzeichnungen dienen mehreren Zwecken.

Erstens ermöglichen sie die forensische Analyse bei Sicherheitsvorfällen. Wenn ein System kompromittiert wird, kannst du anhand der Session-Aufzeichnungen nachvollziehen, welche Aktionen durchgeführt wurden und ob sie von einem legitimen Administrator oder einem Angreifer stammen.

Zweitens schaffen sie Accountability. Wenn Administratoren wissen, dass ihre Aktionen aufgezeichnet werden, verhalten sie sich sorgfältiger und halten sich an die definierten Verfahren. Das ist kein Misstrauen, sondern ein Schutzmechanismus, der auch den Administrator selbst schützt: Wenn etwas schiefgeht, kann die Aufzeichnung belegen, dass er korrekt gehandelt hat.

Drittens unterstützen sie die Compliance. ISO 27001 fordert in Annex A.8.15 (Logging) die Protokollierung sicherheitsrelevanter Ereignisse. Session Recording für privilegierte Zugriffe ist eine der effektivsten Umsetzungen dieser Anforderung.

Für Unternehmen, die keine vollständige Session-Recording-Lösung einsetzen können, ist das Logging auf den Zielsystemen eine Alternative. PowerShell Transcription und Script Block Logging auf Windows, auditd auf Linux und die nativen Audit-Funktionen von Datenbanken und Cloud-Plattformen erfassen zumindest die ausgeführten Befehle.

Just-in-Time Access

Die vierte Säule ist der zeitlich begrenzte Zugriff. Statt permanente Admin-Rechte zu vergeben, die rund um die Uhr aktiv sind, werden Rechte nur bei Bedarf und für eine definierte Zeitspanne gewährt.

Der Ablauf funktioniert so: Der Administrator beantragt den Zugriff über ein Self-Service-Portal oder ein Ticketsystem. Die Anfrage wird automatisch oder manuell genehmigt. Die privilegierten Rechte werden für die beantragte Zeitspanne aktiviert. Nach Ablauf der Zeit werden die Rechte automatisch entzogen.

In Entra ID heißt diese Funktion Privileged Identity Management (PIM). PIM ermöglicht die zeitlich begrenzte Aktivierung von Entra-ID-Rollen (z. B. Global Administrator) und Azure-Ressourcen-Rollen. Die Aktivierung kann eine MFA-Abfrage, eine Begründung und eine Genehmigung durch einen zweiten Administrator erfordern.

Für On-Premise-Umgebungen lässt sich ein ähnliches Konzept mit temporären Gruppenmitgliedschaften im Active Directory umsetzen. Der Administrator wird für die Dauer der Aufgabe zur Admin-Gruppe hinzugefügt und nach Ablauf automatisch entfernt. PowerShell-Skripte oder PAM-Lösungen können diesen Prozess automatisieren.

Least Privilege: Das Fundament

Alle vier PAM-Säulen bauen auf dem Prinzip der minimalen Rechte (Least Privilege) auf. Dieses Prinzip besagt, dass jeder Benutzer, jeder Prozess und jedes System nur die minimalen Rechte erhalten soll, die für die jeweilige Aufgabe erforderlich sind.

In der Praxis bedeutet das eine grundlegende Veränderung: Administratoren arbeiten im Normalzustand mit einem Standardbenutzeraccount und wechseln nur bei Bedarf auf einen separaten Admin-Account. Dieser Admin-Account hat nur die Rechte, die für die spezifische Aufgabe erforderlich sind, nicht die Generalschlüssel-Rechte eines Domain Admins.

Die Umsetzung von Least Privilege beginnt mit der Inventarisierung. Wer hat welche privilegierten Rechte? Welche dieser Rechte werden tatsächlich benötigt? Die Erfahrung zeigt, dass bei dieser Analyse regelmäßig Überraschungen auftreten: Accounts mit Domain-Admin-Rechten, die seit Jahren nicht genutzt wurden, Mitarbeiter mit Admin-Rechten, die längst die Abteilung gewechselt haben, und Service Accounts mit weitreichenden Rechten, deren Zweck niemand mehr kennt.

Tiered Administration im Active Directory

Für Unternehmen mit Active-Directory-Infrastruktur ist das Tiered-Administration-Modell (auch Red Forest oder Enhanced Security Administrative Environment genannt) ein bewährter Ansatz, um privilegierte Zugriffe zu strukturieren. Das Modell teilt die Infrastruktur in drei Tiers auf.

Tier 0 umfasst die Identitätssysteme: Domain Controller, Entra Connect, PKI-Server, PAM-Server. Nur Tier-0-Administratoren dürfen auf diese Systeme zugreifen, und sie dürfen ihre Tier-0-Credentials niemals auf einem System der Tiers 1 oder 2 verwenden.

Tier 1 umfasst die Server-Infrastruktur: Dateiserver, Datenbankserver, Anwendungsserver. Tier-1-Administratoren verwalten diese Systeme, haben aber keinen Zugriff auf Tier-0-Systeme.

Tier 2 umfasst die Endgeräte: Arbeitsplatzrechner, Laptops, Drucker. Der lokale IT-Support verwaltet diese Geräte, hat aber keinen Zugriff auf Server oder Domain Controller.

Die strikte Trennung verhindert, dass ein Angreifer, der ein Endgerät (Tier 2) kompromittiert, direkt auf einen Domain Controller (Tier 0) zugreifen kann. Stattdessen muss er sich durch jedes Tier einzeln arbeiten, was die Angriffskette verlängert und mehr Gelegenheiten zur Erkennung bietet.

Die praktische Umsetzung erfordert separate Admin-Accounts für jedes Tier. Ein Administrator, der sowohl Server als auch Endgeräte verwaltet, hat drei Accounts: einen normalen Benutzeraccount für die tägliche Arbeit, einen Tier-1-Account für die Serververwaltung und einen Tier-2-Account für den Endgerätesupport. Die Tier-Trennung wird durch Group Policies durchgesetzt, die verhindern, dass ein Tier-0-Account sich auf einem Tier-2-System anmeldet und umgekehrt.

PAM ohne Enterprise-Lösung: Der pragmatische Einstieg

Nicht jedes Unternehmen kann oder will eine Enterprise-PAM-Lösung wie CyberArk, BeyondTrust oder Delinea einsetzen. Diese Lösungen kosten sechsstellige Beträge und erfordern dediziertes Personal für den Betrieb. Für ein mittelständisches Unternehmen mit 50 bis 500 Mitarbeitern gibt es einen pragmatischen Einstieg, der die wichtigsten PAM-Prinzipien umsetzt, ohne ein großes Budget zu erfordern.

Separate Admin-Accounts: Jeder Administrator erhält einen separaten Admin-Account, der nur für administrative Aufgaben verwendet wird. Der normale Benutzeraccount wird für E-Mails, Browsing und die tägliche Arbeit genutzt. Diese Trennung verhindert, dass ein Phishing-Angriff auf den Benutzeraccount direkt Admin-Rechte kompromittiert.

LAPS für lokale Administratoren: Microsoft LAPS sorgt dafür, dass jedes System ein einzigartiges, regelmäßig rotiertes Passwort für den lokalen Administrator hat. Die Einrichtung ist einfach und kostenlos.

MFA für alle privilegierten Zugriffe: Jeder Zugriff auf ein privilegiertes System erfordert einen zweiten Faktor. Das umfasst Remote-Desktop-Verbindungen zu Servern, den Zugriff auf das Azure/Entra-Portal, den Login auf Netzwerkgeräten und den Zugang zu Datenbank-Management-Tools.

Privileged Access Workstations (PAWs): Für Tier-0-Administratoren sollte ein dedizierter Arbeitsplatz eingerichtet werden, der ausschließlich für administrative Aufgaben genutzt wird. Kein E-Mail-Client, kein Browser, kein Internet-Zugang. In der Minimalvariante kann das eine gehärtete virtuelle Maschine sein, die nur über einen Jump-Server erreichbar ist.

Zentrales Logging: Alle Anmeldungen an privilegierten Systemen werden zentral protokolliert und regelmäßig überprüft. Windows Event Forwarding kann die relevanten Events von allen Servern an einen zentralen Collector senden.

Dokumentierte Break-Glass-Verfahren: Für den Notfall existieren versiegelte Umschläge mit den Zugangsdaten für die kritischsten Accounts. Die Umschläge werden sicher verwahrt, und jede Öffnung wird protokolliert und nachbereitet.

Rezertifizierung privilegierter Rechte

Privilegierte Rechte haben die Tendenz, sich über die Zeit anzusammeln. Ein Mitarbeiter erhält Admin-Rechte für ein Projekt, das Projekt endet, aber die Rechte bleiben bestehen. Ein anderer Mitarbeiter wechselt die Abteilung und behält seine alten Rechte zusätzlich zu den neuen. Nach einigen Jahren haben deutlich mehr Personen privilegierte Zugriffe als nötig.

Die Rezertifizierung ist der Prozess, bei dem alle privilegierten Rechte regelmäßig überprüft und bestätigt oder entzogen werden. ISO 27001 fordert in Annex A.5.18 eine regelmäßige Überprüfung der Zugangsrechte, und für privilegierte Rechte sollte diese Überprüfung in kürzeren Intervallen stattfinden als für normale Rechte.

Ein pragmatischer Rhythmus ist eine vierteljährliche Rezertifizierung der privilegierten Rechte. Der Prozess beginnt mit dem Export aller Mitglieder der privilegierten Gruppen aus dem Active Directory. Für jedes Mitglied wird geprüft: Ist der Mitarbeiter noch im Unternehmen? Benötigt er die Rechte noch für seine aktuelle Rolle? Ist das Tier korrekt? Der verantwortliche Vorgesetzte bestätigt oder widerruft die Rechte.

Automatisierung erleichtert diesen Prozess erheblich. Skripte können die Gruppenmitgliedschaften exportieren, Veränderungen seit der letzten Rezertifizierung hervorheben und die Ergebnisse dokumentieren. In ISMS Lite lässt sich der Rezertifizierungsprozess als wiederkehrende Aufgabe mit Verantwortlichem, Frist und Nachweis abbilden, sodass die Ergebnisse für den nächsten Audit griffbereit sind.

PAM in Cloud-Umgebungen

Cloud-Umgebungen bringen eigene Herausforderungen für PAM mit sich. Die privilegierten Accounts sind nicht mehr im lokalen Active Directory, sondern in der Cloud-Plattform. Die Zugriffsrechte sind feingranularer und komplexer, und die Angriffsfläche ist größer, weil der Zugriff von überall aus möglich ist.

In Azure/Entra ID bietet Privileged Identity Management (PIM) native PAM-Funktionen. PIM ermöglicht die zeitlich begrenzte Aktivierung von Rollen, erfordert MFA und Begründung bei der Aktivierung, sendet Benachrichtigungen an Reviewer und erstellt Audit-Logs aller Aktivierungen. PIM ist in Entra ID P2 enthalten und sollte für jede Azure-Umgebung aktiviert werden.

In AWS bietet der Identity and Access Management (IAM) Service ähnliche Konzepte. AWS Organizations und Service Control Policies begrenzen die maximal möglichen Rechte, IAM Roles ermöglichen die temporäre Übernahme von Rechten (AssumeRole), und CloudTrail protokolliert alle API-Aufrufe. AWS empfiehlt, den Root-Account der AWS-Organisation mit MFA zu sichern und niemals für den täglichen Betrieb zu verwenden.

In Google Cloud bietet IAM Conditions die Möglichkeit, Rechte zeitlich zu begrenzen, und Cloud Audit Logs protokollieren alle Zugriffe. Google empfiehlt die Nutzung von Service Accounts mit minimalen Rechten und die Vermeidung von Service-Account-Schlüsseln zugunsten von Workload Identity Federation.

Unabhängig von der Cloud-Plattform gelten dieselben Grundprinzipien: Least Privilege, separate Admin-Accounts, MFA für alle privilegierten Zugriffe, regelmäßige Rezertifizierung und lückenloses Logging.

PAM und Incident Response

Im Falle eines Sicherheitsvorfalls spielen privilegierte Accounts eine zentrale Rolle, sowohl als potenzielle Angriffsvektoren als auch als Werkzeuge für die Eindämmung und Wiederherstellung.

Dein Incident-Response-Plan sollte spezifische Verfahren für die Kompromittierung privilegierter Accounts enthalten. Wenn der Verdacht besteht, dass ein privilegierter Account kompromittiert wurde, ist die erste Maßnahme die sofortige Sperrung des Accounts und die Rotation aller Passwörter, auf die der Account Zugriff hatte. Gleichzeitig müssen die Session-Logs und Audit-Trails des Accounts analysiert werden, um den Umfang der Kompromittierung zu bestimmen.

Kerberos-Tickets im Active Directory stellen eine besondere Herausforderung dar. Selbst wenn du das Passwort eines kompromittierten Accounts änderst, können vorhandene Kerberos-Tickets noch bis zu ihrer Ablaufzeit (standardmäßig zehn Stunden) gültig sein. Bei einem schweren Vorfall kann es notwendig sein, das Kerberos-Ticket-Granting-Ticket (krbtgt) doppelt zu rotieren, um alle vorhandenen Tickets zu invalidieren.

Die Break-Glass-Verfahren werden im Incident-Response-Fall besonders wichtig. Wenn der Identity Provider kompromittiert ist oder der normale Zugang nicht verfügbar ist, brauchst du einen alternativen Weg, um auf die kritischen Systeme zuzugreifen. Die Break-Glass-Accounts müssen regelmäßig getestet werden, damit sie im Ernstfall funktionieren.

PAM-Richtlinie erstellen

Eine PAM-Richtlinie dokumentiert die verbindlichen Regeln für den Umgang mit privilegierten Accounts in deinem Unternehmen. Sie ist ein zentraler Bestandteil deines ISMS und bildet die Grundlage für Audits und Compliance-Nachweise.

Die Richtlinie sollte folgende Punkte abdecken: Welche Accounts gelten als privilegiert? Wie werden privilegierte Accounts beantragt, genehmigt und eingerichtet? Welche Authentifizierungsmethoden sind für privilegierte Zugriffe erforderlich? Wie oft werden Passwörter rotiert? Wie läuft die Rezertifizierung ab und in welchen Intervallen? Welche Logging- und Monitoring-Anforderungen gelten? Wie werden Break-Glass-Accounts verwaltet? Was passiert bei einem Verstoß gegen die Richtlinie?

Die Richtlinie muss von der Geschäftsführung freigegeben und allen relevanten Mitarbeitern bekannt gemacht werden. Sie wird regelmäßig überprüft und an veränderte Anforderungen angepasst.

Regulatorische Anforderungen

PAM ist keine optionale Best Practice, sondern eine regulatorische Anforderung unter mehreren Rahmenwerken.

ISO 27001 adressiert privilegierte Zugriffe in Annex A.8.2 (privilegierte Zugangsrechte): Die Zuweisung und Nutzung privilegierter Zugangsrechte muss eingeschränkt und verwaltet werden. Annex A.5.18 (Zugangsrechte) fordert die regelmäßige Überprüfung, und Annex A.8.5 (sichere Authentifizierung) verlangt starke Authentifizierung für privilegierte Systeme.

NIS2 fordert in Artikel 21 Maßnahmen zum Zugangsmanagement, die explizit den Umgang mit privilegierten Zugriffsdaten umfassen. Unternehmen müssen nachweisen, dass sie privilegierte Accounts identifiziert, geschützt und überwacht haben.

Der BSI-Grundschutz behandelt das Thema in mehreren Bausteinen: ORP.4 (Identitäts- und Berechtigungsmanagement), SYS.1.1 (Allgemeiner Server) und APP.2.1 (Allgemeiner Verzeichnisdienst). Die Anforderungen umfassen die Verwendung separater Admin-Accounts, die Beschränkung der Anzahl privilegierter Benutzer und die Protokollierung administrativer Tätigkeiten.

Umsetzungsfahrplan

Die PAM-Einführung ist ein Prozess, der schrittweise umgesetzt werden sollte. Ein realistischer Fahrplan für ein mittelständisches Unternehmen sieht folgendermaßen aus.

In den ersten vier Wochen inventarisierst du alle privilegierten Accounts, führst separate Admin-Accounts ein und aktivierst LAPS für lokale Administratoren. In den Wochen fünf bis acht implementierst du MFA für alle privilegierten Zugriffe und richtest das zentrale Logging ein. In den Wochen neun bis zwölf erstellst du die PAM-Richtlinie, definierst den Rezertifizierungsprozess und führst die erste Rezertifizierung durch. Ab Woche 13 evaluierst du, ob eine PAM-Lösung sinnvoll ist, und planst die Implementierung des Tiered-Administration-Modells.

Jeder Schritt ist für sich genommen wertvoll. Du musst nicht alles gleichzeitig umsetzen, aber du musst anfangen. Der erste Schritt, die Inventarisierung deiner privilegierten Accounts, kostet nichts außer Zeit und liefert Erkenntnisse, die für alle weiteren Maßnahmen unverzichtbar sind.

Weiterführende Artikel

• Berechtigungskonzept erstellen: Vom Rollenmodell bis zur Rezertifizierung
• Active Directory absichern: Härtung, Tiering und Monitoring
• Multi-Faktor-Authentifizierung (MFA) einführen: Strategie, Rollout und Akzeptanz
• User Lifecycle Management: Onboarding, Rollenänderung, Offboarding
• Logging und Monitoring: Strategie, Tools und Umsetzung im Mittelstand