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:
- En el contrato con el proveedor se deben detallar los servicios que van a ser objeto de subcontratación.
- También deben quedar identificadas las empresas subcontratadas.
- El cliente debe autorizar cada una de las subcontrataciones.
- 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
