Eine Richtlinie für privilegierten Zugriff legt fest, wer in Ihrer Organisation administrative Rechte halten darf, wie diese Rechte vergeben werden und wie sie wieder entzogen werden. Gefordert wird sie unter ISO 27001 A.5.15 und A.8.2, SOC 2 CC6, NIST SP 800-53, PCI DSS, DORA und HIPAA.
Das Dokument ist zugleich der Maßstab, an dem Auditoren Sie prüfen. Steht eine Kontrolle erst einmal in der Richtlinie, ziehen Prüfer Stichproben aus Ihren Nachweisen, um zu sehen, ob die Kontrolle auch gelebt wird. Verspricht Ihre Richtlinie vierteljährliche Reviews privilegierter Zugriffe und haben Sie in den letzten zwölf Monaten nur zwei durchgeführt, erzeugt die Richtlinie die Feststellung selbst.
Die meisten wiederkehrenden Schwächen solcher Richtlinien gehen auf eine Handvoll immer gleicher Schreibmuster zurück: allgemeine Formulierungen, unklare Zuständigkeiten und Zusagen, die das Team im Betrieb nicht einlösen kann.
Was in das Dokument gehört
Eine allgemein vorgeschriebene Struktur gibt es nicht, aber einige Abschnitte tauchen in nahezu jeder seriösen Vorlage auf und decken sich mit dem, worauf Auditoren achten. Eine brauchbare Richtlinie für privilegierten Zugriff kommt mit 6 bis 8 Seiten aus.
Geltungsbereich und Begriffe
Legen Sie fest, für welche Systeme, Umgebungen und Nutzergruppen die Richtlinie gilt: On-Premises, Cloud, SaaS, OT, BYOD, externe Auftragnehmer. Gehen Sie nicht davon aus, dass die Cloud stillschweigend mitgemeint ist. Auditoren werden danach fragen.
Definieren Sie anschließend, was „privilegiert” in Ihrer Umgebung bedeutet. Die meisten Richtlinien lassen das offen oder setzen es mit „Domänen-Admin” gleich. Eine brauchbare Definition umfasst alle, deren Zugriff Standard-Sicherheitskontrollen umgehen, Systemkonfigurationen ändern, auf Daten anderer Nutzer zugreifen oder weitere Rechte erlangen kann. Dazu zählen Cloud-Rollen, Datenbankadministratoren, SaaS-Superuser und Dienstkonten.
Rollen, Zuständigkeiten und Kontotypen
Arbeiten Sie mit Rollen, nie mit Namen von Personen. Die Richtlinie sollte festlegen, wer Zugriff beantragt, wer ihn genehmigt, wer ihn umsetzt, wer ihn überprüft und wer ihn entzieht. Die Funktionstrennung zwischen Antrag und Genehmigung ist ein häufiger Prüfpunkt im Audit, besonders bei SOX-relevanten Systemen.
Menschliche Nutzer sind der einfache Teil. Die Richtlinie muss außerdem regeln:
- Dienstkonten und Maschinenidentitäten
- Konten von Drittanbietern und Dienstleistern
- Geteilte Konten (falls überhaupt erlaubt)
- Break-Glass– und Notfallkonten
Jeder dieser Kontotypen hat eigene Lebenszyklusregeln und ein eigenes Risikoprofil.
Autorisierung und Authentifizierung
Der Abschnitt zur Autorisierung beschreibt, wie jemand überhaupt an privilegierten Zugriff kommt: welche geschäftliche Begründung nötig ist, welche Nachweise erfasst werden und wie der Genehmigungsablauf aussieht. Nutzen Sie ein Ticketsystem, nennen Sie es beim Namen.
Die Anforderungen an die Authentifizierung sollten MFA-Vorgaben abdecken, Abfragen pro Sitzung oder pro Anmeldung, Hardware-Token für Tier-0-Systeme und etwaige Zusagen zur passwortlosen Anmeldung. ISO 27001 schreibt MFA nicht ausdrücklich vor, doch Lead Auditoren erwarten sie für privilegierten Zugriff und Fernzugriff als grundlegende Risikobehandlung.
Dauerhafte Rechte, zeitlich begrenzter Zugriff und Review-Rhythmus
Halten Sie fest, wo Ihre Organisation zwischen „alle haben dauerhafte Admin-Rechte” und „Zero Standing Privilege” steht. Erlauben Sie auf bestimmten Systemen dauerhaften Zugriff, sollte die Richtlinie sagen, auf welchen und warum.
Für Reviews legen Sie fest, was überprüft wird, von wem, wie oft und wie das dokumentierte Ergebnis aussieht. Privilegierter Zugriff rechtfertigt in der Regel mindestens vierteljährliche Reviews, für die riskantesten Konten zusätzlich eine laufende Überwachung. Sagen Sie einen Rhythmus zu, den das Team verlässlich einhalten kann.
Protokollierung, Ausnahmen und Notfallzugriff
Die Vorgaben zur Protokollierung sollten regeln, welche privilegierten Ereignisse erfasst werden, wie lange Protokolle aufbewahrt werden und wer darauf zugreifen darf. Die Aufbewahrungsfrist muss sich gegenüber Ihren regulatorischen Pflichten begründen lassen: für die meisten Rahmenwerke mindestens 90 Tage, im Finanzsektor länger.
Der Ausnahmeprozess braucht einen benannten Genehmiger, eine Höchstdauer, einen Mechanismus zur Nachverfolgung und einen automatischen Ablauf. Über Ausnahmen ohne Ablaufdatum schleichen sich dauerhafte Rechte wieder ein.
Break-Glass-Verfahren sollten festlegen, wann Notfall-Zugangsdaten genutzt werden dürfen, wer sie anfordern darf, wie ihre Nutzung in Echtzeit protokolliert wird und wie sie danach rotiert werden.
Lebenszyklus und Pflege der Richtlinie
Koppeln Sie Offboarding und Rollenwechsel an HR-Auslöser (Kündigung, Versetzung, Vertragsende) und hinterlegen Sie eine Frist für den Entzug: am selben Tag bei Kündigungen, ein festgelegtes Zeitfenster bei Rollenwechseln.
Zuletzt sollte die Richtlinie ihren eigenen Verantwortlichen benennen, einen Überprüfungsrhythmus festlegen (mindestens jährlich), definieren, wie Änderungen genehmigt werden, und angeben, wo die Versionshistorie liegt. ISO 27001 verlangt die Freigabe durch die oberste Leitung.
Fünf Schwächen, die Auditoren bemängeln
Die meisten Richtlinien decken die Abschnitte oben in irgendeiner Form ab. Die Feststellungen entstehen dadurch, wie diese Abschnitte geschrieben sind.
1. Die Richtlinie beschreibt nicht, was das Team wirklich tut
Das ist die am häufigsten genannte Lücke in SOC-2-Audit-Feststellungen und ISO-27001-Überwachungsaudits. Die Richtlinie beschreibt ein vierteljährliches Access Review; die Nachweise zeigen zwei im vergangenen Jahr. Die Richtlinie sagt, jeder privilegierte Zugriff brauche die Genehmigung einer Führungskraft; das Ticketsystem zeigt Admins, die sich selbst genehmigen.
Die Lösung ist unbequem: Schreiben Sie die Richtlinie so, dass sie beschreibt, was das Team wirklich tut, und verbessern Sie die Praxis, sobald das Dokument ehrlich ist. Schaffen Sie vierteljährliche Reviews nicht verlässlich, sagen Sie halbjährliche zu und erfüllen Sie diesen Anspruch konsequent.
2. Textbausteine ohne Zuständigkeit
Auditoren bemängeln Richtlinien, die wirken, als stammten sie aus einer Vorlage. Verräterisch sind unspezifische Formulierungen wie „Der Zugriff ist auf berechtigte Nutzer beschränkt”, „Angemessene Kontrollen sind vorhanden” oder „Regelmäßige Überprüfungen finden statt”. Keine dieser Aussagen ist prüfbar.
Prüfbar wird eine Richtlinie, wenn jede Aussage eine benannte Rolle, einen definierten Auslöser und ein messbares Ergebnis hat:
Der IT Operations Manager überprüft privilegierte Zugriffe vierteljährlich anhand der in [System] gepflegten Zugriffsmatrix; Ausnahmen werden im Ausnahmeregister für privilegierten Zugriff dokumentiert.
Dieser Satz erzeugt Nachweispflichten, die das Team auch erfüllen kann.
3. Keine echte Trennung zwischen Standard- und privilegiertem Zugriff
Die meisten Access Reviews fragen, ob eine Person Zugriff auf ein System braucht. Reviews privilegierter Zugriffe müssen strenger fragen: Braucht diese Person administrativen Zugriff auf dieses System?
Fehlt diese Unterscheidung, winkt derselbe Prozess, der den Lesezugriff eines Finanzanalysten genehmigt, auch jeden durch, der gerade in der Gruppe der Datenbankadministratoren steckt. Die Richtlinie sollte ausdrücklich eigene Reviews für privilegierte Zugriffe verlangen, mit engerem Rhythmus und höheren Anforderungen an die Begründung.
4. Privilegierte Konten werden nicht gesondert erfasst und verwaltet
ISO 27001 A.8.2 verlangt ein dokumentiertes, aktuell gehaltenes Verzeichnis privilegierter Konten. Die häufigste Feststellung lautet hier, dass es entweder gar kein Verzeichnis gibt oder dass es seit dem letzten Audit nicht aktualisiert wurde.
Dienstkonten sind die schlimmsten Kandidaten. Sie sammeln sich in Active Directory und Cloud-Plattformen an und werden selten überprüft, weil kein Mensch für sie verantwortlich ist.
Die Richtlinie muss ein gepflegtes Verzeichnis zusagen, mit benannten Verantwortlichen für jedes privilegierte Konto, einschließlich nicht-menschlicher Identitäten. Außerdem sollte sie festlegen, wie sich privilegierte Konten von Standardkonten unterscheiden: über Namenskonventionen, die Platzierung in Organisationseinheiten (OUs) oder Gruppenmitgliedschaften.
5. Die Randbereiche bleiben ungeregelt
Drittanbieter, Dienstleister, Auftragnehmer, Dienstkonten, Break-Glass-Verfahren und Notfallzugriff sind die Stellen, an denen die meisten realen Vorfälle passieren, und zugleich die Stellen, an denen die meisten Richtlinien am vagesten bleiben.
Der Verizon DBIR 2025 stellte bei 30 Prozent der Sicherheitsverletzungen eine Beteiligung Dritter fest, doppelt so viel wie im Vorjahr. Behandelt Ihre Richtlinie Dienstleisterzugriff als Fußnote, steht ausgerechnet beim häufigsten Angriffsweg die Tür offen.
Jeder dieser Randfälle braucht eine eigene Regelung: wie Zugriff vergeben wird, wie er zeitlich begrenzt wird, wie er anders protokolliert wird als normale Aktivität und wie er endet, wenn der Auftrag abgeschlossen ist.
Praktische Hinweise zum Schreiben
Schreiben Sie die Richtlinie nicht allein in der IT. Privilegierter Zugriff betrifft viele Bereiche, deshalb braucht das Dokument Input von:
- HR, für die Anbindung an Joiner-Mover-Leaver-Prozesse und die Abstimmung von Fristen
- der Rechtsabteilung, für Aufbewahrungs- und Offenlegungspflichten
- den Systemverantwortlichen, die im Alltag mit den Regeln leben müssen
Die Freigabe sollte von der Geschäftsleitung kommen. ISO 27001 erwartet das, und die meisten anderen Rahmenwerke setzen es stillschweigend voraus.
Halten Sie das Dokument so kurz, dass es sich in einem Zug lesen lässt. Hat Ihr Entwurf mehr als 8 Seiten, haben Sie vermutlich eine Verfahrensanweisung geschrieben statt einer Richtlinie. Verschieben Sie operative Details in eigene Verfahrensdokumente, auf die die Richtlinie verweist.
Überprüfen Sie das Dokument jährlich und nach jeder größeren Änderung der Umgebung, etwa einer neuen Compliance-Pflicht, einer großen Plattformmigration oder einer Umstrukturierung. Pflegen Sie die Versionen sauber, denn die Versionshistorie ist selbst ein Audit-Nachweis.
Ein Vertrag über administrative Macht
Eine Richtlinie für privilegierten Zugriff ist ein operativer Vertrag zwischen Ihrem Sicherheitsteam und dem Rest des Unternehmens darüber, wie administrative Macht vergeben, genutzt und belegt wird. Spiegelt das Dokument die Wirklichkeit, gehen Audits schneller und Vorfälle lassen sich leichter untersuchen.
Ihre Werkzeuge entscheiden mit darüber, ob diese Verbindung hält. Admin By Request EPM und unsere Secure Remote Access-Lösung erzeugen genau die Zugriffsanfragen, Genehmigungen, zeitlich begrenzten Rechteerhöhungen und Audit-Logs, die die meisten Richtlinien zusagen.
Wie das in der Praxis aussieht, zeigen wir Ihnen gern in einer Demo. Oder Sie registrieren sich für unseren Free Plan, der den vollen Funktionsumfang für bis zu 25 Endpunkte bietet, ohne Zeitlimit.
Dieser Blog wurde ursprünglich auf Englisch auf unserer Website veröffentlicht. Das Original finden Sie hier.
