Ein Domänen-Administratorkonto liegt in vielen mittelständischen Unternehmen noch immer außerhalb der normalen Zugriffskontrolle. Es wird geteilt, dauerhaft berechtigt oder über einen Dienstleister genutzt, während die Dokumentation in Tickets, Tabellen und persönlichen Notizen verteilt ist. Genau dort setzt Privileged Access Management, kurz PAM, an: bei Konten, die nicht nur Daten lesen, sondern Systeme verändern, Sicherheitskontrollen umgehen und ganze Betriebsabläufe beeinflussen können.
Seit der Veröffentlichung der NIS-2-Richtlinie im Amtsblatt der EU am 27.12.2022 ist privilegierter Zugriff in Deutschland von einer Best Practice zu einer klaren Compliance-Anforderung geworden. Das BSI nennt für rund 29.500 Einrichtungen neue gesetzliche Pflichten, darunter Registrierung, Meldeprozesse für Sicherheitsvorfälle sowie technische und organisatorische Sicherheitsmaßnahmen. PAM wird in NIS2 nicht ausdrücklich als Produktkategorie genannt. Die geforderten Kontrollen, Zugriffskontrolle, sichere Authentisierung und Protokollierung, bilden jedoch genau den Kern eines belastbaren PAM-Modells.
Inhaltsverzeichnis
- Warum ein Admin-Konto zum Risiko wird
- So funktioniert Privileged Access Management technisch
- NIS2 in Deutschland und der Blick in den Audit
- Angriffe auf privilegierte Konten in der Praxis
- Schritt für Schritt zur eigenen PAM-Einführung
- Vorteile eines Managed-PAM-Partners in der Region
- Best Practices, häufige Fehler und nächste Schritte
Warum ein Admin-Konto zum Risiko wird
In einem Klinikum mit mehreren Standorten fällt an einem Montagmorgen zunächst nur auf, dass sich ein IT-Mitarbeiter ungewöhnlich oft neu anmelden muss. Eine E-Mail sah aus wie eine Nachricht des internen Helpdesks. Die Absenderdomain war nachgeahmt, die Anmeldeseite wirkte vertraut. Der Mitarbeiter gab seine Zugangsdaten ein, und der Angreifer erhielt damit Zugriff auf ein einzelnes Domänen-Administratorkonto.
Von dort aus blieb es nicht bei einem kompromittierten Arbeitsplatz. Der Angreifer bewegte sich in Richtung Domain-Controller, veränderte Sicherungskonfigurationen und griff Systeme an, die für die medizinische Versorgung entscheidend waren. PACS und KIS standen nicht mehr zuverlässig zur Verfügung, die Notaufnahme arbeitete mit Papierprozessen, und eine wichtige Schnittstelle zur Kassenabrechnung war unterbrochen.
Das Problem war nicht fehlende Antivirensoftware. Auch eine Firewall hätte den Missbrauch gültiger Zugangsdaten nicht automatisch verhindert. Ein privilegiertes Konto ist ein direkter Steuerzugang zur IT, und ein Angreifer kann mit einer gültigen Identität oft unauffälliger handeln als mit einer auffälligen Schadsoftware.
Praktische Regel: Behandle jedes Konto, das Konfigurationen, Identitäten, Backups oder Sicherheitswerkzeuge verändern kann, wie einen Generalschlüssel.
Die Angriffskette beginnt selten im Rechenzentrum
Typische Einstiege sind Phishing, wiederverwendete Passwörter, ungeschützte lokale Administratoren, gemeinsam genutzte Dienstkonten oder dauerhaft aktive Zugänge externer Wartungsfirmen. Sobald ein Angreifer eine privilegierte Identität übernimmt, kann er Rechte ausweiten, sich seitlich durch das Netzwerk bewegen, Protokollierung deaktivieren oder Systeme so verändern, dass eine Wiederherstellung deutlich schwieriger wird.
Für betroffene Organisationen entstehen neben dem technischen Schaden auch regulatorische und wirtschaftliche Folgen. Ein Sicherheitsvorfall muss nach den einschlägigen NIS2-Meldeprozessen innerhalb der vorgegebenen Fristen behandelt werden, die frühe Meldung innerhalb von 24 Stunden ist dabei ein zentraler Bestandteil der europäischen Vorgaben. Hinzu kommen mögliche Vertragsstrafen, Probleme mit Kostenträgern, Reputationsverlust und erhebliche Kosten für Forensik und Wiederanlauf.
Klassische Zugriffskontrolle bleibt notwendig, reicht aber für privilegierte Tätigkeiten nicht aus. Sie beantwortet oft, wer grundsätzlich Zugriff besitzt. PAM muss zusätzlich kontrollieren, wann, warum, mit welchen Rechten und unter welcher Aufsicht ein privilegierter Zugriff tatsächlich stattfindet. Genau diese Kombination aus technischer Sperre, Freigabeprozess und prüfbarer Aufzeichnung unterbricht die Angriffskette.
So funktioniert Privileged Access Management technisch
PAM lässt sich mit einem Hotelsafe vergleichen. Gäste erhalten nur den Schlüssel zu ihrem Zimmer. Das Personal bekommt je nach Aufgabe begrenzte Berechtigungen, und der Zugang zum Master-Tresor wird besonders geschützt. Jede Entnahme wird dokumentiert, jeder Schlüssel kann ersetzt werden, und niemand muss dauerhaft mit dem Generalschlüssel arbeiten.
Technisch beginnt PAM mit dem Prinzip der geringsten Rechte. Ein Administrator erhält nicht automatisch globale Berechtigungen, sondern nur den Zugriff, den die konkrete Aufgabe verlangt. Das BSI beschreibt für NIS2 den Grundsatz, dass nur autorisierte Personen und Komponenten Zugriff erhalten und nur die zwingend erforderlichen Rechte vergeben werden.
Vom Passworttresor zur kontrollierten Sitzung
Vaulting bedeutet, dass privilegierte Zugangsdaten in einem verschlüsselten Tresor gespeichert und nicht mehr in Tabellen, Skripten oder persönlichen Passwortsammlungen verwaltet werden. Die Plattform kann Kennwörter nach einer Nutzung automatisch ändern. Der Administrator erhält dadurch idealerweise nicht einmal das eigentliche Geheimnis, sondern eine kontrollierte Verbindung zum Zielsystem.
Just-in-Time-Berechtigungen ersetzen dauerhafte Administratorrechte durch eine zeitlich begrenzte Erhöhung. Ein Techniker beantragt Zugriff für eine definierte Aufgabe, ein Verantwortlicher genehmigt ihn, und die Berechtigung verfällt nach Abschluss oder Ablauf. Für Notfallkonten braucht es einen gesonderten Prozess mit klarer Begründung und nachgelagerter Prüfung.
Session Recording zeichnet privilegierte Sitzungen auf. Dazu gehören je nach Plattform Anmeldezeit, Zielsystem, ausgeführte Befehle und Bildschirmaktivitäten. Session Isolation trennt die Verbindung über einen kontrollierten Broker. Der Nutzer arbeitet nicht direkt mit dem Zielsystem, und die Organisation kann Sitzungen überwachen, beenden oder bei verdächtigen Aktionen blockieren.
Eine produktive Architektur umfasst mindestens:
- Identitätsebene: Starkes MFA am PAM-Zugang, rollenbasierte Freigaben und getrennte Admin-Identitäten.
- Zugriffsebene: Gateway oder Broker für RDP-, SSH-, Datenbank- und Webzugriffe.
- Tresorebene: Verschlüsselte Speicherung, Passwortrotation und Verwaltung von Service- und Domänenkonten.
- Kontrollebene: Richtlinien, Genehmigungen, Sitzungsaufzeichnung und manipulationsgeschützte Audit-Daten.
- Integrationsebene: Übergabe relevanter Ereignisse an SIEM, ITSM und Ticketing.
Das Grundbild lautet: Endpunkt → Gateway → Vault mit Policy- und Audit-Schicht. Diese Trennung verhindert, dass ein einzelner Arbeitsplatz direkt als Sprungbrett zu kritischen Systemen dient.
NIS2 in Deutschland und der Blick in den Audit
NIS2 verlangt keine bestimmte PAM-Marke. Die Richtlinie verlangt wirksame Sicherheitsmaßnahmen, und Art. 21 nennt funktional genau die Kontrollen, die privilegierte Zugriffe beherrschbar machen: Zugangskontrolle, sichere Authentisierung und Protokollierung. Das BSI informiert über die deutsche Umsetzung und die Pflichten für beaufsichtigte Einrichtungen.
Für Verantwortliche zählt im Audit nicht die Aussage „Wir haben ein PAM-Tool“. Entscheidend ist, ob sich nachweisen lässt, dass privilegierte Konten vollständig erfasst, angemessen berechtigt, stark authentisiert, überwacht und regelmässig überprüft werden. Ein Auditor will Richtlinien, Konfigurationen, Freigaben und Exporte sehen, nicht nur eine Produktpräsentation.
Welche Belege in die ISMS-Dokumentation gehören
| NIS2/BSI-Anforderung | PAM-Funktion | Typische Auditschwachstelle | Prüfnachweis |
|---|---|---|---|
| Zugangs- und Berechtigungsmanagement | Konteninventar, Rollenmodell und Vaulting | Lokale Administratoren sind nicht erfasst | Export des privilegierten Konteninventars mit Verantwortlichen |
| Least Privilege | Rollenbasierte Rechte und Just-in-Time-Zugriff | Dauerhafte Domain-Admin-Berechtigungen | Genehmigte Rollenmatrix und zeitlich begrenzte Zugriffstickets |
| Sichere Authentisierung | MFA, getrennte Admin-Identitäten und Richtlinien | Gemeinsame Admin-Zugänge ohne individuelle Zuordnung | MFA-Konfiguration, Identitätszuordnung und Testprotokoll |
| Protokollierung | Session Recording und zentrale Audit-Trails | Sitzungen auf Tier-0-Systemen werden nicht aufgezeichnet | Export einer vollständigen Sitzung mit Zeit, Nutzer und Zielsystem |
| Erkennung und Reaktion | SIEM-Anbindung, Alarmierung und Sitzungsabbruch | PAM-Ereignisse bleiben im Plattform-Log | SIEM-Regel, Alarmhistorie und dokumentierter Reaktionsprozess |
| Notfallzugriff | Vier-Augen-Freigabe und nachgelagerte Rezertifizierung | Break-Glass-Konten bleiben dauerhaft aktiv | Freigabe, Verwendungsbegründung und Review-Nachweis |
| Dienstleisterzugriff | Broker, Ablaufdatum und Session-Aufzeichnung | Externe Konten sind dauerhaft freigeschaltet | Vertragliche Zuordnung, Ablaufregel und Sitzungsbericht |
Die Einordnung von PAM als Baustein der deutschen NIS2-Umsetzung ist deshalb praktisch relevant: Ein Audit prüft nicht nur, ob ein Zugriff theoretisch erlaubt ist. Es prüft, ob die Organisation die Entscheidung und die tatsächliche Nutzung nachvollziehbar belegen kann.
Angriffe auf privilegierte Konten in der Praxis
Ein mittelständischer Maschinenbauer hatte ein ungeschütztes Domänen-Administratorkonto, das selten verwendet wurde und deshalb kaum auffiel. Ein Angreifer probierte mit Passwort-Spraying bekannte Zugangsdaten aus, übernahm das Konto und verbreitete Ransomware über SMB. Die Produktion stand still, weil Server und Steuerungsumgebungen nicht mehr zuverlässig erreichbar waren.
Erkennbar wären ungewöhnliche Anmeldeversuche, Zugriffe ausserhalb des üblichen Arbeitsmusters und neue Verbindungen von Systemen gewesen, die sonst keine Administrationsaufgaben ausführen. Credential Vaulting mit individueller Zuordnung und automatischer Rotation hätte das statische Passwort aus dem Angriffsszenario entfernt. Ein Least-Privilege-Audit hätte zusätzlich geprüft, ob dieses Konto überhaupt dauerhaft so weitreichende Rechte benötigt.
In einem Klinikverbund wurde ein Helpdesk-Mitarbeiter Opfer einer täuschend echten Phishing-Nachricht. Sein Konto konnte mehr als Benutzer zurücksetzen. Der Angreifer nutzte die weitreichenden Rechte, bewegte sich im Active Directory und versuchte, Patientendaten aus erreichbaren Systemen abzuziehen. Session Recording, MFA und eine zeitlich begrenzte Eskalation hätten die Nutzung des Kontos enger an eine konkrete Aufgabe gebunden und die Untersuchung der Sitzung ermöglicht.
Sicherheitsentscheidung: Ein Helpdesk-Konto darf nicht deshalb weitreichende Rechte besitzen, weil ein einzelner Prozess sonst bequemer wäre.
Das dritte Szenario betrifft einen externen Dienstleister in einer Sozialträger-Umgebung. Ein dauerhaft aktives Dienstkonto ermöglichte Fernzugriff auf Server und Sicherheitskomponenten. Der Dienstleisterzugang wurde missbraucht, ein EDR-Schutz verändert und eine Persistenz im Netzwerk aufgebaut. Ein PAM-Broker mit Ablaufdatum, Ticketbindung, Freigabe und vollständiger Sitzungsaufzeichnung hätte den Zugang auf den erforderlichen Wartungszweck begrenzt.
Für die technische Prüfung reicht ein Schwachstellenscan nicht. Ein Red-Team-Test für privilegierte Zugriffe sollte kontrolliert prüfen, ob sich ein kompromittierter Standardzugang zu höherwertigen Identitäten, Domain-Controllern, Backup-Systemen oder Sicherheitswerkzeugen bewegen kann.
Ein typischer Angriffspfad muss dabei nicht vollständig verhindert werden, um PAM zu rechtfertigen. Es reicht bereits, wenn die Plattform die Rechteausweitung erschwert, Sitzungen sichtbar macht und Verantwortliche frühzeitig alarmiert.
Schritt für Schritt zur eigenen PAM-Einführung
Eine PAM-Einführung scheitert selten an fehlenden Funktionen. Sie scheitert an unvollständiger Bestandsaufnahme, ungeklärten Zuständigkeiten und einem Rollout, der den Betrieb überrascht. Die Reihenfolge muss deshalb feststehen, bevor die Plattform ausgewählt wird.
Sechs Phasen mit klaren Entscheidungen
Phase 1, Wochen 1 bis 3: Der IT-Leiter lässt privilegierte Konten in Active Directory, Cloud-Diensten, Servern und Fachanwendungen inventarisieren. Dazu gehören Domänen- und lokale Administratoren, Servicekonten, Datenbankzugänge, API-Secrets und Dienstleisterkonten. Exit-Kriterium ist ein freigegebenes Inventar mit Konteninhaber, Zweck, Zielsystem und aktuellem Berechtigungsumfang.
Phase 2, Wochen 4 bis 6: CISO oder externer Berater klassifiziert die Konten nach Kritikalität und definiert die Least-Privilege-Policy. Tier-0-Systeme, Identitätsdienste, Backups und zentrale Fachanwendungen erhalten Priorität. Die Entscheidung ist abgeschlossen, wenn Rollen, Genehmiger, Notfallregeln und Rezertifizierungsanforderungen schriftlich feststehen.
Phase 3, Wochen 7 bis 10: Der IT-Betrieb führt einen PoC mit zwei privilegierten Konten durch. Getestet werden Vaulting, MFA, Zugriff über den Broker, Rotation, Session Recording und die Ticketintegration. Ein PoC ist nur bestanden, wenn der Administrator arbeiten kann und der Auditor die resultierenden Nachweise versteht.
Phase 4, Wochen 11 bis 16: Das Plattform-Team baut den Vault auf und bindet die wichtigsten Tier-0-Systeme an. MFA, Richtlinien, Session Recording und Notfallzugriff werden produktiv getestet. Die Plattform darf erst weiter ausgerollt werden, wenn Wiederherstellung, Ausfallszenario und Zuständigkeiten dokumentiert sind.
Phase 5, Wochen 17 bis 22: Compliance führt Just-in-Time-Eskalation, Credential Rotation und Audit-Reporting ein. Freigaben müssen einem Vorgang zugeordnet werden können. Der Exit ist ein prüfbarer Bericht über genehmigte, genutzte und beendete Zugriffe.
Phase 6, ab Woche 23: Der Betrieb übernimmt kontinuierliche Audits und erweitert die Kontrolle auf Dienstleister, verteilte Standorte und schwer integrierbare Legacy-Systeme. PAM ist ab diesem Punkt ein laufender Prozess, kein abgeschlossenes Installationsprojekt.
| Phase | Zeitfenster | Verantwortung | Exit-Kriterium |
|---|---|---|---|
| Inventarisierung | Wochen 1 bis 3 | IT-Leitung | Vollständiges, freigegebenes Konteninventar |
| Klassifikation | Wochen 4 bis 6 | CISO oder Beratung | Rollenmodell und Least-Privilege-Policy |
| PoC | Wochen 7 bis 10 | IT-Betrieb | Zwei Konten kontrolliert und auditierbar angebunden |
| Technischer Aufbau | Wochen 11 bis 16 | Plattform-Team | Vault, MFA und Sitzungsaufzeichnung produktiv getestet |
| Governance | Wochen 17 bis 22 | Compliance | JIT, Rotation und Audit-Reports nachweisbar |
| Regelbetrieb | Ab Woche 23 | IT-Betrieb und Fachverantwortliche | Kontinuierliche Reviews und Erweiterungsplan |
Vorteile eines Managed-PAM-Partners in der Region
Ein PAM-System im Eigenbetrieb klingt zunächst kontrollierbar. In der Praxis braucht es jedoch mehr als einen Tresor. Die Organisation muss Plattformbetrieb, Updates, Integrationen, Sitzungsüberwachung, Alarmbearbeitung, Forensik, Notfallprozesse und Auditvorbereitung dauerhaft abdecken. Für Kliniken und mittelständische Produktionsbetriebe ist genau diese Kombination oft schwer mit dem vorhandenen Personal abzubilden.
Ein Managed-PAM-Partner bündelt diese Aufgaben in einem definierten Betriebsmodell. Das schafft einen Ansprechpartner für Vaulting, Session Recording, Berechtigungsreviews und NIS2-Dokumentation. Regionale Betreuung ist besonders bei verteilten Standorten und kritischen Betriebsumgebungen wertvoll, weil Entscheidungen nicht ausschliesslich über anonyme Tickets laufen müssen.
Die im PAM-Fachumfeld genannte Gegenüberstellung zeigt den möglichen organisatorischen Unterschied: Ein isoliertes Eigenprojekt wird mit einer Stellzeit von 18 Monaten beschrieben, ein Managed-Service-Modell mit 5 Monaten. Ebenso werden jährliche Lizenz- und Betriebskosten im Managed-Modell mit 30 bis 60 Prozent unter der Vollkostenrechnung einer Eigenbetreibung eingeordnet. Diese Werte sind keine automatische Einspargarantie, sondern hängen von Umfang, Dienstleistung und Vertragsmodell ab. Die Fachübersicht zu PAM und BSI-Anforderungen ordnet Managed-Betrieb als praxisrelevanten Ansatz für kontrollierbare Prozesse ein.
Der Unterschied liegt im Betrieb
| Kriterium | Eigenbetrieb | Managed-PAM-Partner |
|---|---|---|
| Plattformbetrieb | Interne Spezialisten müssen Betrieb und Pflege abdecken | Betrieb über klaren Service und definierte Zuständigkeiten |
| Überwachung | Abhängig von interner Bereitschaft und vorhandenen Prozessen | Laufende Überwachung mit Eskalationswegen |
| Auditvorbereitung | Nachweise müssen intern aus mehreren Quellen zusammengestellt werden | Standardisierte Reports und dokumentierte Kontrollen |
| Dienstleisterzugriffe | Häufig manuelle Freigaben und Einzellösungen | Einheitlicher Broker-, Ablauf- und Aufzeichnungsprozess |
| Notfallunterstützung | Wissen liegt bei wenigen internen Personen | Verbindliche Unterstützung nach SLA |
| Regionale Abstimmung | Interne Ressourcen bleiben vollständig gebunden | Ansprechpartner mit deutscher Arbeitssprache und Vor-Ort-Nähe |
Bei Kliniken und Sozialträgern kommt Datenschutz hinzu. Die Auswahl eines Partners sollte deshalb Rechenzentrumsstandort, Auftragsverarbeitung, Rollenmodell, Protokollzugriff und Löschkonzept ausdrücklich dokumentieren. Regionalität ersetzt keine technische Qualität, sie erleichtert aber Abstimmung mit Geschäftsführung, Datenschutz und Betriebsrat.
Best Practices, häufige Fehler und nächste Schritte
PAM wird wirksam, wenn Regeln im Alltag automatisch durchgesetzt werden. Eine Richtlinie, die für Domänen-Admins eine Passwortrotation alle 90 Tage vorsieht, muss technisch kontrolliert werden. Sonst bleibt sie eine Absichtserklärung. Die Empfehlung zur Rotation und die übrigen Praxisanforderungen sollten im Prozess für die Rezertifizierung von Zugriffsrechten mit Konteninhabern, Fristen und Freigabeverantwortlichen verankert werden.
Abschluss-Checkliste für den Betrieb
- Vaulting: Alle Domänen- und Servicekonten gehören in einen geschützten Tresor. Ausnahmen müssen begründet, genehmigt und regelmässig geprüft werden.
- Zeitbegrenzung: Dauerhafte Administratorrechte werden durch Just-in-Time-Zugriff ersetzt, soweit das Zielsystem dies erlaubt.
- Sitzungsaufzeichnung: Tier-0-Systeme und besonders kritische Fernzugriffe werden aufgezeichnet und revisionssicher aufbewahrt.
- Notfallkonten: Break-Glass-Zugriffe folgen dem Vier-Augen-Prinzip und erhalten eine nachgelagerte Rezertifizierung.
- CMDB-Bezug: Konten, Zielsysteme, Verantwortliche und Abhängigkeiten werden mit der Configuration Management Database abgeglichen.
- Offboarding: Rollenwechsel und Austritte lösen automatisch die Prüfung und Entziehung privilegierter Rechte aus.
Die häufigsten Fehler sind nicht spektakulär. Produktionskonten werden geteilt, Servicekonten behalten starre Zugangsdaten, Dienstleisterzugänge laufen nach Projektende weiter, und niemand besitzt eine klare RACI-Matrix. Bei Legacy-Systemen fehlen oft Sitzungsdaten, weil der Zugriff nicht über einen Broker geführt werden kann. Diese Lücken müssen im Risikoregister stehen, inklusive Kompensationsmassnahme und Termin.
Drei Schritte bringen eine Organisation aus der Diskussion in die Umsetzung:
- PAM-Quick-Check durchführen: Konten, Systeme, Dienstleister und Notfallzugänge erfassen lassen.
- Technische Bestandsaufnahme abschliessen: Active Directory, Cloud, Fachanwendungen, Datenbanken und lokale Administratoren abgleichen.
- Pilotbereich festlegen: Einen klar abgegrenzten 90-Tage-Pilot mit zwei bis wenigen kritischen Konten, definierten Freigaben und messbarer Erfolgskontrolle starten.
Wer diese Schritte sauber dokumentiert, erhält nicht nur bessere Sicherheit. Die Geschäftsführung bekommt eine belastbare Entscheidungsgrundlage, und der Audit kann nachvollziehen, wie privilegierte Rechte tatsächlich kontrolliert werden.
GSL Groß GmbH unterstützt KMU, Kliniken und Organisationen bei der Bestandsaufnahme privilegierter Konten, der NIS2-orientierten PAM-Konzeption und dem laufenden Betrieb mit Monitoring und nachvollziehbarer Dokumentation. Besprechen Sie Ihren PAM-Quick-Check und den passenden Pilotbereich direkt mit GSL Groß GmbH.