Anwendungsfall · Privilegierte Konten

Wo die neue Regel endet und die alte Vorsicht beginnt.

Rotation für Standard-User abschaffen ist die leichte Entscheidung. Für Domain-Admins, Service-Accounts und Break-Glass-Konten gelten andere Regeln — und das ist keine Inkonsequenz, sondern NIST-konforme Differenzierung. Dieser Deep-Dive beschreibt, wie die Policy für die privilegierte Ausnahme formuliert wird.

Wo es sich lohnt

Fünf Admin-Schreibtische, an denen die Ausnahme verhandelt wird.

In der System-Administration eines Logistikunternehmens mit 24/7-Betrieb

Drei Domain-Admin-Konten, geteilt über zwei Standorte und drei Schichten. Die Konten wurden 2019 eingerichtet, die Passwörter stehen seitdem in einem KeePass-Tresor, den fünf Personen kennen. Wenn einer der fünf das Unternehmen verlässt, beginnt die Diskussion: Ändern wir die Passwörter, oder vertrauen wir der Austrittsvereinbarung? Diese Diskussion ist die Antwort: ja, ändern — und zwar mit einem Verfahren, nicht ad hoc.

Bei der Betriebssoftware eines Versicherers mit Windows-Domäne und Linux-Bestand

Service-Accounts für SQL-Server-Dienste, Veeam-Backup-Jobs, Nagios-Monitoring, Ansible-Runs, Zertifikats-Erneuerung. Rund sechzig technische Konten, verteilt auf vier Tresore, gepflegt von drei Admins. Rotation findet statt, wenn ein Admin geht — sonst nie. Die IT-Revision fragt: Welche dieser Konten haben in den letzten zwei Jahren ihre Passwörter nicht geändert? Die Antwort steht in keinem Dashboard. Das ist der Moment für eine formale PAM-Strategie.

In einem Security-Engineering-Team bei einem Finanzdienstleister

BaFin-Aufsicht, MaRisk-Anforderungen, eine interne Revision, die jedes Quartal privilegierte Zugriffe prüft. Drei Break-Glass-Konten für den Domain-Notfall, versiegelt im physischen Tresor, letzte Rotation vor achtzehn Monaten. Die Frage ist nicht, ob diese Konten rotieren — sie müssen. Die Frage ist, in welcher Frequenz, mit welchem Verfahren und mit welcher Dokumentation. NIST SP 800-63B lässt diese Entscheidung bewusst beim Betreiber.

Beim Onboarding einer PAM-Lösung in einem Maschinenbau-Konzern

Die Entscheidung zwischen CyberArk, Delinea und Keeper PAM ist gefallen, das Einführungs-Projekt läuft. In der Policy-Definitionsphase steht die Frage: Welche Konten gehen in den Tresor, welche bleiben draußen, welche rotieren automatisch nach welchem Zyklus? Der Rotations-Modellierer hilft hier nicht bei der Sicherheit — er hilft bei der Gesprächsgrundlage. Wie viel Aufwand ist ein wöchentlicher Service-Account-Rotations-Job wert, wenn Monitoring-Skripte bei jeder Rotation neu konfiguriert werden müssen?

Bei einem MSP, der sechzehn Mandanten-ADs betreut

Pro Mandant ein Paar privilegierter Zugänge für den betreuenden Techniker, plus Service-Accounts für die Backup- und Monitoring-Agenten des MSP. Das ergibt ungefähr fünfzig privilegierte Konten über Mandanten-Grenzen hinweg. Die Herausforderung ist nicht die Passwort-Qualität — die ist hoch. Die Herausforderung ist der Rollen-Übergang: Was passiert, wenn ein Techniker die Kundenbetreuung abgibt? Ohne dokumentierten Übergabeprozess bleiben seine Credentials in fünf Mandanten-Tresoren liegen.

Warum überhaupt

Privileg ist keine Abweichung. Es ist eine Kategorie.

NIST SP 800-63B Rev. 3, Abschnitt 5.1.1.2, macht den Unterschied ausdrücklich: Die Absage an erzwungene periodische Änderung gilt für „memorized secrets“ von Endnutzer:innen — nicht für hoch privilegierte Konten, nicht für maschinelle Zugänge, nicht für Konten, auf die mehrere Personen gleichzeitig Zugriff haben. Wer die Rotation für den Fachbereich fallen lässt und im gleichen Atemzug die Rotation für Domain-Admins fallen lässt, hat das Dokument nicht zu Ende gelesen. Die Differenzierung ist Teil der Empfehlung, nicht ihr Gegensatz.

Die ISO 27002:2022 in Abschnitt 8.5 (Secure authentication) und die BSI-ORP.4-Anforderungen verlangen für privilegierte Konten eine dokumentierte, verschärfte Verfahrensweise: starke Authentifizierung (MFA zwingend), getrennte Tresor-Haltung, protokollierte Nutzung, definierter Rotations-Zyklus oder — noch besser — Just-in-Time-Provisionierung über eine PAM-Lösung. Welche dieser Optionen in Ihrer Umgebung passt, hängt von der Größe, der Regulatorik und der bereits vorhandenen Infrastruktur ab. Was nicht passt: die Fachbereichs-Policy eins zu eins auf die Admin-Gruppe anwenden.

Für Service-Accounts ist der Pfad am klarsten: sehr lange, sehr zufällige Passwörter (acht-Wort-Passphrasen oder 32-Zeichen-Zufallsstrings), Haltung im Tresor oder in der PAM-Lösung, Rotation bei Personalwechsel plus in definierten Abständen, Monitoring der letzten erfolgreichen Anmeldung. Break-Glass-Konten sind der Spezialfall: versiegelt im physischen Tresor, Vier-Augen-Prinzip beim Öffnen, sofortige Neuvergabe nach jedem Zugriff, quartalsweise Prüfung der Siegel. Das sind keine Empfehlungen aus dem Bauch — das sind die Mindestanforderungen, an denen TISAX-Assessor:innen und ISO-27001-Auditor:innen prüfen.

Ehrlich gesagt

Was der Rotations-Modellierer für Admin-Konten leistet — und was nicht.

Das Modell auf dieser Seite ist für die Fachbereichs-Policy gebaut. Es rechnet mit 18 Prozent Reset-Rate pro Rotationszyklus und 15 Prozent Lockout-Eskalation — beides Werte, die für Admin-Konten keinen Sinn ergeben. Admins vergessen ihre Passwörter seltener, und ein gesperrtes Admin-Konto produziert keinen Helpdesk-Ticket, sondern einen Security-Incident. Für privilegierte Konten liegt der Wert einer Rotation in der Verringerung des Lateral-Movement-Zeitfensters, nicht in Helpdesk-Einsparungen.

Das Werkzeug ersetzt keine PAM-Analyse. Ob CyberArk, Delinea, Keeper, ein Open-Source-Ansatz wie HashiCorp Vault oder eine selbstgebaute Lösung mit AD-Service-Account-Discovery sinnvoll ist, hängt von der Kontenzahl, der Integrationstiefe und dem Betriebsmodell ab. Der zxcvbn-Score prüft die Stärke einer einzelnen Eingabe — er prüft nicht die Architektur des Tresors, nicht die Protokollierung, nicht die Rotations-Automation.

Und ehrlich gesagt: Die schwierigste Diskussion um privilegierte Konten ist nicht die Frequenz, sondern die Granularität. Einen geteilten „Admin“-Zugang für fünf Personen gibt es heute in jeder dritten mittelständischen IT — das ist die Altlast, die vor jeder Rotations-Policy angegangen werden sollte. Individuelle Admin-Konten pro Person, mit Protokollierung der Sudo-Eskalationen, liefern mehr Sicherheitsgewinn als jede Verkürzung der Rotationsfrequenz des geteilten Zugangs.

Direkt ausprobieren

Der Rechenweg für die Admin-Konto-Ausnahme.

Der Rotations-Modellierer liefert die Grundlage auch für privilegierte Konten — mit der Einschränkung, dass die Helpdesk-Kosten für Admins gegen null gehen und der Wert woanders liegt. Nutzen Sie das Werkzeug, um für die PAM-Entscheidungsvorlage die Basiszahlen zu erheben: Wie viele privilegierte Konten existieren, welche Rotationsfrequenz war bisher angedacht, was kostet die manuelle Rotation gegenüber einer PAM-Automation?

Werkzeug öffnen — Rotations-Zyklen

Drei Fragen

Was in Admin-Policy-Runden regelmäßig verhandelt wird.

Wenn aus Tresor-Pflege ein Projekt wird

Fünfzig privilegierte Konten sind keine Passwort-Frage. Sie sind eine Architektur.

Admin-Konto-Inventur, Service-Account-Discovery im AD, Rollen-Trennung zwischen Helpdesk-Eskalation und Domain-Admin, PAM-Auswahl und Einführung, Protokollierung für die nächste Revision — das ist die Schicht, in der Modular-Admin und unser Beratungsansatz zusammengreifen. AD/LDAP-Integration, Audit-Evidence-Pakete für TISAX und ISO 27001, dokumentierte Übergabeprozesse beim Personalwechsel. Im kostenfreien Erstgespräch sehen wir uns die aktuelle Konten-Landschaft an und zeigen, wo die erste Strecke sinnvoll ansetzt.

Kostenfreies Erstgespräch buchen