Registros de acceso a datos personales: registrar quién leyó qué registro

Qué es

Un registro de acceso para datos personales registra las lecturas, no solo las escrituras: qué principal (una persona del personal, un servicio, una herramienta de soporte, un trabajo de exportación) leyó el registro de qué sujeto, cuándo, por qué ruta y con qué motivo declarado. Complementa al registro de auditoría de cambios de estado. Dos capas pueden producirlo. En la capa de aplicación, el manejador que carga el registro de un cliente emite un evento que lleva el identificador del sujeto. En la capa de base de datos, una extensión como pgAudit registra las sentencias; su README indica que el registro de auditoría de objetos registra las sentencias que afectan a una relación concreta y admite SELECT, INSERT, UPDATE y DELETE, configurado mediante un rol al que se conceden privilegios sobre las relaciones que se desean observar. NIST SP 800-92 cubre la disciplina que rodea todo esto; su resumen describe orientación sobre cómo establecer infraestructuras y procesos de gestión de registros, que es donde corresponde el almacenamiento, la protección y el análisis del propio registro de acceso.

Por qué importa

Las preguntas que este registro debe responder están centradas en el sujeto: «¿quién consultó los datos de esta persona en el último año?» y «¿alguien leyó registros fuera de su propia carga de casos?». Ninguna de las dos puede responderse a partir de registros de solicitudes indexados por URL. El uso indebido de herramientas internas por parte de personal autorizado es una clase de incidente reportada con frecuencia que solo un registro de lecturas puede detectar.

Cómo aplicarlo

• Registrar en la ruta de lectura de la aplicación con un esquema fijo: actor, actor_type, subject_id, object, action, reason, request_id, at. Las lecturas masivas registran la consulta y el número de filas, no cada fila.
• Hacer del motivo un campo obligatorio en las herramientas internas: un número de ticket o una entrada de una lista predefinida, ya que el texto libre es difícil de analizar después.
• Indexar por sujeto y por actor; construir los dos informes estándar (por sujeto a lo largo del tiempo, por actor frente a la carga de casos esperada) antes del primer incidente, no durante él.
• Usar el registro a nivel de base de datos para las rutas que eluden la aplicación (SQL ad hoc, migraciones, personal de análisis) y conciliarlo con el registro de la aplicación; una lectura sin un evento de aplicación correspondiente es un hallazgo.
• Mantener el propio registro de acceso bajo acceso estricto y con retención propia: es un dato personal tanto sobre el actor como sobre el sujeto.
• Alertar sobre patrones: un actor que lee a muchos sujetos en una ventana corta, lecturas de registros marcados, lecturas fuera del horario laboral para roles que no lo tienen.

Trampas

Registrar cada vista de lista genera volumen sin información; limitar el alcance a las vistas de detalle y a las exportaciones. Un acierto de caché nunca llega al manejador, así que hay que registrar en la API de lectura, no en la llamada a la base de datos. Un registro de acceso que el personal de soporte puede examinar revela qué colegas están bajo revisión. El registro de sentencias a nivel de base de datos puede capturar los valores de los parámetros, lo que introduce datos personales en el registro; en pgAudit, el ajuste pgaudit.log_parameter controla si se incluyen los parámetros pasados con una sentencia.

Lecturas masivas y exportaciones

Una vista de lista que muestra a cincuenta clientes es una lectura de cincuenta sujetos, y una exportación es una lectura de todos los sujetos que contiene; la pregunta centrada en el sujeto no puede responderse a partir del texto de una consulta y un recuento, porque la consulta no puede volver a ejecutarse más tarde contra los datos tal como eran. Registrar los identificadores de sujeto realmente mostrados: una vista de lista tiene un tamaño de página, así que el arreglo es pequeño. Para una exportación, almacenar el manifiesto de identificadores de sujeto (o una lista de hashes) junto con el trabajo de exportación y referenciarlo desde el evento del registro de acceso. Solo los informes agregados, cuyas filas no llevan identificador de sujeto, se registran como consulta más recuento. El ajuste pgaudit.log_relation añade una línea por cada relación tocada, lo cual basta para la conciliación con el registro de base de datos, pero no sustituye a los identificadores.