Ramp a réparti les rôles AWS par équipe, puis a rendu l'accès à la production temporaire et soumis à demande

Ramp est passée de moins de 100 à plus de 600 employés tout en continuant à gérer l'accès d'ingénierie backend avec 3 rôles AWS : Junior-Engineers, Engineers et Admins. Chaque nouvelle demande d'accès à une ressource obligeait l'équipe infrastructure à modifier manuellement une politique IAM, ce qui créait deux problèmes chroniques : les ingénieurs seniors accumulaient un accès persistant à la production bien plus large que leur travail réel, augmentant le rayon d'impact de la moindre erreur ou d'un compte compromis, tandis que les ingénieurs juniors devaient passer par les ingénieurs seniors pour des requêtes de routine, ce qui consumait leur temps.

La correction apportée par l'équipe comportait deux niveaux. Premièrement, un contrôle d'accès fin : ils ont remplacé les 3 rôles par plus de 20 groupes AWS SSO, un par équipe d'ingénierie, chacun défini par un module Terraform (`engineers_X.tf`) listant exactement les pipelines CI/CD, fonctions Lambda, conteneurs ECS, chemins S3 et secrets que cette équipe pouvait toucher. Cela rendait la propriété lisible : les ingénieurs pouvaient consulter le fichier de leur propre équipe pour voir leurs accès et demander des modifications via une pull request plutôt qu'un ticket infrastructure.

Deuxièmement, un accès juste-à-temps (JIT) : pour chaque rôle d'équipe, ils ont créé un rôle de production élevé correspondant, sans appartenance permanente. À l'aide de ConductorOne (déjà déployé chez Ramp pour le provisionnement des applications), les ingénieurs éligibles demandent un rôle de production ; une demande pour le rôle de leur propre équipe est approuvée automatiquement, une demande pour le rôle d'une autre équipe est routée vers le tech lead de cette équipe pour approbation, et les octrois expirent après une fenêtre choisie. Ils l'ont d'abord déployé sur une équipe, ont itéré, puis l'ont déployé à l'échelle d'AWS, et ont intégré le flux de demande dans leur CLI existante afin que les ingénieurs n'aient pas à quitter leur terminal.

Le résultat a resserré la posture de sécurité — en réduisant l'empreinte des accès permanents et en liant chaque action de production à une justification énoncée — tout en maintenant la latence entre la demande et l'accès sous 10 secondes, de sorte que le gain de sécurité ne réintroduise pas la friction du système initial basé sur des tickets.

Faire de chaque rôle de production un sur-ensemble limité dans le temps que les ingénieurs doivent demander, et non un octroi permanent

Répartir les rôles par équipe avant d'automatiser l'accès a créé une unité naturelle pour l'approbation automatique (sa propre équipe) et l'approbation routée (le propriétaire d'une autre équipe) — le JIT a besoin d'une carte de propriété pour router les demandes.

Faire des rôles de production des sur-ensembles des rôles d'équipe non-production signifiait que retirer l'accès permanent ne changeait pas ce que les ingénieurs pouvaient déjà faire au quotidien — cela ajoutait seulement une étape de demande.

Approuver automatiquement les demandes de la même équipe tout en routant les demandes inter-équipes vers un tech lead alignait la friction d'approbation sur le risque réel : ses propres ressources relèvent de la routine, celles d'autrui nécessitent un second regard.

Intégrer le flux de demande dans la CLI que les ingénieurs utilisaient déjà pour les déploiements et le SSH signifiait que l'adoption ne dépendait pas du fait de se souvenir d'ouvrir une application web séparée sous pression temporelle.

Une propriété fine doit exister avant que l'accès juste-à-temps puisse fonctionner — sans rôles délimités associés d'abord à une propriété d'équipe réelle, il n'existe aucune unité sensée à accorder ou à approuver automatiquement.

Ramp a rapporté que le déploiement du JIT a renforcé sa posture pour des référentiels comme SOC 2 et ISO 27001, où les auditeurs recherchent des accès limités dans le temps plutôt que des octrois permanents, et a réduit le périmètre d'audit en liant chaque action de production à une justification énoncée. Les leçons énoncées par l'équipe : la propriété des systèmes devait être réglée avant de construire l'outil d'accès, l'intégration de centaines d'ingénieurs a demandé plus d'efforts que la construction du flux de travail elle-même, et le choix précoce d'un fournisseur adapté à leur échelle a évité des reprises à mesure que les effectifs continuaient de croître.