Rund 80 Prozent der angezeigten Cyberspionage-Angriffe in Deutschland entfielen zuletzt auf kleine und mittlere Unternehmen, während das BSI die IT-Sicherheitslage 2025 weiterhin als angespannt bewertet (BSI-Lagebericht 2025). Ein Team von neun Personen mit zwei externen Senior-Entwicklern ist damit kein Nischenfall, sondern Teil der Statistik. Ein eigenes IAM-Team hat es trotzdem nicht.

Zugriffskontrolle entscheidet in diesem Umfeld selten über ein ausgefeiltes Modell. Sie entscheidet darüber, ob ein Zugang, der gestern richtig war, heute noch existiert. Wer Rechte vergibt und niemanden benennt, der sie wieder entzieht, betreibt keine Zugriffskontrolle, sondern eine Sammlung von Gewohnheiten.

Der harte Test: Ein Team beherrscht Zugriffskontrolle, wenn es für jeden bestehenden Zugang in fünf Minuten begründen kann, warum er noch gebraucht wird und wann er endet.

Der Unterschied zwischen einem Zugriffsmodell und einer Zugriffsroutine ist der Unterschied zwischen einer Zeichnung und einem laufenden Betrieb. Ohne Modell weiß niemand, welche Rolle welche Aktion auslösen darf. Ohne Routine bleibt das Modell ein Dokument, das niemand liest.

Drei Modelle für eine Frage – wer darf was?

Jede Zugriffsentscheidung lässt sich auf einen Satz reduzieren: Welche Identität darf mit welcher Aktion auf welche Ressource zugreifen? Das Bundesamt für Sicherheit in der Informationstechnik (BSI) zerlegt diese Frage in drei Schritte, und die Reihenfolge ist nicht verhandelbar.

Zuerst steht die Identifikation: Wer ist das überhaupt. Danach die Authentisierung, also der Nachweis, etwa Passwort plus Gerätezertifikat oder ein Passkey. Erst dann folgt die Autorisierung, die eigentliche Zugriffskontrolle: Was darf diese Identität nach dem Nachweis tatsächlich nutzen. Nach der BSI-Definition muss Identifikation und Authentisierung vor jeder Interaktion zwischen Benutzer, Anwendung, Dienst und IT-System erfolgen; die Berechtigungen legen anschließend fest, welche Informationen, Dienste oder Transaktionen genutzt werden dürfen. Genau hier entstehen die meisten Fehler, weil viele Teams die drei Schritte zu einer einzigen Login-Seite zusammenziehen.

Der Ablauf ist unspektakulär, aber er erklärt, warum ein Modell allein nichts löst.

Ein Hotelschlüssel öffnet genau ein Zimmer. Ein Konferenzausweis gilt für bestimmte Räume und ein festes Zeitfenster. Beides beantwortet dieselbe Frage mit unterschiedlichen Mitteln: Der Schlüssel kodiert eine Ressource, der Ausweis kodiert eine Rolle plus Kontext.

Für Software gibt es drei verbreitete Antworten, die sich in der Entscheidungsgrundlage unterscheiden.

Die Modelle schließen sich nicht aus. In der Praxis kombiniert fast jedes belastbare Setup Rollen für den Grundzugang mit Attributen für Ausnahmen: Die Rolle „Softwareentwicklung“ öffnet das Repository, die Bedingung „nur mit verwaltetem Gerät“ schützt die produktionsnahe Umgebung. Vier Fragen bestimmen, womit ein Team startet: Wie groß ist die Mannschaft, wie viele Systeme sind angebunden, wie sensibel sind die Daten, und welche Compliance-Pflichten gelten.

Bei weniger als 30 Personen und einer Handvoll Systemen ist RBAC fast immer der richtige Einstieg, weil es ohne zusätzliche Attributquellen funktioniert. Sobald mehrere Mandanten, Datenklassen oder Standorte dazukommen, trägt das Rollenmodell die Ausnahmen nicht mehr. Unabhängig vom gewählten Modell verlangt der BSI-Grundschutz, für jede Funktion festzulegen, welche Rechte eine Person erhält und wann sie ihr wieder entzogen werden.

RBAC – Rollen als Ordnungsprinzip im Entwicklerteam

RBAC weist Berechtigungen zunächst Rollen und diese Rollen anschließend Personen zu. So lässt sich ein Teamwechsel über eine Änderung der Rollenzuordnung abbilden, statt Rechte einzeln anzupassen. Das BSI empfiehlt im IT-Grundschutz Standard-Rechteprofile, die den Funktionen und Aufgaben der Mitarbeitenden entsprechen, statt individueller Vollzugriffe (ORP 4 im IT-Grundschutz-Kompendium). Für ein Entwicklungsteam lassen sich fünf Rollen entlang der tatsächlichen Arbeit festlegen.

Softwareentwicklung schreibt in eigenen Branches und deployt nach Staging. Produktionszugriff und Secret-Zugriff gehören nicht zur Rolle. Muss jemand davon abweichen, erhält die Person eine befristete Freigabe.

Code-Review liest Staging und gibt Pull Requests frei. Schreibrechte auf den Hauptzweig sind dafür nicht erforderlich. Qualitätssicherung testet auf Staging und liest Produktionslogs; Schreibzugriff ist für diese Aufgaben nicht vorgesehen.

Betrieb deployt nach Freigabe. Im Regelbetrieb rotiert ausschließlich die Rolle Betrieb Secrets, und zwar über den Secret-Store, nicht über lokale Dateien oder Notizen im Ticket; die Administration greift nur im protokollierten Notfall darauf zu. Administration verwaltet Repository-Einstellungen und erhält Produktionszugriff nur mit Step-up-Authentisierung. Notfallzugriff wird protokolliert und zeitlich begrenzt.

Das BSI fordert Funktionstrennung im IT-Betrieb: Administrationsaufgaben und sonstige Betriebsaufgaben müssen unterschiedlichen Rollen zugeordnet sein. Auch verschiedene Betriebstätigkeiten sollen getrennte Rollen mit den jeweils erforderlichen Berechtigungen erhalten (IT-Grundschutz-Kompendium 2023). In der Matrix darf daher niemand zugleich entwickeln, freigeben und produktiv ausrollen. Die Trennung muss serverseitig greifen. Eine Prozessbeschreibung verhindert keine Aktion, wenn dieselbe Person weiterhin alle privilegierten Rechte besitzt.

Zu viele Ausnahmen führen zur Rollenexplosion. Werden Sonderfälle jeweils als eigene Rolle abgebildet, entstehen Namen wie Developer_alt_2023, deren Zweck und Gültigkeit unklar sind. Halten Sie Rollen knapp und eindeutig. Befristete Freigaben lassen sich über ein Ablaufdatum begrenzen; bei einem Teamwechsel wird die alte Zuordnung entzogen und die passende Rolle vergeben.

Attribute und Richtlinien statt starrer Rollen

Ein Entwickler wechselt für drei Monate in das Payments-Team und behält seine Rolle. In RBAC braucht er eine neue Rolle oder eine Sonderfreigabe. In ABAC ändert sich ein Attributwert, und die bestehende Regel greift sofort.

Beispielregel: Zugriff auf Ressourcen der Klasse „vertraulich“ ist erlaubt, wenn Abteilung = Payments, Gerät = verwaltet, Projektfenster aktiv und die Anfrage über den Firmen-Proxy kommt.

Attributbasierte Zugriffskontrolle zieht ihre Entscheidung aus drei Quellen: den Eigenschaften des Benutzers (Abteilung, Standort, Gerätezustand), den Eigenschaften der Ressource (Datenklasse, Projekt, Mandant) und dem Kontext (Uhrzeit, Netzwerk, Risikosignal). Der Vorteil liegt nicht in der Eleganz, sondern in der Anzahl der Regeln: Eine Bedingung wie „Datenklasse vertraulich nur mit verwaltetem Gerät“ ersetzt Dutzende projektspezifischer Rollen.

Der Preis dafür ist unangenehm konkret. Attributquellen müssen korrekt sein. Steht im HR-System die falsche Abteilung, öffnet genau diese Regel die falschen Türen, und zwar still. Der Aufwand liegt nicht im Regelwerk, sondern in der Datenpflege: Wer die Attributwerte nicht pflegt, baut ein Sicherheitsmodell auf veralteten Stammdaten.

Policy-basierte Zugriffskontrolle (PBAC) geht einen Schritt weiter und hält die Regeln zentral als Code, ausgewertet von einer Policy-Engine, versioniert, vor dem Rollout getestet und für Audits protokolliert. Open Policy Agent mit der Sprache Rego und AWS Cedar sind die zwei Beispiele, denen man in verteilten Setups am häufigsten begegnet. Der Aufwand verschiebt sich: einmalig hoch beim Aufbau der Policies, danach niedrig, solange die Engine läuft und die Attribute stimmen.

Neben der Regel gehört der Test. Eine Policy ohne Testfälle sperrt irgendwann legitime Zugriffe aus oder öffnet, was sie schließen sollte. Für jede Regel braucht es mindestens zwei Fälle: einer, der erlaubt werden muss, und einer, der abgelehnt werden muss. Beide laufen in der CI, bevor die Policy produktiv geht.

ABAC oder PBAC lohnt sich unter klaren Bedingungen: mehrere Mandanten in einer Anwendung, sensible Datenklassen, die quer zu Teams liegen, mehrere Standorte oder viele Dienste, die dieselbe Regel konsistent anwenden sollen. Fehlt eine dieser Bedingungen, ist ein sauberes Rollenmodell billiger und leichter zu prüfen.

Least Privilege und Zero Trust im Alltag

Least Privilege heißt, nur die Rechte zu vergeben, die eine Aufgabe tatsächlich benötigt. Need-to-know ergänzt das um die Frage, welche Informationen wirklich gebraucht werden. Zero Trust bedeutet, Vertrauen nicht aus dem Netzwerkstandort oder einer bestehenden VPN-Verbindung abzuleiten. Das BSI empfiehlt für solche Architekturen die Kombination aus Least Privilege, Authentisierung und Autorisierung jedes einzelnen Zugriffs sowie kontinuierliches Monitoring (BSI zu Zero Trust).

Der Zusammenhang ist mechanisch: Wird Vertrauen nicht mehr aus dem Standort abgeleitet, begrenzt ein kompromittiertes Konto den Schaden auf die Ressourcen, die seine aktuelle Policy erlaubt. Praktisch sind das sieben Kontrollen, die ein kleines Team in dieser Reihenfolge einführen kann.

1. Kurzlebige Tokens statt langlebiger Service-Credentials, idealerweise mit automatischer Rotation.
2. MFA oder phishing-resistente Authentisierung für alle Konten, die nicht ausschließlich lesend auf öffentliche Daten zugreifen.
3. Gerätebezogene Zustandsprüfungen, damit ein privates Notebook nicht dieselbe Policy erhält wie ein verwaltetes Gerät.
4. Getrennte Produktions- und Entwicklungsumgebungen, inklusive getrennter Credentials.
5. Anwendungsbezogene Policies pro Dienst statt einer pauschalen Netzwerkfreigabe.
6. Step-up-Authentisierung für Secret-Rotation, Produktionsdeployments und Datenexporte.
7. Vier-Augen-Freigabe für dieselben Aktionen, weil ein einzelner kompromittierter Account dann nicht genügt.

Direkt daneben gehört die Einschränkung: MFA verbessert die Sicherheit nicht, wenn verwaiste Konten, überbreite Rollen und unkontrollierter Drittanbieterzugriff bestehen bleiben. Die Angriffsfläche bleibt dieselbe, sie bekommt nur einen zweiten Faktor davor.

Die unangenehme Frage: Nicht „Welches Tool fehlt uns?“, sondern „Können wir belegen, dass jeder bestehende Zugriff noch benötigt wird?“

Ohne Protokollierung bleibt diese Frage unbeantwortbar. Fehlgeschlagene Anmeldungen, Rechteänderungen, ungewöhnliche Herkunftsregionen und Zugriffe außerhalb definierter Arbeitszeiten sollten zentral korreliert werden und einen Alarm auslösen, nicht in fünf verschiedenen Logs liegen. BSI-Material nennt Protokollierung, Monitoring und unverzügliche Gegenmaßnahmen ausdrücklich als Kernelemente.

Wer zuerst die Basis aufräumen will, findet in den Grundlagen zu Single Sign-On, Passwort-Management und MFA den Einstieg, weil ein zentraler Login die Voraussetzung dafür ist, dass eine Sperre überhaupt ankommt.

Für eine Scale-up-Umgebung reicht diese Reihenfolge in den meisten Fällen aus. Der Unterschied zwischen einem Team, das Zero Trust betreibt, und einem, das es beschreibt, ist selten die Technik. Es ist die Frage, wer die Liste der bestehenden Zugriffe zuletzt tatsächlich durchgesehen hat.

Onboarding, Rollenwechsel und Offboarding für Remote-Teams

Der Lebenszyklus eines externen Entwicklers ist kein Zustand, sondern ein Ablauf mit Fristen. Für wichtige und besonders wichtige Einrichtungen in Deutschland schreibt das NIS-2-Umsetzungsgesetz nach § 30 Absatz 2 Satz 2 Nummer 9 BSIG dokumentierte Konzepte für die Zugriffskontrolle vor; das BSI beschreibt Zugriffskontrolle dabei als Steuerung, Verwaltung und Begrenzung des Zugriffs auf schützenswerte Systeme durch ein Identity-and-Access-Management-System (BSI zu NIS-2 und Personalsicherheit). Auch ohne Regulierung ist ein dokumentiertes IAM-Konzept die einzige Form von Zugriffskontrolle, die sich prüfen lässt.

Onboarding beginnt vor dem ersten Arbeitstag: Antrag, fachliche Prüfung, Genehmigung, technische Einrichtung. Die Rolle erhält dabei von Anfang an ein Ablaufdatum, das im Ticket steht. Wer erst am ersten Tag Rechte anlegt, legt sie unter Zeitdruck meist zu breit an.

Rollenwechsel ist der Schritt, den Teams am häufigsten überspringen. Die alten Rechte werden am Tag des Wechsels entzogen, nicht später. Ein Entwickler, der aus dem Payments-Projekt in die Plattform wechselt, behält sonst beide Zugriffe, und niemand merkt es, weil beide legitim aussahen.

Projektende braucht keine Entscheidung, wenn der Zugang befristet war. Er läuft automatisch ab. Das ist der einzige Mechanismus, der auch dann funktioniert, wenn das Projekt chaotisch endet und niemand an Offboarding denkt.

Offboarding ist eine Frist, keine Aufgabe: Konten, SSH-Schlüssel, Tokens, Repository-Zugriffe und CI-Secrets werden innerhalb eines Arbeitstags gesperrt oder rotiert. Rotiert wird alles, was die Person lesen konnte, nicht nur das, was sie zuletzt benutzt hat. Rezertifizierung prüft monatlich die privilegierten Rechte und entfernt, was nicht mehr gebraucht wird.

Remote-spezifisch kommt eine Bedingung dazu: Private, nicht verwaltete Geräte erreichen die Produktion nicht, der Zugang läuft ausschließlich über den Firmen-Login. Voraussetzung für all das ist ein zentraler Identity Provider als einzige Quelle für Konten, damit eine Sperre ohne eigenes IAM-Team an alle Dienste weitergegeben wird. Ticketbasierte Genehmigungen mit dokumentierter Freigabe und automatischem Ablauf liefern dabei die Prüfspur, ohne Enterprise-Software.

Wer den Ablauf von der ersten Woche an sauber aufsetzen will, findet im Onboarding-Prozess für flexible Mitarbeiterpools eine brauchbare Vorlage für die organisatorische Seite; die technische Durchsetzung bleibt davon getrennt. Wie sich Konten beim Eintritt automatisieren lassen, statt Rechte von Hand zu kopieren, beschreibt der Beitrag zum effizienten Onboarding von Benutzern mit Automatisierung.

Externe Entwickler sind der Punkt, an dem dieser Ablauf am häufigsten bricht, weil ihre Konten oft außerhalb der eigenen Personalprozesse entstehen. PandaNerds vermittelt Senior-Entwickler, die als eingebettete Teammitglieder arbeiten, während Rechtevergabe und Offboarding vollständig beim Kunden bleiben und damit derselben Frist unterliegen wie bei internen Mitarbeitern.

Typische Fehler und wo Zugriffe tatsächlich scheitern

Im GDD-Praxisreport 2021 waren unbeabsichtigte Übermittlungen personenbezogener Daten an falsche Empfänger mit 47 Prozent der ausgewerteten Fälle die häufigste Ursache gemeldeter Datenschutzverletzungen (GDD-Praxisreport 2021). Der Report wertete 94 vollständige Fälle aus. Cyberangriffe machten 14 Prozent aus, System- und Konfigurationsfehler, darunter falsch gesetzte Berechtigungen, 10 Prozent. Für den Alltag heißt das: Rechte nach Aufgabe, Datenklasse und Risiko begrenzen und Änderungen nachvollziehbar protokollieren.

Vier Fehler treten besonders leicht auf, wenn ein Team keinen eigenen IAM-Betrieb hat:

1. Verwaiste Konten bleiben nach Projektende aktiv. Sie fallen oft erst auf, wenn jemand sie missbraucht oder ein Audit sie entdeckt. Verknüpfe die Sperrung mit einer festen Offboarding-Frist und einem Ticket mit Verantwortlichem.
2. Mehrere Personen nutzen dasselbe Administratorkonto. Das Protokoll zeigt dann nicht, wer eine Änderung vorgenommen hat. Nutze persönliche Admin-Konten und benenne dafür einen Owner.
3. Zugriff hängt am Team oder am VPN statt an der Identität. Eine Verbindung zum Netz belegt nicht, dass eine Person die jeweilige Ressource benötigt. Verknüpfe die Freigabe mit einer verifizierten Identität und dem konkreten Zugriffszweck.
4. Befristete Ausnahmen laufen nicht ab. Eine Freigabe für zwei Wochen kann so zum dauerhaften Recht werden. Hinterlege Owner und Ablaufdatum im Ticket und setze das Ende technisch durch.

Fehlgeleitete Datenübermittlung lässt sich nicht allein durch Login-Schutz verhindern. Für den Umgang mit vertraulichen Informationen müssen klare Freigaben und technische Grenzen zusammenspielen. Dazu gehört, Vertraulichkeit mit passenden Schutzmaßnahmen zu wahren, statt sich auf Rundmail-Erinnerungen zu verlassen.

Jede Ausnahme braucht einen Owner und ein Enddatum. Fehlt eines von beidem, bleibt das Recht dauerhaft bestehen.

Zugriffsmodell in vier Schritten festlegen

Ein Team, das seinen Zugriff neu aufsetzt, kommt mit vier Schritten aus. Sie sind bewusst in dieser Reihenfolge, weil jeder Schritt die Entscheidungen des nächsten vereinfacht.

1. Systeme und Datenklassen inventarisieren. Repositories, Cloud-Konten, Produktionsdatenbanken und SaaS-Werkzeuge auflisten, dann die Daten in jedem System klassifizieren: öffentlich, intern, vertraulich. Ohne diese Liste bleibt jede Rechtevergabe eine Vermutung.
2. Rollen aus Aufgaben ableiten. Fünf bis sieben Rollen entlang der tatsächlichen Funktionen bilden, keine individuellen Vollzugriffe. Diese Zahl ist keine Vorgabe, sondern das Ergebnis davon, dass Ausnahmen nicht als Rolle modelliert werden.
3. Ausnahmen über Attribute oder Zeitgrenzen lösen. ABAC-Regeln oder befristete Freigaben nur dort, wo das Rollenmodell nicht passt. Wichtig bleibt der Ablauf: Bevor ein Zugriff eingerichtet wird, muss eine autorisierte Person die formale Genehmigung erteilen, so wie es das BSI für kritische Infrastrukturen mit Least Privilege und Need-to-know konkretisiert (KRITIS-Konkretisierung des BSI).
4. Offboarding und monatliche Rezertifizierung als feste Prozesse. Jeder Prozess bekommt einen benannten Verantwortlichen und die Fristen aus dem Zugriffslebenszyklus. Ein Prozess ohne Namen ist eine Absicht.

Die Dokumentation ist dabei kein bürokratischer Zusatz, sondern der eigentliche Prüfnachweis. Ein Konzept, das festhält, welche berechtigten Personen auf welche Assets zugreifen dürfen und wann ein Recht endet, ist auch ohne Enterprise-Software prüfbar. Die Richtung, in die das geht, ist alt: Das IT-Sicherheitsgesetz stärkte 2015 die Anforderungen an Betreiber kritischer Infrastrukturen, nachdem das BSI bereits 1991 seine Arbeit aufgenommen hatte (BSI-Zeitstrahl). Die Verbindung aus Authentifizierung, Berechtigung, Nachweisbarkeit und organisatorischer Verantwortung ist seither gewachsen, nicht neu entstanden.

Der erste Schritt vor dem ersten Commit: eine Inventarliste mit Rollen und Ablaufdatum für jeden externen Entwickler, der ins Repository kommt.

Nur so werden Rechte nach denselben Regeln vergeben, begrenzt und entzogen, unabhängig davon, ob die Person intern sitzt oder für ein Quartal eingekauft wurde. Wer diese Liste einmal hat, kann jeden weiteren Schritt darauf aufbauen.

Wenn Sie die Rechte für externe Entwickler nicht dauerhaft selbst nachhalten wollen, ist das der Punkt, an dem PandaNerds ins Spiel kommt: Wir vermitteln geprüfte Senior-Entwickler, die sich in bestehende Teams und bestehende Prozesse einfügen, inklusive klarer Projektfenster und nachvollziehbarer Übergaben. Die Rechtevergabe bleibt bei Ihnen, der Onboarding- und Offboarding-Aufwand wird planbar. Sprechen Sie uns auf pandanerds.com an, wenn Sie Zugriffsregeln und Teamaufbau gemeinsam sauber aufsetzen wollen.