Ein ehemaliger Entwickler hat vor acht Monaten ein dreimonatiges Projekt beendet. Sein GitHub-Zugriff - inklusive privater Repos, interner Tools und Staging-Umgebungen - ist immer noch aktiv. Niemand hat es bemerkt. Das IT-Team hat den Okta-Account deaktiviert, also wirkte alles erledigt. Aber dieser Entwickler war nie in Okta. Er nutzte eine private Gmail-Adresse, die am ersten Tag direkt vom Lead Engineer freigeschaltet wurde.
So sieht ein "verwaister Freelancer-Account" in der Realität aus. Kein theoretisches Risiko. Kein Sonderfall. Sondern ein absolut vorhersehbares Ergebnis eines Prozesses, der für Angestellte gebaut wurde - und jedes Mal lautlos scheitert, sobald er auf Freelancer oder externe Dienstleister trifft.
Laut U.S. Government Accountability Office machen externe Mitarbeitende inzwischen rund 30-40 % der US-Arbeitskräfte aus, und diese Zahl steigt weiter. Trotzdem gehen die meisten Programme für Identity Lifecycle Management und Berechtigungsmanagement immer noch davon aus, dass die Belegschaft ausschließlich aus Angestellten mit HRIS-Datensätzen besteht. Das stimmt längst nicht mehr. Genau in dieser Lücke zwischen dem Modell Ihrer Tools und der tatsächlichen Struktur Ihrer Organisation entstehen verwaiste Accounts, überprovisionierte Zugriffe und unangenehme Audit Findings.
Diese Anleitung ist ein praktischer Walkthrough - kein weiterer "Warum das wichtig ist"-Artikel (das haben wir bereits in unserem Beitrag zu warum Standard-JML-Automatisierung bei Freelancern bricht erklärt). Hier ist der Schritt-für-Schritt-Prozess zur Lösung: alternative Identitätsquellen, automatisierte Provisionierung, zeitlich begrenzte Zugriffe und sauberes Offboarding - auch dann, wenn es nie ein HR-Event gibt.
Das Kernproblem: Ihr JML-Prozess wurde für Angestellte gebaut
Die meisten Organisationen betreiben Joiner-Mover-Leaver-(JML-)Automatisierung auf Basis einer einzigen Annahme: Das HRIS ist die "Single Source of Truth". Mitarbeiter wird eingestellt -> HR legt einen Datensatz an -> ein Workflow startet -> Zugriffe werden provisioniert. Mitarbeiter verlässt das Unternehmen -> HR schließt den Datensatz -> SSO wird deaktiviert -> SCIM-verbundene Apps werden deprovisioniert.
Das funktioniert - solange die Person im HRIS existiert.
Freelancer und andere externe Mitarbeitende tun das meist nicht. Sie werden in Beschaffungsportalen, Systemen von Personaldienstleistern, Manager-E-Mails oder in Excel-Listen geführt. Wenn ein Freelancer-Projekt endet, wird kein HR-Datensatz geschlossen. Es gibt kein JML-Event. Keine Automatisierung läuft. Der Slack-Workspace, die GitHub-Mitgliedschaft, der Notion-Zugriff und die Jira-Instanz des Freelancers bleiben exakt so bestehen wie am ersten Tag.
Die HRIS-Falle: Die Standard-JML-Automatisierung wird ausgelöst, wenn sich ein HR-Datensatz ändert. Auftragnehmer haben in der Regel keinen HR-Datensatz – daher wird kein Ereignis ausgelöst, und kein Konto wird automatisch deaktiviert. Das ist kein Prozessfehler. Es ist eine architektonische Lücke in der Art und Weise, wie die meisten IGA-Tools entworfen wurden.
Das ist kein Versagen der IT-Teams. Es ist eine Architektur-Lücke. Die eingesetzten Tools wurden nie dafür entworfen, Identitäten zu verwalten, die außerhalb des HRIS entstehen. Solange Sie die Architektur - nicht nur den Prozess - nicht anpassen, werden Sie in einem festen Rhythmus weiter verwaiste Accounts produzieren.
Bevor Sie starten: Bewerten Sie Ihre aktuelle Gefährdung
Bevor Sie Ihren Prozess für die Zukunft neu aufsetzen, sollten Sie wissen, wie groß Ihre aktuelle Angriffsfläche ist - insbesondere im Hinblick auf verwaiste Accounts und fehlende Externe Identitätsverwaltung.
Der 7-Schritte-Prozess für sauberes Freelancer Lifecycle Management
Behandle das HRIS nicht mehr als deine einzige Quelle der Wahrheit. Kartiere jedes System, in dem Auftragnehmer-Identitäten tatsächlich existieren: Beschaffungs- bzw. Lieferantenportale, Projektmanagement-Tools (Jira, Linear), vom Manager initiierte Anfragen, Plattformen zur Vertragsverwaltung (DocuSign, Ironclad), Personalvermittlungsagenturen-Listen, und manuelle IT-Aufnahme-Tickets. Jede dieser Quellen ist eine gültige Identitätsquelle – du musst sie nur integrieren.
Zum Zeitpunkt der Onboarding eines Auftragnehmers erfassen Sie: Vertragsbeginn, Vertragsende (Pflichtfeld), Projektumfang (welche Tools, welche Repos, welche Kanäle), Zugriffs-Genehmiger (der sponsorende Manager) und Zugriffslevel (minimale Berechtigungen, nicht 'Gib ihnen, was das Dev-Team hat'). Diese Metadaten treiben die automatisierte Bereitstellung und die saubere Deprovisionierung später an. Ohne sie wird bereits ein verwaistes Konto eingerichtet.
Leite den Zugriffsantrag durch einen automatisierten Workflow, nicht durch eine Ticket-Warteschlange. Der Workflow sollte Folgendes tun: das Rollenprofil des Auftragnehmers gegen einen vordefinierten Berechtigungs-Katalog abgleichen, nur die spezifischen Apps und Berechtigungen bereitstellen, die benötigt werden (Kanalebene in Slack, Repository-Ebene in GitHub, Seitenebene in Notion – keine breiten Gruppenzuweisungen), und jede Bereitstellungsaktion mit Zeitstempel und Genehmiger für Audit-Trail-Zwecke protokollieren.
Jedes Konto eines Auftragnehmers erhält ein automatisches Ablaufdatum, das an das in Schritt 2 erfasste Vertragsende gebunden ist. Dies ist weder optional noch eine Erinnerungs-E-Mail – es ist ein harter Ablauf, der auf der Zugriffsebene durchgesetzt wird. Wenn das Datum erreicht ist, wird der Zugriff automatisch über alle verbundenen Apps widerrufen – egal, ob sie SCIM unterstützen, eine API haben oder nicht. Keine manuelle Aktion erforderlich. Keine Slack-Erinnerung mit der Aufforderung 'Bitte deprovisionieren'.
Die Rolle eines Auftragnehmers ändert sich mitten im Projekt häufiger, als Sie denken. Durchsetzen Sie quartalsweise (oder ereignisgesteuerte) Zugriffsüberprüfungen für alle aktiven Auftragnehmer-Identitäten. Die Überprüfungen sollten Folgendes aufdecken: ungenutzte Berechtigungen (Apps, in die der Auftragnehmer seit 30+ Tagen nicht eingeloggt ist), Umfangserweiterungen (Zugriff, der über die ursprüngliche Freigabe hinaus erweitert wurde) und Konten, die nicht mehr einem aktiven Vertrag oder Manager zugeordnet sind. Bereinigen Sie Berechtigungen kontinuierlich – warten Sie nicht bis zum Offboarding, um die Ausmaße zu erkennen.
Sie können nicht darauf warten, dass HR ein Kündigungs-Ereignis auslöst, das nie ausgelöst werden sollte. Richten Sie drei parallele Offboarding-Trigger ein: (1) Datumsbasiert: Das Vertragsende aus Schritt 2 löst eine automatische vollständige Deprovisionierung aus. (2) Vom Manager initiiert: Der sponsorende Manager hat eine Ein-Klick-Offboarding-Aktion, die sofort allen Auftragnehmerzugriff entfernt. (3) Inaktivitätsbasiert: Wenn ein Auftragnehmerkonto für einen konfigurierbaren Zeitraum (z. B. 30 Tage) keine Aktivität zeigt, wird es automatisch zur Sperrung und Überprüfung markiert. Auch eines dieser drei Trigger sollte ausreichen, um allen Zugriff zu schließen – einschließlich Apps außerhalb von SSO, Apps ohne SCIM und jeglicher direkter Anmeldeinformationen, die außerhalb des primären Identitätsanbieters bereitgestellt wurden.
Nach dem Offboarding wird automatisch ein Deprovisioning-Bericht erstellt: Welche Konten wurden geschlossen, zu welchem Zeitstempel, über welche Apps hinweg. Dieser Bericht dient als Audit-Beleg. Er beantwortet die Frage des Auditors - 'Können Sie bestätigen, dass dieser ehemalige Auftragnehmer keinen Zugriff mehr hat?' - in Sekunden, nicht Wochen manueller Protokollsuche. Speichern Sie ihn zusammen mit der ursprünglichen Zugrifffreigabe als vollständigen Identitäts-Lifecycle-Eintrag.
Das Offboarding-Trigger-Problem: Warum "Wir haben einen Prozess" nicht reicht
Die meisten Teams sagen auf die Frage nach Freelancer-Offboarding etwas in der Art: "Der Manager schreibt IT eine E-Mail, wenn der Vertrag endet." Das ist ein Prozess. Aber noch keine Governance.
Der Unterschied ist entscheidend. Ein Prozess hängt davon ab, dass jemand sich erinnert, reagiert und nachhält - für jeden Freelancer, jedes Projekt, jedes Team, jede Zeitzone. Governance ist automatisiert, richtlinienbasiert und hängt nicht vom Gedächtnis einzelner Personen ab.
So schneiden die gängigsten Offboarding-Trigger im Vergleich ab - und hier bricht jeder von ihnen:
| Offboarding-Auslöser | Funktionsweise | Was verpasst wird | Risikostufe |
|---|---|---|---|
| HR-Beendigungsereignis | HR schließt den Datensatz -> SSO deaktiviert -> SCIM-Apps deprovisioniert | Auftragnehmer ohne HR-Datensatz, direkte Anmeldungen, nicht-SCIM-Apps | 🔴 Hoch (für Auftragnehmer) |
| Manuelles IT-Ticket | Manager schickt IT eine E-Mail -> IT entfernt den Zugriff auf Apps manuell – App für App | Apps, die IT nicht kennt, Abgänge außerhalb der Arbeitszeiten, vergessene Tickets | 🔴 Hoch |
| Nur SSO-Deaktivierung | Okta/Entra-Konto deaktiviert -> SSO-geschützte Apps blockiert | Direkte Anmeldungen, Apps außerhalb des SSO-Gebiets, Nicht-SCIM-Integrationen | 🟠 Mittel (teilweise) |
| Datumsbasierte automatische Deprovisionierung (Vertragsende) | Vertragsende löst automatische Deprovisionierung über alle verbundenen Apps aus | Behandelt nur Apps ab, die mit der Governance-Plattform verbunden sind | 🟢 Niedrig (mit universellen Konnektoren) |
| Vom Manager initiiertes Ein-Klick-Offboarding | Manager löst sofort die vollständige Entfernung aller Zugriffe über eine einzige Oberfläche aus | Erfordert Manager-Aktion – muss in das Prozessdesign integriert sein | 🟢 Niedrig (mit passenden Werkzeugen) |
| Inaktivitätsbasierte Sperrung | Kein Login für 30+ Tage -> Konto wird automatisch gesperrt und zur Überprüfung markiert | Erfasst keinen Zugriff, der weiterhin von einer unbefugten Partei genutzt wird | 🟢 Niedrig (als Sicherheitsnetz) |
Der einzige Ansatz, der Zugriffe verlässlich ohne manuelle Aktion schließt, ist datumsbasierte Auto-Expiry - mit einer universellen Abdeckung aller Apps als Durchsetzungsmechanismus. Ohne Universal Connectors, die jede App in Ihrem Stack erreichen (ob über SCIM, API oder gar nichts davon), bleibt zeitlich begrenzter Zugriff eine Richtlinie auf Papier.
Was "alternative Identitätsquellen" in der Praxis wirklich bedeutet
Wenn Freelancer nicht in Ihrem HRIS auftauchen, müssen Sie die Systeme anbinden, in denen sie tatsächlich entstehen. So sieht das entlang der typischen Intake-Pfade für Freelancer Onboarding aus:
Beschaffungs- und Vendor-Portale
Freelancer, die über Procurement-Flows (z. B. SAP Ariba, Coupa, ServiceNow Vendor Records) beauftragt werden, haben einen Vertragsdatensatz mit Start- und Enddatum. Binden Sie dieses System als Identitätsquelle an Ihre IGA-Plattform an. Ein neuer Vendor-Datensatz löst Provisionierung aus. Eine geschlossene Bestellung bzw. ein beendeter Auftrag löst das Offboarding und die automatisierte Deprovisionierung aus.
Manager-Attestierung und IT-Intake-Formulare
Bei Freelancern, die über Manager-Anfragen (Jira-Ticket, Formular, Slack-Nachricht) ins Unternehmen kommen, wird das Intake-Formular zur Identitätsquelle - aber nur, wenn Sie von Anfang an die richtigen Daten erfassen. Ein Formular, das Name, E-Mail und "welche Zugriffe werden benötigt" abfragt, reicht nicht. Sie brauchen Vertragsenddatum, verantwortlichen Manager und konkrete Zugriffsscope. Alles darunter bedeutet, dass Sie jemanden onboarden, den Sie später nicht sauber offboarden können.
Projekt-Start-/Enddaten als Lifecycle-Signale
Bei projektbasierten Freelancern (häufig in Tech, Logistik und Consulting) ist das Projekt selbst das Lifecycle-Signal. Wenn ein Projekt in Jira, Linear oder Ihrem PSA-Tool geschlossen wird - oder wenn ein Sprint-Meilenstein erreicht ist - kann dieses Ereignis eine Freelancer-Zugriffsüberprüfung oder das Auslaufen der Berechtigungen triggern. Das funktioniert besonders gut bei Freelancern, die an einem klar definierten Deliverable arbeiten, nicht an einer offenen Dauerrolle.
Staffing-Agenturen und Workforce-Management-Systeme
Wenn Sie ein Vendor Management System (VMS) oder eine Staffing-Plattform nutzen, liegt der Freelancer Lifecycle oft zuerst dort. Eine API-Verbindung zwischen VMS und IGA-Plattform sorgt dafür, dass Freelancer Onboarding und Offboarding automatisch synchronisiert werden - ganz ohne manuelle Übergaben.
Das verbindende Prinzip: Jeder Intake-Pfad muss dieselben drei Datenpunkte liefern - Startdatum, Enddatum und Zugriffsscope - und sie in eine zentrale Governance-Schicht einspeisen, die unabhängig von der Herkunft des Freelancers konsistente Richtlinien anwendet. Genau hier setzt moderne Externe Identitätsverwaltung an.
Feingranulare Provisionierung: Der Unterschied zwischen "Zugriff" und "dem richtigen Zugriff"
Einer der häufigsten Fehler im Freelancer Onboarding ist das Berechtigungsmanagement per Analogie: "Gib ihnen das gleiche Setup wie dem Dev-Team." Schnell? Ja. Richtig? So gut wie nie.
Freelancer sollten nur die Zugriffe erhalten, die ihre konkrete Rolle und ihr Projekt erfordern - und zwar auf dem granularsten Level, das Ihre Tools zulassen. Das bedeutet zum Beispiel:
- Slack: spezifische Channels statt Workspace-weitem Zugriff
- GitHub: spezifische Repositories statt Organisation-weitem Membership
- Notion: konkrete Seiten oder Datenbanken statt voller Workspace-Zugriffe
- Jira: bestimmte Projekte statt Zugriff auf alle Projekte der Instanz
- AWS/GCP: spezifische Umgebungen statt breiter Rollen "dev" oder "prod"
Das ist keine Spitzfindigkeit. Es ist der Unterschied zwischen einem Freelancer, dessen kompromittierte Zugriffe ein einzelnes Projekt betreffen - und einem, dessen Rechte Ihre komplette Engineering-Umgebung exponieren.
Die meisten IGA-Tools enden bei SCIM-Gruppenzuordnungen. Dadurch bleibt feingranulares Berechtigungsmanagement auf Channel-, Repo- oder Projektebene ungeprüft. Suchen Sie nach einer Plattform mit Connectors, die tiefer gehen als SCIM - manche nennen das "SCIM++" -, damit die Richtlinien, die Sie definieren, auch exakt den real vergebenen Berechtigungen entsprechen. So wird Freelancer Zugriffsmanagement effektiv und revisionssicher.
Das Drei-Trigger-Offboarding-Modell
Sauberes Offboarding von Freelancern stützt sich nicht auf einen einzelnen Trigger. Es nutzt drei parallele Mechanismen - von denen jeder für sich ausreichen sollte, um sämtliche Zugriffe zu entziehen:
Trigger 1 - Datumsbasierte Expiry
Das beim Onboarding erfasste Vertragsenddatum löst am geplanten Tag eine vollautomatische Deprovisionierung aller Zugriffe aus. Kein manueller Eingriff nötig. Das ist der primäre Trigger.
Trigger 2 - Manager-initiiertes Offboarding
Der verantwortliche Manager hat einen One-Click-Offboarding-Button - in der Governance-Plattform oder eingebettet in Slack/Teams -, der alle Freelancer-Zugriffe sofort entzieht. So lassen sich vorzeitige Vertragsbeendigungen, Scope-Änderungen oder verschobene Enddaten abbilden.
Trigger 3 - Inaktivitätsbasierte Suspendierung
Wenn ein Freelancer-Account über einen definierten Zeitraum (30 Tage ist ein sinnvoller Standard) keine Log-in-Aktivität zeigt, wird er automatisch zur Suspendierung markiert und dem verantwortlichen Manager zur Prüfung vorgelegt. So fangen Sie Freelancer ab, die faktisch nicht mehr tätig sind, deren offizielles Enddatum aber noch nicht erreicht ist - und Accounts, die schlicht vergessen wurden.
Alle drei Trigger müssen Zugriffe in jeder angebundenen Anwendung deprovisionieren - inklusive Apps außerhalb des SSO-Perimeters, Apps ohne SCIM-Support und sämtlicher direkten Credentials, die am Identity Provider vorbei vergeben wurden. Ein Offboarding, das Okta-Zugang entzieht, aber GitHub, Notion und das Kundenportal unverändert lässt, ist nur ein teilweises Offboarding - und damit nichts anderes als ein verwaister Account in Zeitlupe.
Audit Readiness: Den Lifecycle jedes Freelancers sauber abschließen
Wenn ein Compliance-Framework Sie auffordert nachzuweisen, dass ein Freelancer keinen Zugriff mehr hat, brauchen Sie diesen Nachweis in Sekunden - nicht nach drei Wochen Fleißarbeit mit Screenshots, Access-Logs und Slack-Historien.
Jedes Freelancer-Offboarding sollte automatisch einen Deprovisioning-Record erzeugen: einen protokollierten Bericht mit Zeitstempel, der alle geschlossenen Accounts über alle Apps auflistet - inklusive des auslösenden Triggers und der zustimmenden oder verantwortlichen Person. Dieses Dokument bildet zusammen mit der ursprünglichen Zugriffsfreigabe aus dem Onboarding einen vollständigen Audit-Trail für den Identity Lifecycle.
Dieser Audit-Trail beantwortet Fragen wie:
- "Wer hatte zwischen Januar und März Zugriff auf dieses Repository?"
- "War Freelancer X am Tag des Vorfalls noch aktiv?"
- "Können Sie nachweisen, dass der Zugriff des ehemaligen Vendors beim Vertragsende entfernt wurde?"
Das sind reale Audit-Fragen. Die Organisationen, die sie souverän beantworten, sind nicht die mit der umfangreichsten Excel-Liste, sondern diejenigen, die ihren Identity Lifecycle - einschließlich Freelancer Onboarding und automatisierte Deprovisionierung - konsequent automatisiert haben.
Einen umfassenderen Blick darauf, wie Identity Lifecycle Management und Berechtigungsmanagement Ihre Compliance-Fähigkeit für Rahmenwerke wie SOC 2, ISO 27001 und DORA stärken, finden Sie in unserem Leitfaden zu regulatorisch bereitgestellter Identity Governance.
Wo Universal Connectors das Spiel verändern
Alles in dieser Anleitung basiert auf einer grundlegenden Fähigkeit: Zugriffe in jeder Anwendung Ihres Stacks provisionieren und deprovisionieren zu können - nicht nur in den SCIM-fähigen.
Laut von C1 zitierter Forschung haben 89 % der Unternehmen weniger als die Hälfte ihrer Anwendungen mit ihrer IGA-Lösung integriert - der Großteil der Umgebung bleibt also ungeregelt. Freelancer greifen zudem häufig genau auf die Tools zu, die außerhalb des SSO-Perimeters liegen (Projektmanagement-Tool, Analytics-Dashboard, Design-Plattform auf dem Free-Tarif) und vergrößern diese Lücke damit weiter.
Idens Universal Connectors unterstützen 175+ Anwendungen, darunter auch Apps ohne SCIM oder APIs - ganz ohne teure Enterprise-Upgrades, nur um Automatisierung freizuschalten. Das bedeutet: Freelancer Zugriffsmanagement - inklusive der "kleinen SaaS-Tools", die sich heimlich zu kritischen Bausteinen Ihres Stacks entwickelt haben - unterliegt vom ersten Tag an demselben Identity Lifecycle Management und derselben automatisierten Deprovisionierung wie Ihre SCIM-verbundenen Kernanwendungen.
Wenn das Enddatum eines Freelancers erreicht ist, wird Offboarding in jeder angebundenen Anwendung automatisch ausgelöst. Nicht nur in Okta. Nicht nur in den Apps mit SCIM. In allen. Genau das braucht es, wenn Sie wirklich keine Offboardings mehr verpassen wollen - und verwaiste Accounts konsequent vermeiden.
Die wichtigsten Erkenntnisse
- Freelancer haben keine HRIS-Datensätze - JML-Automatisierung, die ausschließlich von HR-Events abhängt, wird für sie nie feuern. Sie benötigen alternative Identitätsquellen und eine saubere Externe Identitätsverwaltung.
- Erfassen Sie beim Onboarding drei zentrale Datenpunkte: Vertragsenddatum, verantwortlichen Manager und granulare Zugriffsscope. Ohne diese Informationen ist sauberes Offboarding unmöglich.
- Nutzen Sie drei parallele Offboarding-Trigger: datumsbasierte Expiry, managerinitiierte Entfernung und inaktivitätsbasierte Suspendierung. Jeder einzelne sollte ausreichen, um alle Zugriffe zu schließen.
- Feingranulare Zugriffe sind entscheidend: Provisionieren Sie auf Channel-, Repo- und Projektebene - nicht übergroße Gruppenrechte, die das eigentliche Engagement überdauern.
- Universal-Connector-Abdeckung ist die Durchsetzungsschicht: Zeitlich begrenzte Zugriffsrichtlinien sind nur so stark wie Ihre Fähigkeit, sie über 100 % Ihres Stacks hinweg technisch durchzusetzen.
- Generieren Sie Deprovisioning-Records automatisch: Ihr Audit-Trail sollte automatisch entstehen - nicht erst im Stress, wenn ein Auditor danach fragt.
Häufig gestellte Fragen
Was ist, wenn Auftragnehmer von verschiedenen Teams eingearbeitet werden und es keinen zentralen Intake-Prozess gibt?
Dies ist die häufigste Situation. Die Lösung besteht nicht darin, über Nacht einen einzigen Intake-Kanal vorzuschreiben – es geht darum, mehrere Intake-Kanäle in eine zentrale Governance-Schicht zu integrieren. Egal, ob die Anfrage aus einem Jira-Ticket, einem vom Manager eingereichten Formular, einem Beschaffungsportal oder einer API einer Personalvermittlung stammt, sollte Ihre IGA-Plattform in der Lage sein, diese Anfrage zu erfassen, die Lebenszyklus-Metadaten (Startdatum, Enddatum, Umfang) zu extrahieren und dieselbe politikgesteuerte Bereitstellungslogik unabhängig von der Quelle anzuwenden.
Kann man zeitlich begrenzten Zugriff für Apps durchsetzen, die SCIM nicht unterstützen oder keine API haben?
Ja – aber nur, wenn Ihre Governance-Plattform eine universelle Konnektorabdeckung bietet. Die meisten IGA-Tools beschränken sich auf SCIM-fähige Apps. Iden's universelle Konnektoren erreichen Apps mit SCIM, Apps mit APIs und Apps ohne beides und verwenden agentenbasierte oder UI-gesteuerte Automatisierung, um Zugriff bereitzustellen und zu entziehen, unabhängig davon, was die Anwendung nativ unterstützt. Zeitlich begrenzter Zugriff ist nur so gut wie Ihre Fähigkeit, ihn über den gesamten Stack hinweg durchzusetzen.
Welche Mindestmetadaten müssen beim Onboarding von Auftragnehmern erfasst werden, um ein sauberes Offboarding zu ermöglichen?
Mindestens: Vertragsende, der sponsornde Manager (der Offboarding-Genehmiger) und der spezifische Zugriffsumfang (welche Apps, welche Repos, welche Kanäle – nicht nur eine Rollengruppe). Mit diesen drei Datenpunkten lässt sich ein vollständig automatisierter Lebenszyklus aufbauen, der am ersten Tag Berechtigungen bereitstellt und am letzten Tag entzieht, ohne manuelle Eingriffe.
Wie gehen wir mit Auftragnehmern um, die ihren Vertrag verlängern oder in eine zweite Beauftragung zurückkehren?
Erweiterungen sollten einen erneuten Attestierungs-Workflow auslösen - der sponsorende Manager genehmigt ein neues Enddatum, und das Ablaufdatum wird automatisch aktualisiert. Für zurückkehrende Auftragnehmer behandeln Sie sie wie eine neue Bereitstellung: Überprüfen Sie erneut ihren Zugriffsbedarf, wenden Sie das Prinzip des geringsten Privilegs von Grund auf an und setzen Sie ein neues Ablaufdatum. Vermeiden Sie die Versuchung, ein altes Konto einfach zu reaktivieren, da dies oft veraltete Berechtigungen aus der vorherigen Beauftragung mit sich bringt.
Wie beweisen wir einem Auditor, dass der Zugriff eines Auftragnehmers vollständig entfernt wurde?
Ihre IGA-Plattform sollte automatisch einen Deprovisioning-Datensatz erzeugen, sobald das Offboarding abgeschlossen ist: ein zeitstempelter Bericht, der jedes Konto in jeder App auflistet, zu welchem Zeitpunkt, ausgelöst durch welches Ereignis (datumsbasiert, durch den Manager initiiert oder Inaktivität). Dieser Datensatz – zusammen mit der ursprünglichen Zugriffsfreigabe – bildet eine vollständige Audit-Trail des Identitätslebenszyklus. Keine Screenshots. Keine manuelle Protokollkorrelation. Keine Wochen Vorbereitungen.
