¿Cómo trabajas con tus bases de datos en producción? ¿Y en entornos de desarrollo? Las organizaciones manejan un enorme volumen de datos personales en sus plataformas de datos y documentos electrónicos digitalizados y físicos que custodian. El 90% de los documentos que las empresas almacenan tiene algún tipo de información de carácter personal.
¿Estás tomando las medidas adecuadas para proteger la información sensible, como exige la normativa? La ofuscación puede ayudarte a cumplir con la GDPR. En este artículo te contamos cómo.
¿En qué afecta GPDR a los departamentos de desarrollo y testing?
Tras la entrada en vigor del reglamento Europeo de Protección de Datos (GDPR) se pretende convertir a Europa en una de las zonas más seguras del mundo para el desarrollo de un comercio de confianza y establecer la privacidad de los datos como un derecho fundamental de las personas. Se estima que con este reglamento, en vigor desde Mayo de 2018, las sanciones por vulnerar el derecho fundamental a la protección de datos de carácter personal de los ciudadanos, pueden alcanzar los 20 millones de euros o el 4% del volumen de negocios anual de las empresas e instituciones.
Las organizaciones a menudo necesitan depurar errores de producción, lo que muchas veces en el pasado se ha venido haciendo apuntando directamente aplicaciones de desarrollo directamente a la BBDD de producción. Esto, que es por sí una mala praxis, es una de las medidas que viene a regular la GPDR con fuerza y es precisamente una de las cosas que nunca debemos hacer.
Otra de las malas praxis habituales es la de copiar datos de producción almacenados en bases de datos de producción hacia bases de datos de no producción o prueba. Esto se realiza para completar de manera realista la prueba de funcionalidad de la aplicación y cubrir escenarios en tiempo real o casos de prueba, para minimizar los errores o defectos de producción. Como resultado de esta práctica, igualmente a lo comentado previamente, un entorno de no producción puede convertirse en un blanco fácil para los ciberdelincuentes o empleados malintencionados que buscan datos sensibles que pueden ser expuestos o robados. Debido a que un entorno de no producción no está tan estrechamente controlado o administrado como el entorno de producción el GDPR establece una normativa clara sobre estos entornos y como se deben tratar los datos en ellos, prohibiendo el uso de datos reales sensibles en ellos.
[box type=”info”] Acceder a datos de producción desde entornos no productivos está totalmente prohibido por ley.[/box]¿Podemos depurar conectando a nuestra BBDD de producción?
No, pero podemos depurar contra una base de datos de producción convenientemente ofuscada, de forma que a todos los efectos sea la BBDD de producción (mismos registros, claves, relaciones e interdependencias…) pero que sea totalmente imposible obtener datos sensibles de ninguna forma.
A dáa de hoy, SQL Server no dispone de un mecanismo nativo para dar soporte a la regulación GPDR en el escenario que estamos comentando (depurar utilizando datos de producción). Se hizo un intento con “Static data masking” en SQL Server 2019, que finalmente fue abortado sin fecha tentativa de resolución. Ninguna de las características que ofrece SQL Server como tecnología de seguridad y enmascaramiento cubre este escenario:
- Dynamic data masking
- No sirve puesto que un desarrollador con acceso a los datos podría desactivar la feature con los permisos adecuados y por tanto acceder a la información, que está almacenada sin cifrar
- Cifrado
- Transparent data encryption
- Solo cifra el soporte de E/S. El dato por tanto, con las credenciales adecuadas está disponible y accesible
- Always encrypted
- Independientemente de que activar Always encrypted tiene bastantes limitantes a tener en cuenta, esta característica finalmente produce que al activarla, si conectamos con la aplicación que tiene el driver registrado se accederá al dato con normalidad (justo lo que no se quiere) y si no, veremos un churro binario o nulls en las celdas cifradas, cosa que tradicionalmente uno tampoco quiere ver cuando depura datos contra “producción”
- Claves de cifrado
- Un developer con suficientes credenciales puede acceder a esa clave y descifrarla. Si no es el caso, estaremos como en el caso anterior, con celdas que mostrarán un churro binario o nulls en las celdas cifradas, lo que uno tampoco quiere cuando esperar depurar
- Transparent data encryption
- Row level security
- No sirve puesto que un desarrollador con acceso a los datos y suficientes credenciales podría desactivarse a si mismo y por tanto acceder a la información, que está almacenada sin cifrar
¿Qué es la ofuscación de datos? ¿Cómo se aplica?
En el entorno tecnológico, la ofuscación de datos es el proceso de reemplazar información sensible existente en entornos de prueba o de desarrollo con la información que parece información real de producción, pero sin que aparezcan datos reales que incumplan el GDPR. Por lo tanto, las técnicas de ofuscación de datos se utilizan para proteger los datos mediante la randomización de los datos sensibles contenidos en entornos de no producción, o enmascarando la información identificable con valores realistas, lo que permite a las empresas mitigar el riesgo de exposición de datos y cumplir así el GDPR.
Para que esta técnica sea realmente interesante para entornos de testing y desarrollo:
- La aleatorización de datos no debería generar datos confusos, sino coherentes con lo que se espera.
| Dato real | Dato ofuscado |
| Nombre: Enrique Catalá Bañuls |  Xfajavsñf asfjevstñs fjekscto00xx |
| Nombre: Enrique Catalá Bañuls |  Alejandro Bernabeu Imaginario |
| Calle: Avenida pintor baeza, 12, 6ºA | fjffj fñarkf toff10, 100f, 5X |
| Calle: Avenida pintor baeza, 12, 6ºA | Calle andromeda, 14, 2ºA |
| DNI: 53234565-F | XXXXXXXX-X |
| DNI: 53234565-F | 456543456-F (siendo un dni que pase validaciones de dni, pero aleatorio en si mismo) |
Es decir, que en un ejemplo cualquiera, una muestra aleatorizada de DNI, debería generar un DNI válido conforme al formato DNI, que pase reglas de validación que la propia aplicación pueda soportar. Es aquí donde la solución que hemos desarrollado en SolidQ, “Database Obfuscator”, entra en acción:
- La aleatorización debería realizarse en un tiempo razonable
- De nada nos sirve que se consiga, si se tarda 24h en conseguir finalizar el proceso y los datos ya no son relevantes
- La aleatorización debería realizarse únicamente de los datos sensibles, que pueden ser cambiantes y además estar entre decenas de miles de columnas en miles de tablas
- Hay que evitar manualidades y confiar lo mínimo en el factor humano. El sistema debería ser autosuficiente
¿Qué es Database Obfuscator?
Database Obfuscator es una solución que ofrecemos desde SolidQ, con el que somos capaces de realizar el proceso de ofuscación basado en un conjunto de reglas que dependen del tipo de información sensible almacenada. Para implementar dicho servicio, hemos diseñado e implementado una herramienta de base de datos, que es capaz de detectar qué columnas debemos ofuscar, que ofuscará siguiendo patrones de anonimización transparentes (nadie al ver el resultado sabrá que ha sido anonimizado) y que además lo hará tan rápido como el hardware sobre el que corra lo permita.
Los principales beneficios de esta herramienta son:
- Analizador automático que detecta qué columnas hay que ofuscar para conseguir una BBDD ofuscada que cumpla GPDR
- Diccionarios de ofuscación completamente configurables para satisfacer cualquier escenario con dato real y generar valores con sentido para la aplicación cliente
- Ofuscación a la máxima velocidad que soporte la cabina de almacenamiento donde se encuentre el dato a ofuscar
- Soporte opcional de creación de BBDD de testing, como un subconjunto de datos que cumplen integridad referencial
- Ejemplo: Crear una base de datos de un 5% del tamaño de la de producción, ofuscada y consistente…para ser utilizada como imagen docker por equipos de desarrollo
- Pausa y resumen del proceso de ofuscación
- API modular, con soporte de Windows y Linux
Ejemplo de uso
En estos ejemplos de despliegue detallo los tiempos empleados en el proceso de ofuscación:
- 2h 38m ofuscando una BBDD de 1Tb de información OLTP
- 32 minutos generando una BBDD de 58Gb a partir de la anterior BBDD de 1Tb, que finalmente acaba como imagen docker lista para ser consumida por el equipo de desarrollo
¿Quieres saber más de nuestra solución Database Obfuscator?
Descubre más detalles y solicita una demo en nuestra página dedicada al Cumplimiento y GDPR.
