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

El mismo ciclo de vida, el campo de batalla opuesto

Tras el hospital, nos vamos al otro extremo. El ciclo operativo y el ciclo de vida JML son los mismos — pero aquí el obstáculo no es la complejidad regulatoria ni la seguridad del paciente. Es la velocidad. Una startup construye producto más rápido de lo que construye proceso, adopta herramientas más rápido de lo que las gobierna, y trata cada control como fricción entre ella y el próximo release.

Conoce a Rebate — una cashback app que paga a los usuarios una porción de lo que gastan en comercios aliados. Hace dieciocho meses eran doce personas en una sala. Hoy son 95 en tres husos horarios, tras levantar una Serie B, y ahora toca datos de tarjeta, conexiones bancarias y millones de cuentas de consumidores. La pregunta de IAM no es “cómo manejamos nuestro laberinto regulatorio” — es “cómo mantenemos el acceso sano mientras duplicamos plantilla cada nueve meses sin contratar ni un solo ingeniero de IAM dedicado”.

La organización y sus poblaciones de identidad

Las poblaciones de Rebate son más simples en número que las del hospital pero más desordenadas en comportamiento:

Dos cosas destacan. Primero, la población de consumidores empequeñece a la plantilla — pero la identidad de consumidor (CIAM) es un problema aparte gobernado por la propia app; este artículo se queda en el JML de la plantilla, que es donde vive el ciclo operativo. Segundo, las cuentas de servicio y los tokens de CI son una población que nadie gestiona: los ingenieros las crean para lanzar, y sobreviven al feature, al proyecto y a veces al ingeniero. Son huérfanas esperando a ocurrir.

El proveedor de identidad es todo el plano de control

Rebate no tiene una suite IGA. Lo que tiene — y todo lo que necesita a este tamaño — es un proveedor de identidad (Okta) cableado como puerta de entrada única, con aprovisionamiento SCIM hacia cada app SaaS que lo soporte. El IdP guarda los mapeos de grupo-a-app, así que la membresía de grupo es acceso: agrega a alguien al grupo “Ingeniería” y queda aprovisionado en GitHub, la consola cloud, el stack de observabilidad y la herramienta de guardia; quítalo y todo se desaprovisiona.

flowchart LR
  accTitle: El plano de control de identidad de la startup y su punto ciego
  accDescr: El HRIS envía eventos de contratación, cambio y terminación al proveedor de identidad, que asigna usuarios a grupos basados en squad. Esos grupos aprovisionan apps SaaS automáticamente vía SCIM. Fuera de este bucle está el shadow IT — herramientas SaaS adoptadas por equipos sin SSO — que el bucle de aprovisionamiento no alcanza y que se vuelven cuentas huérfanas al irse alguien.
  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

Esta es una versión deliberadamente liviana del ciclo operativo: el HRIS es la fuente autoritativa, el IdP es el registro maestro y el motor de aprovisionamiento, y los grupos son el modelo de roles. Entrega joiner y leaver automáticos y un mover por grupos — el bucle JML central — sin un dólar gastado en herramental IGA. El punto ciego, dibujado con línea discontinua, es todo lo que está fuera del bucle: herramientas que un equipo contrató con una tarjeta de crédito y una contraseña compartida, nunca conectadas a SSO. Ese shadow IT es donde se crían las cuentas huérfanas.

Joiner: productivo el día uno, acotado por squad

El joiner de Rebate tiene que ser rápido — un ingeniero nuevo que no puede lanzar el día uno es un costo visible en una empresa que mide todo en velocidad. El flujo:

• El HRIS dispara el evento de contratación en cuanto se firma la oferta, con fecha de inicio y un squad.
• El IdP crea la identidad y, por plantillas de grupo basadas en squad, asigna birthright (correo, Slack, docs, el portal de RR. HH.) más el acceso de rol del squad (un ingeniero recibe el grupo de ing; un agente de soporte recibe el stack de soporte).
• SCIM aprovisiona cada app conectada antes de la fecha de inicio; las cuentas se habilitan el día uno.
• El acceso sensible — producción, el tablero de pagos, las exportaciones de PII de clientes — no es birthright. Es solicitable, con aprobación, y cada vez más acotado en el tiempo.

La disciplina que salva a Rebate más adelante es computar el birthright desde el atributo de squad, no clonar a un compañero. “Configura al nuevo como el último” se siente rápido, pero el último era un empleado de la era fundadora cargando dos años de permisos acumulados. Plantilla desde el rol, no desde una persona.

Mover: el problema del difuminado de roles

En una startup el Mover es peligroso por una razón específica de las empresas pequeñas y rápidas: los roles se difuminan constantemente y nadie suelta nada. La misma persona que lanzó el feature de pagos ahora está de guardia para él, ayuda a soporte a depurarlo y saca analítica de él. Cada pivote agrega acceso; ningún pivote lo quita jamás. Para cuando Rebate tiene 95 personas, sus ingenieros más antiguos conservan permisos dispersos que no mapean a ningún rol actual — puro sedimento, acumulado un permiso de apariencia razonable a la vez.

El arreglo no requiere una suite IGA, solo una disciplina y una cadencia:

• Movimientos por grupos: cuando alguien cambia de squad en el HRIS, su grupo de squad viejo se quita y el nuevo se agrega — y como el acceso es membresía de grupo, la remoción de verdad ocurre.
• Revisiones de acceso trimestrales: los managers confirman las membresías de grupo de su equipo. Liviano, pero atrapa el acceso que los cambios de grupo dejaron pasar.
• JIT para la cola peligrosa: en lugar de pelear el privilege creep en sistemas sensibles, quita el acceso fijo a ellos por completo (ver abajo) para que no haya nada que se acumule.

La prueba honesta de el artículo de JML aplica brutalmente aquí: si cambiar de squad quita el acceso viejo automáticamente, Rebate está en el nivel de madurez 3; si solo agrega, cada reorg empeora el desparramo.

El reto distintivo: acceso JIT a producción

El movimiento más agudo de Rebate es negarse a que los ingenieros tengan acceso fijo a producción del todo. El acceso fijo a prod es el mayor pozo de privilegio peligroso en cualquier organización de ingeniería, y es el privilegio con más probabilidad de acumularse. Así que Rebate lo elimina: nadie tiene acceso a prod por defecto, y los ingenieros lo solicitan just in time, acotado y limitado en el tiempo, normalmente atado a un turno de guardia o a un incidente activo.

sequenceDiagram
  accTitle: Acceso just-in-time a producción para un ingeniero de guardia
  accDescr: Un ingeniero de guardia solicita acceso elevado a producción para un incidente. El broker de acceso verifica que está en la rotación de guardia activa, otorga un rol acotado en el tiempo, registra el otorgamiento con la referencia del incidente, y revoca el acceso automáticamente cuando la ventana expira.
  participant ENG as Ingeniero de guardia
  participant BROKER as Broker de acceso
  participant ONCALL as Calendario de guardia
  participant PROD as Producción
  ENG->>BROKER: Solicita acceso a prod (incidente #4821)
  BROKER->>ONCALL: Confirmar turno de guardia activo
  ONCALL-->>BROKER: Confirmado
  BROKER->>PROD: Otorgar rol acotado (2h)
  Note over BROKER,PROD: Registrado con ref del incidente
  PROD->>PROD: Expira la ventana → acceso auto-revocado

Este único patrón hace un trabajo enorme. Quita el problema de creep en la fuente — no hay acceso fijo a prod que acumular. Produce un rastro de auditoría limpio que mapea cada toque de producción a una persona, una ventana de tiempo y una razón, que es justo lo que un auditor de SOC 2 o PCI quiere ver. Y escala: a medida que el equipo crece, el broker aplica la regla de manera uniforme en lugar de depender de que todos recuerden quién debería tener qué.

Cumplimiento sin departamento de cumplimiento

Rebate no puede ignorar la regulación solo por ser pequeña. Toca datos de tarjeta y banco, así que PCI-DSS aplica desde el día uno, y sus comercios aliados empresariales e inversionistas exigen un informe SOC 2. Ambos marcos se interesan por los mismos fundamentos de JML: acceso otorgado por rol, usuarios terminados desaprovisionados con prontitud, y revisiones de acceso periódicas con evidencia.

El stack liviano — IdP como plano de control, aprovisionamiento SCIM, acceso por grupos, JIT para prod, revisiones trimestrales — resulta que produce justo la evidencia que esas auditorías exigen. No es coincidencia: los marcos codifican la misma higiene de acceso que evita que una empresa de rápido crecimiento se ahogue en su propio desparramo. Construir JML temprano es más barato que retroadaptarlo bajo presión de auditoría con auditores cobrando por hora.

Un recorrido de leaver: el desparramo de SaaS en la práctica

La teoría se encuentra con la realidad cuando alguien se va. Daniel, un ingeniero de growth, renuncia un viernes. En cuanto RR. HH. lo marca como terminado, el IdP deshabilita su identidad y SCIM desaprovisiona cada app conectada — GitHub, la consola cloud, Slack, el stack de observabilidad — en segundos. Hasta aquí, de manual.

Luego aparecen los huecos. El equipo de growth adoptó cuatro herramientas con una tarjeta de la empresa que nunca se cablearon a SSO: una plataforma de email outreach, un servicio de A/B testing, una herramienta de heatmaps y una app de automatización no-code que guarda claves de API a datos de producción. Ninguna está en el IdP, así que ninguna se desaprovisiona. Daniel todavía tiene logins fijos a las cuatro el lunes — y las claves de la app de automatización le permitirían llegar a datos vivos mucho después de devolver su laptop.

Lo que los profesionales hacen al respecto es concreto y vale la pena copiar:

• “SSO o no recibe datos de la empresa” como política escrita. Cualquier herramienta que toque datos de clientes o producción debe estar detrás del IdP antes de adoptarse — empujando contra el llamado “impuesto SSO” que cobran algunos proveedores, o aceptando ese riesgo conscientemente y por escrito.
• Una capacidad de descubrimiento de SaaS — una plataforma de gestión de SaaS o un CASB, o como mínimo la revisión de reportes de gastos y logs de DNS — para sacar a la luz las apps en la sombra que el bucle de aprovisionamiento nunca ve.
• Un dueño sistema-de-registro por app, para que cada herramienta tenga un humano responsable de dar de baja las cuentas que SCIM no puede alcanzar.
• Un runbook de leaver escrito para la cola sin SSO, ejecutado y marcado el mismo día, no cuando alguien se acuerde.

La verdad incómoda es que el mayor riesgo de offboarding de la startup no son los sistemas que gestiona bien — son los que no gestiona en absoluto.

Lo que los profesionales realmente operan a esta escala

Antes de que una empresa pueda justificar una suite IGA completa, los equipos reales ensamblan un stack de buenas prácticas reconocible que entrega el bucle JML de forma barata:

• Gestión de ciclo de vida nativa del IdP como motor — Okta Lifecycle Management o Microsoft Entra ID Governance impulsan joiner/mover/leaver directo desde el feed del HRIS.
• Acceso como código: grupos y plantillas de rol definidos en Terraform o similar, de modo que cada cambio de quién-recibe-qué se revisa en un pull request y tiene historial en git — el sustituto liviano de una gobernanza de acceso formal.
• JIT a propósito para el acceso privilegiado — herramientas como Teleport o StrongDM, o patrones cloud-native (permission sets de AWS IAM Identity Center con duración de sesión acotada) — cableados al calendario de guardia para que la elevación mapee a una necesidad real.
• Una dirección de viaje Zero Trust: minimizar el acceso fijo y verificar por solicitud es justo lo que describe NIST SP 800-207 y lo que el Modelo de Madurez Zero Trust de CISA traza como camino — una startup puede adoptar la postura mucho antes de tener presupuesto para todo el herramental.
• Revisiones de acceso trimestrales, exportadas directo del IdP, produciendo la evidencia que un auditor de SOC 2 espera bajo sus criterios de control de acceso.
• Un gestor de secretos (HashiCorp Vault o un equivalente cloud-native) que da a cada cuenta de servicio y token de CI un dueño, rotación y expiración — cerrando el hueco de identidad no humana.

Nada de esto es IGA de grado empresarial, y no necesita serlo. La habilidad está en ensamblar un bucle coherente con herramientas que la empresa ya paga, apuntado en la dirección que los marcos avalan, de modo que “suficientemente bueno hoy” sea también “listo para crecer mañana”.

Identidad de plantilla y de consumidor: una empresa, dos planos

Rebate tiene 3,1 millones de cuentas de consumidor y 95 empleados, y la decisión arquitectónica más importante es mantener esas dos poblaciones en planos de identidad separados — almacenes separados, modelos de amenaza separados, equipos de registro separados. El ciclo operativo y JML de este artículo gobiernan a la plantilla; los consumidores son un problema de CIAM con su propio dominio más adelante en el programa.

Los profesionales son enfáticos en no difuminar la línea, porque mezclarlas es cómo un compromiso de plantilla se vuelve una brecha de datos de clientes. La costura que exige más cuidado es el conjunto de herramientas internas de admin que actúan sobre datos de consumidores — la consola de soporte que puede leer la wallet de un usuario, el tablero de ops que puede emitir reembolsos. Esas son gobernadas por la plantilla pero impactan al consumidor, así que la buena práctica les da el trato más estricto de toda la empresa: nada de acceso fijo, solo elevación JIT, auditoría completa de cada expediente de consumidor que un empleado toca — la misma rendición de cuentas estilo break-glass que el hospital aplica a los expedientes de pacientes. El “expediente de celebridad” de una cashback app es el saldo de un usuario de alto valor, y los controles riman.

El recorrido de madurez: 12 a 95 a 500

La IAM en una startup no es un diseño fijo — es una secuencia de decisiones “suficientemente buenas por ahora”, cada una de las cuales debería anticipar la siguiente etapa en lugar de pintarse a un rincón. El arco de Rebate es el que los profesionales recomiendan recorrer deliberadamente:

La etapa de fundación es perdonable — doce personas que confían entre sí no necesitan gestión de permisos. El peligro es arrastrar los hábitos de la era de fundación a la etapa de escalamiento: los primeros ingenieros que eran todos admins se quedan admins en silencio, y ese acceso fijo se vuelve el privilege creep que la empresa pasará su etapa de consolidación desenredando. El movimiento de mayor palanca en la transición al escalamiento es hacer el IdP autoritativo y meter el acceso de los propios fundadores por el mismo ciclo de vida que el de todos los demás — que el liderazgo se exente del modelo es cómo el modelo muere.

Anticipar la etapa de consolidación también moldea las decisiones de hoy. Definir el acceso como código ahora significa que cuando Rebate compre una plataforma IGA real, ya tendrá definiciones de rol limpias y revisables para importar en lugar de una década de otorgamientos ad-hoc que aplicar ingeniería inversa. El momento más barato para tener los datos bien es antes de que haya muchos.

Métricas que una startup debería de verdad rastrear

Una startup no correrá un programa de métricas empresarial, pero un puñado de números le dice si el bucle liviano aguanta a medida que sube la plantilla:

• Tiempo de desaprovisionamiento al salir — el único número que más importa, y el primero que pedirá un auditor de SOC 2. Detrás de SSO deberían ser minutos; la brecha entre eso y la remoción completa incluyendo la cola sin SSO es tu exposición real.
• Tasa de automatización del aprovisionamiento — la porción de cambios de acceso que el IdP ejecuta sin un ticket. Si cae al crecer, tu programa “automatizado” está revirtiendo en silencio a manual.
• Conteo de acceso privilegiado fijo — cuántas personas conservan acceso permanente a prod o admin. La meta es un número cercano a cero, con todo lo demás fluyendo por JIT.
• Conteo de descubrimiento de shadow IT — apps encontradas fuera del IdP por trimestre. Un número creciente no es un fallo; no medirlo sí lo es.

La prueba honesta de el artículo de JML se reformula limpiamente para una startup: si una salida quita el acceso en todas partes en minutos, y un reorg quita el acceso viejo con tanta fiabilidad como otorga el nuevo, el bucle liviano es real. Si cualquiera de los dos depende de que alguien se acuerde, la empresa ha confundido moverse rápido con no mirar.

Cuando llega un layoff: la prueba de estrés del leaver masivo

Las startups no solo crecen — también corrigen. Una ronda de financiamiento que no cierra, un pivote o una reestructuración pueden convertirse en un layoff que da de baja a veinte personas en una sola hora. El leaver masivo es donde un bucle JML se demuestra o falla en público, porque cada debilidad que es tolerable de a una se vuelve aguda a escala y bajo presión emocional.

La buena práctica que los profesionales siguen es ensayarlo antes de que sea real:

• Un único disparador, ejecutado simultáneamente. RR. HH. marca a la cohorte como terminada a una hora precisa, y el IdP los deshabilita y desaprovisiona a todos a la vez — no un manager bajando por una lista mientras los primeros dados de baja avisan al resto.
• Sesiones y tokens revocados, no solo logins deshabilitados. Alguien a mitad de sesión sigue trabajando hasta que su token expire a menos que mates activamente las sesiones — justo el hueco que más importa cuando una salida es involuntaria.
• La cola sin SSO manejada por runbook, el mismo problema de shadow IT del recorrido de leaver, ahora multiplicado por veinte personas a la vez.
• Desactivar, no eliminar. Retén las cuentas para el traspaso y cualquier investigación; un layoff es precisamente cuando luego podrías necesitar saber qué accedió alguien en sus últimas horas.

Una empresa que puede dar de baja a una persona limpiamente pero colapsa dando de baja a veinte tiene un bucle que solo parece automatizado. El leaver masivo es la prueba de estrés honesta, y una startup tiene mucha más probabilidad de enfrentarlo que un hospital — que es justo por qué construir el bucle bien mientras se es pequeño rinde frutos cuando llega el día difícil.

Lo que enseña este caso

Rebate se generaliza a toda organización de rápido crecimiento y poca gobernanza:

La lección más profunda es que la buena IAM a escala startup no es una versión más pequeña del IGA empresarial — es una forma distinta. Te apoyas en el proveedor de identidad, prefieres eliminar el acceso a gobernarlo, y aceptas un bucle liviano que es “suficientemente bueno” hoy y está listo para crecer. El modo de fallo no es hacer muy poco; es no hacer nada y llamarle al desparramo resultante “movernos rápido”.

Tres preguntas para autoevaluarte

1. Rebate corta las cuentas conectadas a SSO al instante cuando alguien se va, pero un ingeniero que se fue todavía tenía acceso a una herramienta de analítica una semana después. Explica cómo ocurrió eso y qué único proceso lo habría atrapado.
2. Un ingeniero dice que el acceso JIT a producción “ralentiza la respuesta a incidentes”. ¿Cómo diseñas el flujo JIT para que agregue segundos, no minutos — manteniendo el rastro de auditoría intacto?
3. Los primeros cinco empleados de Rebate conservan acceso que no mapea a ningún rol actual. ¿Qué paso de JML falló durante dos años, por qué ocurre más rápido en startups, y qué cadencia lo detendría sin contratar un equipo de IAM?