¿Por qué se declaran tan pocas transferencias internacionales de datos?

En la jornada sobre cloud computing que la Agencia Española de Protección de Datos (AEPD) organizó en enero de 2012 se llegó a la conclusión de que la computación en la nube había generado un cambio de paradigma en las subcontrataciones y en las transferencias internacionales de datos.

Este cambio de paradigma fue analizado posteriormente en este blog para comprobar cómo estaba actuando la oferta y la demanda en materia de subcontrataciones y transferencias internacionales.

En esta ocasión me gustaría analizar si este cambio de paradigma se ha manifestado en la tipología de las transferencias internacionales que fueron autorizadas por el Director de la AEPD durante 2012 y si la globalización y el abaratamiento de los servicios de hosting, unido a la aparición de nuevas categorías de servicios, está provocando una menor identificación de los supuestos en los que se produce una transferencia internacional de datos.

En relación a la primera cuestión, es fácil comprobar que las transferencias internacionales de datos autorizadas por el Director de la AEPD en 2012 se distribuyen en dos grandes tipologías:

– 122 transferencias internacionales realizadas en el marco de un contrato de prestación de servicios de encargado de tratamiento (call center, gestión de aplicaciones, gestión de bases de datos).

– 53 transferencias internacionales relativas a la gestión centralizada de datos de RRHH o de clientes en la sede central de una empresa multinacional.

En ninguna de ellas se identificó como destinatario de la transferencia internacional a alguno de los grandes proveedores que ofrecen servicios de hosting como prestación principal, es decir, como prestación no complementaria a los servicios de call center o gestión de bases de datos.

Tampoco se identificó como destinatario de la transferencia internacional a alguno de los grandes proveedores de cloud computing, en su modalidad de nube pública, ni a las principales redes sociales.

De este análisis rápido, basado exclusivamente en las transferencias internacionales autorizadas por el Director de la AEPD en 2012, extraigo las siguientes conclusiones:

  1. Sigue pareciéndome bajo el número de empresas que identifican y declaran como transferencia internacional los servicios contratados a proveedores que tratan datos en países con un nivel de protección no equiparable al de la UE. Según la Memoria de la AEPD de 2011, sólo se han autorizado 735 transferencias internacionales en total en 12 años, incluyendo las transferencias a la sede central de multinacionales.
  2. No parece que exista una práctica generalizada de declarar como transferencia internacional los servicios de cloud computing en los que los datos son almacenados en países de protección no equiparable.
  3. Lo mismo sucede con la contratación de servicios de mero hosting de datos.
  4. Lo mismo sucede con el tratamiento de datos realizado por las empresas en las redes sociales.

Estas conclusiones me llevan a plantear si se están dando en el mercado circunstancias que dificultan la identificación de los supuestos en los que se produce una transferencia internacional de datos que exigiría la autorización del Director de la AEPD.

Todo parece indicar que efectivamente se está produciendo una progresiva pérdida de control por parte del responsable del fichero sobre los distintos encargados y subencargados del tratamiento que acceden a sus ficheros. Por otro lado, hay nuevos servicios en los que cuesta más identificar dónde están los datos a lo largo del ciclo de vida de la relación con el proveedor.

Agrupando estas nuevas circunstancias con las que ya pueden considerarse clásicas, podríamos enumerar las principales razones por las que no llegan al Director de la AEPD todas las transferencias internacionales que se están produciendo:

  1. Tratamiento realizado aparentemente en la UE o en país con protección equiparable
  2. Consentimiento del usuario final a través de los términos y condiciones del servicio
  3. Desconocimiento de la obligación por parte del responsable del fichero
  4. Falta de identificación de la transferencia internacional en ciertos servicios
  5. Imposibilidad de controlar la ubicación de los datos en ciertos servicios
  6. Aplicación de técnicas de cifrado, ofuscación y fragmentación de datos
  7. Dificultad para controlar las subcontrataciones en materia de hosting

Además de estas razones, estamos asistiendo a un proceso de transformación de la manera en que vemos la información y su almacenamiento. Como decía Manuel Castells en 2001, la información ya no es un activo a almacenar, sino un flujo a optimizar, y hoy más que nunca cobra sentido esta afirmación.

Por ello, es comprensible que cada vez sea más difícil, y a la vez irrelevante, saber dónde están realmente los datos.

Cómo funciona MEGA, el nuevo Megaupload

Este fin de semana se lanza MEGA, la nueva apuesta del fundador de Megaupload, en la que pretende superar todos los obstáculos que tendría una versión funcionalmente idéntica a la anterior.

Los elementos clave de la nueva versión son los siguientes:

1. Documentos privados

El nuevo MEGA presenta como factor innovador un sistema de aseguramiento de la privacidad que no exige instalar software dedicado, ya que cifra y descifra los datos de forma transparente en el navegador del usuario a partir de una clave pública de 2.048 bits. El usuario es el único que tiene la clave de acceso a sus contenidos, alojados de forma cifrada en la nube de MEGA.

La estrategia de MEGA consiste en trasladar al usuario la responsabilidad de los contenidos almacenados en su nube, alegando que estos contenidos están cifrados y que, aunque quisiera, MEGA no podría conocer su nivel de legalidad, ya que no tiene acceso a ellos.

2. Fragmentación y dispersión

El sistema de almacenamiento de MEGA es multicéntrico, es decir, está distribuido en una larga serie de servidores en todo el mundo, que no son de su propiedad. Los contenidos que se alojen en la nube privada de cad usuario serán inmediatamente cifrados, fragmentados y distribuidos por todo el mundo. Ello significará que, a diferencia del P2P, un servidor nunca tendrá el fichero completo, ni siquiera un fragmento reconocible del fichero. Cada servidor tendrá una porción ininteligible que sólo podrá ser unido al resto del fichero a través de la plataforma de MEGA y con la clave del usuario.

Se trata del sistema de ofuscación que Google y otros proveedores de cloud computing ya utilizan para cumplir las exigencias de sus clientes en materia de confidencialidad de la información y protección de datos personales.

Según MEGA, el usuario tendrá el control absoluto sobre las personas que podrán acceder de forma cifrada y confidencial a sus carpetas compartidas, de manera que ningún otro usuario, incluido MEGA, podrá participar en las comunicaciones confidenciales ni acceder a los contenidos cifrados. Ello eliminaría la posibilidad de que MEGA pudiese supervisar dichos contenidos o atender requerimientos judiciales para acceder a ellos. Estos requerimientos deberían dirigirse al usuario.

Las dudas que surgen sobre la eficacia de este sistema tienen que ver con las páginas de enlaces que basan sus ingresos en la publicidad y, por lo tanto, en la afluencia masiva de visitantes. Se espera que MEGA aporte la solución definitiva para evitar la trazabilidad de las descargas directas, pero todo parece indicar que el nuevo sistema va dirigido a la creación de redes de confianza y al intercambio de ficheros entre conocidos.

En el momento en que un fichero privado se haga público para permitir la descarga directa de desconocidos, además de dejar de ser privado, se abrirá la posibilidad de conocer el contenido del fichero, el identificador del fichero en el sistema y el identificador del propietario o administrador del mismo. Se entiende que, en su afán de legalidad, y teniendo en cuenta su ubicación en Nueva Zelanda, MEGA deberá disponer de un servicio de atención de reclamaciones y de retirada de contenidos. Será interesante conocer la aplicación práctica del protocolo que MEGA ha diseñado para atender estos requerimientos y desviarlos hacia el usuario, o bien resolver los eventuales conflictos generados entre la entidad que reclame la retirada y el usuario que haya subido el fichero, suponiendo que éste haya permitido, en algún momento, desvelar su existencia y permitir un acceso al mismo.

Respecto a la posible responsabilidad de MEGA sobre los contenidos publicados en la plataforma, hay materia para dedicar un artículo específico. Cabe reflexionar sobre la aplicación de las siguientes figuras:

– El régimen de responsabilidad de los ISP.
– La ceguera intencional utilizada en el blanqueo de capitales.
– La inducción y la cooperación necesaria.

Todo ello sin descartar el triunfo de la ingeniería jurídica diseñada por Kim Dotcom para eludir la ley.

ACTUALIZACIÓN

Protocolo que seguirá MEGA en el caso de que reciba una denuncia de infracción de los derechos de autor

Formulario de denuncia de infracciones de los derechos de autor en MEGA

Resumen de la nueva ISO 22301 sobre gestión de la continuidad del negocio

La ISO 22301:2012 es el nuevo estándar internacional que especifica los requisitos para configurar y gestionar de forma eficaz un Sistema de Gestión de la Continuidad de Negocio (BCMS por sus siglas en inglés).

Podríamos decir que el BCMS es para la continuidad del negocio lo que el SGSI de la ISO 17799 y la ISO 27001 es la para la seguridad de la información. De hecho, el BCMS y el SGSI comparten el típico proceso continuado de mejora Plan-Do-Check-Act (PDCA) entre otros muchos puntos en común.

Con la implantación de un BCMS una empresa se planteará las siguientes metas:

1. Entender las necesidad de establecer una política y unos objetivos en relación a la gestión de la continuidad del negocio

2. Implantar controles y medidas dirigidas a gestionar la capacidad de la organización para atender incidentes que puedan tener un impacto significativo en la continuidad de su negocio

3. Monitorizar y revisar el rendimiento y la eficacia del BCMS

4. Mejorar continuamente el modelo de acuerdo con una medición objetiva de los resultados

El BCMS, como cualquier otro sistema de gestión, tiene los siguientes componentes:

1. Una política

2. Unas personas con responsabilidades definidas

3. Unos procesos de gestión relacionados con la política, la planificación, la implantación, la operativa, la valoración del rendimiento, la revisión de la gestión y la mejora contínua.

4. Unos documentos que suministren evidencias auditables

5. Cualquier proceso de gestión de la continuidad del negocio que sea relevante para la organización

La ISO 22301:2012 es aplicable a organizaciones de cualquier tipo y tamaño que deseen:

1. Establecer, implantar, mantener y mejorar un BCMS,

2. Asegurar la conformidad con políticas declaradas de continuidad de negocio

3. Demostrar la conformidad a terceros

4. Solicitar la certificación o registro de su BCMS por parte de una entidad de certificación

5. Realizar una autoevaluación o una autodeclaración de conformidad con este estándar internacional.

En mi opinión, la implantación de un BCMS conforme con esta ISO supone una prueba inequívoca de la diligencia debida y del esfuerzo realizado por una empresa para garantizar la continuidad de su negocio, contribuyendo al objetivo de minorar su responsabilidad por los daños causados a terceros a causa de la interrupción de su actividad, prestación de servicios o suministro de productos.

Al mismo tiempo, genera evidencias de la existencia de controles preventivos que pueden permitir enervar la responsabilidad penal en el caso de delitos directamente relacionados con la continuidad del negocio, como los delitos medioambientales, el delito de daños o los delitos los relacionados con la seguridad de la información.

Esta ISO es altamente recomendable para los proveedores de outsourcing, cloud computing y hosting, así como para las empresas que gestionan infraestructuras críticas.

Las transferencias internacionales en el cloud computing

Esta semana ha tenido lugar en Bruselas una reunión plenaria del Grupo de Autoridades Europeas de Protección de Datos (Grupo de Trabajo del Artículo 29). Entre los asuntos incluidos en la agenda de la reunión se encontraba la discusión y posible adopción del dictamen sobre computación en la nube, así como del dictamen sobre reglas corporativas vinculantes para encargados de tratamiento de datos. Ello significa que queda poco para que estos dos documentos, que van a influir en el futuro del cloud computing en Europa, salgan a la luz.

Ambos documentos van a referirse ampliamente a uno de los asuntos que más preocupan en la actualidad a las empresas: la ubicación de los datos y la consiguiente transferencia internacional de los mismos. Dejo para el momento de su publicación un estudio más detallado del régimen que se propondrá aplicar a las transferencias internacionales en estos dictámenes y en el futuro Reglamento de la Unión Europea. Ahora me centraré en un supuesto que debería permitir eludir la figura de la transferencia internacional.

En el artículo dedicado a la subcontratación en el cloud computing analicé las condiciones en las que las empresas proveedoras de servicios en la nube gestionan el alojamiento de los datos y mencioné la posibilidad del cifrado, la disociación y la fragmentación de los datos entre distintos proveedores y países. respecto al cifrado, podemos encontrar un ejemplo específico para cloud computing en http://www.cipherdocs.com

Pero más allá del cifrado y la disociación existe la posibilidad de establecer en el contrato de cloud computing una serie de obligaciones, que algunos proveedores ya ofrecen como función por defecto u opcional:
1. El proveedor debe utilizar un sistema de ficheros distribuidos diseñado para alojar grandes cantidades de datos y un amplio número de servidores.
2. Los datos deben estar estructurados y almacenados en una base de datos construida en el nivel superior del sistema de ficheros.
3. Los datos deben ser fragmentados y replicados en múltiples servidores.
4. Los fragmentos o “chunks” deben tener nombres generados de forma automática y aleatoria.
5. Los fragmentos de datos no deben ser almacenados en texto claro sino en un formato ininteligible para el ser humano.
La AEPD se ha pronunciado en diversos foros sobre la transferencia internacional de datos en el cloud computing y ha mencionado dos puntos interesantes:
1. La disociación de datos debe ser irreversible, y ello no es posible en el cloud computing.
2. Por cuestiones de seguridad nacional las normas de ciertos países permiten a las autoridades requerir el acceso a los datos almacenados en servidores que se encuentren en su territorio.
Respecto a ello cabe decir que:
1. Debe tenerse en cuenta que la relación tiene tres partes: el cliente, el proveedor y las empresas de hosting distribuido.
2. Las empresas de hosting no alojan datos completos disociados, sino fragmentos ininteligibles de datos.
3. La irreversibilidad estaría garantizada por el proveedor en los países donde sólo se almacenen fragmentos cifrados de los datos.
4. La información sólo sería accesible de forma inteligible desde España.
5. Un requerimiento de acceso a datos a los proveedores de hosting sería inútil, ya que ninguno de ellos tendría datos completos e inteligibles.
En resumen, en el sistema descrito sólo hay acceso a datos personales en España. Los restantes países no alojan datos personales.
Como dije en mi anterior artículo, ello hace que el elemento débil de la cadena sean los puntos de acceso y la gestión de las contraseñas de los usuarios.
Este riesgo puede limitarse utilizando:
1. La doble autenticación que ofrecen algunos proveedores de cloud computing.
2. Certificados electrónicos que reproduzcan la jerarquía de privilegios de acceso de la empresa.
3. Limitación de acceso a un rango de direcciones IP de la empresa.
4. Limitación de acceso a los dispositivos de la empresa.
Sirvan estas notas como avance del análisis más profundo que precisará esta cuestión cuando se publiquen los dos documentos reseñados al principio de este artículo.

La subcontratación en el cloud computing

Uno de los principales problemas que encuentran las empresas españolas al intentar firmar contratos de cloud computing con empresas extranjeras, generalmente norteamericanas, está asociado a la estricta normativa que en materia de protección de datos personales rige en Europa.

Sin embargo, las empresas están encontrando soluciones que consisten en pactar con el proveedor de cloud computing unas medidas que tengan un efecto equivalente a las exigidas en la ley. La Agencia Española de Protección de Datos (AEPD) se ha pronunciado recientemente a favor de escapar de una interpretación literal de la Ley Orgánica de Protección de Datos (LOPD) y de su Reglamento (RLOPD), para buscar soluciones alternativas que se adapten a las peculiaridades del cloud computing y permitan garantizar la protección de los derechos de los afectados.

En este artículo analizaremos los puntos en los que se han producido ciertos avances.

1. Ubicación de los datos

Hoy en día el almacenamiento de datos ha sufrido una importante reducción de costes, debido principalmente a la caída del precio de los soportes informáticos. Ello ha generado una sana competencia entre los principales proveedores de servicios de hosting.

El crecimiento y la optimización de las redes y de los protocolos de comunicación y de compresión de datos también han influido en la existencia de una oferta económica y global.

La libre competencia en el mercado internacional y la amplitud de la oferta permite a las empresas de cloud computing escoger los proveedores de hosting que más les convienen en calidad y precio, pudiendo éstos encontrarse en cualquier país y latitud. Últimamente parece que están emergiendo las latitudes frías, donde el coste de refrigeración de los servidores es muy reducido.

Todo ello contribuye a que los datos gestionados por el proveedor de cloud computing puedan tener múltiples ubicaciones a lo largo de la vigencia del contrato. Si las oscilaciones en los precios del hosting son importantes, el proveedor de cloud computing podría cambiar la ubicación de los datos con una mayor frecuencia.

Todo ello tiene ventajas y desventajas. Un ventaja se produciría en materia de seguridad, ya que los posibles interesados en conseguir un acceso ilegal a los datos no podrían saber dónde se encuentran éstos en cada momento.

Un desventaja clara sería que, legalmente, la empresa cliente estaría obligada a saber dónde se encuentran los datos personales de sus clientes y trabajadores, para poder comprobar si se hallan en un país que ofrece una protección equivalente a la Unión Europea o que tiene un convenio de Puerto Seguro como Estados Unidos.

En caso de ser así, la empresa cliente debería solicitar una autorización al Director de la AEDP, al tratarse dicho hosting de una transferencia internacional de datos a un país sin protección equivalente a la de la UE. Durante el ejercio 2011 el Director de la AEPD autorizó 735 transferencias a estos países. De ellas, el 84,2% correspondió a transferencias de datos a encargados del tratamiento, es decir, a empresas de outsourcing, cloud computing, call centers externalizados y otros servicios con tratamiento de datos personales.

Avances

1. Desde un punto de vista legislativo, el avance que se está produciendo en esta materia es que el legislador está reconociendo el carácter global de las redes de telecomunicaciones y la necesidad de bajar el listón en relación a los requisitos exigidos para las transferencias internacionales de datos.

Pensemos que hay supuestos en que los es imposible cumplir estos requisitos. Por ejemplo, los sistemas de enrutamiento analizan en tiempo real los tiempos de salida y llegada de los paquetes IP y que, en cualquier momento pueden dirigir el tráfico a través de nodos situados en países sin protección equivalente. Aunque sería un tránsito efímero, la caché del router puede conservar esos datos durante un tiempo indeterminado.

2. Desde un punto de vista técnico, algunos proveedores de cloud computing están recurriendo a sistemas de informática distribuida en el que cada servidor tiene fragmentos o chunks tipo P2P. Ello hace que las cadenas de datos estén truncadas, y que sea imposible recuperar información útil desde un solo servidor.

Valorado jurídicamente, este sistema es mucho más potente que la disociación o la anonimización de los datos, ya que la dispersión de datos fragmentados en diferentes países permitiría eludir la figura de la transferencia internacional de datos.

En el caso de la disociación, los datos no podrían ser relacionados con las personas a las que van referidos, pero seguirían siendo datos inteligibles, con información suficiente, en algunos casos, para asociarlos a los afectados. En la fragmentación no existiría este riesgo, ya que cada fragmento incluiría datos ininteligibles.

Además, en la disociación, el tratamiento se realiza normalmente en bloque, y el proveedor tiene acceso inteligente a todos los datos. En cambio, en la fragmentación, el proveedor sólo tiene un acceso no inteligente a una parte de la base de datos. Es un acceso no inteligente porque se trata de un mero almacenamiento de bits no inteligibles y porque el proveedor no realizará ningún esfuerzo intelectual para tratar los datos.

2. Selección e identificación de las empresas subcontratadas

La LOPD y su Reglamento establecen requisitos muy claros y exigentes en relación a la cadena de custodia y tratamiento de datos personales por parte de un proveedor que subcontrate los servicios de otras empresas. Estos requistos, detallados en el artículo 21,2 del RLOPD y en la Sentencia del Tribunal Supremo de 15 de julio de 2010, son los siguientes:

  1. En el contrato con el proveedor se deben detallar los servicios que van a ser objeto de subcontratación.
  2. También deben quedar identificadas las empresas subcontratadas.
  3. El cliente debe autorizar cada una de las subcontrataciones.
  4. Debe existir un contrato entre el proveedor y las empresas subcontratistas que incluya las mismas garantías y obligaciones del contrato principal.

Avances

1. Desde un punto de vista jurídico, la propia AEPD ha reconocido en diversas ponencias que las características particulares de los contratos de cloud computing impiden aplicar literalmente los requisitos de la subcontratación.

Por un lado, el proveedor de cloud computing presenta, en la mayoría de los casos, una oferta prediseñada con unas aplicaciones estándar. En función del tipo de servicio de cloud computing contratado habrá un distinto nivel de implicación del usuario y por lo tanto, el nivel de personalización del servicio y del contrato será también distinto. Tengamos en cuenta que estos servicios se regulan normalmente en un contrato de adhesión, y que el proveedor va a resistirse a cambiar sus cláusulas, dada la necesidad de disponer de un régimen uniforme para todos los clientes y para todos los países.

Por otra parte, el proceso de selección de las empresas que el proveedor de cloud computing contrata está basado en las oscilaciones de la oferta de servicios como el almacenamiento de datos, y por lo tanto esta sujeto a una evolución constante. Ello impide establecer una lista permanente de empresas subcontratadas como anexo al contrato. La AEPD en este sentido recomienda una remisión a una lista dinámica ubicada en el sitio web del proveedor, que vaya siendo actualizada constantemente.

2. Desde un punto de vista técnico debemos tener en cuenta varios puntos importantes. Las empresas de cloud computing se están convirtiendo en proveedores críticos de las empresas. Las empresas que administran infraestructuras críticas tienen que recurrir a medidas de ocultación como primera barrera de seguridad frente a ataques. Un ejemplo sería no dar a conocer la ubicación de sus CPD o pixelar las fotografías aéreas de sus instalaciones en Google Maps y otros servicios similares. De la misma manera sería interesante no desvelar la identidad del proveedor de cloud computing cuando éste administra recursos críticos.

En la tarea de crear esas primera barreras a un eventual ataque, la propuesta de relacionar a las empresas subcontratadas en el sitio web del proveedor de cloud computing no parece recomendable, salvo que ésta se encuentre en una zona privada a la que sólo el cliente tenga acceso.

Pensemos que, en materia de seguridad, una cadena es tan fuerte como el más débil de sus eslabones, y es inútil que una empresa concentre todos los recursos posibles en la protección de sus activos intangibles y de los datos personales de sus clientes si después externaliza parte de su gestión a un proveedor que no realiza los mismos esfuerzos, o genera una cadena de subcontrataciones que van diluyendo, en cada nuevo nivel de subcontratación, el control sobre dichos activos. También hay que reconocer que el proveedor, como responsable frente a muchos clientes, puede haber invertido más en seguridad que el propio cliente, pero no podemos dejar de tener en cuenta la teoría del riesgo moral, que demuestra que nadie protege con tanto esmero sus activos como su propietario. Además, si miramos la casuística de los ataques, filtraciones, siniestros y descuidos en materia de seguridad que se han llegado a los medios de comunicación, veremos un incremento en la implicación de los proveedores en estos incidentes y una clara migración de estos ataques hacia ellos.

Estos factores de riesgo hacen aconsejable una labor de control sobre el proveedor de cloud computing y de éste sobre sus subcontratistas. El fenómeno de la externalización está haciendo que nuestros proveedores y sus subcontratistas se conviertan en gestores de nuestros activos intangibles y de nuestra reputación corporativa, por lo que no debe ser raro aplicar fórmulas de auditoría y control similares a las funciones de auditoría y control internos. Alguna empresas consideran suficiente solicitar el informe SAS70, pero en el caso del cloud computing sería necesario ampliar el alcance del control.

Otro factor importante a tener en cuenta es la virtualización. ¿Hasta qué punto podemos seguir hablando de hosting en entornos virtualizados gestionados directamente por el cliente? La fórmula se asemeja más a un housing virtual que a un hosting. Una máquina virtual es, como dice la palabra, una máquina, una unidad a la que el propietario del servidor físico no tiene acceso inteligente.

Si a ello unimos el proceso de cifrado y fragmentación de los datos, no debería seguir considerándose encargados o subencargados del tratamiento a los subcontratistas que simplemente dan alojamiento a una máquina virtual llena de datos ininteligibles. Aunque la LOPD incluye la simple conservación de datos personales en la definición de tratamiento, deberíamos preguntarnos si un paquete fragmentado de una gran base de datos puede seguir siendo considerado como un contenedor de datos personales, y si el simple almacenamiento de ese paquete fragmentado en una máquina virtual sin acceso inteligente del propietario del servidor es realmente una tratamiento de datos personales.

Publicado en e-Penteo – Número 11 – Abril 2012