Dauerhafte Adminrechte sind kein Betriebsmodell

Ein Administrator besitzt für seine tägliche Arbeit lokale Administratorrechte, Domänenrechte, Cloud-Rollen und Zugriff auf Sicherungssysteme. Das ist bequem und scheint in einem kleinen Team effizient. Gleichzeitig kann ein kompromittiertes Konto, ein falscher Klick oder eine unklare Anweisung sehr viele Systeme auf einmal betreffen.

Die Alternative darf nicht aus einem Freigabeprozess bestehen, der jede notwendige Arbeit verzögert. Privileged Access Management muss zum realen Betrieb passen. Es soll privilegierte Aufgaben kontrollierbar machen, nicht Administratoren daran hindern, sie auszuführen.

Der Ausgangspunkt ist deshalb nicht ein bestimmtes Werkzeug. Zuerst werden Aufgaben, Rollen, Reichweite und Zeitbedarf geklärt. Danach lässt sich entscheiden, welche Rechte dauerhaft, welche nur aktivierbar und welche ausschließlich für Notfälle verfügbar sein müssen.

Eine technische Rolle ist noch keine Befugnis

Administrative Berechtigung beantwortet, was ein Konto technisch tun kann. Sie beantwortet nicht automatisch, ob eine Person eine konkrete Änderung fachlich oder organisatorisch freigeben darf.

Für privilegierte Arbeit müssen mindestens drei Dinge getrennt sein:

• Aufgabe: Welche konkrete Tätigkeit ist notwendig?
• Befugnis: Wer darf entscheiden, dass sie unter diesen Bedingungen ausgeführt wird?
• Berechtigung: Welcher technische Zugriff ist dafür erforderlich?

Ein Administrator kann technisch einen produktiven Dienst abschalten, ohne dazu befugt zu sein. Umgekehrt kann ein Change Owner die Abschaltung freigeben, ohne selbst Zugriff auf das System zu benötigen. Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ vertieft diese Trennung.

Alltagskonto und Administrationskonto gehören auseinander

E-Mail, Webzugriff, Chat und Dokumentbearbeitung erzeugen eine andere Angriffsfläche als administrative Systemarbeit. Werden beide Tätigkeiten mit derselben dauerhaft privilegierten Identität ausgeführt, erreicht ein Fehler aus der Alltagsnutzung unmittelbar den administrativen Kontext.

Ein pragmatischer Mindeststandard ist:

• persönliches Standardkonto für Kommunikation und normale Nutzung,
• separates, persönlich zuordenbares Administrationskonto,
• keine E-Mail- oder allgemeine Webnutzung mit dem Administrationskonto,
• starke Authentisierung und geschützte Wiederherstellung,
• spezifische Rollen statt pauschaler höchster Berechtigung,
• zentrale Erfassung der Zuweisungen und regelmäßige Prüfung.

Geteilte Konten erschweren Zuordnung und Entzug. Wo ein technischer Herstellerzugang nicht personalisiert werden kann, braucht es wenigstens geregelte Herausgabe, Geheimniswechsel und eine zusätzliche Protokollierung der Nutzung.

Der BSI-Baustein ORP.4 fordert unter anderem ein Rollen- und Berechtigungskonzept, die restriktive Vergabe administrativer Rechte und eine Trennung privilegierter Konten. Die konkrete Umsetzung muss zur jeweiligen Umgebung passen.

Least Privilege ist eine Aufgabenfrage

„So wenig Rechte wie möglich“ klingt eindeutig, hilft aber ohne Aufgabenanalyse wenig. Zu kleine Rechte erzeugen ständige Umgehungen; zu große Rechte vergrößern die Wirkung eines Fehlers.

Für jede privilegierte Aufgabe sind zu klären:

• auf welche Systeme und Daten sie wirkt,
• welche Aktionen tatsächlich benötigt werden,
• wie häufig und wie lange sie vorkommt,
• ob sie planbar, spontan oder notfallbedingt ist,
• welche Kontrolle vor, während und nach der Ausführung sinnvoll ist,
• welche Abhängigkeiten einen Ausfall der Rechteverwaltung kritisch machen.

Das NIST SP 800-53 Rev. 5 behandelt Least Privilege und die Beschränkung privilegierter Funktionen im Kontrollkatalog AC-6. Der Katalog richtet sich an ein breites Spektrum von Organisationen und ist kein fertiges Rollenmodell. Er macht aber deutlich, dass privilegierte und nicht privilegierte Nutzung bewusst getrennt werden sollen.

Zeitlich begrenzter Zugriff reduziert das offene Fenster

Ein Recht, das nur für eine Aufgabe benötigt wird, muss nicht zwingend dauerhaft aktiv sein. Bei Just-in-Time-Zugriff erhält oder aktiviert eine berechtigte Person die Rolle für einen begrenzten Zeitraum.

Je nach Risiko kann die Aktivierung enthalten:

• erneute starke Authentisierung,
• Auswahl der benötigten Rolle und des Geltungsbereichs,
• Begründung oder Referenz auf einen Change beziehungsweise Incident,
• Genehmigung durch eine andere Rolle,
• automatische Befristung,
• Benachrichtigung und Protokollierung,
• nachträgliche Prüfung auffälliger Nutzung.

Nicht jede Aktivierung braucht eine manuelle Genehmigung. Für häufige, klar abgegrenzte Tätigkeiten kann eine selbstständige zeitliche Aktivierung mit Protokoll ausreichend sein. Für seltene hochkritische Rollen kann ein Vier-Augen-Prinzip angemessen sein.

Microsoft Entra Privileged Identity Management ist ein produktspezifisches Beispiel für eligible, aktive und zeitlich begrenzte Rollen. Laut Microsoft-Dokumentation vom Juli 2026 erfordern die entsprechenden PIM-Funktionen eine passende Entra-ID-P2- oder Entra-ID-Governance-Lizenz. Das Produktbeispiel ist keine allgemeine Empfehlung: Andere Plattformen benötigen eigene Verfahren oder ergänzende Werkzeuge.

Der Notfallweg darf die Kontrolle nicht heimlich ersetzen

Eine Rechteplattform, die bei einem Identitäts- oder Netzwerkausfall nicht erreichbar ist, kann den Wiederanlauf blockieren. Deshalb braucht es einen getrennten Notfallweg.

Ein Notfallkonto sollte:

• nur für klar definierte Ausfälle oder Wiederherstellungen vorgesehen sein,
• nicht im Tagesgeschäft verwendet werden,
• stark geschützt und regelmäßig auf Funktionsfähigkeit geprüft sein,
• bei Nutzung sofort sichtbar alarmieren,
• nach Nutzung überprüft und gegebenenfalls mit neuen Geheimnissen versehen werden,
• mindestens einer weiteren verantwortlichen Rolle bekannt und zugänglich sein.

Der Beitrag „Ein Notfallkonto ist kein zweites Administratorkonto“ beschreibt diesen Sonderfall ausführlich. Notfallzugriff und tägliche privilegierte Arbeit dürfen nicht vermischt werden.

Dienstkonten brauchen einen anderen Lebenszyklus

Nicht jeder privilegierte Zugriff gehört einer Person. Dienste, Automatisierungen, Integrationen und Agenten benötigen technische Identitäten. Diese Konten lassen sich nicht sinnvoll durch eine menschliche Aktivierung vor jeder Nutzung steuern.

Für sie sind andere Kontrollen wichtig:

• eindeutiger technischer und fachlicher Owner,
• eng begrenzter Zweck und Geltungsbereich,
• verwaltete Geheimnisse oder Zertifikate statt fest eingebauter Passwörter,
• automatische Rotation, wo technisch möglich,
• nachvollziehbare Nutzung und Alarmierung bei Abweichungen,
• dokumentierte Abhängigkeiten,
• Entzug, wenn Anwendung oder Schnittstelle endet.

Ein technisches Konto ohne Owner wird bei Personalwechseln leicht übersehen. Das Microsoft-365-Offboarding zeigt dieselbe Lebenszyklusfrage aus Sicht personengebundener Identitäten.

Konstruiertes Beispiel: Der schnelle Fix bleibt dauerhaft aktiv

Das folgende Beispiel ist konstruiert.

Für eine Störung erhält ein externer Spezialist vorübergehend eine umfassende Cloud-Rolle. Die Störung wird behoben, das Ticket geschlossen. Weil kein Enddatum und kein Owner für die Zuweisung hinterlegt wurden, bleibt die Rolle über den Einsatz hinaus aktiv.

Ein zeitlich begrenzter Zugang hätte nicht zwingend zusätzliche Wartezeit erzeugt. Die Rolle hätte für die Dauer des Einsatzes aktiviert und danach automatisch entzogen werden können. Der entscheidende Unterschied liegt nicht in mehr Freigaben, sondern in einer Zuweisung mit Zweck, Umfang und Ende.

Die Privileged-Access-Karte

Eine kompakte Karte hilft, privilegierte Aufgaben statt Personen pauschal zu betrachten.

Feld	Entscheidung
Aufgabe	Welche administrative Tätigkeit wird ausgeführt?
Befugnis	Wer darf die Ausführung oder Ausnahme genehmigen?
Identität	Persönliches Adminkonto, technische Identität oder Notfallkonto
Umfang	Welche Rolle, Systeme, Mandanten und Daten sind nötig?
Zeitpunkt	dauerhaft aktiv, eligible, zeitlich begrenzt oder nur im Notfall
Aktivierung	Authentisierung, Begründung, Genehmigung und maximale Dauer
Arbeitsumgebung	Von welchem verwalteten Gerät oder Zugang ist die Nutzung zulässig?
Nachweis	Welche Ereignisse, Änderungen und Referenzen werden protokolliert?
Kontrolle	Wer prüft Zuweisung und auffällige Nutzung in welchem Anlass?
Ausfallweg	Wie bleibt notwendige Administration bei Ausfall der Rechteplattform möglich?
Ende	Welches Ereignis entzieht Rolle, Konto oder Geheimnis?

Der pragmatische Einstieg für kleine Teams

Eine kleine IT-Abteilung muss nicht mit einer komplexen Privileged-Access-Plattform beginnen. Ein sinnvoller erster Schritt kann sein:

1. alle hochprivilegierten persönlichen und technischen Konten erfassen,
2. Standard- und Administrationskonten trennen,
3. pauschale Höchstrechte durch spezifischere Rollen ersetzen,
4. temporäre Dienstleisterzugänge immer mit Enddatum versehen,
5. hochkritische Rollen regelmäßig durch IT-Leitung und Systemverantwortliche prüfen,
6. einen getrennten und getesteten Notfallzugang einrichten,
7. erst dann Just-in-Time-Funktionen für die wichtigsten Plattformen einführen.

Ein aufwendiger Aktivierungsprozess für jede lokale Einzelaufgabe kann unverhältnismäßig sein. Dauerhafte höchste Rechte für Alltagskonten sind deshalb aber nicht die einzige Alternative.

Privilegierter Zugriff wird beherrschbar, wenn die Organisation nicht fragt, wer „Admin sein darf“, sondern welche Aufgabe mit welchem Recht, für welchen Zeitraum und mit welchem Nachweis erledigt werden muss. Aus einem Personenstatus wird damit ein steuerbarer Betriebsweg.