Capítulo 13 — Identidad y acceso | Grado Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 13 publicada. Mapa, ejemplo, EX025.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["13.1 Tres preguntas"]
  N2["13.2 Factores y acceso remoto"]
  N3["13.3 Roles y segregación de funciones"]
  N4["13.4 El ciclo de vida de las cuentas y las revisione"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX025"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["13.1 Tres preguntas"]
  N2["13.2 Factores y acceso remoto"]
  N3["13.3 Roles y segregación de funciones"]
  N4["13.4 El ciclo de vida de las cuentas y las revisione"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]

[Resultados de aprendizaje y conexión]
    |
    v
[13.1 Tres preguntas]
    |
    v
[13.2 Factores y acceso remoto]
    |
    v
[13.3 Roles y segregación de funciones]
    |
    v
[13.4 El ciclo de vida de las cuentas y las revisione]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX025]

Resultados de aprendizaje y conexión

Después de este capítulo usted podrá (1) distinguir identificación, autenticación y autorización; (2) comparar los factores de autenticación y explicar por qué los métodos resistentes al phishing importan para el acceso remoto a los sistemas críticos; (3) diseñar un acceso basado en roles con segregación de funciones; y (4) realizar una revisión de accesos que encuentre cuentas huérfanas, inactivas, compartidas y con combinaciones tóxicas. Se apoya en el capítulo 6 (conjuntos) y el capítulo 11 (privilegios) y prepara el capítulo 16 (arquitectura) y el capítulo 24 (controles).

13.1 Tres preguntas

La identificación responde a «¿quién dice usted que es?» (un nombre de usuario). La autenticación responde a «demuéstrelo», con algo que usted sabe (una contraseña), tiene (un token o un teléfono) o es (una huella dactilar). La autorización responde a «¿qué puede hacer?»: los permisos asociados a la identidad autenticada. Los errores de cada etapa son distintos: una autenticación débil deja entrar a la persona equivocada; una autorización excesiva permite a la persona correcta (o a quien le robó la sesión) hacer demasiado. Las directrices de identidad digital del NIST fijan requisitos para los autenticadores y recomiendan opciones resistentes al phishing para los niveles de garantía más altos (SP 800-63B).

13.2 Factores y acceso remoto

Las contraseñas se adivinan, se reutilizan y se roban por phishing. Los códigos de un solo uso enviados por SMS o tecleados desde una aplicación añaden un segundo factor, pero una página de inicio de sesión falsa convincente puede retransmitirlos. Los autenticadores resistentes al phishing vinculan criptográficamente el inicio de sesión al sitio auténtico, de modo que un sitio falso no recibe nada aprovechable. Para el acceso remoto a la TO y a otros sistemas críticos (la vía del aviso de CPN del capítulo 5), una autenticación fuerte es necesaria pero no suficiente: la sesión debe llegar a un servidor de salto controlado, tener un tiempo limitado, ser aprobada sesión a sesión en el caso de los fabricantes y quedar grabada.

13.3 Roles y segregación de funciones

En el control de acceso basado en roles (RBAC), los permisos se asocian a roles («scada-operator», «payments-approve») y las personas reciben roles. Los roles hacen manejables las revisiones: se comprueban cincuenta roles, no cincuenta mil permisos individuales. La segregación de funciones prohíbe ciertas combinaciones: quien crea un pago no debe aprobarlo; el ingeniero que cambia la lógica de control no debería controlar también el cortafuegos que registra el cambio. Expresada con conjuntos (capítulo 6), una combinación tóxica $T$ se infringe cuando $T \subseteq \text{roles}(u)$.

El Lab 7 codifica ambas reglas como conjuntos TOXIC y señala a chloe, que tiene payments-create y payments-approve, y a dev, que tiene scada-engineer y firewall-admin y además lleva 214 días inactivo.

13.4 El ciclo de vida de las cuentas y las revisiones

Las cuentas se crean cuando las personas se incorporan (alta), se modifican cuando cambian de puesto (cambio) y se eliminan cuando se marchan (baja). Las fallas se acumulan en cada paso: quienes cambian de puesto conservan roles antiguos («acumulación de privilegios»), las cuentas de quienes se marchan perduran, las cuentas de fabricantes se crean para un proyecto y nunca se eliminan, y las cuentas compartidas de operador hacen que las acciones no se puedan rastrear. Una revisión de accesos compara las cuentas con una fuente autorizada (el sistema de RR. HH., el registro de contratos con fabricantes) y con el uso.

El Lab 7 muestra cada falla: ben se marchó pero conservó su cuenta, vendorx no tiene responsable en RR. HH. y no ha iniciado sesión en 304 días, y ops1 es compartida. Los datos de uso importan tanto como el estado en RR. HH.: dev está activo en RR. HH. pero lleva 214 días inactivo en un rol privilegiado.

13.5 Ejemplo resuelto y Lab 7 (sintético)

Este caso es sintético. Una revisión conjunta de las cuentas del sistema de control de CPN y del sistema de pagos de Calder Mutual (combinados aquí solo con fines didácticos) usa el estado en RR. HH., el último inicio de sesión y dos combinaciones tóxicas.

# Lab 7 - access review: orphans, dormant accounts and toxic combinations (synthetic, offline)
from datetime import date
TODAY = date(2026, 10, 1)
HR = {"ana": "active", "ben": "left", "chloe": "active", "dev": "active"}
ACCOUNTS = [  # user, roles, last login, shared?
    ("ana",   {"scada-operator"},                       date(2026, 9, 30), False),
    ("ben",   {"scada-engineer"},                       date(2026, 5, 2),  False),
    ("chloe", {"payments-create", "payments-approve"},  date(2026, 9, 29), False),
    ("dev",   {"scada-engineer", "firewall-admin"},     date(2026, 3, 1),  False),
    ("ops1",  {"scada-operator"},                       date(2026, 9, 30), True),
    ("vendorx", {"remote-support"},                     date(2025, 12, 1), False),
]
TOXIC = [{"payments-create", "payments-approve"}, {"scada-engineer", "firewall-admin"}]
for user, roles, last, shared in ACCOUNTS:
    issues = []
    if user not in HR: issues.append("no HR owner")
    elif HR[user] != "active": issues.append("owner has left")
    if (TODAY - last).days > 90: issues.append(f"dormant {(TODAY - last).days} d")
    if shared: issues.append("shared account")
    issues += ["toxic: " + "+".join(sorted(t)) for t in TOXIC if t <= roles]
    print(f"{user:8} {', '.join(issues) if issues else 'ok'}")

Salida esperada:

ana      ok
ben      owner has left, dormant 152 d
chloe    toxic: payments-approve+payments-create
dev      dormant 214 d, toxic: firewall-admin+scada-engineer
ops1     no HR owner, shared account
vendorx  no HR owner, dormant 304 d

Acciones: desactivar ya a ben (baja); retirar uno de los roles de pago de chloe; retirar los roles privilegiados inactivos de dev y preguntar si necesita alguno; ops1 es un inicio de sesión compartido de la sala de control (habitual en operaciones 24/7, donde importa un relevo rápido), así que conviene sustituirlo por inicios de sesión individuales con cambio rápido de usuario o, como mínimo, registrar quién está de turno; vendorx debería desactivarse y reactivarse en cada sesión de soporte bajo un patrocinador nombrado. Observe lo que el script no puede ver: si el rol de ana sigue correspondiendo a su trabajo.

13.6 Errores comunes y límites

Equiparar «autenticado» con «autorizado».
Revisiones que confirman que las cuentas existen en lugar de si son necesarias.
Eliminar las cuentas compartidas de una sala de control sin una alternativa viable, de modo que el personal comparte contraseñas en su lugar.
Olvidar las cuentas de servicio y de fabricantes, que no tienen registro en RR. HH.

En el Lab 7, el script confirma que la cuenta de ana está «ok» solo en el sentido de que está activa y no inactiva; si todavía necesita scada-operator es algo que debe decir su responsable. Eliminar ops1 sin más llevaría a la sala de control a compartir la contraseña de una persona, lo cual es peor. Y tanto ops1 como vendorx muestran «no HR owner», que es la señal de que las cuentas de servicio y de fabricantes necesitan otra fuente autorizada, como el registro de contratos.

Ejercicios — capítulo 13

EX025 — Diseñar los roles. Objetivo: aplicar el mínimo privilegio y la segregación de funciones. Entradas: el CEDC necesita operadores de llamadas, despachadores, supervisores, un administrador del CAD y un ingeniero de soporte del fabricante. Pasos: defina cinco roles con sus permisos clave y dos combinaciones tóxicas. Evidencia esperada: tabla de roles y combinaciones. Rúbrica: 3 = roles razonables de mínimo privilegio, pares tóxicos justificados (p. ej., administrador del CAD + administrador del registro de auditoría; soporte del fabricante + acceso permanente); 2 = roles sin combinaciones; 1 = vago; 0 = nada.

EX026 — Ampliar la revisión. Objetivo: añadir una regla. Entradas: Lab 7. Pasos: añada una comprobación que señale cualquier cuenta con un rol privilegiado (scada-engineer, firewall-admin, payments-approve) que no se haya vuelto a aprobar en 180 días, dado un nuevo campo approved (una fecha). Elija las fechas de modo que al menos una cuenta quede señalada y muestre la salida. Evidencia esperada: código y salida. Rúbrica: 3 = lógica correcta, datos de prueba elegidos para mostrar casos señalados y no señalados; 2 = funciona, prueba débil; 1 = error de lógica; 0 = nada.

Síntesis del capítulo

La identidad responde a tres preguntas distintas. Use una autenticación fuerte y resistente al phishing para el acceso remoto crítico, conceda permisos mediante roles, prohíba las combinaciones tóxicas y revise las cuentas frente a fuentes autorizadas y al uso real. Las cuentas compartidas y de fabricantes necesitan alternativas viables, no solo prohibiciones.