Implementación adecuada de HIPAA dentro de la aplicación iOS con varios factores

Descargo de responsabilidad: mi empresa hace una aplicación de iPod compatible con HIPAA. Soy responsable del cumplimiento ...

El iPhone cumple con muchos requisitos de HIPAA fuera de la caja. Una vez que se establece un código de acceso en el dispositivo, los contenidos se cifran, lo que se encarga de muchos requisitos de HIPAA, especialmente el cifrado en reposo.

Para descargar los datos, debe usar una conexión TLS o cifrada para asegurarse de que los datos estén encriptados en tránsito.

Debe configurar su aplicación para descargar y enviar una política de seguridad a un sitio web en un archivo .mobileconfig que obliga a los usuarios a configurar un código de acceso en el dispositivo para usar la aplicación. Si se establece el código de acceso, entonces el dispositivo está cifrado. Por lo tanto, el .mobileconfig aplicará esto.

También debe aprovechar el uso del llavero para almacenar cualquier tipo de token o credencial proporcionada por el usuario. Para hacerlo más sencillo, puede hacer que su aplicación requiera un código de acceso de 4 dígitos para desbloquear esas credenciales del llavero, en lugar de que vuelvan a escribir una contraseña en el teléfono.

Si la aplicación no tiene una conexión de red con el servidor constantemente, puede crear un botón de sincronización. Esto sincronizará los datos relevantes al sistema de archivos local. Cuando se realizan los cambios, los guarda localmente, hasta que se le pide a la aplicación que se sincronice nuevamente, en cuyo caso concilia los cambios con la base de datos de la aplicación web maestra.

Finalmente, esta no es una descripción exhaustiva del cumplimiento de iOS HIPAA, lo invito a consultar con un abogado para redactar sus políticas de seguridad y otra documentación, que debe tener bajo HIPAA.

Sé que esta es una pregunta bastante antigua, pero la encontré como parte de otra búsqueda y pensé en lanzar una idea más aquí en caso de que otros enfrenten desafíos similares.

Es posible que desee ver el cifrado de sobres.

Un ejemplo de estrategia que podrías usar es el siguiente:

Asunciones:

Usted tiene PHI, tiene el usuario A y el usuario B, y cada usuario tiene una contraseña diferente. Desea que ambos usuarios tengan acceso total a la PHI después de ingresar sus respectivas contraseñas. El inicio de sesión de un usuario se compone de un nombre de usuario y una contraseña.

Estrategia:

Cifras la PHI con una clave secreta (llamémosla K). Envía una tabla de datos al dispositivo, que contiene para cada usuario: un hash del nombre de usuario (por ejemplo, md5) y una versión de K encriptada por la contraseña del usuario (llamemos a esa clave encriptada eK).

Entonces, para obtener acceso a la PHI, el usuario A ingresa su nombre de usuario y contraseña, y ocurre lo siguiente, en orden:

• un hash se calcula a partir del nombre de usuario
• ese hash se usa para encontrar la entrada relevante en la tabla
• la clave cifrada eK se descifra utilizando la contraseña que el usuario ingresó, lo que resulta en una clave utilizable K
• la PHI se descifra con K y se carga en la memoria
• (el usuario puede modificar los datos según sea necesario)
• la PHI se vuelve a cifrar con K y se almacena en el dispositivo

Ahora, el usuario A podría cerrar sesión y el usuario B podría iniciar sesión con su nombre de usuario y contraseña, lo que resulta en una versión descifrada de la misma K, que luego se puede descifrar y volver a cifrar la PHI según sea necesario.

Consideraciones

Al incluir un hash en el nombre de usuario, evitamos revelar cualquier nombre de usuario real en la tabla de datos.

Con esta estrategia, puede almacenar la clave de cifrado en sí misma, pero de una manera tal que un usuario sin el nombre de usuario / contraseña adecuado no podría acceder a la clave y no podría descifrar la PHI.

Si bien pronto voy a comenzar una carrera relacionada con HIPAA y, por lo tanto, me he estado preparando, hasta el momento solo tengo experiencia con el cumplimiento de PCI. Dicho esto, mi comprensión de lo que he buscado hasta ahora parece indicar que tanto el ePHI como los metadatos de ese ePHI (fecha / hora de creación, nombre de archivo, fecha del último mod --- ref. enlace ) debe estar encriptado.

Almacenar una clave donde almacena los datos que desea proteger parece un movimiento arriesgado. Como mantener una llave de tu coche en la visera.

Además, parte del cumplimiento de HIPAA es la seguridad física. ¿Qué control físico tiene el teléfono de ese usuario móvil? Para mis dos centavos, la mejor manera de avanzar es olvidarme de las capacidades fuera de línea y concentrarme en una aplicación que puede requerir siempre una conexión a Internet, pero es segura.

Creo que su pregunta es "¿Cómo realizar la autenticación y autorización sin conexión en un dispositivo que no es de confianza?".

La respuesta corta a esta pregunta es: no puedes.

La respuesta larga es: algunos muchachos intentaron solucionar este problema, para los jugadores de rayos azules y las consolas de videojuegos. Para resolver el problema, intentan que el dispositivo que no es de confianza sea confiable, evitando que los usuarios tomen un control permanente de su dispositivo. Los nuevos blue-ray necesitarán jugadores actualizados para jugar y los jugadores con vulnerabilidades están en la lista negra del consorcio de blue-ray. Las consolas utilizan componentes criptográficos a prueba de temperatura para proteger sus secretos (en combinación con otros mecanismos). Para obtener información detallada sobre estos dos ejemplos, puede comenzar con wikipedia buscando las secciones sobre la gestión de DRM. Sin embargo, , los videojuegos y los rayos azules no son información de salud protegida. Pueden tolerar que sus mecanismos de protección se rompan de vez en cuando, lo planearon y pueden recuperarse. Además, no tiene ningún control sobre los dispositivos y no puede implementar un mecanismo de seguridad similar a ellos.

Lo que te recomendaría que hicieras primero es olvidarte de autenticar a muchos usuarios para simplificar tus necesidades. Usted simplemente autentica al usuario de la aplicación iOS y luego le transfiere la responsabilidad de la PHI. Luego puede compartir sus datos, pero cualquier problema que resulte será de su culpa por completo. El usuario tendrá que seguir los pasos para seguir siendo compatible con HIPAA (su aplicación podría ayudarlo). En segundo lugar, olvídate de la autenticación sin conexión. Autentíquelo en línea, antes de recuperar los datos y los derechos asociados. Sin embargo, no podrá hacer cumplir esos derechos con fuerza, ya que no tiene control sobre el dispositivo. Nuevamente, su aplicación puede intentar imponerlas y usted puede hacer que sea ilegal alterar o aplicar ingeniería inversa a la aplicación. En tercer lugar, el almacenamiento de datos encriptados con la clave para descifrarlos no tiene sentido. Solo aumentará los costos de desarrollo y mantenimiento sin aumentar el valor de su aplicación. Si HIPAA exige el cifrado, deje que iOS lo administre: use sus API y deje que lo cifre con la contraseña del usuario o los tokens de seguridad o lo que sea.

Puede haber otras soluciones que se adapten mejor a sus necesidades.