La lección anterior cerró con doce medidas priorizadas para Nimbus, y la número uno era el MFA. No fue casualidad: varias de las restantes giran también alrededor de la misma pregunta —quién eres y qué puedes hacer—. Cuando la mitad de la plantilla trabaja fuera de la oficina, los datos están en la nube, hay una consultora con acceso remoto y la API la consume una app móvil, el perímetro deja de ser una línea en la red. Lo que queda separando a un atacante de las agendas de las clínicas es una credencial y una decisión de autorización. Esta lección desarrolla las dos: el ciclo de vida de una identidad y las cuentas huérfanas, qué dicen hoy las guías sobre contraseñas, las formas de MFA ordenadas por su resistencia real al phishing, SSO y los protocolos de identidad con la diferencia exacta entre OAuth 2.0 y OpenID Connect, sesiones y JWT con su validación correcta frente a la ingenua, los cinco modelos de autorización con el diseño concreto de Nimbus, y las cuentas privilegiadas con acceso just-in-time y recertificación.

1. La identidad como nuevo perímetro
2. Ciclo de vida de la identidad y cuentas huérfanas
3. Factores de autenticación y sus debilidades
4. Contraseñas: qué dicen hoy las guías
5. MFA ordenado por resistencia al phishing
6. SSO, federación y protocolos de identidad
7. Sesiones y tokens: cookies y JWT
8. Modelos de autorización y el RBAC de Nimbus
9. Multi-tenencia y aislamiento
10. Cuentas privilegiadas, de servicio y de terceros
11. Recertificación: la revisión periódica de accesos

El modelo clásico dividía el mundo en dentro y fuera, y ponía el control en la frontera. Ese modelo describe cada vez peor la realidad de Nimbus:

Lo único que atraviesa todos esos contextos es la identidad. Si un atacante obtiene las credenciales de Lucía, no necesita atravesar ningún cortafuegos: entra por la puerta principal de cada uno de esos sistemas, desde cualquier lugar del mundo, y todo lo que haga parecerá legítimo.

De ahí la formulación que resume el enfoque Zero Trust de 01-03 aplicado a este dominio:

La identidad es el nuevo perímetro. No se confía en una petición por venir «de dentro»; se confía por poder verificar quién la hace, con qué dispositivo, para qué recurso y bajo qué condiciones, en cada petición.

Tres conceptos que hay que separar con precisión, porque se confunden constantemente:

Y la trampa recurrente: la mayoría de los incidentes graves no son fallos de autenticación, son fallos de autorización. El IDOR de 01-01 ocurría con una sesión perfectamente válida. Autenticar bien y autorizar mal es el patrón número uno del OWASP Top 10.

Una identidad no es un registro estático: es un proceso con tres momentos, y el tercero es el que casi siempre falla.

Los cuatro requisitos de un alta correcta:

1. Basada en el rol, no en la copia. El error clásico es «dale los mismos permisos que a Iván». Se copian también los permisos que Iván acumuló por proyectos antiguos, y el privilegio se propaga como una infección. Debe existir un perfil de acceso por rol predefinido.
2. Con aprobación registrada del propietario del activo (el campo «propietario» del inventario de 01-04 sirve exactamente para esto).
3. Con caducidad si es temporal. Un becario, un contrato de tres meses o una consultora deben tener fecha de fin en el sistema, no en la memoria de alguien.
4. Con identidad nominal. Nada de cuentas compartidas: sin identidad nominal no hay trazabilidad, y sin trazabilidad no hay no repudio (01-01).

Es el problema silencioso. Rubén entró en soporte, ayudó seis meses en facturación, participó en la migración de datos y ahora coordina el equipo. Si en cada cambio se añadieron permisos sin retirar los anteriores, Rubén tiene hoy más accesos que cualquier otra persona de Nimbus, y nadie lo ha decidido nunca.

La regla: todo cambio de rol es una baja del rol anterior y un alta del nuevo, no una suma. Y todo permiso temporal nace con fecha de fin.

Un desarrollador se marcha de Nimbus. Lucía desactiva su cuenta de correo el mismo día y da el proceso por terminado. Seis meses después, en la revisión de inventario, aparece esto:

Ocho accesos vivos de una persona que ya no trabaja aquí. Y ninguno de ellos aparece en un cortafuegos, porque todos son legítimos desde el punto de vista técnico.

Por qué las cuentas huérfanas son especialmente peligrosas, más allá de lo obvio:

• Nadie las vigila. Un uso anómalo de la cuenta de Lucía se puede notar; nadie echa de menos a dev_carlos.
• Nadie las mantiene. Su contraseña no se rota, no se les añade MFA cuando se despliega, no se revisan sus permisos.
• Son el objetivo preferido del credential stuffing. Si esa persona reutilizaba la contraseña y aparece en una brecha de otro servicio, la puerta sigue abierta.
• No siempre hay mala intención. El ex empleado que sigue accediendo «para ayudar» crea un problema igual de serio: acceso sin autorización vigente y sin control.

El procedimiento de baja correcto para Nimbus:

Los dos puntos que más se olvidan son la revocación de sesiones y tokens —desactivar una cuenta no invalida una sesión ya emitida, como viste en el pass-the-cookie de 02-03— y la rotación de secretos compartidos: si esa persona conocía la contraseña del NAS o la clave de la pasarela, esas credenciales están comprometidas por definición.

La medida estructural que reduce el problema a la mitad: cuantos más sistemas estén federados con un único proveedor de identidad, menos casillas hay que marcar. Es la razón principal por la que el SSO es una medida de seguridad y no solo de comodidad.

Un factor es una categoría de prueba. La autenticación multifactor exige factores de categorías distintas; dos contraseñas no son dos factores.

Tres precisiones que corrigen malentendidos frecuentes:

1. La biometría casi nunca viaja al servidor. Cuando Iván desbloquea su móvil con la huella, el dato biométrico no sale del dispositivo: desbloquea una clave privada almacenada en el hardware seguro. Lo que el servicio recibe es una prueba criptográfica. Esa distinción es la que hace que las passkeys sean sólidas y no un problema de privacidad.
2. Las preguntas de seguridad no son un factor, son una contraseña peor: la respuesta suele ser pública o adivinable, y no se puede cambiar el nombre del colegio de tu infancia.
3. El contexto no sustituye a un factor, pero es enormemente valioso combinado: exigir reautenticación cuando cambia el país o el dispositivo es lo que convierte un token robado en un token inútil.

Las recomendaciones cambiaron sustancialmente en la última década, y muchas organizaciones siguen aplicando las de 2005 —que empeoran la seguridad—. La referencia actual es la guía NIST SP 800-63B.

La comprobación contra listas de filtradas es la medida individual más eficaz de esta tabla, y la menos implantada. Impide que alguien elija una contraseña que ya está en los diccionarios que usan los atacantes. Se implementa sin enviar la contraseña a ningún sitio: se envían los primeros caracteres del hash y se compara localmente el resto (modelo de k-anonimato).

Gestores de contraseñas. Para Nimbus son obligatorios, y el argumento es simple: hacen posible cumplir lo único que de verdad importa —una contraseña larga, aleatoria y distinta por servicio— sin memorizar nada. La objeción habitual («¿y si comprometen el gestor?») ignora la alternativa real, que no es memorizar 40 contraseñas fuertes: es reutilizar tres débiles. Un gestor con contraseña maestra fuerte y MFA es, con enorme diferencia, la opción más segura. Ventaja añadida y poco conocida: el gestor no rellena las credenciales en un dominio que no coincide, lo que lo convierte en un detector de phishing pasivo.

El almacenamiento seguro de contraseñas en el servidor —por qué nunca se guardan en claro ni con un hash simple, y qué son bcrypt, scrypt y Argon2 con su factor de coste y su sal— se estudia en detalle en 03-04. Aquí basta con la regla: Nimbus nunca almacena contraseñas recuperables, y ningún proceso legítimo puede devolverle a un cliente su contraseña actual.

El MFA es la medida más rentable de la lección, pero no todas las formas de MFA valen lo mismo. La diferencia decisiva es si el segundo factor puede ser capturado y reutilizado por un atacante interpuesto.

Todos los métodos anteriores comparten un defecto de fondo: producen un secreto que el usuario transmite. Si el usuario está en una web falsa, transmite el secreto al atacante, que lo reenvía al sitio real en segundos. Eso es exactamente lo que hacen los kits de phishing con proxy inverso, y por eso «tenemos MFA» dejó de ser una respuesta suficiente.

FIDO2 rompe ese esquema con dos propiedades:

1. La clave privada nunca sale del dispositivo. No hay ningún secreto que el usuario pueda entregar, ni siquiera queriendo.
2. La firma está vinculada al dominio (origin binding). El navegador incluye en la operación el origen real de la página. Si el usuario está en nimbusreservas.example.portal-facturas.example, la llave produce una firma para ese dominio, que el servidor legítimo rechaza. El ataque no falla porque el usuario se dé cuenta: falla porque es criptográficamente inválido.

Formulado de otro modo: con TOTP o SMS, la defensa depende de que el usuario detecte la web falsa. Con FIDO2, la defensa funciona aunque el usuario no detecte nada. Es la diferencia entre una medida que depende del criterio humano y una que no. Recuerda el principio de 02-03: si tu defensa exige que 38 personas acierten siempre, no tienes defensa.

Las passkeys son FIDO2 con la clave sincronizada entre los dispositivos del usuario a través de su ecosistema, lo que elimina la principal fricción (perder la llave) a cambio de confiar en el sincronizador.

Aunque el objetivo sea FIDO2, TOTP sigue siendo el mínimo realista para muchas cuentas. Conviene entender cómo funciona por dentro.

Las cuatro decisiones que separan esta implementación de una ingenua:

• (a) Ventana de tolerancia acotada. Sin tolerancia, los usuarios con el reloj ligeramente desviado no pueden entrar. Con una ventana grande (por ejemplo ±5), el código vale casi cinco minutos y el ataque en tiempo real se vuelve trivial. ±1 es el equilibrio habitual.
• (b) hmac.compare_digest. Una comparación normal de cadenas termina en cuanto encuentra una diferencia, y ese tiempo es medible. En tiempo constante no se filtra nada.
• (c) Consumo de un solo uso. Es el control que más se olvida: sin él, un código capturado por phishing sigue siendo válido durante la ventana restante, que es justamente lo que necesita el atacante interpuesto.
• El secreto se almacena cifrado en la base de datos, no en claro: quien lo lea puede generar códigos indefinidamente.

Y la conclusión honesta: por bien implementado que esté, TOTP sigue siendo phisheable, porque el usuario teclea un código en una página. Por eso la línea de trabajo para Nimbus es TOTP como mínimo general y FIDO2 para lo administrativo.

Conectando con 02-03: el bombardeo de notificaciones explota que aprobar es un botón sin contexto. Las correcciones, por orden de eficacia:

1. Number matching: obliga a mirar la pantalla del origen y a introducir un número, lo que hace imposible aprobar por inercia.
2. Contexto en la notificación: aplicación, ubicación aproximada, dispositivo. Una petición desde otro país es evidente.
3. Límite de intentos: tras 3 peticiones denegadas o ignoradas, se bloquea la cuenta y se alerta.
4. Alerta a seguridad ante ráfagas: una ráfaga de peticiones MFA significa que alguien ya tiene la contraseña, con independencia de que la apruebe o no. Es una señal de alto valor que casi nadie vigila.

Con inicio de sesión único, el usuario se autentica una vez ante un proveedor de identidad y accede a todas las aplicaciones federadas.

El contrapeso, que hay que asumir conscientemente: el proveedor de identidad se convierte en el activo más crítico de todos. Si cae, nadie entra a nada; si lo comprometen, se compromete todo. Por eso: MFA FIDO2 obligatorio para sus administradores, registro exhaustivo, y un procedimiento de acceso de emergencia con credenciales guardadas fuera de línea para el caso de indisponibilidad.

Es la confusión más extendida del dominio, y produce sistemas inseguros.

La frase que hay que fijar: OAuth 2.0 no es un protocolo de autenticación. Usar un token de acceso como prueba de identidad es un error clásico: ese token dice qué se puede hacer, no quién eres, y podría haber sido emitido para otra aplicación. Si lo que necesitas es «quién es este usuario», usa OIDC y valida el ID token.

SAML es el veterano: mismo objetivo que OIDC (autenticación federada), basado en XML y aserciones firmadas, muy implantado en el entorno corporativo. Para integraciones nuevas se prefiere OIDC por su simplicidad y su encaje natural con aplicaciones móviles y SPAs; SAML sigue siendo obligado cuando un cliente corporativo grande lo exige, y es una petición habitual en un SaaS B2B como Nimbus.

Por qué PKCE es imprescindible y no un extra. El código de autorización viaja por el navegador, y en una aplicación pública (SPA o app móvil) no hay forma de guardar un secreto de cliente: cualquiera puede descompilar la app o leer el JavaScript. Si un atacante intercepta el código, podría canjearlo por tokens.

PKCE lo impide con una idea sencilla: la aplicación genera un valor aleatorio (code_verifier), envía solo su hash al iniciar el flujo y presenta el valor original al canjear. Quien no tenga el code_verifier no puede usar el código robado, y ese valor nunca sale del navegador que inició el flujo.

Los cuatro errores frecuentes en este flujo:

• Usar el flujo implícito (tokens en la URL): obsoleto y desaconsejado.
• Guardar los tokens en localStorage: accesible desde JavaScript, luego robable con un XSS. Preferible una cookie HttpOnly gestionada por un intermediario de servidor.
• No validar aud en la API: aceptar un token emitido para otra aplicación.
• No validar el parámetro state: es la protección contra CSRF del propio flujo de autenticación.

SameSite=Strict frente a Lax: Strict es más seguro pero rompe la navegación desde enlaces externos (el usuario llega al panel y aparece como no autenticado). Lax es el equilibrio habitual; para operaciones sensibles se combina con token anti-CSRF.

Un JWT tiene tres partes separadas por puntos: cabecera, carga útil y firma, codificadas en base64url.

Lo primero que hay que entender, y lo que más se malinterpreta: un JWT está firmado, no cifrado. Cualquiera que lo tenga puede leer su contenido sin ninguna clave. La firma garantiza integridad y origen, no confidencialidad.

Qué NO debe ir nunca dentro de un JWT:

Lo que sí debe llevar: un identificador de sujeto (sub), el tenant, los roles o ámbitos mínimos, y siempre iss, aud, exp, iat y jti.

Los tres fallos y por qué cada uno es explotable:

1. Sin verificar la firma, un atacante compone un JWT con "roles": ["admin"] y "tenant_id": 7 y entra como administrador de cualquier clínica. La variante histórica de este fallo es aceptar el algoritmo none que el propio token declara en su cabecera: nunca se debe confiar en el alg del token para decidir cómo validarlo.
2. Sin comprobar exp, un token robado hace un año sigue sirviendo. Sin iss y aud, un token válido emitido por otro sistema o para otra aplicación se acepta aquí.
3. Confiar ciegamente en los roles del token significa que un cambio de permisos o una baja no tienen efecto hasta que el token caduque.

Las siete decisiones, explicadas:

1. Claves desde JWKS por kid. Permite rotar la clave de firma sin tocar la API. Codificar la clave pública en el código convierte la rotación en un despliegue, y lo que es difícil no se hace.
2. algorithms=["RS256"] fijado. Cierra el ataque de confusión de algoritmo (por ejemplo, hacer pasar la clave pública RSA como secreto HMAC).
3. y 4. issuer y audience. Sin aud, un token legítimo para otro servicio del mismo emisor sería aceptado por la API de Nimbus.
4. leeway. Evita fallos espurios por desfase de relojes; 30 s es razonable, minutos no.
5. Revocación por jti. Es el punto débil estructural del JWT: al ser autocontenido, es válido hasta que caduca aunque el usuario haya sido dado de baja. La lista de revocados con vida igual a la del token resuelve el problema con un coste mínimo.
6. Permisos vigentes desde la fuente de verdad. Los roles del token sirven como pista rápida; las decisiones sensibles se toman con datos actuales.

Rotación de refresh con detección de reutilización, que es la pieza elegante: si un refresh token ya usado se presenta otra vez, significa que alguien tiene una copia robada. La respuesta correcta es invalidar toda la familia de tokens de esa sesión y forzar reautenticación. Es un mecanismo de detección de robo que funciona sin más infraestructura.

Recordemos el hallazgo: la cuenta de servicio nimbus-deploy-bot con un token personal sin caducidad y permisos de escritura en todos los repositorios. Fue además el primer eslabón del ataque encadenado de 02-02.

Todo lo que está mal en él:

La corrección, en orden de preferencia:

1. Eliminarlo y usar credenciales efímeras del propio CI (identidad federada de corta duración emitida para cada ejecución). El mejor secreto es el que no existe.
2. Si no es posible: token de aplicación con ámbito por repositorio, caducidad de 90 días, rotación automatizada y almacenamiento en el gestor de secretos.
3. En cualquier caso: alerta ante cualquier uso desde una IP no esperada y revisión trimestral de tokens vivos.

Los tokens sin uso en 30 días son tan peligrosos como los eternos, y por la misma razón que las cuentas huérfanas: nadie los echaría de menos si alguien empezara a usarlos.

Autenticar responde «quién eres». Autorizar responde «qué puedes hacer», y es donde ocurren la mayoría de los incidentes graves.

Qué le conviene a Nimbus: RBAC como base, con atributos para las condiciones. Es el modelo híbrido que usa casi todo el mundo: los roles definen el grueso de los permisos y unas pocas reglas contextuales cubren lo que los roles no expresan (el tenant, el horario, el dispositivo).

Roles de cliente (dentro de una clínica o gimnasio):

Roles internos de Nimbus:

Cuatro decisiones de este diseño que merecen atención:

1. profesional usa un atributo (agenda_asignada), no un rol. «Sus» pacientes no se puede expresar solo con roles: es una relación entre el usuario y el recurso. Aquí es donde RBAC puro se queda corto y se añade ABAC/ReBAC.
2. suplantar_usuario es un permiso explícito con condiciones, no una capacidad implícita del rol de soporte. Es la corrección del «ver como cliente» que permitió acceder a 40 clínicas en el ejercicio de 02-02. Y se notifica al cliente: la transparencia es en sí misma un control.
3. auditoria:borrar aparece como denegado explícito para todos, incluido sistemas. Es la separación de funciones de 01-03: quien administra no puede borrar la prueba de lo que hizo, coherente con el INSERT sin UPDATE de nimbus_api.
4. El fichero está en el repositorio. Un cambio de permisos pasa por revisión y queda en el historial. Los permisos que se cambian a mano en una consola no dejan rastro comprensible.

Y en la base de datos, la contrapartida del mismo diseño, coherente con los roles de 01-03:

Nimbus es multi-tenant: una única base de datos con los datos de todas las clínicas. El aislamiento entre clientes es el producto: si falla, no hay negocio.

Ya has trabajado las dos piezas —el filtro por tenant_id que corrigió el IDOR en 01-01 y la seguridad a nivel de fila (RLS) que lo hace obligatorio desde el motor en 01-03—. Lo que corresponde aquí es cómo encaja el aislamiento en el control de acceso:

La regla de diseño, en una frase: el tenant_id nunca procede de un parámetro que envía el cliente; procede siempre del token validado en el servidor. Un endpoint que acepte ?tenant_id= del cliente es un IDOR con otro nombre.

Y la comprobación que conviene automatizar: una prueba en el CI que, con el token de un tenant, intente acceder a un recurso de otro y exija un 404. Es una prueba de cinco líneas que habría detectado el IDOR original antes de llegar a producción.

Las cuentas con permisos elevados son el objetivo final de casi cualquier ataque. Merecen un tratamiento distinto del resto.

El problema: si Lucía navega, lee correo y administra la infraestructura con la misma cuenta, un phishing exitoso contra su correo entrega directamente el control de toda la producción.

La solución: dos identidades para la misma persona.

El coste es una molestia diaria moderada; el beneficio es que el vector más probable (el phishing al correo) deja de conducir al activo más crítico.

PAM (gestión de accesos privilegiados) agrupa las prácticas de control de las cuentas con más poder:

El cambio mental que propone el just-in-time: en lugar de preguntar «¿quién debe tener acceso permanente?», se pregunta «¿por qué alguien tendría acceso permanente?». En un sistema bien diseñado, el estado normal de una cuenta administrativa es sin privilegios; los privilegios se conceden por minutos y desaparecen solos. Es el principio de mínimo privilegio de 01-03 llevado al eje del tiempo: no solo el mínimo de permisos, también el mínimo de duración.

Es el activo con criticidad crítica y propietario Marta del inventario de 01-04, y el patrón exacto del incidente de Target que analizaremos en 02-06.

Situación actual:

Configuración objetivo:

1. Cuentas nominales por técnico de la consultora. Sin excepciones: sin nominación no hay no repudio.
2. MFA obligatorio en todos los accesos.
3. Acceso just-in-time: sin privilegios de forma predeterminada; se solicitan con motivo, los aprueba Lucía o Marta y caducan en horas.
4. Alcance acotado: solo los sistemas que realmente necesitan, nunca «administrador de todo».
5. Sesiones registradas y revisadas por muestreo.
6. Caducidad automática del acceso alineada con el contrato, con revisión trimestral.
7. Alerta ante cualquier acceso fuera de la ventana pactada.

Nota: las obligaciones contractuales con el proveedor —alcance, confidencialidad, notificación de incidentes, subcontratación, auditoría— y la gestión del riesgo de terceros como proceso se tratan en 04-04, y sus implicaciones en materia de protección de datos en 06-03. Deben validarse con asesoría jurídica.

Las cuentas que usan los sistemas (no las personas) son el punto ciego habitual: no tienen quien las reclame ni quien las revise.

Todo lo anterior se degrada con el tiempo. La recertificación es la revisión periódica en la que el propietario de cada activo confirma —o retira— los accesos concedidos.

Cómo se hace en Nimbus, de forma sostenible:

El dato que hace eficiente la revisión es la fecha de último uso. Un permiso sin uso en seis meses casi nunca es necesario, y presentar la lista ordenada por ese campo convierte una revisión tediosa en una decisión rápida.

Un permiso «NUNCA USADO» es la mejor noticia posible en una recertificación: se retira sin discusión, sin riesgo de romper nada y con beneficio inmediato de reducción de superficie.

Errores comunes:

• Dar de baja solo el correo. Es el error del apartado 2.3: quedan vivos ocho accesos en sistemas no federados.
• Desactivar la cuenta sin revocar sesiones ni tokens. Una sesión emitida sigue funcionando; un token sin caducidad, para siempre.
• Copiar los permisos de otro empleado al dar de alta. Propaga privilegios acumulados que nadie decidió conceder.
• Tratar todo el MFA como equivalente. SMS y FIDO2 se diferencian en si el ataque de phishing funciona o no.
• Forzar caducidad de contraseñas cada 90 días. Produce variaciones triviales y contraseñas escritas en papel; las guías actuales lo desaconsejan salvo indicio de compromiso.
• Usar OAuth 2.0 como si fuera autenticación. Un token de acceso dice qué se puede hacer, no quién eres. Para identidad, OIDC y validación del ID token.
• Guardar tokens en localStorage. Un XSS los roba. Cookie HttpOnly o intermediario de servidor.
• Confiar en un JWT sin verificar firma, exp, iss y aud, o dejar que el token elija el algoritmo.
• Meter datos personales dentro del JWT. Está firmado, no cifrado: cualquiera lo lee.
• Aceptar tenant_id como parámetro del cliente. Es un IDOR con otro nombre.
• Conceder acceso privilegiado permanente porque «es más cómodo». El estado normal de una cuenta administrativa debería ser sin privilegios.
• Recertificar con la regla «se retira lo que alguien pida retirar». Por defecto debe retirarse lo que no se confirma.

Consejos:

• Empieza por lo que más rinde: FIDO2 en las cuentas administrativas y caducidad en todos los tokens. Son dos tardes de trabajo y cierran los dos vectores más explotados.
• Escribe el checklist de baja del apartado 2.3 y ejecútalo el último día, no después. Guarda constancia firmada.
• Separa la cuenta administrativa de la personal para Lucía y Marta. Es incómodo una semana y protege durante años.
• Pon el fichero roles.yaml en el repositorio y trátalo como código: revisión, historial y despliegue controlado.
• Añade al CI la prueba de aislamiento entre tenants. Cinco líneas que vigilan permanentemente el fallo más caro de un SaaS.
• Ejecuta hoy la consulta de tokens sin caducidad. Si devuelve filas, ya tienes tu tarea de la semana.
• En la recertificación, ordena siempre por fecha de último uso: convierte una revisión tediosa en decisiones de un segundo.

Iván deja Nimbus. Lucía ejecuta lo siguiente:

1. Desactiva su cuenta de correo.
2. Le quita del canal interno de mensajería.
3. Recupera el portátil.
4. Le retira del repositorio de GitHub como colaborador.

Dos meses después, en la revisión trimestral, se detecta actividad: alguien ha ejecutado un despliegue a las 4:10 de la madrugada.

Se pide: (a) enumera al menos seis accesos que probablemente sigan vivos y explica por qué cada uno es peligroso; (b) escribe el checklist de baja completo que debería haberse aplicado; (c) explica cómo pudo ejecutarse un despliegue si la cuenta de GitHub estaba retirada, con dos hipótesis técnicas distintas; (d) propón tres medidas estructurales que reduzcan este riesgo con independencia de la disciplina de quien ejecute la baja.

Este es el código de autenticación de una nueva versión de la API de Nimbus:

Se pide: (a) identifica todos los problemas de seguridad, clasificándolos en críticos, altos y medios; (b) explica el impacto concreto de los dos más graves sobre los datos de las clínicas; (c) reescribe emisión y validación correctamente; (d) explica qué cambia si la API se despliega en tres instancias y se necesita revocar una sesión de inmediato.

Nimbus lanza los informes de ocupación por profesional. Requisitos de negocio:

• El administrador de centro ve el informe de todos los profesionales de su centro.
• El profesional ve solo su propio informe.
• Recepción no accede a esta funcionalidad.
• Soporte de Nimbus (Rubén) puede ver el informe de un centro solo con un ticket abierto y aprobación de un segundo operador, durante 30 minutos como máximo, y el centro debe ser notificado.
• Los informes pueden exportarse a CSV, con un máximo de 5.000 filas y 6 peticiones por hora y usuario.
• Un profesional dado de baja hace más de 90 días no debe aparecer.

Se pide: (a) decide qué modelo o combinación de modelos de autorización usarías y justifícalo; (b) escribe el fragmento de roles.yaml correspondiente; (c) escribe el código Python del endpoint con todas las comprobaciones de autorización, indicando en comentarios qué ataque previene cada una; (d) indica tres eventos que registrarías y una alerta que construirías sobre ellos.

Solución 1

(a) Accesos que probablemente sigan vivos:

(b) El checklist del apartado 2.3, ejecutado el último día, con constancia firmada y con reasignación de la propiedad de sus activos del inventario.

(c) Dos hipótesis del despliegue nocturno:

1. Token personal vivo. Iván creó un token de GitHub con permisos de escritura y sin caducidad —el patrón del hallazgo de 01-04—. Retirar la cuenta como colaborador no invalida el token, que sigue autenticando frente a la API del servicio. Es la hipótesis más probable.
2. Clave SSH o credencial de infraestructura. El despliegue no pasó por GitHub: se ejecutó directamente contra el servidor con una clave SSH que quedó en authorized_keys, o con credenciales del proveedor cloud que conocía.

En ambos casos, la lección es la misma: la identidad no es solo la cuenta. Es la cuenta más todos los artefactos que ella creó y que viven de forma independiente.

(d) Tres medidas estructurales:

1. Federar todo lo posible con el proveedor de identidad, de modo que una única baja desactive el máximo número de accesos. Reduce la dependencia de la disciplina humana.
2. Prohibir por política los tokens sin caducidad y las claves SSH personales en servidores, sustituyéndolos por credenciales efímeras emitidas por el CI y acceso por bastión con identidad central. Un artefacto que no existe no se olvida.
3. Recertificación trimestral con la consulta del apartado 11, que detecta lo que se escapó del proceso. Es la red de seguridad: asume que la baja fallará alguna vez y limita cuánto tiempo pasa hasta que se detecta.

Solución 2

(a) Problemas encontrados:

(b) Impacto de los dos más graves. Con none aceptado, un atacante construye un token con "tenant_id": 7 y "roles": ["centro_admin"], sin firma, y la API lo acepta. Resultado: acceso completo a la agenda y los datos de cualquier clínica, sin necesidad de credenciales, sin phishing y sin explotar nada más. Combinado con la ausencia de caducidad, un token obtenido una sola vez —de un log, de una captura, de un portátil— da acceso indefinido. En términos de la tríada CIA, esto es una pérdida total de confidencialidad e integridad sobre datos que revelan información de salud, y desencadena obligaciones de notificación (06-03).

(c) Código correcto:

(d) Revocación inmediata con tres instancias. Un JWT es autocontenido: las tres instancias lo validan sin consultar a nadie, así que una baja no tiene efecto hasta que caduca. Soluciones, combinables:

1. Lista de revocación compartida (Redis) consultada por jti, con vida igual a la del token: máximo 15 minutos de entradas. Coste: una consulta rápida por petición; es lo que hace el código anterior.
2. Vida corta del access token (5-15 min) con refresh rotatorio. La revocación real se aplica al refresh, que sí se comprueba contra la base de datos: la ventana máxima de exposición es la vida del access token.
3. Marca de invalidación por usuario (tokens_validos_desde): se rechaza todo token con iat anterior a esa marca. Revoca todas las sesiones de una persona con un solo campo, ideal para una baja o un compromiso.

El compromiso de fondo: el JWT es rápido y sin estado, pero la revocación exige estado. La solución práctica no es elegir un extremo, sino acortar la vida del token para que la ventana sea aceptable y mantener un mecanismo de revocación para lo urgente.

Solución 3

(a) Modelo elegido: RBAC como base + ABAC/ReBAC para el alcance y las condiciones. Justificación:

• Los tres perfiles (administrador de centro, profesional, recepción) son roles: RBAC los expresa de forma directa y auditable.
• «Solo su propio informe» no es un rol: es una relación entre el usuario y el recurso (el profesional asignado). Requiere ReBAC o un atributo.
• «Con ticket, aprobación, 30 minutos y notificación» son condiciones contextuales: ABAC.
• «Profesional dado de baja hace más de 90 días» es un atributo temporal del recurso.

RBAC puro obligaría a crear un rol por profesional, lo que es ingobernable. ABAC puro sería expresivo pero muy difícil de auditar. El híbrido es lo que usan los sistemas reales.

(b) Fragmento de roles.yaml:

(c) Endpoint con las comprobaciones:

(d) Tres eventos a registrar y una alerta:

Alerta: acceso de soporte a más de 3 tenants distintos en 24 horas, o cualquier acceso de soporte sin ticket asociado. Es exactamente la señal que habría detectado en horas —en lugar de en tres días— el incidente del panel de soporte del ejercicio de 02-02, y es barata de construir porque los campos ya están en el registro. Una segunda alerta útil: cualquier exportación CSV fuera del horario laboral del tenant, que aprovecha que Nimbus conoce el horario de cada centro.

Has trabajado el dominio que más incidentes decide hoy. Sabes por qué la identidad es el nuevo perímetro: ninguno de los activos relevantes de Nimbus está detrás de una frontera de red, y lo único que atraviesa todos los contextos es quién eres. Has separado con precisión identificación, autenticación y autorización, y has fijado la trampa que se repite en todo el curso: la mayoría de los incidentes graves no son fallos de autenticación, sino de autorización. Has recorrido el ciclo de vida de la identidad y su punto débil, la baja, con el caso concreto de los ocho accesos que sobreviven a una desactivación de correo, el checklist que lo evita y las dos cosas que siempre se olvidan: revocar sesiones y tokens, y rotar los secretos compartidos.

En contraseñas te llevas la actualización de las guías —longitud sobre complejidad, sin caducidad forzada, permitir pegar, y la medida más eficaz y menos implantada: comprobar contra listas de filtradas— y el argumento definitivo a favor de los gestores. En MFA has aprendido la jerarquía que de verdad importa, la de resistencia al phishing, y la razón por la que FIDO2 es cualitativamente distinto: la clave nunca sale del dispositivo y la firma está vinculada al dominio, de modo que la defensa funciona aunque el usuario no detecte nada. Has visto por dentro la verificación TOTP con sus cuatro decisiones —ventana acotada, comparación en tiempo constante, consumo de un solo uso y secreto cifrado— y la corrección del MFA fatigue con number matching.

En federación has fijado la diferencia exacta entre OAuth 2.0, que autoriza, y OpenID Connect, que autentica, junto con el flujo Authorization Code + PKCE y la razón por la que PKCE es imprescindible en aplicaciones públicas. En sesiones y tokens has recorrido los atributos de cookie que neutralizan XSS, CSRF y captura en tránsito, y has comparado una validación de JWT ingenua con una correcta: firma verificada con clave del emisor, algoritmo fijado por nosotros, iss, aud y exp comprobados, revocación por jti y permisos sensibles recargados de la fuente de verdad. Y has corregido el token sin caducidad de 01-04, el primer eslabón del ataque encadenado de 02-02.

En autorización has comparado DAC, MAC, RBAC, ABAC y ReBAC y has construido el diseño real de Nimbus: roles de cliente y roles internos en un roles.yaml versionado, con suplantar_usuario como permiso condicionado y notificado, y auditoria:borrar denegado a todos. Has cerrado el aislamiento multi-tenant con su regla de oro —el tenant_id viene siempre del token, nunca del cliente— y su prueba automatizada en el CI. Y has terminado con las cuentas privilegiadas: la separación de la cuenta administrativa, PAM y el acceso just-in-time que convierte el mínimo privilegio en mínima duración, la configuración objetivo para el acceso de la consultora (A-19) y la recertificación periódica cuya regla decisiva es que lo que no se confirma, se retira.

Tienes ya el arsenal completo del módulo: sabes qué se ataca, cómo, con qué se defiende y cómo se controla el acceso. Falta la prueba de realidad. En la última lección del módulo, Casos de Estudio de Incidentes de Ciberseguridad (02-06), aplicaremos un método de análisis a incidentes reales y públicos —Target, WannaCry, Equifax, SolarWinds, Colonial Pipeline y una fuga por almacenamiento en la nube mal configurado—, mapearemos cada uno a los conceptos del curso, extraeremos los patrones que se repiten sin excepción y reconstruiremos hora a hora un incidente ficticio de ransomware en Nimbus que entra por el acceso remoto de la consultora, para responder a la única pregunta que importa: qué habría cambiado el desenlace.