El ciclo IAM en acción: una startup de cashback app

Una dimisión en viernes

Daniel, ingeniero de growth en Rebate, dimite un viernes. En cuanto RR. HH. lo marca como baja, el proveedor de identidad desactiva su identidad y todas las aplicaciones conectadas, GitHub, la consola de la nube, Slack, la plataforma de observabilidad, eliminan su cuenta en segundos. De manual. Pero el lunes alguien se da cuenta de que Daniel todavía puede entrar en cuatro herramientas: una plataforma de envío de correos, un servicio de pruebas A/B, una herramienta de mapas de calor y una app de automatización sin código que guarda claves de API con acceso a datos de producción. El equipo de growth se había dado de alta en las cuatro con una tarjeta de la empresa. Ninguna se conectó nunca al inicio de sesión único, así que ninguna se enteró de que Daniel se había ido.

Después del hospital, este es el otro extremo. El ciclo operativo y el ciclo de vida JML son los mismos, pero aquí el obstáculo no es la normativa ni las urgencias de vida o muerte. Es la velocidad. Una startup construye producto más deprisa que procesos, adopta herramientas más deprisa de lo que las gobierna y ve cada control como fricción entre ella y la próxima versión.

Rebate es una app de cashback que devuelve a sus usuarios una parte de lo que gastan en comercios asociados. Hace dieciocho meses eran doce personas en una sala. Hoy son 95 repartidas en tres husos horarios, han cerrado una ronda de serie B y tocan datos de tarjetas, conexiones bancarias y millones de cuentas de consumidores. Su pregunta de IAM no es “¿cómo navegamos un laberinto normativo?”, sino “¿cómo mantenemos los accesos en orden mientras duplicamos la plantilla cada nueve meses, sin contratar a una sola persona dedicada a IAM?”. La respuesta honesta es que con 95 personas no se construye un programa de IGA completo, ni se debe intentar. El objetivo es el bucle JML mínimo viable: altas y bajas automáticas a través del proveedor de identidad, accesos que dependen de grupos y elevación justo a tiempo para lo peligroso. Si aciertas en esas tres cosas, cubres la mayor parte del riesgo por una fracción del coste.

Cuatro poblaciones

Rebate tiene menos tipos de identidad que el hospital, pero se comportan de forma más desordenada. Unos 80 empleados a tiempo completo se contratan deprisa y se reorganizan a menudo, con Rippling como sistema de RR. HH. Unos 15 contratistas y agencias trabajan en proyectos cortos y están en los registros de contratistas del mismo sistema. Unos 3,1 millones de consumidores se dan de alta solos a través del propio sistema de identidad de clientes de la app. Y unas 250 cuentas de servicio y tokens de CI los crean los ingenieros en la nube y en el gestor de secretos, y casi nunca se retiran.

Destacan dos cosas. Los consumidores empequeñecen a la plantilla, pero la identidad de clientes es un problema aparte que resuelve la propia app; este artículo se queda en el JML de la plantilla, que es donde vive el ciclo operativo. Y las cuentas de servicio y los tokens de CI son una población que nadie gestiona: los ingenieros los crean para poder sacar algo y sobreviven a la funcionalidad, al proyecto y a veces al propio ingeniero. Son huérfanas a la espera.

El proveedor de identidad es el plano de control

Rebate no tiene una suite de IGA. Lo que tiene, y todo lo que necesita a este tamaño, es un proveedor de identidad, Okta, configurado como única puerta de entrada, con aprovisionamiento SCIM hacia todas las aplicaciones SaaS que lo admiten. El proveedor de identidad guarda qué grupo da acceso a qué aplicación, así que pertenecer a un grupo es tener acceso: añade a alguien al grupo “Engineering” y recibe GitHub, la consola de la nube, la observabilidad y la herramienta de guardias; sácalo y todo desaparece.

flowchart LR
  accTitle: El plano de control de identidad de la startup y su punto ciego
  accDescr: El sistema de RR. HH. envía eventos de alta, cambio y baja al proveedor de identidad, que asigna a los usuarios a grupos por squad. Esos grupos aprovisionan las aplicaciones SaaS automáticamente por SCIM. Fuera de este bucle está el shadow IT, herramientas SaaS que los equipos adoptan sin inicio de sesión único, a las que el bucle de aprovisionamiento no llega y que se convierten en cuentas huérfanas cuando alguien se va.
  HRIS[HRIS<br/>Rippling] -->|alta / cambio / baja| IDP[Proveedor de identidad<br/>Okta]
  IDP --> GROUPS[Grupos por squad]
  GROUPS -->|SCIM| SAAS[SaaS conectado a SSO]
  SHADOW[Shadow IT<br/>SaaS sin SSO]:::danger -.fuera del bucle.-> ORPHAN[Cuentas huérfanas<br/>al irse alguien]
  classDef danger stroke-dasharray: 5 5

Es una versión deliberadamente ligera del ciclo operativo. RR. HH. es la fuente autoritativa, el proveedor de identidad es a la vez el registro maestro y el motor de aprovisionamiento, y los grupos hacen de modelo de roles. Eso da altas y bajas automáticas y cambios de puesto por grupos, el bucle JML esencial, sin gastar nada en herramientas de IGA. El punto ciego, dibujado con línea discontinua, es todo lo que queda fuera del bucle: herramientas en las que un equipo se dio de alta con una tarjeta y una contraseña compartida y que nunca conectó al inicio de sesión único. Ese shadow IT es donde se crían las cuentas huérfanas, y ahí vivían las cuatro herramientas de Daniel.

Altas: productivos el primer día, según el squad

El flujo de alta de Rebate tiene que ser rápido, porque un ingeniero nuevo que no puede sacar nada el primer día es un coste visible en una empresa que lo mide todo en velocidad. RR. HH. dispara el evento de alta en cuanto se firma la oferta, con fecha de inicio y squad. El proveedor de identidad crea la identidad y, con plantillas de grupo por squad, asigna los accesos de nacimiento, correo, Slack, documentos y el portal de RR. HH., más los accesos del squad, de modo que un ingeniero recibe el grupo de ingeniería y una agente de soporte las herramientas de soporte. SCIM aprovisiona todas las aplicaciones conectadas antes de la fecha de inicio, y las cuentas se encienden el primer día. Los accesos sensibles, producción, el panel de pagos, las exportaciones de datos personales de clientes, no son de nacimiento. Hay que pedirlos y aprobarlos, y cada vez más tienen tiempo limitado.

La costumbre que salva a Rebate más adelante es calcular el acceso de nacimiento a partir del atributo de squad y no copiarlo de un compañero. “Configura a la persona nueva como a la anterior” parece rápido, pero la anterior puede ser una de las primeras empleadas, con dos años de concesiones acumuladas. Usa el rol como plantilla, no a una persona.

Las cuentas de servicio también son altas, y nadie las da de baja. Cada pipeline de CI, cada integración y cada cron se ejecutan como una identidad, y en Rebate se crean con prisas y nunca entran en ningún ciclo de vida. Si no se tratan como identidades de verdad, con un responsable y una fecha de caducidad, se convierten en la mayor bolsa de acceso fijo y desatendido de la empresa, justo el tipo de credencial que aparece en los análisis posteriores a las brechas.

Cambios de puesto: roles que se difuminan

En una startup el cambio de puesto es peligroso por un motivo propio de las empresas pequeñas y rápidas: los roles se difuminan todo el tiempo y nadie suelta nada. Quien sacó la funcionalidad de pagos ahora está de guardia para ella, ayuda a soporte a depurarla y saca analíticas sobre ella. Cada giro añade accesos y ninguno quita. Con 95 personas, los primeros ingenieros de Rebate tienen permisos desperdigados que no corresponden a ningún puesto actual, sedimentos acumulados concesión a concesión, cada una razonable en su momento.

Arreglarlo no exige una suite de IGA, solo una costumbre y un ritmo. Los cambios los mueven los grupos: cuando alguien cambia de squad en RR. HH., se le quita el grupo del squad antiguo y se le añade el nuevo, y como el acceso es la pertenencia al grupo, la retirada ocurre de verdad. Las revisiones trimestrales de accesos piden a cada jefe que confirme los grupos de su equipo, algo ligero que atrapa lo que se les escapó a los cambios de grupo. Y para la cola peligrosa, el acceso justo a tiempo elimina por completo el acceso fijo a los sistemas sensibles, así que no queda nada que acumular. La prueba honesta del artículo del JML se aplica aquí sin piedad: si cambiar de squad quita el acceso antiguo de forma automática, Rebate está en el nivel 3 de madurez; si solo añade, cada reorganización empeora la proliferación.

Acceso a producción justo a tiempo

La decisión más acertada de Rebate es no dejar que los ingenieros tengan acceso fijo a producción. El acceso fijo a producción es la mayor bolsa de privilegio peligroso de cualquier organización de ingeniería y la que más tiende a acumularse. Así que Rebate lo elimina. Nadie tiene acceso a producción por defecto, y los ingenieros lo piden justo a tiempo, limitado en alcance y en duración, normalmente ligado a un turno de guardia o a un incidente abierto.

sequenceDiagram
  accTitle: Acceso justo a tiempo a producción para un ingeniero de guardia
  accDescr: Un ingeniero de guardia pide acceso elevado a producción por un incidente. El broker de acceso comprueba que está en el turno de guardia activo, concede un rol con tiempo limitado, registra la concesión con la referencia del incidente y revoca el acceso automáticamente cuando vence la ventana.
  participant ENG as Ingeniero
  participant BROKER as Broker
  participant ONCALL as Guardias
  participant PROD as Producción
  ENG->>BROKER: Pide acceso a prod (incidente 4821)
  BROKER->>ONCALL: Confirma el turno de guardia activo
  ONCALL-->>BROKER: Confirmado
  BROKER->>PROD: Concede rol con tiempo limitado (2 h)
  BROKER->>BROKER: Registra la concesión con el incidente
  PROD->>PROD: Vence la ventana, acceso revocado

Ese único patrón hace mucho trabajo. Elimina la acumulación de raíz, porque no hay acceso fijo a producción que acumular. Deja un rastro limpio que une cada toque a producción con una persona, una ventana de tiempo y un motivo, justo lo que quiere ver un auditor de SOC 2 o de PCI. Y escala: a medida que crece el equipo, el broker aplica la regla a todos por igual, en lugar de depender de que la gente recuerde quién debería tener qué.

Cumplimiento sin departamento de cumplimiento

Ser pequeña no le permite a Rebate ignorar la normativa. Toca datos de tarjetas y de bancos, así que PCI DSS aplica desde el primer día, y sus socios comerciales grandes y sus inversores quieren un informe SOC 2. Los dos se fijan en lo mismo del JML: accesos concedidos según el rol, accesos retirados pronto cuando alguien se va y revisiones periódicas de accesos con pruebas. La pila ligera, el proveedor de identidad como plano de control, el aprovisionamiento SCIM, los accesos por grupos, el acceso justo a tiempo a producción y las revisiones trimestrales, produce justo las pruebas que piden esas auditorías. No es casualidad: los marcos describen la misma higiene de accesos que impide que una empresa que crece deprisa se ahogue en su propia proliferación, y construirla pronto sale más barato que añadirla después con los auditores cobrando por horas.

Las cuatro herramientas de Daniel

La baja de Daniel muestra dónde se acaba la pila ligera. Todo lo que estaba detrás del inicio de sesión único desapareció en segundos. Las cuatro herramientas de fuera seguían abiertas el lunes, y las claves de la app de automatización le habrían dejado llegar a datos reales mucho después de devolver el portátil.

Lo que hacen los equipos al respecto es concreto y vale la pena copiarlo. Ponen por escrito una regla, “sin inicio de sesión único no hay datos de la empresa”: cualquier herramienta que toque datos de clientes o de producción tiene que estar detrás del proveedor de identidad antes de que nadie la adopte, lo que obliga a plantar cara a los proveedores que cobran aparte el inicio de sesión único, o a aceptar ese riesgo de forma consciente y por escrito. Añaden una forma de descubrir SaaS, una plataforma de gestión de SaaS o un CASB, o al menos una revisión de las notas de gastos y de los registros DNS, para encontrar las herramientas en la sombra que el bucle de aprovisionamiento nunca ve. Dan a cada aplicación un responsable con nombre, encargado de dar de baja las cuentas a las que SCIM no llega. Y tienen un procedimiento de baja por escrito para la cola que queda fuera del inicio de sesión único, que se ejecuta y se marca como hecho el mismo día y no cuando alguien se acuerde. El proceso que las startups siempre se saltan es la reconciliación, listar de vez en cuando las cuentas de cada aplicación y marcar las que no corresponden a ninguna identidad. Incluso una revisión manual trimestral habría encontrado las cuatro cuentas de Daniel, y es mejor que encontrarlas en el informe de una brecha. La verdad incómoda es que el mayor riesgo de una startup al dar de baja a alguien no está en los sistemas que gestiona bien, sino en los que no gestiona en absoluto.

Lo que usan de verdad los equipos a este tamaño

Antes de que una empresa pueda justificar una suite de IGA completa, los equipos reales montan una pila reconocible que da el bucle JML a bajo coste. La gestión del ciclo de vida integrada en el proveedor de identidad, como Okta Lifecycle Management o Microsoft Entra ID Governance, mueve altas, cambios y bajas directamente desde RR. HH. Los accesos como código definen grupos y plantillas de rol en Terraform o similar, de modo que cada cambio en quién recibe qué se revisa en una pull request y tiene historial, un sustituto ligero del gobierno formal de accesos. Herramientas específicas de acceso justo a tiempo para el acceso privilegiado, como Teleport o StrongDM, o patrones nativos de la nube como los permission sets de AWS IAM Identity Center con sesiones de duración limitada, conectadas al calendario de guardias para que cada elevación responda a una necesidad real. Revisiones trimestrales de accesos, exportadas directamente del proveedor de identidad, producen las pruebas que espera un auditor de SOC 2. Y un gestor de secretos, HashiCorp Vault o un equivalente de la nube, da a cada cuenta de servicio y cada token de CI un responsable, rotación y fecha de caducidad, y cierra el hueco de las identidades no humanas.

Detrás de todo hay una dirección más que un producto: reducir al mínimo el acceso fijo y comprobar cada petición es lo que la NIST SP 800-207 describe como Zero Trust y lo que el modelo de madurez Zero Trust de CISA propone como camino, y una startup puede adoptar esa postura mucho antes de poder pagar todas las herramientas. Nada de esto es IGA empresarial, ni tiene por qué serlo. La habilidad está en montar un bucle coherente con herramientas que la empresa ya paga, apuntando en la dirección que avalan los marcos, para que “suficiente por hoy” sea también “listo para crecer mañana”.

Dos planos de identidad

Rebate tiene 3,1 millones de cuentas de consumidores y 95 personas en plantilla, y su decisión de arquitectura más importante es mantener esas dos poblaciones en planos de identidad separados: almacenes separados, modelos de amenazas separados y equipos responsables separados. El ciclo operativo y el JML de este artículo gobiernan a la plantilla; los consumidores son un problema de IAM de clientes con su propio dominio más adelante en el programa.

Los profesionales son tajantes en no difuminar esa línea, porque mezclarlas es como una cuenta de empleado comprometida se convierte en una brecha de datos de clientes. La costura que pide más cuidado son las herramientas internas de administración que actúan sobre datos de consumidores, la consola de soporte que puede leer el monedero de un usuario, el panel de operaciones que puede hacer devoluciones. Se gobiernan como herramientas de la plantilla pero afectan a los clientes, así que la buena práctica les da el trato más estricto de la empresa: nada de acceso fijo, solo elevación justo a tiempo y un registro completo de cada cuenta de consumidor que toca un empleado, el mismo tipo de rendición de cuentas que el hospital aplica a las historias clínicas. El equivalente en una app de cashback a la historia clínica de un famoso es el saldo de un usuario de alto valor, y los controles riman.

De 12 a 95 y a 500

En una startup, el IAM no es un diseño fijo; es una serie de decisiones “suficientes por ahora”, y cada una debería anticipar la siguiente etapa en lugar de acorralar a la empresa. Con unas 12 personas, Rebate funcionaba con un Google Workspace compartido en el que todos eran administradores, y la trampa era dejar que “todos somos admin” se endureciera hasta un modo dios permanente. Con unas 95, hoy, funciona con el proveedor de identidad y SCIM, grupos, acceso justo a tiempo a producción y revisiones trimestrales, y la trampa es creer que tener altas automáticas significa haber terminado. Con unas 500 necesitará IGA de verdad, minería de roles, certificaciones automatizadas y reglas de separación de funciones, y la trampa será comprar herramientas empresariales antes de que los datos estén lo bastante limpios para usarlas.

La etapa fundacional es perdonable: doce personas que confían entre sí no necesitan gestionar permisos. El peligro es arrastrar las costumbres fundacionales a la etapa de crecimiento. Los primeros ingenieros, que eran todos administradores, siguen siéndolo sin que nadie lo note, y ese acceso fijo se convierte en la acumulación de privilegios que la empresa pasará su siguiente etapa desenredando. El movimiento más útil en esa transición es convertir el proveedor de identidad en la autoridad y pasar los accesos de los propios fundadores por el mismo ciclo de vida que los de todos los demás. Que la dirección se exima a sí misma es como muere el modelo.

Pensar en lo que viene también da forma a las decisiones de hoy. Definir los accesos como código ahora significa que, cuando Rebate compre una plataforma de IGA de verdad, tendrá definiciones de roles limpias y revisables que importar, en lugar de años de concesiones puntuales que desentrañar. El momento más barato para poner en orden los datos es antes de que haya muchos.

Qué debería medir una startup

Una startup no va a montar un programa de métricas empresarial, pero un puñado de cifras dice si el bucle ligero aguanta a medida que crece la plantilla. El tiempo hasta retirar el acceso cuando alguien se va es el que más importa, y lo primero que pedirá un auditor de SOC 2. Detrás del inicio de sesión único deberían ser minutos; la distancia entre eso y la retirada completa, incluidas las herramientas que están fuera del inicio de sesión único, las cuatro de Daniel, es tu exposición real. La tasa de automatización, la parte de los cambios de acceso que hace el proveedor de identidad sin ticket, debería mantenerse; si baja a medida que creces, tu programa “automatizado” está volviendo en silencio a lo manual. El número de personas con acceso privilegiado fijo, derechos permanentes en producción o de administración, debería estar cerca de cero, y todo lo demás debería pasar por el acceso justo a tiempo. Y el número de herramientas en la sombra descubiertas cada trimestre no es un fracaso si sube; lo es no medirlo.

La prueba honesta del artículo del JML encaja muy bien en una startup. Si una baja retira el acceso en todas partes en minutos, y una reorganización quita el acceso antiguo con la misma fiabilidad con la que da el nuevo, el bucle ligero es real. Si cualquiera de las dos cosas depende de que alguien se acuerde, la empresa ha confundido ir deprisa con no mirar.

Cuando llegan los despidos

Las startups no solo crecen; también se corrigen. Una ronda que no se cierra, un giro o una reestructuración pueden acabar en unos despidos que dan de baja a veinte personas en una hora. Una salida masiva es donde un bucle JML demuestra lo que vale o fracasa en público, porque cada debilidad tolerable de una en una se vuelve grave a escala y con la tensión emocional del momento.

La buena práctica es ensayarlo antes de que sea real. RR. HH. marca la baja de todo el grupo a una hora exacta y el proveedor de identidad los desactiva y desaprovisiona a todos a la vez, no un jefe recorriendo una lista mientras los primeros en salir avisan al resto. Se revocan las sesiones y los tokens, no solo se desactivan los inicios de sesión, porque quien está en mitad de una sesión sigue trabajando hasta que caduca su token si no cortas la sesión activamente, y ese es justo el hueco que más importa cuando la salida es involuntaria. La cola que queda fuera del inicio de sesión único se resuelve con el procedimiento escrito, el mismo problema de las cuatro herramientas de Daniel multiplicado por veinte. Y las cuentas se desactivan, no se borran, y se conservan para el traspaso y para cualquier investigación, porque unos despidos son justo el momento en que más adelante puedes necesitar saber a qué accedió alguien en sus últimas horas. Una empresa que da de baja limpiamente a una persona pero se desmorona al dar de baja a veinte tiene un bucle que solo parece automatizado, y una startup tiene muchas más papeletas de vivir ese día que un hospital.

Lo que enseña Rebate

Las lecciones de Rebate valen para cualquier organización que crece deprisa con poco gobierno. Convierte el proveedor de identidad en el plano de control, porque una sola puerta de entrada es mejor que cincuenta gestionadas por separado. Trata la pertenencia a un grupo como acceso, porque si salir de un grupo quita el acceso, tus cambios de puesto funcionan. Elimina el privilegio fijo, porque no puedes acumular lo que no existe. Reconcilia, porque el shadow IT cría huérfanas y tu bucle de aprovisionamiento tiene un punto ciego, como demostró el lunes de Daniel. Y da a las cuentas de servicio un responsable y una fecha de caducidad, o sobrevivirán a todo el mundo.

La lección más profunda es que un buen IAM a escala de startup no es una versión reducida del IGA empresarial; tiene otra forma. Te apoyas en el proveedor de identidad, prefieres eliminar accesos a gobernarlos y aceptas un bucle ligero que basta hoy y está listo para crecer. El fracaso no es hacer poco; es no hacer nada y llamar “ir deprisa” a la proliferación que resulta.

Tres preguntas para ponerte a prueba

1. Rebate corta al instante las cuentas que están detrás del inicio de sesión único cuando alguien se va, y aun así un ingeniero que se fue seguía teniendo acceso a una herramienta de analítica una semana después. Explica cómo pasó y qué proceso lo habría detectado.
2. Un ingeniero dice que el acceso justo a tiempo a producción “ralentiza la respuesta a incidentes”. ¿Cómo diseñarías el flujo para que añada segundos y no minutos, sin perder el rastro de auditoría?
3. Los cinco primeros empleados de Rebate tienen accesos que no corresponden a ningún puesto actual. ¿Qué paso del JML falló durante dos años, por qué pasa más deprisa en las startups y qué ritmo lo frenaría sin contratar un equipo de IAM?