Cloud compliance report_csa-es_v.1.0

Iniciat iva coordinada y patrocinada por:

Cloud Compliance Report

CAPÍTULO ESPAÑOL DE CLOUD SECURITY ALLIANCE

Versión 1 - mayo 2011

Título:Cloud Compliance Report

Copyright y derechos:CSA- ES (Cloud Security Alliance- España) - ISMS Forum Spain.

Todos los derechos de esta Obra están reservados a CSA-ES (Cloud Security Alliance-España) y a ISMS Forum Spain. Los titulares reconocen el derecho a utilizar la Obra en el ámbito de la propia actividad profesional con las siguientes condiciones:

a) Que se reconozca la propiedad de la Obra indicando expresamente los titulares del Copyright.

b) No se utilice con fines comerciales.

c) No se creen obras derivadas por alteración, trasformación y/o desarrollo de esta Obra.

- Los titulares del Copyright no garantizan que la Obra esté ausente de errores. En los límites de lo posible se procederá a corregir en las ediciones sucesivas los errores señalados.

- El contenido de la Obra no constituye un asesoramiento de tipo profesional y/o legal.

- No se garantiza que el contenido de la Obra sea completo, preciso y/o actualizado.

- Eventuales denominaciones de productos y/o empresas y/o marcas y/o signos distintivos citados en la Obra son de propiedad exclusiva de los titulares correspondientes.

Más información acerca de CSA-ES se puede consultar a través de su página oficial:

www.cloudsecurityalliance.es

www.ismsforum.es/csa

www.cloudsecurityalliance.org

Sobre CSA-ES:Con 91 miembros fundadores, representativos de los distintos actores de la industria del Cloud Computing en España, nació en mayo de 2010 el capítulo Español de Cloud Security Alliance: CSA-ES, impulsado por ISMS Forum Spain y Barcelona Digital. CSA es la organización internacional de referencia en la que exper-tos de algo nivel debaten y promueven el uso de mejores prácticas para garantizar la seguridad y privacidad en el entorno del Cloud Computing. Por su parte, el capítulo español ya cuenta con 200 miembros, siendo su ámbito de interés el “Compliance en la Nube”. En este sentido existen tres grupos de trabajo específicos, como son: Privacidad y Cumplimiento Normativo en la Nube; Sistemas de Gestión de Seguridad de la Información, y Gestión de Riesgos en la Nube; y Contratación, Evidencias Electrónicas y Auditoría en la Nube. Los profesionales que conforman estos grupos han trabajado en este primer Report español en materia de Cloud Compliance.

La estructura de CSA-ES consta de:

Junta Directiva

Nombre Cargo, empresa Cargo en la Junta Directiva de CSA-ES

Luis Buezo Bueno Director EMEA IT Assurance, HP Technology Services Presidente - Comité Operativo

Jesús Milán Lobo Director de Riesgos Tecnológicos y Seguridad Informática de Bankinter

Vicepresidente - Comité Operativo

Jesús Luna García Investigador, Technische Universität Darmstadt (Alemania) Vocal - Comité Operativo

Casimiro Juanes Director Regional de Seguridad RMED de Ericsson Vocal - Comité Operativo

Nathaly Rey Directora General de ISMS Forum Spain Vocal - Comité Operativo

Gianluca D´Antonio Chief Information Security Officer (CISO) del Grupo FCC Vocal

Elena Maestre Socio de Riesgos Tecnológicos de PricewaterhouseCoopers Auditores S.L. Vocal

Ramón Miralles López

Coordinador de Auditoria y Seguridad de la Información de la Autoridad Catalana de Protección de Datos Vocal

Carlos Alberto Sáiz Peña

Socio responsable del Área de GRC Governance, Risk y Compliance de Ecija Vocal

Víctor A. Villagrá Profesor Titular de Universidad. Dpto. Ingeniería Telemática en la E.T.S.I. Telecomunicación de la Universidad Politécnica de Madrid (UPM) Vocal

Los líderes de los Grupos de Trabajo

Nombre Cargo, empresa Grupo de Trabajo

Miguel Ángel Ballesteros Bastellesteros Auditor en CEPSA Privacidad y Cumplimiento Normativo en la Nube

Antonio Ramos Managing Partner en n+1 Intelligence & Research

Sistemas de Gestión de Seguridad de la Información, y Gestión de Riesgos en la Nube

María Luisa Rodríguez Security R&D Business Manager en Barcelona, Digital Centre Tecnològic

Contratación, Evidencias Electrónicas y Auditoria en la Nube

Consejo Asesor

Nombre Cargo, empresa

Pau Contreras Director de Innovación y Desarrollo de Negocio de Oracle Ibérica

Antoni Felguera R+D Security Manager de Barcelona Digital Technology Centre

Marcos Gómez Hidalgo Subdirector de Programas de INTECO

Olof Sandstrom Director General de Operaciones de Arsys

Cloud Compliance Report Capítulo Español de Cloud Security Alliance

i 50. Índice 5

1. Resumen ejecutivo 9

2. Introducción y justificación del estudio 12

3. Contenido del documento 14

4. Cumplimiento legislativo en materia de Privacidad 18

4.1 Introducción 18

4.2 Contenido del capítulo 21

4.3 Legislación aplicable 23

4.4 Encargado de tratamiento 25

4.5 Medidas de seguridad 32

4.6 Transferencias Internacionales 36

4.7 Ejercicio de derechos 42

4.8 Autoridades de control 46

4.9 Comunicación de datos a otras autoridades 51

4.10 Conclusiones 54

5. Cumplimiento con otras legislaciones 58



5.3 Anteproyecto de Ley de modificación de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones 59

5.4 Ley 11/2007, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos 60

5.5 Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y Comercio Electrónico 60

5.6 Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal 62

5.7 Aspectos Jurídicos Laborales 67

Índice


0. Índice 6

6. Sistemas de Gestión de la Seguridad de la Información en la nube 70



6.3 Principios generales de despliegue de un SGSI 71

6.4 Fase I. Definición y preparación del SGSI 72

6.5 Fase II. Implantación y operación del SGSI 81

6.6 Fase III. Seguimiento y mejora del SGSI 83

6.7 Conclusiones 85

7. Efectos de la computación en la nube sobre la contratación de servicios TIC 88


7.2 Contenido 90

7.3 Mecanismos de resolución de conflictos 91

7.4 Confidencialidad 91

7.5 Propiedad Intelectual 92

7.6 Responsabilidad 93

7.7 Resolución anticipada 93

7.8 Privacidad y protección de datos 94

7.9 Ley aplicable y jurisdicción 96

7.10 Auditabilidad 97

7.11 Seguridad 99

7.12 Acuerdos de Nivel de Servicio (ANS) 101

7.13 Recomendaciones 102

8. La obtención de evidencias digitales en la nube 105



8.3 La problemática 106

8.4 Las “amenazas principales” y la prueba electrónica 108



i 70. Índice 7

9. Auditoría de entornos de computación en la nube 113



9.3 Metodologías y tecnologías de auditoría. 115


10. Glosario 120

11. Referencias 123

12. Anexos 125

Anexo I. Amenazas asociadas a tecnologías específicas 125

Anexo II. Amenazas 127

Anexo III. La prueba electrónica en el marco legal Español 133

Anexo IV. Metodologías y tecnologías de auditoría 138



El cumplimiento normativo es uno de los aspectos mencionados ineludiblemente por cualquier estudio rela-tivo a la implantación de modelos de computación en la nube. Esta circunstancia, unida al hecho de que la regulación española sobre la privacidad es modélica a nivel mundial, ha hecho que el capítulo español de la Cloud Security Alliance se haya decidido a abordar este ‘Cloud Compliance Report’.

Pero el enfoque del cumplimiento normativo se ha abordado de una manera amplia, no limitado a los aspectos sobre la privacidad, sino que incluye también otras normas exigibles en España, así como, nor-mativas de carácter voluntario, como la ISO/IEC 27001:2005 sobre Sistemas de Gestión de la Seguridad de la Información (SGSI) o un análisis de los aspectos relacionados con la contratación como pieza funda-mental de la relación entre cliente y proveedor de servicios en la nube.

Además de incluir todo este tipo de normas, el estudio ha ido un poco más allá e incluye también lo rela-cionado con la validación del cumplimiento, es decir, analiza la realización de auditorías y la obtención de evidencias digitales en entornos de computación en la nube.

Finalmente, resaltar que el estudio ha tomado en consideración tanto el punto de vista del cliente como del proveedor de servicios para lo que ha sido fundamental que sus autores conformaran un grupo multidis-ciplinar y representativo de ambas perspectivas. En aquellos puntos donde es relevante, también existen reflexiones y recomendaciones por tipo de servicio (SaaS, PaaS o IaaS) y por tipo de despliegue (nube privada, pública, híbirida…).

Uno de los principales objetivos del presente documento es aportar un enfoque metodológico que ayude a abordar las necesidades de cumplimiento dentro de la computación en la nube. Está claro que no pode-mos ver sólo los beneficios del computación en la nube y obviar sus implicaciones y riesgos, en especial, todo lo relacionado con el cumplimiento. Por otro lado, tampoco podemos recurrir sistemáticamente a argumentos de seguridad y cumplimiento para paralizar las iniciativas en la nube. Todo es cuestión de balancear, identificando qué servicios, cómo y cuándo se pueden ir implementando de manera adecuada en los diferentes modelos de computación en la nube. La evolución hacia la nube será gradual y clara-mente los requerimientos de cumplimiento serán uno de los principales parámetros que irán marcando la velocidad de esta evolución.

En cuanto a las conclusiones más relevantes de este estudio, aunque son difíciles de resumir en tan poco espacio, sí que es interesante resaltar que tienen un mismo hilo conductor: Aumentar la transparencia en la relación entre cliente y proveedor de servicios de computación en la nube como elemento básico de confianza entre las partes (en este sentido, por ejemplo, contar con un proveedor certificado es un factor muy positivo). Estas recomendaciones, en gran medida, también podrían ser de aplicación a los modelos más tradicionales de externalización de servicios (como el housing o el hosting), lo cual es lógico, puesto

Resumen ejecutivo



que la computación en la nube podría considerarse como un salto cualitativo en los modelos de provisión de servicios TIC.

De este modo, nos encontramos con recomendaciones como la de que los clientes informen a los provee-dores sobre los tratamientos de datos de carácter personal que están realizando y los requisitos que sobre ellos existen y que éstos, a su vez, identifiquen e informen de las localizaciones en las que realizarán dichos tratamientos o de proveedores a los que ellos subcontraten parte de sus servicios, así como, que se establezcan mecanismos de coordinación entre ambas partes para asegurar que se puede dar cumplimien-to a los derechos de los afectados de manera responsable.

En cuanto a la implantación de SGSIs, también nos encontramos recomendaciones en sentido de ampliar los canales de comunicación en materia, por ejemplo, de valoración de riesgos, de incidencias, de va-riación de los niveles de riesgo, así como de coordinación (como, por ejemplo, en materia de definición de roles y responsabilidades, respuesta a incidentes o realización de tareas de seguimiento y auditoría), mecanismos éstos especialmente relevantes en el caso de SGSIs “encapsulados”. En este punto, se incluye una reflexión especial en relación a los alcances, en el sentido de que deben ser significativos para los servicios prestados en la nube.

En relación a la contratación de servicios en la nube, las recomendaciones también tienen la misma orien-tación, encontrándonos con referencias a los Acuerdos de Nivel de Servicio como herramientas funda-mentales para definir y monitorizar el servicio, pero también con aspectos como determinar la propiedad intelectual de los distintos elementos de la provisión del servicio, establecer mecanismos de resolución de conflictos o clarificar desde el inicio las leyes aplicables y la jurisdicción aplicable.

Para finalizar, en cuanto a los aspectos relacionados con la validación del cumplimiento (evidencias y au-ditoría), las recomendaciones hacen foco en los aspectos de coordinación (quién debe encargarse de qué tarea en aspectos como elaboración de métricas, realización de revisiones, etc.), así como en el estableci-miento de un entorno confiable mediante la implantación de mecanismos como procedimientos de gestión de evidencias, medidas de protección de los registros de auditoría, planificación de auditorías, etc.


2. Introducción y justificación del estudio 12

El pasado 21 de Mayo de 2010, ISMS Forum Spain y Barcelona Digital, centro tecnológico de I+D+i es-pecializado en seguridad, conjuntamente con la Cloud Security Alliance (CSA), anunciaron la creación del capítulo español del CSA. Como es ya conocido, CSA es la organización internacional de referencia en la que expertos de alto nivel debaten y promueven el uso de mejores prácticas para garantizar la seguridad y privacidad en el entorno de computación en la nube.

El capítulo español, que se denomina CSA-ES, lo constituyeron inicialmente 91 miembros. Se trató del primer capítulo de ámbito nacional del CSA y se fundó con la misión de avanzar en el desarrollo seguro de la tecnología cloud computing (computación en la nube) en España, constituyendo un foro de discusión y aglutinamiento de los profesionales de seguridad en éste ámbito de trabajo. Los principales objetivos de CSA-ES son promover un nivel de entendimiento entre consumidores y proveedores de cloud, potenciar el desarrollo de guías y buenas prácticas independientes, así como lanzar campañas de concienciación y sensibilización sobre el uso adecuado y seguro de la nube.

Cada capítulo regional selecciona un ámbito específico de interés en relación con la computación en la nube. El hecho de que la regulación española sobre la privacidad es modélica a nivel mundial, ha justificado que el CSA-ES seleccionara el área de “Compliance en la Nube”, marcándose como objetivo desarrollar el presente documento, según ratificó la Junta Directiva, una vez que la misma fue constituida.

Desde la fundación de CSA-ES, se constituyeron 3 grupos de trabajo enfocados a trabajar en paralelo para el desarrollo del presente documento en las siguientes áreas:

• Grupo de Trabajo 1: Privacidad y cumplimiento normativo

• Grupo de Trabajo 2: Sistemas de gestión de seguridad de la información y gestión de riesgos

• Grupo de Trabajo 3: Contratación, evidencias electrónicas y auditoría..

CSA-ES está convencido de que este ‘Cloud Compliance Report’, sin duda alguna, aportará un gran valor a la industria en virtud de que precisamente el cumplimento normativo es una de las barreras a la hora de implantar el modelo de computación en la nube en muchas organizaciones, máxime teniendo en cuenta las rigurosas obligaciones de seguridad que vienen impuestas por la normativa de protección de datos de carácter personal, y la carencia de un nivel de entendimiento con reguladores y autoridades de control.

El objetivo del Capítulo es partir de una base general robusta en materia de cumplimiento, para después, ir trabajando por sectores de interés (banca, salud, seguros, telecomunicaciones, etc.).

Introducción y justificación del estudio



Para abordar el estudio del cumplimiento en la nube, el capítulo español de la Cloud Security Alliance dividió el tema considerando que el cumplimiento tiene dos estadios. En primer lugar, el inventariado. En este primer momento, lo que afrontamos es la identificación de las normas que son de aplicación a la Or-ganización. Dentro de estas, podríamos clasificar las normas de aplicación a cualquier organización en:

• Normas generales, que a su vez, podrían ser obligatorias (ordenamiento jurídico de los Estados normalmente) o voluntarias (códigos tipo o mejores prácticas).

• Normas particulares, es decir, aquellas que aplican con carácter individual por aceptar los términos de un contrato o normas sectoriales.

Una vez superado este estadio enunciativo, vendría la etapa de validar el cumplimiento. Este cumplimiento se apoya en dos grandes ejes. Por un lado, las evidencias digitales que permiten demostrar hechos en los entornos telemáticos y que son de especial relevancia en la nube y, como no, la auditoría, como herra-mienta (que se apoya en múltiples ocasiones en evidencias digitales) para validar que una determinada organización, sistema o servicio “cumplen” con lo requerido por alguna de las normativas mencionadas anteriormente.

Esta estructuración de contenidos se concentró generando tres grupos de trabajo:

• El primer grupo de trabajo se centró en las normas generales y los resultados se encuentran en los capítulos 4 y 5. Se ha decidido tratar la privacidad en un capítulo propio, dada su especial relevancia en el contexto de la computación en la nube, y la importancia de la normativa de protección de datos de carácter personal, especialmente en el contexto Europeo.

• El segundo grupo de trabajo se dedicó a las normas voluntarias, más concretamente, se concen-tró en los Sistemas de Gestión de la Seguridad de la Información en base a la norma ISO/IEC 27001:2005 dada su importancia a nivel mundial y mejor práctica generalmente aceptada y cuyo análisis se encuentra en el Capítulo 6.

• Finalmente, el tercer grupo se dedicó a los aspectos restantes. A la contratación, como meca-nismo en el que se establecen los requisitos entre las partes (Capítulo 7) y, por otro lado, en lo relacionado con la verificación del cumplimiento, que se traduce en dos capítulos independien-tes: las evidencias digitales (Capítulo 8) y la auditoría (Capítulo 9).

Contenido del documento



La estructura resultante es la que puede apreciarse en el gráfico adjunto (Ilustración 1).

Por otra parte, aunque los aspectos cubiertos por este documento son algunos muy diferentes, se ha pro-curado mantener una misma estructura en todos los capítulos de forma que sea fácil para el lector seguir la argumentación a lo largo de todo el estudio pero que también puedan ser consultados de manera indi-vidual sin que sea necesario leer todo el informe para sacar provecho de su lectura. De esta forma, todos los capítulos tienen los siguientes apartados:

• Una introducción inicial que ayuda a centrar el tema en cuestión, explica por qué se aborda y su relación con la computación en la nube.

• Un apartado que explica el contenido del capítulo de manera específica para que el lector sepa dónde puede encontrar determinados aspectos que le interesen en mayor medida.

ComplianceReport

8. Evidenciasdigitales

Normas

Validación

Generales

Obligatorias

4. Privacidad

5. Otras

6. SGSIVoluntarias

ContrataciónParticulares

9. Auditoría

Ilustración 1. Organización del contenido del documento


• Finalmente, tras el desarrollo de cada aspecto se incluye un apartado final de conclusiones o recomendaciones a modo de compendio final de los aspectos más relevantes del capítulo. No obstante, durante el desarrollo de cada parte del documento se van realizando recomendacio-nes relativas a la materia en estudio en cada momento, por lo que es importante, si el lector está interesado en algún tema concreto que lea el capítulo completo para obtener un mayor grado de detalle.


Ilustración 2. Estructura de los capítulos

Introducción

Estructuracapítulos Contenido

Conclusiones / Recomendaciones

Desarrollo



4.1 Introducción

Actualmente existen diversas definiciones y características de computación en la nube, por lo que no es fácil dar una definición clara a lo que podríamos describir como un modelo para la prestación de servicios y recursos (redes, servidores, capacidad de almacenamiento, aplicaciones y servicios) bajo demanda a través de la red, caracterizado por su adaptabilidad, flexibilidad, escalabilidad, rapidez, optimización y eficiencia.

Estos componentes pueden orquestarse, abastecerse, implementarse y desmantelarse rápidamente y esca-larse en función de las dimensiones necesarias para ofrecer los servicios solicitados.

También puede definirse como que el modelo en la nube es, en la actualidad, una oferta de acceso inme-diato y a un coste asequible (y a veces gratuito) a las tecnologías de la información cuya infraestructura, hardware, software y personal cualificado, se pone al alcance de empresas y particulares para ofrecer diversos productos y servicios.

Siguiendo con la definición que ofrece la Cloud Security Alliance (en adelante, CSA) de la computación en la nube, las características esenciales de este modelo son: autoservicio a la carta, amplio acceso a la red, reservas de recursos en común, rapidez y elasticidad y servicio supervisado [CSA, 2009].

De acuerdo con el documento de CSA “Top Threats to Cloud Computing v1.0” [CSA, marzo 2010], y dada la importancia del fenómeno de la computación en la nube, como demuestra la publicación de otros infor-mes similares como el de INTECO [Inteco, 2011], el del World Privacy Forum [WPF, 2009], etc., se pueden enumerar una serie de amenazas a tener en cuenta a la hora de desplegar un modelo de servicio en la nube como serían: Interfaces y APIs1 poco seguros, problemas derivados de las tecnologías compartidas, pérdida o fuga de información, secuestro de sesión, riesgos por desconocimiento, migración de servicios hacia otro proveedor, amenaza interna y mal uso o abuso del servicio. A estos riesgos asociados a este modelo de computación, que además destacan por su falta de históricos, habría que añadir otros como son los accesos de usuarios con privilegios, la localización y el aislamiento de los datos, la recuperación, el soporte investigativo, la viabilidad a largo plazo, la falta de control de la gestión y seguridad de los datos, las cesiones no consentidas o las transferencias internacionales no autorizadas, en definitiva, la privacidad de los datos en la nube y el cumplimiento normativo o legal.

Conviene recordar que aspectos como las transferencias internacionales, las subcontrataciones o las dis-tintas jurisdicciones de las diferentes autoridades de control son difíciles de resolver en este modelo de computación, según entendemos la normativa actualmente.

Cumplimiento legislativo en materia de Privacidad

1 Application Programming Interface



Tampoco conviene olvidar que es casi imposible cumplir con el precepto de verificación del cumplimiento del encargado del tratamiento por el responsable del fichero dada la diferencia de tamaño y capacidad negociadora de las organizaciones que a veces están implicadas en el proceso.

A su vez, existen muchos retos desde el punto de vista del cumplimiento normativo y la privacidad que tratan de dar una respuesta adecuada a los riesgos correspondientes enumerados en el párrafo anterior.

Este capítulo viene a estudiar los diferentes aspectos contemplados anteriormente con objeto de poder ayudar al lector a establecer pautas para abordar los retos que conlleva el modelo de computación en la nube desde la perspectiva española. Las razones para ello son, principalmente dos: La primera y más evidente es que constituye la aportación del capítulo español de la Cloud Security Alliance. La segunda, obedece a que España cuenta en la actualidad con la normativa más rigurosa en materia de protección de datos personales. España ha sido el país europeo que ha desarrollado con mayor intensidad, los principios consagrados por la Directiva 95/46/CE, que a su vez es el marco jurídico más garantista que se conoce, en materia de protección de datos. Esto permite afirmar que cualquier prestación de servicios en la nube, que cumpla con los requisitos exigidos por la normativa española, puede cubrir los requisitos exigidos por las normativas de otros Estados.

Antes de entrar a analizar la normativa española de protección de datos, conviene realizar una referencia sucinta de los marcos normativos existentes.

4.1.1 Estados UnidosEn Estados Unidos, la protección de datos personales no está considerada como un derecho fundamental. Existe una política legislativa de mínimos que fomenta la autorregulación en el sector privado. Con un enfoque mercantilista, se persigue la protección de los derechos de los ciudadanos, desde la perspectiva de la “protección del consumidor”.

No obstante, existen desarrollos normativos verticales que buscan adaptarse al contexto específico en cuanto a la naturaleza de los datos, la finalidad de su tratamiento, o la naturaleza responsable de dicho tratamiento. A modo de ejemplo podemos mencionar: Electronic Communications Privacy Act de 1986, Electronic Funds Transfer Act, Telecommunications Act de 1996, Fair Credit Reporting de 1970 y Consumer Credit Reporting Reform Act de 1996, Right to Financial Privacy Act, entre otras.

En cuanto a la aplicación, son los propios titulares de los datos quienes deben velar por el cumplimiento de la normativa que regula el tratamiento de sus datos, a través del ejercicio de los derechos que se les reconocen.

4.1.2 EuropaEn Europa, la protección de datos personales está considerada como un derecho fundamental. En línea con una tradición jurídica positivista, se ha acentuado la labor legislativa con el fin de establecer un sistema garantista (de hecho, el más garantista que existe en la actualidad) en aras de asegurar una la protección efectiva a los derechos de los ciudadanos.

La Directiva 95/46/CE [Directiva, 1995] constituye el marco europeo de referencia. En esta Directiva se establecen ciertos principios, que los Estados Miembros ha tenido que transponer en sus respectivos ordenamientos, a saber:



1. Información. 2. Consentimiento. 3. Finalidad. 4. Calidad. 5. Seguridad. 6. Derechos de Acceso, Rectificación, Cancelación y Oposición. 7. Autoridad de Control independiente. 8. Limitación a las trasferencias internacionales de datos.

El enfoque europeo ha servido también como fuente de inspiración para otras legislaciones, principalmen-te de corte continental, que han incorporado o están incorporando estos principios, evidentemente para proteger los derechos de los ciudadanos, pero también, para favorecer el tráfico económico con los países miembros de la Unión. Argentina,Chile y Colombia y México son algunos ejemplos en este sentido.

4.1.3 Safe Harbor PrinciplesEl término Safe Harbor Privacy Principles, se refiere a los principios de privacidad a los que deben adhe-rirse las organizaciones estadounidenses, para poder ser importadores de datos personales provenientes de los Estados miembros de la Unión Europea.

Estos principios fueron publicados en el año 2000 por el Departamento de Comercio de los Estados Uni-dos. La adhesión a ellos pretende asegurar la aplicación, por parte del importador, de unos niveles de protección adecuados que sean equiparables a los establecidos por la Directiva.

Con la adhesión, el importador se obliga a observar ciertos principios rectores en tratamiento de datos personales, como son:

1. Notificación e información a los titulares, previos a la recogida de datos. 2. Derecho de oposición a la comunicación de datos a terceros o a los usos incompatibles con el

objeto inicial de la recogida. 3. Abstención de transferencia ulterior de datos a terceros que no se hayan adherido a los prin-

cipios de Safe Harbor. 4. Obligación de implementar medidas de seguridad. 5. Calidad de los datos. 6. Reconocimiento de los derechos de acceso y rectificación a los afectados. 7. Necesidad de adoptar mecanismos que brinden garantías para la aplicación de los principios.

4.1.4 Marco APEC2

Comparte los principios de protección de datos personales de la Directiva Europea, no obstante, presenta grandes diferencias en cuanto a la aplicación.

En el modelo europeo, las autoridades de protección de datos regulan y verifican el cumplimiento de dichos principios, mientras que en el modelo APEC esto se lleva cabo, a través de mecanismos de auto-regulación verificados por organismos públicos o privados, de modo que no se garantiza que se obligue desde el Estado.

2 De las sigas en inglés de Asia-Pacific Economic Cooperation, en español, Foro de Cooperación Económica Asia-Pacífico.



Al igual que el modelo estadounidense, existe un enfoque desde el punto de vista consumidor y es un modelo ex post, en el que una autoridad pública o privada puede intervenir sólo después de que se ha producido la supuesta violación.

4.1.5 Habéas DataEn los países con el modelo Hábeas Data, la protección de datos se asocia con un derecho a conocer, actualizar y a rectificar datos. Estos modelos presentan las siguientes características:

• Existen mecanismos de garantía procesal o judicial.

• La intervención de la autoridad es siempre ex-post, es decir, la normativa no implica cumpli-miento de obligaciones ex-ante por parte de las organizaciones.

• Inexistencia de autoridades de control.

• Legitimación personas que han sufrido una lesión en su intimidad por el uso abusivo de sus datos.

4.1.6 Resolución de Madrid sobre Estándares Internacionales sobre Protección de Datos Personales y Privacidad

Este documento, producto de la labor conjunta de los garantes de la privacidad de casi cincuenta países, bajo coordinación de la Agencia Española de Protección de Datos, ha desembocado en un texto que trata de plasmar los múltiples enfoques que admite la protección de este derecho, integrando legislaciones de los cinco continentes.

Tal y como establece la Disposición Primera del Documento, los Estándares tienen por objeto “Definir un conjunto de principios y derechos que garanticen la efectiva y uniforme protección de la privacidad a nivel internacional, en relación con el tratamiento de datos de carácter personal; y Facilitar los flujos internacio-nales de datos de carácter personal, necesarios en un mundo globalizado”.

Aunque no tiene un carácter vinculante, estos Estándares establecen un compromiso político de quienes lo han suscrito, en el sentido de servir como referencia a los Estados que en la actualidad no hayan legislado sobre la materia, y de servir como referencia para la armonización de la normativa existente, en aras de que la normativa sobre protección de datos y la privacidad no se constituya un obstáculo al comercio internacional; facilitándose el flujo de los datos de carácter personal y la uniformidad de la misma.

4.2 Contenido del capítulo

El objetivo del capítulo, por tanto, es plasmar los resultados del estudio sobre el cumplimiento normativo y privacidad en computación en la nube tomando como base la legislación europea y haciendo referencia a otra normativa cuando sea necesario.

El informe se estructura de la siguiente forma: Un primer apartado de introducción donde se explica la motivación del análisis, las ventajas, y los riesgos de este modelo de procesamiento.



Este segundo apartado donde se explica la estructura y contenido del informe, con una breve explicación del contenido de cada uno de ellos.Un tercer apartado con un resumen ejecutivo donde, mediante una visión rápida, el lector se puede hacer una idea bastante aproximada del cumplimiento normativo en la computación en la nube.

A continuación, el cuarto apartado, estudia con más detalle cada uno de los aspectos que se conside-ran relevantes a la hora de establecer un modelo de proceso basado en la computación en la nube. El análisis de cada uno de estos aspectos se estructura de la misma forma, una descripción general, los aspectos mas relevantes de la situación analizada en base a los modelos de servicio y despliegue de la nube, la legislación que le aplica y, finalmente, las recomendaciones que se proponen desde el punto de vista de proveedor o cliente del servicio sin olvidar, cuando sea necesario, el punto de vista de las personas afectadas. En el apartado de las medidas de seguridad se sigue una estructura diferente, estudiándose las diferentes medidas desde el punto de vista de la empresa proveedora y de la empresa que contrata.

El primer punto empieza estudiando la legislación aplicable según el responsable del tratamiento resida en un país dentro del Espacio Económico Europeo o fuera de él.

El segundo punto estudia la figura del encargado del tratamiento, como proveedor del servicio en la nube, repasando la subcontratación y otros agentes operadores de telecomunicaciones.

El tercer punto se centra en las medidas de seguridad analizando los principales aspectos de las mismas como son el documento de seguridad, el control de acceso, la gestión de incidencias, las copias de segu-ridad y las auditorías.

El cuarto punto trata las transferencias internacionales, tanto desde de la situación en que no exista comu-nicación de datos a un tercero como cuando se da esta comunicación y la diferenciación de un país con nivel adecuado de protección o sin nivel adecuado.

El quinto punto aborda el ejercicio de los derechos por los interesados tanto en sus características como requisitos y riesgos.

El sexto punto analiza el papel de las autoridades de control en tanto a la determinación de la ju-risdicción a aplicar en el caso de una denuncia o tutela de derechos y la ejecución efectiva de las resoluciones.

El séptimo punto considera la comunicación de datos a otras autoridades bien por requerimientos de leyes o de organismos tanto desde el ámbito nacional como de otros países.

La audiencia de este documento son los clientes y usuarios de los recursos ofrecidos mediante modelos de computación en la nube y los proveedores de los mismos, sirviendo como referencia para solicitar y ofrecer soluciones en lo relativo a la privacidad de los datos en la nube, el cumplimiento normativo o legal y los mecanismos de seguridad y acuerdos necesarios para controlarlos.



4.3 Legislación aplicable3

4.3.1 Descripción general4La normativa sobre legislación aplicable a los tratamientos de datos personales se encuentra descrita en el artículo 4 de la Directiva de Protección de Datos [Directiva 1995]. Este artículo tiene dos partes bien diferenciadas. La primera, hace referencia a la ley aplicable a responsables de tratamiento que estén esta-blecidos en un Estado miembro del Espacio Económico Europeo (EEE)5. La segunda, de manera que puede resultar sorprendente pues podría suponer un cierto grado de aplicación extraterritorial de la Directiva, a aquellos responsables que, sin estar establecidos en el EEE, utilizan medios situados en el mismo para el tratamiento de datos personales.

Para el primer caso, el concepto clave para la determinación de la legislación aplicable es el de la ubica-ción del establecimiento del responsable del tratamiento en conjunción con las actividades de tratamiento que se llevan a cabo conforme al apartado 1 del artículo 4 de la Directiva, letra a).

Por lo tanto, no siempre existe una única ley aplicable para todas las operaciones de un determinado responsable de tratamiento de datos personales: Si dicho responsable está establecido en distintos Esta-dos miembros del EEE y trata datos personales en el ámbito de las actividades de varios de ellos, a cada uno de estos tratamientos se le aplicaría un Derecho nacional diferente6, lo que nos lleva a considerar el segundo elemento esencial para determinar la ley aplicable, para qué responsable se lleva a cabo el trata-miento. Por ejemplo, un responsable establecido en Bélgica tiene tiendas en diversos países europeos (por ejemplo, Bélgica, Alemania, Portugal, Francia e Italia) pero las acciones de marketing están centralizadas en Bélgica y todos los datos de los clientes para esta finalidad se tratan en allí. En este caso, y para ese tratamiento específico, independientemente del lugar en que se recojan los datos, la ley aplicable será la belga7.

No obstante, esta regla tiene un corolario y es el que se desprende de la aplicación del apartado tercero del artículo 17 de la Directiva y que se refiere a las medidas de seguridad que deben aplicar los encar-

3 En este estudio no se abordará la casuística de aquellos servicios que se contratan directamente (ya sea gratuitamente o no) por los usuarios finales al proveedor de computación en la nube (ejemplos de ellos son los servicios de correo electrónico en la nube o las redes sociales) ni aquellos casos en los que el proveedor de servicios –típicamente un encargado de tratamiento en la terminología de protección de datos– se transforma también en responsable por utilizar los datos personales para finalidades propias (lícita o ilícitamente) como, por ejemplo, un proveedor de servicios IaaS que utiliza los datos confiados a su custodia para, a través de herramientas de minería de datos, establecer perfiles de hábitos de compra para su explotación o su venta a terceros.

4 Para una discusión en profundidad de este asunto se puede consultar el Dictamen 8/2010, sobre Ley Aplicable, del Grupo de Trabajo del Artículo 29.

5 Formado por los estados de la Unión Europea e Islandia, Noruega y Lienchtenstein6 Así, ni la nacionalidad ni el lugar de residencia de los afectados ni, incluso, la localización física de los sistemas de

información donde se tratan datos personales son, en este caso, elementos relevantes para determinar el derecho aplicable a un tratamiento.

7 No hay que confundir ley aplicable con jurisdicción. Podría suceder que una autoridad de control de un estado miembro tuviera jurisdicción para dictaminar sobre un determinado tratamiento de datos pero tuviera que hacerlo aplicando la ley de otro Estado miembro. En el ejemplo expuesto, en base a lo que establece el artículo 28 de la Directiva, si hubiera una reclamación relativa a una acción de marketing llevada a cabo en Francia, la autoridad competente para resolverla sería la francesa, pero debería aplicar la legislación belga.



gados de tratamiento de datos establecidos en un Estado del EEE. En efecto, este artículo dispone que los encargados de tratamiento, además de estar sujetos a lo que dispone la ley del Estado en que está esta-blecido el responsable del tratamiento, también han de aplicar las medidas de seguridad establecidas por la legislación del Estado miembro en que estén establecidos y, en caso de que hubiera un conflicto entre ambas, prevalecerá esta última.

La segunda parte que se mencionaba al inicio de esta sección se refiere a la aplicación de las previsiones de la Directiva8 a un responsable que, aun no estando establecido en un Estado del EEE recurre “para el tratamiento de datos personales, a medios, automatizados o no, situados en el territorio de dicho Estado miembro, salvo en caso de que dichos medios se utilicen solamente con fines de tránsito por el territorio de la Comunidad Europea”. En este caso, el responsable del tratamiento deberá designar un representante establecido en el territorio del Estado miembro de que se trate.

Así pues, en el caso de un proveedor de servicios en la nube establecido, por ejemplo, en Estados Unidos, pero que utiliza, para determinados tratamientos de datos, servidores ubicados en un Estado del EEE, la legislación aplicable a los mismos será la de este Estado y, de hecho, el proveedor exportará la legislación europea a los tratamientos de datos personales que lleven a cabo sus clientes.

4.3.2 Aspectos más relevantesEn relación con la legislación aplicable a de responsables ubicados en el EEE, el modelo de servicio o de despliegue es irrelevante ya que, en cualquier caso, la determinación de la ley aplicable tan solo de-penderá del Estado en que esté establecido el responsable del tratamiento que ha contratado los servicios de computación en la nube y no del lugar en que se localicen los proveedores de dichos servicios o los equipos de tratamiento utilizados por los mismos.

No obstante, también puede tenerse que tomar en consideración la legislación sobre seguridad de otro Estado miembro si el proveedor de servicios en la nube está establecido en dicho Estado miembro distinto del cual en el que está establecido el cliente.

Para el caso en que el cliente de un servicio de computación en la nube (que será el responsable de los tratamientos de carácter personal) no esté establecido en el EEE pero su proveedor de servicios utilice medios o equipos ubicados en un Estado miembro del EEE para prestarle los servicios, como antes se ha mencionado, éste le exporta automáticamente la aplicabilidad de los requisitos de la legislación de protec-ción de datos del país de que se trate9.

4.3.3 Legislación aplicableLos artículos que regulan la ley aplicable a un tratamiento de datos son el artículo 4 de la Directiva de Protección de Datos en el que se ha basado el análisis llevado a cabo en este capítulo, el artículo 2 de la Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal (en adelante, LOPD) y el artículo 3 del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo

8 En el bien entendido que lo que esta frase significa en la realidad es la aplicación de la legislación que el Estado miembro correspondiente haya aprobado al transponer la Directiva. No se tratará el caso descrito en la letra b) del apartado primero del artículo 4 por ser un caso residual y de escasa relevancia para el objeto de este estudio.

9 Como se puede apreciar, en este caso no es suficiente que el proveedor de computación en la nube esté establecido en un Estado del EEE sino que utilice medios que sí estén ubicados dentro del EEE.



de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal (en adelante, RLOPD)10.

4.3.4 RecomendacionesDado que la legislación aplicable a una determinada operación de tratamiento de datos personales no es algo que dependa de la voluntad de ninguna de las partes vinculadas por el contrato de prestación de servicios en la nube, no hay mucho margen para realizar recomendaciones específicas. No obstante, se mencionarán algunos puntos que deberán tenerse en cuenta.

4.3.4.1 Empresa proveedoraLas empresas que utilicen medios situados en el territorio del EEE para prestar servicios a sus clientes de-berán ser conscientes que exportan la legislación europea a todos aquellos que no estén establecidos en dicho espacio. Esto implica que las obligaciones de la legislación de protección de datos del Estado miem-bro que corresponda les resulta de aplicación y que, además, ello les obliga a nombrar un representante en el Estado de que se trate11.

Si sus clientes están establecidos en el territorio del EEE, las obligaciones relativas a protección de datos (salvo, quizás, las referentes a medidas de seguridad) serán incumbencia de dichos clientes.

4.3.4.2 Empresa clienteSi es una empresa establecida en el territorio del EEE, independientemente de donde esté ubicado su proveedor de servicios en la nube o los sistemas de tratamiento de la información de dicho proveedor, ella será la respon-sable en términos de protección de datos y le será de aplicación la ley del Estado en que esté establecida.

Si su proveedor está establecido en un Estado miembro diferente, deberá tener en cuenta que puede existir la necesidad de analizar los requerimientos en materia de seguridad aplicables en el Estado de estable-cimiento del proveedor y que, en todo caso, si existe alguna incompatibilidad o conflicto entre ambas normativas, prevalece la del Estado de establecimiento del proveedor.

4.4 Encargado de tratamiento

4.4.1 Descripción generalEl concepto de ‘encargado de tratamiento’ se determina en función de dos condiciones básicas: Ser una entidad independiente del responsable del tratamiento y realizar el tratamiento de datos personales por cuenta de éste12.

10 De hecho, este artículo no transpone correctamente las normas sobre legislación aplicable de la Directiva, ya que dispone que la LOPD solo es de aplicación a tratamientos de datos personales llevados a cabo por responsables establecidos en España y que se produzcan en territorio español lo que, como hemos visto, no es lo que establece la Directiva. El artículo 3 del RLOPD (sin entrar a valorar si ha de prevalecer o no sobre el régimen de la LOPD) ha recogido de manera correcta el modelo de la Directiva.

11 El Grupo de Trabajo del Artículo 29 reconoce en su Dictamen 8/2010 que esta previsión de la Directiva puede ocasionar problemas prácticos y económicos pero, aun así, afirma que no existe otra interpretación posible aunque aboga por una reflexión sobre este hecho en el marco de la futura revisión de la legislación europea de protección de datos.

12 Dictamen 1/2010 sobre los conceptos de “responsable del tratamiento” y “encargado del tratamiento” emitido por el Grupo de Trabajo del Art. 29. Este dictamen analiza el concepto de encargado del tratamiento, cuya existencia depende de una decisión adoptada por el responsable del tratamiento, que puede decidir que los datos se traten dentro de su organización o bien delegar todas o una parte de las actividades de tratamiento en una organización externa.



Dentro de la normativa de protección de datos española encontramos la definición de encargado de trata-miento como “la persona física o jurídica, autoridad pública, servicio o cualquier otro organismo que, sólo o conjuntamente con otros, trate datos personales por cuenta del responsable del tratamiento”13.

Tal como indica la Sentencia de la Audiencia Nacional de 20 de septiembre de 200214, el encargo de tratamiento se ampara en la prestación de un servicio que el responsable del tratamiento recibe de una empresa ajena a su propia organización y que le ayuda en el cumplimiento de la finalidad del tratamiento de datos consentida por el afectado.

Ahora bien, este tratamiento debe delimitarse, concretando el responsable el margen de actuación del encargado en su función encomendada, o se puede dejar un cierto grado de discrecionalidad sobre cómo realizar su función en base a los intereses del responsable del tratamiento.

Es aquí donde la figura del encargado de tratamiento se vincula al proveedor de servicios en la nube, ya que éste presta servicios de negocio y tecnología, que permite al usuario acceder a un catálogo de servicios estandarizados de forma flexible y adaptativa, permitiendo a este proveedor que establezca los medios técnicos y de organización más adecuados.

Por lo tanto, teniendo en cuenta la normativa aplicable y las obligaciones que conlleva, el proveedor de servicios en la nube podrá determinar su responsabilidad como encargado de tratamiento en función de la tipología de nube (pública, privada, comunitaria o híbrida) y del servicio que decida contratar el respon-sable de tratamiento de los datos de carácter personal, ya que en función del modelo de despliegue de los servicios en la nube (modelo SPI), las responsabilidades del proveedor serán diferentes.

4.4.2 Legislación aplicable

4.4.2.1 Proveedores de servicioLa regulación aplicable distingue claramente la figura entre “responsable de tratamiento” y “encargado de tratamiento”, estableciendo como obligación principal la confidencialidad y seguridad de los datos15.

El acceso a los datos por parte del proveedor de la nube para prestar sus servicios se condiciona, como premisa esencial, al cumplimiento del régimen establecido por el artículo 12 de la LOPD. Este artículo esta-blece la obligación de la realización de un contrato formal entre el responsable de los datos, (cliente que contrata el servicio en la nube) y el encargado del tratamiento (proveedor del servicio en la nube)16.

El cliente que contrata un proveedor de la nube que suponga el acceso a datos de carácter personal, debe tener claro los requisitos formales que establece el artículo 12 de la LOPD, ya que este artículo obliga a que el contrato “conste por escrito o en alguna otra forma que permita acreditar su celebración y conteni-do”. Además existe jurisprudencia17 que indica que, para la validez de la comunicación de los datos del artículo 12 no es suficiente la existencia de un contrato, también es necesario que detalle las condiciones

13 Ver Art. 3. g.) Ley Orgánica de Protección de Datos.14 Sentencia de la AN, Sala de lo Contencioso-administrativo, Sección 1ª, 20 sep. 2002 (Rec. 150/2000).15 Ver artículos 2(d) y (e) de la Directiva 95/46/CE, artículo 3.g LOPD y artículo 5.1.i RLOPD.16 Ver artículos 16 y 17 de la Directiva 95/46/CE. Artículo12.2 LOPD y artículos 20 y 22 RLOPD.17 Sentencia de la Audiencia Nacional, Sala de los Contencioso-administrativo, sección 1ª, 16 mar. 2006 (Rec. 427/2004).



que se establecen en dicho precepto y que garantice la seguridad de los datos impidiendo el acceso a los mismos de terceros18.

En este contrato debe figurar el siguiente contenido:

1. Especificar y delimitar la finalidad para la que se comunican los datos (Art. 12.2 LOPD).

2. Establecer expresamente que el proveedor de la nube no puede comunicar estos datos a terce-ros, ni siquiera para su conservación (Art. 12.2 LOPD).

3. Implementar las medidas de seguridad que debe cumplir el responsable en función del tipo de datos que contenga el fichero y el nivel de seguridad aplicado (Art. 9 y 12.2 LOPD).

4. Delimitar el tiempo de ejecución del servicio.

5. Determinar de forma concreta las condiciones de devolución de los datos o destrucción de los datos una vez cumplido el servicio (Art. 12.3 LOPD y 22RLOPD).

6. Existencia de una clausula de confidencialidad, tanto al proveedor de la nube, como a sus empleados que puedan acceder a los datos.

7. Establecer la obligación del encargado, en el caso de que los interesados ejerciten sus dere-chos ARCO19 ante el mismo, de dar traslado de la solicitud al responsable. A excepción, en el caso de que exista un acuerdo entre el proveedor de la nube y el cliente de que dicha gestión la realice directamente el encargado de tratamiento.

Otro criterio a tener en cuenta en base a la normativa de protección de datos es la obligación del encar-gado de tratamiento a disponer de un Documento de Seguridad, ya que el proveedor de la nube, según el tipo de nube y el servicio que preste al responsable, encaja como agente tratante definido en el artículo 82.2 del RLOPD. Este documento de seguridad debe cumplir con los requisitos que le exige el artículo 88 del RLOPD.

Por lo tanto, podemos decir que, tanto el encargado de tratamiento como el responsable del tratamiento, tienen las mismas obligaciones de cumplimiento de implementación de las medidas de seguridad que exi-ge la normativa. Además, se debe tener en cuenta que el RLOPD, en su artículo 20.2, exige al responsable, es decir al cliente que contrata el servicio en la nube, que vigile el cumplimiento por parte del encargado de tratamiento, y por tanto, se obliga al responsable tener una diligencia a través de algún sistema que permita la realización de controles periódicos.

En cuanto a la posibilidad de existencia de subcontratación de servicios externos por parte del proveedor de computación en la nube, en los cuales estos subencargados tengan acceso a datos de carácter perso-

18 Los aspectos de contratación se tratan específicamente en el Capítulo 7, no obstante, se incluyen en este capítulo los requerimientos de contratación específicos en materia de privacidad establecidos por la LOPD.

19 Acrónimo utilizado comúnmente para referirse a los derechos de acceso (A), rectificación (R), cancelación (C) y oposición (O) de los titulares de los datos.



nal, la ley no descarta la legitimidad de esta posibilidad, pero obliga a cumplir los siguientes requisitos (incluidos en el artículo 21 RLOPD):

• Que los servicios que se pretende subcontratar se hayan previsto en el contrato entre el provee-dor y el cliente de este servicio.

• Que se especifique en el contrato el contenido detallado del servicio subcontratado.

• El cliente debe establecer las instrucciones de cómo tratar los datos.

En definitiva, las empresas que deseen contratar un servicio de computación en la nube, deben tener en cuenta que existe una normativa estatal que impone al encargado del tratamiento la obligación de procesar los datos del cliente de acuerdo con el sistema de seguridad establecido por la regulación de protección de datos.

4.4.2.2 Otros agentesEn la prestación de los servicios del proveedor de computación en la nube intervienen otros agentes sin los que no sería posible la comunicación y el acceso a la información en la nube. Dichos agentes son los operadores de telecomunicaciones y los prestadores de servicios de acceso a la red.Estos operadores explotan las redes públicas de comunicaciones gestionando y garantizando el tráfico de datos que circulan por su infraestructura o prestan servicios de comunicaciones electrónicas, disponibles al público, consistentes en permitir el acceso a las redes públicas de comunicaciones entre otros servicios.

En tal supuesto, los datos de los abonados o usuarios son aquellas personas físicas o jurídicas que contra-tan el servicio ya sea directamente al operador que hace a la vez de proveedor de servicios de Internet (ISP, por sus siglas en inglés) o a través de un tercero que alquila los servicios de explotación al operador de red.

Por lo tanto, al considerarse sujetos obligados en base a la siguiente normativa20:

• Ley 25/2007, de 18 de octubre, de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones.

• Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones.

Se establece una serie de requisitos, en relación a la protección de datos, que se deben cumplir21:

• Identificar al personal autorizado para acceder a los datos que son objeto de esta Ley.

• Adoptar medidas de seguridad con sujeción a lo dispuesto en el Título VIII del RLOPD.

En base a la normativa aplicable se establece que el operador de telecomunicaciones que no preste ser-vicios de acceso a la red directamente al abonado podría considerarse prestador de servicios sin acceso

20 Esta legislación se analiza en detalle en el Capítulo 5.21 Ver Art. 8 de la Ley 25/2007 “Protección y seguridad de los datos” y Art. 34 de la Ley 32/2003 “Protección de datos

de carácter personal”.



a datos personales de los ficheros de los abonados o usuarios (que actúan en calidad de responsables de tratamiento)22 al tener prohibido en base al artículo 3.3 de la ley 25/2007 la conservación de ningún dato que revele el contenido de las comunicaciones a excepción de los supuestos de interceptación de las comunicaciones autorizadas en base a lo contemplado en leyes especiales. Por lo tanto, deberá cumplir con el artículo 83 del RLOPD.

El ISP podría equipararse a la figura del operador de telecomunicaciones, en el supuesto que se limite a prestar servicio de acceso a la red y, por tanto, se considere que presta un servicio sin acceso a datos personales de los ficheros de los abonados o usuarios debido a la prohibición de conservar ningún dato que revele el contenido de las comunicaciones según el artículo 3.3 de la ley 25/2007 a excepción de los supuestos de interceptación de las comunicaciones autorizadas en base a lo contemplado las leyes especiales. Por lo tanto, al igual que el operador de telecomunicaciones, también deberá cumplir con el artículo 83 del RLOPD.

En el supuesto de que el ISP preste servicios complementarios de housing o hosting de correo electrónico o disco duro virtual, por ejemplo, debería considerarse encargado de tratamiento de los datos contenidos en los ficheros de los abonados y por tanto cumplir con los requisitos del artículo 12 LOPD y artículos 20 a 22 del RLOPD.

4.4.3 RecomendacionesAbordando el tratamiento de datos desde un punto de vista de ciclo de vida y teniendo en cuenta las obligaciones y el cumplimiento legal, se pueden enumerar una serie de recomendaciones básicas para cada uno de los perfiles posibles: Empresa proveedora de servicios en la nube, empresa contratante de las mismas y usuarios23.

El concepto de tratamiento de datos engloba las fases de creación, almacenamiento, uso, compartición o comunicación, archivo y cancelación de la información. En concreto, y con el fin de no solaparse con otros estudios, en esta fase se va a centrar en el almacenamiento, uso y archivo de la información.

Tres conceptos básicos se deben tener en cuenta en relación al tratamiento de los datos, sea cual sea el ámbito de aplicación o actuación:

• Recurso: Información sobre la que se desea actuar.

• Acción: Tipo de actuación que se quiere realizar sobre un recurso.

• Actor: Usuario que desea realizar una acción determinada sobre un recurso en concreto.

La combinación de estos tres conceptos y cómo se gestionan, establecerá el ámbito de actuación en rela-ción al tratamiento de los datos.

22 Delimitación de la figura de responsable y encargado en el Operador de telecomunicaciones contemplada en el Dictamen 1/2010 del Grupo del Artículo 29 sobre los conceptos de «responsable del tratamiento» y «encargado del tratamiento» (WP 169): http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp169_es.pdf .

23 Personas afectadas por el tratamiento de sus datos personales.



4.4.3.1 Empresa proveedoraLas responsabilidades del proveedor se relacionan según el tipo de servicio que se contrate, ya que el tipo de servicio nos indica el grado de responsabilidad que le afecta. Por eso, el proveedor es responsable de pro-porcionar los controles de medidas de seguridad que exige la normativa, en base al servicio contratado.

El proveedor de computación en la nube será considerado encargado de tratamiento de los datos conte-nidos en los ficheros de los clientes y, por tanto, deberá cumplir con los requisitos del artículo 12 LOPD y artículos 20 a 22 del RDLOPD.

Los proveedores de computación en la nube, como usuarios de las redes de comunicación y con provee-dor propio de ISP, deberán verificar el cumplimiento legal y legitimación de estos últimos agentes que le permiten prestar el servicio a sus clientes finales.

Tal verificación previa de cumplimiento normativo será necesaria para que los contratos de encargado de tratamiento con los clientes finales puedan reflejar la información referente a los subencargados que per-mitirán la prestación de servicio. En las cláusulas del contrato se deberá resaltar la finalidad de dichos su-bencargos, la identificación geográfica de los agentes operadores y ley aplicable, así como una remisión de las medidas de seguridad aplicables y el compromiso de responsabilidad de cualquier incumplimiento normativo. Cualquier incumplimiento de las estipulaciones del contrato será asumido directamente por la empresa proveedora como responsable directo ante el propio cliente (responsable de fichero o tratamiento) y ante las autoridades competentes de protección de datos.

De manera general, la principal consideración sería que el papel del proveedor debe ser el de proporcionar las herramientas necesarias y suficientes al propietario o responsable de la información en función del tipo de nube (IaaS, PaaS, SaaS), siguiendo las pautas establecidas por la legislación actual y las normativas o pro-cedimientos que la organización propietaria de la información tenga desplegadas. En consecuencia con lo comentado, desde el punto de vista de ciclo de vida del tratamiento de la información hay que considerar:

• Almacenamiento o Control de acceso a la información. o Gestión de la documentación (meta-información que lleva asociada la documentación o informa-

ción). En este punto, es importante remarcar que el tipo de clasificación que se defina en combi-nación con las capacidades de actuación que un usuario pueda poseer, proporciona un marco de control de acceso y gestión de la documentación muy avanzada, granular y programable a cualquier escenario, que es uno de los objetivos principales de cualquier tipo de nube.

o Cifrado de la información. o Trazabilidad y auditoría.

• Uso o Trazabilidad y auditoria. o Lógica de aplicación. o Control de acción sobre la información.

• Archivo o Cifrado de la información en medios de almacenamiento de medio-largo plazo. o Gestión de activos y trazabilidad.



4.4.3.2 Empresa clienteTodo cliente, responsable del tratamiento de datos personal, que contrata la prestación de un servicio en la nube, debe velar que el encargado del tratamiento reúna e implante las garantías para el cumplimiento de las obligaciones en virtud de la normativa en materia de protección de datos.

El propietario de la información debe analizar los riesgos sobre el ciclo de vida de la información y los acti-vos que lo contienen y gestionan. Por ello, la normativa de protección de datos y las diversas normativas de seguridad de la información establecen la necesidad de llevar a cabo una auditoría interna o externa.

Para garantizar la trazabilidad y auditoría se recomienda establecer en el contrato una clausula contrac-tual del derecho a auditar, de manera que el proveedor de la nube acepte ser auditado. Sobre todo en este caso, en que el propietario de la información tiene responsabilidades de cumplimiento normativo24.

También es recomendable desarrollar un proceso para recopilar evidencias del cumplimiento normativo, incluyendo los registros de auditoría e informes de la actividad, gestión y procedimientos25.

También podría darse el caso de generar contratos de adhesión donde el nivel de seguridad aplicable a la prestación del servicio en la nube deberá ser indicado por parte del responsable del fichero y este último aceptar en bloque las medidas adoptadas por su prestador de servicios de computación en la nube.

En conclusión, se debe prestar atención a la elección de un proveedor de la nube, verificando que pro-porciona suficientes medidas de seguridad técnicas y medidas organizativas que rigen el tratamiento a realizar, y garantizar el cumplimiento de dichas medidas.

De manera general, podríamos decir que el cliente, con el fin de cumplir las obligaciones del responsable de tratamiento hará uso de las herramientas y técnicas que el proveedor le ofrezca. En consecuencia con lo co-mentado, desde el punto de vista de ciclo de vida del tratamiento de la información deberíamos considerar:

• Almacenamiento o Control de acceso a la información. o Gestión de la documentación. o Cifrado de la información. o Trazabilidad y auditoría. En este punto sería interesante que el proveedor ofreciese la posibili-

dad de programar diferentes tipos de alertas que avisen al contratante de situaciones de riesgo o pérdida de información.

•Uso o Trazabilidad y auditoria. o Lógica de aplicación. o Control de acción sobre la información.

•Archivo o Cifrado de la información en medios de almacenamiento de medio-largo plazo. o Gestión de activos y trazabilidad.

24 Este aspecto se trata con mayor generalidad en el apartado 7.10 Auditabilidad.25 Para un análisis más detallado de este aspecto se puede consultar el Capítulo 8.



4.4.3.3 UsuariosEn el caso de los usuarios, debemos asegurar que puedan ejercer sus derechos, al igual que se debe ase-gurar el cumplimiento de sus derechos fuera de la nube:

• Almacenamiento o Control de acceso a la información. o Trazabilidad.

•Uso o Trazabilidad. o Control de acción sobre la información.

4.5 Medidas de seguridad

4.5.1 Empresa proveedoraLos proveedores de servicios en la nube disponen, por definición, de una infraestructura distribuida sobre la que deberán desarrollar un marco de control a nivel de los datos que permita trazar en todo momento su localización y el tratamiento de los mismos. Adicionalmente, el proveedor del servicio en la nube puede subcontratar parte de sus servicios a terceros. En esos casos, el proveedor deberá adoptar las medidas necesarias para asegurar que el proveedor subcontratado aplica las medidas necesarias para asegurar la privacidad y confidencialidad de los datos.26

Sin embargo, independientemente del modelo de servicios, las empresas proveedoras de servicios en la nube, al igual que la totalidad de las entidades que llevan a cabo cualquier tipo de actividad en España, están afectadas directamente por la LOPD así como su desarrollo reglamentario (RLOPD).

4.5.1.1 Documento de seguridadAquellas empresas que operen en España deberán disponer de un ‘Documento de Seguridad’ que descri-ba las medidas de seguridad aplicadas para proteger los ficheros que contengan datos personales de sus empleados, clientes y/o proveedores, tal como indica el artículo 88 del RLOPD. Para el tratamiento en la nube se tendrá especial cuidado en detallar qué tipos de datos se están o van a tratar y el nivel que deberá aplicar la empresa proveedora de servicios en la nube.

La empresa proveedora de servicios en la nube deberá facilitar las herramientas de auditoría que la em-presa contratante requiera para cumplir con sus obligaciones.

4.5.1.2 Responsable de SeguridadEn el Documento de Seguridad se indicará el o los responsables de seguridad designados por el proveedor de servicios en la nube.

4.5.1.3 Control de acceso e identificaciónEn esta apartado nos estamos refiriendo al control de acceso a la información que ejerce una organización ante la petición de acceso de un usuario. No nos estamos refiriendo a la comunicación de la información entre agentes o aplicaciones, es de suponer que si durante el flujo del proceso de acceso a los datos, se

26 En el Capítulo 6 se analiza en detalle la implantación de Sistemas de Gestión de Seguridad de la Información y la interrelación entre sistemas de clientes y proveedores de servicios en la nube.



ha alcanzado el nivel de control de acceso, se han cumplido todas las restricciones aplicables en el nivel de comunicación y transmisión de la información.

El proveedor del servicios en nube (en función del tipo de servicio) deberá proporcionar las herramientas necesarias y suficientes al propietario o responsable de la información, siguiendo las pautas establecidas por la legislación actual y las normativas o procedimientos que la organización propietaria de la informa-ción tenga desplegadas.

Para ello, será necesario disponer de un buen sistema de clasificación de la información sobre el que apo-yarse a la hora de aplicar las medidas de seguridad, incluido las de control de acceso e identificación27.

En este punto, es importante remarcar que el tipo de clasificación que se defina en combinación con las capacidades de actuación que un usuario pueda poseer, proporciona un marco de control de acceso y gestión de la información muy avanzada, granular y programable a cualquier escenario, que es uno de los objetivos principales de cualquier tipo de nube.

Si nos centramos en la LOPD, el nivel de control de acceso trata el consentimiento explícito por parte del afectado (LOPD), es decir, a quién se le permite el acceso y para qué. Estos controles se reflejan en un conjunto de políticas de autorización/acceso que serán definidas y gestionadas por parte del proveedor y/o por el propietario de la información.

4.5.1.4 Gestión de incidenciasDe acuerdo con lo estipulado en los Artículos 90 y 100 (nivel bajo y medio) del RLOPD, el proveedor de servicios en la nube deberá disponer de un procedimiento de notificación, gestión y respuesta de las incidencias, entendiendo por “incidencia” cualquier anomalía que afecte o pueda afectar a la seguridad de los datos.

Ante cualquier anomalía que afecte a los datos carácter personal el proveedor de servicios en la nube deberá notificarla inmediatamente al cliente que ha delegado la gestión de los datos en el proveedor.

4.5.1.5 Copias de seguridad y recuperaciónPara todo proveedor de servicios de en la nube la disponibilidad de los servicios es vital para su negocio, dada la multiterritorialidad de sus clientes. En este escenario, es fundamental disponer de un sistema de copias de seguridad, así como de un plan de recuperación de la información almacenada.

Desde un punto de vista LOPD, es importante tener en mente que el propietario o responsable de la infor-mación es el encargado de decidir cómo debe ser almacenada la documentación. El proveedor del servi-cio en la nube únicamente deberá proporcionar las herramientas necesarias para que se pueda gestionar cómo se va a almacenar la documentación.

4.5.1.6 AuditoriasEl auditor es la figura garante del cumplimiento de unas buenas prácticas y de la existencia de un nivel de control suficiente por parte del proveedor del servicio de computación en la nube, así como de posibles

27 La clasificación de la información se trata en detalle en el capítulo 6 relativo a los Sistemas de Gestión de Seguridad de la Información.



terceros a los que se hayan cedido los datos para su tratamiento. Para ello, el auditor, en el caso de que el proveedor de servicios en la nube acepte ser auditado, deberá ser un tercero independiente.

Uno de los retos fundamentales del auditor será la obtención de evidencias de la realización de las tareas de control interno, así como la ubicación física de los datos.

Por ello, el trabajo del auditor, dada la dispersión intrínseca a la arquitectura de la computación en la nube tendrá que adoptar un enfoque multi-territorial.

La cuestión fundamental en este caso es cómo el propietario de la información (y el responsable de segu-ridad) tiene acceso y control de la trazabilidad y auditoría de su información y de los accesos que se han realizado sobre ella. Este aspecto es vital para el cumplimiento del marco legal en relación a la protección de datos personales y en relación a determinadas normativas de seguridad de la información.

Es importante señalar que el proveedor de servicios en la nube deberá proporcionar las herramientas necesarias para que el propietario pueda ejercer sus obligaciones, ofreciendo un marco de gestión de la trazabilidad y auditoría de los accesos permitidos y los accesos no permitidos, así como un registro de las incidencias ocurridas relativas a los datos de carácter personal.

Asimismo cabe destacar la diferencia de planteamiento cuando la información está localizada en un único punto o bien está distribuida por un número determinado de nubes. Este aspecto es transparente para el propietario o responsable de la información, pero no para el proveedor de servicios en la nube, ya que deberá desplegar un sistema de gestión y correlación de eventos de seguridad (SIEM) o similar en entorno colaborativo según sea el caso.

4.5.1.7 TelecomunicacionesEl proveedor de servicios en la nube deberá proporcionar los mecanismos adecuados para proteger la confidencialidad y privacidad de la información que circule a través de sus sistemas e infraestructuras de comunicaciones. Para ellos, deberá aplicar medidas criptográficas o de cifrado que protejan la informa-ción de accesos no autorizados (por ejemplo, SSL-TLS, IPSec, Kerberos, etc.)

4.5.2 Empresa clienteEl cliente es donde empieza y acaba el servicio. Son sus datos o los de sus clientes los que debe proteger directamente o a través del proveedor de servicios en la nube. El cliente es el responsable de definir la política de seguridad y privacidad que aplicar a sus datos.

Podemos agrupar a los clientes en base a:

• Modelo de “Cloud” • Tamaño de su Organización

Modelo de “Cloud” • Infrastructure as a Service (IaaS)

El cliente es el responsable de la mayor parte de los controles de seguridad, incluyendo control de acceso de las aplicaciones, gestión de identidades de usuarios, etc.



• Platform as a Service (PaaS) El cliente gestiona y controla las aplicaciones de software y, por lo tanto, es responsable de los controles de aplicación.

• Software as a Service (SaaS) El cliente es un mero usuario o receptor del servicio que delega toda la responsabilidad en el proveedor de servicios en la nube. El cliente centrará sus esfuerzos en la supervisión de los Acuerdos de Nivel de Servicio (ANS) y de las medidas de seguridad. Dependerá de la infor-mación proporcionada por el proveedor.

Modelo de OrganizaciónLas personas jurídicas actúan como intermediarios entre las personas físicas (clientes, empleados, proveedores, etc.) y el proveedor de servicios en la nube. Son los custodios de los datos obtenidos de sus propios clientes.

• Grandes Corporaciones Multinacionales: Se trata de entornos muy complejos con gran cantidad de datos procedentes de distintos países con diferentes requisitos. Disponen de una estructura de con-trol interna que deberá adaptarse a las circunstancias de la computación en la nube. Su herramienta básica de gestión será un Acuerdo de Nivel de Servicio (ANS) que permita regular la relación. La principal dificultad estará en detectar incumplimientos y hacer que se respete el ANS28.

• Pequeña y Mediana Empresa: Suele tratarse de organizaciones que carecen de un marco de control interno o es muy limitado, por lo que deberán confiar en la debida diligencia del proveedor en la prestación del servicio y el cumplimiento de la legislación vigente. Sus deci-siones de abogar por la computación en la nube dependerá de cuestiones económicas y de la confianza que generen las soluciones basadas en la misma. En este grupo estarían incluidos microempresas, autónomos y profesionales liberales.

En este caso, aplicarán los mismos requisitos que al proveedor de servicios en la nube. Sin embargo, en este caso el Documento de Seguridad deberá tener en cuenta que la gestión de muchos de los procedi-mientos de gestión de la información corresponderá al proveedor.

4.5.2.1 Responsable de seguridadEl responsable de seguridad es la figura encargada de definir las medidas de seguridad a implantar para asegurar la privacidad y confidencialidad de los datos, de acuerdo con los requisitos de cada país.

El responsable de seguridad tiene la difícil misión de armonizar los diferentes requisitos de tal modo que den como resultado un marco de control coherente.

El responsable de seguridad debe realizar una labor de coordinación con el proveedor de servicios en la nube e internamente, dentro de su organización. Cabe destacar, la necesidad de colaboración entre los responsables de seguridad del proveedor de servicios en la nube y del cliente.

Asimismo, deberá supervisar la implantación de las medidas de seguridad definidas y monitorizar de for-ma periódica su cumplimiento y la adecuada resolución de las anomalías que se detecten. La preocupación del responsable de seguridad ahora es la información (los datos), no el contenedor o la infraestructura.

28 Para un análisis más detallado de los Acuerdos de Nivel de Servicio, consultar el apartado 7.12



Son especialmente sensibles las trasferencias de datos entre países, donde los datos de un país A viajan a un país B con requisitos distintos en materia de privacidad (como veremos en el siguiente apartado).

4.5.2.2 Control de acceso e identificaciónLa empresa que contrata servicios en la nube deberá definir las medidas de control de acceso a la infor-mación de carácter personal de sus empleados, clientes o proveedores en base a su clasificación y nivel de seguridad (alto, medio o bajo).

Asimismo, deberá asegurar la posibilidad de acceso de las personas a sus datos personales para su con-sulta, modificación o eliminación.

4.5.2.3 Gestión de incidenciasEl responsable de seguridad del cliente deberá conocer y validar el procedimiento de notificación, gestión y resolución de incidencias del proveedor de servicios en la nube. Asimismo, deberá supervisar la adecua-da resolución de las incidencias detectadas.

4.5.2.4 Copias de seguridad y recuperaciónEl cliente deberá conocer y validar el procedimiento de realización y recuperación de copias de seguridad de su proveedor de servicios en la nube.

Asimismo, se deberá acordar un plan de copias adecuado con el propietario de los datos y con el proveedor.

El responsable de seguridad del cliente deberá supervisar la adecuada ejecución de dichos procedimien-tos de copia y recuperación de los datos.

4.5.2.5 AuditoriasTal y como se especifica en el RLOPD, el responsable de seguridad será responsable de que se lleve a cabo una auditoria bienal (excepto en el caso de ficheros de nivel bajo) con objeto de validar el cumplimiento de los requerimientos de dicho reglamento. En caso de que se produzcan cambios significativos sobre los sistemas de información o instalaciones, se realizará una auditoría de carácter extraordinario, a partir de la cual se reiniciará el cómputo de los dos años hasta la siguiente auditoría.

Para aquellos datos cuya gestión se delega en el proveedor de servicios en la nube, se deberá obtener la conformidad correspondiente, bien a través de una auditoría directa por parte del cliente o bien que el proveedor proporcione una auditoría tipo SAS 70 o ISAE 3402 que incluya en su alcance la validación del cumplimiento de los requisitos exigidos por la LOPD.

4.6 Transferencias Internacionales

4.6.1 Descripción generalLas transferencias internacionales de datos de carácter personal tienen una regulación específica que se ha de considerar para la computación en la nube, dado el frecuente carácter transnacional de ésta.

No se van a considerar en este apartado las cesiones o comunicaciones de datos a otro responsable de fi-chero, dado que en ese caso se deberá cumplir la regulación correspondiente pero el hecho de estar en un caso de computación en la nube no supone implicaciones adicionales. Asimismo, no se van a considerar los aspectos relacionados con la seguridad de la transferencia que son considerados en el apartado 4.5.



Por tanto, se contemplan los movimientos transfronterizos de datos que no sean considerados cesión o comunicación de datos. Esta situación se da en dos casos:

• El movimiento de datos transfronterizo lo realiza el responsable del tratamiento sin comunicar los datos a terceros.

• El movimiento de datos transfronterizo implica el acceso de un tercero a los datos, pero dicho acceso es necesario para la prestación de un servicio al responsable del tratamiento29. Dicho tercero actuaría como ‘encargado del tratamiento’.

En ambos casos, al no tratarse de una comunicación de datos desde el punto de vista de la legislación sobre protección de datos, no es preciso el permiso del interesado aunque sí aplica la regulación referente a las transferencias internacionales de datos.

4.6.2 Legislación aplicableLas transferencias internacionales de datos de carácter personal están reguladas en:

• Capítulo IV “Transferencia de datos personales a países terceros” de la Directiva 95/46/CE [Directiva 1995].

• Título V “Movimiento internacional de datos” de la LOPD.

• Título VI “Transferencias Internacionales de datos” del RLOPD.

Un aspecto clave en la regulación aplicable es si la transferencia se hace a un país con un nivel de protec-ción adecuado o a un país que no tiene un nivel adecuado.

Los países entre los que los datos se pueden mover sin ningún requisito adicional a los de los movimientos dentro del propio país son los 27 estados miembros de la Unión Europea y los tres países miembros del EEE. Adicionalmente, la Comisión Europea ha reconocido hasta ahora30 que tienen un nivel de protec-ción adecuado los siguientes países: Suiza, Canadá, Argentina, Jersey, Isla de Man, los principios sobre privacidad Safe Harbor del Departamento de Comercio de los Estados Unidos y la transferencia del “Air Passenger Name Record” a la Oficina de Aduanas y protección de fronteras de los Estados Unidos.

La regulación para cada uno de estos dos casos es:

• País de la UE, EEE o con un nivel adecuado de protección de datos. El movimiento transfron-terizo de datos no implica requisitos adicionales a los movimientos dentro del país, salvo su identificación en la notificación del fichero al Registro General de Protección de Datos.

Asimismo se deberá tener en cuenta:

o Movimientos realizados por el responsable del tratamiento: Deberá cumplir los requi-sitos de seguridad establecidos en el título VIII del RLOPD.

29 Ver artículo 12 de la LOPD.30 Ver información actualizada en http://ec.europa.eu/justice/policies/privacy/thridcountries/index_en.htm



o Movimientos con participación de un encargado del tratamiento: Deberá cumplir los requisitos para la prestación de este tipo de servicios (artículo 12 LOPD y artículos 20 a 22 del RLOPD).

o Movimientos dentro de un grupo multinacional. Se puede hacer de dos maneras:

• Cumplir los requisitos para los encargados del tratamiento (artículo 12 LOPD y artículos 20 a 22 del RLOPD)

• Establecer unas ‘Binding Corporate Rules’ (BCR)31 que regulen los movimientos de datos.

• País sin un nivel adecuado de protección de datos En este caso, el movimiento transfronterizo de datos tiene los mismos requisitos de legi-timidad que el anterior y en todos los casos será necesario recabar la autorización de la autoridad competente, el Director de la Agencia Española de Protección de Datos, en el caso español (art. 70 del RLOPD). Asimismo, se deberá incluir la información so-bre la transferencia en la notificación al Registro General de Protección de Datos. Para que el Director conceda el permiso, deberá existir un contrato escrito entre el expor-tador y el importador en el que consten las necesarias garantías de respeto a la pro-tección de la vida privada de los afectados y a sus derechos y libertades fundamenta-les y se garantice el ejercicio de sus respectivos derechos. A tal efecto, se considerará que establecen las adecuadas garantías los contratos que se celebren de acuerdo con lo previsto en las Decisiones de la Comisión Europea sobre cláusulas contractuales32. Los grupos multinacionales pueden optar por el modelo general basado en contratos caso por caso o adoptar y conseguir la aprobación por la autoridad competente de unas normas o reglas internas (Binding Corporate Rules) en que consten las necesarias garantías de respeto a la protección de la vida privada y el derecho fundamental a la protección de datos de los afectados y se garantice el cumplimiento de la regulación sobre la materia.

4.6.3 Aspectos más relevantesEn general, la responsabilidad sobre el control de legalidad, en todos sus aspectos, respecto de las condi-ciones para legitimar las transferencias internacionales de datos recae en el cliente de servicios en la nube que será el responsable desde el punto de vista de la protección de datos personales y quien deberá tener en cuenta las consideraciones realizadas en el punto anterior.

31 Ver documentos wp153 y wp154 del Grupo del artículo 29 en http://ec.europa.eu/justice/policies/privacy/workinggroup/wpdocs/2011_en.htmo

32 - 2010/87/EC: Commission Decision of 5 February 2010 on standard contractual clauses for the transfer of personal data to processors established in third countries under Directive 95/46/EC of the European Parliament and of the Council

- 2004/915/EC: Commission Decision of 27 December 2004 amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to third countries

- 2001/497/EC: Commission Decision of 15 June 2001 on standard contractual clauses for the transfer of personal data to third countries, under Directive 95/46/EC



El responsable del fichero se ha de preocupar de conocer la ubicación territorial de los medios que va a emplear el proveedor de servicios en la nube para prestarle el servicio, en particular ha de conocer si el servicio se va a dar desde países con un nivel de protección adecuado o si, en algún caso, el servicio se puede dar desde países sin ese nivel. La regulación desde qué países se va a poder prestar el servicio ha de estar establecida contractualmente.

En función del modelo de servicio y del modelo de despliegue la responsabilidad, en particular en lo rela-tivo a la seguridad, se repartirá de forma diferente. Al poder estar el encargado del tratamiento fuera del territorio español se deberán establecer contractualmente las medidas de seguridad a aplicar, dado que no estaría sometido al RLOPD.

En todos los casos en que haya una transferencia internacional de datos, se deberán aplicar los requisi-tos legales identificados con independencia del modelo de servicio o despliegue. Lo que variará será la responsabilidad sobre la ejecución de las actividades y, en consecuencia, el contenido de los contratos o BCR que se establezcan.

4.6.3.1 Aspectos más relevantes por modelo de servicioMás allá de las medidas de seguridad y cómo se reparten entre el responsable (cliente) y el encargado de tratamiento de datos (proveedor de servicios en la nube), lo cual se recoge en el apartado 4.5 y que dependerá del modelo de servicios, en el caso de las transferencias internacionales no existen diferencias entre los modelos SPI, ya que la infraestructura subyacente puede cambiar de ubicación física sin control del responsable del tratamiento, haciendo necesario que este aspecto deba regularse específicamente para evitar generar transferencias internacionales de datos no controladas.

4.6.3.2 Aspectos más relevantes por modelo de despliegueEl modelo de despliegue tiene implicaciones en relación a quién realiza de forma efectiva el tratamiento y el control geográfico del mismo.

Nube privadaSi la nube privada es propiedad del responsable del tratamiento, se deben considerar dos aspectos:

• Ubicación geográfica: Si la nube no sale del EEE no tiene ningún requisito específico, pero si incluye países con un nivel de protección adecuada no pertenecientes al EEE, se han de consi-derar los requisitos de notificación. Si incluye terceros países, se ha de considerar la necesidad de obtener la autorización de la autoridad competente.

• Regulación de la nube: Si es un grupo multinacional, se deberá considerar el uso de BCR o de contratos casos por caso.

• Si la nube privada es operada por uno o varios encargados del tratamiento se ha de considerar: o Ubicación geográfica: Ídem que el caso anterior. o Regulación de cloud: Se ha establecer un contrato conforme a la regulación legal

estudiada previamente.

Nube PúblicaEn este caso, los requisitos son los mismos que en el caso de una nube privada operada por uno o varios encargados de tratamiento. No obstante, se ha de prestar especial atención a:



• Ubicación geográfica: Asegurar contractualmente que se conoce el espacio geográfico en que se tratan los datos para asegurar el cumplimiento de los requisitos correspondientes. En particu-lar, si se producen transferencias de datos a países terceros se deberá asegurar la conformidad del contenido del contrato.

• Regulación: Se ha establecer un contrato conforme a la regulación legal estudiada previamente.

Nube HíbridaHa de contemplar los requisitos de los dos casos anteriores.

4.6.4 Recomendaciones

4.6.4.1 Empresa proveedoraLa transferencia internacional de datos de carácter personal puede ser uno de los mayores inhibidores para la contratación de servicios en la nube, por ello, los proveedores de este tipo de servicio deberían establecer medidas que atenúen está problemática y faciliten la contratación de los servicios por parte de los clientes. Entre las medidas recomendables están:

• Ofrecer servicios en los que se pueda delimitar en qué países pueden estar los datos. Por ejem-plo, si se garantiza que los datos no van a salir del EEE, se facilita enormemente la contratación a las empresas europeas.

• Tener preparado modelos contractuales que cubran la casuística y requisitos de las transferen-cias internaciones de datos. En el caso de los datos de carácter personal, el uso de los modelos propuestos por la Comisión Europea facilita su adopción.

• El tener datos en terceros países dificulta el control por el responsable del fichero, por lo que es conveniente que el proveedor disponga de mecanismos para reforzar la confianza de éste con medios como auditorias de terceros.

4.6.4.2 Empresa clienteComo en toda relación con terceros, la empresa ha de evaluar primero qué datos va a poner en la nube y con qué propósito. Respecto a los datos, ha de considerar si incluyen datos de carácter personal, en cuyo caso le aplica la regulación descrita en este apartado, y si el tener datos en otro país le puede plantear problemas con la jurisdicción que aplica en dicho país.

Una vez conocido qué se quiere hacer y los requisitos regulatorios, se ha de buscar un proveedor que pueda satisfacerlos para lo cual hay diversas alternativas:

• El proveedor garantiza que los datos no salen de la EEE: En este caso la regulación es la misma que en el caso nacional. Esta garantía deberá estar recogida en el contrato.

• El proveedor garantiza que los datos no salen de países con un nivel de protección adecuada: Se deberá conocer qué países incluye para la declaración de ficheros, pero por lo demás, la regulación es igual que en caso nacional.



• Los datos van a países sin un nivel de protección adecuado: En este caso, el contrato que se establezca ha de cumplir los requisitos que demanda la legislación. A tal efecto, se considerará que establecen las adecuadas garantías, los contratos que se celebren de acuerdo con lo pre-visto en las Decisiones de la Comisión Europea comentadas anteriormente.

Los grupos multinacionales que gestionen su propia nube tienen dos alternativas:

• Optar por el modelo general basado en contratos caso por caso. Esta alternativa es más rápida pero se ha de establecer un nuevo contrato ante un nuevo tratamiento y si se incluye un país sin un nivel de protección adecuado, hay que recabar para el nuevo tratamiento la autorización del Director de la Agencia Española de Protección de Datos (AEPD).

• Adoptar y conseguir la aprobación por la autoridad competente de unas normas o reglas internas (Binding Corporate Rules) en que consten las necesarias garantías de respeto a la pro-tección de la vida privada y el derecho fundamental a la protección de datos de los afectados y se garantice el cumplimiento de la regulación sobre la materia. Esta alternativa es más lenta pero tiene la ventaja de que una vez aprobado, se pueden realizar nuevos tratamientos dentro de su marco sin tener que recabar de nuevo una autorización.

4.6.4.3 UsuariosLas personas afectadas por el tratamiento de sus datos se enfrentan a dos casos:

• Sus datos son tratados por una empresa española que subcontrata parte de sus servicios en la nube: De acuerdo con la LOPD, la empresa no está obligada a pedir permiso de ese tra-tamiento por terceros siempre que cumpla los requisitos exigidos para el uso de ‘encargados del tratamiento’. En este caso, es poco probable que conozca la existencia de la transferencia internacional y frente a él, toda la responsabilidad es del responsable del fichero.

• La persona contrata directamente unos servicios en la nube como pueda ser correo electrónico, almacenamiento de datos, capacidad computacional (IaaS) o cualquier otro. En este caso, la persona debería tener unas precauciones similares a una empresa usuaria con la diferencia que su capacidad negociadora va a ser muy reducida. Debería considerar:

o Qué datos va a transferir a la nube, qué sensibilidad tienen para él.

o Conocer las condiciones contractuales del proveedor en aspectos como confidencia-lidad, seguridad, resolución de conflictos, ubicación, etc. En algunos casos las condi-ciones pueden resultar abusivas.

o Conocer las opciones del servicio. Frecuentemente el servicio se puede configurar de forma voluntaria con unos mayores niveles de protección y privacidad.

o Ser prudente. Dependiendo de la ubicación geográfica del proveedor, puede ser difícil hacer cumplir los derechos legales y se puede tener indefensión.



4.7 Ejercicio de derechos

4.7.1 Descripción generalDar respuesta a las solicitudes de derechos de acceso, rectificación, cancelación u oposición (en adelante, conjun-tamente, derechos ARCO) es una obligación que corresponde a todo responsable del fichero o tratamiento.

El responsable del fichero o tratamiento de datos personales debe contestar en forma y plazo a todas las solicitudes de esta tipología que se interpongan o ejerciten ante él por parte de cualquier interesado (titular de los datos o persona que actúe en su representación o que acredite obrar por determinadas circunstan-cias y razones que legitimen dicha actuación).

4.7.2 Legislación aplicableLos apartados legislativos que habrán de tenerse en cuenta a la hora de estudiar la respuesta a un derecho ARCO a datos personales en la nube son los referentes a:

- La Sección IV denominada “información del interesado” (Artículos 10 y 11), la Sección V referi-da al “Derecho de acceso del interesado a los datos” (Artículo 12) y la Sección VI denominada “Excepciones y limitaciones” (Artículo 13), Sección VII relativa al “Derecho de oposición del interesado” (Artículos 14 y 15) de la Directiva 95/46/CE [Directiva 1995].

- El Título III relativo a “Derechos de las personas”, Artículos 13 al 19 de la LOPD.

- El Título I relativo a las “Disposiciones Generales” (Artículos 2 y 4) y el Título III relativo a los “Derechos de acceso, rectificación, cancelación y oposición” del RLOPD.

Teniendo en cuenta que la Directiva de Protección de Datos establece el derecho de los afectados y, por contra, la obligación de los responsables de ficheros con carácter genérico y las condiciones específicas para el ejercicio de los derechos se introducen directamente en la legislación de cada Estado miembro, a continuación se analizarán y tratarán directamente los preceptos establecidos en la legislación española.

4.7.3 Aspectos relevantes por modelo de servicio de la nubeAntes de analizar las particularidades de cada modelo de servicio en la nube, hay que tratar aquellos aspectos que son comunes a todos los modelos. En particular, ha de afirmarse que la responsabilidad so-bre el control de la legalidad, en todos sus aspectos, de cara a garantizar el ejercicio de los derechos de las personas recae en el cliente de servicios en la nube o responsable del fichero que será el responsable desde el punto de vista de la regulación de protección de datos personales y será quien deberá tener en cuenta las consideraciones realizadas en los apartados anteriores.

En base a lo anterior, el responsable del fichero o tratamiento deberá regular, en su relación con el pro-veedor de servicios en la nube o encargado del tratamiento, la posibilidad de que los afectados ejerciten sus derechos ante dicho encargado, el cual deberá dar traslado de la solicitud al responsable, salvo en los casos en que contractualmente se haya determinado que sea atendido por el encargado.

Asimismo, conviene plantearse la necesidad de que dicho proveedor de servicios comunique a su cliente (responsable del fichero) el ejercicio de un derecho en un plazo razonable de tiempo, recomendando que sea un plazo de tiempo cerrado, teniendo en cuenta la brevedad de los plazos de contestación al solici-tante impuestos en la normativa vigente.



En este mismo sentido, cabe señalar que corresponderá al responsable del fichero o tratamiento la prueba de cumplimiento del deber de respuesta al afectado que ejercita un derecho, por lo que deberán arbitrase los mecanismos necesarios para conservar la acreditación del cumplimiento mencionado.

En cualquier caso, es el cliente quien deberá, por sí mismo o dando las instrucciones precisas al proveedor de servicios en la nube, asegurarse de que el tratamiento de los datos en el servicio prestado permite la localización y acceso a los datos personales para dar respuesta al ejercicio de cualquier derecho por parte del afectado y quien tendrá que plasmar en el contrato de prestación de servicios y en el acuerdo del nivel de servicio, el clausulado y las condiciones precisas bajo las cuales el proveedor de servicios en la nube deberá posibilitar al responsable el cumplimiento normativo. En este último sentido, el proveedor de servicios en la nube deberá facilitar y/o ejecutar las acciones necesarias respecto del acceso a los datos personales de una determinada persona, su rectificación y/o cancelación o la marcación y gestión de la oposición a determinados tratamientos.

Por despliegue IaaS: En este modelo de despliegue, el responsable del fichero no gestiona ni controla la infraestructura de nube subyacente, pero tiene control sobre los sistemas operativos, almacenamiento, aplicaciones desplegadas y la posibilidad de tener un control limitado de componentes de red seleccionados.

Por ello, el responsable del fichero o del tratamiento de datos (cliente) no perderá la capacidad de dispo-sición sobre los datos personales incluidos en ficheros de su titularidad y, en consecuencia, lo único que deberá asegurar con el proveedor de servicios en la nube será poder localizar los datos personales sobre los que se ejercite algún derecho para, en su caso, tomar las acciones necesarias de cara a facilitar el acceso al solicitante, rectificación de sus datos o la cancelación de los mismos si así procede.

Por despliegue PaaS:En este tipo de despliegue de servicios en la nube, se utilizan las herramientas del proveedor para la programación de aplicaciones y servicios, por lo que, se tendrá que considerar que las plataformas con-tratadas deberán permitir la tutela efectiva de los derechos de los afectados.

Por tanto, quizá en este modelo de computación en la nube sí que sea necesario que el proveedor asuma obligaciones en cuanto a facilitar o permitir al responsable las acciones necesarias encaminadas a facilitar los derechos de los afectados.

Por despliegue SaaS: En este modelo, el proveedor de servicios en la nube tiene control sobre los datos personales de los que el cliente es responsable. El cliente se limita a externalizar los servicios en el proveedor que ejecutará el servicio en la nube.

Por lo tanto, en este modelo, el responsable del fichero o tratamiento (el cliente) deberá asegurar contrac-tualmente34 que, en caso de que se ejercite un derecho ante el cliente, el proveedor asuma la obligación como mediador necesario de comunicarle la información de la que dispone en relación al afectado o solicitante en el plazo de tiempo acordado que permita al cliente (responsable del fichero o tratamiento) el cumplimiento de su obligación y la contestación al peticionario, así como, la ejecución de cuantas accio-nes sean necesarias para dar un cumplimiento efectivo del derecho solicitado, esto es, facilitar el acceso

34 Los aspectos de contratación se pueden consultar en el Capítulo 7.



a los datos, su rectificación, la oposición al tratamiento con determinados fines o la cancelación de los mismos si el afectado así lo desea.

4.7.4 Aspectos relevantes por modelo de despliegue de la nubePor lo que respecta a las condiciones generales para el ejercicio de los derechos de las personas, no pare-ce haber ninguna diferencia en la aplicación de la normativa en función del tipo de despliegue en la nube, por cuanto que la satisfacción de los derechos de las personas son decisiones operativas, organizativas y/o jurídicas que solo dependen de la voluntad y decisión del responsable y no de los medios técnicos a través de los cuales se materializan.

En lo que sí puede influir el tipo de despliegue es en la relación entre el responsable y el encargado de tratamiento que lleve a cabo la gestión integral del servicio, ya que, en el caso de que la Organización recurra a un encargado de tratamiento (recurso opcional en el caso de nube privada y prácticamente in-evitable, en todo o en parte, en el resto de despliegues), deberá hacer constar en el contrato que se firme para regular la prestación del servicio, las medidas y acciones necesarias que habrán de adoptarse, en particular, para el ejercicio de los derechos o, en su caso, contemplar las cláusulas por las que el encar-gado asuma la satisfacción íntegra de los derechos ARCO, siempre por cuenta del responsable que es el garante último de su cumplimiento.

4.7.5 Posibles riesgos detectados a) Posibilidad de que el responsable del fichero o tratamiento reciba y procese una contestación

a una solicitud de derecho de rectificación o cancelación por parte de un interesado sin comu-nicar dicho ejercicio al proveedor de servicios en la nube (en un modelo de despliegue SaaS) y, consecuentemente, se produzca una incoherencia en las bases de datos que este último gestione.

b) Dificultad de ejecutar de manera eficiente un derecho de cancelación de imagen ejercitado por un usuario en una red social cuando las mismas se replican en diferentes servidores de sus proveedores de la nube (éstos no suelen cancelar las imágenes hasta que no realizan su-presiones automáticas de contenidos). Por tanto, mientras las imágenes no se cancelan por los proveedores de servicios en la nube, se puede seguir accediendo a la imagen a través del link cuando el mismo se introduzca en la barra del navegador, aunque no en un buscador.

c) Recopilación de datos por parte del proveedor de servicios en la nube respecto de los usuarios del servicio a través de registros que faciliten información comercial relativa a los usuarios. Este hecho podría constituir una vulneración de derechos en cuanto a recogida de datos adiciona-les a los informados en relación con el tratamiento de datos y/o posibilidad de uso no consen-tido (envíos comerciales o publicitarios, comercialización de las bases de datos a empresas de marketing on line, etc.)

4.7.6 Recomendaciones

4.7.6.1 Empresa proveedoraDado que la empresa proveedora de servicios en la nube se constituirá como encargada del tratamiento de los ficheros con datos personales que trate para llevar a cabo la prestación de servicios de su cliente (respon-sable del fichero), habrá de considerar las obligaciones establecidas en la normativa de protección de datos en relación con esta figura. Esto es, se deberá regularizar la prestación de los servicios en la nube a través de



un contrato que recoja los aspectos del Art. 12 de la LOPD relativo al acceso a datos por cuenta de terceros, así como, los relativos a los Arts. 20, 21 y 22 del RLOPD en caso de subcontratación de servicios.

Asimismo, en dicho contrato deberán quedar debidamente delimitadas las funciones y responsabilidades de cada figura en lo relativo a la recepción, gestión y resolución de un ejercicio de derechos ARCO ante cualquiera de las partes.

Quizá por las particularidades de la gestión de la computación en la nube o prestaciones añadidas a lo que es el objeto contractual, tales como, seguridad y reserva de la privacidad de los datos y colaboración con el responsable del fichero para la efectiva tutela de los derechos de los afectados, sea conveniente plantearse el establecimiento de tarifas especiales como un añadido a la prestación de servicios objeto de contratación.

4.7.6.2 Empresa clienteDado que la empresa que contrata soluciones de computación en la nube será la responsable de los fiche-ros con datos personales a los que accederá o tratará su proveedor de servicios en la nube (encargado del tratamiento), deberá regularizar la prestación de servicios que suscriba con este proveedor a través de un contrato de encargo de tratamiento, en el cual, queden debidamente delimitadas las funciones y responsabilidades de cada figura.

En este sentido, se recomienda, con carácter adicional a la regularización del encargo del tratamiento y los términos que regularán las posibles subcontrataciones de servicios, delimitar en las cláusulas contractuales, en particular, los siguientes aspectos relativos a la gestión de derechos ARCO:

• A quien corresponderá atender las solicitudes de derechos ARCO que se ejerciten por parte de los interesados.

• Procedimiento o vías y plazos para la comunicación entre las partes de la recepción de una solicitud de esta tipología.

• Viabilidad de la localización y acceso a los datos personales tratados.

• Obligaciones del proveedor de servicios relativas a facilitar los datos al responsable, rectificar-los y/o cancelarlos de conformidad con las indicaciones del responsable como mediador nece-sario para el cumplimiento de las obligaciones legales y la consecución de una tutela efectiva de los derechos de las personales tratados en ficheros de su titularidad.

• Obligaciones del proveedor en relación con la finalización del servicio, esto es, devolución y/o destrucción de los datos, así como, de las copias o réplicas de los mismos se hubieran realizado.

Adicionalmente, para los casos como el indicado relativo a la cancelación de imágenes, se habrá de con-siderar por parte del responsable de fichero esta circunstancia, así como cualquier otra particularidad que pueda suponer un obstáculo para la satisfacción de los derechos ejercidos por los posibles afectados.

Asimismo, para el supuesto de que se lleve a cabo la recogida de datos adicionales relativos a información comercial de los usuarios, así como, un posible uso no legítimo de los mismos, se recomienda incluir en



los términos del contrato la posibilidad de revisar el cumplimiento de las obligaciones relacionadas con la seguridad y privacidad a través de una auditoría del servicio prestado.

En caso de que el proveedor de servicios en la nube se oponga a la realización de una auditoría, por lo menos, intentar que facilite los resultados de una auditoría interna o externa en relación al cumplimiento de estos extremos.

En definitiva, será necesario que además de regular el acceso a datos personales por parte del proveedor como encargado del tratamiento, establecer en el acuerdo de nivel de servicios (ANSs), las obligaciones o buenas prácticas precisas para poder atender, gestionar y resolver los ejercicios de derechos ARCO de manera eficaz y conforme a derecho.

4.8 Autoridades de control

4.8.1 Descripción generalLa Directiva 95/46/CE considera35 que es esencial la existencia de una autoridad independiente de control en el contexto de la protección de datos de carácter personal, de ahí que el artículo 28 de la men-cionada Directiva obligue a los Estados miembros de la Unión Europea a crear, una o más autoridades públicas encargadas de vigilar la aplicación, en su territorio, de las disposiciones nacionales adoptadas en aplicación de la Directiva; debe tenerse en cuenta que en algún caso esas autoridades de control tam-bién deberán aplicar las legislaciones de otros estados del EEE36.

En el caso del Estado Español esa disposición nacional es la LOPD, que prevé la existencia de una au-toridad de control estatal, la Agencia Española de Protección de Datos, y da la posibilidad de que las comunidades autónomas creen, asimismo, otras autoridades de control.

La actividad de vigilancia del cumplimiento de las legislaciones nacionales en materia de protección de datos de carácter personal, que desarrollan las autoridades de control, se concreta en un conjunto de funciones que deben ser ejercidas con total independencia de poderes públicos o privados, y que pueden sintetizarse en las siguientes actividades:

• Atender las peticiones y reclamaciones realizadas por las personas afectadas.

• Resolver las reclamaciones de tutela de los derechos ARCO.

• Ejercer la potestad de inspección y sancionadora, así como, desarrollar actuaciones de control preventivo.

• Requerir a responsables y encargados de tratamiento para que adopten medidas de adecua-ción a lo previsto en la normativa, lo que incluye la posibilidad de ordenar el cese del trata-miento o incluso exigir la eliminación de los datos objeto de tratamiento.

35 Considerando 62 de la Directiva 95/46/CE: “Considerando que la creación de una autoridad de control que ejerza sus funciones con plena independencia en cada uno de los Estados miembros constituye un elemento esencial de la protección de las personas en lo que respecta al tratamiento de datos personales”

36 Se recomienda la lectura del apartado legislación aplicable del presente estudio, ya que resulta necesario y complementario al presente apartado.



• Responder a consultas, dictaminar, recomendar y dictar instrucciones que faciliten la adecua-ción de los tratamientos a lo previsto en la legislación.

• Otorgar las autorizaciones que prevea la normativa.

• Y velar por la publicidad de los tratamientos.

En relación a la computación en la nube, el análisis del papel de las autoridades de control tiene interés en relación a dos cuestiones:

a) La determinación de la jurisdicción o competencia para vigilar la adecuación de los tratamien-tos a la legislación aplicable, es decir, qué autoridad de control va a intervenir, por ejemplo, en el caso de una denuncia o de una tutela de derechos.

b) La ejecución efectiva de las resoluciones y decisiones adoptadas en relación a los tratamientos de los que son competentes o tiene jurisdicción una autoridad de control, es decir, una vez tomada la decisión en relación a la reclamación recibida, cómo se va a dar cumplimiento a lo que prevea la resolución, por ejemplo, el cobro de una multa o la inmovilización de un fichero o tratamiento.

Tal y como prevé el ya mencionado artículo 28 de la Directiva Europea de protección de datos personales, las autoridades de control se encargan de vigilar en su territorio las disposiciones nacionales adoptadas por sus respectivos estados en aplicación de la Directiva.

Aparece aquí un primer elemento de compleja resolución en un ambiente de computación en la nube al de-terminar que el ámbito de actuación de las autoridades de control viene definido por un criterio territorial, todo y que, ciertamente la Directiva ya prevé una cierta extraterritorialidad, en el sentido de que se dé la circunstancia de que sea necesario que una autoridad de control aplique más de una legislación nacional para, por ejemplo, resolver una reclamación37.

Uno de los aspectos esenciales de la computación en la nube es, precisamente, el uso dinámico de los recursos de tratamiento, ya sean de almacenamiento, de procesamiento, de comunicaciones, etc., de manera que en función de las necesidades del usuario el proveedor de los servicios en la nube ad-ministrará los recursos disponibles allá donde estén disponibles, superando las tradicionales barreras de espacio y tiempo, y en consecuencia donde el criterio de territorialidad no es relevante, dado que usualmente no estará predeterminado el lugar de procesamiento, aunque si que deberá ser determinable en algún momento.

La cuestión de cual es el ámbito competencial de las autoridades de control va unida, en general, a la determinación de la legislación aplicable (con la excepción ya descrita anteriormente), aspecto ya tratado en el apartado 4.3 de este informe, lo que va a incluir también las cuestiones relacionadas con las auto-rizaciones previstas en la normativa, especialmente las de transferencias internacionales, tratadas en el apartado 4.6 de este informe.

37 El Dictamen 8/2010 sobre Ley Aplicable del Grupo de Trabajo del Artículo 29 introduce la cuestión de que no siempre tienen porque coincidir la legislación aplicable con la competencia de los órganos de supervisión (autoridades de control).



Otra cuestión bien diferente tiene que ver con el hecho de cómo se van a resolver, una vez determinada la competencia de una concreta autoridad de control, en un caso específico, las siguientes cuestiones:

a) En primer lugar, qué mecanismos operativos va a seguir la autoridad de control para investigar y obtener datos e informaciones que le permitan determinar si se está produciendo una vulne-ración del derecho a la protección de datos de carácter personal, lo que la Directiva identifica como “poderes de investigación”.

b) Y en segundo lugar, y una vez tomada una decisión por parte de esa autoridad de control, cómo va a ser ejecutada o atendida esa resolución, que tal vez vaya dirigida a un prestador de servicios que tiene su establecimiento y/o medios de procesamiento en otro país, ya sea de fuera o de dentro de la Unión Europea, lo que la Directiva identifica como “poderes efectivos de intervención”38.

Las dos situaciones revelan dificultades para dar adecuada respuesta a la lesión al derecho fundamental a la protección de datos de carácter personal, por tanto de interés para las personas afectadas, pero tam-bién son relevantes para los responsables y encargados de tratamientos en la nube, que puedan llegar a tener que someterse a más de una autoridad de control, o a autoridades de control de otros estados, según los criterios de legislación aplicable que vayan a ser tenidos en cuenta.

La Directiva prevé que las autoridades de control atiendan las solicitudes que le lleguen de cualquier per-sona, sin tener en cuenta cuestiones como la nacionalidad o la ciudadanía, y asimismo las autoridades de control pueden ser instadas a ejercer sus poderes por una autoridad de control de otro Estado miembro.

En este punto, la cooperación y coordinación de las diferentes autoridades de control involucradas es clave, de manera que el rol y los límites de actuación de cada una de ellas sean claros, en este sentido el ya mencionado dictamen 8/2010 del Grupo del Artículo 29, pone de relieve la dificultad de la cuestión y la pospone para un estudio más profundo, en un documento específico en el que tratar esa cooperación y coordinación entre autoridades de control cuando concurre más de una, en un mismo asunto.

Destacar, por último, que el hecho de que, según la Directiva, deban proveerse mecanismos de revisión judicial de las resoluciones de las autoridades de control, hace muy relevante quien sea la autoridad de control competente, ya que eso determinará los tribunales a los cuales recurrir sus decisiones.

4.8.2 Aspectos más relevantes Lo cierto es que ni los diferentes modelos de servicio, ni las diferentes posibilidades de despliegue van a ser relevantes en el análisis de esta cuestión.

Una vez determinada la competencia de una autoridad de control, que el servicio en la nube sea de SaaS, PaaS o IaaS, no va a añadir aspectos diferenciales a la intervención de la autoridad.

En la práctica, la actual arquitectura competencial llevará a que la decisión de la persona afectada vaya a ser determinante de cual va a ser la autoridad de control que vaya a actuar de manera principal.

38 El artículo 28.3 de la Directiva describe los poderes de que debe disponer una autoridad de control creada conforme a la Directiva.



Efectivamente, aquella autoridad a la cual se dirija la persona afectada en caso de que considere su de-recho lesionado, o en general, para solicitar la intervención de una autoridad de control que proteja su derecho a la protección de datos, va a ser la competente para resolver, al menos en un primer momento, ya que va a tener posibilidad de actuar con independencia de la legislación aplicable.

4.8.3 Legislación aplicableCon carácter general se deberá tener en cuenta lo previsto en el ya mencionado artículo 28 de la Directiva y las cuestiones relacionadas con el ámbito de aplicación de la LOPD39.

En cuanto a las funciones y competencias de la Agencia Española de Protección de Datos se estará a lo previsto en el título VI de la LOPD, y en cuanto a los procedimientos tramitados por esta, a lo previsto en el título IX del RLOPD.

Los procedimientos, relevantes para computación en la nube, tramitados por la Agencia Española de Protección de Datos son:

a) Tutela de derechos ARCO (artículos 117 a 119 del RLOPD).

b) Ejercicio de la potestad sancionadora (artículos 120 a 129 del RLOPD).

c) Inscripción o cancelación de ficheros (artículos 130 a 136 del RLOPD).

d) Transferencias internacionales de datos (artículos 137 a 144 del RLOPD).

e) Exención del derecho de información al interesado (artículos 153 a 156 del RLOPD).

f) Autorización de conservación de datos para fines históricos, estadísticos o científicos (artículos 157 y 158 del RLOPD).

En el estado español existen tres autoridades de control autonómicas, que con mínimas diferencias, desa-rrollan funciones equivalentes; por orden de creación:

a) La Agencia de Protección de Datos de la Comunidad de Madrid, regulada por la Ley 8/2001, de 13 de julio, de Protección de Datos de Carácter Personal en la Comunidad de Madrid.

b) La Autoridad Catalana de Protección de Datos, creada como agencia de protección de datos por la Ley 5/2002, de 19 de abril, que ha sido derogada por la Ley 32/2010, de 1 de octu-bre, que crea y regula la Autoridad Catalana de Protección de Datos.

c) La Agencia Vasca de Protección de Datos, regulada por la Ley 2/2004, de 25 de febrero, de Ficheros de Datos de Carácter Personal de Titularidad Pública y de Creación de la Agencia Vasca de Protección de Datos.

39 Como ya se ha dicho tratadas en un apartado específico de este estudio: “Legislación aplicable”.



4.8.4 RecomendacionesLas recomendaciones incluidas en este apartado se centran en situaciones de servicios en la nube donde se dé la “pluri-territorialidad”, a la vez que existe un tercero que trata datos por cuenta ajena (encargado de tratamiento40), ya que en el caso de que el proveedor de servicios en la nube y la empresa cliente estén establecidas en el mismo territorio, el hecho de que se utilicen servicios basados en el paradigma de com-putación en la nube no aporta ningún diferencial, en relación a la aplicación de la legislación en materia de protección de datos de carácter personal respecto de situaciones donde no se utilicen.

Ya se ha hecho referencia al uso de criterios territoriales para la determinación de la legislación aplicable, y por tanto para la concreción de la autoridad de control competente, pero debe tenerse en cuenta que la futura revisión de la Directiva Europea de protección de datos con toda seguridad tendrá en cuenta para-digmas como el de computación en la nube, haciendo hincapié en la cuestión de las normas aplicables y de la competencia de las autoridades de control, ya que el criterio territorial en relación a los medios utilizados para la prestación de los servicios no es suficiente para dar respuesta a todas las casuísticas, y por tanto van a tener que entrar en juego otros criterios para determinar la competencia de las autoridades de control, como por ejemplo, el de la audiencia a la que van dirigidos los servicios, de manera que podrá darse el caso de que sin existir ningún vinculo territorial, al menos en cuanto al procesamiento principal, una autoridad de control vaya a poder ser competente para resolver.

Las recomendaciones incluidas a continuación se basan en la regulación vigente en el estado español en el momento de la publicación de este informe.

4.8.4.1 Empresa proveedoraDeberá tener en cuenta que, en todo caso, deberá cumplir con lo previsto en el título VIII del RLOPD, es decir, por el mero hecho de ser un encargado de tratamiento ubicado en España, aunque los datos tratados sean de un responsable no establecido en territorio español, le serán de aplicación las medidas de seguridad pre-vista en el reglamento que desarrolla la LOPD (segundo párrafo del artículo 3.1.a del RLOPD), por tanto, la autoridad de control que sea competente en aplicación de los criterios de reparto competencial previstos a la LOPD y normativas autonómicas, se podrá dirigir a la empresa proveedora, en el ejercicio de los poderes y funciones que les atribuye el ordenamiento jurídico, y esta deberá darle respuesta en relación a la seguridad de los datos, con independencia de la legislación aplicable con carácter general a los datos tratados.

Obviamente, si además, la legislación aplicable al tratamiento es la española, también estarán sujetos al resto de obligaciones que puedan derivarse, y por tanto deberá atender los requerimientos de información u otras intervenciones ordenadas por la autoridad de control del estado español que sea competente.

También deberá tener en cuenta que, en aplicación de la Directiva, pueden recibir solicitudes de informa-ción y requerimientos de autoridades de control de otros Estados miembros, o recibirlos de las autoridades del estado español a solicitud, y con destino, a autoridades de control de los Estados miembros.

4.8.4.2 Empresa clienteDeberá comunicar al encargado de tratamiento (empresa proveedora de servicios en la nube) qué legisla-ción de protección de datos es aplicable a los tratamientos que realizará por cuenta suya, y a ser posible comunicará también que autoridades de control son competentes para vigilar el cumplimiento de la norma-tiva aplicable a los tratamientos objeto de encargo.

40 Remitimos al lector a la parte de este estudio que aborda en detalle la cuestión de los encargados de tratamiento, apartado 4.4.



Deberá tener conocimiento de qué obligaciones tiene la empresa proveedora en relación a la legislación de protección de datos aplicable en el territorio, o territorios, donde se procese, o se tenga previsto proce-sar, la información que, en razón del encargo de tratamiento que le ha contratado, ha sido comunicada a la empresa proveedora de servicios en la nube.

Deberá comunicar a los usuarios, al menos de manera colectiva, mediante políticas de privacidad globa-les u otros mecanismos equivalentes, cual es la autoridad de control a la que deben dirigirse, en caso de que consideren vulnerado su derecho a la protección de datos de carácter personal en el contexto de los tratamientos de los que es responsable.

4.8.4.3 UsuariosAunque, en principio, se ha excluido de este estudio el caso en el que los usuarios finales contratan direc-tamente con los proveedores de servicios en la nube, conviene poner de relevancia la conveniencia de que los usuarios finales, y por tanto personas afectadas por el tratamiento de sus datos personales, antes de contratar, se informen de cual es la autoridad, o autoridades, de control competentes para resolver posibles incidentes con su derecho a la protección de datos de carácter personal, de manera que puedan valorar si sus reclamaciones, especialmente, podrán ser convenientemente investigadas y las resoluciones de la autoridad de control podrán ser eficazmente ejecutadas.

4.9 Comunicación de datos a otras autoridades

4.9.1 Descripción generalEn este apartado se van a analizar aquellas situaciones en las que las autoridades competentes soliciten información de carácter personal gestionada por un proveedor de servicios en la nube.

Se contemplan en este estudio todas aquellas comunicaciones que impone una ley aplicable a un servicio en la nube. A modo de ejemplo, en el caso español, podemos mencionar:

• Ley General Tributaria. • Ley de Enjuiciamiento Civil. • Ley de Enjuiciamiento Criminal. • Ley General de la Seguridad Social.

Principalmente, nos centraremos en aquellas situaciones en las que el proveedor de servicios en la nube no se encuentra en España y se solicita el acceso a los datos por parte de policía u organismos análogos a los señalados en los puntos anteriores en el país donde resida dicho proveedor.

4.9.2 Legislación aplicableComo se indica en el punto 4.3 del presente estudio (Legislación Aplicable): el concepto clave para la determinación de la legislación aplicable es el de la ubicación del establecimiento del responsable del tratamiento en conjunción con las actividades de tratamiento que se llevan a cabo.

Si el proveedor de servicios en la nube se encuentra en España, la regulación que aplica es la siguiente:

• Artículo 23 de la LOPD, Excepciones a los derechos de acceso, rectificación y cancelación. • Artículo 24 de la LOPD, Otras excepciones a los derechos de los afectados.



Si el proveedor opera en uno de los 27 estados miembros de la Unión Europea y los tres países miem-bros del espacio EEE, las condiciones de comunicación de datos a otras autoridades están reguladas en el artículo 13 de la Directiva 95/46/CE “Excepciones y Limitaciones” [Directiva, 1995] en el que se establece que los Estados miembros podrán limitar la aplicación de determinadas disposiciones de la Directiva en materia de seguridad nacional y pública o el enjuiciamiento y la prevención del crimen.

Así, en función de la legislación local en un Estado miembro, en determinadas circunstancias algunos datos que manejen los proveedores pueden no estar sujetos a todas las normas establecidas en la Directiva. Los ejemplos para aplicar tal limitación se aplican cuando constituya una medida necesaria para la salva-guardia de la seguridad del Estado, la defensa, la seguridad pública, la prevención, la investigación, la detección y la represión de infracciones penales o de las infracciones de la deontología en las profesiones reglamentadas, un interés económico y financiero importante de un Estado miembro o de la Unión Euro-pea, incluidos los asuntos monetarios, presupuestarios y fiscales, etc.

Dependiendo del Estado miembro concreto donde operase el proveedor de servicios en la nube, aplicaría la legislación que el Estado miembro haya aprobado al transponer la Directiva.

Si el proveedor de servicios en la nube opera en un país distinto a los referidos anteriormente, habrá que considerar la normativa aplicable en dicho país a tal efecto. En el presente estudio no se hace referencia a otra legislación que no sean las referidas Directiva 95/46/CE, LOPD y RLOPD.

4.9.3 Aspectos más relevantes En general, la responsabilidad sobre el control de legalidad, en todos sus aspectos, respecto de las condi-ciones para que una autoridad pueda solicitar ciertos datos al proveedor de servicios en la nube recae en el responsable del fichero. Éste se ha de preocupar de conocer la ubicación territorial de los medios que va a emplear dicho proveedor para prestarle el servicio, en particular, ha de conocer si el servicio se va a dar desde España, desde países del espacio EEE o fuera de los dos casos anteriores.

En función del modelo de servicio y del modelo de despliegue, la responsabilidad, en particular en lo relativo a la seguridad, se repartirá de forma diferente.

Al poder estar el encargado del tratamiento fuera del territorio español se deberán establecer contractual-mente las condiciones a aplicar dado que no estaría sometido al RLOPD.

4.9.3.1 Aspectos más relevantes por modelo de servicioEn este caso, no existen diferencias por el tipo de servicio utilizado (SaaS, PaaS o IaaS). Dado que los elementos que dan servicio pueden cambiar de ubicación física sin control del responsable del tratamiento, este aspecto deberá regularse específicamente para que, en este caso el cliente (responsable del fichero), tenga información de qué autoridad puede solicitar sus datos en caso de estar amparado por la normativa vigente en el país donde opera dicho proveedor de computación en la nube.

4.9.3.2 Aspectos más relevantes por modelo de despliegueSi bien el modelo de despliegue tiene implicaciones en relación a quién realiza de forma efectiva el trata-miento y el control geográfico del mismo (privado, público o híbrido), en el caso que nos ocupa, no tiene especial relevancia.



4.9.4 RecomendacionesEs importante destacar que si no se informa adecuadamente en el contrato, un proveedor de servicios en la nube puede conocer muy poco acerca de la información que el cliente está confiando en él. Esta situación puede provocar que, ante un requerimiento de información personal por parte de autoridades competen-tes, el proveedor no sea consciente de la información que gestiona y puede que no sea capaz de generar el aviso adecuado al cliente para que éste sea consciente de la situación.

Como se ha indicado en otras situaciones en este estudio (transferencia de datos, por ejemplo) es muy im-portante reflejar en el contrato que se van a confiar datos personales del cliente al proveedor de servicios en la nube.

4.9.4.1 Empresa proveedoraComo se ha indicado en los puntos anteriores, la ubicación geográfica del responsable del tratamiento es clave a la hora de saber qué autoridad puede solicitar información de carácter personal.Por lo tanto, las medidas recomendables para los proveedores de servicios son:

• Plasmar de forma clara en los contratos41 en qué países pueden estar los datos.

• Incluir en los contratos referencias a la normativa aplicable en los casos en que el proveedor se encuentre ubicado en España (LOPD y RLOPD), en países miembros del espacio EEE (Directiva Europea 95/46/CE o normativa local transpuesta) o en terceros países.

4.9.4.2 Empresa clienteComo en toda relación con terceros, la empresa ha de evaluar primero qué datos va a llevar a la nube y con qué propósito. Respecto a los datos, ha de considerar si incluyen datos de carácter personal, en cuyo caso aplica la regulación descrita en este apartado, y si el tener datos en otro país le puede plantear problemas con la jurisdicción que aplica en dicho país.

Una vez conocido qué se quiere hacer y los requisitos regulatorios se ha de buscar un proveedor que pueda satisfacerlos para lo cual hay diversas alternativas:

• El proveedor garantiza que los datos se encuentran en España o en países miembros de la EEE: La regulación es la misma que en el caso nacional. Esta garantía deberá estar recogida en el contrato.

• Los datos van a estar en terceros países: El contrato que se establezca ha de cumplir los requi-sitos que demanda la legislación.

4.9.4.3 Usuarios En caso de que los datos personales del usuario sean reclamados por una autoridad competente al pro-veedor de servicios en la nube, se debería pedir a éste que informase al usuario de que sus datos han sido requeridos e informados a la correspondiente autoridad.

Ya que esta situación se puede producir independientemente del país en que opere el proveedor, y éste ha de cumplir el requerimiento de la autoridad correspondiente, el usuario debería considerar:

41 Los aspectos relacionados con los contratos se analizan detalladamente en el Capítulo 7.



• Conocer, a través del contrato, la ubicación geográfica del proveedor. Esta información le ayuda-rá a saber de antemano qué autoridades pueden reclamar los datos gestionados en la nube.

• Qué datos va a transferir a la nube, qué sensibilidad tienen para él.

4.10 Conclusiones

En este capítulo, se analizan los principales aspectos relativos al cumplimiento con lo establecido en la Directiva 95/46/CE, LOPD y RLOPD y que conciernen a empresas proveedoras de soluciones de compu-tación en la nube, a empresas que contratan dichas soluciones y en algunas situaciones, a los usuarios o personas afectadas por el tratamiento de sus datos personales.

Se ha analizado la legislación aplicable, donde hemos comprobado que para su identificación, se deberá tener en cuenta principalmente dónde está establecido el responsable de seguridad; Los responsables del tratamiento que estén establecidos en un estado miembro del EEE tendrán en cuenta su ubicación, las actividades que desempeñan y dónde realizan el tratamiento de los datos para cumplir con las obligaciones previstas por el Derecho nacional aplicable. En caso de que responsable y encargado no estén ubicados en el mismo estado, el encargado del tratamiento deberá cumplir las normativas de la Ley del Estado donde está establecido el responsable y las medidas de seguridad del Estado donde esté dicho encargado, prevaleciendo estas últimas en caso de conflicto. En un segundo caso en el que el responsable no esté establecido en el EEE, pero su proveedor utilice para el tratamiento de datos personales medios o equipos situados en el mismo, exportará automáticamente la aplicabilidad de los requisitos de la legisla-ción de protección de datos del país del que se trate y deberá designar (salvo que el medio usado sólo sea de tránsito) un responsable representante miembro de la EEE.

En lo relativo a las transferencias internacionales, se destaca la existencia de una regulación espe-cífica debido al carácter transnacional de la computación en la nube. Como aclaración de este punto, se pasa a estudiar dos casos identificados: movimiento de datos transfronterizo por el encargado sin co-municación de datos a un tercero y un segundo caso, en el que los datos son comunicados debido a una necesidad del servicio. En ninguno de los casos será necesario el permiso del interesado.

Un aspecto clave de este punto será el análisis de la transferencia a:

• Un país de la UE, EEE o con un nivel adecuado de protección (reconocidos por la Comisión Europea).

• Un país sin un nivel adecuado de protección. En este caso debe ser autorizado por el Director de la AEPD.

Se describen también las actividades y funciones de las Autoridades de Control, como autoridades pú-blicas independientes encargadas de vigilar la aplicación en su territorio de las disposiciones nacionales adoptadas en aplicación a la Directiva 95/46/CE en los estados miembros de la UE y la importancia de definir claramente su competencia y ámbito ya que los afectados pueden tener que someterse a más de una autoridad de control o a autoridades de otros estados, siendo a veces necesario que estas autoridades co-operen y se coordinen en un mismo asunto. También se han analizado las comunicaciones de datos a otras autoridades en situaciones en las que el proveedor no está ubicado en España y se solicita el acceso a los datos por parte de la policía u organismos análogos en el país donde reside el proveedor.



En lo relativo a las responsabilidades del proveedor de servicios en la nube como encar-gado del tratamiento, se pueden resaltar los siguientes puntos:

• Tendrá en cuenta la tipología de la nube (publica, privada, comunitaria o híbrida) y el tipo servicio contratado por el responsable.

• En caso de que se subcontraten servicios a un subencargado, tiene la obligación de incluir este hecho en el contrato con el cliente, detallando el servicio subcontratado y sobre el que el cliente establecerá las instrucciones que considere oportunas.

• Es responsable de proporcionar los controles de medidas que exige la normativa en base al servicio contratado.

• La responsabilidad en el tratamiento de datos desde un punto de vista del ciclo de vida de la información (creación, almacenamiento, uso, compartición o comunicación, archivo, cancela-ción) se relacionará con el tipo de servicio contratado, ya que el tipo de servicio indicará el grado de responsabilidad que le afecta.

• Adoptará las medidas de seguridad en función del modelo de nube (IaaS, SaaS o PaaS) y deberá cumplir con las medidas de seguridad aplicables a los datos de carácter personal en lo relativo a:

o Documento de Seguridad o Control de Acceso e Identificación o Gestión de Incidencias o Copias de Seguridad y Recuperación o Auditorias o elecomunicaciones

• Atenderá el ejercicio de los derechos ARCO si está establecido por contrato. En caso contrario, si los recibiera, deberá hacerlos llegar lo antes posible al responsable (en plazo razonable y cumpliendo con los tiempos establecidos).

• Tendrá en cuenta que la deslocalización puede ser un inhibidor para contratar sus servicios, por lo que debería establecer medidas que atenúen los problemas, por ejemplo, delimitando los países donde pueden estar los datos, ofreciendo modelos de contratos que contemplen la situación o añadiendo mecanismos que refuercen la confianza del cliente.



En lo relativo a las responsabilidades del cliente como responsable del fichero, se pueden resaltar los siguientes puntos:

• Deberá vigilar el cumplimiento de las obligaciones del proveedor o encargado en materia de protección de datos, obligándole a tener una diligencia apropiada. Fijará por contrato temas relacionados con las normativas aplicables, condiciones y garantías de la seguridad de los datos que impidan el acceso a terceros no autorizados, lista de países donde se permite la prestación del servicio, información que se confía al proveedor, sensibilidad, propósito, etc.

• Como propietario de la información, debe analizar los riesgos sobre el ciclo de vida de la infor-mación (creación, almacenamiento, uso, compartición o comunicación, archivo, cancelación) y los activos que lo contienen y gestionan.

• Debe tener en cuenta la necesidad de hacer auditorias internas y externas de cumplimiento, por lo que incluirá estos términos en los contratos como cláusulas de derecho a auditar.

• Es responsable de que se cumplan los controles, que variarán en función del modelo de nube (IaaS, SaaS o PaaS) y el tamaño de la organización y deberá cumplir con las medidas de seguridad aplicables a los datos de carácter personal en lo relativo a:

o Documento de Seguridad o Responsable de seguridad o Control de Acceso e Identificación o Gestión de Incidencias o Copias de Seguridad y Recuperación o Auditorias o Telecomunicaciones

• Atenderá el ejercicio de los derechos ARCO salvo que, por contrato, se determine que sea el encargado.



5.1 Introducción

Como se ha comentado ya en varias ocasiones, la computación en la nube permite a los usuarios y/o clientes almacenar toda la información necesaria en servidores de terceros, de forma que puedan ser ac-cesibles desde cualquier terminal que posea acceso a Internet sin la necesidad, por lo general, de instalar un software adicional.

Este modelo de gestión totalmente dinámico, requiere que se haga hincapié y se preste especial atención, además de a cuantas cuestiones se han abordado específicamente respecto de la protección de datos de carácter personal42, a la seguridad de la información implicada, y ello, teniendo en cuenta que, con dicho sistema, se facilita el acceso a toda la información, documentos y datos que, hasta ahora, se encontraban almacenados en un equipo o servidor local a un proveedor de servicios (excepto en los casos de nubes privadas operadas por la propia organización).

El modelo de computación en la nube se basa en la gestión remota, normalmente por parte de un tercero, de la información que los usuarios le han transmitido previamente. Todo ello conlleva que, por parte de los destinatarios de servicios en la nube, se vuelque gran cantidad de información relevante, tanto de carácter personal como de negocio, a servidores de terceros. Por supuesto, las consecuencias jurídicas de seme-jantes prácticas son de diverso tipo, como lo son las disposiciones normativas a tener en cuenta y entre las que destacan de manera principal las que someramente se analizan a continuación.

Hoy en día, y debido precisamente a la gestión remota que se realiza de esa información, casi toda la tecnología existente en el modelo de computación en la nube se basa en la utilización de navegadores de Internet, los cuales -progresivamente- se han ido mejorando con funcionalidades entre las que se encuen-tran fórmulas de aceptación de plug-ins, máquinas de ejecución de código,etc. que posibilitan a los usua-rios, no solamente realizar una navegación clásica por Internet, sino que también permiten la ejecución de aplicaciones en su sentido más extenso desde el modelo de computación en la nube. En este sentido, podemos llegar a vislumbrar que en el futuro puedan generarse litigios entre las diversas empresas que in-tervienen en la prestación de servicios informáticos bajo este modelo debido a una pretendida vulneración de la legislación en materia de propiedad intelectual e industrial.

5.2 Contenido del capítuloEste capítulo se ha organizado entorno a la legislación aplicable en España para los servicios de com-putación en la nube, aparte de la ya analizada en el Capítulo 4 en materia de protección de datos de carácter personal.

Cumplimiento con otras legislaciones

42 Ver Capítulo 4 previo.



De esta forma, este capítulo cuenta con apartados dedicados al análisis concreto de las siguientes nor-mas:

•Anteproyecto de Ley de modificación de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones.

•Ley 11/2007, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos.

•Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y Comercio Elec-trónico.

•Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal.

•Aspectos Jurídicos Laborales

En cada uno de estos apartados, se incluyen las reflexiones y recomendaciones relevantes por lo que no existe un apartado de conclusiones o recomendaciones generales general en este capítulo.

5.3 Anteproyecto de Ley de modificación de la Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones

La Ley 32/2003 General de Telecomunicaciones vela por el cumplimiento de las obligaciones relacionadas en materia de secreto de las comunicaciones y protección de datos personales, así como de los derechos y obligaciones de carácter público vinculados con las redes y servicios de comunicaciones electrónicas, mediante la imposición de las correspondientes sanciones en el caso de un eventual incumplimiento.

Con motivo de la transposición al ordenamiento jurídico nacional del denominado Paquete de Directivas Telecom de 2009, el Ministerio de Industria, Turismo y Comercio ha elaborado un Anteproyecto de Ley de modificación de la actualmente vigente Ley 32/2003, que deberá dar lugar a la nueva Ley General reguladora del sector de las telecomunicaciones antes del próximo 25 de mayo de 2011.

A falta de la aprobación del Anteproyecto y posterior implantación del texto definitivo, todo apunta a que la nueva norma dará lugar a la incorporación a nuestro ordenamiento de una serie de disposiciones que afectan de manera muy directa a los prestadores de servicios de computación en la nube.

Así, una presumible incorporación de lo ya establecido en el Considerando (6) de la denominada Direc-tiva Acceso43 respecto del concepto de acceso a las redes de comunicaciones electrónicas, incluyendo los “servicios asociados” (otorgando tal calificación a cualesquiera servicios que apoyen el suministro de servicios de comunicaciones electrónicas o tengan potencial para ello) tendría inevitables consecuencias, entre otros, para los prestadores de servicios en la nube.

En este sentido, frente al concepto de acceso a redes generalmente reconocido a los operadores de co-municaciones electrónicas, conviene tener presente que las condiciones y obligaciones que la regulación

43 Directiva 2002/19/CE del Parlamento Europeo y del Consejo, de 7 de marzo de 2002, relativa al acceso a las redes de comunicaciones electrónicas y recursos asociados, y a su interconexión (Directiva de acceso) [Diario Oficial L 108 de 24.04.2002].



impone están encaminadas a garantizar el acceso de los usuarios finales a cualquier servicio soportado por una red o servicio de comunicaciones electrónicas. A este respecto, debe tenerse en cuenta que po-drían producirse conflictos de acceso, no sólo entre operadores de telecomunicaciones, sino también entre éstos y otras entidades que carezcan de tal naturaleza pero que proporcionen servicios de la sociedad de la información (como es el caso de los prestadores de servicios en la nube) o de contenidos a los usuarios finales y necesiten de funcionalidades o recursos asociados para la efectiva prestación de un servicio de calidad y con unas prestaciones determinadas.

La principal consecuencia de lo anterior no es otra que, con toda probabilidad, el texto de la aún por llegar Ley General de Telecomunicaciones contemplará la posibilidad de que la Comisión del Mercado de las Telecomuni-caciones vea ampliado su marco de actuación, pudiendo intervenir en la resolución de conflictos que pudieran surgir –a modo de ejemplo- entre prestadores de servicios en la nube y operadores de telecomunicaciones.

Todo lo anterior, con el objetivo último de preservar los derechos de los clientes finales de las empresas de computación en la nube a una prestación con garantías y en condiciones de idoneidad de los servi-cios contratados con éstas. Estableciendo un sencillo paralelismo: Del mismo modo que se benefician los usuarios de telecomunicaciones de la intervención en el mercado del órgano regulador, es previsible que se puedan beneficiar (en términos de calidad del servicio) los clientes de las empresas de servicios en la nube, en caso de producirse la reforma referida en los términos expuestos.

5.4 Ley 11/2007, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos

La Ley 11/2007, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos supone un importante reto para las administraciones públicas si desean estar en condiciones de poder cumplir los requisitos de acceso electrónico de los ciudadanos a la Administración. El modelo de computación en la nube constituye una alternativa económica y viable para mejorar los servicios públicos que las administraciones prestan a los ciudadanos, a la vez que permiten tanto una mejora de la operativa funcionarial interna como de sus relaciones electrónicas con otras administraciones.

Los sistemas informáticos que se implanten siguiendo el modelo de computación en la nube con la finali-dad de dar cumplimiento a esta ley, deben centrarse en potenciar los sistemas de gestión de las Entidades Públicas y en optimizar la actividad de los funcionarios y mejorando la atención al ciudadano, en todo lo referente a la gestión de procesos, la gestión económica y presupuestaria, la gestión de la población y del territorio y a los sistemas de acceso a información y de fomento de la interoperabilidad, el establecimiento de portales de atención al ciudadano a través de Internet y la creación de Intranets.

5.5 Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y Comercio Electrónico

La prestación de servicios denominados de la Sociedad de la Información –entre los que, sin duda, se cuentan los servicios de computación en la nube- no requiere, de conformidad con el artículo 6 de la Ley de Servicios de la Sociedad de la Información y del Comercio Electrónico (en adelante denominada, LSSI), autorización previa alguna, encontrando este supuesto su única excepción en los casos de prestación de servicios relacionados con materias reguladas cuya normativa específica así lo requiera. Sin embargo, estos proveedores de servicios sí deberán comunicar al Registro Mercantil en que se hallaran inscritos, al menos, un nombre de dominio o dirección de Internet desde el que prestarán sus servicios con el fin de permitir su identificación.



Tomando en consideración que los prestadores de servicios en la nube disponen, por lo general (como no puede ser de otra manera, teniendo en cuenta el ámbito en que prestan sus servicios) de un sitio web a tra-vés del que establecen la relación con sus clientes, quedan obligados, de conformidad con lo establecido en el artículo 10 de la LSSI, a suministrar a los destinatarios y a los órganos que resultaran competentes, determinada información. Entre otros datos, deberán hacerse accesibles aquellos que permitan estable-cer con él lo que el citado texto normativo denomina “una comunicación directa y efectiva” (a saber, su denominación y domicilio social o, en su caso, la dirección de uno de sus establecimientos permanentes en España). Además, en caso de que se ofrecieran servicios o productos, información precisa acerca de los mismos y sus precios y gastos de envío si procediera (con el detalle de los impuestos que resultaran de aplicación si fuera pertinente).

Dicha información –establece la propia LSSI- deberá proporcionarse de manera claramente visible e iden-tificable, siendo preceptivo que resulte accesible por medios electrónicos. En este sentido, se tiene por debidamente cumplida tal obligación, en aquellos supuestos en que el prestador del servicio en cuestión facilite la citada información en su sitio de Internet respetando los ya aludidos requisitos de visibilidad y accesibilidad con que en todo caso se deben ofrecer.

Adicionalmente a cuantas obligaciones resulten de aplicación, la prestación de servicios de la Sociedad de la Información que realizan las empresas de computación en la nube queda sometida a un régimen de responsabilidades que variará en función del tipo de servicio prestado. De manera general, puede hacerse referencia a las responsabilidades inherentes a cualquier prestador de servicios en la nube (sin perjuicio de que algunas otras de las contenidas en el texto de la LSSI lo sean para unos y no para otros en virtud de las actividades que lleven a cabo): La responsabilidad que tendrán como prestadores de servicios de alojamiento o almacenamiento de datos44. Hasta tal punto alcanza tal responsabilidad que las empresas de computación en la nube, devendrán en responsables de la información de terceros almacenada, en tanto en cuanto, tengan conocimiento efectivo de que la misma resulte ilícita o de algún modo lesiva y no actúen con la diligencia debida para evitar el acceso a la misma o para proceder a su retirada.

De alguna manera, puede entenderse que este régimen de responsabilidad de las empresas proveedoras de servicios en la nube, a menudo comportará la adopción de las medidas pertinentes por parte de las mismas para evitar tener acceso a la información de terceros que almacenen. Evitando el conocimiento efectivo, estarían eludiendo responsabilidades sobre el mismo, lo que, al tiempo, supondría una ventaja en relación con la seguridad para el propio destinatario de sus servicios.

Conviene aquí señalar que la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información introduce una modificación a la Ley 34/2002, por lo que en su art.12.2 bis establece las obligaciones que deben cumplir los prestadores de servicios de la sociedad de la información en rela-ción con la información que deben facilitar sobre las medidas de seguridad que deben implantarse ante posibles amenazas.

44 Entre otras, podrían resultar objeto de análisis las posibles responsabilidades de los prestadores de servicios en la nube con motivo de la realización de copias temporales de datos de los usuarios o del hecho de que pudieran facilitar enlaces a contenidos o instrumentos de búsqueda. Si bien estas responsabilidades concretas no parecen dirigidas a empresas de computación en la nube, el modo en que éstas prestaran sus servicios podrían verse afectadas por las mismas. Sin duda, tal determinación requeriría un estudio caso por caso de la forma y los entornos en que se prestan los servicios en la nube.



De esta manera, los proveedores de servicios establecidos en España que realicen actividades consistentes en la prestación de servicios de acceso a Internet, están obligados a informar a sus clientes de forma per-manente, fácil, directa y gratuita sobre:

a) Los medios de carácter técnico que aumentan los niveles de la seguridad de la información y permiten la protección frente a virus informáticos y programas espía y la restricción de correos electrónicos no solicitados.

b) Las medidas de seguridad que estos proveedores aplican en la provisión de los servicios.

c) Las herramientas existentes para el filtrado y restricción del acceso a determinados contenidos y servicios en Internet no deseados o que puedan resultar nocivos para la juventud y la infan-cia.

d) Las posibles responsabilidades en que puedan incurrir por el uso de Internet con fines ilícitos, en particular, para la comisión de ilícitos penales y por la vulneración de la legislación en materia de propiedad intelectual e industrial.

e) Las obligaciones de información referidas en los apartados anteriores se darán por cumplidas si el correspondiente proveedor incluye la información exigida en su página o sitio principal de Internet en la forma establecida en los mencionados apartados.

5.6 Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal

El pasado 23 de diciembre, entró en vigor la reciente reforma del Código Penal (Ley Orgánica 5/2010 de 22 de junio, en adelante, CP) por la que se incorpora, por vez primera a nuestro Ordenamiento Jurídico, la responsabilidad penal de las personas jurídicas.

Los ilícitos cuya comisión es más factible por parte de una empresa proveedora de servicios en la nube, son aquellos que recaen sobre los activos de información de los que es responsable el cliente (revelación de secretos, violación del secreto de las comunicaciones, delitos contra la propiedad intelectual e industrial, etc.) y entre ellos, los que recaen sobre los datos de carácter personal, en los que además de responder penalmente, habrá cometido una infracción administrativa (además de su respectiva responsabilidad civil, frente al responsable del fichero y frente al afectado, respectivamente).

La propia LSSI antes mencionada expresamente establece que, sin perjuicio de lo dispuesto en la misma, los prestadores de servicios de la Sociedad de la Información (entre los que, como se ha dicho, se encuen-tran las empresas de computación en la nube) están sujetos a la responsabilidad civil, penal y administra-tiva establecida con carácter general en el ordenamiento jurídico.

Es responsable penal la persona jurídica, como tal, respecto de los delitos cometidos en su nombre o por su cuenta y en su provecho por las personas que tienen poder de representación en las mismas (los administra-dores de hecho o de derecho y representantes legales), así como, por sus empleados cuando la empresa no haya realizado el debido control sobre éstos (art. 31 bis CP). La responsabilidad penal de la persona jurídica se podrá declarar con independencia de que se pueda o no individualizar la responsabilidad de la persona física que tiene la capacidad de representar a la empresa. En todo caso, la responsabilidad de las personas morales no viene a sustituir la de sus administradores que pueden llegar a sufrir penas de prisión.



Por ello, con la reciente reforma del Código Penal español, se ha incrementado el riesgo de que un direc-tivo sea imputado e incluso condenado por la mala conducta de un trabajador de la empresa o, incluso, por una decisión operativa o estratégica.

Esta reforma viene a recordar de manera más perentoria a las empresas a las que pueda resultar de aplicación del Código Penal español, la necesidad de implantar un sistema de supervisión y control de cumplimiento normativo como mecanismo indispensable y eficaz de prevención y mitigación de su respon-sabilidad penal.

En paralelo, el legislador también ha querido premiar a las sociedades más diligentes por lo que su res-ponsabilidad penal se verá atenuada en caso de que se produzca:

a) Confesión de la infracción ante las autoridades.

b) Colaboración en la investigación del hecho delictivo.

c) Reparación del daño causado por el delito.

d) Establecimiento de medidas eficaces para prevenir y descubrir los delitos que en el futuro pu-dieran cometerse con los medios o bajo la cobertura de la persona jurídica.

Más concretamente, en el ámbito de computación en la nube, podemos mencionar que si la empresa pro-veedora de servicios no despliega unas políticas de control interno que resulten suficientes para crear un clima favorable para que sus directivos y empleados comentan delitos, puede ser penalmente responsable, al igual que si no ejerce la vigilancia debida sobre los mismos (culpa invigilando).

Por ello, resulta muy aconsejable que las empresas dispongan de sistemas de prevención, medidas de vigilancia y control que permitan evitar o detectar la posible comisión de ilícitos penales. De este modo, la compañía estará en mejor posición para acreditar la realización del debido control sobre sus empleados y por lo tanto atenuar la responsabilidad derivada de la nueva regulación del CP.

Estas actuaciones se deberán implementar en las empresas a través de un plan preventivo integral dirigido a identificar, prevenir y mitigar riesgos penales de origen corporativo.

Para ello, se deberá analizar y regularizar la documentación jurídico-financiera de la empresa (tanto en soportes físicos como digitales) y los procedimientos relacionados con la producción, operaciones y admi-nistración (calidad, ISO, procesos, productos, relaciones laborales, etc.).

Y en el área más puramente tecnológica, deberán ponerse en práctica acciones conducentes a la elabo-ración de:

a) Códigos éticos de buen gobierno corporativo.

b) Programas de cumplimiento corporativo que garanticen el cumplimiento de la ley.

c) Preparación de un programa con contenido “informático forense” que permita la trazabilidad y generación de la prueba en los sistemas informáticos.



d) Normas de organización interna en materia informática y tecnológica.

e) “E-discovery”: Programas de revisión de la documentación depositada en formato digital.

f) Comités de vigilancia y supervisión tanto física cómo lógica del que deben formar parte conse-jeros independientes.

Los prestadores de servicios en la nube, por tanto, pueden llevar a cabo conductas expresamente tipifi-cadas como faltas o delitos en el Código Penal, de las que pueden a su vez resultar afectados los desti-natarios de tales servicios. En este sentido, y sin perjuicio de cualesquiera otros que pudieran resultar de aplicación según el supuesto concreto, procede aquí hacer mención a un conjunto de artículos del Código Penal Español.

Así, en los delitos relativos a la propiedad industrial, la intervención penal relativa a la propiedad industrial se centra en dos sectores de la actividad mercantil, el que abarca las creaciones industriales, por un lado, y el relativo a los signos distintivos, por otro. En concreto, la intervención punitiva va encauzada a la pro-tección de las patentes, modelos de utilidad y la protección de las marcas (Art. 273 y 274 CP).

En el delito de espionaje industrial (Art. 278 CP), la conducta típica consiste en el descubrimiento de un secreto de empresa, apoderándose de datos, documentos escritos o electrónicos, soportes informáticos u otros objetos y, además, constituye un tipo agravado el apoderamiento seguido de la difusión. Lo dispuesto respecto a este delito es independiente de las penas que puedan corresponder por el apoderamiento o la destrucción de los soportes informáticos (hurto, robo, etc.).

La violación de los deberes de reserva (Art. 279 CP) consiste en el descubrimiento de secretos por parte de quien ha tenido acceso a los mismos de forma legítima, pero viola las reglas que exigen el mantenimiento del mismo por tener legal o contractualmente obligación de guardar reserva con respecto a él. La acción típica consiste en difundir, revelar o ceder el secreto, diferenciándose del caso anterior tan sólo en la forma de acceder al mismo. En este sentido, el art. 279.2 CP contiene un tipo privilegiado que reduce la pena al sujeto que viola los deberes, no de reserva frente a terceros, sino de aprovechamiento personal del secreto frente a quien se lo ha facilitado legalmente.

Así, a modo de ejemplo, aquellos proveedores de servicios de computación en la nube que se apoderen, utilicen o modifiquen, en perjuicio de un tercero, tanto datos de carácter personal como datos relaciona-dos con las comunicaciones que se hallen registrados en ficheros o soportes informáticos, electrónicos o telemáticos podrán estar incurriendo en un delito de descubrimiento o revelación de secretos tipificado por el código Penal. A su vez, en caso de tratarse de datos de carácter personal, la pena se agravará si el infractor, en su calidad de encargado o responsable de los ficheros, difundiera, revelara o cediera a ter-ceros los datos en cuestión. Con independencia del mayor detalle con que siempre podría abordarse esta cuestión, resulta -a los efectos que aquí interesan- significativo que el legislador penal es bien consciente de la posición relevante que ostenta cualquiera que pudiera tener, de manera general, acceso a información de terceros45.

En el área de lo que se define con mayor precisión como el delito informático, el art. 264 CP hace exten-sible la responsabilidad por este delito a las personas jurídicas, incurriendo con ello en penas de multa u

45 Vid. artículo 197 del Código Penal



otras a juicio de los jueces y tribunales. La conducta típica se produce cuando el objetivo de la actividad realizada es dañar, alterar, suprimir o hacer inaccesible datos o programas electrónicos ajenos. En lo que se refiere al continente del objeto destruido, alterado, inutilizado o dañado, los datos, programas o docu-mentos electrónicos deben hallarse en redes, soportes o sistemas informáticos.

De la literalidad de la norma podemos inducir que el medio utilizado para cometer la acción puede ser ‘cualquier medio’. Con ello se engloba cualquier posibilidad, y por tanto, la norma jurídica iguala, por tanto, un acto de destrucción física a un acto de manejo de un ordenador.

Sin que deba atenderse en absoluto que una empresa de computación en la nube tenga por objeto la realización de las conductas a las que nos referiremos a continuación, a través de los medios de los que dispone un prestador de servicios en la nube pueden realizarse actividades fraudulentas consistentes -por ejemplo- en la creación de ficheros informáticos “paralelos” produciendo un error en el usuario que tendrá la idea de estar actuando en un entorno distinto del real.

Este tipo de actividades son, con frecuencia, ejecutadas con el fin de llevar a cabo transacciones fraudulen-tas, definidas en el Código Penal (art. 248 CP) como aquellas que, utilizando engaño bastante mediante manipulación informática o artificio semejante para la producción de error en un tercero, induzca a éste a realizar actos de disposición o transferencias no consentidas de activos patrimoniales en perjuicio propio o ajeno.

Obviamente, a través del modelo de computación en la nube podrían llegar a proliferar estafadores cuya actividad delictiva consista en la creación de páginas web de Internet falsas cuya finalidad consistiría en apropiarse indebidamente de información volcada por los usuarios, así como en realizar acciones ten-dentes a modificar o a sustituir el archivo del servidor de nombre de dominio, dando lugar a un cambio de la dirección IP legítima de una entidad e induciendo a que cuando el usuario escriba el nombre de dominio sobre la barra de direcciones, el navegador lo redirija a una dirección IP falsa. Una vez que se ha redireccionado al usuario a la página web de Internet fraudulenta, el estafador podría obtener aquellos datos personales pertenecientes a la víctima así como la información confidencial necesaria para realizar transacciones fraudulentas. Como decimos, la actividad que aquí se describe encontraría un encuadre en el tipo penal del fraude online, recogido en el artículo 248 del Código Penal.

En relación con las posibles colisiones con los derechos de propiedad intelectual, la nube podría llegar a ser un entorno inseguro para poner a disposición del público determinados contenidos sujetos a derechos de propiedad intelectual de consumo típicamente lineal como pueden ser los libros electrónicos, las pelícu-las, música, etc. Sin embargo, sí puede ser un entorno seguro y atractivo para aquellos contenidos sujetos a derechos de propiedad intelectual de consumo interactivo como los videojuegos o el software que sólo se pueden ejecutar en la nube, sin que se deba acceder al archivo que los contiene en un determinado servidor y sin que se deban llevarse a cabo copias o su instalación en el terminal propio del usuario.

El artículo 270 del Código Penal es un precepto que contiene importantes elementos normativos que de-ben ser interpretados acudiendo a la legislación reguladora mercantil y civil. En ese artículo se describen las acciones que resultan sancionables y establece la exigencia de un dolo específico, esto es, obrar con ánimo de lucro y en perjuicio de tercero. Esta frase implica que el delito se consuma con la realización de la conducta típica sin que sea necesario que se llegue a producir “de hecho” un perjuicio en el titular de los derechos o que se logre el lucro perseguido. Sin embargo, no habrá delito cuando falte el ánimo de lucro, como es el caso, de quien realiza una copia privada sin autorización del titular. El elemento subjetivo



exigido, esto es, el ánimo de lucro, no puede tener una interpretación amplia o extensiva sino que ha de ser entendido sentido estricto de lucro comercial. Por ello, las conductas para la comunicación u obtención de obras protegidas en Internet o utilizando nuevas tecnologías de la información -como colocar en la red o bajar de Internet- no son oponibles si no concurre ánimo de lucro comercial.

Este artículo del código Penal recoge en su texto cuatro conductas básicas: la reproducción, el plagio, la distribución y la comunicación pública de las obras. Y en relación con ellas, son tres las circunstancias necesarias que los hechos encuentren encajen en el tipo delictivo:

• Una acción de reproducción, plagio, distribución o comunicación pública de una obra literaria artística o científica o de transformación, interpretación o ejecución de las mismas en cualquier tipo de soporte o su comunicación por cualquier medio;

• La carencia de autorización para cualquier clase de esas actividades por parte de los titulares de los correspondientes derechos de propiedad intelectual;

• La realización intencionada de esas conductas con la concurrencia de dolo específico, esto es, ánimo de lucro.

En todo caso, en el modelo de computación en la nube, las empresas clientes podrían desear acceder y usar los servicios prestados de acuerdos con sus propias necesidades, beneficiándose del acceso a los servicios, contenidos y software que proporciona la empresa proveedora. Sin embargo, en determinados casos las empresas clientes también perseguirán que los derechos de propiedad intelectual que ellas ge-neren sobre sus propios contenidos o el nuevo software (original o derivado) creado o almacenado en la nube queden debidamente protegidos.

Una de las soluciones que se imponen pasaría por introducir en el contrato que rige la prestación de servi-cios en la nube y en la política de uso o de acceso a la nube las cláusulas tendentes a establecer el equili-brio necesario entre la responsabilidad debida por las empresas clientes al ejecutar y usar los contenidos, servicios y software ajenos desde la nube y las medidas de seguridad tendentes a proteger los derechos de propiedad intelectual que deberán ser garantizados por la empresa prestadora de servicios.

En esta misma línea, conviene destacar que la utilización de las aplicaciones alojadas en la nube puede dar lugar a la generación de creaciones intelectuales merecedoras de protección en materia de derechos de propiedad intelectual, por lo que resulta muy aconsejable incluir en el contrato cláusulas dirigidas a establecer el régimen de titularidad o de co-titularidad de los derechos de propiedad intelectual relativos a las creaciones intelectuales que pudieran generarse bajo el modelo de negocio de la nube.

Existe, asimismo, la posibilidad de que las empresas clientes utilicen los servidores en la nube para alma-cenar contenidos o software ajenos como forma –a su vez- de prestar servicios a terceros, de forma que queden alojadas copias de contenidos y de software en servidores de almacenamiento remoto desde los cuales que posteriormente puedan realizarse reproducciones. Cuando este tipo de servicios se prestan en la manera descrita, las empresas clientes ponen a las empresas proveedoras de estos servicios en la nube en riesgo de una responsabilidad jurídica en función de las potenciales infracciones de derechos de la propiedad intelectual que pudieran producirse. Si este fuese el caso, resulta necesario incluir en el contra-to de servicios en la nube la asunción expresa e inequívoca por parte de las empresas clientes de toda responsabilidad jurídica que pudiera surgir con motivo de estos actos potencialmente ilícitos, mediante la



incorporación en el contrato y en la política de uso de los servicios en la nube de aquellas previsiones a través de las cuales la empresa prestadora de servicios pueda reservarse a su favor la facultad tanto de hacer un seguimiento como de eliminar aquellos contenidos y software ajenos que los usuarios terceros puedan incluir en los servidores de la nube, estableciéndose para ellos determinados criterios como que puedan afectar a derechos de terceros, intereses u orden públicos, etc.46

La deslocalización internacional –característica propia de la prestación de servicios en la nube- puede dar lugar en ocasiones a la utilización del contenido ajeno, software ajeno o de servicios que se prestan desde jurisdicciones donde está prohibido su uso o el mismo no se encuentra autorizado. Por ello, se hace necesario contemplar en el contrato regulador de estos servicios las restricciones que deban regir respecto del uso de los servicios en la nube en relación con aquellos territorios desde donde no resulta lícito su utilización, así como establecer los más adecuados mecanismos de control tecnológico de forma que ese contenido o software ajeno no pueda ser ejecutado en tales territorios. Otra solución jurídica viable consis-tiría en renegociar y ampliar las licencias firmadas entre los terceros proveedores de software, contenidos o servicios y la empresa proveedora de servicios en la nube para que las empresas clientes puedan utilizar lícitamente tales derechos desde cualquier jurisdicción.

En definitiva, puede entenderse que el entorno de Internet -en general- y el de los servicios de computación en la nube -en particular- podrían servir de medio para la realización de conductas delictivas, lo que, sin embar-go, no debe constituir una señal de alarma mayor que la que pudiera entenderse en entornos no digitales.

5.7 Aspectos Jurídicos Laborales

En la medida en que la gestión de los sistemas utilizados en el modelo de computación en la nube es desempeñada por un tercero, el cumplimiento del deber de vigilancia de la actividad de los empleados por parte de la empresa cliente se ve de algún modo limitada. Sin embargo, tanto la empresa proveedora de servicios en la nube, como la empresa cliente mantienen la obligación de establecer los mecanismos adecuados con el fin de que se produzca el adecuado uso de los servicios tanto por los propios empleados como por parte de los empleados de la empresa cliente.

Es importante destacar que el establecimiento de estos mecanismos provoca ineludiblemente la aparición de un riesgo de intromisión en los derechos a la intimidad del trabajador, mientras que –en paralelo- la misma posibilidad de acceder desde cualquier punto de conexión a la información depositada en los servidores de computación en la nube, puede conducir a un uso fraudulento de la identidad de los usua-rios finales (también, potencialmente, trabajadores de la empresa cliente), si –entre otras medidas - no se implanta un sistema a través del cual se procura una rigurosa gestión de los controles de acceso por parte de esos trabajadores. Un sistema excesivamente laxo de gestión de los nombres de usuario y de sus corres-pondientes contraseñas puede dar lugar a la violación de las obligaciones de confidencialidad asumidas por las empresas en relación con terceros y la consiguiente extracción no deseada de información de los sistemas por parte de terceros no autorizados.

La implantación de los denominados “protocolos de utilización de herramientas informáticas y tecnológicas en el puesto de trabajo” se presenta en el modelo de computación en la nube con una obligación más que inexcusable al objeto de delimitar el uso que los trabajadores pueden realizar de las aplicaciones ubicadas en la nube.

46 Los aspectos relativos a la contratación se analizan detalladamente en el Capítulo 7.



Este protocolo debe tener su reflejo en la inclusión en el contrato laboral de aquellas condiciones conte-nidas en el mismo, de tal forma que su incumplimiento por parte del trabajador –como, por ejemplo, la obligación de secreto de la información a la que se tiene acceso- pueda resultar en la adopción de las correspondientes acciones disciplinarias que en materia laboral sean de aplicación. En todo caso, las me-didas impuestas por parte de las empresas (tanto proveedoras de servicios en la nube como de empresas clientes de estos servicios) deben guardar una adecuada proporcionalidad con los objetivos que se per-siguen, no implicar la utilización de medios intrusivos y deben estar debidamente justificadas en relación con los propósitos perseguidos en el marco de la contratación efectuada.

En el protocolo se establecerá el modo en el que se generarán las evidencias electrónicas así como su procedimiento de obtención, conservación y aportación47. Asimismo, en dicho protocolo deberá especifi-carse la persona responsable que en el seno de la propia empresa realizará el seguimiento y el control de la actividad en la nube por parte de los trabajadores -tanto en el ámbito profesional como en privado, si fuese el caso- y cuyo alcance, lógicamente, dependerá de las características propias de las aplicaciones, infraestructuras o plataformas que sean objeto de contratación por parte de las empresas.

47 Este aspecto se trata con detalle en el Capítulo 8.



6.1 Introducción

El uso de la computación en la nube supone un impacto significativo para los procesos de operación y man-tenimiento de sistemas de información con respecto a los modelos tradicionales, así como en la prestación de servicios hacia el público objetivo al que se dirigen. Del mismo modo, el uso de la computación en la nube afecta sustancialmente a los modelos de gestión de seguridad de la información.

El objetivo de este capítulo es proporcionar una serie de pautas para establecer, de forma práctica y efi-caz, un adecuado Sistema de Gestión de Seguridad de la Información (en adelante, SGSI) por parte de aquellas empresas que deseen utilizarlo en el ámbito de la computación en la nube. Por tanto, es relevante para usuarios, clientes finales, así como para proveedores que deseen implantar un SGSI, en función de su rol en este ámbito.

Este apartado se centrará únicamente en aquellos aspectos del establecimiento de un SGSI que sean carac-terísticos de la computación en la nube. Aquellos lectores interesados en obtener una visión general sobre SGSI deberán referirse al estándar de referencia ISO/IEC 27001:2005 (en adelante ISO 27001).

Es necesario destacar que las recomendaciones incluidas en este apartado hacen referencia frecuentemen-te a los controles del estándar ISO/IEC 27002 (en adelante ISO 27002), así como a los controles de la matriz desarrollada por CSA [CSA, diciembre 2010].


Este capítulo se ha estructurado siguiendo las etapas generalmente aceptadas para la implantación de un SGSI (ver Ilustración 3). De esta forma, comenzando por un apartado inicial en el que se tratan los principios generales de despliegue de un SGSI en la nube, se han incluido tres apartados que agrupan las tareas de despliegue en tres grandes fases:

• I. Definición y preparación del SGSI

• II. Implantación y operación del SGSI

• III. Seguimiento y mejora del SGSI

Sistemas de Gestión de la Seguridad de la Información en la nube



En cada una de las fases se incluyen recomendaciones relativas a la implantación de un SGSI consideran-do los diferentes modelos de despliegue de servicios en la nube (modelo SPI) y para los distintos actores (cliente o proveedor).

6.3 Principios generales de despliegue de un SGSI

El establecimiento de un SGSI está basado en el principio de mejora continua (modelo Plan-Do-Check-Act), tal y como establece el estándar de referencia ISO 27001. Este principio sigue siendo aplicable en el caso de la computación en la nube, así como el modelo general para el establecimiento, implementación, ope-ración, supervisión, revisión, mantenimiento y mejora de un SGSI definidos en dicho estándar.

Las particularidades en el caso de la computación en la nube responden a la propia naturaleza de dicho servicio y el hecho de que éste sea a la carta, multi-inquilino48, elástico, medible, accesible por red, en ocasiones auto-provisionable y soportado por recursos compartidos. Estas características implican una di-ferencia en los niveles y en los mecanismos de gestión del riesgo existentes con respecto a los sistemas de información tradicionales y, por tanto, la necesidad de un cambio en la gestión de la seguridad por parte de usuarios, clientes y proveedores. Este cambio no implica que siempre haya que realizar tareas adicio-nales, sino que debemos afrontarlas de distinta manera (de hecho, en múltiples ocasiones, se simplifican para alguno de los actores, las tareas la implantación de este tipo de sistemas de gestión).

Asimismo, en el proceso de implantación del SGSI, será necesario diferenciar claramente el ámbito de actuación: usuario, cliente o proveedor; así como el tipo de servicio utilizado conforme al modelo SPI.

En el caso de una empresa usuaria de servicios en la nube, se deberá prestar especial atención a la inte-gración de los sistemas de información tradicionales con las particularidades concretas de la computación

Ilustración 3. Fases de despliegue de un SGSI

Definición yprepareción

del SGSI

Fasesdel SGSI

Implantacióny operación

del SGSI

Seguimientoy mejoradel SGSI

48 Del inglés, multi-tenant



en la nube, así como la integración de los indicadores específicos de gestión e integración del posible SGSI del proveedor, la definición de un correcto alcance, así como a las cláusulas del contrato y los acuer-dos de nivel de servicio con el proveedor49.

Por otro lado, los proveedores de servicios en la nube deberán focalizar sus esfuerzos en proporcionar los niveles de seguridad adecuados para cada cliente sobre la base de las normativas aplicables; así como en gestionar el cumplimiento de los niveles de servicio acordados.

En cuanto al tipo de servicio, en el caso de SaaS el proveedor estará dotado de un mayor grado de res-ponsabilidad con respecto a la ejecución de controles que en el caso de PaaS y, a su vez, es mayor en el escenario PaaS que en el IaaS. Esto determinará el grado en que el cliente deberá delegar la gestión de controles al proveedor, así como la forma de asegurar su correcto diseño y operación50.

6.4 Fase I. Definición y preparación del SGSI

6.4.1 Presentación inicialEs altamente recomendable iniciar el ciclo de vida de un SGSI con una presentación a las principales áreas involucradas, a fin de comunicar, revisar y establecer los objetivos, la organización, el grado de participa-ción requerido y la identificación de los interlocutores para la implantación y seguimiento.

Ilustración 4. Etapas de la Fase I

PresentaciónInicial

MetodoEvaluación

RiesgosActivos

Definición Organización Amenazas

AlcancePolítica deSeguridad Impactos

Selección de Controles

49 Este aspecto se tratará más adelante en el Capítulo 7 Efectos de la computación en la nube sobre la contratación de servicios TIC de este documento.

50 Por ejemplo, mediante el uso de acuerdos y métricas de nivel de servicio como veremos en el Capítulo 7.



En el caso de computación en la nube, es primordial involucrar a los proveedores desde el inicio para asegurar un grado de colaboración adecuado durante todo el proceso. Cabe destacar que el ciclo de vida de un SGSI es indefinido y por tanto será necesario asegurar un compromiso permanente por parte de éstos. En el caso de nuevos proveedores, será necesario formalizar dicho compromiso antes de iniciar la prestación de servicios.

6.4.2 Definición del SGSIEs necesario establecer desde el principio qué se entiende por un SGSI, así como definir los conceptos que deberán utilizar y compartir todos los participantes. En este sentido, es importante que clientes y proveedo-res de computación en la nube consensuen un lenguaje común en sus acuerdos y métricas, así como en las cláusulas del contrato de servicios51. Los usuarios del SGSI, independientemente de ser cliente o proveedor, también deberán conocer y entender las implicaciones y los nuevos requisitos que se impondrán en la implantación así como en el posterior mantenimiento.

6.4.3 Alcance del SGSILa organización debe definir el alcance y los límites del SGSI en base a las características del negocio y la organización, sus objetivos, ubicación, activos y tecnología; y justificar cualquier exclusión del ámbito de aplicación.

La definición del alcance es un aspecto esencial en la implantación de cualquier SGSI cuando existe involu-cración de terceros y la computación en la nube no es una excepción (excepto en los casos de nubes priva-das donde la gestión corresponde a la misma organización). Por tanto, es importante que la organización invierta recursos tanto en identificar los procesos que deben ser incluidos en el SGSI como en analizar su grado de dependencia de la computación en la nube. Cabe destacar que no hay que excluir obligatoria-mente del alcance del SGSI aquellas actividades efectuadas por proveedores dentro de los procesos selec-cionados. Con el fin de gestionar dicha casuística, se recomienda a la organización usuaria considerar la aplicación de controles específicos para terceras partes previsto por el propio estándar ISO 27002.

Por otra parte, es posible que las actividades efectuadas o gestionadas por proveedores dentro del alcance estén a su vez incluidas dentro de un SGSI del proveedor; en lo que podríamos denominar como “SGSIs encapsulados”. En este caso, la organización usuaria puede utilizar la certificación y/o evidencias del SGSI del proveedor como pruebas de una gestión adecuada para su propio SGSI (en relación a las ac-tividades efectuadas por dicho proveedor). El mismo razonamiento puede aplicarse a la subcontratación de servicios por parte del proveedor de computación en la nube a otros proveedores (cadena de aprovi-sionamiento). Dicho intercambio de información deberá ser regulado y aceptado por ambas partes para proteger la integridad de ambos SGSI, así como definir su uso y frecuencia.

Los proveedores de servicios en la nube que deseen implantar un SGSI deberán prestar especial atención a que el alcance sea significativo para las organizaciones usuarias y minimice, por tanto, la necesidad de controles y revisiones adicionales por parte de éstas. Cuanto más precisa sea la definición del alcance del SGSI, más probabilidad de éxito tendremos para la implementación y mantenimiento del mismo.

Por último, cabe destacar que las características de la computación en la nube posibilitan la contratación de servicios por parte de las áreas de negocio de la organización sin involucrar al departamento de

51 Las cláusulas en los contratos se tratan en detalle en el Capítulo 7 Efectos de la computación en la nube sobre la contratación de servicios TIC.



sistemas de información. El área responsable de la implantación del SGSI deberá explorar la existencia de dichos casos y considerar su inclusión en el alcance. En cualquier caso, la contratación de servicios debería ser planteada al Comité de Seguridad de la Organización para que evalúe los riesgos de dicha contratación y considere su integración y/o seguimiento en el SGSI.

6.4.4 Política de SeguridadLa organización deberá establecer una política que especifique las directrices a seguir en materia de protec-ción de la información dentro del alcance del SGSI. La aprobación de dicha política es la misión más impor-tante de la Dirección y un hito imprescindible antes de proceder con la implantación. Dicha política deberá describir el contexto estratégico para la gestión de riesgos en la organización, incluida la aceptación de uso de computación en la nube; así como reflejar los requisitos legales, regulatorios y contractuales existentes.

La política de seguridad deberá ser comunicada a los usuarios de la organización así como a terceras partes con responsabilidades en el ámbito de la seguridad de la información; incluidos los proveedores de computación en la nube, los cuales deberán considerar e incorporar dicha política para el uso de la información que utilicen.

En el caso de proveedores implementando un SGSI, la política de seguridad podrá ser utilizada para comunicar tanto a clientes usuarios como a otras empresas subcontratadas la estrategia y principios de protección de la in-formación; y alcanzar por tanto un mayor grado de garantía. La política podrá ser adaptada para cada cliente o proveedor en función del tipo de servicio prestado (SaaS, PaaS o IaaS) y niveles de control acordados.

6.4.5 Organización del SGSIEs necesario que, tanto las responsabilidades como las funciones, que se derivan del SGSI estén adecuada-mente definidas y asignadas, por ejemplo, mediante el uso de matrices RACI. En el caso de la computación en la nube, es imprescindible definir los roles y responsabilidades de cliente y proveedor con respecto a la definición, implantación, mantenimiento y revisión de controles; así como, con respecto a la gestión y monitorización de riesgos.

Por otra parte, la Dirección de la organización deberá permanecer debidamente informada y aceptar su responsabilidad en el impulso y dirección de todas las actividades necesarias para la correcta implanta-ción y supervisión del SGSI; incluida la autorización de recursos extraordinarios cuando sea necesario.

Adicionalmente, antes de comenzar la prestación de servicios en la nube, deberán definirse y acordarse la información requerida, canales de comunicación y tiempos de respuesta entre proveedor y cliente(s). La información solicitada puede referirse a métricas del nivel de servicio, pero también a datos sobre la localización de la información52 o una posible investigación por parte de las autoridades53. Los canales de comunicación deben ser probados periódicamente durante las operaciones.

6.4.6 Definición y establecimiento del método de evaluación de riesgosEl adecuado control de un SGSI a lo largo de su ciclo de vida se verá determinado por el modelo elegido para el análisis de riesgos, dado que éste será el principal motor para la identificación y gestión del riesgo y la subsecuente toma de decisiones.

En el caso de la computación en la nube, la metodología seleccionada deberá, al menos:

52 Aspecto tremendamente importante como se ha podido comprobar durante el Capítulo 4.53 Este aspecto se trata en detalle en el Capítulo 8. La obtención de evidencias digitales en la nube.



• Considerar las amenazas y vulnerabilidades específicas de la nube;

• Estar alineada con el ciclo de vida de proyectos y desarrollo de servicios de computación en la nube;

• Producir resultados comparables y reproducibles, independientemente del proveedor de servicios y del tipo de servicio contratado; es muy importante la adecuada elección de la metodología utilizada ya que deberá ser gestionada en los años sucesivos para producir resultados comparables.

• Contener aquellas medidas de seguridad específicas para computación en la nube en la lista o catálogo base de controles;

• Contemplar la dependencia con respecto al proveedor (y sus empresas subcontratadas) para los procesos de identificación, tratamiento, monitorización y notificación de riesgos.

Cabe enfatizar que las actividades ejecutadas por proveedores de servicios en la nube tienen impacto sobre los activos de sus organizaciones usuarias y, por tanto, no pueden considerarse como riesgos trans-feridos ni pueden eliminarse del proceso de evaluación.

En el caso de proveedores de computación en la nube que estén implantando un SGSI, deberán validar que su metodología de evaluación de riesgos está alineada con las buenas prácticas, así como con las leyes y regulaciones aplicables para cada industria y territorio. Es indispensable que la metodología selec-cionada esté bien documentada y pueda ser comunicada a los usuarios cuando estos lo requieran.

6.4.7 Identificación y valoración de activosDentro del proceso de planificación del SGSI, es necesario identificar los activos dentro del alcance, así como los propietarios de estos activos.

La naturaleza abierta de la computación en la nube dificulta este proceso, ya que la organización usuaria no tiene visibilidad sobre todos los activos que soportan los servicios contratados (especialmente en SaaS). En este caso, el cliente deberá considerar la inclusión en el alcance de aquellos activos sobre los que tenga visibilidad directa (por ejemplo, el servicio, proveedor u aplicación) pero no necesariamente aquellos activos que los soportan; especialmente si se hallan fuera de sus instalaciones y son gestionados por el proveedor.

Por tanto, en caso de ser posible, sería recomendable, contar con un inventario de los activos del provee-dor que sustentan un proceso del cliente. En caso de no poder facilitar dicha información, será necesario que sea sustituido por el nivel de riesgo asociado a ese conjunto de activos, incluyendo la definición de dicho nivel y/o los criterios utilizados para la clasificación.

Tanto proveedor como cliente deben contar con un mapa de servicios, procesos y activos. El enfoque para realizar este tipo de mapas no es diferente del que se puede seguir en otros ámbitos (identificación de procesos, actividades, etc.).

Para la identificación de procesos y activos de información es importante formalizar las personas consi-deradas como propietarios de los procesos / activos, ya que serán las responsables del correcto diseño, implantación, operación y mantenimiento del mismo. En especial, se deben identificar tanto los procesos responsabilidad del cliente como los del proveedor. En particular, los clientes deberían conocer aquellos procesos propietarios de los mismos que se sustenten en subprocesos del proveedor.



Adicionalmente, es importante conocer si los procesos del proveedor son gestionados por él mismo o si son subcontratados a otro proveedor de servicio.

A continuación se presenta, en formato de matriz RACI, una relación no exhaustiva y a modo ilustrativo de procesos y activos de información que, a priori, son responsabilidad del cliente / pro-veedor para cada uno de los modelos de servicios en la nube (SaaS, PaaS, IaaS).

No obstante, para la gestión de los activos de información debería establecerse en el contrato54 entre cliente y proveedor una matriz de responsabilidades al estilo de la incluida a continuación.

Tabla 1. Roles y responsabilidades según el modelo SPI de implantación

I* Siempre que los cambios realizados no afecten a las condiciones contractuales y/o ANSs (Acuerdos de Nivel de Servicio), en cuyo caso el cliente deberá ser consultado (C).

A/R** El cliente y el proveedor serán responsables de las medidas de seguridad en función de su ámbito de actuación (es de-cir, el proveedor será responsable de las medidas que afecten a la infraestructura compartida y el cliente del resto).

ProcesosSaaS PaaS IaaS

Cliente Proveedor Cliente Proveedor Cliente Proveedor

Desarrollo de aplicaciones I R R I R I

Gestión de la configuración I R A R A/R R

Gestión del cambio I R A R A R

Gestión del parcheado I R A/R R A/R R

Gestión de identidades A R A/R R A/R R

Gestión de acceso lógico A R A/R R A/R R

Cumplimiento legal y regulatorio A/R R A/R R A/R R

Gestión Ciclo de Vida de la Información A/R A A/R A A/R A

Gestión Continuidad de Negocio A R A/R R A/R R

Gestión Incidentes de seguridad A R A/R R A/R R

Gestión acceso físico I A I A I A

Activos de información

Información A R A R A R

Aplicaciones I A/R A/R A/R

Servidores (HW) I A/R I* A/R I* A/R

Almacenamiento I A/R I* A/R I* A/R

Sistemas Operativos I A/R I* A/R A/R

Red I A/R I* A/R I* A/R

Sistemas de seguridad I A/R I* A/R A/R** A/R**

54 La contratación de servicios se trata en detalle en el Capítulo 7 Efectos de la computación en la nube sobre la contratación de servicios TIC.

R – Responsable / A – Aprobador / C – Consultado / I - Informado



Desde la perspectiva del proveedor se deberá tener en cuenta que:

• Es importante contar con un proceso de gestión del riesgo que considere la situación actual del riesgo de los servicios que ofrece a sus clientes. Para ello, es clave documentar, para cada servicio ofertado, los procesos que lo forman, así como sus activos de información y los riesgos a los que están sometidos puesto que los mismos afectarán a los procesos de negocio del clien-te. De esta forma, se podrán establecer diferentes categorías (por ejemplo: oro, plata, bronce) para los servicios ofertados en función del nivel de riesgo y del servicio prestado al cliente.

• Debe poder identificar aquellos activos que soportan, o han soportado en un momento dado, los servicios de cada uno de sus clientes, pudiéndose dar el caso de que un mismo activo sea compartido por varios clientes. Esta trazabilidad permitirá realizar análisis forenses en caso de ser necesario.

• Debe tener identificados todos aquellos procesos que hacen uso de activos de información de terceros e informar debidamente al cliente (en función de los compromisos establecidos con él).

• Es necesario tener en cuenta la ubicación de las plataformas que oferta puesto que pueden en-contrarse en diferentes ubicaciones geográficas siendo la legislación aplicable, las amenazas y sus probabilidades de ocurrencia dependientes de las mismas55.

Por otro lado, el cliente, en relación a la identificación y valoración de activos, debe ser consciente de que:

• Es importante conocer el valor de los procesos de negocio que van a ser soportados por servicios en la nube, ya que en función de su importancia estratégica, variarán los requisitos de seguridad a exigir, y por tanto, la categoría de servicios a contratar (en cuanto al nivel de seguridad deseable). De esta forma, un cambio en los procesos de negocio que afecten a la valoración de los mismos o de sus activos pueden conllevar la necesidad de modificar el tipo de servicios contratados para que proporcionen el nivel de seguridad adecuado al nuevo nivel de riesgo.

• Los inventarios de activos de los clientes debería incluir activos que acojan servicios en la nube y que estén bajo el control de proveedor. Los planes de valoración y clasificación deberían ser acordes.

• Es importante conocer si el servicio ofertado por el proveedor será soportado por procesos y activos de un tercero. En esos casos, será necesario examinar la gestión del riesgo por parte de dichos terceros, y exigir unos niveles acordes a la categoría contratada.

6.4.8 Identificación y valoración de amenazasEn el contexto de una provisión de servicios en la nube, es necesario que tanto cliente como proveedor comprendan las amenazas asociadas al servicio en cuestión.

55 El efecto de la ubicación física también es analizado en los Capítulo 4, 7 y 8 en relación a la privacidad, a los contratos y a las evidencias electrónicas en entornos de computación en la nube.



De esta forma, se puede definir una amenaza en un entorno de computación en la nube como la causa po-tencial de un incidente que puede causar daños en la información hospedada y procesada en ese entorno, o a algún elemento o conjunto de ellos que conforman el servicio.

De cara a identificar las posibles amenazas que pueden incidir en un servicio en la nube es necesario contextualizar el servicio, clarificando las implicaciones de un suceso que puede afectar a los activos que conforman el servicio en detrimento de su valor para la organización.

Esta contextualización permitirá detectar problemas de aplicabilidad así como la identificación de amena-zas inherentes a los propios modelos de servicio en la nube y a los modelos de implantación.

Esta información se conforma de especial importancia como un primer elemento discriminante en la se-lección de tipología de servicios por parte de un cliente y como una herramienta útil en la elaboración de análisis de riesgos en dichos servicios.

De esta forma, se sugieren los siguientes mecanismos para la identificación de amenazas:

• Entrevistas con los propietarios de los activos, departamentos de sistemas, CIO – Chief Informa-tion Officer, CISO – Chief Information Security Officer y CSO – Chief Security Officer.

• Listados y fuentes de información externas, de amplia difusión, provenientes de entidades in-ternacionales con un amplio espectro (como, por ejemplo, CSA56, ENISA57, Computer Security Institute58).

• Listados y fuentes de información gubernamentales (como los CSIRTs/CERTs nacionales, NIST u otras fuentes que puedan existir a nivel nacional)59.

En el presente documento se han reestructurado y complementado el listado de amenazas más frecuentes en los entornos de computación en la nube ya identificadas por organismos supranacionales en sus infor-mes y trabajos colaborativos. Se han tomado principalmente dos fuentes:

• “Cloud Computing Information Assurance Framework” [ENISA, 2009]

• “Top Threats to Cloud Computing v1.0” [CSA, marzo 2010]

Teniendo en cuenta que los diversos modelos de servicio e implementación en la nube conllevan unos ries-gos inherentes, independientemente de su naturaleza, es conveniente definir la aplicabilidad para valorar el potencial de una amenaza.

En este sentido, a continuación se presenta un modelo o matriz de amenazas que introduce otro criterio como es la categoría de la amenaza (organizativa, técnica y legal), dejando a un lado aquellos aspectos o riesgos no específicos de la nube (el Anexo I incluye un análisis más detallado de las amenazas técnicas):

56 www.cloudsecurityalliance.org57 www.enisa.europa.eu58 www.gocsi.eu59 Tanto en www.first.org como en www.terena.org se puede obtener una lista de CSIRTs



Fuente Categoría Amenaza

Ámbito de Aplicación (Aplicabilidad)

Modelo de Servicio Modelo de Implementación

IaaS PaaS SaaS Pública Privada Compartida Híbrida

[1] Organizativa Restricción al cambio de proveedor (lock-in) x x x x x x x

[1] Organizativa Pérdida de la gobernabilidad x x x x x x x

[1] Organizativa Retos de cumplimiento x x x x x x x

[1] Organizativa Pérdida de reputación de negocio (co-tenant) x x x x x x

[1] Organizativa Terminación o fallo del servicio en la nube x x x x x x x

[1] Organizativa Adquisición de proveedor en la nube x x x x x x x

[1] Organizativa Fallo en la cadena de suministro x x x x x x x

[2] Técnica Agotamiento de recursos x x x x x x x

[2] Técnica Fallos de aislamiento de servicios x x x x

[2] Técnica Denegación de servicio distribuida x x x x x x x

[2] Técnica

Uso Indebido y nefasto de la

computación en la nube

x x x x x

[2] Técnica Interfaces inseguras y APIs x x x x x x

[2] Técnica Usuarios internos maliciosos x x x x x x x

[2] TécnicaAspectos de la tecnología compartida

x x x x

[2] Técnica Pérdida o fuga de datos x x x x x x x

[2] Técnica Secuestro de servicio o cuenta x x x x x x x

[2] Técnica Perfil de riesgo desconocido x x x x x x x

[2] Legal Incumplimiento de legislación aplicable x x x x x x x

[1] [ENISA, 2009][2] [CSA, marzo 2010]

Tabla 2. Aplicabilidad de amenazas según modelo de servicio y de implementación



Como en cualquier entorno, para la identificación y valoración de amenazas es recomendable realizar agrupaciones funcionales de las que compartan características comunes (por su origen, por su motiva-ción…), definir su aplicabilidad y la dimensión de la seguridad que se puede ver afectada y tener en cuenta que varían en función del tipo de organización y estado del arte.

Adicionalmente, de cara a afrontar una identificación efectiva de las amenazas dentro de un entorno de computación en la nube, tanto desde una perspectiva de un cliente como del lado del proveedor, se sugie-ren las siguientes recomendaciones que facilitarán dicha labor:

• Partir de un listado de amenazas predefinidas por fuentes externas reconocidas (como las men-cionadas anteriormente), teniendo en cuenta que no todas las amenazas afectan a todos los activos (lo que conlleva una simplificación del análisis).

• Tener en cuenta que las amenazas legales dependen no sólo del país de origen/residencia del cliente sino también de la localización geográfica de la infraestructura desde la cual el provee-dor le presta los servicios en la nube60.

• Tomar en consideración que las amenazas varían en función del modelo de servicio y del mo-delo de implementación.

6.4.9 Análisis de impactosAunque el impacto sobre el negocio resultante de la materialización de una vulnerabilidad en un activo se manten-drá, la computación en la nube sí que afecta a la probabilidad de que se produzca. Adicionalmente, se puede dar la paradoja de que un mismo riesgo, pueda ser a la vez beneficioso o perjudicial dependiendo de si somos clientes o proveedores. Por ejemplo, con la restricción al cambio de proveedor61, por una parte, el cliente pierde flexibilidad, pero por otra, el proveedor reduce la probabilidad de fuga de clientes por el incremento en el coste del cambio. Finalmente, también se da la paradoja para el cliente de que, por un lado, aumenta el riesgo por la concentración de la información, pero por otro, también disminuye por la simplificación de la adopción de controles sobre la misma.

Usando como base el documento de ENISA sobre evaluación de riesgos en la nube [ENISA, 2009], se incluyen en el Anexo II, tablas comparativas de impactos sobre proveedor y cliente, junto a algunas orientaciones para reducirlos.

6.4.10 Selección de objetivos de control y controlesDentro de esta fase de planificación del SGSI, deberán seleccionarse los objetivos de control y controles aplicables al alcance. Dichos controles representarán las medidas, tanto tecnológicas como organizativas o de otro tipo, que serán consideradas para el tratamiento de riesgos durante la fase de implantación. La lista de controles seleccionados (o “Declaración de Aplicabilidad”) podrá indudablemente ser actualizada en base al resultado del análisis de riesgos y su posterior plan de tratamiento.

Para la selección de controles en el contexto de computación en la nube, referimos al lector al estándar de referencia ISO 27002 así como a la matriz de riesgos [CSA, diciembre 2010]. La selección deberá también tener en cuenta los requerimientos legales, regulatorios y contractuales existentes62.

60 El efecto de la aplicación geográfica en la contratación se estudia en el Apartado 7.9. Ley aplicable y jurisdicción.61 Del término en inglés, lock in.62 Estos aspectos son analizados más detalladamente en los Capítulos 4, 5 y 7.



6.5 Fase II. Implantación y operación del SGSI

Aunque no es un requerimiento del estándar ISO 27001, es habitual que las organizaciones se apoyen en herramientas de gestión que proporcionen soporte, tanto para el establecimiento como para el manteni-miento continuado del SGSI. En el caso de la computación en la nube, dicha herramienta puede contribuir a automatizar el intercambio de información con los proveedores como, por ejemplo, la relativa a inciden-tes de seguridad, seguimientos de acuerdos de nivel de servicio, etc.

En caso de que se vaya a utilizar una herramienta de este tipo, su instalación conviene que sea realizada durante esta fase de la implantación del SGSI para contar desde el inicio con su asistencia y establecerse como principal herramienta gestora de forma intuitiva.

6.5.1 Evaluación del nivel de riesgoAl igual que en cualquier análisis de riesgos, una vez identificados y valorados los activos, las amenazas y los impactos es necesario valorar el nivel de riesgo existente, plasmándose los resultados en un mapa de riesgos.

Dicho mapa de riesgos se confeccionará en función de la metodología utilizada por cada organización (que deberá ser homogénea en el tiempo para permitir su comparación evolutiva) y ofrecerá, en cualquier caso, unos niveles de riesgo por activo (o agrupación de activos) y por amenazas (o tipo de amenazas), ya sea de manera cuantitativa o cualitativa.

Al margen de otras consideraciones, en los entornos de computación en la nube es importante que cliente y proveedor de los servicios sean conocedores de los niveles de riesgo de ambas partes. El cliente deberá conocer los niveles de riesgo que suponen los servicios ofrecidos en la nube y el proveedor deberá ser conocedor de los niveles de riesgo que el cliente está dispuesto a aceptar, en función de la relación de dichos servicios con sus procesos de negocio y el análisis realizado. Para ello, es básico que cliente y proveedor acuerden un lenguaje común que les permita comprender las clasificaciones y niveles de riesgo utilizadas por la otra parte.

Adicionalmente, también deberá existir transparencia en cuanto a las estrategias de gestión del riesgo empleadas por ambas partes, de forma que se eviten posibles faltas de alineamiento en la evolución futura de los niveles de riesgo.

6.5.2 Plan de AcciónLos planes de acción tienen las mismas características que en cualquier otra implantación de un SGSI (parten de los riesgos identificados en la fase anterior, son acordes a la disposición presupuestaria…) incluyendo la agrupación de los proyectos necesarios a desarrollar para la implantación de los controles identificados en la Fase anterior, y que deberán de ser abordados de forma planificada.

ControlesPrincipales

EvaluaciónRiesgo

PlanAcción

Normativa Básica

Ilustración 5. Etapas de la Fase II



En el caso de computación en la nube, dicho Plan de Acción deberá de ser sincronizado entre la empresa proveedora y su cliente para conseguir una adecuada evolución e implantación de los controles, que de otra manera no se podría realizar.

Es fundamental establecer hitos de seguimiento y revisión por cada proyecto realizado para comprobar que, durante todo el flujo de información entre las dos partes, se respetan escrupulosamente las medidas de controles establecidas en el documento de aplicabilidad de los controles.

El plan de Acción resultante de una compañía usuaria de servicios en la nube deberá considerar a su proveedor para evitar caer en posibles contradicciones o retrasos en la implantación de las medidas de control seleccionadas.

6.5.3 Desarrollo Normativo BásicoEl Desarrollo Normativo Básico constituirá el marco de referencia base para el SGSI, y estará basado en la ISO 27002 pudiendo incorporar los elementos que se consideren necesarios de otras fuentes, como, por ejemplo, la matriz de controles [CSA, diciembre 2010]. La premisa fundamental que se aplica es que no se puede exigir nada a ningún usuario que no se haya establecido previamente, y es precisamente mediante el establecimiento de este marco el que posibilitará este hecho. Dicho marco normativo básico debería de incluir, según nuestro criterio, los siguientes documentos:

• Normas de seguridad de la información. Partiendo de la Política de Seguridad de la Organiza-ción que establece las directrices que deben seguirse, las normativas de Seguridad desarrollan el ‘qué’ se debe hacer para conseguir alcanzar los objetivos de la Organización. Son funda-mentales para la prestación de servicios en la nube pues suponen el punto de partida para la definición de los requerimientos de seguridad que debe cumplir dichos servicios.

• Plan de concienciación de seguridad de la información.

• Procedimientos de clasificación de la información y de control y gestión de la documentación. Es necesario ser cautos en cuanto a los ámbitos en los que circulará la información para cerciorarse, no sólo de las medidas extras que se deben de poner en función del tipo de servicios en la nube contratado, sino además, si dicha empresa contratada podría soportar dichos requisitos.

• Procedimiento de gestión de incidencias de seguridad de la información. Un documento fun-damental en cualquier implantación pero que cobra especial importancia a la hora de definir el método y los participantes de ambas organizaciones en la gestión eficaz y eficiente de la incidencia y sus posibles repercusiones.

• Procedimientos de las auditorías necesarias dentro de la Organización. Establecerán el proce-so de auditoría interna que deberá de implantar la Organización, así como la necesidad de crear los mecanismos de colaboración mutua en función de las especificaciones que se hayan establecido en los acuerdos de nivel de servicio y del contrato entre el cliente y el proveedor del servicio en la nube.

• Procedimiento de control de acceso físico.



• Procedimiento de gestión de licencias de software. En el entorno de computación en la nube y dado que es fundamental aclarar dichos aspectos por contrato, es fundamental definir clara-mente los procedimientos de gestión de licencias63.

• Identificación de la legislación/normativa vigente aplicable. En función del tipo de servi-cio en la nube contratado, el sector en el que se ubica la Organización demandante y el ámbito geográfico es necesario identificar todos aquellos marcos regulatorios aplicables, así como los procedimientos de identificación establecidos para la identificación de los nuevos64.

• Plan de Recuperación de Desastres y de Continuidad de Negocio.

6.5.4 Implantación de los Controles PrincipalesDerivado del marco normativo gestado anteriormente, será necesario controlar claramente, qué controles se están incluyendo en cada documento concreto, qué registros se deberán generar para poder realizar la revisión de la evolución del control correspondiente y quién es el responsable de cada tarea. Este aspecto es fundamental dado que es imprescindible establecer los registros que se deben de revisar, así como asegurar el ciclo de vida de los mismos.

Además es necesario definir los indicadores que permitirán realizar la valoración del estado de implan-tación y madurez del propio SGSI, dichos indicadores serán complementarios a los ya incluidos en los controles procedentes del repositorio utilizado, matriz de controles [CSA, diciembre 2010] o ISO 27002, y su fin será medir el estado de implantación del SGSI en la Organización.

Es importante destacar el papel de todos los integrantes de la Organización en esta actividad, puesto que la implantación de los controles, y en consecuencia del mantenimiento de los registros, estarán cada una de las áreas involucradas.

6.6 Fase III. Seguimiento y mejora del SGSI

6.6.1 Desarrollo e implantación de la normativaEl desarrollo normativo consistirá, como en cualquier SGSI, en una serie de documentos exhaustivos con las especificaciones técnicas de los controles de seguridad necesarios para la Organización sobre la base de la Declaración de Aplicabilidad aprobada.

Esta fase se representa de forma independiente al Desarrollo Normativo Básico (apartado 6.5.3) para simbolizar la continuación de la implantación de controles, así como a la definición de indicadores para la valoración de su estado de implantación y efectividad. Dicha implantación estará planificada, según se especifique en el Plan de Acción.

63 Este aspecto es uno de los analizados con detalle en el Capítulo 7. Efectos de la computación en la nube sobre la contra-tación de servicios TIC.

64 Los aspectos relacionados con el cumplimiento normativo se han analizado en los Capítulos 4 y 5 previos.



Ilustración 6. Etapas de la Fase III

ImplantaciónNormativa

Auditoríainterna Certificación

Seguimiento y monitorización

Mejoracontinua

Comunicacióny divulgación

6.6.2 Seguimiento y monitorizaciónUna vez definidos, documentados e implantados los controles, deberá procederse a su monitorización sistematizada mediante el uso de mecanismos de seguimiento (por ejemplo con indicadores). El objetivo es la detección de problemas en su diseño y efectividad, posibilitando la identificación de mejoras en el SGSI.

El seguimiento de los controles puede realizarse mediante una herramienta de gestión del SGSI que, debidamente configurada, podría proporcionar la información necesaria para seguir la evolución de los controles así como informar sobre incidentes de seguridad.

En el caso de computación en la nube, deberá obtenerse por parte del proveedor una garantía indepen-diente sobre la implantación de los procesos de seguimiento y mejora de controles (por ejemplo, auditorías de terceros y/o informes del auditor de servicios). El resultado de dichos procesos deberá comunicarse y ser analizado por el cliente usuario de los servicios en la nube.

Se deberán definir las responsabilidades y los flujos de comunicación ante cambios e incidencias, teniendo en cuenta que dichas responsabilidades dependen del modelo SPI de implantación de los servicios en la nube.

6.6.3 Mejora ContinuaEl SGSI ha de estar sujeto a una mejora continua, para lo cual es necesario efectuar una debida gestión y seguimiento de los controles del SGSI. Dicha mejora continua debe ser establecida por los responsables del sistema, asegurando que se consideran todos los aspectos definidos en los puntos anteriores. En el caso de computación en la nube será necesario establecer una adecuada comunicación entre cliente y proveedor, así como un mecanismo conjunto de decisión respecto a la modificación e incorporación de nuevos controles para mantener el nivel de riesgo deseado.

6.6.4 Auditoría interna del SGSILa norma ISO 27001 exige la realización de auditorías internas sobre el SGSI. Se recomienda que los incumplimientos con dicha norma sean considerados como no conformidades mayores, menores u obser-vaciones, tal y como especifica el criterio utilizado por las entidades de certificación.



Las auditorias son especialmente relevantes en el caso de computación en la nube (sea cual sea su tipo, SaaS, IaaS o PaaS) debido al papel que desempeñan como garantía independiente para clientes usua-rios. Además de la ejecución de auditorías, el cliente deberá asegurar una adecuada colaboración con el proveedor y la corrección de las no conformidades detectadas. Para ello resulta fundamental la relación contractual entre ambas partes65.

6.6.5 Certificación del SGSILa organización, si así lo desea, podrá efectuar la auditoria de su SGSI por parte de una Autoridad Cer-tificadora. Para obtener el certificado, el SGSI deberá cumplir con todos los requisitos de la ISO 27001, así como haber considerado aquellos controles aplicables de la ISO 27002, sin desfavorecer a estándares relevantes como la matriz de controles [CSA, diciembre 2010].

6.6.6 Comunicación y DivulgaciónComo parte del proceso de mejora y seguimiento del SGSI, es necesaria una presentación regular a la Dirección sobre el proceso de seguimiento y mejora llevado a cabo y los resultados obtenidos, así como la evolución de los indicadores existentes. Este aspecto formará parte del mantenimiento del SGSI y se ejecutará al menos de forma anual.

En el caso de computación en la nube será necesario establecer unos canales adecuados de comunicación entre cliente usuario y proveedor para identificar las mejoras requeridas en el servicio, y las posibles mo-dificaciones el contrato, con el objetivo de formalizar el firme compromiso de mejora continua establecido entre ambas organizaciones.

6.7 Conclusiones

A modo de conclusiones generales de este capítulo en el que hemos tratado las particularidades de la implantación de un SGSI en un entorno de computación en la nube, podríamos decir que el establecimiento de un SGSI, tal y como establece el estándar ISO 27001, está basado en el principio PDCA de mejora continua. Y que este principio sigue siendo aplicable en el caso de la computación en la nube, así como el modelo general para el establecimiento, implementación, operación, supervisión, revisión, mantenimiento y mejora de un SGSI definidos en dicho estándar.

Por tanto, si debiéramos resaltar algo respecto a los SGSIs en los entornos de computación en la nube sería que no cambian en el fondo, pero sí en la forma:

• Es imprescindible establecer mecanismos de comunicación fluidos entre cliente y proveedor, así como, definir un lenguaje común en el que entender dichas comunicaciones. Esta comunicación afecta desde el comienzo de la definición del SGSI y continúa a lo largo de toda la implantación y operación posterior. El ejemplo más claro lo tendríamos en el caso de “SGSIs encapsulados” en los que los sistemas de gestión de una de las partes está incluido en el sistema de gestión de la otra a modo de “envoltorio”.

65 Para un análisis detallado de este tema consultar el Capítulo 7. Efectos de la computación en la nube sobre la contratación de servicios TIC.



• Los alcances certificados cobran una importancia extraordinaria pues son la forma en la que el proveedor informa al cliente sobre el o los entornos en los que aplicará el mencionado sistema de gestión.

• La definición clara de responsabilidades y roles en lo relativo al SGSI, considerando que puede aplicar a usuarios de distintas organizaciones es básico que se aborde lo más tem-prano posible durante el proceso de definición del SGSI.

• En lo relativo a todas las etapas necesarias para realizar un análisis de riesgos, la comuni-cación también es pieza clave, pues permite a las partes tener un lenguaje común en el que entenderse y definir los niveles de riesgos globales.

Los aspectos que podríamos considerar más diferentes respecto a sistemas “tradicionales” serían los rela-cionados con:

• La valoración de activos y de amenazas, puesto que son responsabilidad de distintos propietarios que deben coordinarse y entenderse. Normalmente, el cliente deberá conocer los niveles de riesgo que está dispuesto a asumir en función de la relevancia del activo y, por otra parte, el proveedor, debe conocer los niveles de riesgo que su operación de las tecnologías de la información y las comunicaciones (TIC) supone para sus clientes.

• Cierto tipo de amenazas muy características de la computación en la nube que implican nuevos riesgos en este tipo de entornos.

• El seguimiento, la monitorización y la auditoría, puesto que lo que antes se realizaba, con mayor o menor dificultad, dentro de la organización, ahora hay que ser capaz de seguir haciendo pero, considerando que probablemente, los activos y los procesos de negocio ya no pertenecen a la misma organización y es necesario entenderse con un tercero independiente de mi SGSI.



7.1 Introducción

La computación en la nube es un modelo de provisión de servicios de TIC cuya configuración por las partes en una relación B2B – Business to Business, es en principio libre, en virtud de la autonomía de la voluntad que rige la contratación.

No obstante, dependiendo del tipo de organización contratante y de la información que se vea involucrada en el ámbito de los servicios, es muy probable que existan requerimientos legales y regulatorios específicos, que deban ser tenidos en cuenta en el diseño del marco contractual que rija la relación de prestación de servicios.

Estos requerimientos legales y regulatorios lógicamente variarán dependiendo de factores como la ubica-ción geográfica y el sector de actividad de la entidad contratante o usuaria, entre otros, o simplemente dependerán de su participación en un mercado concreto. Algunos ejemplos los encontramos en Sarbanes Oxley, HIPAA, GLBA, PCI DSS, Esquema Nacional de Seguridad, Basilea o Solvencia, entre otras. Asimis-mo, en caso de que los servicios en la nube impliquen el tratamiento de datos de carácter personal (lo cual sucede en la mayoría de los casos) entran en juego las normas que regulan la privacidad y la protección de datos de carácter personal aplicables al cliente o usuario del servicio y/o al proveedor, y que varían en función de la jurisdicción en la que se encuentren, respectivamente66.

Como punto de partida para la contratación, la organización contratante deberá conocer muy bien sus obligaciones. Sin ello, no será posible cumplirlas y menos aún, trasladarlas a un proveedor de servicios en la nube mediante un contrato.

Estas obligaciones pueden provenir de distintas fuentes, a saber:

• Externas (generales y obligatorias): Se refieren al derecho positivo de un país y atañen al con-junto de normas jurídicas escritas que aplican a la entidad contratante, fundamentalmente, en virtud de su localización o de su sector de actividad.

• Internas:

• Normas y políticas corporativas de obligado cumplimiento para la organización (voluntarias). En muchos casos, estas normas y políticas ordenan la adopción de estándares existentes (por ejemplo, ISO 27001).

• Obligaciones contractuales (particulares) adquiridas por la organización.

Efectos de la computación en la nube sobre la contratación de servicios TIC

66 El impacto de la legislación en materia de protección de datos personales ha sido analizado en el Capítulo 4.



Como resultado del análisis de los requisitos de cumplimiento a los que está sometida la organización, se podrá determinar:

• La información susceptible de ser trasladada a la nube por no existir impedimento legal, norma-tivo o contractual alguno para ello.

• El tipo de despliegue de servicios en la nube que se deberá utilizar con relación a cada tipo de información, o en su caso, qué tipo de despliegue conviene utilizar. Por ejemplo, si una entidad del sector sanitario establecida en territorio español desea tratar datos clínicos de sus pacientes en la nube, debería asegurarse de que el proveedor tenga la capacidad necesaria para cifrar el tráfico de dichos datos. En algunos casos, puede que los costes de la implan-tación de ciertas medidas o controles de seguridad exigidos por la normativa, minimice o elimine el beneficio de ahorro de costes que se asume como inherente a las soluciones de computación en la nube.

• Finalmente, los requisitos que deberá exigir al proveedor mediante contrato, en aras del cum-plimiento de la organización en la nube.

Una vez que el proveedor tenga determinadas sus obligaciones, deberá analizar los riesgos específicos que supone dar el salto a la nube. En este sentido, es importante determinar la extensión geográfica o en otras palabras, el lugar de la ubicación de la infraestructura ya que la localización de los activos de información en determinadas jurisdicciones podría suponer un incremento de la carga regulatoria para la organización. Así mismo, se debe evitar que los activos de información se alojen en países con panoramas políticos o regulatorios inestables.

Mientras que en las nubes privadas y comunitarias este problema es fácilmente abordable, el mayor reto se presenta con relación a las nubes públicas e híbridas.

En el caso de las públicas e híbridas, el cliente deberá conocer, en primer lugar, dónde se podrían tratar potencialmente los datos, es decir dónde están los centros de proceso de datos del proveedor y, tras conocer del ambiente político y regulatorio existente u otras amenazas existentes (p.e. si es un lugar sísmico), deberá analizar los riesgos que supondría la prestación del servicio en esas condiciones.

En cualquier caso, resulta fundamental establecer dónde se podrán tratar potencialmente los datos por parte del proveedor, determinando una “lista blanca de países” autorizados.

En otro orden de ideas, la organización debe tener garantías de que va a poder responder en tiempo y forma a los requerimientos de las autoridades administrativas y/o jurisdiccionales, que afecten a sus activos de información, por lo que es conveniente articular plazos y mecanismos de respuesta ante dichos requerimientos, que permitan al cliente cumplir con eventuales exigencias de dichas autoridades.




Este capítulo, dedicado a analizar la contratación de servicios en la nube se ha estructurado entorno a los aspec-tos más relevantes que se han de tomar en consideración para la elaboración de dichos contratos (Ilustración 7):

• Mecanismos de resolución de conflictos • Confidencialidad • Propiedad intelectual • Responsabilidad • Resolución anticipada • Privacidad y protección de datos • Ley aplicable y jurisdicción • Auditabilidad • Seguridad • Acuerdos de Nivel de Servicio

Estos aspectos se han agrupado dentro de un mismo apartado para facilitar su localización y consulta en el presente documento.

Finalmente, se ha incluido también un apartado que resume las recomendaciones más importantes de las proporcionadas en el análisis de los aspectos mencionados.

Contratación

Mecanismos deresolución de

conflictos

Privacidad yprotecciónde datos

PropiedadIntelectual

Resoluciónanticipada

Ley aplicabley jurisdicción

Acuerdos deNivel de Servicios

Auditabilidad

SeguridadConfidencialidad

Responsabilidad

Ilustración 7. Elementos de la contratación



7.3 Mecanismos de resolución de conflictos

La deslocalización de servicios y la consecuente concurrencia de jurisdicciones intervinientes apuntan a la necesidad de definir contractualmente una ley y una jurisdicción aplicable.

En este sentido, articular mecanismos de resolución de conflictos puede ser de gran utilidad, máxime te-niendo en cuenta que la administración de justicia, en muchos casos, no cuenta con la celeridad y el nivel de especialización deseable y necesario para la resolución de conflictos en el ámbito tecnológico.

Dadas las características de la computación en la nube y teniendo en cuenta que es muy probable que las partes contratantes y los elementos del servicio estén en jurisdicciones diferentes, el arbitraje tecnológico es una buena opción a considerar como mecanismo alternativo para la resolución de conflictos.

7.4 Confidencialidad

La contratación en la nube exige en muchas ocasiones al prestador de servicios guardar la confidencia-lidad, no sólo de los datos o contenidos que el cliente aloja en sus servidores o que desarrolla en dicho entorno, sino el hecho mismo de la contratación. Dicha obligación de confidencialidad debe vincular, además de al propio prestador del servicio en la nube, también a sus empleados y/o colaboradores, respondiendo el proveedor de la actuación negligente o dolosa de éstos.

En este sentido, es relevante que el acuerdo de prestación de servicios que suscriba quien desea ac-ceder a la nube incorpore esta previsión, haciendo expresa referencia a que el término “Información Confidencial” sea lo más amplio posible, de tal manera que englobe toda la información referente al cliente, sus filiales o empresas de grupo, incluyendo los programas y las partes integrantes de dichos programas, sus procedimientos de desarrollo e implantación, su know-how, estructura inter-na, organización empresarial, planes de negocios, información financiera, documentación, diseños, invenciones, tecnología, precios, ventas, y en general, toda la información a la que eventualmente pudiera tener acceso el prestador del servicio con causa en el contrato. De esta manera se cierran las eventuales salidas o vías de escape que el prestador del servicio pudiera tener en materia de respon-sabilidad en caso de incumplimiento.

Otro de los puntos clave a tener en cuenta en materia de confidencialidad es la limitación de los supuestos en los que el prestador del servicio podrá revelar la información a terceros. Aunque la jurisdicción específi-ca que vaya a regir el contrato podrá contener previsiones específicas en este sentido, resulta conveniente limitar la revelación de datos a efectos de cumplir obligaciones legales o de requerimientos de autoridades competentes. En todo caso, de proceder, la revelación de datos o información ha de ser la mínima nece-saria para cumplir con cualesquiera obligaciones legales o requerimientos.

Igualmente, un dato a tener en cuenta en los supuestos en los que el tipo de información que se desea alo-jar en la nube sea extremadamente sensible para la organización es la posibilidad de exigir al proveedor del servicio que despliegue algún tipo de tecnología que tenga como objetivo identificar, monitorizar y proteger los datos alojados, como, por ejemplo, sistemas de prevención de fuga de datos o cualesquiera otros que cumplan tal fin. Asimismo, el establecimiento de medidas de seguridad en el acceso a datos por parte de empleados del prestador del servicio en la nube debe ser acotado y garantizado en función del tipo de información alojada, debiendo prever el contrato el control y trazabilidad en el acceso a informa-ción por aquellos.



Por último, y en consideración de los eventuales conflictos que pudiesen surgir, el cliente deberá exigir al proveedor del servicio la incorporación de una previsión que obligue a indemnizar al cliente por todos los daños de cualquier tipo causados, incluyendo los correspondientes gastos y costes y, de ser posible, la prefijación de cláusulas penales por tal concepto.

7.5 Propiedad Intelectual

Otro de los aspectos clave de la computación en la nube es el relativo a la propiedad intelectual, entendi-da ésta en su acepción anglosajona, esto es, como disciplina formada por derechos de autor y derechos afines, pero también aglutinadora de lo concerniente a marcas, patentes y diseño industrial.

La regulación de la propiedad intelectual en la nube y, en particular, las premisas que deben ser tomadas en consideración a la hora de contratar, apenas difieren de su regulación más tradicional, si bien es cierto que esta modalidad presenta una serie de particularidades en función del modelo concreto de servicio por el que se opte (IaaS, PaaS o SaaS).

• IaaS. En la medida que este modelo permite utilizar recursos de hardware de un proveedor en forma de servicio, de manera que el cliente puede adquirir recursos hardware como si se tratara de servicios externalizados, resulta necesario fijar en el acuerdo que, tanto los resulta-dos finales obtenidos por el cliente, como cualesquiera evoluciones parciales de los mismos son titularidad exclusiva del cliente, sin que corresponda al proveedor derecho de explotación de ningún tipo sobre los mismos, al igual que no corresponde al cliente derecho alguno sobre el hardware, más allá de la propia prestación del servicio.

• PaaS. Esta modalidad provee al cliente con todos los componentes necesarios para la crea-ción de aplicaciones informáticas desde la nube, ofreciendo un servicio que normalmente integra un entorno de desarrollo y una interfaz de programación de aplicaciones, ofrecien-do aquellas funcionalidades necesarias para que los diseñadores de software puedan desa-rrollar aplicaciones web y otras funcionalidades que se ejecuten en su plataforma. En materia de propiedad intelectual y sin perjuicio de que el entorno de desarrollo y la interfaz de programación de aplicaciones será, en todo momento, titularidad del proveedor, el contrato debe reflejar que el software desarrollado por el cliente le pertenece en su totalidad sin que el servicio prestado al cliente en ningún caso pueda generar derechos a favor del proveedor, ni económicos ni de otro tipo.

• SaaS. Esta modalidad es, posiblemente, una de las cuestiones más complejas de regular en materia de propiedad intelectual. Resulta muy complicado, en un entorno en el que se ofrece al cliente el consumo de gran variedad de aplicaciones proporcionadas por el proveedor del servicio y que se ejecutan en la infraestructura en la nube, discernir entre el servicio prestado y que es susceptible de generar derechos y el contenido creado por el propio cliente.

En todo caso, con carácter común a todo este tipo de servicios, el proveedor debe asumir que el acceso al contenido generado por el cliente, así como la reproducción, copia, modificación, comunicación públi-ca, distribución y cualquier otro tipo de cesión sobre el mismo constituye una infracción de la propiedad intelectual del cliente, previsto como tal en el derecho internacional y las leyes que resulten aplicables. Asimismo, el acceso no consentido por el proveedor del servicio a determinados datos supondría una vul-



neración del secreto de las comunicaciones en los supuestos en los que el servicio contratado en la nube tenga como contenido la provisión de comunicaciones entre usuarios.

En este sentido, el contrato ha de reflejar que la propiedad intelectual sobre cualesquiera contenidos ge-nerados por el cliente o que éste pueda compartir en la nube (incluida documentación comercial, códigos, así como cualquier otro elemento relacionado o derivado de aquéllos) pertenecerá en todo momento al cliente, reteniendo éste la plena titularidad sobre los mismos, no estando facultado el proveedor para su utilización de ningún modo.

Por tal motivo, el acuerdo no implicará en ningún caso la cesión de ningún derecho de propiedad intelec-tual a favor del proveedor, que ha de comprometerse a no copiar, plagiar, reproducir, ceder ni transmitir a terceros, parcialmente o en su totalidad, en ninguna forma ni por ningún medio.

7.6 Responsabilidad

Si existe un aspecto clave en todo contrato, además del referido a las propias obligaciones asumidas por las partes, éste es el de la responsabilidad.

Por este motivo, y a salvo de aquellas cuestiones que puedan quedar fuera del ámbito de control o volun-tad del prestador del servicio, éste ha de hacerse responsable frente al cliente de cualesquiera daños o perjuicios o de cualquier reclamación que pudiera surgir o que traiga causa en la suscripción del contrato. Por tal motivo, el prestador del servicio deberá asumir y mantener indemne al cliente de cualquier daño o perjuicio sufrido.

Uno de los puntos conflictivos en materia de responsabilidad es el referido a la concreta ley aplicable que rige el contrato. En caso de contratos sometidos a legislación de corte anglosajón, son frecuentes las limitaciones de responsabilidad de los prestadores de servicio y, en particular, la determinación de una cantidad económica –normalmente fijada en la cuantía desembolsada por el cliente en la contratación de la prestación del servicio-. Dichas previsiones son normalmente contrarias a las legislaciones de corte continental, las cuales permiten la limitación por negligencia pero no por culpa o dolo. La incorporación de una de estas previsiones en supuestos en los que el contrato está sometido a una legislación de corte continental, devienen en nula dicha previsión.

7.7 Resolución anticipada

Sin perjuicio de las múltiples variantes que pueden influir en la estipulación de resolución anticipada, que debe figurar de manera obligada en cualquier contrato (tenga o no su base en la nube) consideramos relevante apuntar los siguientes datos a modo de recomendación de mejores prácticas.

Con carácter general es recomendable que el cliente tenga una salida67 en el contrato que le permita salirse del mismo sin necesidad de alegar justa causa, mediante el envío de un preaviso. Esta previsión es absolutamente relevante en contratos que tienen como sustento la tecnología porque lo que, en una fecha puede ser apto para las necesidades del cliente, pude no serlo tanto en un futuro relativamente cercano.

67 Del inglés, way out.



Lo anterior es lo deseable, pero no siempre resulta posible. Por tal motivo, es recomendable asegurar que la resolución anticipada del contrato sin causa no suponga un perjuicio económico inasumible para el cliente en caso de que, por cualquier motivo, sea su deseo resolver anticipadamente el contrato. En este sentido, identificar cualquier penalización o exigencia de pago íntegro del servicio es crucial, a efectos de eliminarla del contrato cuando sea posible o, en caso contrario, asumir el riesgo implícito en ello.

Sin perjuicio de lo anterior, en servicios en la nube, al objeto de garantizar la disponibilidad de acceso a la información por el cliente en todo momento, incluso en el momento de la extinción de la relación, resultaría necesario que el proveedor estuviese contractualmente obligado a cooperar en el marco de una migración de datos a la nueva infraestructura que indique el cliente.

7.8 Privacidad y protección de datos68

La cláusula de protección de datos se ha convertido, sin lugar a dudas, en uno de los elementos clave de todo contrato en el que se regulen servicios relacionados con el tratamiento de información. Y ello por un motivo sencillo: prácticamente todas las compañías cuentan con ficheros con información personal entre sus activos intangibles, que se ven afectados por las legislaciones en materia de privacidad y protección de datos de carácter personal, especialmente estrictas en Europa.

Son varios los factores que deben ser tenidos en cuenta antes de decidir el salto a la nube. El primero, y más importante, es determinar cuál es el rol del cliente desde el punto de vista del tratamiento de este tipo de datos:

• Si tiene capacidad de decisión sobre la finalidad, el contenido y el uso de la información, la empresa será considerada responsable del tratamiento.

• Si carece de dicha capacidad, y se limita a tratar los datos personales por cuenta de un tercero en el marco de la prestación de un servicio, hablaremos de un encargado del tratamiento.

Pues bien, sólo los responsables del tratamiento pueden tomar la decisión de enviar su información a la nube libremente. En lo que a los encargados se refiere, la situación es mucho más compleja, puesto que la posibilidad de saltar a la nube dependerá de los pactos previstos en materia de subcontratación en el contrato de prestación de servicios que haya firmado con el responsable, y de la normativa a la que quede sometido el tratamiento de datos, que no siempre será la nacional.

Determinado este rol, será también necesario conocer el papel correspondiente al proveedor de servicios en la nube. Partiendo de la base de que dicho prestador es una empresa distinta del cliente, con el que se establecerá un contrato de servicios B2B. De este modo, y con independencia del rol del cliente, el proveedor será considerado encargado del tratamiento, circunstancia que se deberá hacer constar en el contrato de prestación de servicios.

Dependiendo de la normativa a la que se encuentre sometido el tratamiento de datos (que, por regla ge-neral, suele ser la correspondiente al responsable del tratamiento), el contrato de prestación de servicios podrá ver condicionado su contenido por una serie de obligaciones específicas. Obligaciones que pueden

68 Este tema se aborda en este capítulo de manera muy general puesto que ha sido analizado con detalle en el Capítulo 4.



verse ampliadas en caso de que los centros de proceso de datos empleados por el proveedor de servicios en la nube se encuentren situados en el extranjero; y ello porque es habitual que las legislaciones de pro-tección de datos incluyan restricciones a las transferencias internacionales de datos personales.

Ante la imposibilidad de analizar todos los regímenes jurídicos vigentes, se analizará a continuación el caso de la legislación española, una de las más detalladas, que regula el contenido mínimo del contrato en la LOPD, y en concreto en su artículo 12; así como en los artículos 21 y 22 de su Reglamento de de-sarrollo:

• Debe establecer que el proveedor de servicios en la nube, únicamente tratará los datos siguien-do las instrucciones del responsable del tratamiento.

• Debe recoger las finalidades del tratamiento de datos (que, como regla general, coincidirán con el objeto del contrato), y que no se aplicarán ni utilizarán los datos para ninguna finalidad distinta a la prevista.

• Debe figurar el nivel de seguridad aplicable a los ficheros, conforme a la clasificación prevista en el artículo 81 del Reglamento de desarrollo de la LOPD; así como las medidas de seguridad que lleva aparejadas, que serán de obligada implementación para el proveedor de servicios en la nube.

• Debe aclarar que no se comunicarán los datos a otras personas, ni siquiera para su conserva-ción.

• Sin perjuicio de lo anterior, y teniendo en cuenta que en la prestación de estos servicios se utilizan servidores alquilados (hosting) o ubicados en instalaciones de terceros (housing), es altamente recomendable que la cláusula incluya un apartado en el que se especifique:

o Que la información puede ser almacenada y procesada en servidores que pertenez-can a o que estén ubicados en terceras empresas, únicamente por motivos técnicos.

o Que el tratamiento realizado por dichas terceras empresas se ajustará en todo caso a las instrucciones del responsable del fichero.

o Que el proveedor de servicios de computación en la nube se compromete a forma-lizar contratos con todas las terceras empresas que presten servicios conforme al artículo 12 de la LOPD.

• Debe dejarse constancia, finalmente, que en caso de que se rescinda el contrato, por cualquier causa, los datos de carácter personal deberán ser destruidos o devueltos al responsable del tratamiento, salvo en aquellos casos en los que una previsión legal exija o permita su conserva-ción, en cuyo caso se conservarán debidamente bloqueados.

Sin embargo, la firma de una cláusula que incluya todos los contenidos anteriormente citados no resulta suficiente en la práctica para evitar posibles sanciones. El responsable del tratamiento, igualmente, deberá velar por que el encargado del tratamiento reúna las garantías para el cumplimiento de la legislación vigente, lo que se traduce en una doble obligación: elegir un proveedor de servicios adecuado, y asegu-



rarse de que cumple con la ley. Teniendo en cuenta la dificultad que esto entraña en la práctica, se hace recomendable añadir dos apartados más a la cláusula que nos ocupa:

• Uno en el que el proveedor de servicios declare reunir las garantías suficientes para cumplir la legislación vigente en materia de protección de datos y, en especial, en relación con las medi-das de seguridad técnicas y organizativas aplicables a los tratamientos a efectuar.

• Otro en el que se prevea la posibilidad de que el responsable de seguridad verifique el cumpli-miento de la legislación, y que se debe poner en relación con la cláusula relativa a auditabili-dad, que veremos más adelante.

Por otra parte, y en el probable caso de que todos o parte de los servidores utilizados por el provee-dor de servicios de computación en la nube se encuentren ubicados físicamente en Estados ajenos al Espacio Económico Europeo, deberá tenerse en cuenta el régimen de transferencias internacionales de datos previsto en los artículos 33 y siguientes de la LOPD. Si además, el Estado de destino no está reconocido como “adecuado” por la Comisión Europea o por la Agencia Española de Protección de Datos, puede ser necesaria la solicitud de una autorización al Director de dicha Agencia. Un proceso que, dependiendo de las circunstancias, puede llegar a ser largo y tedioso, a pesar de la existencia de una serie de cláusulas contractuales tipo aprobadas por la Comisión Europea que han contribuido a su simplificación.

Por último, y como apartado adicional, y en caso de que las partes acuerden que sea el proveedor de servicios en la nube quien realice la llevanza del documento de seguridad al que obliga el citado RLOPD, esta circunstancia se tendría que hacer constar igualmente en el contrato.

7.9 Ley aplicable y jurisdicción

Sin lugar a dudas, uno de los problemas fundamentales que nos podemos encontrar en un contrato de prestación de servicios en la nube es el derivado del contraste entre la universalidad de la red con respecto a la compartimentación de las normas y los Estados. Los ordenamientos jurídicos tienden a establecer el te-rritorio como ámbito de aplicación, mientras que la información colgada en la red no conoce de fronteras y fluye, en la práctica, con total libertad de un punto a otro del planeta.

Resulta evidente que la forma más sencilla de lidiar con esta problemática es lograr que tanto la ley aplica-ble al contrato, como los juzgados que se designen para resolver las posibles controversias que resulten de la interpretación del mismo, sean los más cercanos al lugar donde se encuentre el establecimiento o sede de la empresa. Por ejemplo, parece lógico que una sociedad cuya sede se encuentre en Madrid prefiera que la ley aplicable sea la española, y los tribunales competentes los de la capital de España, principal-mente por comodidad, proximidad y mejor conocimiento de la normativa local.

No obstante, no siempre resulta sencillo lograr que tanto ley como jurisdicción recaigan en el propio país. En la práctica, la decisión definitiva termina por depender de la capacidad de negociación de las partes, de tal forma que aquella empresa que goce de una posición más fuerte termina por imponer sus condi-ciones, y por tanto el fuero que le resulta más conveniente. En todo caso, las partes deben ser conscientes de que estamos ante una decisión de gran relevancia, especialmente cuando se pretende hacer valer las condiciones de un contrato en caso de incumplimiento.



Lo que resulta recomendable, en todo caso, es hacer que los tribunales competentes estén siempre some-tidos a la ley aplicable. Por ejemplo, carecería de sentido afirmar que la legislación a aplicar es la del estado de Washington, pero que los conflictos deben ser dirimidos por los juzgados de Zaragoza, puesto que sería realmente complicado que el órgano español pudiese juzgar (y sobre todo, ejecutar la sentencia) en base a la legislación norteamericana.

Finalmente, debe tenerse en cuenta que esta cláusula será complementaria con la de resolución de con-flictos, a la que nos hemos referido con anterioridad, por lo que ambas deben redactarse con especial cuidado para evitar contradicciones.

7.10 Auditabilidad

Dentro de los factores relevantes a la hora de configurar la contratación de servicios de computación en la nube, uno de los que ha tenido entrada más tardía, y probablemente menor atención hasta hace poco, ha sido la auditabilidad, entendida como la capacidad por parte del cliente que contrata los servicios para auditar la actividad del proveedor. Expresado en estos términos, se trata de un concepto de gran amplitud, y que puede alcanzar una elevada complejidad de puesta en práctica, por lo que se debe personalizar en cada caso y en cada contrato de servicios en la nube.

Antes de entrar en la proposición de parámetros de configuración de la cláusula de auditabilidad, hay que indicar que es importante que se configure de modo que no se solape o contradiga con el contenido del correspondiente Acuerdo de Nivel de Servicio.

Entrando en la configuración de la cláusula, en primer lugar, los tipos de auditorías que se pueden incor-porar a la correspondiente cláusula serían las siguientes (Ilustración 8):

1. Auditoría de cumplimiento normativo. Aquella dirigida al cumplimiento de una obligación legal que establezca la necesidad de realizar una auditoría sobre un determinado ámbito, alcance, controles, periodo, etc.

2. Auditoría de cumplimiento de estándares, buenas prácticas y otras normas no legales. Aquella dirigida al cumplimiento de un requisito establecido en una norma de carácter no legal pero que el cliente ha decidido cumplir (por ejemplo, para obtener o mantener una certificación).

Auditoría decumplimiento

normativo

Auditoría depolíticaspropias

Auditoría decumplimientode estándares

Auditoría sobrepuntos de control

del contrato

Ilustración 8. Tipos de auditoría

Tipos deauditoría



3. Auditoría de cumplimiento de las políticas propias del cliente. En muchas ocasiones, el cliente de com-putación en la nube tiene un cuerpo normativo propio, que igualmente son objeto de auditoría. (por ejemplo, normas de uso de correo, controles asociados al Código ético, etc.). Por tanto, los proveedores de servicios en la nube deberán tener la capacidad de responder a necesidades de auditoría derivadas de cuerpos normativos internos del cliente.

4. Auditoría sobre puntos de control establecidos en el propio contrato. En el propio de servicios en la nube se pueden incorporar necesidades específicas de auditoría, en función del acuerdo entre las partes. No obstante, se deberá verificar que no hay solapamientos ni contradicciones con el Acuerdo de Nivel de Servicio correspondiente.

En segundo término, se pueden señalar una serie de factores críticos a valorar en la configuración de la cláusula de auditabilidad, que van a influir en el éxito de la misma (Ilustración 9):

1. Alcance geográfico. Se deben delimitar las ubicaciones físicas del proveedor de servicios en la nube (por ejemplo, centros de procesos de datos) que en definitiva están “detrás” de la nube y que se pre-tende auditar.

2. Capacidad de auditar a los subcontratistas del proveedor. Tan importante o más, en ocasiones, que la capacidad de auditar al proveedor de servicios en la nube, puede ser el disponer de la capacidad para extender la auditoría a sus proveedores críticos que tengan un impacto efectivo en dichos servicios.

Factorescríticos

Alcancegeográfico

Auditoresautorizados

Auditoría a subcontratados

Acceso a otrasauditorías

Resultados dela auditoría

Gastosgenerados

Ilustración 9. Factores críticos para definir las auditorías



3. Acceso a otras auditorías. En muchas ocasiones, el proveedor de servicios en la nube va a tener que realizar sus propias auditorías (por obligación legal, estándares, política interna…), por lo que se debe establecer si su cliente puede acceder a los resultados de tales auditorías.

4. Quién puede realizar la auditoría (por sí o por terceros). Si para el proveedor de servicios en la nube puede ser difícil de asimilar que su cliente le audite, más lo puede ser el permitir que sea un externo contratado por el cliente quien lo haga, considerando incluso posibles vínculos con competidores.

5. Gastos generados. ¿Quién asume los gastos que para el proveedor tiene la auditoría exigida por su cliente?

6. Resultados de la auditoría. En este sentido, se debe delimitar si el proveedor va a tener acceso al resul-tado de la auditoría y si ésta va a tener algún efecto sobre el contrato de computación en la nube.

7.11 Seguridad

El planteamiento de base de la seguridad como parte de un servicio de computación en la nube debería ser que no debe haber ningún sacrificio, menosprecio, minoración, diferenciación o desestimación del concepto de seguridad por el hecho de que los servicios sobre los que se establece se presten en modo servicio en la nube.

Una buena forma de afrontar la seguridad en un contrato de computación en la nube puede ser tomar como punto de partida, previo a la configuración y puesta en explotación del servicio, la realización de un Análisis de Riesgos que permita identificar aquellos riesgos prioritarios o más relevantes para la orga-nización antes de poner en práctica una estrategia de computación en la nube69.

De ese modo, se podrán incorporar al contrato de adquisición de servicios en la nube aquellas medidas que permitan al cliente del servicio reducir los riesgos identificados hasta alcanzar el umbral de riesgo asu-mible que se haya fijado (teniendo en cuenta que cada organización tiene un perfil de riesgo diferente).En este sentido, la incorporación de los factores relativos a seguridad en el contrato de computación en la nube puede estructurarse, entre otras muchas formas, en base a los criterios de seguridad ACIDA70. A modo de ejemplo, se proponen como factores a incorporar:

69 Los análisis de riesgos han sido analizados en relación a la computación en la nube en el Capítulo 6. Sistemas de Gestión de la Seguridad de la Información en la nube.

70 Acrónimo de las cinco dimensiones consideradas: A – Autenticidad, C – Confidencialidad, I – Integridad, D – Disponibi-lidad y A – Auditabilidad.



De manera añadida, e introduciendo un concepto de gran interés desde hace un tiempo en el ámbito de la privacidad, se podría añadir como un aspecto adicional (aunque sin considerarlo una dimensión de la seguridad), el principio de ‘responsabilidad’71. Este principio y su significado no tiene una relación, más allá de la nominal, con la responsabilidad que se analizaba en un punto anterior, como se podrá apreciar de la definición conceptual que se recoge a continuación.

Y ello por cuanto que este principio vendría a suponer que quienes estén tratando o procesando informa-ción, tanto de datos personales como cualquier otra información sometida o afectada por algún tipo de normativa, deberán aplicar medidas adecuadas y eficaces para poner en práctica los principios y obliga-ciones que establecería la normativa aplicable, y demostrar tal cumplimiento cuando así le sea exigido. En definitiva, el principio de responsabilidad incorpora dos elementos principales:

71 En inglés, accountability.

Tabla 3. Estructura de medidas de seguridad según criterios ACIDA

Criterio Medidas

Autenticidad

• Fuentes de datos• Seguridad de base de datos• Encriptación• Enmascaramiento• Etc.

Confidencialidad

• Identificación usuarios• Gestión de roles• Control de difusión• Seguridad en dispositivos móviles• Comunicaciones• Seguridad base de datos• Acceso físico a instalaciones• Especialización del personal• Etc.

Integridad

• Trazabilidad • Respaldo• Recuperación• Controles de consistencia• Garantías de exportación a otros sistemas (en la nube o no)• Etc.

Disponibilidad

• Respaldo• Recuperación• Contingencias informáticas• Continuidad de negocio

• Comunicaciones• Ventanas de mantenimiento• Respuesta a incidentes• Etc.

Auditabilidad

• Monitorización• Comunicación de brechas de seguridad• Evidencia electrónica• Etc.



•La necesidad de que el responsable de la información o del procesamiento de la misma adopte medidas adecuadas y eficaces para cumplir los principios que se establezcan en la normativa aplicable a tales datos o a su tratamiento o procesamiento;

•La necesidad de demostrar, si así se requiere, que se han adoptado medidas adecuadas y eficaces; así pues, el responsable de la información o del procesamiento de la misma deberá generar pruebas de lo indicado en el punto anterior.

7.12 Acuerdos de Nivel de Servicio (ANS)

Una parte fundamental de todo contrato de computación en la nube es el Acuerdo de Nivel de Servicio (ANS), que muchos identificarán mejor bajo sus siglas en inglés SLA (Service Level Agreement).

El National Institute of Standards and Technology (NIST) ha publicado el documento “Guidelines on Secu-rity and Privacy in Public Cloud Computing” [NIST, 2011], que contiene una interesante disertación sobre qué es un ANS: “Un ANS representa la comprensión entre el cliente y el proveedor de servicios en la nube sobre el nivel esperado del servicio que se va a entregar y, en caso de que el proveedor falle en entregar dicho servicio al nivel especificado, la compensación disponible para el cliente. Un ANS, sin embargo, típicamente forma solo una parte de los términos de servicio estipulados en el contrato o en el acuerdo de servicio general. Los términos de servicio cubren otros detalles importantes tales como licencia de servicios, criterios de usos aceptables, suspensión y finalización del servicio, limitaciones de disponibilidad, política de privacidad y modificaciones en los términos del servicio.”

Por tanto, lo primero que tenemos que tener en cuenta es que el ANS es una parte del contrato de presta-ción de servicios de computación en la nube, y seguramente una de sus partes más relevantes. Lo que no excluye que se incorpore al contrato como parte del cuerpo principal o como un anexo.

Es fundamental tener en cuenta que el ANS viene a reflejar, sea negociado o no, las expectativas del cliente en cuanto a qué espera del servicio en la nube que ha contratado. Es por ello que, tanto el cliente como el proveedor, del servicio en la nube deben de tener muy claro que entienden del mismo modo los indicadores, métricas y penalizaciones/bonificaciones incorporadas al ANS. En cuanto a una posible definición de estos tres últimos conceptos, se puede proponer la siguiente (Ilustración 10):

Ilustración 10. Componentes del ANS

Penalizaciones/ bonificaciones

Métrica

ANS

Indicadores



• Indicadores. Parámetros por los cuáles se va a medir el desempeño del servicio en la nube.

• Métrica. Modo de representación de los resultados obtenidos de los indicadores, teniendo en cuenta que un mismo indicador (por ejemplo, tiempo de indisponibilidad del servicio), puede contrastarse contra muchas referencias, dando lugar a diferentes métricas (periodo temporal, criticidad del periodo en el que ocurre, servicios afectados, comparación con la competen-cia, etc.).

• Penalizaciones / bonificaciones. Son aquellos efectos que se producen en el caso de que las métricas alcancen determinados valores acordados por las partes, y que normalmente se tradu-cen en un perjuicio / beneficio económico para el proveedor.

En cuanto a la elección de los indicadores que se pueden incorporar a un ANS, pueden ser tantos como servicios en la nube son posibles, teniendo en cuenta además que, para un mismo servicio, puede haber diferentes indicadores, en función de las necesidades y expectativas de cada cliente (siempre que sea posible negociar los indicadores a utilizar, claro está). En todo caso, existen ciertos parámetros que pueden tener en cuenta en la selección de indicadores, de modo que los indicadores sean:

• Específicos. Cuanto más específicos sean, más se reduce el riesgo de conflicto.

• Medibles. Es fundamental que el modo de medir sea objetivo, para evitar discrepancias e inclu-so facilitar la auditabilidad por terceros.

• Alcanzables. Realmente pocos proveedores de servicios en la nube van a permitir indicadores no alcanzables si pueden conllevar penalizaciones.

• Realistas. Se debe tener en cuenta que los indicadores responden a expectativas, por lo que serán estas las que, en primer término, sean efectivamente realistas.

7.13 RecomendacionesComo resumen, y a modo de recomendaciones del presente capítulo, podríamos considerar las siguientes:

• Confidencialidad: En materia de confidencialidad, es absolutamente relevante que el acuer-do de prestación de servicios que suscriba quien desea acceder a la nube incorpore una previsión de confidencialidad, previendo que el término “información confidencial” sea lo más amplio posible y salvaguarde al máximo los intereses de quien contrata. Asimismo, debe acor-darse expresamente la limitación de los supuestos en los que el prestador del servicio podrá revelar la información a terceros.

• Propiedad Intelectual: En lo que a propiedad intelectual se refiere, el contrato ha de reflejar que la propiedad intelectual sobre cualesquiera contenidos generados por el cliente o que éste pueda compartir en la nube (incluida documentación comercial, códigos, así como cualquier otro elemento relacionado o derivado de aquéllos) pertenecerá en todo momento al cliente, reteniendo éste la plena titularidad sobre los mismos, y no estando facultado el proveedor para su utilización de ningún modo.



• Responsabilidad: En materia de responsabilidad, y a salvo de aquellas cuestiones que puedan quedar fuera del ámbito de control del prestador del servicio, éste ha de hacerse responsable frente al cliente de cualesquiera daños o perjuicios o de cualquier reclamación que pudiera surgir o que traiga causa en la suscripción del contrato, debiendo el prestador del servicio asumir y mantener indemne al cliente de cualquier daño o perjuicio sufrido.

• Resolución anticipada: En lo relativo a resolución anticipada, es recomendable que el cliente tenga una salida en el contrato que le permita salirse del mismo sin necesidad de alegar justa causa, mediante un simple preaviso. Esta previsión es absolutamente relevante en contra-tos que tienen como sustento la tecnología porque lo que en una fecha puede ser apto para las necesidades del cliente, puede no serlo tanto en un futuro cercano.

• Privacidad y protección de datos: Se trata éste de uno de los ámbitos más delicados de la contratación a la nube. El cliente de computación en la nube debe analizar la legislación apli-cable al tratamiento de datos que realice, y comprobar si está legitimado para contratar el ser-vicio. Para ello, deberá identificar previamente su condición de responsable o encargado del tratamiento. Exigirá igualmente al proveedor de servicios en la nube garantías de su capacidad de cumplir con la legislación y, además, el contrato hará constar que los datos serán tratados por cuenta del cliente y siguiendo sus instrucciones. Y ello, sin perjuicio de otros condicionantes fijados en la legislación nacional, y de la obtención las autorizaciones de transferencias inter-nacionales que resulten necesarias.

• Ley aplicable y jurisdicción: Partiendo de la base de que toda compañía debe aspirar a establecer como ley aplicable y jurisdicción las que más le convengan, que habitualmente serán aquéllas más cercanas a su sede, y que no siempre contará con capacidad de negociación para lograrlo... cuando menos, deberá velarse por que la ley aplicable y la jurisdicción sean coincidentes.

• Auditabilidad: Este concepto se refiere a la capacidad por parte del cliente de servicios en la nube para auditar la actividad del proveedor. Es importante que se configure de modo que no se solape o contradiga con el ANS. Puede haber diferentes tipos de auditoría (de cumplimiento normativo, de cumplimiento de estándares o buenas prácticas, etc.), y en su configuración se han de considerar aspectos como el geográfico, o la capacidad de auditar a los subcontratistas del proveedor.

• Seguridad: La contratación de servicios en la nube no debe suponer sacrificio, menosprecio, minoración, diferenciación o desestimación del concepto de seguridad. En este sentido, la in-corporación de los factores relativos a la seguridad en el contrato de computación en la nube puede estructurarse, entre otras muchas formas, en base a los criterios de seguridad ACIDA.

• Acuerdo de Nivel de Servicio: Es fundamental tener en cuenta que el ANS viene a reflejar, sea negociado o no negociado, las expectativas del cliente en cuanto a qué espera del servicio en la nube que ha contratado. Es por ello que, tanto el cliente como el proveedor del servicio de computación en la nube, deben de tener muy claro que entienden del mismo modo los indi-cadores, métricas y penalizaciones / bonificaciones incorporadas al ANS.


8.1 Introducción

Para aquellos profesionales del sector legal o de la informática forense, la mera definición del concepto de “prueba electrónica” o “evidencia electrónica” ya supone todo un debate, sobre todo por las conse-cuencias jurídicas que dicha definición conlleva. Con el objetivo de evitar cualquier debate que pudiera distraernos del objetivo de nuestro estudio y con el fin de estandarizar los conceptos que trataremos en este apartado, definiremos la prueba electrónica como “cualquier dato almacenado o transmitido en forma digital y que por sus características pudiera ser utilizado para probar algún hecho en un procedimiento judicial”.

Si bien es cierto que la computación en la nube no es únicamente una plataforma de almacenamiento de información y archivos sino también un nuevo modelo de prestación de servicios de negocio y tecnología, a la hora de analizar el procedimiento de gestión de pruebas electrónicas de computación en la nube, este documento se centrará básicamente en la información y datos almacenados en este entorno y no como prestador de servicios, pues es del análisis de los datos de donde obtendremos un conjunto de indicios que reconstruirán la cadena de acontecimientos constituyendo pruebas electrónicas.

La informática forense, cuyo objetivo es la aplicación de técnicas y metodologías que permitan identificar, extraer, preservar y analizar datos en formato electrónico que sean admisibles en un procedimiento legal, es un sector que cuenta con una ya reconocida madurez (sin referirnos a los aspectos jurídicos de la ma-teria). Existen numerosas herramientas y metodologías en el mercado que facilitan cada una de las tareas relacionadas con la gestión de pruebas electrónicas. Aunque si bien, y dejando fuera de momento los aspectos jurídicos de la materia, las herramientas existentes facilitan de gran manera el trabajo a realizar, siempre existe un componente de complejidad atado al medio o repositorio tecnológico en donde se en-cuentra la prueba electrónica. Esto es, la dificultad de extraer, de forma forense, un fichero del disco duro de un portátil no es la misma que extraer el registro de una base de datos de diversos terabytes que a su vez se encuentra almacenada en una arquitectura de almacenamiento del tipo RAID.

Sin duda alguna, es este último aspecto el que nos lleva a desarrollar este apartado, la dificultad que conlleva trabajar con pruebas electrónicas ubicadas en entornos de computación en la nube está definida en su mayor parte por los retos que supone trabajar con las arquitecturas que permiten que nuestras soluciones o servicios en la nube sean escalables, económicos, eficaces, etc.


El presente capítulo incluye un apartado que reflexiona sobre el impacto de las principales amenazas de los entornos de computación en la nube sobre las evidencias electrónicas, precedido por otro apartado que desgrana la problemática relativa a esta materia.


La obtención de evidencias digitales en la nube



Finalmente, el último apartado del capítulo presenta un resumen de las principales recomendaciones iden-tificadas a lo largo de todo el capítulo presente.

Finalmente, se incluye como Anexo III, el tratamiento que recibe la prueba electrónica en el marco legal Español.

8.3 La problemática

Las características del diseño que nos permiten acceder a las ventajas típicas de los entornos de computación en la nube se convierten, a su vez, en los grandes retos tecnológicos a afrontar en la obtención de pruebas electrónicas en este tipo de arquitecturas. Aunque si bien dichos retos se han ido afrontando a lo largo de los años, en arquitecturas similares, mediante la variación de técnicas utilizadas en la informática forense tradicional, aún existen retos que se acentúan con la adopción masiva de la computación en la nube.

8.3.1 Responsabilidad compartidaEl modelo tradicional de las grandes empresas, en lo que a la gestión de sus datos se refiere, consiste en que, o bien la misma empresa cuenta con su propia infraestructura y personal necesario para gestionar sus datos y servicios tecnológicos, o bien se cuenta con algún proveedor que le ofrece un servicio personaliza-do (housing, hosting) el cual le proporciona un control casi completo sobre sus datos.

Ante algún incidente de seguridad, el cliente del servicio contará con la posibilidad de acceder de forma ilimitada a los recursos requeridos para iniciar una investigación y, por tanto, se le permitirá actuar de la forma más eficiente posible.

Ilustración 11. La problemática de las evidencias

MultiposesiiónEvidencias

Responsabilidadcompartida

Distribucióngeográfica

Arquitecturas



Por otro lado, el modelo de computación en la nube pasa a ser un modelo compartido, en el que los datos siguen siendo propiedad de los clientes pero las aplicaciones o servicios que gestionan estos datos pueden ser propiedad del proveedor y por tanto:

• Es más difícil determinar cómo o con quien debe contactarse en caso de que se produzca una incidencia de seguridad o cualquier otro evento que requiera una investigación forense.

• Será más complicado implantar metodologías de “forensic readiness” que permitan establecer el sistema de respuesta a incidentes que más se adecue a nuestra organización.

• Es probable que existan problemas de jurisdicción en cuanto a la ubicación geográfica en la que se almacenan los datos y que por tanto pudieran convertirse en impedimentos para la garantía de la cadena de custodia.

• Adicionalmente, la facilidad de contratar servicios “on-the-go” de varios proveedores de com-putación en la nube puede significar que en algún momento los clientes se encuentren utilizando servicios de algún proveedor desconocido y que, por tanto, se complique la toma de contacto con el mismo en caso de algún incidente.

8.3.2 MultiposesiónUno de los procedimientos más eficaces y comúnmente utilizados para la gestión de pruebas electrónicas en entornos tradicionales es la copia forense del o de los discos duros que almacenan aquellos datos que pueden convertirse en pruebas digitales. Una vez se dispone de la copia del dispositivo, y siempre siguien-do las metodologías que permitirán garantizar la admisibilidad de la prueba, el analista podía proceder con calma a realizar el análisis en todo el disco para poder así localizar las pruebas más adecuadas para la investigación (‘offline forensic’). Este tipo de análisis tiene como objetivo, no solo identificar las pruebas electrónicas más relevantes para la investigación, sino también adquirir aquellas pruebas electrónicas de “entorno” que permitirán ratificar, si fuese necesario, la veracidad o autenticidad de la prueba principal.

Evidentemente, el escenario ideal es aquel en el que el investigador tiene acceso total al disco o dispositivo en donde se encuentran todos los datos relevantes para la investigación. Sin embargo, dada la caracte-rística de multi-posesión que suelen tener casi todos los servicios en la nube, es muy probable que en una misma infraestructura se encuentren datos de distintos clientes y que no cuenten con garantías absolutas de aislamiento. Es por esto que, dado que el proveedor tendrá la necesidad de garantizar la privacidad y seguridad de sus clientes, la posibilidad de que el proveedor nos permita un acceso completo a la arqui-tectura que almacena nuestros datos es muy poco probable.

8.3.3 Distribución geográficaEn los entornos tradicionales, los clientes pueden controlar de cierta forma la ubicación de sus datos y por tanto actuar de forma correspondiente a la hora de extraer o eliminar algunos de sus datos. Aún en el caso de que las pruebas relevantes en una investigación estuviesen almacenadas en un servidor remoto, el propietario de los datos siempre podría, con los permisos necesarios, acceder de forma remota a dicha información.

En entornos de computación en la nube por otro lado, una de las ventajas con las que cuentan los clientes es el fácil acceso que se tienen a proveedores de servicios que se encuentran fuera de su ámbito geo-gráfico y que le permiten acceder a servicios más competitivos. Sin embargo, esta globalización de la información es quizás una de las problemáticas más comentadas en cuanto a la seguridad de los entornos



de computación en la nube. Una vez que los datos salen de la infraestructura del cliente, y a no ser que se haya estipulado previamente, el cliente pierde parcial o completamente la trazabilidad sobre la ubicación de su información con las siguientes consecuencias:

• Si no se conoce la ubicación de las pruebas, no se pueden establecer las metodologías adecua-das para adquirirlas.

• Es posible que se omitan, por desconocimiento de su existencia, pruebas que estén distribuidas y que por tanto su identificación sea imposible.

8.3.4 El secreto de las arquitecturasHasta hace algunos años, y previa a la existencia de la computación en la nube, existía una cierta norma-lización de tecnologías que permitían conocer con menor o mayor detalle su funcionamiento, facilitando cada una de las tareas relacionadas con la gestión de pruebas electrónicas.

El hecho de identificar alguna información ilícita en el correo electrónico de un usuario y, posteriormente, aportar indicios sobre la autenticidad de dicha prueba podía ser un procedimiento casi trivial.

Sin embargo, el boom en la tipologías de infraestructuras, plataformas o servicios en la nube, conjunta-mente con el secretismo de los proveedores, hacen casi imposible, para los profesionales del sector de la informática forense, conocer en su totalidad y, por tanto estandarizar, las metodologías, herramientas y procedimientos para la extracción, análisis y presentación de pruebas electrónicas y por lo que nos enfren-tamos a una ausencia de protocolos homologados, procedimientos de obtención, conservación y análisis de los documentos electrónicos y otros elementos que la sustentan. Esta falta de protocolos homologados dificulta la acreditación de autenticidad e integridad y obliga a justificar y demostrar en cada caso que los procedimientos utilizados han sido los correctos.

8.4 Las “amenazas principales” y la prueba electrónicaComo ya se ha comentado previamente, dada la similitud de las arquitecturas de computación en la nube con otros modelos anteriores, los profesionales del sector de la informática forense han ido desarrollando tecnologías y procedimientos para solventar o paliar los retos impuestos por tecnologías SaaS, PaaS e IaaS. Estas tecnologías y procedimientos han consistido en mejores prácticas basadas en la adaptación de meto-dologías forenses “tradicionales” y aplicación de sentido común, a cada uno de los retos impuestos por el entorno de computación en la nube. Por desgracia, estas mejores prácticas no son globales y muchas veces consiguen tan solo una pequeña fracción de la prueba electrónica que desearíamos o bien éstas carecen por completo de validez jurídica. El impacto de la computación en la nube en la Sociedad de la Información vendrá marcado, en mayor o menor medida, por las garantías que ofrezca la misma como infraestructura a la cual migrar desde entornos tradicionales. Entre las garantías necesarias se encuentra, sin lugar a dudas, la eliminación del anonimato digital comúnmente asociado a este tipo de entornos [CSA, marzo 2010].

La primera aproximación de los profesionales del sector para resolver la problemática a la que nos enfren-tamos en materia de prueba electrónica en la nube ha sido la tipificación de incidentes de seguridad más comunes que pudieran surgir en entornos de computación en la nube, y así, posteriormente identificar las tecnologías, metodologías y herramientas fundamentales para facilitar la adquisición de las pruebas elec-trónicas más relevantes para cada uno de ellos. El presente estudio pretende aportar una primera aproxi-mación sobre los procedimientos de respuesta en materia de prueba electrónica a cada uno de ellos.



8.4.1 Uso indebido o ilícitoEl “abuso” de infraestructuras IaaS y PaaS afecta principalmente a los proveedores, salvo cuando dicho abuso impacta en otros clientes de esas mismas infraestructuras.

Desde el punto de vista de la prueba electrónica, debemos requerir al proveedor la aplicación de un protocolo de respuesta a incidentes que garantice, no sólo la eliminación del problema, sino también la disponibilidad de las pruebas necesarias para su posterior análisis. Afortunadamente, el entorno de com-putación en la nube resulta especialmente atractivo para una correcta y eficiente respuesta a incidentes de esta naturaleza. La virtualización de las plataformas, comúnmente abusadas, permite al proveedor congelar de inmediato los recursos necesarios. No es necesario plantear el viejo dilema “pull-the-plug”, en estos entornos virtuales podemos congelar al instante el sistema, conservando íntegramente el cien por cien de la prueba disponible. Eso sí, se debe requerir al proveedor, el archivo de las máquinas congeladas por abuso durante un período de tiempo suficientemente amplio como para que terceras partes que se hayan visto afectadas por dicho abuso puedan requerir acceso a las imágenes para su investigación.

8.4.2 Abuso o uso indebido de interfaces insegurasAnte la materialización de un abuso de APIs o interfaces inseguras será necesario disponer de un registro de auditoría de su uso. Dicho registro debería ser completo y exhaustivo identificando no solo la secuencia de uso de las APIs sino también todos y cada uno de los parámetros en cada una de las llamadas realiza-das, IP origen, tokens de autenticación empleados, IP del nodo de acceso utilizado etc.

Los registros de auditoría del uso de las APIs en entornos distribuidos deberían realizarse con fuentes de tiempo confiables y sincronizadas. Idealmente, deberían adoptarse medidas por parte del proveedor para la aplicación en tiempo real de mecanismos de sellado de tiempo y/o notarización digital.

8.4.3 Abuso por parte del proveedor del servicioLa materialización de este riesgo derivaría en una investigación y respuesta al incidente gestionada in-ternamente por el propio proveedor. Por ello, los consumidores deben valorar aquellos proveedores que cuentan internamente con equipos de respuesta a incidentes, y prevención del fraude. Asimismo, su infra-estructura interna (más allá de la propia infraestructura de computación en la nube) debería cumplir con las mejores prácticas existentes en el entorno del “forensic readiness”.

Afortunadamente los consumidores pueden mitigar este riesgo sacrificando un poco algunas de las venta-jas del modelo de computación en la nube. El uso de tecnologías de cifrado de disco y comunicaciones así como la gestión por parte del cliente de la autenticación y gestión de clientes contribuyen a la mitigación de este tipo de riesgo pero impiden aprovechar al cien por cien el nivel de abstracción y la desvinculación de la gestión propias del modelo de computación en la nube.

8.4.4 Riesgos asociados a al compartición de recursosDesde el punto de vista de la prueba electrónica, la materialización de este riesgo presenta muchas similitu-des con el punto anterior. Un atacante capaz de saltarse las medidas de aislamiento propias de un entorno IaaS tendría un acceso muy similar al de un usuario interno malintencionado (malicious insider). Técnica-mente, contaría con muchos de los vectores de ataque propios de un usuario interno. Desgraciadamente, no hay mucho que se pueda requerir en cuanto a prueba electrónica se refiere, dado que este riesgo utiliza un vector de ataque capaz de eludir por completo las APIs del proveedor (públicas y privadas) y por lo tanto, difícilmente tendremos información útil incluso en aquellos proveedores con un nivel de trazabilidad forense excelente.



8.4.5 Pérdida de datosAnte la materialización de este riesgo el consumidor está íntegramente a merced del proveedor de servi-cios. Será el proveedor quien tendrá o no la capacidad para recuperar la información perdida. El consu-midor debe blindar el comportamiento del proveedor de servicios en la nube mediante la firma de ANSs que específicamente regulen las políticas de respaldo y retención del proveedor.

8.4.6 Fugas de informaciónLa materialización de fuga de información de un entorno de computación en la nube resulta, probablemen-te, uno de los supuestos más exigentes en cuanto a las necesidades de prueba electrónica durante la etapa de investigación se refiere. Será necesario disponer de:

• La capacidad para congelar las imágenes virtuales de los sistemas afectados. • Registros de trazabilidad del uso de las APIs del proveedor de servicios en la nube. • Registros del tráfico de salida (y tal vez entrada). • En caso de depender de subsistemas del proveedor de servicios en la nube (autenticación,

gestión de usuarios, VPN, etc.), registros de auditoría del uso de todos ellos.

La mitigación de la materialización de este riesgo pasa, nuevamente, por minimizar la dependencia del consumidor con la infraestructura de servicios y subsistemas en la nube. Cuanto más opaco sea nuestro servicio a los ojos del proveedor menor será este riesgo derivado de la migración a un entorno en la nube. El cliente no debe olvidar, no obstante, que es mejor depender de los subsistemas del proveedor de servi-cios en la nube cuando no se disponen de soluciones maduras y robustas internamente. De lo contrario, el riesgo se materializaría por carencias en nuestros propios subsistemas.

8.4.7 Secuestro de la cuenta o servicioLa materialización de este riesgo impone en el proveedor la necesidad de prueba en dos áreas principales:

1. Recabar prueba del uso de cuentas y/o credenciales en procesos de autenticación. 2. Recabar prueba del uso ilícito de privilegios asociados a las cuentas y/o credenciales.

El primer punto pasa por disponer de un proveedor de servicios en la nube con un nivel adecuado de trazabilidad forense en sus sistemas de autenticación. Idealmente, las propias pasarelas externas de autenticación del provee-dor deberían internamente atacar las propias APIs del proveedor y, por lo tanto, la trazabilidad forense en el uso de las APIs (comentado anteriormente) daría cobertura a las necesidades de prueba electrónica en este sentido.

El segundo punto pasa por la posibilidad de poner en marcha un protocolo de respuesta a incidentes en los sistemas afectados. Aquí, el entorno de computación en la nube no solo nos permite “congelar la prueba”, sino que además nos permite clonarla y relanzarla de inmediato de forma que no se producen tensiones entre la necesidad de dar servicio y la necesidad de salvaguardar la prueba.

8.4.8 Otros riesgos desconocidosEste es el único riesgo inherente al modelo de computación en la nube y por lo tanto, su materialización va asociada necesariamente a toda contratación y uso de tecnologías de este tipo.Desde la óptica de la prueba electrónica, nos encontramos en un entorno en el cual desconocemos el nivel de trazabilidad y ‘forensic readiness’ del proveedor y por lo tanto, en gran medida, de nuestros servicios. Des-graciadamente, normalmente el cliente no es consciente del nivel de trazabilidad forense de su proveedor de computación en la nube hasta que lo necesita.



La mitigación de este riesgo inherente al modelo de computación en la nube pasa por incorporar, por parte del consumidor, unos niveles mínimos de trazabilidad en las capas de aplicación y negocio acordes al servicio desplegado en la infraestructura de computación en la nube. Lógicamente, esto va en contra de la facilidad de uso y la reducción de costes que promete el modelo de computación en la nube. Por ello, el consumidor debe valorar todas las iniciativas en este aspecto que su proveedor ofrezca.

8.5 Recomendaciones

Como resumen de lo mencionado anteriormente en relación a las evidencias electrónicas en entornos de computación en la nube, cabría destacar las siguientes recomendaciones desde la perspectiva del cliente:

• Requiera al proveedor la aplicación de un protocolo de respuesta.

• Asegúrese de que su proveedor es capaz de congelar la prueba, conservando íntegramente el cien por cien.

• Requiera al proveedor que los registros de uso de las APIs en entornos distribuidos se realicen con fuentes de tiempo confiables y sincronizadas.

• Prepare con el proveedor de computación en la nube la posibilidad de disponer de un protoco-lo de “entrega” a sus clientes de una copia de esas imágenes para su investigación.

• Asegúrese de que el proveedor cuenta internamente con equipos de respuesta a incidentes y prevención del fraude.

• Revise los ANS para blindarse ante la pérdida de datos.

• Los clientes y proveedores de computación en la nube deben comprender mutuamente las fun-ciones y responsabilidades de cada uno en relación con la gestión de pruebas electrónicas, incluyendo actividades como la preservación de documentos debido a litigio, búsquedas de descubrimiento, quién presta testimonio experto, etc.

• El proveedor de servicios en la nube y el cliente deberían disponer de un proceso unificado para responder a citaciones, emplazamientos y otras solicitudes legales.

• Aunque el proveedor disponga de un nivel de trazabilidad excelente, el cliente pocas veces tiene acceso y el proveedor que sí lo tiene, pocas veces tiene la motivación necesaria para invertir recursos en el análisis de dichos registros. Se recomienda el análisis de la oferta del mercado de cara a identificar posibles soluciones de terceros de confianza que permitan a los clientes obtener la trazabilidad mínima e indispensable.

• Los clientes y proveedores deberán conocer los procedimientos más elementales concernientes a la gestión de pruebas electrónicas desde la etapa de identificación, recolección y análisis de las pruebas hasta su potencial presentación en un posible litigio.



9.1 Introducción

Las auditorías generalmente se enfocan en proveer garantías, lo que normalmente involucra evaluar la efectividad de los controles que revelan información acerca de la conducta de uno o más procesos de negocio. Todas las compañías cotizadas deben realizar auditorías internas para garantizar la efectividad de sus controles para los propósitos de subsecuentes auditorías financieras o de revisión de políticas in-ternas.

Sin embargo, el entorno de provisión de servicios TIC a través de la nube presenta características específi-cas diferenciales frente a otros entornos de provisión de servicios TIC. Estas diferencias sugieren la necesi-dad de revisar la forma en que la función auditora puede cumplir sus fines en este nuevo entorno, así como la de adaptar la operativa concreta aplicable al mismo: herramientas, metodologías, responsabilidades, colaboraciones, etc. Estas características diferenciales están estrechamente ligadas con los modelos de nube definidas por la Cloud Security Alliance (Pública, Privada, Híbrida o Compartida) [CSA, 2009].

A efectos de la función de auditoría se pueden listar las siguientes características diferenciales de los en-tornos de computación en la nube respecto a los que no lo son:

1. Los elementos incluidos en el programa de auditoría pueden estar físicamente ubicados en una o más instalaciones, incluso separadas geográficamente entre sí. De esta forma, la posibilidad de que un equi-po auditor realice su labor presencialmente requiere de mayor esfuerzo, complejidad y por consiguiente en mayores costes.

2. Debido a la distribución geográfica de los recursos de la nube, la acción auditora deberá seleccionar cuáles de aquéllos marcos jurídicos involucrados deben ser considerados.

3. Debido a que los elementos físicos incluidos en el programa de auditoría no son propiedad del cliente auditado (ni su uso es privativo por él), en entornos compartidos como es la nube (multi-inquilino), exis-tirán recursos lógicos de otros clientes que queden excluidos del alcance de la acción auditora.

En general, los auditores internos y externos para la nube buscarán las suficientes garantías basadas en el riesgo evaluado de los controles operacionales en toda la cadena de proveedores. Por ejemplo, los au-ditores internos y externos para un proveedor SaaS que a su vez utiliza un IaaS requerirán las suficientes garantías de este último en controles tales como la continuidad del negocio o los procesos de seguridad.

Adicionalmente, hay otros elementos que, si bien forman parte del modelo de computación en la nube, no resultan diferenciales sobre otros ecosistemas TIC existentes. Para estos, son aplicables las metodologías tradicionales de auditoría:

Auditoría de entornos de computación en la nube



• Prestación de servicios TIC a través de un tercero, modelado mediante un Acuerdo de Nivel de Servicio (ANS). Incluyendo:

o Gestión y resolución de conflictos entre proveedor y clientes,

o Albergado de datos, servicios y recursos TIC en instalaciones de un tercero (conside-rado individualmente, un tercero y uno cualquiera de los Centros de Procesamiento de Datos de un servidor de computación en la nube).

o Responsabilidad del prestador del servicio por deficiencias en el mismo.

o Seguimiento del cumplimiento del ANS, y aplicación de medidas correctivas o com-pensatorias en su caso.

o Finalización de los contratos.

• Acceso a datos propios por terceros, incluyendo personal y proveedores del proveedor del cliente.

• Exportación / importación de datos de carácter personal entre países.

• Riesgos reputacionales o de fraude por dependencias de terceros.

Es importante resaltar que el resto de esta sección no pretende dar un cuestionario o lista de verificación para realizar una auditoría de servicios en la nube, sino mostrar las diferentes metodologías y tecnologías existen-tes o que se están desarrollando actualmente e indicar mejores prácticas de auditoría en el nuevo entorno. En este cambio de paradigma, las TIC ya no se encuentran en el límite físico de las organizaciones, sino que están dispersas en muchos casos en diversos territorios, cada uno con legislaciones específicas más o menos restrictivas en términos de manejo de privacidad, políticas de gobernabilidad de información, etc.


Este capítulo, destinado a analizar los retos de la realización de auditorías en entornos de computación en la nube, se ha estructurado entorno a dos grandes ejes que, a su vez, son los dos apartados principales del mismo.

Por un lado, se analizan las metodologías y tecnologías de auditoría, considerando las distintas modalida-des de implementación de servicios en la nube y repasando los distintos estándares que se pueden utilizar como referencia para la realización de estas auditorías. También se incluye un breve repaso por tipos de tecnologías que pueden ayudar a la realización de auditorías y, finalmente, se analiza brevemente el pa-pel que pueden jugar unas figuras emergentes como son los denominados Public Auditing Services (PAS) y Third Party Auditors (TPA).

El otro eje que estructura este capítulo son las recomendaciones que se realizan para llevar a cabo auditorías en este tipo de entornos de la manera más eficaz y eficiente posible, analizada desde tres perspectivas: • La elección del marco de auditoría. • La ejecución de dichas auditorías. • La difusión de los resultados de las mismas.



9.3 Metodologías y tecnologías de auditoría

Tal y como se presentó en la sección anterior, existen una serie de factores diferenciales en la computación en la nube que requieren un replanteamiento de las metodologías y tecnologías actuales de auditoría TIC. La Tabla 4 resalta la necesidad del uso de herramientas diferenciadas, en los distintos modelos de aprovi-sionamiento de computación en la nube.

Ilustración 12. Perspectivas de análisis de auditorías

Ejecuciónde pruebas

Elecciónde marco

Difusión de resultados

Recomendaciones

Tabla 4. Necesidad de metodologías y tecnologías de auditoría diferenciadas por el modelo de computación en la nube.

Nube Pública

Nube Privada

Nube Híbrida

Nube Comunitaria

Auditoría física de las ubicaciones ++ NO + ++

Aplicación de marcos jurídicos transnacionales ++ NO + ++

Uso compartido de sistemas TIC por otros clientes ++ NO NO +

Acceso a servicios a través de Internet ++ + + +

Jurisdicción aplicable para conflictos. ++ NO + +

Capacidad negociadora entre las partes + NO NO NO

++ = Necesario, + = Opcional, NO = No necesario



Partiendo de la tabla anterior, se puede comentar adicionalmente que las principales áreas a auditar en un modelo de computación en la nube son las siguientes:

•Gobernanza de las TIC •Cumplimiento (Normativo y Contractual)72

•Privacidad 73

•Seguridad de TIC74

•Gestión de operaciones (Red) •Plan de contingencia

En el Anexo IV se incluye un análisis pormenorizado de las metodologías y tecnologías “diferenciadas” que pueden utilizarse para la computación en la nube, tomando en cuenta sus principales ventajas e in-convenientes desde una perspectiva práctica.

Estas metodologías o programas de auditoría pueden ser utilizadas indistintamente por clientes y provee-dores de servicios en la nube. Asimismo, se observa que son lo suficientemente genéricas para los distintos modelos de servicio y de aprovisionamiento, de forma que no es necesario hacer distinciones para su utilización entre estos.

Los auditores internos y externos para la computación en la nube buscarán las suficientes garantías eva-luando el riesgo de los controles operacionales en toda la cadena de proveedores. Por ejemplo, los au-ditores internos y externos para un proveedor SaaS que a su vez utiliza un IaaS requerirán las suficientes garantías de este último en controles tales como la continuidad del negocio y los procesos de seguridad. Regularmente para un proveedor IaaS es costoso (tiempo y dinero) el llevar a cabo estas labores de audito-ría, por lo cual puede optar por elegir alguna otra opción para proveer las garantías pertinentes sin tener que dar respuesta a todas y cada una de las peticiones individuales de auditoría.

En este punto surgen las Public Auditing Services (PAS)75 y Third Party Auditors (TPA)76 que es una forma de auditoría que ha surgido para garantizar la seguridad de los servicios en la nube -y en particular, la relacionada con los datos almacenados y los procesos que se ejecutan en estos sistemas-. Sus principales ventajas y desventajas se muestran en la Tabla 5.

72 Analizado en el Capítulo 773 Analizado en el Capítulo 4

74 Analizado en el Capítulo 675 Servicios de auditoría públicos

76 Auditores terceros independientes

Tabla 5. Ventajas y desventajas de los PAS y TPA

Ventajas Desventajas

- Debido a los potenciales conflictos de interés de los auditores internos, los PAS se requieren para evaluar la efectividad de los controles a pesar que el trabajo y la información recolectada vayan a ser similares.

- Este auditor actúa como tercera parte de confianza (TPA por sus siglas en inglés) y, para conservar la independencia del TPA, es deseable que éste sea independiente del proveedor de servicios al que audita.

- Un TPA usualmente contará con los conocimientos y recursos para periódi-camente verificar, por ejemplo, la integridad de los datos almacenados en la nube, algo que el cliente normalmente no podría llevar a cabo.

- Por su naturaleza misma, los PAS y TPA pueden representar en si un riesgo para los datos personales de los clientes almacenados en el proveedor que auditan.

- Posibilidad de carencia de independencia en el caso de que sean contratados o tengan alguna relación directa con el proveedor.



9.4 Recomendaciones

Esta sección recoge una serie de recomendaciones y mejores prácticas sobre metodologías y tecnologías de auditoría para la computación en la nube, esperando servir de guía no solamente para los clientes, sino también para los proveedores mismos.

Estas recomendaciones se ordenan en tres líneas de actuación diferenciadas, tal y como se muestra en la ilustración a continuación. Cabe resaltar que dichas líneas de actuación son aplicables tanto a los modelos de servicio como de aprovisionamiento de computación en la nube.

9.4.1 Recomendaciones en la definición del marco auditor a aplicarSe recomienda que los mecanismos de supervisión sean de obligado cumplimiento para el prestador del servicio en la nube, garantizando el servicio y el acceso a sus instalaciones a petición del usuario o cliente de los aparatos de comunicaciones, equipos informáticos o armarios de discos y soportes.

Se recomienda seguir de cerca la evolución de mecanismos, tales como CloudAudit, ya que su integración en los servicios y productos existentes será deseable para hacer más transparentes a los proveedores de servicios en la nube. También se recomienda seguir la labor de grupos como el “Security Metrics WG” de la Cloud Security Alliance, cuyos resultados serán complementarios al CloudAudit.

Se recomienda que el TPA sea independiente del proveedor de servicios de computación en la nube al que audita.

Asimismo, es recomendable que se haga público un catálogo de TPA autorizados por cada proveedor de computación en la nube.

9.4.2 Recomendaciones en la praxis de ejecución de la acción auditoraEn general, todos los servicios de auditoría y mecanismos de control para la computación en la nube de-berán de respetar la confidencialidad y privacidad de los clientes y sus datos.

Se deberá observar que cada prestador de servicios en la nube cada prestador de servicios en la nube debe disponer de una estructura organizativa que pueda atender las necesidades y requerimientos de cumplimiento legal de sus clientes y, en su caso, facilitar los trabajos de auditoria.77

Se auditará que el Acuerdo de Nivel de Servicios (ANS)78 entre el proveedor y el cliente deba incorporar elementos adicionales y penalizaciones asociados a su incumplimiento, en los ámbitos de: cumplimientos regulatorios exigible a su cliente, verificación del cumplimiento del ANS, acceso no autorizado por em-pleados del proveedor o proveedores a información del cliente, errores de seguridad y/o servicio que sean responsabilidad del proveedor, accesos no autorizados por deficiencias en el servicio del proveedor. La verificación se realizará tanto sobre la existencia de estos elementos, como en su medición y seguimiento en el curso de la prestación de los servicios, como en la aplicación de penalizaciones y/u otras provisiones que, contractualmente, se hayan establecido.

77 Estos aspectos se tratan en mayor detalle en el Capítulo 4 destinado a la privacidad.78 Los Acuerdos de Nivel de Servicio se analizan en detalle en el apartado 7.12.



El auditor deberá verificar la existencia y el uso de herramientas que protejan la integridad y completitud de ficheros de registros utilizados por el proveedor de servicios en la nube, para prevenir y/o detectar cualquier intento de manipulación.

Al hacer sus valoraciones, el auditor debe evaluar toda la cadena de confianza que va desde la fuente (creación) de la información de los registros, pasando por la medidas de protección utilizadas en la trans-misión de dicha información (HTTPS, TLS, etc.) hasta el tipo de protección de integridad (criptográfica o de otro tipo) utilizada y la cronología de dichos ficheros.

En el ámbito de colaboración con el proveedor de servicios en la nube, y buscando minimizar el impacto en recursos y operaciones del proveedor que pueden suponer las distintas acciones auditoras por parte de sus distintos clientes, el equipo auditor se adaptará a los calendarios y ventanas de auditoría que establez-ca el proveedor de forma que sus distintos clientes puedan compartir para sus diversos fines los resultados de actividades auditoras realizadas en dicho calendario.

9.4.3 Recomendaciones en la difusión y publicación de los resultadosSe deberá observar que los servicios de auditoría para la computación en la nube estén disponibles para su consulta en cualquier momento a petición del auditor autorizado por el peticionario del servicio en la nube o del cliente del servicio, sin interrumpir los niveles de servicio acordados. La forma en la que dichos servicios están disponibles serán diferentes en el caso de TPAs y PAS.

Se deberá verificar que se establezcan los mecanismos de monitorización y alerta de los servicios pres-tados que informen al consumidor el grado de cumplimiento (o incumplimiento) de los niveles de servicio acordados. En particular, estos elementos deben ser puestos a disposición de los equipos auditores en el transcurso de su trabajo.


10. Glosario 120

Acuerdo de Nivel de Servicio (ANS)

Contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio. El ANS es una herramienta que ayuda a ambas partes a llegar a un consenso en términos del nivel de calidad del servicio, en aspectos tales como tiempo de respuesta, disponibilidad horaria, documentación disponible, personal asignado al servicio, etc.

Auditabilidad

Entendida como la capacidad por parte del cliente que contrata los servicios en la nube para auditar la actividad del proveedor.

Binding Corporate Rules

Ver Normas Corporativas Vinculantes.

IaaS (Infrastructure as a Service)

Modelo de computación en la nube en el que la infraestructura se utiliza como servicio.

ISAE 3402

Ver la definición de SAS70.

Evidencia electrónica

Cualquier dato almacenado o transmitido en forma digital y que por sus características pudiera ser utilizado para probar algún hecho en un procedimiento judicial.

Forensic readiness

Habilidad de una organización para maximizar su potencial para usar evidencias digitales minimizando los costes de la investigación.

Matriz RACI

Herramienta que identifica tareas a realizar en una materia y asigna a los roles pertinentes que se definan en la organización una función sobre esa tarea. El nombre de la herramienta deriva de las iniciales en inglés de los tipos de funciones que se asignan: R – Responsible, A – Accountable, C – Consulted, I – Informed.

En ocasiones, se utiliza la variante RASCI, que incluye el rol de soporte (S – Supported).

Modelo SPI

Tipificación de modelos generales de implantación de servicios en la nube en tres categorías que dan nombre al modelo: SaaS – Software as a Service, PaaS – Platform as a Service, IaaS – Infrastructure as a Service.

Multi-inquilino

Propiedad de la computación en la nube que consiste en la existencia de varios clientes en un mismo sistema (del inglés, multi-tenant).

Glosario


10. Glosario 121

Normas Corporativas Vinculantes

Desarrolladas por el Grupo de Trabajo del Artículo 29, permiten a corporaciones multinacionales realizar transferencias internacionales intracompañía de datos de carácter personal cumpliendo con la legislación a.

Notarización digital

Sistema que permite dar fe de algún aspecto de manera electrónica.

PaaS (Platform as a Service)

Modelo de computación en la nube en el que la plataforma se utiliza como servicio.

Prueba electrónica

Cualquier dato almacenado o transmitido en forma digital y que por sus características pudiera ser utilizado para probar algún hecho en un procedimiento judicial.

SaaS (Software as a Service)

Modelo de computación en la nube en el que los programas, el software se utiliza como servicio.

SAS 70

Statement on Auditing Standards No.70: Service Organizations. Proporciona guía a los auditores cuando están evaluando los controles internos de un proveedor de servicios y emitiendo un informe en consecuencia.

Sellado de tiempo

Protocolo on-line descrito en el RFC 3161 que permite demostrar que una serie de datos han existido y no han sido alterados desde un instante específico en el tiempo.

Trusted Computing Base (TCB)

Conjunto de componentes hardware, middleware y/o software críticos para la seguridad del sistema.

VA

Aplicativos Virtuales diseñados para ejecutarse en plataformas virtualizadas.

VM

Máquinas virtuales. Instalación de un sistema operativo aislado en el sistema operativo normal.


11. Referencias 123

[CSA, 2009] Cloud Security Alliance, diciembre 2009. “Security Guidance for Critical Areas of Focus in Cloud Computing v2.1”.

[CSA, marzo 2010] Cloud Security Alliance, marzo 2010. “Top Threats to Cloud Computing v1.0”

[CSA, diciembre 2010] Cloud Security Alliance, diciembre 2010. “Cloud Security Alliance launches Cloud Controls Matrix (CCM) 1.1”.

[Directiva 1995] Directiva 95/46/CE del parlamento europeo y del consejo de 24 de octubre de 1995 relativa a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos.

[ENISA, 2009] European Network and Information Security Agency, noviembre 2009. “Cloud Computing Information Assurance Framework”.

[ENISA, 2011] European Network and Information Security Agency, 2011. “Cloud Computing Information Assurance Framework”.

[Inteco, 2011] INTECO-CERT, marzo 2011. “Riesgos y Amenazas en Cloud Computing”.

[ISACA, 2010] ISACA, 2010. “Cloud Computing Management Audit/Assurance Program”.

[ISO 27001] International Organización for Standardization, octubre 2005. ISO/IEC 27001:2005 “Information technology -- Security techniques -- Information security management systems – Requirements”.

[ISO 27002] International Organización for Standardization, junio 2005. ISO/IEC 27002:2005 “Information technology -- Security techniques -- Code of practice for information security management”.

[NIST, 2011] National Institute of Standards and Technology, enero 2011. “Guidelines on Security and Privacy in Public Cloud Computing”.

[RLOPD] Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.

[WPF, 2009] World Privacy Forum, febrero 2009. “Privacy in the Clouds: Risks to Privacy and Confidentiality from Cloud Computing”.

Referencias


12. Anexos 125

Anexo I. Amenazas asociadas a tecnologías específicas

Los ataques se vuelven cada vez más sofisticados, produciéndose un cambio de enfoque, con los atacantes centrados expresamente en agotar los recursos que no son expresamente de ancho de banda, como son los cortafuegos, los balanceadores de carga, la infraestructura de back-end de base de datos y la capaci-dad transaccional asociada y los algoritmos que sirven datos almacenados en caché.

Con la consolidación y migración de infraestructuras/servicios a la nube (por ejemplo, DNS), el riesgo de ataques que impactan en múltiples entidades y que con mayor frecuencia inducen daños colaterales, es mayor. Este hecho es conocido como multi-tenancy, y se erige como un factor determinante a la hora de identificar las amenazas asociadas a la provisión de un servicio en la nube, siendo un factor discriminante en la elaboración de un análisis de riesgos sobre el mismo.

Sin embargo, de las asociaciones entre fabricantes de las múltiples disciplinas/tecnologías que interactúan en la nube, están surgiendo nuevas arquitecturas multi-tenancy aseguradas, conformando infraestructuras compartidas y virtualizadas, que proporcionan un aislamiento más seguro de los datos, y mantienen el rendimiento de la carga de trabajo.

Como consecuencia, proliferan diversas opciones para mitigar los riesgos derivados del uso masivo de estas tecnologías en los contextos de provisión de servicio en la nube.

• Soluciones Independientes: Las tecnologías y los fabricantes están evolucionando hacia solucio-nes específicas, asociándose entre ellos, conformando agrupaciones de inte-rés. Estas tecnolo-gías, entre otras, proporcionan un mayor control sobre el hipervisor, in-cluso descargando a los sistemas/servidores (Virtual Machines - VM) de la carga propia de procesamiento (real-time mo-nitoring/scan) proporcionando una capa de seguridad inde-pendiente (Virtual Appliance - VA). Existen varios enfoques empleados en dicha aproximación:

o independencia total (no es necesario desplegar agentes que permitan realizar la ges-tión local de las tecnologías).

o independencia parcial (se descargan funciones en VA, y se mantienen otras a través de agentes sobre las VM).

Anexos


12. Anexos 126

• Soluciones Integradas: Además de estas tecnologías, existen otras específicas que se integran con el hipervisor y lo protegen frente a ataques de rootkits que inyectan malware en el hipervisor.

• Soluciones Simplificadas (Redefinición, Reingeniería): Otros enfoques están orientados hacia la simplificación/inhabilitación de componentes a priori innecesarios que pueden mejorar la seguridad de los hipervisores reduciendo la tasa de riesgo a través de la denominada Trusted Computing Base (TCB). Precisamente, debido a la carga de código innecesario en la TCB, los hipervisores pueden verse expuestos a distintos ataques:

o Ataques desde máquinas virtuales invitadas. o Ataques físicos.

•Ataques procedentes de la subcontratación de terceros (proveedores de servicios en la nube).

Las tecnologías que mitigan los riesgos introducidos por hipervisor reducen el ámbito del ataque a la TCB minimizando la interfaz entre la TCB y la máquina virtual invitada. Incluso si la vulnerabilidad existe dentro de la TCB, el sistema sigue siendo seguro, siempre y cuando el atacante no pueda explotarla. Implica re-pensar el diseño del hipervisor para escenarios en la nube, eliminando dispositivos virtuales innecesa-rios.


Anexo II. Amenazas

Las tablas incluidas a continuación se han organizado conforme a la siguiente estructura:

12. Anexos 127

Nom

bre

de la

am

enaz

a

Consideraciones sobre la relevancia de la amenaza en entornos de computación en la nube.

Efecto de la amenaza en servicios IaaS

Efecto de la amenaza en servicios PaaS

Efecto de la amenza en servicios SaaS

Recomendaciones de control para usuarios de servicios IaaS

Recomendaciones de control para usuarios de servicios PaaS

Recomendaciones de control para usuarios de servicios SaaS

Blo

queo

en

el p

rove

edor

Aunque no es una amenaza exclusiva de entornos de computación en la nube, si adquiere en éstos particular relevancia.

Al estar los servicios IaaS basados en la virtualización sobre sistemas operativos estándar, el “lock In”, aunque existente, es fácil de migrar la aplicación y sus datos a otro proveedor con una complejidad similar al cambiar de máquina física.

En consecuencia, la necesidad de conocimiento de las herramientas de gestión, es asimilable al cambio de fabricante de HW.

En los PaaS, cada uno ofrece un lenguaje más o menos especifico, por tanto, cambiar de PaaS puede implicar reescribir por completo la aplicación en caso de incompatibilidad o hacer cambios menores para adaptarse a las especificidades de cada proveedor.

En SaaS, los datos y la aplicación están en un formato definido por el proveedor, el cambio a otro proveedor implicaría el mismo esfuerzo que el cambio de aplicativos en modelos tradicionales (otro modelo de ERP / CRM /etc.) Cuanto más estándar sea nuestra necesidad cubierta por el servicio SaaS, más fácil será reubicarlo en otro proveedor.

Se ha de evaluar qué funcionalidades específicas del proveedor sean fácilmente sustituibles por otras de otros proveedores. Por ejemplo, los balanceadores de carga.

Procurar utilizar operativas mediante lenguajes estándar y controlar los aspectos específicos del proveedor, abstrayéndolos en lo posible.

Asegurar que existen sistemas de exportación de todos los datos importantes a formatos interoperables.

Pér

dida

de

gobi

erno

Esta amenaza tiene mayor incidencia en la evaluación de riesgo respecto al modelo tradicional debido a que cedemos parte de la gestión a otras compañías que tendrán sus

propios estándares de gobierno.

La pérdida de control afecta a la infraestructura y los datos.

La pérdida de control afecta a la infraestructura, el servidor de aplicaciones y los datos.

La pérdida de control afecta a la infraestructura, el servidor de aplicaciones, la propia la aplicación y los datos.

Asegurar, vía contrato, que se establecen medios de gobierno compatibles con los de tu compañía y trabajar como si no se estuvieran cumpliendo en activos de impacto alto.


12. Anexos 128

Adq

uisi

ción

del

pro

veed

or

clou

d

La adquisición no tiene por qué ser perjudicial en sí misma, pero se ha de evaluar el grado de trasparencia para los clientes hospedados. En caso de que se entienda que aumenta

significativamente los niveles de riesgo evaluados con el antiguo propietario, deberemos actuar como en el caso de fallo o cierre.

Si el bloqueo (lock in) con el proveedor lo mantenemos a niveles controlados, el riesgo sería que fallara o cesara su actividad sin darnos tiempo a ejecutar las contramedidas necesarias para mover

los procesos allí alojados a otro proveedor.

Disponer de los datos en formato neutro de proveedor en un almacenamiento local o de un tercero independiente, por ejemplo, fuera del centro de procesamiento de datos/proveedor donde tenemos el

servicio.

Incu

mpl

imie

ntos

nor

mat

ivos

Esta amenaza existe siempre, pero en entornos de computación en la nube tenemos que asegurar mediante contrato que hemos obrado correctamente.

La mayoría de proveedores permiten conocer dónde están los datos y qué procesos usan, pero el entorno aumenta la complejidad de las auditorias por terceras partes debido a la existencia de nuevos actores.

Es más complicado auditar cómo se guardan los datos y dónde, aún así, la aplicación desarrollada debería incorporar contramedidas.

Nos basamos en el grado de cumplimiento del proveedor y en los controles que, como usuarios de aplicación, podamos establecer.

Cifrar los datos almacenados de forma que el proveedor no pueda acceder a ellos. Lógicamente, se deberá controlar la clave privada.

Implantar las contramedidas en la aplicación a desarrollar para evitar incumplir alguna norma, aunque el proveedor tenga algún incidente de seguridad.

Aunque solo se tenga acceso a la administración de la aplicación, se deberán establecer las medidas que se puedan a este nivel y asegurar el resto mediante contrato y revisión periódica.

Pér

dida

de

repu

taci

ón a

cau

sa d

e ac

tivi

dade

s de

“ve

cino

s”

Al compartir infraestructura con otros, sus actividades pueden afectarnos. De igual forma que los vecinos de nuestro lugar de trabajo, de alguna forma, afectan a la reputación del

negocio.

Aunque el servicio solo sea a nivel de infraestructura, puede producirse, por ejemplo, al compartir infraestructura con otro cliente que realice actividades de spammer puesto que podría afectar a nuestras tasas de entrega de correo y por revelación de datos.

Lo mismo puede ocurrir si lo que se comparte es el servidor de aplicaciones y por revelación de datos.

Igualmente, puede ocurrir al compartir la aplicación y por revelación de datos.

Existe una gran dependencia del servicio concreto, pero, en cualquier caso, hemos de asegurar que el proveedor no tolere comportamientos que consideremos inadecuados mediante correctas políticas de

acceso y requerimientos de buen uso controlados.


12. Anexos 129

Fallo

o c

ierr

e de

l pro

veed

or

La adquisición no tiene por qué ser perjudicial en sí misma, pero se ha de evaluar el grado de trasparencia para los clientes hospedados. En caso de que se entienda que aumenta

significativamente los niveles de riesgo evaluados con el antiguo propietario, deberemos actuar como en el caso de fallo o cierre.

Si el bloqueo (lock in) con el proveedor lo mantenemos a niveles controlados, el riesgo sería que fallara o cesara su actividad sin darnos tiempo a ejecutar las contramedidas necesarias para mover

los procesos allí alojados a otro proveedor.

En cualquier caso tenemos que tener habilitados estos procesos que actúen de contramedida, en especial la realización de una correcta Due Dilligence en el proceso de selección del proveedor.

Disponer de los datos en formato neutro de proveedor en un almacenamiento local o de un tercero independiente, por ejemplo, fuera del centro de procesamiento de datos/proveedor donde tenemos el

servicio.

Existe una gran dependencia del servicio concreto, pero, en cualquier caso, hemos de asegurar que el proveedor no tolere comportamientos que consideremos inadecuados mediante correctas políticas de

acceso y requerimientos de buen uso controlados.

Fal

los

en la

cad

ena

de

sum

inis

tro

Si el proveedor subcontrata determinadas tareas a terceros, la seguridad total es la del elemento más débil.

En IaaS, se ha de mantener controlada nuestra infraestructura por si hay elementos maliciosos en el proveedor.

En PaaS, no solo se han de tener en cuenta los elementos de IaaS, sino todas las dependencias que existan en la aplicación. Planificar para el fallo y validar la integridad de las mismas y los datos.

En SaaS, aunque subyacen las consideraciones de PaaS e IaaS, generalmente estamos limitados a lo que soporta el proveedor.

Asegurar contractualmente que todas las subcontrataciones, al menos, mantendrán el nivel de seguridad.

Ago

tam

ient

o de

los

recu

rsos

Al compartir infraestructura con otros, sus actividades pueden afectarnos. Si el control de recursos no es adecuado, algunos usuarios pueden copar su uso.

Podemos encontrarnos con que se reduce el rendimiento de los servidores o, en caso de caída, que no puedan reiniciarse.

El efecto habitual sería la reducción del rendimiento de la aplicación.

El efecto sería la reducción del rendimiento del servicio.

Asegurar, vía contrato, la utilización y adhesión a métricas de rendimiento y de capacidad adicional. Por ejemplo, reserva adicional del 10% comprometido.

Asegurar, vía contrato, la utilización y adhesión a métricas de rendimiento a nivel de experiencia de usuario. Por ejemplo, en el 95% de las ocasiones, la carga de un pedido tarda menos de 2 segundos.


12. Anexos 130

Secu

estr

o de

ser

vici

o o

cuen

ta

Al ser uno de los principios de computación en la nube que sea ofrecido con autoprovisión y autogestión, si un ente malicioso obtiene acceso a nuestras credenciales puede realizar

cualquier acción que podamos hacer nosotros.

Aunque se proveen servicios de infraestructura, se pueden borrar datos, parar máquinas o implantar malware que no detectemos a tiempo.

En un PaaS a parte de obtener los datos, pueden modificar el código para obtener nuevas credenciales o realizar otras acciones.

Obtienen acceso a los datos y pueden realizar acciones que afecten al negocio. Por ejemplo enviar un correo en nombre de un empleado a un cliente.

Utilizar métodos fuertes de autenticación, comunicaciones cifradas, e implantar medidas para comprobar la integridad de nuestros servicios.

Utilizar métodos fuertes de autenticación, utilizar comunicaciones cifradas e implantar medidas para comprobar la integridad de nuestro código.

Utilizar métodos fuertes de autenticación y utilizar comunicaciones cifradas.

Pér

dida

o fu

ga d

e da

tos

El modelo de computación en la nube incrementa este riesgo ya que, potencialmente, existen más actores que pueden tener acceso al repositorio de los datos, además de

difuminar el perímetro de protección.

Perdemos control sobre los métodos de baja de servicio o control de acceso a los APIs.

Además de lo comentado para IaaS, debemos controlar cómo escribimos los datos y validar que el código que se ejecuta es el nuestro.

Perdemos control sobre las formas de almacenaje y/o código para acceder, debemos asegurar por contrato/auditoria que se establecen las prácticas adecuadas.

Lo recomendable sería cifrar todos los datos, en tránsito y almacenados, asegurar procedimientos fiables de desprovisión de servicio, utilizar métodos de autenticación seguros e impedir el uso de mecanismos débiles de autenticación.

Se debería firmar el código y comprobar la firma en ejecución para tener una cierta garantía de que nadie ha tocado nuestro código para acceder a los datos ya protegidos.

Todos los datos que el servicio permita que sean opacos, los podemos cifrar y, para el acceso, deshabilitar los sistemas débiles de autenticación, dejando únicamente activos los robustos.

Den

egac

ión

de s

ervi

cio

dist

ribu

ida

Para todos nuestros servicios públicos en Internet, los servicios de computación en la nube reducen el riesgo de afectación ya que podemos dimensionar la capacidad de forma

mucho más ágil y minimizar el impacto de los ataques DDoS.

Para los servicios IaaS, si son públicos, nos puede afectar a nosotros, y si son privados aunque en infraestructura pública, nos pueden afectar también los posibles ataques a nuestros vecinos que agoten los recursos del proveedor.

En el modo PaaS, donde se dimensionan los recursos en base a demanda, el riesgo lo tenemos en la sobresuscripción que pueda haber hecho el proveedor.

Por modelo de negocio, los proveedores SaaS publican el servicio mediante Internet, así que un ataque exitoso nos afectará si afecta al servicio del proveedor.

Evitar en lo posible exposiciones del servicio a la red pública, ya sea con VPN o redes dedicadas hasta el proveedor de servicio.

Vía contrato asegurar una garantía de rendimiento que nos independice de los posibles ataques a los vecinos.

Exigir al proveedor que disponga de métodos de mitigación de ataques y tenga en la lista blanca de IPs a nuestras sedes.


12. Anexos 131

Per

fil d

e ri

esgo

des

cono

cido Al externalizar parte o toda la gestión a un tercero, perdemos el control de qué equipos

ofrecen el servicio, versiones de software, controles de acceso, etc…

En este caso, al ser el problema el desconocimiento, lo tenemos en todos los escenarios SPI en mayor o menor medida.

Con objeto de mitigarlo, lo único que podemos hacer es disminuir los ámbitos de desconocimiento.

Realizar una correcta ‘due dilligence’ en el proceso de contratación del proveedor con objeto de reducir los ámbitos de desconocimiento.

Asegurar que el proveedor avise en caso de detectar alguna anomalía con efectos en ámbitos de seguridad, manteniendo unos contenidos y flujos de información ágiles y preestablecidos.

Incu

mpl

imie

nto

de le

gisl

ació

n ap

licab

le

Al externalizar parte o toda la gestión a un tercero, perdemos el control de qué equipos ofrecen el servicio y donde están, con lo que algunas legislaciones de la que no tengamos

constancia pueden obligar a nuestro proveedor a ofrecer datos o entregar los equipos, provocando un fuga de datos o denegación de servicio.

En este caso, al ser el problema la legislación, lo tenemos en todos los escenarios SPI en mayor o menor medida.

Para mitigarlo, debemos conocer las legislaciones que pueden aplicar, solicitando al proveedor que no mueva los servicios a ubicaciones y/o sistemas que no cumplan nuestros requisitos.

A todos los efectos, debemos sumar las consideraciones de los casos en que el proveedor deja de dar servicio y pérdida de datos. Aquí no sería por motivos técnicos o maliciosos sino por imperativo legal,

pero el resultado sería similar.

Los contratos firmados han de determinar las responsabilidades derivadas del cumplimiento normativo aplicable de forma explícita.

Fallo

s de

l ais

lam

ient

o de

ser

vici

os

Al estar en plataforma compartida, si un vecino es vulnerable, pueden afectar a nuestro entorno. En entornos privados, los fallos de aislamiento son más fáciles de controlar ya

que todos los vectores están bajo nuestro control o del proveedor.

Aquí el proveedor, sea IaaS, PaaS o SaaS nos debe dar las garantías necesarias para confiar en que tienen estos aspectos completamente en cuenta. Ya sea por normas y procesos de calidad de código,

diseño y operación o aplicación de parches.

La mejor forma de mitigar el riesgo es considerar que nuestro servicio en sí es vulnerable y aplicar cifrados y controles de integridad, mitigando el riesgo de compromiso de datos al minimizar el tiempo

en que estos son accesibles en claro.

Uso

inde

bido

y n

efas

to

del c

loud

com

puti

ng

Los usuarios maliciosos aprovechan las ventajas de computación en la nube para lanzar ataques (en especial, a proveedores).

Normalmente, el usuario malicioso usará una tarjeta de crédito o cuentas comprometidas y después de un gran uso de recursos, el proveedor no podrá recibir compensación.

Con objeto de mitigarlo, debemos encontrar el compromiso entre facilidad de activación de servicio y garantías de pago y buen uso del servicio.

Se debe poder analizar el tráfico por si se están lanzando ataques desde nuestra infraestructura, validar que el cliente es quien dice ser, monitorizar la reputación de nuestros bloques de red, etc…


12. Anexos 132

Asp

ecto

s de

la te

cnol

ogía

co

mpa

rtid

a

La computación en la nube se basa en la compartición de infraestructura para poder mejorar eficiencias y aprovechar economías de escala, así que problemas en la tecnología

compartida, pueden afectar a nuestro servicio.

El proveedor debe poder asegurarnos agilidad en la aplicación de los parches que solucionen vulnerabilidades y herramientas de gestión y supervisión para identificar comportamientos no

esperados. Por ejemplo, tráfico destinado a un cliente es visible por otro servidor, un usuario del cliente X está accediendo a datos del cliente Y, etc…

Para mitigarlo y proteger nuestra información, debemos cifrar y validar la integridad de la misma. De esta forma, un fallo en la tecnología compartida podría afectar a la disponibilidad, pero no tanto a la

integridad y confidencialidad.

Inte

rfac

es y

AP

Is in

segu

ras Si una de las características de la computación en la nube es la autoprovisión y gestión del

servicio, dichas interfaces y APIs deben permitir el acceso desde Internet.

Al permitir acceso remoto a herramientas de gestión, debemos poder autenticar y autorizar debidamente al ente (usuario o programa) que está realizando la petición. Un fallo puede afectar al

servicio del cliente o comprometer su infraestructura (especial relevancia en entornos PaaS).

Para mitigarlo, debemos habilitar y exigir los sistemas de autenticación adecuados para el servicio ofrecido. Por ejemplo, la comunicación cifrada, autenticación mediante certificados y/o contraseñas

de un solo uso, etc…

El proveedor debe poder ofrecer métodos seguros de autenticación y además supervisar la actividad para detectar posibles malos usos.

Usu

ario

s in

tern

os

mal

icio

sos

En los entornos tradicionales, ya es muy conocido el riesgo de usuarios maliciosos internos, pero al externalizar los servicios, podemos encontrarnos con usuarios del

proveedor que tengan más derechos que el propio usuario.

Deberíamos exigir al proveedor conocer cómo se dan derechos a los usuarios, qué auditoria existe y qué tipo de supervisión y procesos tienen implantados para reducir la posibilidad de tener usuarios

internos maliciosos.

Para mitigarlo, debemos considerar que estamos en un entorno hostil y, para proteger nuestra información, cifrar y validar la integridad de la misma. De esta forma, un usuario malicioso podría

afectar a la disponibilidad, pero no tanto a la integridad y confidencialidad.


12. Anexos 133

Anexo III. La prueba electrónica en el marco legal Español

Definición de Prueba electrónica“Prueba: Justificación de la verdad de los hechos controvertidos en un juicio, hecha por los medios que autori-za y reconoce por eficaces la ley” (DICCIONARIO DE LA LENGUA ESPAÑOLA - Vigésimosegunda edición)

El concepto de prueba electrónica, como herramienta procesal probatoria de los acontecimientos ocurridos en la nube, evoca lo intangible. La volatilidad está en la propia naturaleza de la prueba electrónica, y por lo tanto, esa tendencia inevitable a la alteración de dicho soporte probatorio exige actuar con mucha cau-ción y diligencia. Son datos de inestimable valor para todo presunto fraude digital, electrónico, virtual o en la nube que se esté investigando, pues sirve para adquirir convencimiento de la certeza de un hecho.

Estas características intrínsecas de la prueba electrónica llevan a implementar unas medidas garantistas en el momento de la obtención de los indicios, la información o los datos contenidos en estos entornos que podrán generar prueba si son debidamente capturados. Los principios básicos acerca de las garantías de integridad de la información a tener en consideración para conseguir convertir el indicio en prueba son:

• los datos o la información almacenada y que quiere ser obtenida no puede ser alterada o ma-nipulada,

• la persona que realiza la investigación debe tener autorización para llevarla a cabo, y

• todo el proceso seguido debe quedar registrado o auditado por un fedatario público de tal forma que un tercero pueda llevar a cabo el mismo proceso alcanzando la misma conclusión.

A pesar de que las garantías de integridad de la prueba electrónica sean generales para todo tipo de prue-bas, a la hora de abordar el marco jurídico aplicable sobre cómo obtener indicios electrónicos de estas plataformas de gestión remota de la información de los usuarios, dónde éstos vuelcan grandes volúmenes de información eventualmente sensible en servidores pertenecientes a terceros, debemos diferenciar cla-ramente el procedimiento legal a seguir para la obtención de pruebas electrónicas obtenidas de entornos distribuidos de los procedimientos que se siguen para obtener pruebas de entornos controlados como se hace en la mayoría de situaciones actualmente.

Es importante destacar que las consideraciones jurídicas que se hagan en relación a las pruebas electró-nicas obtenidas de la computación en la nube deben ser necesariamente analizadas desde parámetros análogos a los realizados para el tratamiento jurídico de las pruebas obtenidas de Internet, debido a su similitud y a la falta de una regulación específica para esta tecnología tan específica.

Situación ActualA pesar de que es responsabilidad del investigador en la nube asegurar el cumplimiento con la legislación y estar seguro de que los procedimientos adoptados en la obtención de pruebas electrónicas son llevados a cabo según los procedimientos adecuados y la jurisprudencia aplicable al caso concreto, esta labor se complica debido a las lagunas legales existentes en estos temas.

La escasez de una regulación específica en nuestra legislación nacional acerca de la prueba electrónica, ya sea de entornos distribuidos o de entornos controlados, hace que las normas generales relativas a la prueba apliquen de la misma forma a las pruebas electrónicas obtenidas de dispositivos electrónicos o entornos virtuales como a las pruebas que provengan de otro tipo de fuentes.


12. Anexos 134

Por otro lado, si bien es cierto que actualmente en los Tribunales españoles se presentan y utilizan pruebas electrónicas desde hace años para alegar, o refutar, una hipótesis, también es cierto que se carece aún de una jurisprudencia uniforme y concreta para dicha materia.

Esta incertidumbre en torno a la prueba electrónica sea en un entorno controlado o distribuido traspasa las fronteras del Estado español, ya que la obtención, análisis, presentación y admisibilidad de estas pruebas ante los tribunales se efectúa de una manera distinta en cada Estado de la Unión Europea, y no existen apenas referentes legislativos, cuestión que agrava más aún el panorama.

Por lo tanto, desde el punto de vista jurídico, sin perjuicio de que no existe normativa expresa en el Or-denamiento Jurídico relativa a las pruebas electrónicas, resulta posible su aportación a un procedimiento, ya sea como prueba documental (ej.: almacenamiento de un archivo existente en la nube) o como informe pericial (ej.: ciberinvestigación sobre información subida a la nube).

En efecto, los arts. 299-2 y 384-2 de la Ley de Enjuiciamiento Civil establecen que se admitirán, como medios de prueba, los medios de reproducción de la palabra, el sonido y la imagen, así como los instru-mentos que permiten archivar y conocer o reproducir palabras, datos, cifras y operaciones matemáticas llevadas a cabo con fines contables o de otra clase, relevantes para el proceso. El Legislador ha intentado ser lo más amplio posible a la hora de regular para poder aceptar cualquier medio de prueba que se pueda llevar a cabo en la sociedad y así pueda ser presentado en juicio, por muy novedoso que sea, aplicándose por lo tanto directamente a nuestro campo de estudio: la computación en la nube.

En el artículo 812-1-1 de la Ley de Enjuiciamiento Civil se regula los documentos para acceder al proceso Monitorio diciendo que “cualquiera que sea su forma y clase o el soporte físico en que se encuentren, que aparezcan firmados por el deudor o con su sello, impronta o marca o con cualquier otra señal, física o electrónica, proveniente del deudor”, haciendo referencia, en este caso, a la prueba electrónica.

Para que la prueba electrónica sea admitida en juicio, no debemos olvidar los principios de pertinencia, utilidad y legalidad establecidos en el artículo 283 de la Ley de Enjuiciamiento Civil, ni los requisitos establecidos por el artículo 256 de la misma normativa. Por lo tanto, no será admitida ninguna prueba electrónica que haya sido obtenida vulnerando derechos fundamentales o su contenido sea una actividad prohibida por la ley. Es importante tener en consideración a la hora de obtener pruebas electrónicas -para que éstas posteriormente sean válidas en juicio- los requisitos materiales basados en el principio de proporcionalidad, que se dividen en tres juicios: el juicio de idoneidad, el de necesidad y el de propor-cionalidad.

La Ley 24/2001, de 27 de diciembre, que establece modificaciones a la Ley del Notariado en su artículo 17 bis equipara la prueba electrónica a la prueba documental, igual que el artículo 24-2 de la Ley de Servicios de la Sociedad de la Información (LISI), que establece que “el soporte electrónico en que conste un contrato celebrado por vía electrónica será admisible en juicio como prueba documental”. El artícu-lo 3-8 de la Ley 59/2003 sobre Firma Electrónica, en la versión dada por la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información establece a su vez que “el soporte en que se hallen los datos firmados electrónicamente será admisible como prueba documental en juicio”. También en la Exposición de Motivos de la misma Ley se afirma que “se incluye dentro de la modalidad de prueba documental el soporten en el que figuran los datos firmados electrónicamente, dando mayor seguridad jurídica al empleo de la firma electrónica al someterla a las reglas de eficacia en juicio de la prueba documental”.


12. Anexos 135

En los procesos penales, el art. 26 del Código Penal dispone que se considera documento todo soporte material que exprese o incorpore datos, hechos o narraciones con eficacia probatoria o cualquier otro tipo de relevancia jurídica.

Por su parte, los arts. 32 y 33 de la Ley de Arbitraje ratifican los principios de libertad y flexibilidad que presiden la fase probatoria del arbitraje, de forma que permiten que se pueda aportar como prueba, una prueba electrónica en los mismos términos que podría aportarse en un procedimiento judicial.

Aunque no es propiamente objeto de nuestro estudio, no podemos dejar de mencionar la importan-cia que tienen en esta materia la Ley 34/2002, de Servicios de la Sociedad de la Información y del Comercio Electrónico (LSSI), la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal y la Ley de Medidas de Impulso de la Sociedad de la Información, que establece las obligaciones de los prestadores de servicios de la sociedad de la información sobre las medidas de seguridad a implementar ante posibles amenazas; y también la Ley 32/2003 General de Telecomunicaciones, que vela por el cumplimiento de las obligaciones en el secreto de las comunicaciones y protección de datos personales, así como de los derechos y obligaciones de carácter público vinculados con las redes y servicios de comunicaciones electrónicas, imponiendo las correspondientes sanciones por su incumplimiento.

En consecuencia, según veremos a continuación, los presupuestos jurídicos y los protocolos utilizados para la obtención, almacenamiento y documentación de las pruebas electrónicas en la nube deben replicar los marcados para los mismos procedimientos preestablecidos para las pruebas electrónicas obtenidas de Internet y la problemática jurídica radica en determinar la forma y requisitos que deben tenerse en cuenta a la hora de obtener las pruebas electrónicas que, a falta de normativa, ha de extraerse de la escasa jurisprudencia dictada por los tribunales, según veremos a continuación.

Análisis de los marcos existentes para tratarlo o resolverloTal y como hemos comentado anteriormente, la prueba electrónica aún no está debidamente instaurada en los Tribunales españoles, siendo habitual que se produzca la confusión entre el documento electrónico y su copia impresa, siendo frecuente que se admitan como prueba, simples impresiones (ej.: correos electróni-cos), que no garantizan la integridad de la prueba, habiendo podido ser manipuladas, sobre la base de la libre disposición de la prueba por las partes si no son impugnadas (art. 326 de la Ley de Enjuiciamiento Civil). No obstante, existe jurisprudencia sectorial que resulta de utilidad para determinar los requisitos de las pruebas electrónicas.

Jurisprudencia en el ámbito penal. Es frecuente que el objeto de la prueba electrónica sean comunicaciones electrónicas (correos electrónicos) o contenidos de páginas web publicadas en Internet (blogs, redes sociales, etc.). Con carácter general, el art. 18 de la Constitución Española garantiza el derecho a la intimidad y el secreto de las comunicaciones, de forma que sólo pueden verse afectados mediante resolución judicial motivada y siempre que la medida sea idónea y proporcional a la búsqueda realizada. De esta forma, la intervención de una comunicación requiere que se dicte un mandamiento judicial en el seno de un procedimiento penal (arts. 579 y siguientes de la Ley de Enjuiciamiento Criminal).

Debido al desarrollo de las nuevas tecnologías, el Tribunal Supremo ha equiparado el correo electrónico a las comunicaciones, en sentido amplio, de modo que las garantías establecidas en el art. 579 de la Ley de Enjuiciamiento Criminal también son de aplicación a la intervención de los correos electrónicos. De


12. Anexos 136

esta forma, se posibilita la intervención de las comunicaciones en aplicación de la doctrina de la Sala II del Tribunal Supremo, que establece los siguientes requisitos:

a) Debe ser autorizada por la Autoridad Judicial

b) Finalidad exclusivamente probatoria

c) Excepcionalidad de la medida

d) Proporcionalidad de la medida

e) Limitación temporal de la utilización de la medida

f) Especialidad del hecho delictivo

g) La medida recaerá únicamente sobre personas indiciariamente implicadas

h) Existencia previa de procedimiento de investigación penal

i) Existencia previa de indicios de la comisión del delito, y no de meras sospechas o conjeturas

j) Exigencia de control judicial en la ordenación, desarrollo y cese de la medida

k) Que la resolución judicial acordando la intervención de las comunicaciones se halle suficientemente mo-tivada, riguroso requisito para el sacrificio y derogación en casos concretos de derechos fundamentales reconocidos en la Constitución Española; y

l) Además, para la validez como prueba del contenido de las comunicaciones intervenidas se precisa la entrega al órgano jurisdiccional de los soportes originales donde consten las conversaciones detectadas, sin consentirse la previa manipulación.

Jurisprudencia en el ámbito laboralLa Sentencia de la Sala 4ª del Tribunal Supremo de 26 de septiembre de 2007, que unifica la doctrina respecto al control empresarial de las nuevas tecnologías utilizadas por el trabajador, establece las si-guientes matizaciones, que han de ser tenidas en cuenta a la hora de obtener pruebas electrónicas en el ámbito laboral, ya sea un entorno corporativo que basa sus aplicaciones en servicios alojados en la nube o bien un entorno que depende del sistema operativo de cada uno de los ordenadores corporativos:(i) se han de establecer previamente las reglas de uso de los medios informáticos y de comunicación facilitados por la empresa a los trabajadores (con aplicación de prohibiciones absolutas o parciales) y (ii) se ha de informar a los trabajadores que va a existir un control, y de los medios que han de aplicarse en orden a comprobar la corrección de los usos, así como de las medidas que han de adoptarse para garantizar la efectiva utilización laboral de los medios informáticos y de comunicación.

Por ello, si el medio se utiliza para usos privados en contra de las prohibiciones establecidas por el empre-sario y con conocimiento de los controles y medidas aplicables, no podrá entenderse que se ha vulnerado una “expectativa razonable de intimidad”, en los términos establecidos en las Sentencias del Tribunal Europeo de Derechos Humanos de 25 de junio de 1997 y de 3 de abril de 2007.


12. Anexos 137

También establece dicha Sentencia que, en aquellos casos en que la empresa no disponga de un pro-tocolo informático, lo que suele ser habitual, ha de tenerse en cuenta que, en el momento de obtener y analizar los documentos o datos contenidos en la nube se deberán tener en consideración los requisitos formales establecidos en el artículo 18 del Estatuto de los Trabajadores, que aplica por asimilación el registro de la taquilla del trabajador con el análisis de los datos contenidos en la nube. Aplicando este precepto por analogía, los registros deberán realizarse en el centro de trabajo y durante el horario laboral, con la asistencia del trabajador y, en su defecto, de un representante legal de los trabajadores, o, si no hubiere, de otros trabajadores (a ser posible, con una categoría profesional parecida a la del trabajador afectado).

Recomendaciones para la gestión de pruebas electrónicas en EspañaPara asegurar la admisibilidad de la prueba electrónica en un proceso judicial o arbitral, independiente-mente de la arquitectura del dispositivo o entorno que la almacena, han cumplirse unos requisitos mínimos. Por ello es imprescindible que ante cualquier incidente se acuda siempre a profesionales familiarizados con este tipo de procesos y que puedan aportar el máximo de garantías de:

a) Licitud: La prueba electrónica ha de obtenerse de forma lícita, sin vulnerar el derecho a la intimidad y el secreto de las comunicaciones que garantiza el artículo 18 de la Constitución Española. En el caso de que sea necesario realizar una injerencia en dichos derechos para la obtención de una prueba electrónica, sería necesaria una Resolución Judicial expresa y motivada que lo autorizara, fundada en la existencia de sospechas de la comisión de un delito. En todo caso, hay que tener presente el art. 197 del Código Penal, que regula el delito de revelación de secretos, castigando con las penas de prisión de uno a cuatro años y multa de doce a veinticuatro meses, al que se apodere de papeles, cartas, mensajes de correo electrónico o cualesquiera otros documentos o efectos personales de un tercero, o intercepte sus telecomunicaciones o utilice artificios técnicos de escucha, transmisión, grabación o reproducción del sonido o de la imagen, o de cualquier otra señal de comunicación, sin consentimiento.

b) Autenticidad: Debe garantizarse que la prueba es auténtica, es decir, que lo que se analiza es exac-tamente lo ocupado en la actuación, lo que requiere que se haya realizado adecuadamente la cadena de custodia.

c) Integridad: Dada la extremada mutabilidad de las pruebas electrónicas, es necesario preservar la integridad de la misma, no alterando su contenido.

d) Claridad: El componente tecnológico de la prueba electrónica hace que los expertos deban presentar-la ante los tribunales de forma clara y comprensible, para que personas legas en informática puedan comprenderla.

e) Cumplimiento de los requisitos procesales: El Informe Pericial (i) debe explicar el sistema de verificación realizado de forma suficiente para que pueda considerarse que tiene un mínimo de fiabili-dad y (ii) desde un punto de vista formal, debe hacerse la advertencia que exige el art. 335-2 de la Ley de Enjuiciamiento Civil en orden a que el perito manifieste expresamente que el Informe pericial se ha emitido en base a la verdad y que ha actuado con la mayor objetividad posible, tomando en conside-ración tanto lo que pueda favorecer como lo que sea susceptible de causar perjuicio a cualquiera de las partes, así como que conoce las sanciones penales en las que podría incurrir si incumpliere su deber como perito, bajo juramento de decir verdad.


12. Anexos 138

Anexo IV. Metodologías y tecnologías de auditoría

Las tablas 6 Y 7 a continuación, resumen las metodologías y tecnologías “diferenciadas” más representati-vas, tomando en cuenta sus principales ventajas y desventajas desde una perspectiva pragmática.

Origen Descripción Ventajas Inconvenientes

Cloud Control Matrix (CCM).

Cloud Security Alliance. Basada en la “Security Guidance for

critical Areas of focus in Cloud Computing V2”

Programa de auditoria enfocado en evaluar

los requisitos fundamentales de

seguridad en la nube.

- Muy estructurado: 11 dominios y 108 objetivos

de control.- Muy específico para

seguridad.- Ofrece una terminología de la seguridad aplicada

a la nube.

- No define ninguna métrica.

- No incorpora aspectos fuera de la seguridad.

Cloud Computing Information Assurance Framework

ENISA

Framework que permiten evaluar el

riesgo de la adopción de servicios en la nube en base un

conjunto de criterios de seguridad.

- Enfocado en la toma de decisión de adoptar un

servicio de computación en la nube.

- Ámbito reducido.- No define ninguna

métrica.

Cloud Computing Management- Audit/Assurance Program.

ISACA - Basada en Cobit

Programa de auditoria completo y modelo de madurez sobre computación en la

nube.

- Añade aspectos fuera del ámbito de la

seguridad.- Basada en un

framework consolidado y muy reconocido (CObIT).- Aborda la planificación y alcance de la auditoria

hasta la auditoria operativa y el gobierno de

la nube.-Dispone de métricas.

- Requiere un mayor grado de adopción

por parte de los proveedores.

- Posibles problemas de “interoperabilidad” con respecto a otras

metodologías.

Cloud Assurance Maturity Model (CAMM)

ENISA. Basada en CMM, Cloud

Computing Information Assurance

Framework, ISO 27001, …

Programa de auditoria completo y Modelo de madurez sobre computación en la

nube.

- 5 Dominios-Dispone de métricas.

- Incorpora las mejores prácticas del mercado.

- La existencia de métricas facilita la comparación entre

proveedores de computación en la nube.

- Requiere un mayor grado de adopción

por parte de los proveedores.

- Posibles problemas de “interoperabilidad” con respecto a otras

metodologías.

Tabla 6. Resumen de las principales metodologías y tecnologías de auditoría para la computación en la nube

Continúa en página siguiente


12. Anexos 139

Origen Descripción Ventajas Inconvenientes

Service Organization Controls Report (SOC) Anteriormente conocido como SAS 70

AICPA

Se trata de una guía para proveer un

examen altamente especializado de los

controles internos de una organización.

Los reportes obtenidos son

aplicables a los modelos de servicio

de la nube.

- Es una autoridad reconocida para proveer los medios que permiten

lograr las certezas acerca de terceras

organizaciones.- SOC3 es una evolución

del AICPA/Canadian Institute of Chartered

Accountants (CICA) Trust Services Principle- Se ha diseñado

especialmente para proveer certezas acerca

de la confianza en los control de empresas

orientadas a servicios, por lo cual su aplicación

a la nube es clara.

- El estándar se encuentra en una

etapa muy reciente de madurez.

ISO/IEC 27001

International Standards

Organisation (ISO) and

International Electrotechnical

Commission (IEC)

Especifica formalmente a un

sistema de gestión, cuyo propósito

es implementar la seguridad de la información basándose en

controles explícitos y específicos.

Los proveedores de servicios en la nube

que dicen haber adoptado la ISO/

IEC 27001 pueden ser formalmente

auditados, y certificados como que cumplen con el estándar. Esta

certificación ofrece garantías sobre

la seguridad de la información a los

clientes de la nube.

- Internacionalmente reconocida.

- Posee una lista muy completa de controles.

- El ámbito de la certificación, así como algunos datos sobre la

organización auditora se hacen públicos.

- El ámbito de la certificación

podría llegar a ser inapropiado.

- La certificación es posible aunque existan riesgos significativos.

Viene de página anterior


12. Anexos 140

A la par de las metodologías de auditoría que han sido creadas específicamente para la computación en la nube, también han ido surgiendo una serie de tecnologías y/o herramientas automatizadas (CAATS) que permiten auditar este tipo de sistemas. Las más representativas se resumen en la tabla siguiente.

Tecnología Descripción Características

CloudAudit. (anteriormente conocida como “A6 - The Automated Audit, Assertion, Assessment, and Assurance API’’)

Define una API para facilitar los procesos de auditoría en la nube, y para que los clientes puedan verificar

el nivel de seguridad de su proveedor.

- Tiene como objetivo dar mayor transparencia a los proveedores de servicios en la nube mediante la creación de una interfaz común y un espacio de nombres -namespace-

que permitan la automatización de las auditorías, aserciones, asesoramiento y garantías que ofrecen los

ambientes de computación en la nube.- Es escalable, ha sido diseñado de forma que su funcionalidad pueda extenderse de acuerdo a las

necesidades de los clientes.- Para que sea viable requiere de un mayor grado de

adopción por parte de los proveedores.-En su primer versión CloudAudit utiliza el modo de

“solo lectura” (únicamente permite obtener información pre-generada por el proveedor), pero futuras versiones

implementarán la opción de “escritura” (p. ej. para solicitar un network-scan bajo demanda).

Immutable Audit Logs (IAL

Es una tecnología diseñada para grabar todos aquellos

eventos que tienen lugar en cualquier aplicación

o ambiente que requiera compartir información.

- Es posible mostrar de forma irrefutable que existe un grado de cumplimiento con las políticas o legislaciones

aplicables.- Esta tecnología ha sido avalada con reconocimientos

como el de “The Markle Foundation Task Force on National Security in the Information Age”.

- Provee una certeza matemática sobre la integridad del contenido.

- Registra una secuencia inmutable de eventos que han ocurrido sobre los datos.

- No se altera el contenido protegido, y sigue reteniendo su formato nativo.

- Bajo overhead (por ejemplo, comparado con el uso de firmas electrónicas para cada evento).

- Es posible tener una solución “solo-software” de forma que provea flexibilidad, escalabilidad e interoperabilidad.

- En una segunda fase, los eventos que han sido registrados se vuelven “inmutables”, de forma que se haga evidente

cualquier modificación no autorizada y, sea posible crear la evidencia relacionada con las modificaciones autorizadas

que se hayan realizado.

Tabla 7. Resumen de las principales herramientas de automatización de auditorías para la computación en la nube


Listado de Co-Autores Report CSA 141

Nombre Cargo Empresa

Emilio Aced Subdirector General de Registro de Ficheros y Consultoría

Agencia de Protección de Datos de la Comunidad de Madrid

Emiliano Astudillo Jiménez Manager “PwC PricewaterhouseCoopers Auditores, S.L.”

Miguel Ángel Ballesteros Ballesteros Auditor CEPSA

Miguel Luis Banegas Gallego

Consultor Gerente en la Dirección de Marketing de Infraestructuras Telefonica Grandes Clientes

Roberto Baratta Martínez Director de Gestión Interna e Identidades Novacaixagalicia

Joan Barceló i Joaquín Técnico de Cumplimiento Normativo CatalunyaCaixa

Mariano J. Benito Gómez Director de Seguridad / CISO GMV Soluciones Globales Internet

Matías Bevilacqua Trabado Director Tecnológico CFLabs

Roberto Blanc Torres Marketing Director Kinamik

Luís Buezo Director EMEA IT Assurance HP Technology Services

Nadeem Bukhari VP de Product Strategy Kinamik

Juan Francisco Cornago Baratech Manager Strategy Consulting Grupo SIA

Ana Belén Galán López Técnico de Seguridad en la Direccion de Riesgos Tecnologicos y Seguridad Informatica Bankinter

Erwin Güiza Ingeniero de Sistemas y Computación Universidad de Los Andes - Bogotá, Colombia

Adolfo Hernández Lorente Gerente de Governance, Risk & Compliance Ecija

Francisco Javier Carbayo Vázquez

Asociado Senior del Área de Governance, Risk & Compliance Ecija

José Manuel Carmona López-Tello

Responsable del Grupo de Seguridad. Departamento de Preventa Oracle Ibérica

Ramón Codina IT Governance Auditor Atmosferia Projects, S.L.

Gianluca D´Antonio Chief Information Security Officer (CISO) Grupo FCC

Enrique Fojón Chamorro Ingeniero Superior en Informatica | ISO 27001 Lead Auditor

Rafael García del Poyo Abogado. Socio Director del Departamento de Derecho de las Tecnologías de la Información

Cremades & Calvo-Sotelo / Abogados

Marcos Gómez Subdirector de Programas Instituto Nacional de Tecnologías de la Comunicación (INTECO)

Juan José Huerta Díaz Seguridad de Sistemas Mutua Madrileña

Fredesvinda Insa Mérida Directora de desarrollo estratégico CFLabs

Casimiro Juanes Director Regional de Seguridad RMED Ericsson

Jorge Laredo IT Assurance Senior Project Manager, HP Technology Consulting Hewlett-Packard Company

Samuel Linares Director Servicios TI y Seguridad Intermark Tecnologías

Alfonso López García Director de Calidad Nexica

Listado de Co-Autores Report CSA


Listado de Co-Autores Report CSA 142

Nombre Cargo Empresa

Javier López Gutierrez Socio Director de Litigation & Forensic Services Ecija

Dr. Jesús Luna García Investigador Technische Universität Darmstadt (Alemania)

María Elena Maestre García Socio de Riesgos Tecnológicos PricewaterhouseCoopers Auditores S.L.

Jesús Milán Director de Riesgos Tecnológicos y Seguridad Informática Bankinter

Ramón Miralles López Coordinador de Auditoria y Seguridad de la Información

Autoridad Catalana de Protección de Datos

Sergi Morales Surribas CTO Expertos en TI

Manuel Muñiz Somoza IT Security Manager Axpe Consulting

José Leandro Núñez García Abogado

Alfredo Oblanca García Gerente de auditoría y seguridad de la información BDO

Laia Porcar IT Project Leader ING Belgium

Antonio Ramos Managing Partner n+1 Intelligence & Research

Nathaly Rey Arenas Directora General ISMS Forum Spain

Mario Reyes de los Mozos Investigador senior

María Luisa Rodríguez Security R&D Business Manager. | Contratación, Evidencias Electrónicas y Auditoria en la Nube

Barcelona Digital Centre Tecnològic

Julio San José Sánchez Gerente Seguridad Bankinter

Carlos Alberto Sáiz Peña Socio responsable del Área de GRC Governance, Risk y Compliance Ecija

Esmeralda Saracíbar Serradilla

Gerente del Área de Governance, Risk & Compliance Ecija

Alvaro Sastre Planificación y Normalización ONO

Rodolfo Tesone Mendizabal Director del Área Jurídico-Tecnológica ITGLOBAL

Alejandro Touriño Asociado Senior del área de Information Technology Ecija

Víctor A. VillagráProfesor Titular de Universidad. Dpto. Ingeniería Telemática en la E.T.S.I. Telecomunicación

Universidad Politécnica de Madrid (UPM)