¿Confundiendo identificaciones para mayor seguridad en DB?

En última instancia, esta es una idea terrible y le costará en términos de integridad de datos. Las relaciones de datos que están ocultas son relaciones de datos que se corromperán y no serán confiables. Ni siquiera te hace más seguro. La oscuridad protege solo de la más leve curiosidad. Mire la larga historia de sistemas oscuros agrietados para obtener evidencia de esto.

Este enfoque provocará la pérdida de citas, posiblemente citas con el médico equivocado y un sistema generalmente poco confiable.

En general, este tipo de requisitos (HIPPA, PCI, etc.) están escritos por no tecnólogos, y están listos para una amplia interpretación.

Pregunte a la persona que maneja el requisito si está dispuesta a sacrificar la integridad y confiabilidad del sistema por la seguridad a través de la oscuridad. Eso es esencialmente lo que se pide. Supongo que alguien está interpretando que HIPPA es una forma muy restringida si están pidiendo cosas locas como "ocultar las ID de las tablas de la base de datos".

Mi consejo general es encontrar a alguien con experiencia en la interpretación de los requisitos de HIPPA de lo que realmente puede hacer en lugar de que alguien intente interpretarlo en el sentido más restrictivo posible.

Acabo de comenzar a analizar el cumplimiento de HIPPA para una próxima aplicación que estoy creando, y por lo que veo, tomas las reglas / regulaciones un poco por la borda. En lo que respecta a la ofuscación de sus datos, uno de los requisitos principales es proteger su Información de salud protegida electrónica o (ePHI) Esto incluye elementos como nombres, números de SSI o datos privados o confidenciales del paciente. Una de sus identificaciones internas en su base de datos no se incluiría en esta categoría, y tratar de confundir eso solo crearía todo un mundo de problemas para usted sin lograr nada. Por ejemplo, si ocurriera alguna violación de datos y vieran que la Id 5 está vinculada a la id 8, no significaría mucho para nadie sin otros datos personales, que se cifrarían.

Nuevamente, puede que no sea la mejor fuente, ya que también estoy aprendiendo sobre el cumplimiento de HIPPA, pero sé bastante sobre el cumplimiento de PCI y parecen bastante similares.

Estoy de acuerdo con los demás: esta es una mala práctica, desde cada punto de vista, que incluye diseño, auditoría, recuperación, seguridad, rendimiento. La lista continúa.

Si un hacker ingresa a la base de datos, el juego termina. No importa si confundió los datos, será cuestión de tiempo antes de que se pueda desenfocar.

RDBMS en estos días permite permisos basados en columnas y, por lo tanto, el uso de claves reales para unirse a otras tablas permitirá que se utilicen consultas SQL estándar, sin la sobrecarga que se puede eliminar. Además, sus auditores apreciarán la atención prestada a la capacidad de escalar, actualizar, solucionar problemas y mantener la integridad y la seguridad.

Habiendo dicho eso, algunos proveedores, como Microsoft y Oracle, tal vez otros, han aumentado y han permitido un cifrado muy centrado. Las claves se almacenan en un sistema separado y el acceso a las columnas está protegido. Microsoft SQL Server, por ejemplo, utiliza TDE (cifrado de datos transparente) y la administración de claves extensibles (EKM) para hacer precisamente esto. Por lo tanto, las estructuras de su tabla no cambian, y no compromete la sobrecarga de las uniones con la ofuscación, et al. Por lo tanto, si bien es posible que tenga un médico y un paciente, no necesariamente sabrá los nombres u otros detalles de ninguno de los dos, ya que TDE puede permitir el cifrado de estos campos.

Los sistemas RDBMS también permiten el cifrado de toda la base de datos, para manejar las instancias en las que la base de datos es robada.

En resumen, no ofusque las claves de los datos. Más bien, encripta los datos que son sensibles. Puede verse así: no ofusque los metadatos; más bien, solo encripta los datos. Piense en las claves y las claves externas como metadatos.

Tenga cuidado, también, de no ser víctima de la práctica de colocar una seguridad sólida en la puerta principal, mientras deja la puerta trasera desbloqueada: sus registros de transacciones, registros de errores, aplicaciones, registros de aplicaciones, sistemas de respaldo y personas Las personas en quienes se confía para tener acceso a estos datos y aplicaciones son todas fuentes de fugas, por lo tanto, apuntalar los permisos y tener cuidado con lo que se registra y con lo que se hace con esos registros.

Una vez que aplique estos principios, se vuelve menos importante ocultar las claves.