IAM On-Prem para Dispositivos Médicos

Un hospital operaba una flota de dispositivos médicos en red — bombas de infusión, consolas de imágenes, estaciones de monitoreo — dentro de una red clínica segmentada que, por política, no podía alcanzar el internet público. Los dispositivos y sus consolas de gestión aún necesitaban acceso gobernado: quién podía operarlos, quién podía cambiar su configuración y quién les daba servicio. Un servicio de identidad en la nube estaba sencillamente descartado.

El hospital necesitaba identidad, autorización y auditoría completas para su estado de dispositivos médicos, ejecutándose enteramente dentro de sus propios muros.

El desafío

La segmentación de la red clínica es un límite estricto, no una preferencia. Los reguladores y la propia postura de seguridad del hospital prohibían enrutar la autenticación de dispositivos o los datos de auditoría a través de un servicio externo. Sin embargo, el estado de dispositivos tenía exactamente los problemas que el IAM existe para resolver: inicios de sesión de técnico compartidos en las consolas de imágenes, sin atribución para los cambios de configuración en las bombas de infusión y proveedores de servicio con acceso permanente que nadie revisaba.

Necesitaban una plataforma de identidad que viviera on-prem, se integrara con el directorio local y nunca dependiera de una conexión saliente para funcionar.

Qué desplegó Veripass

Veripass se desplegó totalmente on-premises dentro de la red clínica del hospital. Las identidades, las políticas y el registro de auditoría inmutable residían dentro de la propia infraestructura del hospital, sin dependencia de un plano de control externo. El directorio local seguía siendo autoritativo, federado vía OIDC dentro de la red, de modo que clínicos y técnicos se autenticaban contra credenciales que el hospital ya gobernaba.

El acceso a los dispositivos y sus consolas se autorizaba mediante claims, capabilities, roles y perfiles de acceso. Una enfermera operando una bomba de infusión, un técnico cambiando su configuración y un proveedor de servicio ejecutando diagnósticos llevaban cada uno un perfil distinto evaluado por política sensible al contexto. Los proveedores de servicio recibían acceso acotado y temporizado en lugar de cuentas permanentes, y cada operación y cambio de configuración se escribía en el registro de auditoría inmutable on-prem.

• Despliegue totalmente on-premises dentro de la red clínica segmentada
• Identidad, política y auditoría residiendo en la propia infraestructura del hospital
• Federación OIDC al directorio autoritativo local, sin dependencia saliente
• RBAC desde claims, capabilities, roles y perfiles de acceso por acción de dispositivo
• Política sensible al contexto que separa acceso de operación, configuración y servicio
• Acceso acotado y temporizado para proveedores de servicio en lugar de cuentas permanentes
• Registro de auditoría inmutable on-prem de cada operación y cambio de configuración de dispositivo

Para los cambios de configuración en dispositivos críticos para la seguridad, la política exigía un escalonamiento: MFA adaptativo por TOTP de teléfono antes de poder alterar un parámetro, con la elevación registrada junto al cambio — todo sin que un solo paquete saliera de la red clínica.

Resultado

El hospital puso su estado de dispositivos médicos bajo la misma disciplina de identidad que el resto de sus sistemas, sin violar la segmentación de red. Los inicios de sesión de técnico compartidos dieron paso a acceso atribuido, los cambios de configuración nombraban a una persona verificada y los proveedores de servicio perdieron sus cuentas permanentes en favor de otorgamientos acotados y con expiración.

Cada operación de dispositivo y cambio de parámetro vivía ahora en una traza inmutable on-prem que el hospital controlaba por completo — IAM gobernado para hardware crítico de seguridad, entregado enteramente dentro de sus propios muros.