¿Qué proveedor de servicios en la nube es el más adecuado? Parte I

La Autoridad de Protección de Datos Danesa (Datatilsynet) publicó la semana pasada una guía que busca ayudar a responsables y encargados a elegir qué proveedor de servicios en la nube es el más adecuado para su línea de negocio desde el punto de vista de la protección de datos.

Ya la Agencia Española de Protección de Datos hizo los deberes en 2018 con la publicación de una guía sobre Cloud Computing (de la que ya hablamos en nuestro Blog) en la que nos daban una serie de pautas generales con información práctica dirigida a pymes y profesionales, si bien el enfoque de la autoridad de control la danesa se centra específicamente en el ámbito de las transferencias internacionales de datos.

¿Qué es la computación en nube?

Aunque no existe una definición general, tanto la autoridad española como la danesa procuran una aproximación, entendiéndolo como el conjunto de recursos informáticos configurables, escalables y accesibles a través de internet. A modo de curiosidad, el término nube trae su origen en las representaciones de los mapas de red que se realizaban hace 40 años cuando se quería hacer referencia a un acervo de elementos comunicados entre sí.

TIPOS DE CLOUD COMPUTING

De entre las muchas clasificaciones que pueden realizarse sobre el entorno cloud, la guía se centra en los modelos de servicio y de nube.

Modelos de servicio

  • Infraestructura como servicio (IaaS). El proveedor de servicios se limita a proporcionar al cliente la infraestructura física, de modo que este último es quien facilita el software y las aplicaciones. Es el modelo más primitivo de los tres, si bien es en el que el cliente tiene más margen de control, pues además de la responsabilidad sobre la capa lógica, puede elegir el almacenamiento, los componentes en red, las medidas de seguridad…
  • Plataforma como servicio (PaaS). En este caso el proveedor de servicios suele ofrecer, además de la infraestructura, el sistema operativo, algoritmos para el análisis del Big Data o APIs, por lo que la responsabilidad del cliente se limita a las aplicaciones implementadas, aunque hay casos en los que sí podría llegar a tener capacidad, y, por ende, responsabilidad, en la configuración del entorno.
  • Software como servicio (SaaS). Es el modelo más cercano a nivel usuario (Un ejemplo de ello sería el correo electrónico que utilizamos). Aquí el proveedor es el que nos suministra todo lo necesario para desarrollar nuestra actividad, por lo que el cliente sólo tiene posibilidad de configurar la aplicación dentro de los parámetros establecidos por cada proveedor. En este caso es importante valorar si realmente esta clase de servicio va a ser compatible con el resto de entornos con los que trabajamos.

Modelos de nube

  • Nube pública. Es el más habitual y estandarizado de los cuatro, aunque también es el que suele ofrecer más flexibilidad de servicios. En estos casos, el proveedor ofrece a entidades sin relación entre sí un conjunto de recursos compartidos, determinando los términos y condiciones de uso.
  • Nube privada. Al contrario de la anterior, los recursos son de exclusivo de una organización. En estos casos, debemos considerar quién lo va a gestionar; si la propia entidad/es, un tercero (si se establece fuera de la instalación, lo más probable es que sea administrado por el mismo que lo oferta) o la combinación de ambos. En los últimos dos supuestos, se debería detallar en el contrato de encargado de tratamiento las funciones y límites de los actores.
  • Nube compartida. Los recursos son de uso exclusivo para un conjunto de organizaciones o entidades independientes. Son estructuras complejas en las que se debe definir el gobierno de la infraestructura y de los datos (quién y cómo va a llevar la administración, capacidad de uso de las organizaciones, responsabilidades del procesamiento de los datos…)
  • Nube híbrida. Son aquellos que combinan los modelos anteriores, si bien cabe la posibilidad de que estén conectados entre sí, lo que permite la interoperabilidad de los datos y aplicaciones.

Una práctica habitual en este sentido, sobre todo en aquellos clientes que cuentan con cierto volumen de negocio, es la contratación de diferentes proveedores de servicio para la entidad (los llamados entornos multicloud) porque, aunque se incrementa el grado de dificultad en la gestión del modelo de gobernanza de los datos, se reducen las posibilidades de que un fallo afecte a la totalidad de las operaciones.

ELEMENTOS A TENER EN CUENTA ANTES DE CONTRATAR SERVICIOS EN LA NUBE

Repasados los modelos, la guía concreta qué pasos tendremos que realizar nosotros como responsables, así como los aspectos que debemos tener en cuenta antes de contratar con uno o varios proveedores, si bien no debemos olvidar que se trata de un esquema general, por lo que habría que analizar caso por caso.

  • Una descripción completa de las actividades de tratamiento, especificando la base de legitimación de cada una de ellas, la tipología de los datos, los flujos de los datos dentro y fuera de la entidad y los riesgos inherentes.
  1. Diseño del contrato de encargado de tratamiento, prestando especial atención al apartado de subencargados.  Con relación a esto, y tal y como hace referencia la autoridad danesa a lo largo de la guía, en la mayoría de los casos lo que se ofertan son contratos de adhesión cerrados por el proveedor de servicios Cloud, en donde el margen de maniobra del cliente es escaso o nulo (p.ej.: piénsese en una pyme frente a un gran proveedor). En este sentido es importante recordar que, a pesar de la situación de desequilibrio existente, el responsable no queda eximido de cumplir con lo dispuesto en el artículo 28.1 del Reglamento (UE) 2016/679 Europeo de Protección de Datos, en donde se le compele a elegir exclusivamente a aquel encargado “que ofrezca garantías suficientes para aplicar las medidas técnicas y organizativas apropiadas” con el fin de cumplir con lo establecido en la normativa, así como “garantizar el derecho de los interesados”.
  • Análisis de riesgos y/o evaluación de impacto, partiendo de:
  • Identificación de las transferencias a terceros países. Aquí debemos hacer un inciso para recalcar que, si debido a nuestra actividad de negocio vamos a necesitar ubicar los datos (tanto en tránsito como en reposo), fuera del Espacio Económico Europeo o en terceros países sin Decisión de Adecuación por parte de la Comisión Europea, deberemos estudiar la legislación de forma más pormenorizada, haciendo especial hincapié en las cuestiones relativas a seguridad nacional que nos apliquen.
  • Identificar o establecer la herramienta de transferencia del Capítulo V del RGPD  y evaluar si es eficaz (si se basan en Cláusulas Contractuales Tipo (SCC), puede encontrar más información aquí).
  • Reevaluar las transferencias periódicamente con el fin de observar si las medidas implantadas son las pertinentes o, por el contrario, es necesario realizar modificaciones.
  • Descripción del nivel de seguridad y de las medidas implementadas (p.ej. técnicas robustas de cifrado) por todos los responsables y encargados afectados por el tratamiento.
  • Documentar todo el proceso.

Dentro de las transferencias internacionales mencionadas con anterioridad, podemos encontrarnos en alguno de estos tres escenarios:

  • Iniciar o continuar la transferencia sin aplicar mayores medidas si se considera de forma demostrada y documentada que no tiene motivos para creer que la legislación extranjera no garantiza un nivel de protección esencialmente equivalente al garantizado en la UE/EEE.
  • Aplicar medidas complementarias para garantizar dicho nivel. A tal efecto, el EDPB ha publicado un conjunto de recomendaciones que detallan cómo evaluar el nivel de protección de datos en un tercer país y qué medidas complementarias puede adoptar.
  • Abstenerse de iniciar la transferencia o suspenderla, si está en curso, lo que implicaría descartar o dejar de usar ese proveedor.

En definitiva, la principal conclusión que podemos extraer de lo manifestado hasta aquí es que el estudio de la legislación del país de tránsito o destino es vital, tanto para el proceso de análisis y elección de proveedores, como para el propio ciclo de vida del tratamiento.

En el próximo artículo desgranaremos qué preguntas deberíamos hacernos a la hora de elegir el proveedor de servicios más adecuado.