Ramp dividió los roles de AWS por equipo y luego hizo que el acceso a producción fuera temporal y sujeto a solicitud

Ramp pasó de menos de 100 a más de 600 empleados mientras seguía gestionando el acceso de ingeniería de backend con 3 roles de AWS: Junior-Engineers, Engineers y Admins. Cada solicitud de acceso a un nuevo recurso obligaba al equipo de infraestructura a editar a mano una política de IAM, lo que generaba dos problemas crónicos: los ingenieros sénior acumulaban acceso persistente a producción mucho más amplio que su trabajo real, lo que aumentaba el radio de impacto de cualquier error individual o cuenta comprometida, mientras que los ingenieros júnior tenían que canalizar las consultas rutinarias a través de los sénior, consumiendo su tiempo.

La solución del equipo tuvo dos capas. Primero, control de acceso granular: sustituyeron los 3 roles por más de 20 grupos de AWS SSO, uno por equipo de ingeniería, cada uno definido por un módulo de Terraform (`engineers_X.tf`) que enumeraba exactamente qué canalizaciones de CI/CD, funciones Lambda, contenedores ECS, rutas de S3 y secretos podía tocar ese equipo. Esto hizo legible la propiedad: los ingenieros podían leer el archivo de su propio equipo para ver su acceso y solicitar cambios mediante una pull request en lugar de un ticket de infraestructura.

Segundo, acceso justo a tiempo (JIT): para cada rol de equipo, crearon un rol de producción elevado correspondiente sin membresía permanente. Usando ConductorOne (ya desplegado en Ramp para el aprovisionamiento de aplicaciones), los ingenieros elegibles solicitan un rol de producción; una solicitud para el rol de su propio equipo se aprueba automáticamente, una solicitud para el rol de otro equipo se dirige al líder técnico de ese equipo para su aprobación, y las concesiones caducan tras una ventana elegida. Lo desplegaron primero en un equipo, iteraron y luego lo desplegaron en todo AWS, e integraron el flujo de solicitud en su CLI existente para que los ingenieros no tuvieran que salir de su terminal.

El resultado reforzó la postura de seguridad —reduciendo la huella de acceso permanente y vinculando cada acción en producción a una justificación declarada— mientras mantenía la latencia entre solicitud y acceso por debajo de 10 segundos, de modo que la mejora de seguridad no reintrodujo la fricción que tenía el sistema original basado en tickets.

Convertir cada rol de producción en un superconjunto temporal que los ingenieros deben solicitar, no en una concesión permanente

Dividir los roles por equipo antes de automatizar el acceso creó una unidad natural para la aprobación automática (el propio equipo) y para el enrutamiento de aprobaciones (el propietario de otro equipo): el JIT necesita un mapa de propiedad sobre el que enrutar las solicitudes.

Hacer que los roles de producción fueran superconjuntos de los roles de equipo no productivos significó que eliminar el acceso permanente no cambiara lo que los ingenieros ya podían hacer en su día a día: solo añadió un paso de solicitud.

Aprobar automáticamente las solicitudes del mismo equipo mientras las solicitudes entre equipos se dirigían a un líder técnico ajustó la fricción de aprobación al riesgo real: tus propios recursos son rutinarios, los de otro requieren una segunda revisión.

Integrar el flujo de solicitud en la CLI que los ingenieros ya usaban para despliegues y SSH hizo que la adopción no dependiera de recordar abrir una aplicación web separada bajo presión de tiempo.

La propiedad granular debe existir antes de que el acceso justo a tiempo pueda funcionar: sin roles delimitados asignados primero a la propiedad real de los equipos, no hay una unidad sensata que conceder o aprobar automáticamente.

Ramp informó que el despliegue de JIT reforzó su postura para marcos como SOC 2 e ISO 27001, donde los auditores buscan acceso temporal en lugar de concesiones permanentes, y redujo el alcance de la auditoría al vincular cada acción en producción a una justificación declarada. Las lecciones declaradas por el equipo: la propiedad del sistema tuvo que resolverse antes de construir la herramienta de acceso, incorporar a cientos de ingenieros requirió más esfuerzo que construir el flujo de trabajo en sí, y elegir pronto un proveedor adecuado a su escala ahorró retrabajo a medida que seguía creciendo la plantilla.