Ramp teilte AWS-Rollen pro Team auf und machte den Produktionszugriff dann temporär und beantragbar

Ramp wuchs von unter 100 auf mehr als 600 Mitarbeitende, während der Backend-Engineering-Zugriff weiterhin über 3 AWS-Rollen lief: Junior-Engineers, Engineers und Admins. Jede neue Zugriffsanfrage auf eine Ressource bedeutete, dass das Infrastrukturteam manuell eine IAM-Richtlinie bearbeitete, was zwei chronische Probleme schuf – Senior-Engineers häuften dauerhaften Produktionszugriff an, der weit über ihre tatsächliche Arbeit hinausging und den Blast Radius eines einzelnen Fehlers oder kompromittierten Kontos vergrößerte, während Junior-Engineers Routineabfragen über Senior-Engineers leiten mussten, was deren Zeit band.

Die Lösung des Teams hatte zwei Ebenen. Erstens feingranulare Zugriffskontrolle: Sie ersetzten die 3 Rollen durch über 20 AWS-SSO-Gruppen, eine pro Engineering-Team, jede definiert durch ein Terraform-Modul (`engineers_X.tf`), das genau auflistet, auf welche CI/CD-Pipelines, Lambda-Funktionen, ECS-Container, S3-Pfade und Secrets das jeweilige Team zugreifen darf. Dadurch wurde die Zuständigkeit nachvollziehbar – Engineers konnten die Datei ihres eigenen Teams lesen, um ihren Zugriff zu sehen, und Änderungen per Pull Request statt per Infrastruktur-Ticket beantragen.

Zweitens Just-in-Time-Zugriff (JIT): Für jede Team-Rolle erstellten sie eine passende erhöhte Produktionsrolle ohne dauerhafte Mitgliedschaft. Über ConductorOne (bereits bei Ramp für die App-Bereitstellung im Einsatz) beantragen berechtigte Engineers eine Produktionsrolle; eine Anfrage für die Rolle des eigenen Teams wird automatisch genehmigt, eine Anfrage für die Rolle eines anderen Teams wird an den Tech Lead dieses Teams zur Genehmigung weitergeleitet, und Genehmigungen laufen nach einem gewählten Zeitfenster ab. Sie führten es zuerst in einem Team ein, iterierten und setzten es dann AWS-weit ein, und betteten den Antragsablauf in ihre bestehende CLI ein, sodass Engineers ihr Terminal nicht verlassen mussten.

Das Ergebnis straffte die Sicherheitslage – der Umfang des dauerhaften Zugriffs schrumpfte und jede Produktionsaktion war an eine angegebene Begründung geknüpft – während die Latenz vom Antrag bis zum Zugriff unter 10 Sekunden blieb, sodass der Sicherheitsgewinn nicht die Reibung wieder einführte, die das ursprüngliche ticketbasierte System hatte.

Jede Produktionsrolle zu einer zeitlich begrenzten Obermenge machen, die Engineers beantragen müssen, statt einer dauerhaften Gewährung

Die Aufteilung der Rollen nach Team vor der Automatisierung des Zugriffs schuf eine natürliche Einheit für die automatische Genehmigung (eigenes Team) und die weitergeleitete Genehmigung (Eigentümer eines anderen Teams) – JIT braucht eine Zuständigkeitskarte, gegen die Anfragen weitergeleitet werden können.

Dadurch, dass Produktionsrollen Obermengen der Nicht-Produktions-Teamrollen waren, änderte das Entfernen des dauerhaften Zugriffs nicht, was Engineers im Alltag ohnehin tun konnten – es kam nur ein Antragsschritt hinzu.

Die automatische Genehmigung von Anfragen des eigenen Teams, während teamübergreifende Anfragen an einen Tech Lead weitergeleitet wurden, brachte die Genehmigungsreibung mit dem tatsächlichen Risiko in Einklang: Die eigenen Ressourcen sind Routine, die anderer erfordern einen zweiten Blick.

Die Einbettung des Antragsablaufs in die CLI, die Engineers bereits für Deployments und SSH nutzten, bedeutete, dass die Akzeptanz nicht davon abhing, unter Zeitdruck daran zu denken, eine separate Web-App zu öffnen.

Feingranulare Zuständigkeit muss bestehen, bevor Just-in-Time-Zugriff funktionieren kann – ohne zuvor abgegrenzte Rollen, die echter Team-Zuständigkeit zugeordnet sind, gibt es keine sinnvolle Einheit, die gewährt oder automatisch genehmigt werden kann.

Ramp berichtete, dass die JIT-Einführung die Sicherheitslage für Frameworks wie SOC 2 und ISO 27001 stärkte, bei denen Prüfende zeitlich begrenzten Zugriff gegenüber dauerhaften Gewährungen suchen, und den Prüfungsumfang verringerte, indem jede Produktionsaktion an eine angegebene Begründung geknüpft wurde. Die vom Team genannten Lehren: Die Systemzuständigkeit musste geklärt sein, bevor das Zugriffstool gebaut wurde, die Einführung für Hunderte von Engineers erforderte mehr Aufwand als der Aufbau des Workflows selbst, und die frühzeitige Wahl eines für ihre Größenordnung geeigneten Anbieters ersparte Nacharbeit, während die Mitarbeiterzahl weiter wuchs.