MainMind

True & racing de norte a sur


Seudonimización y anonimización de datos personales en la RGPD

La utilización de técnicas de encriptación, índices alternativos y otros elementos de seguridad no garantizan la anonimización de datos mientras sea posible acceder a la misma información atravesando un camino más complejo, pese a ello permitiendo identificar indirectamente a la misma persona física o conjunto de datos.

Ninguna técnica de anonimización carece de deficiencias, aunque algunas de ellas permiten disociar la información suficiente como para no poner en peligro la privacidad suponen la alteración inherente de las fuentes.

En ciertos escenarios, con grandes valores de una muestra sería posible de manera eficiente suprimir los datos no relevantes identificativos de un individuo. Por ejemplo, la estadística de afección de una enfermedad cardiológica en una región no necesita mostrar el nombre del paciente.

Además de la eliminación de datos no relevantes, también es posible realizar su generalización. Por ejemplo, sustituimos la edad por un rango o la localidad por un código postal más amplio.

Estas técnicas de anonimización denominadas generalmente k-anonymity han ido evolucionando, introduciendo mejoras para evitar revertir el anonimato centrados en dos posibles factores:

  • La homogeneidad de la muestra, es decir, un valor sensible dentro de un conjunto determinado de registros en los que los valores son idénticos. Por ejemplo, el 99% de la muestra de pacientes obtenida en la micronesia no contiene haplogrupo de tipo M, con lo que sería más sencillo identificar ese 1% restante de origen indio.
  • Conocimientos genéricos, por ejemplo, conociendo un rango determinado de edad en la que los accidentes de tráfico son más frecuentes es posible extraer un grupo de datos reducido con ciertas características.

Al igual que sucede con los cifrados, el esfuerzo de tiempo/dinero debe ser lo suficientemente alto para que su realización no salga a cuenta por parte del atacante. El análisis de riesgos y la adopción de buenas prácticas, protocolos, formación del personal… definen la intención y diligencia del responsable del fichero.

Pese a todo ello, la identificación indirecta sigue siendo un riesgo difícil de abordar o proteger. Si varias empresas disponen de datos anonimizados independientemente, sería posible cruzarlos para llegar a identificar a una persona concreta. Por ejemplo, datos de movimientos de un banco, resultados médicos de una revisión, pólizas de seguros contratadas, datos demográficos de una localidad…

Tal vez ahora se vea más claro el valor y poder de la información que manejan algunas empresas nacidas de internet como Google, Linkedin, PayPal o Facebook por poner nombres a las bases de datos.

Deben analizarse los peligros de reidentificación según los objetivos y finalidad de la información anonimizada, teniendo claro el umbral de riesgo aceptable.

Una vez repasadas alguna de los conceptos de anonimización, podemos entrar en lo que los perfiles jurídicos denominan seudonimización: sustitución de un atributo (normalmente único) por otro en un registro; dentro de un perfil técnico que haya ideado una base de datos relacional lo denominaría: clave primaria, con su ejemplo más sencillo de utilizar un DNI como tal, un valor autonumérico o un GUID.

Si bien estas técnicas vienen aplicándose en cualquier base de datos relacional, las recomendaciones sugieren (si no se ha hecho todavía) la adición de una capa adicional de seguridad a los datos, a las claves u a ambos, de cifrado con clave secreta. Si además añadimos un valor aleatorio (salt) y funciones hash de cálculo para su comprobación, el coste efectivo frente a un ataque se incrementa.

Teniendo en cuenta el almacenamiento que suele realizarse de las claves y contraseñas, sería aconsejable utilizar técnicas adicionales mixtas. Por ejemplo, si en lugar de basarnos solo en las contraseñas utilizamos datos biométricos en un canal seguro, es decir, una lectura de iris, un patrón de voz o una huella dactilar es otro dato binario más al que podemos aplicar un hash determinado, pero si el canal de obtención es único y seguro podemos combinarlo con una autenticación doble, poniendo las cosas más difíciles en caso de intentos de acceso no autorizados a la información.

 

 

Tamaño de Base de datos y log en SQL Server

Desde las bases de datos del sistema podemos extraer todo tipo de información, para localizar dentro de una BBDD de una instancia concreta de SQL podemos extraer con una consulta la información de los tamaños que ocupan:

 

with mf
as
(
    select database_id, type, size * 8.0 / 1024 size
    from sys.master_files
)
select 
    name, db.is_auto_shrink_on, 
    (select sum(size) from mf where type = 0 and mf.database_id = db.database_id) DatosMB,
    (select sum(size) from mf where type = 1 and mf.database_id = db.database_id) LogMB
from sys.databases db

 

Firebird: conexión fallida

Todavía hay aplicaciones que necesitan interoperabilidad, con bases de datos de Firebird, desde herramientas de Office u otros orígenes de datos; puede realizarse desde ODBC (Open DataBase Connectivity), debemos asegurarnos si la aplicación es de 32 o 64 bits, en ambos casos es posible instalar el driver desde la página oficial, es posible tener los dos instalados sin problema. Si ya disponemos de una versión podemos aprovechar para actualizarla y forzar la instalación de la que nos falte:

Desde linea de comandos y el directorio de instalación de la versión, por ejemplo para la versión de 32 bits:

instclient.exe install gds32

Evento 17137 en bases de datos SQL Server

La configuración por defecto de una base dedatos en Microsoft SQL Server en sus diferentes versiones, permite descargar al servidor de la caché la propia base de datos cuando la propiedad "AUTO CLOSE" esta activada, se genera el evento:

"Event ID 17137 Source: MSSQL$NOMBREUSUARIO Starting up database 'NombreDeLaBBDD'"

Es posible modificar el comportamiento desde SQL Management Studio, haciendo clic con el botón derecho sobre la base de datos, en Opciones indicar la propiedad "Auto Close" a False:

En las versiones SQL Express siempre aparece activado, en el resto desactivado.
Listado de las BBDD con la propiedad activada:

SELECT name FROM master.sys.databases WHERE is_auto_close_on = 1

Cambiar mediante sentencia SQL:

ALTER DATABASE <NombreBBDD> SET AUTO_CLOSE OFF

 

 

Ficheros bak no aparecen en SQL Server

Al trasladar copias de seguridad de SQL Server e intentar restaurarlas desde una ubicación diferente a la predeterminada, desde el explorador de Management Studio (SMSS) aunque sepamos que dentro de una carpeta concreta están los ficheros pueden no aparecer, si no están asignados los permisos; deberemos asignar permisos de lectura por lo menos sobre el usuario "NT SERVICE\MSSQLSERVER" del equipo local donde se ejecuta la instancia (por defecto)

Cuenta con la que se ejecuta el servicio:


Asignación de permisos a la carpeta donde se encuentran las copias de seguridad: