10/04/2018Artículo original
Está a punto de cumplirse el plazo de adaptación al nuevo Reglamento de privacidad aprobado por la Unión Europea en mayo de 2016. Es decir, hemos tenido dos años para adaptarnos a las nuevas obligaciones, aunque hay quien parece que aún no se ha enterado, quizás porque cree que no va con él. Esta nueva legislación, conocida como GPDR (o RGPD en español) es mucho más dura que las pre-existentes, y no solo afecta a las empresas europeas, sino a cualquier empresa del mundo que quiera hacer negocios en Europa y con ciudadanos europeos.
Con la nueva legislación los programadores jugamos un papel realmente importante ya que de acuerdo al nuevo Reglamento debemos ser muy diligentes en cuanto a los datos que gestionan nuestras aplicaciones, cómo los recogemos, qué hacemos con ellos y las medidas de seguridad que aplicamos durante el desarrollo, el despliegue y el mantenimiento.
En este artículo vamos a ver cómo afecta el nuevo Reglamento a todo aquél que se dedique al desarrollo.
Cambios en la Ley de Protección de Datos
El 25 de mayo de 2018 empezará a aplicarse el nuevo reglamento de protección de datos que entró en vigor hace dos años.
El nuevo Reglamento General de Protección de Datos (RGPD a partir de ahora) será muy positivo no solo para los usuarios (estaremos más protegidos) sino que también para los desarrolladores, pues mejorará nuestros procesos y flujos de trabajo. Nos obliga a todos a reflexionar más sobre qué datos recopilamos, cómo los recopilamos y qué hacemos con ellos. Aunque la obligación de informar a los interesados cuando se van a recabar, usar o almacenar datos personales ya estaba recogida en la Directiva 95/46/CE (Directiva de la que emana la actual LOPD), el nuevo RGPD concede una mayor importancia a la información que se debe proporcionar a los ciudadanos cuyos datos van a tratarse, y contempla una lista exhaustiva de los contenidos que deben ser expuestos.
Pero no debemos asustarnos, ni siquiera tendremos que consultar necesariamente a un abogado para averiguar las obligaciones que debemos cumplir ya que son de sentido común. Dichos cambios pueden resultar tediosos pero la buena noticia es que técnicamente son sencillos.
A continuación vamos a centrarnos en los problemas específicos que se encontraría un programador web a la hora de adaptar su flujo de trabajo al nuevo Reglamento. Insistimos en que en este artículo no se trata de hacer una revisión minuciosa de TODO el Reglamento, solo de dar unas orientaciones generales.
¿Qué se consideran datos personales?
Antes de entrar en materia, quizás sea importante aclarar qué considera el nuevo Reglamento un dato personal. (Si esto lo tienes claro pasa al siguiente punto). Según el nuevo marco europeo:
Esta definición es muy importante para los desarrolladores, puesto que nos está diciendo que entre los datos personales se incluye por ejemplo: la dirección IP, el identificador de un dispositivo móvil, el identificador de los navegadores, las etiquetas RFID, las cookies, la telemetría… Y por supuesto, las identificaciones de las cuentas de usuario, y cualquier otra forma de datos generados por el sistema que identifique a una persona física.
¿A quién le afecta este Reglamento?
Las normas europeas de protección de datos, son y siempre han sido, extraterritoriales. Es decir, aplican a todos los datos personales recopilados, procesados y retenidos sobre personas dentro de la Unión Europea, independientemente de su nacionalidad. O sea, que si tú haces negocios en Europa da igual que físicamente tu domicilio social esté en la Conchinchina, tu empresa está obligada a cumplir con la normativa europea.
El tamaño aquí tampoco importa, el reglamento aplica a todo tipo de empresas u organizaciones, públicas y privadas. Así que todos aquellos que levantamos este país (autónomos y pymes) debemos también cumplirlo aunque a nuestro favor está el que debemos hacer menos papeleo ?.
¿Debes cambiar tu forma de trabajar?
Independientemente del lenguaje de programación que utilices en tu día a día o del tipo de aplicaciones que desarrolles, el RGPD te exigirá mayor transparencia a la hora de hacer las cosas y quizás una estructura definida. Esto, que a priori puede parecer un tanto engorroso, verás que se trata de requerimientos de sentido común.
A continuación veremos cómo el RGPD impactará sobre tu trabajo.
UN POCO DE SENTIDO COMÚN
La creación de flujos de trabajo de protección de datos, la captura innecesaria de datos o la pérdida de los mismos, requieren que todos los integrantes de un mismo proyecto trabajen a partir de un conjunto claramente definido de bibliotecas, herramientas y frameworks. Por esa razón, uno de las primeras cosas que debemos hacer para cumplir con el RGPD es crear una lista de estándares aprobados y metodologías utilizadas tanto para programación como para pruebas.
Evidentemente el RGPD no define una lista con los lenguajes de programación que debemos usar, ni con los sistemas de control de versiones o herramientas de testeo. Lo que realmente importa es que lo que usemos esté claramente definido y exista una trazabilidad para cada situación. Es obvio que somos libres de modificar las herramientas que usamos en cualquier momento; ahora bien, debemos asegurarnos de que las vamos a sustituir por otras que están perfectamente definidas y que son válidas para ser usadas en el framework en el que estamos trabajando. (Vamos, un poco de sentido común).
Por último, no debemos olvidarnos de la parte de la seguridad donde lo mejor es siempre tener una actitud preventiva. Por lo tanto lo primero que debemos hacer es desactivar todo aquello que no nos haga falta: plugins que no usemos o bibliotecas de terceras personas que no hayan sido probadas. A continuación debemos definir en qué consiste una auditoría de seguridad en relación a la privacidad. Esta incluiría por ejemplo un análisis de los datos personales que se capturan (¿son todos ellos necesarios?), dónde se guardan, cómo se protegen, etc. así como la existencia de vulnerabilidades de seguridad.
REQUERIMIENTOS DE DISEÑO
A la hora de diseñar un proceso de protección de datos el Reglamento nos dice literalmente:
Lo cual se traduce en:
- Minimización de datos: recoge solo los datos que necesites.
- No vincules datos personales con otros conjuntos de datos almacenados en una sola ubicación. Si agregas datos, elimina todos los datos personales y de identificación que sea posible.
- Limitación del plazo de conservación de datos: el RGPD exige que se defina el plazo durante el cual trataremos los datos que hemos recabado para un fin determinado. Una vez superado dicho plazo, esos datos deben ser eliminados, a excepción de aquellos que sea necesario guardar por motivos, por ejemplo, legales. Eso es perfectamente aceptable, siempre que se documente ese hecho y su fundamento. Así por ejemplo, la solicitud de un usuario de eliminar sus datos no implicaría (por muy cabezota que se ponga) borrar sus registros de compras junto con sus registros impositivos y contables
A la hora de eliminar los datos personales comprobaremos si en su momento hemos definido correctamente los flujos de trabajo. Imagina que quieres eliminar los datos personales de un usuario (no hay motivos legales para mantener nada sobre el mismo); al terminar, ¿eres capaz de responder de forma afirmativa las siguientes preguntas?:
- ¿Estás completamente seguro de que no queda ningún dato personal del usuario en los archivos de la empresa?
- ¿Seguro? ¿Lo has borrado de la base de datos que usó el becario para hacer pruebas en pre-producción?
- ¿Lo has borrado de los backs-up? Ajá, sí también de ahí lo tienes que borrar.
- ¿Ha habido transferencia de datos a terceros? (Por ej. cuando contratasteis aquella campaña de Marketing a una agencia externa) ¿Les habéis pedido que eliminen sus datos? ¿Has verificado que lo han hecho?
Otro aspecto fundamental a la hora de diseñar un sistema de protección de datos es la definición de los permisos, ¿quién tiene acceso a qué dentro de la empresa? y también el cifrado de datos, los datos se deben cifrar en tránsito y en reposo (esto último es muy importante y debes verificar que tus almacenes de datos lo soportan).
CONSENTIMIENTO LIBRE Y MECANISMOS DE ACCESO A LOS DATOS
El RGPD pretende devolver al individuo el control total sobre sus datos personales usando para ellos mecanismos de acceso y consentimiento.
El consentimiento debe ser inequívoco y explícito
Es decir, siempre va a recaer en ti el demostrar que el usuario te ha dado su permiso. Por lo tanto, si aún no lo has hecho, revisa todos tus procedimientos de toma de datos y comprueba que en todos ellos el usuario acepta libremente la cesión de sus datos. (Por ejemplo, no puede estar marcado por defecto el botón de aceptación de la Política de privacidad de tu web).
El proceso de desarrollo de tu back-end también deberá garantizar la documentación con una marca de tiempo sobre el tipo de consentimiento que dio el usuario, cómo lo dio y si lo retiró o no.
Facilitar a los interesados el ejercicio de sus derechos
El RGPD contiene los ya tradicionales derechos ARCO y también algunos nuevos derechos. Además, establece condiciones concretas sobre el procedimiento a seguir para atender a los interesados en el ejercicio de sus derechos.
En lo que a los procedimientos se refiere, estos deben ser visibles, accesibles y sencillos. Un ejemplo sería una interfaz segura donde el interesado pudiera ejercer sus derechos de acceso, como la edición y corrección de la información, el derecho a descargar sus datos, el derecho a restringir el uso de sus datos o el derecho a la eliminación de los mismos. La zona de configuración de las cuentas o los paneles de privacidad son los sitios idóneos donde incluir estas opciones.
TESTING Y MANTENIMIENTO
Por último, programar teniendo en mente el RGPD significa incluir la protección de datos por defecto a la hora de diseñar nuestros procesos.
Los procedimientos de seguridad deben predecir las formas en que los usuarios no autorizados accederían a los datos reales en nuestro sistema. Por ejemplo: ¿se registraría una búsqueda sospechosa de datos de usuario, o una modificación de un registro, como una vulnerabilidad de seguridad? ¿Los datos están almacenados en las cookies de inicio de sesión? ¿Podría alguien obtener acceso a los datos activando intencionalmente un error? ¿Has probado qué fácil es acceder a los datos heredados? Aquí es donde debemos pensar de forma creativa, y algo malintencionada, sobre cómo y dónde los datos pueden caer en manos inadecuadas. Esto, nuevamente, es sentido común pero, no hacerlo, ahora tiene consecuencias legales, además de en el negocio.
Las pruebas de protección de datos por defecto también deberían considerar las alertas externas. ¿Disponemos de algún medio para que alguien externo nos avise sobre infracciones de datos, ya sean potenciales o reales?
Y recuerda la regla de oro del RGPD: do-cu-men-tar-lo.
En resumen
En este artículo hemos visto cómo el RGPD nos exige que tengamos más cuidado con los sitios, servicios y aplicaciones que creamos, mayor transparencia a la hora de recopilar y utilizar los datos, que seamos más considerados con nuestros usuarios y más exhaustivos en nuestros procesos de desarrollo y documentación.
Como has podido ver ninguno de los puntos mencionados te resulta ajeno a tu día a día, por lo que si no quieres que te pille el toro, ya puedes empezar con todo esto inmediatamente y si te atascas, existen cientos de empresas/ consultores expertos en la materia deseando ayudarte.
Y ten en cuenta que las posibles multas que pueden caer a tu empresa no son para tomárselas a broma ?