La GDPR cumple su primer año y medio este mes de noviembre. Parece que los medios ya no hacen tanto ruido sobre el tema, pero la ley sigue en vigor y las estadísticas siguen indicando que todavía no se cumple la normativa de protección de datos.

 

El 79% de las empresas españolas aún no cumple con la GDPR.

cumplimiento gdpr

Según el último estudio de la consultora Capgemini, solo el 21% de las empresas españolas, a fecha de Junio 2019, cumple con la “ya no tan nueva” normativa. Curiosamente, el 78% de las mismas esperaban cumplir un año antes. ¿Ya no nos importa? ¿Necesitamos oír más noticias de multas en los medios para tomar las medidas necesarias?… No te preocupes, este texto no pretende ser un artículo de opinión 😉.

El objetivo de este artículo es tratar aspectos que afectan directamente a la administración de bases de datos haciendo un repaso a los Artículos de la GDPR más relevantes y dar una interpretación (y soluciones) para justificar el cumplimiento.

 

Cómo reducir el riesgo de exposición de información sensible en tu base de datos y evitar multas.

En primer lugar, haremos un repaso rápido por los ejemplos de datos personales más comunes que debemos proteger ante posibles brechas de seguridad:

  • Nombre, documento de identidad, dirección, número de teléfono…
  • Cuenta de correo electrónico, información enviada a redes sociales, dirección IP, cookies…
  • Información física, psicológica, médica, genética…
  • Etc

 

Si trabajas con este tipo de información en entornos de producción o desarrollo y test, te recomiendo leer hasta el final este post.

 

A continuación, destacamos los artículos directamente relacionados con las implicaciones de una posible exposición de la información sensible debida a brechas de seguridad:

 

Como resumen y haciendo referencia a los artículos 33 y 34, las organizaciones y empresas estamos obligados a proteger la información sensible e informar en caso de brecha de seguridad, tanto a las autoridades competentes (Agencia de Protección de Datos si te encuentras en España, y en menos de 72h) como a las personas físicas afectadas si sus datos han podido ser expuestos.

 

¿Estarías preparado para identificar esa brecha y comunicarlo en el plazo establecido? ¿Has pensado en el impacto, en cuanto a reputación, que podría suponer comunicar una brecha de seguridad a tus clientes o proveedores? Las implicaciones negativas que supone la GDPR no son sólo cuantías económicas de las multas si no cumples la normativa…

 

Afortunadamente, existen unos puntos interesantes en estos dos artículos 😊:

“La comunicación al interesado a que se refiere el apartado 1 no será necesaria si se cumple alguna de las condiciones siguientes: a) el responsable del tratamiento ha adoptado medidas de protección técnicas y organizativas apropiadas y estas medidas se han aplicado a los datos personales afectados por la violación de la seguridad de los datos personales, en particular aquellas que hagan ininteligibles los datos personales para cualquier persona que no esté autorizada a acceder a ellos, como el cifrado. ”

“El responsable del tratamiento la notificará a la autoridad de control competente de conformidad con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas.”

 

Es decir, se establece que si nuestros datos están anonimizados o encriptados y se produce una brecha de seguridad, no tendremos obligación de notificar a los afectados ni a la Autoridad de Control, puesto que es ininteligible para terceros y porque dicha violación de la seguridad no constituye un riesgo para los derechos y las libertades de los ciudadanos.

 

Si nuestros datos son inteligibles:

  • Reducimos el riesgo de sanciones
  • Evitamos el proceso de comunicación a la Autoridad de Control y a los posibles afectados
  • Reducimos el riesgo de exposición a críticas y coste en términos de reputación corporativa

 

¿Cómo podemos hacer inteligibles esos datos sensibles?

Mediante un proceso de ofuscación.

Un proceso de ofuscación se basa en una serie de reglas para enmascarar determinada información dependiendo de qué tipo sea. Utiliza diccionarios para que la información parezca real en caso de brecha de seguridad.

Por ejemplo, supongamos que queremos encriptar mi nombre: Paula García. Utilizando una clave de encritación, podría aparecer en un campo “nombre” algo parecido a “6ey9e Netzue”, es decir, algo que no parece un nombre y podría evidenciar que estamos utilizando un método para encriptar.

Mediante un proceso de ofuscación, el nombre vendría asociado a su equivalente en el diccionario, supongamos, “Mariana Romero”. Los valores de las bases de datos ofuscadas parecen reales.

Además, en los diccionarios son configurables. Si quieres saber más sobre este proceso, te recomiendo el artículo de Enrique Catalá “Depurar aplicaciones contra datos de producción: ofuscación y GDPR”.

 

¿Cuándo debemos ofuscar?

En entornos en producción, pero también en entornos de desarrollo y test (porque la normativa también aplica). Es un proceso habitual trabajar con datos reales cuando estamos en fase de prueba en nuestra base de datos en desarrollo para comprobar de manera realista si la funcionalidad es la esperada y cubrir escenarios en tiempo real.

Los ciberdelincuentes tienen este aspecto en cuenta y, sin darnos cuenta, este entorno de pruebas puede ser un blanco fácil (y una puerta de entrada) a datos personales que no deben ser expuestos.

Si te encuentras en esta situación, te recomendamos que tomes medidas cuanto antes.

 

En SolidQ hemos desarrollado la herramienta Database Ofuscator que permite randomizar la toda la información sensible de tu base de datos cloud u on-premise, usando una serie de reglas para randomizar los datos en diccionaros (configurables) mediante TVFs y banderas de consulta especiales, sin comprometer el rendimiento de SQL.

 

¿Quieres saber más sobre nuestra herramienta para SQL Server? En esta página encontrarás más información sobre Database Ofuscator.

¿Te interesa conocer, a nivel técnico, cómo funciona el proceso de ofuscación? Te recomendamos el artículo de Enrique Català «Depurar aplicaciones contra datos de producción: ofuscación y GDPR», así como «Data Masking de datos sensibles… ¡piénsalo dos veces! de Rubén Garrigós.

Paula García Esteban