Just-in-Time-Zugriff — so eliminieren Sie dauerhafte Berechtigungen im Unternehmen
Die meisten Sicherheitsvorfälle in Unternehmen mit privilegiertem Zugriff haben eine gemeinsame Grundursache: Das kompromittierte Konto hatte Zugriff, den es nicht benötigte, auf Systeme, die es seit Wochen nicht berührt hatte, mit Zugangsdaten, die seit Monaten gültig waren. Der Angreifer hat keine Berechtigungen eskaliert — die Berechtigungen waren bereits vorhanden, dauerhaft, wartend. Das ist das Problem dauerhafter Berechtigungen, und Just-in-Time-Zugriff ist genau dafür konzipiert, diese Lücke zu schließen.
Was ist Just-in-Time-Zugriff — und wie unterscheidet er sich von traditionellem PAM
Traditionelles PAM funktioniert nach dem Safe-und-Checkout-Modell. Privilegierte Zugangsdaten werden in einem Safe gespeichert. Wenn ein Systemadministrator Zugriff benötigt, checkt er die Zugangsdaten aus, stellt eine Verbindung zum Zielsystem her und gibt die Zugangsdaten nach Abschluss zurück. Das ist besser als gemeinsam genutzte Tabellenkalkulationen und Haftnotizen, hat aber immer noch ein grundlegendes strukturelles Problem: Das privilegierte Konto selbst existiert dauerhaft im Zielsystem. Das Administrator-Konto auf einem Windows-Server, das root-Konto auf einem Linux-Host, das sa-Konto in der Datenbank — diese Konten sind immer vorhanden, immer aktiv, immer ein Angriffsziel.
Just-in-Time-Zugriff (JIT) verfolgt einen anderen Ansatz: das dauerhafte Konto vollständig eliminieren oder zumindest sicherstellen, dass das Konto deaktiviert und die Zugangsdaten unmittelbar vor und nach jeder Nutzung rotiert werden. Der Zugriff wird auf Anfrage für einen bestimmten Benutzer, ein bestimmtes Ziel und ein bestimmtes Zeitfenster gewährt. Wenn das Fenster abläuft, wird der Zugriff automatisch entzogen — nicht zum Safe zurückgegeben, sondern entfernt.
Das Prinzip Zero Standing Privileges (ZSP) erweitert dies weiter: Kein privilegiertes Konto sollte dauerhaften Zugriff auf ein Produktionssystem haben. Jede privilegierte Sitzung ist eine temporäre Gewährung mit einem definierten Beginn, einem definierten Ende und einem vollständigen Prüfprotokoll. Wenn keine Sitzung aktiv ist, existiert kein privilegierter Zugriff.
Der praktische Unterschied zwischen traditionellem PAM und JIT/ZSP:
- Traditionelles PAM: Die Gruppe
Domain Adminshat 15 Mitglieder. Zugangsdaten befinden sich im Safe. Mitglieder checken Zugangsdaten aus, wenn sie benötigt werden. Konten existieren 24/7 auf jedem domänenbeigetretenen Server. - JIT PAM: Keine dauerhafte Mitgliedschaft in
Domain Admins. Wenn ein Systemadministrator erhöhten Zugriff benötigt, stellt er eine Anfrage für einen bestimmten Server und eine bestimmte Dauer. Das System gewährt Zugriff, erstellt eine Sitzung, zeichnet sie auf und entzieht sie nach Ablauf des Zeitfensters.
Die Angriffsfläche im traditionellen Modell ist jeder Moment, in dem das Konto existiert, gegenüber jedem System, das es erreichen kann. Die Angriffsfläche im JIT-Modell ist die Dauer der genehmigten Sitzung gegenüber dem spezifischen genehmigten Ziel.
Vor JIT vs nach JIT — ein konkretes Szenario
Vor JIT: Ein leitender Systemadministrator in einem 500-Personen-Unternehmen arbeitet seit vier Jahren im Team. Er ist dauerhaftes Mitglied der Gruppe Domain Admins und hat dauerhaften RDP-Administratorzugriff auf etwa 200 Server — Entwicklung, Staging und Produktion. Er nutzt diesen Zugriff aktiv für vielleicht 20 Server regelmäßig. Die restlichen 180 sind Infrastruktur, die er während einer Migration konfiguriert und seitdem nicht berührt hat. Seine Zugangsdaten befinden sich im Unternehmens-SSO, sein Konto wurde nie auf Bereichsreduzierung überprüft, und sein Zugriff hat sich seit seinem Eintritt nicht verändert.
Als sein Laptop durch einen gezielten Phishing-Angriff kompromittiert wird, hat der Angreifer sofortigen, dauerhaften, unbestrittenen Zugriff auf alle 200 Server. Der Strahlungsradius umfasst die gesamte Infrastruktur.
Nach JIT: Derselbe Administrator hat keinen dauerhaften privilegierten Zugriff. Wenn er Wartungsarbeiten an einem bestimmten Produktionsserver durchführen muss, stellt er eine Anfrage: „Ich benötige RDP-Administratorzugriff auf prod-db-03 für 4 Stunden, um das vierteljährliche Patch anzuwenden." Die Anfrage wird von seinem Manager und einem Mitglied des Sicherheitsteams über einen Slack-Genehmigungsworkflow überprüft. Nach Genehmigung weist das System ein zeitlich begrenztes Zugangsdaten-Set zu, das auf diesen spezifischen Server zugeschnitten ist. Die Sitzung wird von Anfang bis Ende automatisch aufgezeichnet. Nach 4 Stunden wird der Zugriff entzogen und das Zugangsdaten-Set rotiert.
Als sein Laptop kompromittiert wird, hat der Angreifer Zugriff auf alle aktiven Sitzungen, die in diesem Moment existieren. Wenn keine Sitzung gerade genehmigt und aktiv ist, hat der Angreifer keinen privilegierten Zugriff auf Produktionssysteme. Der Strahlungsradius ist durch das begrenzt, was zum Zeitpunkt der Kompromittierung genehmigt und aktiv war — nicht durch die gesamte historische Zugangsfläche der Administratorkarriere.
JIT-Zugriff und Compliance — wie ZSP auf NIS2, SOC 2 und ISO 27001 abbildet
JIT-Zugriff und Zero Standing Privileges sind nicht nur bewährte Sicherheitspraktiken — sie werden in den Compliance-Frameworks, die Unternehmen aus Mittel- und Osteuropa und Europa erfüllen müssen, zunehmend zu expliziten Anforderungen.
NIS2 Art. 21 — Prinzip der geringsten Rechte: NIS2 verlangt, dass wesentliche Einrichtungen eine Zugangskontrolle nach dem Prinzip der geringsten Rechte implementieren. „Minimale Rechte" im NIS2-Kontext bedeutet, dass Zugriff nur in dem Umfang gewährt werden sollte, der für die Ausführung einer bestimmten Aufgabe notwendig ist. Dauerhafter Administratorzugriff auf 200 Server erfüllt diesen Test per Definition nicht — ein Administrator, der regelmäßig 20 dieser Server nutzt, hat dauerhaften Zugriff auf 180, die er nicht benötigt. JIT-Zugriff erzwingt das Prinzip der geringsten Rechte strukturell: Zugriff ist immer auf ein bestimmtes System und ein Zeitfenster des tatsächlichen Bedarfs zugeschnitten.
SOC 2 CC6.3 — Zugriffsentzug: Die SOC 2 Trust Service Criteria verlangen, dass Zugriff unverzüglich entfernt wird, wenn er nicht mehr benötigt wird. CC6.3 betrifft ausdrücklich den Zugriffsentzug bei Beendigung des Arbeitsverhältnisses, Rollenwechseln und Projektabschlüssen. JIT-Zugriff erfüllt CC6.3 automatisch: Zugriff läuft am Ende des genehmigten Zeitfensters ab, ohne manuelle Schritte zum Entzug. Die Prüferfrage — „Wie stellen Sie sicher, dass Zugriff entfernt wird, wenn er nicht mehr benötigt wird?" — hat eine deterministische Antwort: „Er läuft automatisch ab; hier ist das Prüfprotokoll jedes Sitzungsablaufs."
ISO 27001 Anhang A.9.2 — Zugriffszuweisung: ISO 27001 A.9.2.2 erfordert einen formellen Zugriffszuweisungsprozess, und A.9.2.3 erfordert, dass privilegierte Zugriffsrechte auf „Need-to-use"-Basis gewährt werden. „Need-to-use" ist die ISO 27001-Sprache für das Prinzip der geringsten Rechte und bildet direkt auf JIT ab: Zugriff sollte existieren, wenn er benötigt wird, und nicht existieren, wenn er nicht benötigt wird. A.9.2.5 verlangt regelmäßige Überprüfungen von Benutzerzugriffsrechten — bei JIT-Zugriff ist die Überprüfung kontinuierlich statt periodisch, da Zugriff für jede Sitzung von Grund auf neu gewährt wird.
Das Compliance-Argument für JIT ist einfach: Dauerhafte Berechtigungen sind strukturell unvereinbar mit dem Prinzip der geringsten Rechte, das NIS2, SOC 2 CC6.3 und ISO 27001 A.9.2 fordern. JIT ist das Implementierungsmuster, das das Prinzip der geringsten Rechte in großem Maßstab operativ umsetzbar macht.
Wie VaultPAM JIT-Zugriff implementiert
VaultPAM implementiert JIT-Zugriff durch vier integrierte Mechanismen:
Genehmigungsworkflows: Wenn ein Benutzer privilegierten Zugriff auf ein Zielsystem anfordert, leitet VaultPAM die Anfrage an den entsprechenden Genehmiger weiter — Manager, Sicherheitsteam oder beide, abhängig von der Zugriffsebene und der Systemempfindlichkeit. Genehmigungen können über die VaultPAM-Weboberfläche oder integrierte Benachrichtigungskanäle durchgeführt werden. Die Anfrage enthält das Zielsystem, die angeforderte Dauer und die Begründung, sodass der Genehmiger den Kontext für eine fundierte Entscheidung hat.
Zeitlich begrenzte Sitzungen: Jede genehmigte Zugangsgenehmigung enthält eine harte Ablaufzeit. Das Sitzungsfenster wird zum Zeitpunkt der Genehmigung festgelegt — 1 Stunde, 4 Stunden, 8 Stunden oder eine benutzerdefinierte Zeit bis zum Richtlinienmaximum. Wenn das Sitzungsfenster abläuft, entzieht VaultPAM den Zugriff automatisch. Es gibt keinen manuellen Schritt, keine Erinnerungs-E-Mail, keine Abhängigkeit von der Benutzerabmeldung. Der Zugriff hört einfach auf zu existieren.
Automatischer Ablauf und Zugangsdaten-Rotation: Bei RDP- und SSH-Sitzungen weist VaultPAM zu Beginn des genehmigten Fensters ein sitzungsspezifisches Zugangsdaten-Set zu und rotiert es beim Ablauf. Das Zugangsdaten-Set, das für die genehmigte Sitzung existierte, funktioniert nach dem Ablauf nicht mehr. Ein Angreifer, der Zugangsdaten während einer Sitzung abfängt, kann sie nach dem Schließen des Fensters nicht erneut verwenden.
Prüfprotokoll: Jede JIT-Anfrage — Einreichung, Genehmigung oder Ablehnung, Sitzungsbeginn, Sitzungsdauer, Sitzungsaufzeichnung und Ablauf — wird im unveränderlichen Prüfprotokoll von VaultPAM erfasst. Das Prüfprotokoll enthält die Identität des Genehmigers, den Genehmigungszeitstempel, den Begründungstext und die vollständige Aufzeichnung der Sitzungsaktivität. Das ist das Nachweispaket, das NIS2-Prüfanforderungen, SOC 2-Prüfer-Sampling und ISO 27001-Stichprobenkontrollen erfüllt.