La Universidad de Copenhague confirmó que unos atacantes accedieron a un entorno de pruebas con datos personales de 525.000 personas. La etiqueta «pruebas» nos sugiere que estamos ante un espacio secundario, separado de lo que importa. Pero, si allí hay datos personales, ¿qué estamos dando por seguro exactamente?
La noticia no cuenta cómo acabaron esos datos en ese entorno ni qué controles tenía, y no voy a rellenar ese hueco con suposiciones. Pero el patrón lo reconocerá cualquiera que haya pasado por un equipo de desarrollo o de sistemas.
Cómo llegan los datos reales a pruebas
Puedo entonar el mea culpa sin problema, si necesitas reproducir un error que solo aparece con datos reales, se restaura una copia de producción en preproducción para salir del paso y esa copia pasa a formar parte del entorno de pruebas. Contiene nombres, documentos de identidad, direcciones o historiales. Lo provisional, en sistemas, tiene una vida sorprendentemente larga.
Y ese entorno suele estar peor cuidado que producción: contraseñas compartidas por todo el equipo, usuarios de base de datos con más permisos de los necesarios, copias sin cifrar, accesible desde más redes «porque es para pruebas», parches que llegan tarde y registros de acceso que nadie revisa. Los mismos datos, con menos protección. Desde luego suena goloso para quien ataca.
Qué se debería hacer
- No restaurar copias de producción tal cual. Hay muchas maneras de anonimizar los datos de una manera sencilla, sin mucho esfuerzo. Ojo con la seudoanonimización: si se puede revertir, siguen siendo datos personales.
- Usar datos sintéticos siempre que se pueda. Para la mayoría de pruebas funcionales no hace falta una persona real; hace falta un registro con la forma correcta. John Doe al rescate.
- Aplicar en pruebas los mismos controles de acceso que en producción. Cuentas nominales, permisos mínimos y nada de credenciales compartidas en un fichero de configuración.
- Inventariar los entornos y ponerles fecha de caducidad. Lo que no se apunta no existe.
Además, el RGPD no distingue entre producción y pruebas. El principio de minimización (artículo 5) y la protección de datos desde el diseño (artículo 25) se aplican a cualquier tratamiento, y copiar la bd al entorno de pruebas es un tratamiento. Si para probar no hace falta el DNI real de nadie, no debería estar ahí.
El nombre del entorno no reduce el valor de los datos que contiene. Construimos espacios para ensayar sin afectar al servicio, y es licito que existan; lo que no puede pasar es que «no es producción» acabe funcionando como permiso para relajarse.