Ein Vorfall, der häufiger passiert, als viele zugeben: Nach einem Sicherheitsvorfall startet die Untersuchung - und die Spur führt zu einem Konto, das noch sechs Monate aktiv ist, obwohl die Person längst nicht mehr für euch arbeitet. Keine Mitarbeiterin, kein Mitarbeiter - ein externer Dienstleister. Jemand, der für ein dreimonatiges Projekt engagiert wurde, den Job erledigt und das Unternehmen verlassen hat. Sein Slack-Zugang, seine GitHub-Mitgliedschaft, sein Figma-Workspace, seine Zugangsdaten zur Staging-Umgebung - alles noch aktiv. Weil niemand den Zugriff entzogen hat.
Das ist kein theoretisches Beispiel. Genau diese Kategorie von Findings löst Audit-Remediation-Pläne aus, beschleunigt Gespräche mit Anbietern und endet im schlimmsten Fall mit einer aufsichtsrechtlichen Mitteilung. Fast immer ist die eigentliche Ursache dieselbe: Der externe Dienstleister hatte stehende Berechtigungen - also dauerhaften, unkontrollierten Zugriff, den niemand überwacht und niemand rechtzeitig entzogen hat.
Die Lösung ist nicht noch eine Offboarding-Checkliste. Es braucht von Tag eins an ein anderes Zugriffsmodell.
Das Problem mit "permanent, bis jemand daran denkt"
Stehende Berechtigungen - also Zugriffsrechte, die auf unbestimmte Zeit aktiv bleiben, bis sie jemand manuell entfernt - sind heute der Standard, wenn es um Zugriffsmanagement für externe Dienstleister geht. Ein Dienstleister wird onboardet, meist über ein Ticket oder eine Manager-Anfrage, bekommt "das gleiche Setup wie das Dev-Team" und legt los.
Dann endet der Vertrag. Und das Modell bricht zusammen.
Externe und befristet Beschäftigte sind für Angreifer ein ideales Ziel, gerade weil die Fluktuation hoch ist und verwaiste Konten sich ansammeln, wenn es keinen definierten Bereinigungsprozess gibt. Häufig tauchen diese Personen nicht in zentralen Systemen wie einem HRIS auf - damit wird es schwer, Statusänderungen schnell genug zu erkennen, um den Zugriff rechtzeitig zu entziehen.
Unter den Unternehmen, die Sicherheitsverletzungen erlitten haben, hatten über 65 % keine automatisierten Prozesse für Onboarding und Offboarding von Nutzenden. Diese Lücke produziert verwaiste Konten und übermäßige Berechtigungen, die Angreifer ausnutzen.
Die Mathematik ist gnadenlos. Ein Unternehmen mit 30 aktiven externen Dienstleistern, die jeweils 8-10 Apps nutzen, in dreimonatigen Engagements rotieren - das sind potenziell Hunderte von Zugriffsgewährungen, die jedes Quartal über Dutzende von Apps hinweg nachverfolgt, angepasst und wieder entzogen werden müssen. Manuell. Dienstleister und Vendoren behalten oft lang gültige Credentials, weil der Entzug übersehen wird oder automatisierte Prozesse nicht korrekt konfiguriert sind.
Security-Forscher stellten fest, dass 27 % der Cloud-Breaches im Jahr 2024 auf den Missbrauch inaktiver Zugangsdaten zurückgingen - viele davon verknüpft mit verwaisten Konten. Das Modell der stehenden Berechtigungen schafft genau diese Bedingungen: breiter Zugriff, kein Ablaufdatum, niemand schaut hin.
Warum stehende Berechtigungen für Dienstleister ein Strukturproblem sind
Es lohnt sich, genau hinzuschauen, warum das immer wieder passiert - denn die Antwort lautet nicht "das IT-Team ist faul". Das Problem ist architektonisch.
Die meisten Identity-Governance-Programme wurden für Festangestellte mit HR-Stammdatensatz gebaut. Wenn ein Mitarbeitender austritt, löst das einen Lifecycle-Event aus, SSO wird deaktiviert und (für SCIM-fähige Apps) startet die Deprovisionierung. Das System funktioniert - für Mitarbeitende, für SCIM-fähige Applikationen, während der regulären Geschäftszeiten.
Externe Dienstleister durchbrechen jede einzelne dieser Annahmen:
- Kein HR-Datensatz. Sie existieren in einer Tabelle, einem E-Mail-Thread oder einem Vendor-Management-Portal - aber nicht im HRIS, das eure Lifecycle-Automatisierung triggert.
- Kein standardisierter Offboarding-Event. Wenn ein Vertrag endet, erfährt die IT oft erst Wochen später davon - falls überhaupt.
- Breiter Anfangszugriff, der nie überprüft wird. "Gib ihnen erstmal, was das Dev-Team hat" ist die häufigste Provisioning-Anweisung - und sie wird später nie zurückgedreht.
- Konten außerhalb des SSO-Perimeters. Dienstleister werden häufig mit privaten E-Mail-Adressen in Projekt-Tools eingeladen, bekommen Shared Accounts für Kundenportale oder direkte Credentials für Apps, bei denen das Unternehmen keine SSO-Lizenzen bezahlt. Einen Account in Okta zu deaktivieren, ändert dort gar nichts.
Erstaunliche 14 % der Security-Verantwortlichen geben an, sie hätten "keine Ahnung", wie viele stehende Berechtigungen in ihren Cloud-Plattformen existieren, und 10 % der Organisationen berichten von "keiner Sichtbarkeit" auf privilegierte Zugriffe in ihren Multi-Cloud-Umgebungen. Für externe Dienstleister - die oft komplett außerhalb des getrackten Perimeters liegen - ist diese Identity Blindspot noch größer.
Stehende Berechtigungen für Dienstleister sind kein Prozessversagen. Es ist ein Designfehler. Das ursprüngliche Modell wurde für Vollzeitangestellte entworfen und skaliert schlicht nicht auf alle anderen, die ebenfalls mit euren Systemen arbeiten.
Was zeitlich begrenzter Zugriff und JIT Provisioning wirklich bedeuten
Diese Begriffe werden oft synonym verwendet, beschreiben aber unterschiedliche - und sich ergänzende - Kontrollen.
Just-in-Time Zugriff (JIT Provisioning) bedeutet, dass Zugriffe bei Bedarf erstellt werden - genau in dem Moment, in dem sie benötigt werden - statt vorab zugewiesen und dann ungenutzt herumzuliegen. Versucht ein Nutzer, auf eine bestimmte Anwendung zuzugreifen, wird sein Account dynamisch mit den benötigten Berechtigungen angelegt oder aktualisiert. Ist die Aufgabe erledigt oder ein definierter Zeitraum abgelaufen, wird der temporäre Zugriff automatisch entzogen oder der Account deprovisioniert. Dieser temporäre Zugriff ist für externe Dienstleister, Zeitarbeitskräfte und projektbasierte Rollen entscheidend - sie erhalten genau dann Zugriff, wenn er nötig ist, und nur so lange, wie das Prinzip der geringsten Rechte es zulässt.
Zeitlich begrenzter Zugriff bedeutet, dass jede Zugriffsgewährung ein klares Ablaufdatum hat - ein Datum oder eine Bedingung, zu der der Zugriff automatisch endet, ohne dass irgendjemand aktiv daran denken muss. Der Zugriff "vernichtet sich selbst" nach Plan.
Für externe Dienstleister funktioniert das richtige Modell nur in der Kombination:
- Der Zugriff wird zu Beginn des Engagements schnell bereitgestellt (JIT - kein wochenlanges Warten auf IT-Tickets)
- Er wird fein granular auf das zugeschnitten, was wirklich gebraucht wird (konkrete Repositories, Channels oder Projekte - nicht "das komplette Setup des Teams")
- Er erhält ein hartes Enddatum, das an das Vertragsende oder ein Projekt-Milestone gekoppelt ist
- Der Entzug ist automatisiert, nachprüfbar und über jede betroffene App hinweg protokolliert
Die Einführung von Just-in-Time Zugriff mit ephemeren (nicht stehenden) Berechtigungen für alle Identitäten - sowohl menschliche als auch Service-Accounts - über mehrere Plattformen hinweg ist ein entscheidender erster Schritt im Privileged Access Management.
Der Kontrast zum Standardmodell könnte größer kaum sein:
| Zugriffsattribut | Ständige Berechtigungen (Stand heute) | Zeitgebundener / JIT-Zugang (Beste Praxis) |
|---|---|---|
| Dauer | Permanent - bis jemand daran erinnert, es zu widerrufen | Auf Projekt, Sprint oder einen bestimmten Zeitraum beschränkt |
| Geltungsbereich | Weit gefasst - 'das gleiche Setup wie das Entwicklungsteam' | Feinkörnig - spezifische Repos, Kanäle, Projekte |
| Offboarding-Auslöser | Manuelles Ticket (oder nichts) | Automatisch - läuft gemäß Richtlinie oder dem Vertragsende ab |
| Risiko verwaister Konten | Hoch - Konten überdauern Verträge um Monate | Minimal - Zugriff wird planmäßig automatisch beendet |
| Audit-Verlauf | Fragmentiert, schwer rekonstruierbar | Vollständig - jede Gewährung und jeder Widerruf protokolliert |
| Compliance-Status | Reaktiv - beim Audit entdeckt | Kontinuierlich - in Echtzeit durchgesetzt |
| Schadensradius | Breit - Angreifer erbt alle bestehenden Berechtigungen | Eng - auf eine abgegrenzte, zeitgebundene Sitzung beschränkt |
Was kosten stehende Berechtigungen für Dienstleister euch wirklich?
Das Risiko lässt sich abstrakt leicht beschreiben. Mit dem folgenden Rechner seht ihr, wie die Zahlen konkret für eure Organisation aussehen.
Das Coverage-Problem, über das niemand spricht
Der Teil der JIT-Diskussion, den viele Plattformen lieber ausblenden: Sie können zeitlich begrenzten Zugriff nur für Apps erzwingen, die SCIM oder eine vollwertige API unterstützen.
Damit deckt ihr typischerweise nur 20-40 % der Anwendungen ab, mit denen ein externer Dienstleister tatsächlich arbeitet. Der Rest - Projektmanagement-Tools, Design-Plattformen, interne Dashboards, das alte Legacy-Portal, über das genau ein spezieller Workflow läuft - bleibt außen vor. Ihr könnt in eurer IGA-Plattform beliebig viele Ablaufregeln definieren: Wenn die Plattform die App nicht erreicht, um den Zugriff wirklich zu entziehen, ist die "Policy" nur Dokumentation.
Die SCIM-Wand ist real – und hier scheitert der zeitlich begrenzte Zugriff. Die meisten IGA-Tools erzwingen JIT- und zeitlich begrenzten Zugriff nur für Apps, die SCIM oder eine vollständige API unterstützen. Der Rest Ihres Stacks – Figma, Notion, Linear, Ihr internes Projektportal, jenes Legacy-Beschaffungswerkzeug – erhält manuelle Prozesse und Wunschdenken. Universelle Konnektoren sind der einzige Weg, den zeitlich begrenzten Zugriff über 100% der Apps durchzusetzen, mit denen ein Auftragnehmer arbeitet.
Organisationen, die keinen Just-in-Time Zugriff durchgesetzt haben, tragen ein deutlich höheres Sicherheitsrisiko und machen Compliance unnötig komplex und zeitaufwendig. Umgekehrt reduzieren Unternehmen, die JIT-basierten, temporären Zugriff breit einsetzen, die Menge an Zugriffsberechtigungen drastisch, die bei Zertifizierungs- und Rezertifizierungsprozessen geprüft werden müssen.
Dieser Vorteil materialisiert sich jedoch nur, wenn die JIT-Kontrollen tatsächlich alle Anwendungen erreichen - nicht nur die SCIM-freundlichen.
Genau diese Coverage-Lücke wird in der Kategorie "modernes IGA" weitgehend ignoriert. Plattformen mit SCIM-first-Architektur liefern zeitlich begrenzten Zugriff für einen Bruchteil des Stacks und erklären das Problem für gelöst. Die anderen 60-80 % der Applikationen - die Long-Tail-SaaS-Tools, alte Legacy-Portale, oder Systeme, bei denen man Enterprise-Pläne bewusst vermieden hat, um die SCIM-Tax nicht zu zahlen - bleiben manuellen Prozessen und gutem Willen überlassen.
Universelle Konnektoren - die über API, Browser-Automation oder proprietäre Methoden funktionieren, wenn es gar nichts anderes gibt - sind der einzige Mechanismus, der diese Lücke wirklich schließt. Kann der Konnektor Zugriff in einer App provisionieren, kann er ihn auch wieder entziehen. Kann er beim Provisioning einen zeitlich begrenzten Zugriff setzen, kann er diesen Scope konsistent durchsetzen. Genau das bedeutet "vollständige Abdeckung" im Kontext von ephemerem, zeitlich begrenztem Zugriff.
Zeitlich begrenzten Zugriff für Dienstleister implementieren: Das Fünf-Schritte-Modell
Vom Modell stehender Berechtigungen hin zu standardmäßig ephemerem Zugriff zu wechseln, ist kein "Rip-and-Replace"-Projekt. Es ist ein Wechsel von Policies und Tooling, der schrittweise erfolgen kann - beginnend bei den risikoreichsten Anwendungen und den kritischsten Dienstleister-Populationen.
Bevor ein Auftragnehmer seinen ersten Login erhält, definieren Sie genau, was er benötigt: Welche Apps, welche Ressourcen innerhalb dieser Apps (Repos, Kanäle, Projekte) und für wie lange. Dies ist nicht 'das gleiche Setup wie beim Entwicklungsteam' – es ist der minimale funktionsfähige Zugriff für das Engagement. Speichern Sie diese Parameter in Ihrer Governance-Richtlinie, nicht im Kopf von jemandem.
Eine Kalendererinnerung, 'überprüfen, ob der Auftragnehmer noch aktiv ist', ist keine Kontrollmaßnahme. Es ist ein Wagnis. Legen Sie ein festes Ablaufdatum für den Zugriff selbst fest – verknüpft mit dem Vertragsende, einem Meilenstein des Projekts oder einem definierten Zeitraum. Wenn das Datum erreicht ist, wird der Zugriff automatisch entzogen, über jede Anwendung im Geltungsbereich hinweg. Kein Ticket erforderlich.
Die meisten Tools unterstützen zeitlich begrenzten Zugriff für SCIM-fähige Apps und hören dort auf. Aber Auftragnehmer greifen auch auf Figma, Notion, Linear, interne Dashboards und Produktionsumgebungen zu, die kein SCIM bieten. Universelle Konnektoren – diejenigen, die über API, Browser-Automatisierung oder gar nichts funktionieren – sind der einzige Weg, zeitlich begrenzten Zugriff über den gesamten Stack durchzusetzen, nicht nur über die einfachen 20%.
Nach Ablauf des Zugriffsfensters verifizieren Sie, dass die Widerrufung tatsächlich stattgefunden hat – in jeder Zielanwendung, nicht nur im Identitätsanbieter. Führen Sie eine kontinuierliche Abgleichung durch, die vergleicht, was die Governance-Schicht als aktiv gelten lässt, mit dem, was tatsächlich in jeder Anwendung live ist. Jede Abweichung ist ein Alarm, kein Anlass zur Überraschung beim nächsten Audit.
Jede Gewährung, jede Änderung des Umfangs und jeder Widerruf sollten einen unveränderlichen Logeintrag erzeugen: Wer hat es genehmigt, wann wurde es gewährt, was war enthalten und wann ist es abgelaufen. Das ist kein Aufwand – es ist das Beweispaket, das die Frage Ihres Auditors beantwortet ('wer hatte zwischen diesen Daten Zugriff auf X?') in Sekunden, nicht Wochen.
Wie fein granulare Kontrolle in der Praxis aussieht
Zeitlich begrenzter Zugriff ohne fein granulare Scope-Kontrolle ist weiterhin problematisch. Einer Dienstleister-Entwicklerin zeitlich begrenzten Zugriff auf "GitHub" zu geben, ist etwas völlig anderes, als ihr zeitlich begrenzten Zugriff nur auf das eine Repository zu geben, das sie für ihr Engagement tatsächlich benötigt.
Diese Unterscheidung ist wichtig, weil:
- Blast Radius. Werden die Credentials einer Dienstleisterin während ihres aktiven Engagements kompromittiert, bedeutet breiter Zugriff, dass auch ein Angreifer breiten Zugriff erbt. Ein auf Repositories, Channels oder Projekte begrenzter Scope limitiert die Reichweite.
- Audit-Fähigkeit. Wenn Auditoren fragen: "Worauf hatte dieser Dienstleister Zugriff?" - ist "GitHub" keine verwertbare Antwort. "Auf diese drei Repositories, in diesem Zeitraum, freigegeben durch diese Person" hingegen schon.
- SoD-Compliance. Einige Zugriffskombinationen sind per se unzulässig - etwa eine externe Entwicklerin, die in Produktion pushen und gleichzeitig ihre eigenen Pull Requests freigeben kann. Fein granulare Kontrolle ermöglicht Segregation-of-Duties-Checks schon beim Provisioning, nicht erst nachträglich im nächsten Access Review.
Idens Konnektoren arbeiten über den gesamten Stack hinweg genau auf dieser Ebene - bis hinunter zu spezifischen Channels in Slack, einzelnen Repositories in GitHub, Projekten in Notion und Figma oder Environments in Cloud-Plattformen. Das ist der Unterschied zwischen Access Governance und reinem Access Management: Governance heißt, ihr trefft bewusst Entscheidungen - ihr verteilt nicht nur Rechte.
Der Compliance-Aspekt: Was Auditoren wirklich wissen wollen
Regulatorische Rahmenwerke wie GDPR, HIPAA, PCI DSS und SOX betonen alle das Prinzip der geringsten Rechte. JIT Zugriff bietet einen natürlichen Mechanismus, diese Anforderungen umzusetzen und nachzuweisen - durch kontinuierliche Durchsetzung von minimal notwendigem Zugriff, detaillierte Audit-Trails von Zugriffsanfragen, Genehmigungen und tatsächlicher Nutzung sowie zeitlich begrenzte Freigaben, die Access Sprawl verhindern.
Wenn ein SOC-2- oder ISO-27001-Auditor nach eurem Zugriffsmanagement für externe Dienstleister fragt, geht es nicht darum, ob es eine Offboarding-Policy gibt. Die eigentlichen Fragen sind:
- Könnt ihr nachweisen, wer zu einem bestimmten Zeitpunkt Zugriff auf kritische Systeme hatte?
- Könnt ihr zeigen, dass dieser Zugriff angemessen auf die Rolle zugeschnitten war (Prinzip der geringsten Rechte)?
- Könnt ihr belegen, dass der Zugriff entzogen wurde, sobald er nicht mehr benötigt wurde?
Manuelle Prozesse liefern auf alle drei Fragen unzuverlässige Antworten. Ein verwaistes Dienstleister-Konto, das drei Monate nach Vertragsende noch aktiv ist, ist ein offizieller Finding - kein "Ups". Die Remediation bezieht sich dann meist nicht auf einen Einzelfall, sondern auf eine Programm-Lücke, die eine breitere Überprüfung der Kontrollen auslöst.
Zeitlich begrenzter Zugriff, durch automatisierte Governance und unveränderbare Audit-Logs durchgesetzt, macht diese Fragen in Sekundenschnelle beantwortbar statt nervenaufreibend. Jede Gewährung, jede Scope-Änderung, jeder Entzug wird geloggt. Das Evidenzpaket ist stets aktuell. Und weil Zugriff per Policy abläuft und nicht per Erinnerung, gibt es keine verwaisten Konten mehr, die ihr mühsam erklären müsst.
Für Teams, die sich mit DORA-Enforcement, NIS2-Compliance oder jährlichen SOC-2-Audits bei kleinem IT-Team auseinandersetzen, ist das nicht nur ein Security-Upgrade - es ist der Unterschied zwischen "Wir beantworten Auditor-Fragen direkt aus dem System" und "Wir rekonstruieren drei Wochen lang Zugriffshistorien aus Excel-Listen, Screenshots und Slack-Nachrichten".
Drei Szenarien, in denen Zugriffsmanagement für externe Dienstleister besonders kritisch ist
1. Das Entwickler-Engagement
Eine Software-Firma holt für einen zweimonatigen Sprint eine externe Entwicklerin ins Team. Sie braucht Zugriff auf drei GitHub-Repositories, eine Staging-Umgebung, ein Projekt-Board in Linear und auf den Slack-Workspace des Teams - aber nur auf bestimmte Channels.
Standardmodell: Sie bekommt Developer-Zugriff auf GitHub, wird zu allen Linear-Projekten hinzugefügt und in Slack eingeladen. Danach hofft man, dass irgendjemand ein Ticket eröffnet, wenn sie das Projekt verlässt.
Modell mit zeitlich begrenztem Zugriff: Zugriff nur auf die konkret benötigten Repos, genau ein Projekt in Linear und die relevanten Slack-Channels. Ablaufdatum auf 60 Tage gesetzt. Nach Ablauf werden alle Berechtigungen automatisch entzogen - inklusive der Slack-Channels und des Linear-Projekts, die zwar kein SCIM unterstützen, aber über universelle Konnektoren gesteuert werden.
2. Das Healthcare-Provider-Portal
Eine externe Ärztin benötigt Zugriff auf ein Portal mit Patientendaten, um für einen definierten Zeitraum an Behandlungsplänen mitzuarbeiten. Stehender Zugriff ist hier nicht nur ein Security-Risiko - er ist ein HIPAA-Compliance-Problem.
Modell mit zeitlich begrenztem Zugriff: Der Zugang wird für die Dauer des Behandlungsepisoden gewährt, eng begrenzt auf die relevanten Patientenakten oder Falltypen. Endet die klinische Beziehung, läuft der temporäre Zugriff automatisch ab. Kein manueller Entzug erforderlich, vollständiger Audit-Trail inklusive.
3. Die Manufacturing-M&A-Integration
Nach einer Übernahme benötigt ein Team externer Berater temporären Zugriff, um Systeme zu integrieren. Sie werden ERP-Umgebungen, alte operative Tools und Dokumenten-Management-Plattformen anfassen - viele davon ohne SCIM-Unterstützung.
Modell mit zeitlich begrenztem Zugriff: Die Berechtigungen werden über universelle Konnektoren über den gesamten Integrations-Scope hinweg provisioniert. Das Ablaufdatum wird auf das Projektende gesetzt. Ist die Integration abgeschlossen und das Beraterteam wieder raus, wird der Zugriff auf alle Systeme - inklusive der Legacy-Umgebungen - planmäßig entzogen. Kein Restzugriff, keine verwaisten Konten, keine Audit-Findings sechs Monate später.
Fazit
Zugriff für externe Dienstleister ist kein Sonderfall. Externe und befristet Beschäftigte machen in den USA inzwischen rund 30-40 % der Workforce aus - Tendenz steigend. Identity-Governance-Programme, die nur für Vollzeitangestellte mit HRIS-Datensatz konstruiert wurden, greifen für diese Gruppe nicht - und die stehenden Berechtigungen, die sich dort ansammeln, bilden eine dauerhafte, wachsende Angriffsfläche.
Die Lösung ist architektonisch, nicht prozessual:
- Ephemeral by default. Zugriff für externe Dienstleister darf niemals dauerhaft sein. Jede Zugriffsgewährung braucht ein klares Ablaufdatum, verknüpft mit Engagement oder Projekt.
- Auf das Nötigste begrenzt. Nicht "das Setup des Dev-Teams", sondern die konkreten Repositories, Channels und Projekte, die dieser Dienstleister wirklich braucht - im Sinne des Prinzips der geringsten Rechte.
- Automatischer Entzug statt Erinnerungen. Zugriff, der per Policy ausläuft, verlässt sich nicht darauf, dass jemand rechtzeitig ein Ticket schreibt.
- Durchsetzung über den gesamten Stack. Zeitlich begrenzter Zugriff funktioniert nur, wenn die Kontrollen jede App erreichen, mit der der Dienstleister arbeitet - inklusive Tools ohne SCIM-Support.
Just-in-Time Zugriff reduziert das Insider-Threat-Risiko, indem sowohl Zeitraum als auch Umfang des Zugriffs minimiert werden. Selbst vertrauenswürdige Mitarbeitende oder Dienstleister können ein Risiko darstellen - JIT Zugriff und konsequentes Privileged Access Management mitigieren dieses Risiko direkt.
Die Werkzeuge dafür existieren. Die entscheidende Frage ist, ob eure Governance-Plattform wirklich den kompletten Stack erreicht - oder ob sie nur für 30 % eurer Apps ephemeren, zeitlich begrenzten Zugriff durchsetzt und die übrigen 70 % dem Zufall überlässt.
Was ist der Unterschied zwischen zeitlich begrenztem Zugriff und Just-in-Time (JIT) Bereitstellung?
Sie hängen zusammen, unterscheiden sich jedoch. Zeitlich begrenzter Zugriff bedeutet, eine feste Ablaufzeit für jeden Zugriff festzulegen – er ist aktiv für ein definiertes Intervall und wird automatisch widerrufen, wenn dieses Intervall endet, unabhängig davon, ob der Benutzer sich anmeldet oder nicht. Just-in-Time (JIT) Bereitstellung bedeutet, dass der Zugriff bei Bedarf erstellt wird, typischerweise, wenn sich ein Benutzer authentifiziert und ihn benötigt, statt vorab bereitgestellt zu sein und untätig zu bleiben. Für Auftragnehmer möchten Sie beides: Zugriff, der zu Beginn der Zusammenarbeit schnell erstellt wird (JIT), eng gefasst auf das, was sie benötigen, mit einer festen Ablaufzeit, wenn die Zusammenarbeit endet (zeitlich begrenzt). Keines davon allein reicht aus.
Warum löst das Deaktivieren eines Auftragnehmers in Okta oder Entra das Problem nicht?
Das Deaktivieren eines Auftragnehmers in Ihrem SSO-Anbieter entfernt dessen SSO-basierte Authentifizierung für Apps, die über diesen Anbieter verbunden sind. Doch viele Auftragnehmerkonten waren von Anfang an gar nicht in Ihrem Verzeichnis – sie wurden mit einer persönlichen E-Mail, einem gemeinsamen Konto oder einem direkten Login registriert, das SSO vollständig umgeht. Und selbst für Apps, die SSO-verbunden sind, ermöglichen einige eine direkte Authentifizierung als Fallback. Die einzige vollständige Lösung ist Governance, die den Widerruf auf Anwendungsebene erzwingt, nicht nur beim Identitätsanbieter.
Funktionieren zeitlich begrenzte Zugriffskontrollen für Apps ohne SCIM-Unterstützung?
Mit den richtigen Werkzeugen ja. Legacy IGA und die meisten 'modern en IGA'-Plattformen können zeitlich begrenzten Zugriff nur für SCIM-fähige Apps erzwingen – was typischerweise 20–40% der Apps in einem typischen SaaS-lastigen Stack abdeckt. Universelle Konnektoren, die über API, browserbasierte Automatisierung oder proprietäre Methoden funktionieren, können die Durchsetzung des zeitlich begrenzten Zugriffs auf den gesamten Stack erweitern, einschließlich Figma, Notion, Linear, Legacy-Portalen und interner Tools. Wenn Ihre Plattform eine App nicht erreichen kann, um Zugriff bereitzustellen, kann sie ihn auch nicht erreichen, um den Zugriff zu widerrufen, wenn das Zeitfenster endet.
Was gilt als 'ständiges Privileg' für einen Auftragnehmer?
Jeder Zugriff, der über den expliziten Bedarf hinaus aktiv bleibt. Wenn die GitHub-Mitgliedschaft eines Auftragnehmers, der Zugriff auf Slack-Workspaces, Notion-Workspace oder Produktionsumgebungs-Credentials noch einen Tag nach Vertragsende aktiv ist, handelt es sich um stehende Privilegien. Noch subtiler: Zugriff, der zu Beginn eines Engagements gewährt wurde und während des Projekts nie richtig dimensioniert oder überprüft wurde, ist ebenfalls effektiv ein stehendes Privileg – breit gefasst, ungeprüft und unwahrscheinlich, am Ende ordnungsgemäß bereinigt zu werden.
Wie wirkt sich JIT-Zugriff auf die Erfahrung des Auftragnehmers aus?
Bei richtiger Umsetzung bleibt der Zugriff für den Auftragnehmer weitgehend unsichtbar. Zugriff wird zu Beginn der Zusammenarbeit schnell bereitgestellt, der Auftragnehmer hat, was er für die Arbeit benötigt, und am Ende wird der Zugriff sauber entfernt. Die Reibungspunkte, die die meisten Auftragnehmer heute erleben – Tage warten auf die Erfüllung von Zugriffstickets, kein Zugriff auf die richtigen Tools oder inkonsistentes Aussperren – entstehen tatsächlich durch manuelle Bereitstellung, nicht durch JIT. Automatisierte, politikgetriebene JIT-Bereitstellung ist in der Regel schneller und konstanter als die manuelle ticketbasierte Alternative.
