Senderos de auditoría e implementación de SOX/HIPAA/etc, mejores prácticas para datos confidenciales

Question

Me considero relativamente competente en términos de diseño de aplicaciones, pero nunca tuve que trabajar con datos confidenciales. Me he estado preguntando cuáles son las mejores prácticas para los registros de auditoría y cómo exactamente uno debe implementarlos. No tengo que hacerlo ahora mismo, pero sería bueno poder hablar con confianza con una compañía médica si me piden que trabaje para ellos.

Digamos que tenemos una base de datos "escolar", con "maestros", "clases", "estudiantes" todos normalizados en una tabla de "muchos grados" de muchos a muchos. ¿Qué registrarías? ¿Cada inserción/actualización en la "tabla de calificaciones"? Solo actualizaciones (por ejemplo, un niño interrumpe y quiere cambiar las calificaciones, esto debería enviar señales rojas)? ¿Esto varía completamente en función de lo paranoico que uno quiere ser? ¿Hay una mejor práctica?

¿Esto es algo que debería hacerse en la base de datos? (¿Un activador en cada SELECT sensible que inserta una fila en una tabla de 'auditoría' que registra cada consulta?) ¿Qué debería registrarse? ¿Hay alguna funcionalidad integrada automáticamente en Oracle/DB2 que lo haga por usted? ¿Debería ser esto lógica de aplicación?

Si alguien tiene documentación/libros formales sobre cómo tratar con datos confidenciales (no del DoD "Trusted Computing", pero algo como: P), lo agradecería. Lo siento si esta pregunta es terriblemente vaga. Me doy cuenta de que esto varía de una aplicación a otra. Solo quiero escuchar sus experiencias detalladas al tratar con datos confidenciales.

Answer 1

Oracle tiene un producto llamado Oracle Audit Vault: DB2 probablemente tenga un equivalente.

Debe comenzar por prevención. El sistema no debe permitir acciones inválidas. Período. Si el sistema permite acciones "dudosas" que deben ser monitoreadas, eso es "lógica de negocios", es probable que sea mejor implementarlo como el resto de la lógica de su negocio.

Si desea hacer algo en su base de datos, puede considerar el envío de registros (la terminología puede diferir de RDBMS a RDBMS). Básicamente, cualquier operación DML se registra en un archivo. Puede utilizar esta información para copias de seguridad y recuperación puntual, incluso para la replicación/HA/failover/etc. Si envía sus registros a un sistema "confiable" por separado en un proceso "solo para agregar" (es decir, el proceso de envío de registros tiene privilegios para crear nuevos archivos de registro, pero no para modificar la información existente), ya tiene una funcionalidad de auditoría primitiva . Si lo hace de forma segura (es decir, autenticación, no repudio), probablemente incluso esté muy cerca del "cumplimiento" :-p

Por supuesto, revisar muchas y muchas instrucciones INSERT/UPDATE/DELETE es no es la forma más sofisticada de trabajar.

Answer 2

Lo primero que debe entender es la capacidad de auditoría nativa de su DBMS elegido. Estos varían en detalle, pero generalmente proporcionan una forma de configurar qué operaciones se auditan y proporcionan un almacenamiento seguro para los registros de auditoría que generan.

Lo siguiente que debe entender es lo que desea auditar. En el caso de HIPAA y SOX, por ejemplo, probablemente esté mirando PII - Información de identificación personal. Recuerde el alboroto sobre las personas que acceden a los registros telefónicos de Obama o registros médicos de varias celebridades, o ... Esos fueron atrapados porque el sistema auditó a quienes leyeron esos registros, y el oficial de análisis de auditorías (AAO) detectó que las personas que no fueron específicamente autorizados para hacerlo. Entonces, esos sistemas deben estar registrando quién accede a cada registro, y detectando cuando el usuario que lo hace no tiene una razón comercial auténtica para hacerlo. En estos casos, parece que los usuarios habían leído la autoridad para los registros, por lo que si sus tareas ordinarias les obligaban a mirar los registros, podían hacerlo.Pero, cuando no se les exigía que lo hicieran, estaban abusando de su poder y habían sido debidamente sancionados (incluso hasta la pérdida de empleos).

Lo que esto significa es que probablemente no desee rastrear quién accede a la tabla de Estados que registra el código de estado y el nombre completo (y otros bits de información sobre el estado). No hay nada confidencial en esa lista, no importa quién lo lea. Por supuesto, casi nadie debería escribirle; la lista de estados no cambia muy a menudo, pero probablemente se pueda manejar revocando la actualización y eliminando el permiso sobre la mesa de todos.

OTOH, es probable que desee registrar quién accede a los registros en historiales médicos (HIPAA), o quién modifica los datos en los sistemas de contabilidad (SOX). Puede o no necesitar preocuparse por quién lee los datos contables; Mucho de eso puede ser tratado con permisos básicos (el personal de contabilidad tiene permiso, el personal de TI no). Sin embargo, la auditoría es siempre una línea de defensa adicional.

Tenga en cuenta que los registros de auditoría no son de ninguna ayuda si nunca se los mira. En general, la auditoría ralentiza un sistema (simplemente porque está haciendo más trabajo cuando escribe registros de auditoría); es importante comprender cuánto se ralentiza antes de decidir implementar su estrategia de auditoría. Sin embargo, hay algunas cosas que son más importantes que la aceleración de la aplicación, y una de ellas es evitar que usted y otros miembros del personal salgan de la cárcel. La auditoría puede ser necesaria para garantizar que eso suceda.