Capítulo 7 — Fundamentos de identidad y acceso
Mapa de la lección
Lección 07 publicada. Mapa, ejemplo, EX019.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["7.1 Identificar, autenticar, autorizar"]
N2["7.2 Tipos de cuenta"]
N3["7.3 El proceso de altas, cambios y bajas"]
N4["7.4 La revisión de accesos"]
N5["7.6 Actividad práctica: revisión de accesos"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX019"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["7.1 Identificar, autenticar, autorizar"]
N2["7.2 Tipos de cuenta"]
N3["7.3 El proceso de altas, cambios y bajas"]
N4["7.4 La revisión de accesos"]
N5["7.6 Actividad práctica: revisión de accesos"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[Resultados de aprendizaje y conexión]
|
v
[7.1 Identificar, autenticar, autorizar]
|
v
[7.2 Tipos de cuenta]
|
v
[7.3 El proceso de altas, cambios y bajas]
|
v
[7.4 La revisión de accesos]
|
v
[7.6 Actividad práctica: revisión de accesos]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX019]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted debería ser capaz de:
- distinguir identificación, autenticación y autorización, y decir qué control actúa en cada paso;
- elegir la robustez de la autenticación según lo que puede hacer una cuenta, no según quién la tiene;
- gestionar los cuatro tipos de cuenta presentes en todo servicio crítico (personales, privilegiadas, de servicio y de proveedor) y las cuentas compartidas que no deberían existir;
- realizar una revisión de accesos que compare las cuentas con una plantilla de referencia y una declaración de necesidades.
En los informes de incidentes del capítulo 5, el acceso es un hilo recurrente: acceso remoto con contraseñas compartidas, cuentas de proveedor que nunca se eliminaron. Para un implementador, la identidad no es un producto; es un conjunto de registros y rutinas que deben mantenerse exactos a medida que las personas se incorporan, cambian de puesto y se van.
7.1 Identificar, autenticar, autorizar
La identificación consiste en declarar una identidad («soy b.lind»). La autenticación consiste en demostrarla, con algo que se sabe (una contraseña), que se tiene (una llave de hardware, una aplicación de autenticación) o que se es (un rasgo biométrico). La autorización consiste en decidir qué puede hacer esa identidad. Las directrices de identidad digital del NIST describen los tipos de autenticadores y los niveles de garantía, y recomiendan una autenticación multifactor resistente al phishing para los accesos de mayor garantía (NIST SP 800-63B). En la práctica: todo acceso privilegiado o remoto a un equipo de LANTERN requiere autenticación multifactor (MFA), y el factor debería resistir el phishing cuando la plataforma lo permita.
7.2 Tipos de cuenta
- Las cuentas personales pertenecen a una persona y son la opción por defecto para todo ser humano.
- Las cuentas privilegiadas pueden cambiar la configuración, las cuentas o los ajustes de seguridad. Deberían estar separadas de la cuenta cotidiana de la persona, exigir MFA y ser pocas.
- Las cuentas de servicio las usa el software (el retransmisor que escribe en el historiador). Deberían tener solo los permisos que el software necesita, ningún inicio de sesión interactivo y credenciales que se rotan y se guardan en un lugar protegido, no en un script.
- Las cuentas de proveedor dan acceso a un tercero. Deberían estar limitadas en el tiempo: habilitadas para un trabajo concreto, vigiladas mientras se usan y deshabilitadas después.
- Las cuentas compartidas ("opsuser") las usan varias personas. Destruyen la rendición de cuentas (el registro dice que lo hizo "opsuser") y su contraseña se filtra con cada baja. Cuando un dispositivo realmente no admite cuentas individuales, controle la credencial compartida en una bóveda que registre quién la retiró y cuándo.
7.3 El proceso de altas, cambios y bajas
Las cuentas fallan en las transiciones. Una alta recibe un acceso copiado de un compañero y hereda privilegios que no necesita. Un cambio de puesto conserva el acceso antiguo al obtener el nuevo. Las cuentas de una baja siguen habilitadas porque nadie avisó al responsable del sistema. La solución es un proceso vinculado a una fuente de referencia (la plantilla de Recursos Humanos) y una revisión de accesos periódica que detecte lo que el proceso no captó. La exportación del Lab 7 muestra los tres fallos: c.mendes es una baja cuya cuenta siguió habilitada después del 31 de agosto, d.reyes conserva un acceso de administración al historiador que Ingeniería Clínica no necesita, y vendor-kell es un acceso permanente de proveedor que nunca se vinculó a una incidencia.
7.4 La revisión de accesos
Una revisión de accesos compara tres cosas: las cuentas que existen en un sistema (exportadas de él, no de memoria), la plantilla de personas y su situación, y una declaración de necesidades: qué funciones requiere cada equipo en cada sistema. Los hallazgos son de tipos reconocibles: huérfanas (cuentas sin persona correspondiente), bajas aún habilitadas (peor si se usaron después de la baja), funciones no justificadas, accesos privilegiados sin MFA, cuentas inactivas, cuentas compartidas y accesos permanentes de proveedor. Para RLY-01 y HIST-01, la exportación enumera nueve cuentas y la plantilla le indica que f.ito no corresponde a nadie.
7.5 Ejemplo resuelto: revisión trimestral de RLY-01 y HIST-01 (sintético)
La exportación tiene nueve cuentas; el Lab 7 encuentra nueve hallazgos repartidos en cinco de ellas. Dos exigen actuar de inmediato, no una incidencia para el próximo trimestre. c.mendes se fue el 31 de agosto y la cuenta se usó el 14 de septiembre: es un posible incidente, no una limpieza administrativa; conserve los registros, deshabilite la cuenta y averigüe si otra persona usó las credenciales (capítulo 20). vendor-kell es una cuenta de administrador permanente en el retransmisor, sin MFA, inactiva desde hace 85 días. Los demás hallazgos son graves pero rutinarios: d.reyes tiene acceso de administración al historiador, que Ingeniería Clínica no necesita, sin MFA, y no ha iniciado sesión en 224 días; opsuser es un administrador compartido sin MFA; f.ito no figura en absoluto en la plantilla: quizá un contratista registrado en otro sitio, quizá una cuenta que nadie sabe explicar.
Fíjese en lo que el script no señala: svc-relay no tiene MFA, lo que es normal en una cuenta de servicio, pero el almacenamiento y la rotación de su credencial no son visibles en esta exportación y deben comprobarse por separado.
7.6 Actividad práctica: revisión de accesos
Lab 7 (guárdelo como lab07.py y ejecútelo con python3 lab07.py):
# Lab 7 - quarterly access review for the relay and historian (offline, standard library only)
# Synthetic account export and HR roster; "today" is 2026-10-12.
from datetime import date
today = date(2026, 10, 12)
roster = {"a.okafor": ("Water Ops", "active"), "b.lind": ("FSTS Security", "active"),
"c.mendes": ("Water Ops", "left 2026-08-31"), "d.reyes": ("Clinical Eng", "active"),
"e.strand": ("FSTS Platform", "active")}
accounts = [ # name, system, role, last_login, mfa, kind
("a.okafor", "HIST-01", "operator", "2026-10-10", True, "person"),
("b.lind", "RLY-01", "admin", "2026-10-11", True, "person"),
("c.mendes", "HIST-01", "engineer", "2026-09-14", True, "person"),
("d.reyes", "HIST-01", "admin", "2026-03-02", False, "person"),
("e.strand", "RLY-01", "admin", "2026-10-01", True, "person"),
("opsuser", "HIST-01", "admin", "2026-10-11", False, "shared"),
("svc-relay", "HIST-01", "writer", "2026-10-12", False, "service"),
("vendor-kell", "RLY-01", "admin", "2026-07-19", False, "vendor"),
("f.ito", "RLY-01", "operator", "2026-10-05", True, "person")]
need = {("Water Ops", "HIST-01"): {"operator", "engineer"}, ("FSTS Security", "RLY-01"): {"admin"},
("FSTS Platform", "RLY-01"): {"admin"}, ("Clinical Eng", "HIST-01"): set()}
findings = []
for name, sysid, role, last, mfa, kind in accounts:
idle = (today - date.fromisoformat(last)).days
if kind == "person":
if name not in roster: findings.append((name, sysid, "not on HR roster (orphan)"))
else:
dept, status = roster[name]
if status != "active": findings.append((name, sysid, f"leaver ({status}) still enabled; used after leaving" if last > status[5:] else f"leaver ({status})"))
elif role not in need.get((dept, sysid), set()): findings.append((name, sysid, f"role {role} not justified for {dept}"))
if kind == "shared": findings.append((name, sysid, "shared account: no individual accountability"))
if kind == "vendor" and idle > 30: findings.append((name, sysid, f"vendor account standing, idle {idle} d: make time-bound"))
if role == "admin" and not mfa and kind != "service": findings.append((name, sysid, "privileged without MFA"))
if idle > 90 and kind == "person": findings.append((name, sysid, f"dormant {idle} d"))
for f in findings: print(f"{f[0]:<12} {f[1]:<8} {f[2]}")
print("accounts:", len(accounts), "findings:", len(findings), "accounts with >=1 finding:", len({f[0] for f in findings}))
Salida esperada (Python 3.13.5):
c.mendes HIST-01 leaver (left 2026-08-31) still enabled; used after leaving
d.reyes HIST-01 role admin not justified for Clinical Eng
d.reyes HIST-01 privileged without MFA
d.reyes HIST-01 dormant 224 d
opsuser HIST-01 shared account: no individual accountability
opsuser HIST-01 privileged without MFA
vendor-kell RLY-01 vendor account standing, idle 85 d: make time-bound
vendor-kell RLY-01 privileged without MFA
f.ito RLY-01 not on HR roster (orphan)
accounts: 9 findings: 9 accounts with >=1 finding: 5
Ordene los nueve hallazgos según lo que debe ocurrir hoy. c.mendes, usada el 14 de septiembre después de la baja del 31 de agosto, pasa al proceso de incidentes: conserve los registros de autenticación antes de deshabilitar la cuenta. vendor-kell, un administrador permanente en el retransmisor sin MFA y con 85 días de inactividad, se deshabilita y solo se vuelve a habilitar mediante incidencia. d.reyes, opsuser y f.ito se convierten en incidencias con responsable. Después busque lo que el script no puede ver, como la forma en que se guarda la credencial de svc-relay y cuándo se rotó por última vez.
7.7 Errores frecuentes y límites
- Revisar las cuentas a partir de una lista que alguien tecleó, en lugar de una exportación del sistema.
- Copiar el acceso de un compañero para una alta.
- Tratar como un asunto de mantenimiento la cuenta de una baja que se usó después de irse.
- Dar a las cuentas de proveedor acceso permanente «para ganar tiempo en una emergencia»; diseñe en su lugar un proceso de habilitación rápido y registrado.
- Exigir MFA a las personas pero dejar los secretos de las cuentas de servicio en scripts en texto plano.
- Eliminar una cuenta compartida en un dispositivo de control antes de confirmar cómo iniciarán sesión los operadores durante una emergencia.
Una revisión de accesos muestra el estado de las cuentas en un momento dado. No muestra cómo se usan las credenciales, para lo que se necesitan registros (capítulo 17), y solo es tan buena como la plantilla y la declaración de necesidades.
Ejercicios — capítulo 7
EX019 — Priorice los hallazgos. Objetivo: separar los incidentes del mantenimiento. Entradas: la salida del Lab 7. Restricciones: tres franjas de prioridad: hoy, esta semana, este trimestre. Pasos: (1) ponga cada hallazgo en una franja; (2) para cada elemento de «hoy», escriba en orden las dos primeras acciones. Evidencia esperada: tabla. Rúbrica: 3 = el uso de c.mendes tras la baja y el administrador permanente del proveedor sin MFA en «hoy», con «conservar registros» antes de «deshabilitar» para c.mendes y confirmación con Kell antes de deshabilitar cuando la operación dependa de ello; d.reyes y opsuser esta semana; f.ito investigada esta semana; 2 = franjas sensatas, acciones en orden erróneo; 1 = todo «hoy»; 0 = nada.
EX020 — Acceso de proveedor limitado en el tiempo. Objetivo: diseñar un proceso de habilitación de proveedores. Entradas: Kell Instruments necesita acceso de administración al retransmisor unas cuatro veces al año, a veces con urgencia por la noche. Restricciones: debe poder usarlo a las 03:00 el tecnólogo de guardia; debe dejar evidencia. Pasos: (1) describa la solicitud, la aprobación, la habilitación, la vigilancia y la deshabilitación; (2) indique el tiempo máximo de habilitación; (3) indique qué evidencia se conserva. Evidencia esperada: procedimiento de diez pasos como máximo. Rúbrica: 3 = solicitud vinculada a una incidencia, aprobación de la guardia con información a operaciones, cuenta habilitada durante una ventana fija con MFA, sesión grabada o registrada, caducidad automática, revisión el siguiente día laborable; 2 = falta la caducidad o la evidencia; 1 = «habilitar cuando lo pidan»; 0 = nada.
EX021 — Amplíe la revisión. Objetivo: añadir una comprobación a la herramienta. Entradas: el Lab 7. Restricciones: solo la biblioteca estándar. Pasos: (1) añada una comprobación que señale a cualquier persona con acceso de administración tanto en RLY-01 como en HIST-01 (una concentración de privilegios); (2) añada una cuenta b.lind en HIST-01 como admin, con MFA y la fecha de hoy como último inicio de sesión; (3) ejecute e informe del nuevo hallazgo. Evidencia esperada: código y salida. Rúbrica: 3 = comprobación implementada sobre toda la lista de cuentas, b.lind señalada, sin falsos positivos; además señala que la propia cuenta nueva no está justificada porque FSTS Security no tiene necesidades declaradas en HIST-01; 2 = funciona sin advertir el hallazgo de necesidad; 1 = no se ejecutó; 0 = nada.
Síntesis del capítulo
La identidad es un conjunto de registros y rutinas. Autentique según lo que puede hacer una cuenta; separe las cuentas personales, privilegiadas, de servicio y de proveedor, y elimine las compartidas o contrólelas en una bóveda; vincule las cuentas al proceso de altas, cambios y bajas; y revíselas con regularidad frente a una exportación, una plantilla y una declaración de necesidades. Algunos hallazgos de la revisión (la cuenta de una baja usada después de irse) son incidentes, y la evidencia va antes que la limpieza.
Siga estudiando — capítulo 07 de 30
← Capítulo 06 · Índice de capítulos del curso · Capítulo 08 →
Continúe con la siguiente lección escrita.