Tema 4.2 — Gestión de identidad y accesos

En la salud y la atención, controlar quién puede ver y hacer qué con el registro de un paciente no es una tarea administrativa de TI sino un determinante de primera línea de la seguridad clínica, la confidencialidad, y la confianza pública.

Por qué esto importa en la salud y la atención#

Cada decisión clínica descansa en el supuesto de que el registro frente a un clínico es el registro correcto, pertenece al paciente correcto, y ha sido alcanzado por la persona correcta. La gestión de identidad y accesos (IAM) es la maquinaria que hace verdaderos esos tres supuestos. Cuando funciona, un paramédico ve una alergia a tiempo, una nota de salvaguarda llega solo a quienes la necesitan, y un rastro de auditoría puede responder la pregunta "¿quién miró este registro y por qué?" Cuando falla, los pacientes resultan dañados por registros abiertos bajo el nombre equivocado, el personal fisgonea a familiares o celebridades, y la confianza en toda la empresa digital se erosiona.

La salud y la atención elevan las consecuencias por encima del caso corporativo ordinario de tres formas. Primero, los datos están entre los más sensibles que una persona jamás generará —salud mental, salud sexual, consumo de sustancias, identidad de género, preocupaciones de salvaguarda— así que una brecha de confidencialidad no es un inconveniente sino un daño duradero. Segundo, la fuerza laboral es móvil, rotacional, y multiorganizacional: los médicos junior rotan cada pocos meses, el personal de agencia y suplente llega para un solo turno, y la atención integrada significa que una enfermera de distrito puede legítimamente necesitar un registro hospitalario. Tercero, el deber de cuidado es implacable con la fricción: un control de acceso demasiado lento a las 3 de la madrugada en reanimación es en sí mismo un peligro de seguridad. La IAM en este sector es, por lo tanto, una negociación constante entre bloquear los datos y dejar entrar rápido a la persona correcta.

Este tema trata la profundidad de control de acceso que se sitúa debajo de los deberes más amplios cubiertos en el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad. Donde ese tema establece el marco legal y organizacional —el Reglamento General de Protección de Datos del Reino Unido, el Data Security and Protection Toolkit, el deber de confidencialidad— este trata sobre la mecánica concreta de probar la identidad y otorgar el acceso mínimo necesario para hacer el trabajo.

Conceptos clave#

La gestión de identidad y accesos es la disciplina y el conjunto de tecnologías que aseguran que las personas correctas tengan el acceso correcto a los recursos correctos en el momento correcto, y que esto se pueda probar después. Descansa en una distinción que es fácil de difuminar y peligrosa de perder: la diferencia entre autenticación y autorización.

La autenticación responde "¿eres quien dices ser?" Se prueba con factores: algo que sabes (una contraseña o PIN), algo que tienes (una tarjeta inteligente, un teléfono, un token de hardware), y algo que eres (una huella dactilar o rostro). La autorización responde una pregunta diferente —"ahora que sabemos quién eres, ¿qué se te permite ver y hacer?" Un consultor y una recepcionista pueden ambos autenticarse perfectamente bien, pero están autorizados a partes muy diferentes de un registro. Confundir las dos lleva a sistemas que verifican la identidad fuertemente y luego dejan que todos vean todo.

La autorización en la salud y la atención generalmente se organiza como control de acceso basado en roles (RBAC), donde los permisos se adhieren a roles —"enfermera de departamento de urgencias", "médico de cabecera", "secretaria médica"— y las personas heredan permisos al ostentar un rol, en lugar de recibir derechos uno por uno. El RBAC se gobierna por el principio de privilegio mínimo: cada persona, y cada cuenta de sistema, debería tener el acceso mínimo necesario para hacer el trabajo y nada más. El privilegio mínimo limita tanto el error accidental como el radio de impacto de una cuenta comprometida.

La autenticación moderna fortalece el paso de "prueba quién eres" con la autenticación multifactor (MFA), combinando dos o más factores para que una contraseña robada sola no sea suficiente. Reduce la fricción con el inicio de sesión único (SSO), donde una sesión autenticada otorga acceso a muchas aplicaciones sin inicios de sesión repetidos —un beneficio de seguridad genuino cuando un clínico debe moverse entre una docena de sistemas en una hora. El SSO a través de límites organizacionales depende de la identidad federada: una organización avala a un usuario para que otra pueda confiar en ellos sin poseer sus credenciales.

La fontanería de la federación y la autenticación moderna se construye sobre estándares abiertos. OAuth es un estándar para la autorización delegada —permitir que una aplicación actúe en tu nombre sin entregar tu contraseña. OpenID Connect superpone la autenticación sobre OAuth para que una aplicación pueda saber quién es el usuario, y el más antiguo Security Assertion Markup Language (SAML) basado en XML hace un trabajo similar para el SSO empresarial. El ciclo de vida de una identidad —la concesión, cambio, y revocación de acceso a medida que las personas se incorporan, se mueven, y se van— se maneja mediante procesos de aprovisionamiento, comúnmente llamados incorporaciones/movimientos/salidas o JML.

La dirección estratégica de viaje es la arquitectura de confianza cero: el supuesto de que ningún usuario o dispositivo es confiable meramente porque se sitúa dentro de la red. Cada solicitud se autentica, autoriza, y verifica frente al contexto —salud del dispositivo, ubicación, sensibilidad de los datos— en lugar de confiar en un perímetro endurecido. En un sector donde el personal trabaja desde clínicas, hogares, ambulancias, y sitios asociados, el perímetro efectivamente se ha disuelto, y la confianza cero nombra la respuesta honesta a eso.

Buenas prácticas#

1. Tratar la autenticación y la autorización como decisiones de diseño separadas. Decide primero cuán fuertemente debes probar la identidad para un sistema dado, y por separado cuán finamente debes controlar qué puede hacer entonces cada rol. Un inicio de sesión fuerte en un sistema que da a todos acceso completo es un falso consuelo, y los permisos de grano fino detrás de una contraseña débil son igualmente huecos. Documenta ambas decisiones explícitamente para cada sistema clínico, y revisítalas cuando cambie la sensibilidad de los datos o la población de usuarios.

2. Hacer que el control de acceso basado en roles refleje los roles clínicos reales, luego mantenerlo limpio. Diseña los roles en torno a cómo realmente se entrega la atención —no en torno al organigrama o los caprichos de la configuración predeterminada de un proveedor— y mapea cada rol a los registros y funciones mínimos que necesita. Con el tiempo, el RBAC se degrada en "explosión de roles", donde se acumulan cientos de roles superpuestos y nadie puede decir qué otorga cada uno. Programa una racionalización periódica de roles, y resiste la tentación de resolver cada solicitud de acceso acuñando un nuevo rol a medida.

3. Aplicar el privilegio mínimo tanto a las personas como a las cuentas de máquina. El privilegio mínimo se aplica rutinariamente a los clínicos y luego se olvida para las cuentas de servicio, motores de integración, y herramientas de reporte que a menudo tienen el acceso más amplio de todos. Una interfaz automatizada que extrae datos para un panel rara vez necesita acceso de escritura o texto libre identificable, sin embargo frecuentemente lo obtiene. Inventaría las identidades no humanas, delimítalas, y rota sus credenciales según un calendario.

4. Exigir la autenticación multifactor para el acceso remoto y privilegiado, y elegir factores que se ajusten al entorno. Las contraseñas solas ya no son defendibles para nada que alcance datos de pacientes desde fuera de un dispositivo confiable, y la MFA ahora es una expectativa de línea base en todos los sistemas del NHS. Elige factores que sobrevivan al entorno clínico: tokens de hardware resistentes al phishing o autenticadores de plataforma para el acceso privilegiado y remoto, y ten cuidado con los códigos SMS en salas donde la señal es pobre y los teléfonos se comparten. Equilibra la ganancia de seguridad con la realidad de que un clínico en medio de una reanimación no puede buscar a tientas un segundo factor.

5. Usar el inicio de sesión único para eliminar la fricción que empuja al personal hacia soluciones alternativas inseguras. Cuando el personal debe iniciar sesión por separado en diez sistemas, escriben contraseñas en notas adhesivas, comparten tarjetas inteligentes, y dejan sesiones abiertas —cada una un riesgo de seguridad y confidencialidad. El SSO bien implementado, idealmente combinado con distintivos de proximidad "tocar para entrar, tocar para salir" en estaciones de trabajo clínicas compartidas, tanto mejora la seguridad como devuelve tiempo a los clínicos. Trata el SSO como una intervención de seguridad del paciente, no meramente una conveniencia, y mide el tiempo de inicio de sesión que eliminas.

6. Modernizar la identidad del NHS más allá de la tarjeta inteligente, sin romper lo que funciona. El NHS Care Identity Service (anteriormente el Care Identity Service y, antes de eso, el régimen de Registration Authority construido sobre tarjetas inteligentes) autentica al personal del NHS e impulsa el acceso a sistemas nacionales como el Spine. La dirección nacional ahora es hacia la autenticación moderna basada en estándares —CIS2 con MFA y OpenID Connect— reduciendo la dependencia de tarjetas inteligentes físicas y lectores de tarjetas que fallan, se comparten, o bloquean la atención. Planifica tu migración deliberadamente: mantén el rigor de aseguramiento y registro del modelo de tarjeta inteligente mientras adoptas la flexibilidad de los tokens modernos.

7. Operar incorporaciones/movimientos/salidas como un proceso controlado y auditable —especialmente las salidas. El fallo grave individual más común de IAM en la salud y la atención es la cuenta que sobrevive a la necesidad de la persona: el médico junior rotado, la enfermera de agencia que se fue, el contratista cuyo acceso nunca se revocó. Automatiza el aprovisionamiento desde una fuente autorizada (generalmente el registro electrónico del personal) para que iniciar, cambiar, y terminar un rol desencadene el cambio de acceso correspondiente dentro de una ventana corta y definida. Trata la revocación el mismo día para salidas y para personal bajo investigación como un requisito estricto, no una aspiración.

8. Recertificar el acceso regularmente y hacer a los gestores responsables de ello. El acceso que era apropiado el primer día se desvía a medida que las personas cambian de equipo y acumulan derechos que ya no necesitan —"deriva de privilegios". Realiza revisiones periódicas de acceso (recertificación) en las que el gestor responsable o propietario del sistema confirme activamente que cada persona todavía necesita cada derecho, con el silencio por defecto hacia la eliminación en lugar de la retención. Haz la revisión significativa presentándola en lenguaje claro de rol clínico, no códigos de permiso en crudo que ningún gestor puede interpretar.

9. Gobernar el acceso privilegiado como una categoría propia. Los administradores, propietarios de bases de datos, e ingenieros de infraestructura pueden leer o alterar cualquier registro y deshabilitar los mismos controles que lo protegen, así que su acceso necesita un tratamiento más fuerte que los usuarios ordinarios. Implementa la gestión de acceso privilegiado: separa las identidades de administrador de las cuentas cotidianas, otorga derechos elevados justo a tiempo y con límite de tiempo en lugar de permanentes, y registra las sesiones privilegiadas para revisión independiente. Nunca dejes que la cuenta de un proveedor o una cuenta de "romper vidrio" se convierta en una llave maestra permanente y no monitoreada.

10. Hacer auditable cada decisión de acceso, y realmente leer la auditoría. El control de acceso que no se puede revisar después es solo medio control; la capacidad de responder "¿quién accedió a este registro, cuándo, y sobre qué base?" sustenta tanto las investigaciones de confidencialidad como la seguridad del paciente. Configura un registro de auditoría completo y a prueba de manipulación, y —fundamentalmente— dota de recursos la auditoría proactiva, incluyendo alertas para autobúsquedas, búsquedas de colegas o VIP, y volúmenes de acceso inusuales. Un rastro de auditoría que nadie examina no disuade a nadie.

11. Diseñar el acceso de "romper vidrio" para que se sirvan las emergencias y se capture el abuso. Los clínicos a veces legítimamente necesitan un registro que no están rutinariamente autorizados a ver —un paciente inconsciente, una emergencia entre organizaciones. Proporciona una vía explícita de "romper vidrio" que otorgue acceso de emergencia con una razón requerida, marcado inmediato, y revisión posterior obligatoria, en lugar de forzar al personal a elegir entre las reglas y el paciente. El objetivo es hacer fácil la acción segura de emergencia y visible la injustificada.

12. Adoptar la confianza cero como una dirección, y secuenciarla pragmáticamente. Muévete de "red confiable, abierta por dentro" hacia verificar cada solicitud frente a la identidad, la salud del dispositivo, y el contexto, para que un portátil comprometido en la LAN corporativa ya no sea automáticamente confiable. Este es un viaje de varios años a través de identidad fuerte, cumplimiento de dispositivo, acceso condicional, y microsegmentación —no un producto que compras. Secuéncialo detrás de los fundamentos (MFA, privilegio mínimo, JML limpio), y alinéalo con el trabajo de patrimonio en el Tema 4.0 — Arquitectura técnica, nube y sistemas heredados.

Preguntas para debatir con tu equipo#

1. ¿Dónde estamos deliberadamente intercambiando fricción de acceso por seguridad clínica, y quién decidió el equilibrio? Cada inicio de sesión adicional, segundo factor, o paso de autorización protege la confidencialidad pero cuesta segundos que, en una emergencia, son en sí mismos un riesgo de seguridad. Esta pregunta obliga al equipo a nombrar los lugares específicos donde los controles de seguridad podrían retrasar la atención —el inicio de sesión de reanimación, la estación de trabajo de sala compartida, el sistema fuera de horario— y a preguntar si el equilibrio actual fue elegido por personas que entienden tanto las consecuencias clínicas como de seguridad, o si se dejó por defecto a una configuración de proveedor. Debate la tensión honestamente: un control demasiado estricto impulsa contraseñas en notas adhesivas y tarjetas inteligentes compartidas que son peores que el riesgo que abordan, mientras que uno demasiado laxo invita al fisgoneo y las brechas. Busca señales concretas de un mal equilibrio —personal compartiendo credenciales, sesiones dejadas abiertas, "romper vidrio" usado rutinariamente. Una buena respuesta identifica quién posee cada disyuntiva, muestra que los clínicos estaban en la sala cuando se estableció, y señala tiempos de inicio de sesión medidos y tasas de solución alternativa en lugar de supuestos. También se compromete a revisitar el equilibrio a medida que cambian los roles, sistemas, y amenazas.

2. ¿Qué tan seguros estamos de que quien se va o se mueve pierde el acceso correcto, en el plazo correcto, cada vez? La cuenta que sobrevive a su necesidad es el fallo clásico de IAM, y en una fuerza laboral de salud rotacional y multiorganizacional el riesgo es agudo. Esta pregunta sondea si incorporaciones/movimientos/salidas es un proceso confiable y automatizado impulsado desde una fuente autorizada, o un conjunto de correos electrónicos manuales que silenciosamente fallan cuando alguien está ocupado. Discute los casos difíciles: el médico junior rotando entre fideicomisos, la enfermera de agencia en un turno, el contratista, el miembro del personal suspendido pendiente de investigación. Considera qué significa "el plazo correcto" para cada uno —la revocación el mismo día no es negociable para una suspensión pero puede ser más suave para un movimiento interno rutinario. Una buena respuesta puede señalar evidencia, no intención: los últimos resultados de auditoría de salidas, el número de cuentas inactivas encontradas y cerradas, el tiempo entre que alguien se va y termina su acceso. Es honesta sobre las brechas y nombra quién es responsable de cerrarlas.

3. Cuando algo sale mal con un registro, ¿podemos realmente reconstruir quién hizo qué —y notaríamos el mal uso sin que un incidente nos avisara? La auditoría es el control que hace exigible la confidencialidad y la seguridad después del hecho, pero solo funciona si los registros están completos, protegidos, y genuinamente revisados. Esta pregunta separa dos cosas que un equipo a menudo confunde: la capacidad de investigar reactivamente cuando llega una queja, y la capacidad de detectar el mal uso proactivamente antes de que alguien se queje. Explora qué capturan realmente tus registros, si pueden alterarse, cuánto tiempo se mantienen, y —la pregunta más difícil— quién los mira cuando no hay un incidente. Considera las amenazas realistas: un miembro del personal buscando a un familiar, un colega, o una figura pública; una cuenta comprometida exfiltrando registros a escala. Una buena respuesta muestra que la auditoría se dota de recursos como una función activa con alertas, no un archivo inactivo, y puede citar un ejemplo real de mal uso que la organización detectó y sobre el que actuó. También conecta la auditoría con la equidad, asegurando que las revisiones no dirijan desproporcionadamente a grupos particulares de personal.

4. Cuando un clínico legítimamente necesita un registro que no está rutinariamente autorizado a ver, ¿hace nuestra vía de romper vidrio fácil la acción segura y visible la injustificada? La salud y la atención difieren de la TI corporativa ordinaria precisamente porque las reglas a veces deben ceder ante el paciente frente a ti —una llegada inconsciente, una emergencia entre organizaciones, un clínico fuera de horario cubriendo una carga de casos desconocida. Esta pregunta pregunta si el acceso de emergencia se diseña como una vía explícita, razonada, marcada, o si se fuerza silenciosamente al personal a elegir entre la política de acceso y el bienestar del paciente. Sondea los modos de fallo en ambos extremos: una ruta de romper vidrio tan engorrosa que los clínicos la evitan y comparten credenciales en su lugar, o una tan sin fricción y sin revisar que se convierte en la vía rutinaria y vacía el RBAC por completo. Discute quién revisa los eventos de romper vidrio, con qué rapidez, y qué proporción resulta injustificada —una tasa cercana a cero puede significar que el control no se usa en lugar de que esté limpio. Una buena respuesta puede describir los pasos exactos que da un clínico, la captura de la razón, el marcado inmediato a la organización de origen del registro, y la revisión posterior que cierra el bucle, y puede mostrar que las emergencias genuinamente se sirven mientras el abuso genuinamente se captura. Es honesta sobre si los volúmenes de romper vidrio están tendiendo en una dirección que sugiere una brecha de autorización más profunda.

5. ¿Estamos gobernando el acceso privilegiado y no humano tan estrechamente como gobernamos a los clínicos —o ahí es donde se sitúa la exposición real? Los controles que protegen los datos de pacientes son ellos mismos administrados por alguien, y los administradores, propietarios de bases de datos, motores de integración, y cuentas de reporte a menudo pueden leer o alterar cualquier registro y apagar las mismas salvaguardas que restringen a todos los demás. Esta pregunta arrastra a la luz el acceso que la disciplina de privilegio mínimo tiene más probabilidades de omitir: cuentas de administrador permanentes, inicios de sesión de soporte remoto de proveedores, cuentas de servicio con derechos de modo dios, y la interfaz automatizada que silenciosamente extrae texto libre identificable que nunca necesitó. Discute si las identidades de administrador están separadas de las cuentas cotidianas, si la elevación es justo a tiempo y con límite de tiempo o permanente, y si las sesiones privilegiadas se registran y revisan independientemente. Considera específicamente el patrimonio no humano —quién posee cada cuenta de servicio, cuándo se rotaron por última vez sus credenciales, y si alguien podría enumerarlas hoy. Una buena respuesta trata el acceso privilegiado como una categoría propia con propietarios nombrados, evidencia de elevación justo a tiempo, y un inventario real de identidades de máquina, en lugar de un supuesto de que los fundamentos aplicados a los clínicos también deben cubrir la oficina administrativa. Es franca sobre los proveedores, y sobre cualquier cuenta que se haya convertido en una llave maestra permanente y no monitoreada.

6. ¿Cuánto de nuestra identidad depende de partes fuera de nuestro control, y somos deliberados sobre esa dependencia? La identidad moderna de salud y atención está federada por diseño —un registro compartido confía en las afirmaciones de cada organización asociada, servicios nacionales como el NHS Care Identity Service y CIS2 avalan al personal, y NHS login avala a los ciudadanos— lo que significa que la fortaleza de tu control de acceso solo es tan buena como los proveedores de identidad en los que confías y los estándares que os vinculan. Esta pregunta pide al equipo que mapee dónde se delega la confianza: qué organizaciones autentican a qué usuarios, qué sucede cuando falla el proceso de incorporaciones/movimientos/salidas de un socio, y cómo se revoca un inicio de sesión federado cuando un miembro del personal de otro empleador se va. Sopesa la migración en curso de tarjetas inteligentes hacia autenticación basada en estándares (CIS2 con MFA y OpenID Connect), y la tensión entre adoptar la dirección nacional y mantener funcionando los flujos de trabajo locales a las 3 de la madrugada. Considera también el ángulo de resiliencia: si un servicio de identidad nacional no está disponible, ¿pueden los clínicos aún alcanzar de forma segura los registros que necesitan, o la federación se convierte en un punto único de fallo? Una buena respuesta muestra que el equipo sabe exactamente en el aseguramiento de quién está confiando, ha acordado cómo se manejan la revocación e incidentes entre organizaciones, y está secuenciando su movimiento hacia la autenticación moderna del NHS deliberadamente en lugar de dejarse llevar por ella. Es realista sobre las partes del patrimonio que aún no pueden federarse y cómo se conectan mientras tanto.

En la práctica: un ejemplo de salud y atención#

El Sistema de Atención Integrada Meadowvale está desplegando un registro de atención compartido para que el personal hospitalario, comunitario, de salud mental, médicos de cabecera, y atención social para adultos pueda ver una vista unificada de cada persona. Temprano en el descubrimiento, el programa se da cuenta de que su riesgo real no es construir el registro sino controlar el acceso a él: una vista única que abarca cinco organizaciones multiplica tanto el beneficio de seguridad de que el clínico correcto vea la información correcta como el daño de que la persona equivocada vea algo sensible.

El equipo hace del control de acceso un flujo de diseño de primer nivel. Acuerdan un modelo de roles expresado en lenguaje clínico —"enfermera comunitaria", "profesional de salud mental aprobado", "gestor de residencia de cuidados"— y mapean cada rol a los datos mínimos que necesita, con los registros de salud mental y salud sexual sujetos a acceso más estricto y autorizado por separado. La autenticación está federada: cada organización asociada autentica a su propio personal a través del NHS Care Identity Service o su proveedor de identidad local usando OpenID Connect, y el registro compartido confía en esas afirmaciones en lugar de emitir sus propias credenciales, así que no hay ninguna nueva contraseña que gestionar y las incorporaciones/movimientos/salidas permanecen con la organización empleadora donde vive el registro autorizado del personal.

Porque un paramédico o un clínico fuera de horario a veces necesitará un registro que no está rutinariamente autorizado a ver, el equipo construye una vía explícita de romper vidrio: el acceso de emergencia se otorga al introducir una razón, se marca inmediatamente a la organización de origen del registro, y se revisa dentro de 48 horas. Establecen una pequeña función conjunta de gobernanza de la información y auditoría que revisa los eventos de romper vidrio, ejecuta alertas para autobúsquedas y búsquedas de individuos marcados, y reporta trimestralmente a la junta del ICS.

Seis meses después de la puesta en marcha, una alerta marca a un coordinador de atención abriendo repetidamente el registro de alguien sin participación activa en su carga de casos. La función de auditoría investiga, encuentra que el acceso fue personal en lugar de profesional, y la organización empleadora toma acción disciplinaria. No ocurrió ningún incidente de seguridad del paciente, la brecha se capturó proactivamente, y —porque los controles demostrablemente funcionaron— la confianza pública en el registro compartido se mantuvo. La junta directiva nota que la misma capacidad de auditoría ahora también sirve como evidencia para su presentación del Data Security and Protection Toolkit (véase el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad).

Perspectivas sectoriales#

Startup#

Una pequeña empresa de salud digital construyendo, digamos, una aplicación de monitoreo remoto tiene la ventaja de no tener legado: puede adoptar autenticación moderna, MFA, y federación basada en estándares desde el primer día, e integrarse con NHS login para ciudadanos y CIS2 para clínicos en lugar de inventar su propio sistema de identidad. El peligro es que la velocidad supere a la disciplina —credenciales de administrador codificadas directamente, una cuenta de superusuario "fundador" compartida, cuentas de servicio con acceso de modo dios, y ningún proceso de salida porque "todos se conocen". El privilegio mínimo y la auditoría se sienten como sobrecarga con diez personas pero se convierten en deuda técnica irrecuperable con cien. El movimiento pragmático es comprar la identidad como un servicio gestionado, hacer cumplir la MFA y el RBAC desde el primer commit, y tratar los requisitos del DTAC (Digital Technology Assessment Criteria) como el listón mínimo para cualquier despliegue en el NHS.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una agencia de atención domiciliaria, una clínica de un solo emplazamiento, o un pequeño proveedor de tecnología de salud que ya superó la etapa previa a los ingresos— carga con los mismos deberes de confidencialidad y control de acceso que un gran fideicomiso pero tiene pacientes reales en el libro, un puñado de personal, y poca o ninguna capacidad de TI dedicada para cumplirlos. El riesgo práctico aquí no es exótico: es el inicio de sesión compartido en la recepción, la contraseña del sistema clínico pegada a un monitor, el suplente al que se le da la tarjeta inteligente de un colega porque registrar una nueva toma demasiado tiempo, y quien se va cuya cuenta nunca se deshabilita porque nadie posee ese trabajo. El camino pragmático es apoyarse en las funciones de identidad ya incorporadas en los sistemas que compran —hacer cumplir la MFA y las cuentas por persona, activar el registro de auditoría del proveedor, y usar NHS CIS2 y NHS login en lugar de credenciales caseras— y escribir una rutina simple de incorporaciones/movimientos/salidas que nombre a una persona responsable, incluso si esa persona es el gestor de la consulta haciéndolo a mano. El privilegio mínimo y la revocación de salida el mismo día importan tanto con diez personas como con diez mil; la diferencia es que aquí deben lograrse con proceso y configuración en lugar de un equipo de identidad dedicado.

Gran organización#

Un gran fideicomiso del NHS o ICS opera docenas de sistemas clínicos de edades enormemente diferentes, cada uno con su propio modelo de identidad, y su desafío central es la integración y el ciclo de vida a escala. Las tarjetas inteligentes, el SSO, los flujos de trabajo "tocar para entrar, tocar para salir", y un pipeline JML confiable desde el registro electrónico del personal importan más aquí que cualquier control inteligente individual, porque los modos de fallo son fallos de volumen: miles de cuentas inactivas, explosión de roles, y registros de auditoría que nadie tiene la capacidad de revisar. La gestión de acceso privilegiado es crítica dado el número de administradores y proveedores que tocan el patrimonio. El progreso viene de una estrategia de identidad que racionaliza los roles, federa a través de sistemas, y dota de recursos una función de auditoría permanente —no de soluciones puntuales añadidas a cada aplicación.

Gobierno#

Un organismo nacional como NHS England opera la identidad como infraestructura compartida para todo el sistema: el NHS Care Identity Service y CIS2 para el personal, NHS login para los ciudadanos, y los regímenes de estándares y aseguramiento que permiten a cientos de organizaciones confiar unas en otras. Sus decisiones establecen la dirección de viaje —el movimiento de tarjetas inteligentes a autenticación moderna, la adopción de OpenID Connect, el impulso hacia la confianza cero— y su responsabilidad es ante el Parlamento y el público tanto por la seguridad como por el acceso equitativo. La tensión es entre la estandarización central y la flexibilidad local: exige demasiado rígidamente y rompes flujos de trabajo locales, exige demasiado laxamente y la federación colapsa en inconsistencia. La lente gubernamental trata, por lo tanto, de establecer estándares interoperables (véase el Tema 4.3 — Interoperabilidad y estándares de datos), proporcionar servicios compartidos confiables, y asegurar el cumplimiento sin microgestionar cada fideicomiso.

Modos de fallo comunes#

• Cuentas huérfanas e inactivas. Quienes se van, el personal rotado, y los contratistas antiguos retienen acceso en vivo porque el JML depende de la notificación manual. La solución es la desaprovisión automatizada desde una fuente autorizada más barridas regulares de cuentas inactivas.
• Explosión de roles y deriva de privilegios. El RBAC se degrada en cientos de roles superpuestos y los individuos acumulan derechos que ya no usan. Contrarresta con recertificación periódica y racionalización de roles programada.
• Compartir credenciales y estaciones de trabajo compartidas. Los inicios de sesión lentos y las tarjetas inteligentes torpes impulsan al personal a compartir tarjetas y dejar sesiones abiertas. Aborda la causa raíz con SSO, distintivos de proximidad, y cambio rápido en lugar de exhortar al personal a comportarse.
• Acceso privilegiado permanente. Los administradores y proveedores tienen cuentas de modo dios permanentes que pueden deshabilitar los controles mismos. Muévete a elevación justo a tiempo, con límite de tiempo, y registrada.
• Auditoría como decoración. Los registros se recopilan pero nunca se revisan, así que el mal uso solo se encuentra reactivamente. Dota de recursos la auditoría proactiva con alertas para autobúsquedas y búsquedas VIP.
• Romper vidrio como escapatoria. El acceso de emergencia existe pero no se monitorea, así que se convierte en la vía rutinaria de menor resistencia. Exige una razón, marca cada uso, y revisa después del hecho.
• Teatro de MFA. La MFA está habilitada pero en factores débiles y susceptibles a phishing, o se renuncia para los usuarios privilegiados más ocupados. Prefiere factores resistentes al phishing donde el riesgo es más alto.

Modelo de madurez#

Lista de verificación#

• La fortaleza de autenticación y el alcance de autorización se deciden y documentan por separado para cada sistema clínico.
• La MFA se aplica para todo el acceso remoto y privilegiado, usando factores apropiados para el entorno clínico.
• El inicio de sesión único y el cambio rápido de estación de trabajo se despliegan para eliminar la fricción de inicio de sesión y el compartir credenciales.
• El modelo de roles se expresa en lenguaje clínico, se mapea al privilegio mínimo, y se racionaliza según un calendario.
• Incorporaciones/movimientos/salidas se automatizan desde una fuente autorizada del personal, con revocación el mismo día para salidas y suspensiones.
• La recertificación periódica de acceso la realizan gestores responsables, con eliminación por defecto para el acceso no confirmado.
• El acceso privilegiado se gestiona como una categoría distinta: identidades separadas, elevación justo a tiempo, registro de sesión.
• Las cuentas no humanas y de integración se inventarían, delimitan al privilegio mínimo, y rotan credenciales.
• Existe un registro de auditoría completo y a prueba de manipulación, con alertas proactivas para autobúsquedas, búsquedas de colegas, y búsquedas VIP.
• El acceso de emergencia de romper vidrio se diseña con razón obligatoria, marcado inmediato, y revisión posterior.
• La migración de tarjetas inteligentes a autenticación moderna del NHS (CIS2 / OpenID Connect) está planificada y secuenciada.
• La hoja de ruta de confianza cero está acordada y alineada con la estrategia de arquitectura técnica.

Fuentes clave#

• NHS England — orientación del NHS Care Identity Service y Care Identity Service 2 (CIS2)
• NHS England — Data Security and Protection Toolkit
• National Cyber Security Centre (NCSC) — Zero Trust Architecture Design Principles
• National Cyber Security Centre (NCSC) — orientación de autenticación multifactor y gestión de identidad/acceso
• NIST — Special Publication 800-207, Zero Trust Architecture
• NIST — Special Publication 800-63, Digital Identity Guidelines
• NHS England / NHS login — documentación del servicio de verificación de identidad de ciudadanos
• DTAC — Digital Technology Assessment Criteria para salud y atención social
• Principios Caldicott y el deber de confidencialidad de derecho consuetudinario (Reino Unido)

Referencias#

1. Identity management (identity and access management) — Wikipedia — https://en.wikipedia.org/wiki/Identity_management
2. Authentication — Wikipedia — https://en.wikipedia.org/wiki/Authentication
3. Authorization — Wikipedia — https://en.wikipedia.org/wiki/Authorization
4. Role-based access control — Wikipedia — https://en.wikipedia.org/wiki/Role-based_access_control
5. Principle of least privilege — Wikipedia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
6. Multi-factor authentication — Wikipedia — https://en.wikipedia.org/wiki/Multi-factor_authentication
7. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
8. Federated identity — Wikipedia — https://en.wikipedia.org/wiki/Federated_identity
9. OAuth — Wikipedia — https://en.wikipedia.org/wiki/OAuth
10. OpenID (and OpenID Connect) — Wikipedia — https://en.wikipedia.org/wiki/OpenID
11. Security Assertion Markup Language (SAML) — Wikipedia — https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
12. Provisioning (technology) — Wikipedia — https://en.wikipedia.org/wiki/Provisioning_(technology)
13. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
14. NHS Care Identity Service 2 (CIS2) — NHS England — https://digital.nhs.uk/services/care-identity-service
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. Zero Trust Architecture Design Principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/zero-trust-architecture
17. Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology (NIST) — https://csrc.nist.gov/pubs/sp/800/207/final
18. Special Publication 800-63: Digital Identity Guidelines — National Institute of Standards and Technology (NIST) — https://pages.nist.gov/800-63-3/
19. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
20. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/