Mantener la seguridad de los datos en movimiento con SSL

TL; DR: Cualquier política de seguridad requerirá una confianza básica de los empleados y socios comerciales, lo que debe equilibrarse con los controles.

  

En teoría, ¿no es posible que un empleado deshonesto de la empresa de alojamiento utilice la clave privada para descifrar los datos en movimiento?

Sí, es posible.

  

Esto parece ser un agujero en nuestra política de seguridad

En realidad no. Tienes una relación comercial y un BAA con esta empresa. Es una suposición razonable de que actuarán de manera responsable y no intentarán comprometer maliciosamente a usted dado su acceso. Usted mismo reconoce esto cuando dice "empleado deshonesto": no le preocupa que sean malos, le preocupa que una manzana mala funcione para ellos.

De la misma manera, ¿no te preocupan las manzanas malas que funcionan para ti? Deberías ser.

¿Hay controles de acceso en los archivos clave? ¿Hay registros de actividad en el servidor? ¿Tienes acceso a ellos? ¿Los audita para acceso inapropiado? Estas son todas las cosas que debe hacer, ya sea su servidor y sus empleados o el servidor y los empleados del proveedor de alojamiento.

Eso depende de cómo implementó SSL. De usted emplea secreto de envío que su único riesgo de un ataque de tipo MitM (con los certificados y las claves privadas, esto es trivial de hacer y NINGUNA POSIBLE PROTECCIÓN es posible).

El secreto de reenvío significa que las claves utilizadas para la conexión (que deberían ser algo diferente a la RSA utilizada para los propios certificados).

como @gowenfawr ya señaló. El problema básico de seguridad es de confianza. y cómo se mitiga eso (a través del registro, por ejemplo).

Y si estás realmente preocupado por esto. Aloje su propio servidor o use un servidor no administrado en el que usted mismo realice el mantenimiento.

Descargo de responsabilidad - ¡No soy abogado!

Preámbulo: -

HIPAA exige un ejercicio de evaluación de riesgos recurrente que analiza toda la infraestructura que respalda la e-PHI e intenta identificar, analizar y calificar los riesgos para la confidencialidad, integridad y disponibilidad de la e-PHI (More Information ).

Un aspecto crucial de todo este ejercicio es: identificar las cosas que puede hacer para minimizar los riesgos (también llamados controles). Algunos ejemplos de posibles controles fueron proporcionados por gowenfawr arriba.

Mis 2 centavos: -

SI este aspecto se ha identificado como un riesgo, Y SI se han implementado los controles necesarios (por ejemplo, el intercambio adecuado de datos / registro / información y el derecho a auditar el acuerdo entre el proveedor de alojamiento y su compañía, prueba del cumplimiento continuo de el proveedor de alojamiento a HIPAA, el registro adecuado, los controles de acceso más estrictos por parte del proveedor de alojamiento, la revisión periódica del acceso por parte del proveedor de alojamiento, la evaluación periódica del riesgo por parte de su empresa y la notificación oportuna del riesgo a la administración, etc.), ENTONCES este riesgo puede debe ser abordado y no debe suponer ningún problema para la e-PHI.

Si bien muchas políticas de seguridad abordan las cosas desde 30,000 pies, y por lo tanto deben ser infalibles, los procesos subyacentes (por ejemplo, auditoría periódica, cosas para escalar, evaluaciones de proveedores, criterios de evaluación de proveedores, poner el derecho a la auditoría como una obligación La cláusula con los proveedores, etc.) no siempre es infalible, lo que da como resultado agujeros en el sistema en general.