Este estándar establece los criterios técnicos internos aplicados por Xaventro para reducir la capacidad de identificación asociada a direcciones IP, registros de conexión y características técnicas de dispositivos utilizados para acceder a xaventro.com.
Su objetivo es evitar que los registros técnicos contengan más información identificativa de la necesaria, reducir la exposición de datos en los sistemas operativos y establecer controles específicos frente a la correlación o reidentificación indebida.
Las medidas descritas se aplican siguiendo los principios de protección de datos desde el diseño y por defecto establecidos en el Reglamento (UE) 2016/679 (RGPD) y la Ley Orgánica 3/2018 (LOPDGDD).
Antes de almacenar información procedente de una conexión, los registros técnicos se clasifican según su capacidad de identificación y su utilidad operativa.
La clasificación diferencia entre información necesaria para operar temporalmente una conexión, información necesaria para investigar un incidente técnico y datos que únicamente resultan útiles para obtener estadísticas generales.
Los campos que no aporten una utilidad concreta deberán excluirse del registro siempre que la arquitectura técnica lo permita.
La dirección IP completa se considera un identificador técnico que requiere protección específica cuando pueda asociarse directa o indirectamente con una persona, sesión, cuenta u operación.
Su disponibilidad no debe extenderse automáticamente a todos los sistemas internos.
Cuando una función pueda realizarse sin conservar la IP completa, deberá utilizarse una representación menos precisa.
Cuando sea técnicamente adecuado, las direcciones IPv4 utilizadas para estadísticas o análisis que no requieran identificación individual podrán reducirse eliminando o neutralizando la parte final de la dirección.
El objetivo del truncamiento es conservar únicamente el nivel de información necesario para el análisis correspondiente y reducir la posibilidad de asociar el registro con una conexión concreta.
Una dirección truncada no se considerará automáticamente anónima si sigue existiendo información adicional que permita relacionarla razonablemente con un visitante.
Las direcciones IPv6 pueden contener un nivel de detalle técnico superior al necesario para determinadas funciones.
Cuando no sea necesaria la dirección completa, se procurará eliminar o neutralizar los segmentos de menor nivel utilizados para distinguir interfaces o dispositivos concretos.
El número de segmentos conservados deberá limitarse al mínimo compatible con la finalidad técnica perseguida.
Cuando un proceso necesite distinguir temporalmente diferentes conexiones pero no conocer directamente su dirección IP, podrá utilizarse un identificador interno generado para ese proceso.
El identificador interno no deberá incorporar de forma legible la dirección IP original.
Cuando exista una tabla o mecanismo que permita relacionar el identificador con el dato original, dicho mecanismo se mantendrá separado del conjunto operativo y sujeto a controles de acceso reforzados.
Cuando resulte apropiado, determinados identificadores técnicos podrán transformarse utilizando mecanismos criptográficos antes de ser utilizados en sistemas secundarios.
Las funciones utilizadas deberán seleccionarse teniendo en cuenta el riesgo de ataques por comparación, diccionario o fuerza bruta.
Una transformación criptográfica reversible o susceptible de correlación no será presentada como anonimización irreversible.
No se considerará suficientemente anonimizada una dirección IP únicamente porque haya sido sometida a una función hash simple.
El espacio limitado y estructurado de posibles direcciones puede permitir ataques de comparación destinados a recuperar o inferir el valor original.
Cuando se utilicen hashes con finalidad de seudonimización, deberán complementarse con medidas técnicas apropiadas que reduzcan este riesgo.
Cuando no resulte necesario conservar el modelo exacto del dispositivo, la información podrá transformarse en categorías generales.
Por ejemplo, un dispositivo podrá clasificarse únicamente como ordenador, teléfono móvil o tableta cuando ese nivel de detalle sea suficiente para la finalidad prevista.
Se evitará conservar combinaciones excesivamente específicas de fabricante, modelo y características de hardware cuando no sean necesarias.
La información sobre sistemas operativos podrá reducirse a familias o versiones principales cuando las versiones secundarias no resulten necesarias.
Esta normalización permite realizar comprobaciones generales de compatibilidad sin mantener detalles técnicos que incrementen innecesariamente la singularidad del dispositivo.
Cuando una finalidad solo requiera conocer la compatibilidad del navegador, podrá conservarse la familia del navegador o su versión principal en lugar de la cadena técnica completa.
Las cadenas completas de User-Agent no deberán replicarse indiscriminadamente en sistemas secundarios cuando una versión normalizada resulte suficiente.
No se combinarán deliberadamente múltiples características técnicas con el único propósito de construir una huella digital altamente singular de un visitante salvo que exista una finalidad legítima, una base jurídica adecuada y resulte necesario conforme a la normativa aplicable.
Características como resolución de pantalla, navegador, fuentes, zona horaria, hardware, sistema operativo y configuración gráfica pueden adquirir mayor capacidad identificativa cuando se combinan.
Por este motivo, la necesidad de combinar estos campos deberá evaluarse de forma específica.
Los registros técnicos deberán evitar conservar parámetros de URL que puedan contener accidentalmente nombres, correos electrónicos, referencias privadas, tokens u otra información identificativa cuando dichos parámetros no sean necesarios.
Cuando sea técnicamente posible, estos valores deberán eliminarse o enmascararse antes de incorporarse a sistemas de análisis o diagnóstico.
Los mensajes de error pueden incorporar accidentalmente datos introducidos por usuarios o información procedente de una solicitud.
Antes de utilizar registros de errores para diagnóstico prolongado, se procurará eliminar campos que puedan contener información personal innecesaria.
Los sistemas no deberán registrar automáticamente contenidos completos de formularios cuando para diagnosticar el problema sea suficiente un código de error o una referencia técnica.
Los tokens de autenticación, identificadores de sesión y credenciales temporales no deberán aparecer íntegramente en registros de diagnóstico destinados a consultas ordinarias.
Cuando sea necesario identificar una sesión para investigar una incidencia, podrán utilizarse referencias parciales o identificadores alternativos que no permitan reutilizar directamente la credencial.
Los datos utilizados para observar rendimiento técnico no deberán combinarse automáticamente con nombres, direcciones de correo electrónico u otros identificadores directos.
Cuando sea imprescindible relacionar temporalmente ambos conjuntos para investigar una incidencia concreta, el acceso deberá limitarse al caso necesario y evitarse la creación de perfiles permanentes sin una finalidad justificada.
Los registros de seguridad, los registros de errores y las estadísticas técnicas podrán mantenerse en conjuntos separados cuando tengan finalidades diferentes.
La separación reduce la posibilidad de que una única base de datos permita reconstruir innecesariamente toda la actividad técnica asociada a una persona.
Las conexiones entre conjuntos deberán limitarse a los supuestos en los que exista una necesidad operativa concreta.
El acceso a información técnica identificable se concederá únicamente a las funciones que necesiten utilizarla.
La posibilidad de consultar una dirección IP completa no deberá derivarse automáticamente del acceso general a herramientas administrativas.
Cuando sea posible, los perfiles ordinarios visualizarán datos reducidos mientras que el acceso a valores completos quedará reservado a funciones justificadas.
Cuando una interfaz administrativa no necesite mostrar una dirección IP completa, podrá presentar una versión parcialmente oculta.
El mismo criterio podrá aplicarse a identificadores técnicos extensos y otros valores que no necesiten ser visibles íntegramente para realizar una tarea ordinaria.
La existencia del dato original en un sistema protegido no justifica su exposición completa en todas las pantallas internas.
La exportación de registros técnicos aumenta el riesgo de pérdida de control sobre los datos.
Antes de generar archivos para análisis, se procurará eliminar direcciones IP completas, identificadores persistentes y campos de dispositivo innecesarios.
Los archivos que todavía contengan información identificable deberán limitarse a la finalidad concreta para la que fueron generados y no mantenerse como copias permanentes sin necesidad.
Los registros que contengan direcciones IP u otros identificadores técnicos no deberán copiarse innecesariamente en documentos personales, hojas de cálculo locales, mensajes informales o herramientas no destinadas a almacenar dicha información.
Cuando sea necesario compartir información para resolver una incidencia, se utilizará preferentemente una versión reducida o enmascarada.
Los entornos de desarrollo, demostración o pruebas no deberán utilizar datos técnicos identificables procedentes de visitantes reales cuando puedan emplearse datos sintéticos o previamente desidentificados.
Si excepcionalmente fuera necesario reproducir una incidencia utilizando información real, el conjunto utilizado deberá limitarse a los campos estrictamente necesarios y protegerse durante todo el proceso.
Para pruebas de funcionamiento se dará preferencia, cuando resulte viable, a direcciones IP reservadas para documentación, identificadores ficticios y configuraciones de dispositivos simuladas.
El uso de datos sintéticos permite comprobar funciones técnicas sin exponer innecesariamente registros correspondientes a visitantes reales.
Antes de utilizar una captura de pantalla para soporte técnico, documentación o resolución de incidencias, deberán ocultarse los identificadores que no sean necesarios para comprender el problema.
Esto incluye direcciones IP completas, identificadores de sesión, direcciones de correo electrónico y cualquier otro dato que aparezca incidentalmente en la interfaz.
Cuando sea necesario proporcionar información técnica a un proveedor para resolver una incidencia, el conjunto enviado deberá reducirse al mínimo necesario.
Siempre que sea posible, se sustituirán valores identificativos por referencias técnicas antes de facilitar el registro.
No se enviarán bases completas de registros cuando un extracto limitado permita investigar el problema.
Los análisis técnicos que requieran distinguir visitantes o dispositivos deberán utilizar ventanas temporales limitadas a la finalidad investigada.
No se mantendrá indefinidamente la capacidad de correlacionar actividad técnica simplemente porque resulte posible hacerlo.
Una vez resuelta la finalidad operativa, deberá evaluarse si los identificadores pueden eliminarse o reducirse.
Cuando un identificador no necesite permanecer estable indefinidamente, podrá aplicarse una rotación periódica o asociada a la finalización de una sesión.
La rotación reduce la posibilidad de vincular actividad técnica correspondiente a períodos diferentes cuando dicha vinculación no sea necesaria.
La desidentificación no se evaluará observando únicamente cada campo de forma aislada.
Se tendrá en cuenta si la combinación de hora exacta, dirección IP reducida, dispositivo, navegador y otros atributos permite volver a distinguir razonablemente a una persona.
Cuando exista un riesgo significativo de correlación, deberán reducirse campos, precisión o granularidad temporal según resulte adecuado.
Para estadísticas que no requieran conocer el instante exacto de una visita, las marcas temporales podrán agruparse en intervalos más amplios.
La utilización de períodos agregados reduce la posibilidad de relacionar un registro estadístico con un evento externo conocido.
Las marcas temporales exactas se reservarán para procesos que realmente necesiten ese nivel de precisión.
Los informes estadísticos deberán evitar, cuando resulte posible, segmentos tan pequeños que permitan inferir la actividad de una única persona.
Cuando una categoría contenga un número insuficiente de observaciones, podrá combinarse con una categoría más amplia o excluirse del informe.
Los datos sometidos a un proceso de anonimización no deberán combinarse posteriormente con fuentes auxiliares con el propósito de reconstruir la identidad de los visitantes.
Los intentos de reidentificación no autorizados se consideran incompatibles con este estándar.
Las pruebas destinadas exclusivamente a evaluar técnicamente la resistencia de un método de anonimización deberán realizarse bajo condiciones controladas y sin reutilizar los resultados para identificar usuarios.
Antes de considerar un conjunto como anónimo se analizará si todavía es razonablemente posible individualizar, vincular o inferir información correspondiente a una persona.
La eliminación del nombre, correo electrónico o dirección IP completa no será suficiente por sí sola si otros campos permiten reconstruir razonablemente la identidad.
Cuando persista una posibilidad razonable de vinculación, el conjunto se tratará como seudonimizado y no como información anónima.
Antes de incorporar una nueva herramienta técnica que recopile información de visitantes, deberá evaluarse qué campos obtiene, qué precisión utiliza y durante cuánto tiempo mantiene los identificadores.
Cuando una funcionalidad pueda operar con menos información, deberá considerarse la configuración que reduzca la recopilación.
La configuración predeterminada de un proveedor no se considerará automáticamente la configuración adecuada para Xaventro.
Cuando una necesidad de seguridad o diagnóstico requiera temporalmente conservar un nivel de detalle superior al habitual, dicha excepción deberá limitarse al problema que la justifica.
Una excepción temporal no deberá convertirse automáticamente en una práctica permanente.
Finalizada la necesidad extraordinaria, se revisará la posibilidad de eliminar o reducir la información adicional recopilada.
Si se detecta una exposición accidental de registros técnicos identificables, se limitará el acceso al conjunto afectado y se evaluará el alcance de la exposición.
Cuando corresponda, se adoptarán medidas para revocar accesos, retirar copias innecesarias, corregir configuraciones y reducir la posibilidad de repetición.
La evaluación del incidente tendrá en cuenta si los datos estaban completos, truncados, seudonimizados, cifrados o protegidos mediante otras medidas.
Cuando finalice la necesidad de conservar identificadores técnicos, estos deberán eliminarse o transformarse de forma que dejen de ser necesarios para distinguir visitantes individuales.
La conservación posterior de estadísticas deberá realizarse, cuando sea posible, mediante información agregada que no necesite mantener el identificador técnico original.
La eliminación de un identificador no deberá considerarse completa únicamente porque haya desaparecido de la interfaz principal.
Cuando resulte técnicamente razonable, deberá comprobarse que no permanezcan copias operativas innecesarias en exportaciones, sistemas secundarios o conjuntos temporales.
Las copias de seguridad seguirán sus ciclos técnicos de conservación y protección correspondientes.
Los métodos de desidentificación deberán revisarse cuando evolucionen las técnicas de análisis o aumente razonablemente la posibilidad de reidentificación.
Una técnica considerada adecuada en un momento determinado puede requerir ajustes posteriores debido a cambios tecnológicos.
Xaventro podrá modificar las medidas descritas en este estándar para mantener un nivel de protección adecuado al riesgo.