HIPAA sobre infraestructura cloud, donde reducir el alcance hace casi todo el trabajo

Los dos errores cuestan lo mismo en monedas distintas. El primero es una empresa que firma un acuerdo de asociado comercial con su proveedor de nube, marca la casilla y da por hecho que la infraestructura ya cumple. No cumple, y la primera revisión de seguridad de un cliente encuentra el registro de auditoría desactivado, un desarrollador con acceso permanente a producción e información sanitaria protegida en una herramienta de soporte que no está cubierta por ningún acuerdo.

El segundo es un equipo que trata todos los sistemas como dentro del alcance, cifra todo dos veces, restringe a todo el mundo de todo y se pasa dieciocho meses construyendo un programa de cumplimiento alrededor de datos que el noventa por ciento de sus servicios nunca necesitaron ver.

La diferencia entre ambos es una decisión de alcance tomada pronto, y vale más que todos los controles que vienen después.

Quién eres determina qué te aplica

Una entidad cubierta es un plan de salud, una cámara de compensación sanitaria o un proveedor sanitario que transmite información de salud por vía electrónica. Hospitales, aseguradoras, la mayoría de las consultas clínicas.

Un asociado comercial es cualquiera que realiza una función por cuenta de una entidad cubierta y que implica información sanitaria protegida. Si vendes software a hospitales y tu producto toca datos de pacientes, eres asociado comercial, estás regulado directamente y sujeto a inspección, no solo obligado contractualmente.

Un subcontratista de un asociado comercial arrastra las mismas obligaciones cadena abajo. Tu proveedor de nube es uno. También tu proveedor de registro, tu proveedor de correo y cualquier otra cosa que toque el dato.

La consecuencia práctica es que necesitas acuerdo de asociado comercial en las dos direcciones: uno con cada cliente que sea entidad cubierta, y uno con cada proveedor que toque el dato. La segunda lista es más larga de lo que los equipos esperan y es la que tiene agujeros.

La información sanitaria protegida y los dieciocho identificadores

La información sanitaria protegida es información de salud identificable individualmente. La expresión que importa es "identificable individualmente", porque es la bisagra sobre la que gira el alcance.

La norma enumera dieciocho identificadores: nombres, detalle geográfico menor que un estado, fechas más precisas que un año, teléfonos y faxes, direcciones de correo, números de la seguridad social, números de historia clínica, números de plan de salud, números de cuenta, números de certificado y licencia, identificadores de vehículo y de dispositivo, URLs, direcciones IP, identificadores biométricos, fotografías de cara completa y cualquier otro código identificativo único.

Que las direcciones IP estén en esa lista sorprende a los ingenieros, y es la razón de que los registros de un servidor web en una aplicación de cara al paciente estén normalmente dentro del alcance.

Reducir el alcance es el trabajo con más palanca

Todo sistema que guarde información sanitaria protegida necesita el conjunto completo de controles, para siempre, y hay que evidenciarlo. Así que la decisión de ingeniería más valiosa es reducir cuántos sistemas son esos.

Tres técnicas, de mayor a menor potencia:

Desidentificación. Los datos despojados de los dieciocho identificadores, por el método de puerto seguro, dejan de ser información sanitaria protegida y salen del alcance por completo. El método alternativo de determinación por experto permite conservar más datos con una opinión estadística documentada. Es la única vía que saca un sistema del régimen en vez de añadirle controles, y está crónicamente infrautilizada. Tu almacén analítico casi con seguridad no necesita identificadores reales.

Tokenización en la frontera. Guarda el dato identificativo en un servicio pequeño y bien controlado y dale a todo lo demás un token. El sistema de facturación, el motor de recomendaciones y el de notificaciones trabajan con tokens, y solo el servicio de tokens está en alcance.

No recogerlo. La fecha de nacimiento que el formulario recoge por costumbre, el campo de texto libre que inevitablemente se llena de detalle clínico, la dirección completa donde bastaría una zona postal.

Traza la frontera explícitamente y déjala escrita como un diagrama con una línea. Todo lo de dentro recibe el tratamiento completo. Todo lo de fuera recibe un control que impida que la información sanitaria protegida cruce hacia dentro, y eso es un control real que hay que hacer cumplir, no una esperanza.

Qué servicios de nube puedes usar de verdad

Todos los proveedores grandes ofrecen acuerdo de asociado comercial, y cada uno publica una lista de servicios cubiertos por él. La lista no son todos los servicios, y usar un servicio no cubierto para información sanitaria protegida es un incumplimiento por bien que lo hayas configurado.

Consulta la lista vigente antes de diseñar, porque cambia. Los servicios nuevos, las funciones en vista previa y algunas ofertas regionales o de IA faltan con frecuencia. Esto muerde sobre todo en las funciones de IA: un extremo de modelo que no está en la lista cubierta no puede recibir datos de pacientes, y tener un acuerdo empresarial genérico no cambia eso.

Ten en cuenta además que el acuerdo cubre las obligaciones del proveedor, no tu configuración. Un servicio cubierto configurado con acceso público sigue siendo tu brecha.

Las salvaguardas, como configuración

La regla de seguridad es deliberadamente neutral en tecnología, con especificaciones de implementación obligatorias y direccionables. Direccionable no significa opcional: significa impleméntalo, o documenta por qué una alternativa es razonable y apropiada. "No nos dio tiempo" no es ese documento.

En la práctica un evaluador mira siempre lo mismo:

• Control de acceso. Identificación única de usuario, acceso basado en roles y cierre de sesión automático. En términos de nube: sin cuentas compartidas, sin acceso permanente a producción, elevación justo a tiempo, y un procedimiento de acceso de emergencia que existe y se ha probado.
• Controles de auditoría. Registrar y examinar el acceso a los sistemas que guardan información sanitaria protegida. La mitad de examinar es la que los equipos se saltan, y necesita un dueño con nombre y una cadencia.
• Integridad. Mecanismos para confirmar que el dato no ha sido alterado ni destruido indebidamente. Versionado, sumas de verificación, registros de auditoría inmutables.
• Autenticación. Doble factor en todas partes, sin excepciones para administradores.
• Seguridad en la transmisión. TLS en tránsito, incluido el tráfico interno. El cifrado en reposo es direccionable más que estrictamente obligatorio, y además es lo más barato de esta lista, así que cifra.
• Eliminación. Destrucción de soportes y datos que puedas evidenciar, incluidas las copias de seguridad.

Casi todo esto es el conjunto de controles que ya operas para SOC 2, y por eso pertenece a un único programa mapeado y no a uno paralelo, como se argumenta en un conjunto de controles para cuatro marcos. Si tienes SOC 2 de tipo dos, ya estás casi aquí, y la diferencia es documentación más algunos detalles; la cuestión del orden está en SOC 2 tipo I o tipo II.

Registro, conservación y el número de seis años

El registro de auditoría es donde la arquitectura cloud y HIPAA interactúan de forma más incómoda.

Necesitas constancia de quién accedió a qué, y tiene que sobrevivir a los intentos de alterarla. Eso significa registros de auditoría en una cuenta separada con acceso de solo escritura desde producción, inmutabilidad activada y una alerta ante cambios de configuración. El mismo patrón que proteger las copias de seguridad del ransomware, y por la misma razón.

La conservación de documentación llega a seis años desde la creación o desde la última fecha de vigencia, y eso aplica a políticas, análisis de riesgos y acuerdos, no necesariamente a cada línea de registro. Decide la retención de logs a conciencia y por clase, y documenta la decisión, porque una retención general de seis años sobre registros de acceso de alto volumen es un valor por defecto caro que nadie te pidió.

El análisis de riesgos merece mención aparte porque es el documento que más a menudo falta y lo primero que se pide en una actuación sancionadora. Es una evaluación escrita, fechada y actualizada periódicamente de los riesgos para la información sanitaria protegida en todos tus sistemas. No es una prueba de penetración ni un informe de escaneo.

Notificación de brechas y el reloj de sesenta días

Una brecha de información sanitaria protegida no asegurada obliga a notificar a las personas afectadas sin demora injustificada y no más tarde de sesenta días, al departamento correspondiente, y a medios de comunicación cuando se ve afectado un número elevado de residentes de un estado o jurisdicción. Las brechas menores pueden registrarse y reportarse anualmente. Los asociados comerciales notifican a la entidad cubierta, que notifica hacia adelante.

La consecuencia de ingeniería es la importante: el dato cifrado conforme a los estándares especificados no está "no asegurado", así que una brecha de datos correctamente cifrados puede no ser notificable. Eso convierte el cifrado en el control con mayor retorno de toda esta lista, y convierte la gestión de claves en una cuestión de cumplimiento y no en una preferencia técnica.

La otra consecuencia es que no puedes acotar una brecha sin registros de acceso. Si no estabas registrando las lecturas, no puedes establecer a qué se accedió, y no poder estrecharlo tiende a ampliar la notificación.

Qué hacer esta semana

Dibuja un diagrama de tus sistemas y pon una línea alrededor de todo lo que guarde información sanitaria protegida. Después, para los tres sistemas más grandes de dentro de la línea, pregunta si necesitan identificadores reales o funcionarían con tokens. Cada sistema que saques fuera de esa línea es una reducción permanente del coste de cumplimiento, y es el trabajo más barato disponible. Arrancamos un proyecto sanitario con exactamente ese diagrama, en la fase de alcance de un proyecto de seguridad.