CSA Guía de Seguridad User Manual

La ubicación permanente y ocial de la versión 4 de la “Guía de Seguridad de Áreas Críticas para la Computación en la Nube” de Cloud Security Alliance está en https://cloudsecurityalliance.org/

download/securityguidance-v4/.

Guía Ocial de Estudio para el

Cloud security Alliance permite el uso de su “Guía de Seguridad de Áreas Críticas para la Computación en la Nube” (“GuiaCSAv4”) bajo licencia Creative Commons AttributionNonCommercial-ShareAlike 4.0 International License (CC-BY-NC-SA 4.0).

Compartir – Puede compartir y redistribuir la Guía en cualquier medio, canal o formato, siempre con propósito no comercial.

Adaptación – Puede adaptar, transformar, modicación o añadir contenidos a la Guía, y distribuir este resultado, solo con nes no comerciales.

Autoría – Debe reconocer la autoría de la Guía por Cloud Security Alliance, incluyendo enlaces a la página de la guía que se encuentra en https://cloudsecurityalliance.org/download/security-

guidance-v4/, e indicar si se han realizado cambios sobre la Guía. No puede declararse o sugerirse

que cualquiera de estos trabajos fue soportado, respaldado o visado por CSA.

Conservación de licencia – Todas las modicaciones y adaptaciones de la Guía deben ser distribuidas bajo el mismo modelo de licencia que la Guía original

Sin restricciones adicionales. No pueden aplicarse limitaciones contractuales, legales y/o técnicas a esta Guía que limite las capacidades de uso de la misma por otros usuarios, más allá de las establecidas por las propias condiciones de licencia.

Licenciamiento comercial – Si desea adaptar, modicar, compartir o distribuir copias de la GuiaCSAv4 para actividades que generen ingresos, es necesario que primero obtenga de Cloud Security Alliance las licencias adecuada para ello. Por favor, contacte con info@cloudsecurityalliance.org.

Avisos: Todas las marcas, copyrights, avisos y advertencias incluidas en la GuiaCSAv4 deber ser incluidas y reproducidas, y no deben ser eliminadas o alteradas.

PROLOGO

Bienvenido a la cuarta versión de la Guía de Seguridad de Áreas Críticas para la Computación en la Nube de Cloud Security Alliance (CSA). El aumento de la computación en la nube como una

tecnología en constante evolución trae consigo una serie de oportunidades y desafíos. Con este documento, nuestro objetivo es proporcionar tanto orientación como inspiración para respaldar los objetivos comerciales, mientras se gestionan y mitigan los riesgos asociados con la adopción de la tecnología de computación en la nube.

Cloud Security Alliance promueve la implementación de buenas prácticas para proporcionar seguridad en el ámbito de la computación en la nube y ha elaborado una hoja de ruta práctica y ejecutable para organizaciones que buscan adoptar el paradigma de la nube. La cuarta versión de la Guía de Seguridad de Áreas Críticas para la Computación en la Nube se basa en iteraciones previas de la guía de seguridad, en investigación dedicada y participación pública tanto de los miembros de Cloud Security Alliance, como de grupos de trabajo y expertos de la industria dentro de nuestra comunidad. Esta versión incorpora los últimos avances en cuanto a computación en la nube, aspectos de seguridad y tecnologías de soporte; reeja las prácticas de seguridad en la nube del mundo real; integra los últimos proyectos de investigación de Cloud Security Alliance; y ofrece orientación para tecnologías relacionadas.

El avance hacia la computación en la nube segura requiere la participación activa de un amplio conjunto de partes interesadas distribuidas a nivel mundial. CSA reúne a una diversa comunidad que incluye diversas asociaciones industriales, capítulos internacionales, grupos de trabajo e individuos. Estamos profundamente agradecidos a todos los que contribuyeron a este lanzamiento.

Por favor visite cloudsecurityalliance.com si está interesado en trabajar con nosotros en identicar y promover las mejores prácticas para garantizar un entorno de computación en la nube seguro.

Atentamente,

Luciano (J.R.) Santos

Vicepresidente Ejecutivo de Investigación Cloud Security Alliance

AGRADECIMIENTOS

De la traducción al Castellano:

Realizada por los siguientes capítulos del CSA:

CSA-ES: Capítulo Español del CSA: http://www.ismsforum.es/csa CSA-CH: Capítulo Chileno del CSA: https://www.linkedin.com/groups/3350633/prole CSA-PE: Capítulo Peruano del CSA: https://www.linkedin.com/groups/3720349/prole CSA-AR: Capítulo Argentino del CSA: https://chapters.cloudsecurityalliance.org/argentina/

Editores / revisores de la edición en Castellano:

Mariano J. Benito, GMV Ricardo Urbina, CSA Capítulo Chileno Jorge Laredo, HPE Diego Bueno, Bankinter

Equipo de traducción de la edición en Castellano:

Antonio Sanz, S2 Grupo Fernando Iglesias, CSA Capítulo España María Jesús Casado, CSA Capítulo España Alexei Morales, CSA Capítulo Chile Carlos Samaniego, CSA Capítulo Chile Edson Vittoriano, CSA Capítulo Chile Juan José Cuellar, CSA Capítulo Chileno Manuel Caldas, Telefónica Gerardo Guzmán, Banco de Crédito del Perú Jorge Rojas, AGN Consultores Leonardo Rosso, CSA Capítulo Argentina Luciano Moreira, CSA Capítulo Argentina

Equipo CSA de coordinación traducción:

Ryan Bergsma, CSA Marina Bregou, CSA

Autores Principales

Rich Mogull James Arlen Francoise Gilbert Adrian Lane David Mortman Gunnar Peterson Mike Rothman

Editores

John Moltz

Dan Moren

Evan Scoboria

Sta CSA

Jim Reavis Luciano (J.R.) Santos Hillary Baron Ryan Bergsma Daniele Catteddu Victor Chin Frank Guanco Stephen Lumpe (Design) John Yeoh

Colaboradores

En nombre de la Junta de Directores de CSA y del Equipo Ejecutivo de CSA, nos gustaría agradecer a todas las personas que contribuyeron con su tiempo y comentarios a esta versión de la Guía de Seguridad de Áreas Críticas para la Computación en la Nube de CSA. Valoramos sus contribuciones voluntarias y creemos que la dedicación de voluntarios como ustedes continuará liderando Cloud Security Alliance en el futuro.

Nota del equipo de traducción

El equipo de traducción, compuesto por personas de múltiples países de habla hispana, ha decidido utilizar en esta guía diversas acepciones y sinónimos del idioma (p.e. monitorización / monitoreo) intentado hacer así una guía más universal.

CARTA DEL DIRECTOR EJECUTIVO (CEO)

Estoy emocionado con esta última contribución a la base de conocimiento de la comunidad de las mejores prácticas de seguridad en la nube que comenzó con el documento de orientación inicial de Cloud Security Alliance publicado en abril de 2009. Esperamos que estudie cuidadosamente los problemas y recomendaciones aquí resumidos, compare con su propia experiencia y nos brinde su opinión. Un gran agradecimiento a todos los que participaron en esta investigación.

Recientemente, tuve la oportunidad de pasar un día con uno de los expertos de la industria que ayudó a fundar Cloud Security Alliance. Me comentó que, en gran parte, CSA ha completado su misión inicial, que era probar que la computación en la nube podría protegerse y proporcionar las herramientas necesarias para ese n. CSA no solo ayudó a hacer de la computación en la nube una opción segura y creíble para la tecnología de la información, sino que hoy la computación en la nube se ha convertido en la opción predeterminada para TI y está reconvirtiendo el mundo empresarial moderno de manera muy profunda.

El rotundo éxito de la computación en la nube y el rol de CSA en liderar el ecosistema de la nube de conanza traen consigo aún mayores desafíos y urgencias en nuestra misión renovada. La nube ahora se está convirtiendo en el back-end para todas las formas de informática, incluido el omnipresente Internet de las Cosas. La computación en la nube es la base de la industria de la seguridad de la información. Las nuevas formas de organizar el cómputo, como los contendedores y DevOps son inseparables de la nube y aceleran nuestra revolución.

En Cloud Security Alliance nos comprometemos a proporcionarle el conocimiento esencial relativo a los aspectos de seguridad que necesita para este entorno de TI de rápida evolución y permanecer a la vanguardia de las tendencias de protección y conanza de nueva generación. Damos la bienvenida a su participación en nuestra comunidad.

Atentamente,

Jim Reavis

Cofundador y Director Ejecutivo Cloud Security Alliance

CONTENIDO

DOMINIO 

Conceptos y Arquitecturas de

la Computación en la Nube

DOMINIO 5

Gobierno de la Información

DOMINIO 9

Respuesta ante Incidentes

DOMINIO 2

Gobierno y Gestión del

Riesgo Corporativo

DOMINIO 6

Plano de Gestión y

Continuidad del Negocio

DOMINIO 10

Seguridad de Aplicaciones

DOMINIO 3

Cuestiones Legales, Contratos y Descubrimiento Electrónico

DOMINIO 7

Seguridad de la

Infraestructura

DOMINIO 11

Seguridad y Cifrado de Datos

DOMINIO 4

Cumplimiento y Gestión

de Auditoría

DOMINIO 8

Virtualización y Contendores

DOMINIO 12

Gestión de Identidades,

Derechos y Accesos

DOMINIO 13

Seguridad como Servicio

DOMINIO 14

Tecnologías Relacionadas

DOMINIO 1

Conceptos y Arquitecturas de la Computación en la Nube

1.0 Introducción

Este dominio proporciona el marco conceptual para el resto de la Guía de Seguridad de Cloud Security Alliance. Describe y dene la computación en la nube, establece nuestra terminología básica, y detalla la lógica general y el marco arquitectónico utilizados en el resto del documento.

Existen muchas formas diferentes de ver la computación en la nube: es una tecnología, una colección de tecnologías, un modelo operativo, un modelo de negocio, solo por nombrar algunos. Es, en esencia, transformador y disruptivo. También está creciendo muy, muy rápido y no muestra signos de desaceleración. Mientras que los modelos de referencia que incluimos en la primera versión de esta Guía son todavía relativamente precisos, ciertamente no están ya completos. Incluso esta actualización posiblemente no cubra todas las posibles evoluciones en los próximos años.

La computación en la nube ofrece inmensos benecios potenciales en agilidad, exibilidad y economía. Las organizaciones pueden moverse más rápido (ya que no tienen que comprar y aprovisionar hardware, y todo está denido por software), reducir el tiempo de inactividad (gracias a la elasticidad inherente y a otras características de la nube), y ahorrar dinero (debido a la reducción de los gastos de capital y una mejor vinculación entre la demanda y capacidad). También ofrece benecios de seguridad ya que los proveedores de servicios en la nube tienen importantes incentivos económicos para proteger a los clientes.

Sin embargo, estos benecios solo aparecen si se comprenden y adoptan modelos nativos de la nube y se ajustan sus arquitecturas y controles para alinearse con las características y capacidades de las plataformas en la nube. De hecho, tomar una aplicación o activo existente y simplemente moverlo a un proveedor de servicios en la nube sin ningún cambio a menudo reducirá la agilidad, la resistencia e incluso la seguridad, todo ello mientras se incrementan los costos.

El objetivo de este dominio es construir la base en la que el resto del documento y sus recomendaciones se fundamentan. La intención es proporcionar un lenguaje común y la comprensión de la computación en la nube para profesionales de la seguridad. Se comienza destacando las diferencias entre la nube y la computación tradicional, y ayudar a orientar a los profesionales de seguridad hacia un enfoque de la adopción de la nube nativa que resulten en una mejor seguridad (y esos otros benecios), en lugar de crear más riesgos.

Este dominio incluye 4 secciones:

• Denición de la computación en la nube

• El modelo lógico de la nube

• Modelo conceptual, arquitectónico y de referencia de la nube

• Alcance, responsabilidades y modelos de seguridad y cumplimiento de la nube

Cloud Security Alliance no se propone crear una nueva taxonomía o modelo de referencia. Nuestro objetivo es renar y armonizar los modelos existentes – especialmente el trabajo de NIST Special

Publication 800-145, ISO/IEC 17788 e ISO/IEC 17789 –, y concentrarse en lo que es más relevante

para los profesionales de la seguridad.

1.1 Visión General

1.1.1 Denición de la Computación en la Nube

La computación en la nube es un nuevo modelo operacional y un conjunto de tecnologías para administrar grupos compartidos de recursos informáticos.

Es una tecnología disruptiva que tiene el potencial de mejorar la colaboración, agilidad, escalabilidad y disponibilidad, además de facilitar oportunidades para la reducción de costos a través de una optimización y eciencia informática. El modelo de la nube contempla un mundo donde los componentes se pueden orquestar rápidamente, aprovisionado, implementado y desmantelado, y escalando hacia arriba o hacia abajo para proporcionar un modelo de asignación y consumo similar a un servicio a pedido.

NIST dene la computación en la nube como:

La computación en la nube es un modelo para permitir un acceso de red ubicuo, conveniente y bajo demanda a un grupo compartido de recursos informáticos congurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que pueden aprovisionarse y liberarse rápidamente con un mínimo esfuerzo o interacción del proveedor de servicio.

La denición de ISO/IEC es muy similar:

Paradigma para permitir el acceso de red a un conjunto de recursos compartidos, escalables y elásticos, físicos o virtuales con aprovisionamiento de autoservicio y administración bajo demanda.

Una forma (un poco) más simple de describir la nube es que toma un conjunto de recursos, como procesadores y memoria, y los coloca en un grupo grande de recursos (en este caso, usando virtualización). Los usuarios piden lo que necesitan del grupo de recursos, como 8 CPUs y 16 GB de memoria, y la nube asigna los recursos para el usuario, el cual se conecta y los utiliza a través de la red. Cuando el usuario naliza su uso, pueden liberar los recursos nuevamente en el grupo para que otro usuario los use.

Una nube puede consistir en casi cualquier recurso informático, desde nuestros ejemplos de “cómputo” de procesadores y memoria hasta redes, almacenamiento y recursos de mayor nivel como bases de

datos y aplicaciones. Por ejemplo, suscribirse a una aplicación de gestión de relaciones con clientes para 500 empleados en un servicio compartido por cientos de otras organizaciones es computación en la nube tanto como el lanzamiento de 100 servidores remotos en una nube informática.

Denición: Un usuario de servicios en la nube es la persona u organización que solicita y utiliza los recursos, y el proveedor de servicios en la nube es la persona u organización que lo entrega. A veces también usamos los términos cliente y consumidor para referirnos al usuario de servicios en la nube, y servicio o simplemente nube para describir al proveedor. NIST 500-292 usa el término “actor en la nube” y agrega roles para intermediarios en la nube, operadores, y auditores. ISO/IEC 17788 utiliza los términos servicio al cliente en la nube, socio de servicios en la nube y proveedor de servicios en la nube.

Las técnicas clave para crear una nube son la abstracción y la orquestación. Los recursos se abstraen de la infraestructura física subyacente para crear nuestras agrupaciones, y usamos la orquestación (y la automatización) para coordinar la distribución y la entrega de un conjunto de recursos de dichas agrupaciones al usuario. Como se verá, estas dos técnicas crean todas las características esenciales que utilizamos para denir algo como una “nube”.

Esta es la diferencia entre la computación en la nube y la virtualización tradicional; la virtualización abstrae los recursos, pero normalmente carece de la orquestación para agruparlos y entregarlos a pedido a los usuarios, en lugar de depender de procesos manuales.

Las nubes son de tenencia múltiple por naturaleza. Múltiples grupos de diferentes usuarios comparten el mismo grupo de recursos, pero están segregados y aislados el uno del otro. La segregación permite que el proveedor de servicios en la nube distribuya los recursos a los diferentes grupos, y el aislamiento asegura que no puedan ver o modicar los activos de los demás. La tenencia múltiple no solo se aplica en diferentes organizaciones; también se usa para dividir recursos entre diferentes unidades en una sola empresa u organización.

1.1.2 Modelo de denición

Cloud Security Alliance (CSA) usa el modelo NIST de la computación en la nube como su estándar para denir la computación en la nube. El CSA también se apoya en el modelo ISO/IEC que es más profundo, y además sirve como modelo de referencia. A lo largo de este dominio, haremos referencia a ambos.

La publicación de NIST es generalmente bien aceptada, y la guía se alinea con el NIST Working Denition of Cloud Computing (NIST 800-145) para brindar coherencia y consenso en torno a un lenguaje para enfocarse en casos de uso en lugar de matices semánticos.

Es importante tener en cuenta que esta guía está destinada a ser ampliamente utilizable y aplicable a las organizaciones a nivel mundial. Si bien el NIST es una organización gubernamental de los EE. UU., la selección de este modelo de referencia no debe interpretarse como una sugerencia de exclusión de otros puntos de vista o geografías.

NIST dene la computación en la nube mediante la descripción de cinco características esenciales, tres modelos de servicios en la nube y cuatro modelos de implementación en la nube. Se resumen de forma visual y se explican en detalle en la página siguiente.

Acceso Banda

Ancha

Elasticidad

rápida

Servicio Medido

Agrupación de Recursos

Autoservicio

Bajo Demanda

Características

Esenciales

SaaS

(Software como Servicio)

Pública

(Plataforma como Servicio)

Privada Híbrida Comunitaria

PaaS

IaaS

(Infraestructura como Servicio)

Modelos de

Servicio

Modelos de

despliegue

1.1.2.1 Características esenciales

Estas son las características que hacen que una nube sea una nube. Si algo tiene estas características, considérelo computación en la nube. Si carece de alguno de ellos, probable que no sea una nube.

• La agrupación de recursos es la característica más fundamental, como se discutió anteriormente. El proveedor abstrae los recursos y los recopila en un grupo, partes de los cuales se pueden asignar a diferentes usuarios (generalmente basados en políticas).

• Los usuarios aprovisionan los recursos del grupo mediante el autoservicio bajo demanda. Ellos manejan sus propios recursos, sin tener que hablar con un administrador humano.

• El amplio acceso a la red signica que todos los recursos están disponibles en una red, sin necesidad del acceso físico directo; la red no es necesariamente parte del servicio.

• La elasticidad rápida permite a los usuarios ampliar o contraer los recursos que utilizan del grupo (aprovisionamiento y desaprovisionamiento), a menudo de forma completamente automática. Esto les permite relacionar más estrechamente el consumo de recursos con la demanda (por ejemplo, agregar servidores virtuales cuando la demanda aumenta y luego apagarlos cuando baja la demanda).

• Medidores de servicio que son proporcionados, para garantizar que los usuarios solo usen lo que se ha asignado, y, si es necesario, cobrar por ello. Aquí es donde viene el término computación como servicio público (utility computing), ya que los recursos informáticos ahora se pueden consumir como el agua y la electricidad, el cliente solo paga por lo que usa

ISO/IEC 17788 enumera seis características clave, las primeras cinco de las cuales son idénticas a las características del NIST. La única adición es múltiple tenencia, que es distinta de la agrupación de recursos.

1.1.2.2 Modelos de servicio

El NIST dene tres modelos de servicio que describen las diferentes categorías fundamentales de servicios en la nube:

• Software como servicio (SaaS) es una aplicación completa administrada y alojada por el proveedor. Los usuarios acceden a ella con un navegador web, una aplicación móvil o una aplicación de cliente liviana.

• Plataforma como Servicio (PaaS) abstrae y proporciona plataformas de desarrollo de aplicaciones, como bases de datos, plataformas de aplicaciones (por ejemplo, un lugar para ejecutar Python, PHP u otro código), almacenamiento de archivos y colaboración, o incluso procesamiento de aplicaciones propietarias (como aprendizaje de máquina, procesamiento de Big Data o acceso directo a interfaces de programación de aplicaciones (API) a características de una aplicación SaaS completa). El diferenciador clave es que, con PaaS, no se maneja los servidores, redes u otra infraestructura subyacente.

• Infraestructura como servicio (IaaS) ofrece acceso a un conjunto de recursos de infraestructura base de informática, como computación, red o almacenamiento.

A veces estos modelos de servicios se denominan niveles “SPI”.

ISO/IEC utiliza una denición más compleja con tipos de capacidades de nube que se correlacionan estrechamente con los niveles SPI (aplicación, infraestructura y tipos de capacidad de plataforma). Entonces lo expande a categorías de servicios en la nube que son más granulares, como computación como un servicio, almacenamiento de datos como un Servicio e incluso incluye IaaS / PaaS / SaaS.

Estas categorías son algo permeables: algunos servicios en la nube abarcan estos niveles, otros no caen en un solo modelo de servicio. Hablando en términos prácticos, no hay razón para tratar de asignar todo en estas tres amplias categorías, o incluso en las categorías más granulares en el modelo ISO/IEC. Esto es simplemente una herramienta descriptiva útil, no un marco rígido.

Ambos enfoques son igualmente válidos, pero dado que el modelo NIST es más conciso y actualmente se usa de manera más amplia, es la denición utilizada predominantemente en la investigación de CSA.

1.1.2.3 Modelos de implementación

Tanto el NIST como ISO/IEC utilizan los mismos cuatro modelos de implementación en la nube. Estos modelos denen la forma en la que las tecnologías se implementan y consumen, y se aplican en toda la gama de modelos de servicio:

• Nube pública. La infraestructura de la nube está disponible para el público en general o un gran grupo de la industria y es propiedad de una organización que vende servicios en la nube.

• Nube privada. La infraestructura de la nube se opera únicamente para una sola organización. Puede ser administrado por la organización o por un tercero y puede estar ubicado en sus instalaciones o fuera de su propiedad.

• Nube comunitaria. La infraestructura en la nube es compartida por varias organizaciones y

soporta a una comunidad especíca que tiene inquietudes compartidas (por ejemplo, misión, requisitos de seguridad, política o consideraciones de cumplimiento). Puede ser administrado por las organizaciones o por un tercero y puede estar ubicado en sus instalaciones o fuera de ellas.

• Nube híbrida. La infraestructura de la nube es una composición de dos o más nubes (privada, comunitaria o pública) que siguen siendo entidades únicas, pero están unidas por estándares o tecnología patentada que permite la portabilidad de datos y aplicaciones (por ejemplo, proliferación de nubes para equilibrar la carga entre nubes). El término Híbrido también se usa comúnmente para describir un centro de datos que no está en la nube y está conectado directamente a un proveedor de servicios en la nube.

Los modelos de implementación se denen según el usuario de servicios en la nube, es decir, quién usa la nube. Como se muestra en el siguiente diagrama, la organización que posee y administra la nube variará incluso dentro de un único modelo de implementación.

Infraestructura

Propiedad de

Pública

Privada/

Comunitaria

Híbrida

La administración incluye: gobierno, operaciones, seguridad, cumplimiento, etc.

La infraestructura implica infraestructura física, como instalaciones, redes informáticas y equipos de

Proveedor externo

Organización

Proveedor Ext.

Organización y proveedor ext.

Infraestructura

Propiedad de

Infraestructura

Localizada en

Consumidad por

Accesible y

Proveedor externo Instalación propia No conable

Organización

Instalación propia

Conable

Proveedor Ext.

Organización y proveedor ext.

Instalación Externa

Instalación propia

y externa

Conable y no

conable

almacenamiento

La ubicación de la infraestructura es tanto física como relativa al alcance de gestión de una organización

y habla de propiedad versus el control

Los usuarios de conanza del servicio son aquellos que se consideran parte del alcance legal / contractual / político de una organización, incluidos empleados, contratistas y socios comerciales. Los usuarios que no son de conanza son aquellos que pueden estar autorizados para consumir algunos / todos los servicios, pero no son extensiones lógicas de la organización

1.1.3 Modelos de referencia y arquitectura

SaaS (Software como Servicio)

PaaS (Plataforma como Servicio)

IaaS (Infraestructura como Servicio)

En la actualidad, existe una amplia gama de técnicas y tecnologías en constante evolución para la creación de servicios en la nube, lo que hace que cualquier referencia o modelo arquitectónico sea obsoleto desde el principio. El objetivo de esta sección es proporcionar algunos fundamentos para ayudar a los profesionales de seguridad a tomar decisiones informadas, así como una línea de base para comprender modelos más complejos y emergentes. Para un profundo modelo arquitectónico de referencia, nuevamente recomendamos ISO/IEC 17789 y NIST 500-292, que complementan el modelo de denición NIST.

Una forma de ver la computación en la nube es como una pila donde el Software como Servicio se basa en la Plataforma como Servicio, que se basa en la Infraestructura como Servicio. Esto no es representativo de todas (o incluso la mayoría) de las implementaciones del mundo real, pero sirve como una referencia útil para iniciar la discusión.

Modalidad de

Presentación

Plataforma de

Presentación

APIs

Aplicaciones

Datos

Metadatos Contenido

Integración & Middleware

APIs

Conectividad de base & Operación

Abstracción

Hardware

Instalaciones

1.1.3.1 Infraestructura como servicio (IaaS)

Las instalaciones físicas y la infraestructura de hardware forman la base de IaaS. Con la computación en la nube, abstraemos y agrupamos estos recursos, pero en el nivel más básico siempre necesitamos hardware físico, redes y almacenamiento para construir sobre ellos. Estos recursos se agrupan utilizando abstracción y orquestación. La abstracción, a menudo a través de la virtualización, libera los recursos de sus restricciones físicas para permitir la agrupación. Luego, un conjunto de herramientas básicas de conectividad y entrega (orquestación) vinculan estos recursos de abstracción en conjunto, crea los grupos y proporcionan la automatización para entregarlos a los clientes.

Todo esto se facilita mediante el uso de Interfaces de Programación de Aplicaciones (API). Las APIs generalmente son el método de comunicación subyacente para los componentes dentro de una nube, algunos de los cuales (o un conjunto totalmente diferente) están expuestos al usuario de servicios en la nube para administrar sus recursos y conguraciones. La mayoría de las APIs en la nube actualmente usan REST (Transferencia de estado representacional), que se ejecuta sobre el protocolo HTTP, lo que lo hace extremadamente adecuado para los servicios de Internet.

En la mayoría de los casos, esas APIs son accesibles de forma remota y se envuelven en una interfaz de usuario basada en web. Esta combinación es el plano de administración de la nube, ya que los consumidores lo usan para administrar y congurar los recursos de la nube, como el lanzamiento de máquinas virtuales (instancias) o la conguración de redes virtuales. Desde una perspectiva de seguridad, esta es la mayor diferencia al proteger la infraestructura física (ya que no puede conar en el acceso físico como control) y la máxima prioridad cuando se diseña un programa de seguridad en la nube. Si un atacante ingresa en su plano de administración, es posible que tenga acceso remoto completo a toda su implementación en la nube.

Así, IaaS consta de una instalación, hardware, una capa de abstracción, una capa de orquestación (conectividad básica y entrega) para unir los recursos abstraídos y APIs para administrar de forma remota los recursos y entregarlos a los consumidores.

Aquí hay un ejemplo arquitectónico simplicado de una plataforma de computación IaaS:

Mundo Exterior

Controlador

Computo

Administración de Redes

Controlador Almacenamiento/ Volumen

(Usando APIs)

Administración y Orquestración

MV MV

Hipervisor

MV MV

Hipervisor

MV MV

Hipervisor

Agrupamiento Computo

MV MV

Hipervisor

Administración y Orquestración

Agrupamiento Almacenamiento

Este es un diagrama muy simple que muestra los controladores de cómputo y almacenamiento para orquestación, hipervisores para abstracción y la relación entre los agrupamientos de cómputo y almacenamiento. Omite muchos componentes, como el administrador de red.

Una serie de servidores físicos ejecutan cada uno dos componentes: un hipervisor (para virtualización) y el software de administración / orquestación para vincular los servidores y conectarlos al controlador de cómputo. Un cliente solicita una instancia (servidor virtual) de un tamaño particular y el controlador de la nube determina qué servidor tiene la capacidad requerida y asigna una instancia del tamaño solicitado.

Luego, el controlador crea un disco duro virtual solicitando almacenamiento del controlador de almacenamiento, que asigna almacenamiento desde el agrupamiento de almacenamiento y lo conecta al servidor huésped correspondiente y a la instancia a través de la red (una red dedicada para el tráco de almacenamiento). Las redes, incluidas las interfaces y direcciones de redes virtuales, también se asignan y conectan a la red virtual necesaria.

El controlador luego envía una copia de la imagen del servidor a la máquina virtual, la inicia y la congura; esto crea una instancia que se ejecuta en una máquina virtual (VM), con la red virtual y el almacenamiento congurados correctamente. Una vez que se completa todo este proceso, el controlador de la nube correlaciona la información de metadatos y conectividad y la pone a disposición del consumidor, que ahora puede conectarse a la instancia e iniciar sesión.

1.1.3.2 Plataforma como servicio (PaaS)

De todos los modelos de servicio, PaaS es el más difícil de caracterizar denitivamente debido tanto a la amplia gama de ofertas de PaaS como a las muchas formas de crear servicios de PaaS. PaaS agrega una capa adicional de integración con marcos de desarrollo de aplicaciones, capacidades de middleware y funciones como bases de datos, mensajería y colas. Estos servicios permiten a los desarrolladores crear aplicaciones en la plataforma con lenguajes de programación y herramientas que son compatibles con la pila disponible en la nube.

Una opción, frecuentemente vista en el mundo real e ilustrada en nuestro modelo, es construir una plataforma sobre IaaS. Una capa de integración y middleware se basa en IaaS, luego es agrupada, orquestada y expuesta a los clientes usando APIs como PaaS. Por ejemplo, una base de datos como servicio podría construirse mediante la implementación de un software de sistema de gestión de bases de datos modicado en instancias que se ejecutan en IaaS. El cliente gestiona la base de datos a través de API (y una consola web) y accede a ella a través de los protocolos de red de base de datos normales o, de nuevo, a través de API.

En PaaS, el usuario de servicios en la nube solo ve la plataforma, no la infraestructura subyacente. En nuestro ejemplo, la base de datos se expande (o contrae) según sea necesario en función de la utilización, sin que el cliente tenga que administrar servidores individuales, redes, parches, etc.

Otro ejemplo es una plataforma de implementación de aplicaciones. Es un lugar donde los desarrolladores pueden cargar y ejecutar código de aplicación sin administrar los recursos subyacentes. Existen servicios para ejecutar casi cualquier tipo de aplicación en cualquier lenguaje en PaaS, liberando a los desarrolladores de la conguración y creación de servidores, manteniéndolos actualizados, o preocupándose por complejidades como la agrupación y el equilibrio de carga.

Este diagrama de arquitectura simplicado muestra una plataforma de aplicación (PaaS) que se ejecuta en la parte superior de nuestra arquitectura IaaS:

Mundo Exterior

Aplicación

Controlador

Computo

Administración y Orquestración

MV MV

Hipervisor

MV MV

Hipervisor

Agrupamiento Computo

Aplicación Aplicación Aplicación

Platforma de Aplicaciones

Administración de Redes

(Usando APIs)

MV MV

Hipervisor

MV MV

Hipervisor

Administración y Orquestración

Agrupamiento Almacenamiento

Controlador Almacenamiento/ Volumen

PaaS no necesariamente se debe construir encima de IaaS; no hay ninguna razón por la que no pueda ser una arquitectura autónoma diseñada a medida. La característica denitoria es que los consumidores acceden y administran la plataforma, no la infraestructura subyacente (incluida la infraestructura de la nube).

1.1.3.3 Software as a Service

Los servicios SaaS son aplicaciones completas para usuarios múltiples, con todas las complejidades arquitectónicas de cualquier plataforma de software grande. Muchos proveedores de SaaS se basan en IaaS y PaaS debido a la mayor agilidad, capacidad de recuperación y (potenciales) benecios económicos.

La mayoría de las aplicaciones modernas en la nube (SaaS u otras) utilizan una combinación de IaaS y PaaS, a veces a través de diferentes proveedores de servicios en la nube. Muchos también tienden a ofrecer API públicas para alguna (o toda) la funcionalidad. A menudo necesitan estas para soportar una variedad de clientes, especialmente navegadores web y aplicaciones móviles.

Por lo tanto, todo SaaS tiende a tener una capa de aplicación / lógica y almacenamiento de datos,

Empujar

Tirar

con una API en la parte superior. Luego, hay una o más capas de presentación que a menudo incluyen navegadores web, aplicaciones móviles y acceso público a la API.

El siguiente diagrama de arquitectura simplicado se toma de una plataforma SaaS real, pero se generaliza para eliminar las referencias a los productos especícos en uso:

Balanceador de Carga Nube

Grupo Escala Automática Servidor Web

Objeto

Almacenamiento

Base de Datos

Relacional Paas

Balanceador de Carga Interno

Grupo Escala Automática Servidor Aplicaciones

Cola Mensajes

PaaS

Agrupamiento Contenedores Microservicios

No-SQL

PaaS

Servicio

Notiﬁcaciones

1.1.4 Modelo lógico

A alto nivel, tanto la computación en la nube como la tradicional se adhieren a un modelo lógico que ayuda a identicar diferentes capas en función de la funcionalidad. Esto es útil para ilustrar las diferencias entre los diferentes modelos de computación:

• Infraestructura: Los componentes principales de un sistema informático: cómputo, red y almacenamiento. La base sobre la que se basa todo lo demás. Las partes móviles.

• Meta-estructura: Los protocolos y mecanismos que proporcionan la interfaz entre la capa de infraestructura y las otras capas. El pegamento que une las tecnologías y permite la administración y conguración.

• Info-estructura: Los datos y la información. Contenido en una base de datos, almacenamiento de archivos, etc.

• Apli-estructura: Las aplicaciones implementadas en la nube y los servicios de aplicaciones subyacentes utilizados para construirlos. Por ejemplo, las funciones de Plataforma como Servicio, como colas de mensajes, análisis de inteligencia articial o servicios de noticación.

Diferentes enfoques de seguridad se asignan a las diferentes capas lógicas. Seguridad de aplicaciones para la infraestructura de aplicaciones, seguridad de los datos a la info-estructura y seguridad de la infraestructura para la infraestructura.

Infoestructura

La diferencia clave entre la computación en la nube y la tradicional es la meta-estructura. La meta-

estructura de la nube incluye los componentes del plano de administración, que están habilitados para la red y accesibles de forma remota. Otra diferencia clave es que, en la nube, se tiende a duplicar en cada capa. La infraestructura, por ejemplo, incluye tanto la infraestructura utilizada para crear la nube como la infraestructura virtual utilizada y administrada por el usuario de servicios en la nube. En una nube privada, la misma organización podría necesitar administrar ambas; en la nube pública, el proveedor gestiona la infraestructura física mientras el consumidor gestiona su parte de la infraestructura virtual.

Como veremos más adelante, esto tiene profundas implicaciones sobre quién es el responsable y el administrador de la seguridad.

Estas capas tienden a asignarse a diferentes equipos, disciplinas y tecnologías que se encuentran comúnmente en las organizaciones de TI. Si bien las diferencias de gestión de seguridad más obvias e inmediatas se encuentran en la meta-estructura, la nube diere ampliamente de la informática tradicional dentro de cada capa. La escala de las diferencias dependerá no solo de la plataforma en

Apli-estructura

Meta-estructura

Infraestructura

la nube, sino de cómo exactamente el usuario de servicios en la nube utiliza la plataforma.

Por ejemplo, una aplicación nativa de la nube que hace una gran utilización de los productos PaaS de un proveedor de servicios en la nube experimentará más diferencias en la aplicación que la migración de una aplicación existente, con cambios mínimos, a la Infraestructura como servicio.

1.2 Ámbito, responsabilidades y modelos de seguridad en la nube

1.2.1 Alcance y responsabilidades de la seguridad en la nube y el cumplimiento

Puede sonar simplista, pero la seguridad en la nube y el cumplimiento incluyen todo lo que un equipo de seguridad es responsable hoy en día, solo que en la nube. Todos los dominios de seguridad tradicionales permanecen, pero la naturaleza de los riesgos, roles y responsabilidades, y la implementación de los controles cambian, a menudo dramáticamente.

Aunque el alcance general de la seguridad y el cumplimiento no cambian, las piezas de las que en particular cualquier actor de la nube es responsable de hacer, ciertamente sí cambian. Piénselo de esta manera: La computación en la nube es un modelo de tecnología compartida donde las diferentes organizaciones son responsables, frecuentemente, de implementar y administrar las diferentes partes de la pila. Como resultado, las responsabilidades de seguridad también se distribuyen en la pila, y por lo tanto a través de las organizaciones involucradas.

Esto se conoce comúnmente como el modelo de responsabilidad compartida. Piense en ello como una matriz de responsabilidad que depende del proveedor de servicios en la nube en particular y la característica / producto, el modelo de servicio y el modelo de implementación.

En un nivel alto, la responsabilidad de seguridad se correlaciona con el grado de control que tiene un actor dado sobre la arquitectura en pila:

• Software como servicio: El proveedor de servicios en la nube es responsable de casi toda la seguridad, ya que el usuario de servicios en la nube solo puede acceder y administrar su uso de la aplicación, y no puede alterar el funcionamiento de la aplicación. Por ejemplo, un proveedor de SaaS es responsable de la seguridad del perímetro, el registro/monitoreo/auditoría y la seguridad de la aplicación, mientras que el consumidor solo puede administrar la autorización y los derechos.

• Plataforma como servicio: El proveedor de servicios en la nube es responsable de la seguridad de la plataforma, mientras que el consumidor es responsable de todo lo que implementa en la plataforma, incluida la forma en que conguran las características de seguridad ofrecidas. Las responsabilidades se dividen de manera más pareja. Por ejemplo, cuando se utiliza una base de datos como servicio, el proveedor gestiona la seguridad, los parches y la conguración central, mientras que el usuario de servicios en la nube es responsable de todo lo demás, incluidas las funciones de seguridad de la base de datos, las cuentas de administración o incluso los métodos de autenticación.

• Infraestructura como servicio: Al igual que PaaS, el proveedor es responsable de la seguridad de base, mientras que el usuario de servicios en la nube es responsable de todo lo que construye en la infraestructura. A diferencia de PaaS, esto otorga mucha más responsabilidad

Responsabilidad en Seguridad

Mayormente el Consumidor

Mayormente el Proveedor

al cliente. Por ejemplo, es probable que el proveedor de IaaS controle su perímetro en busca de ataques, pero el consumidor es totalmente responsable de cómo denen e implementan su seguridad de red virtual, según las herramientas disponibles en el servicio.

Infraestructura

como servicio

Estas funciones se complican aún más cuando se utilizan cloud brokers u otros intermediarios y socios.

La consideración de seguridad más importante es saber exactamente quién es responsable de qué, en cualquier proyecto en la nube. Es menos importante si un proveedor de servicios en la nube en particular

ofrece un control de seguridad especíco, siempre y cuando sepa exactamente qué ofrecen y cómo funciona. Puede llenar los vacíos con sus propios controles o elegir un proveedor diferente si no puede cerrar la brecha de controles. Su capacidad para hacer esto es muy alta para IaaS, y menos para SaaS.

Esta es la esencia de la relación de seguridad entre un proveedor de servicios en la nube y el consumidor. ¿Qué hace el proveedor? ¿Qué necesita hacer el consumidor? ¿El proveedor de servicios en la nube permite al consumidor hacer lo que necesita? ¿Qué está garantizado en los contratos y en el acuerdo de nivel de servicio, y qué implica la documentación y los detalles de la tecnología?

Plataforma

como servicio

Software

como servicio

Este modelo de responsabilidad compartida se correlaciona directamente con dos recomendaciones:

• Los proveedores de servicios en la nube deben documentar claramente sus controles internos de seguridad y las características de seguridad del cliente para que el usuario de servicios en la nube pueda tomar una decisión informada. Los proveedores también deben diseñar e implementar adecuadamente esos controles.

• Los usuarios de servicios en la nube deben, para cualquier proyecto dado en la nube, crear una matriz de responsabilidades para documentar quién está implementando qué controles y cómo. Esto también debería alinearse con los estándares de cumplimiento necesarios.

Cloud Security Alliance proporciona dos herramientas para ayudar a cumplir estos requisitos:

• El Cuestionario de Iniciativa de Evaluaciones de Consenso (CAIQ). Una plantilla estándar para que los proveedores de servicios en la nube documenten sus controles de seguridad y cumplimiento.

• La Matriz de Controles de la Nube (CCM), que enumera los controles de seguridad en la nube y los mapea en múltiples estándares de seguridad y cumplimiento. El CCM también se puede usar para documentar las responsabilidades de seguridad.

Ambos documentos necesitarán ajustes para requisitos especícos de organización y proyecto, pero proporcionan una plantilla de inicio completa y pueden ser especialmente útiles para garantizar que se cumplan los requisitos de cumplimiento.

1.2.2 Modelos de seguridad en la nube

Los modelos de seguridad en la nube son herramientas para ayudar a orientar las decisiones de seguridad. El término “modelo” se puede usar de forma un poco nebulosa, por lo que para nuestros propósitos se descompone en los siguientes tipos:

• Los modelos o frameworks conceptuales incluyen visualizaciones y descripciones utilizadas para explicar conceptos y principios de seguridad en la nube, como el modelo lógico de CSA en este documento.

• Modelos de control o marcos de trabajo que categorizan y detallan controles de seguridad en la nube especícos o categorías de controles, como el CCM de CSA.

• Las arquitecturas de referencia son plantillas para implementar la seguridad en la nube, generalmente generalizadas (por ejemplo, una arquitectura de referencia de seguridad IaaS). Pueden ser muy abstractos, bordeando lo conceptual, o bastante detallados, bajando hasta controles y funciones especícos.

• Los patrones de diseño son soluciones reutilizables para problemas particulares. En seguridad, un ejemplo es la administración de registros IaaS. Al igual que con las arquitecturas de referencia, pueden ser más o menos abstractas o especícas, incluso bajando hasta patrones de implementación comunes en plataformas de nube particulares.

Las líneas entre estos modelos a menudo se difuminan y se superponen, según los objetivos del desarrollador del modelo. Incluso agruparlos todos juntos bajo el encabezado “modelo” es probablemente inexacto, pero dado que vemos los términos usados de manera intercambiable en diferentes fuentes, tiene sentido agruparlos.

CSA ha revisado y recomienda los siguientes modelos:

• CSA arquitectura empresarial

• CSA matriz de controles en la nube

• El borrador NIST la arquitectura de referencia de seguridad de Cloud Computing (NIST

Special Publicación 500-299), que incluye modelos conceptuales, arquitecturas de referencia

y un marco de control.

• ISO/IEC FDIS 27017 Tecnología de la información - Técnicas de seguridad - Código de

práctica para controles de seguridad de la información basado en ISO/IEC 27002 para servicios en la nube.

Servicios de soporte de operaciones comerciales

(BOSS)

Operación y soporte de technología de la información

(ITOS)

Servicios de

Presentación

Servicios de

Aplicación

Seguridad y Gestión de Riesgo

Servicios de

Información

Servicios de

Infraestructura

(SABSA)

A lo largo de esta Guía, también nos referimos a otros modelos especícos de dominio.

(Jericho)(TOGAF)

1.2.2.1 Un modelo simple de proceso de seguridad en la nube

Identiﬁcación de

Requerimientos

Seleccionar

proveedores y

modelos de

implementación

Evaluar los

controles

de seguridad

Diseñar e

implementar

controles

Deﬁnir la

Arquitectura

Identiﬁcar brechas

de Control

Gestionar los

cambios

Si bien los detalles de implementación, controles necesarios, procesos especícos y varias arquitecturas de referencia y modelos de diseño varían mucho según el proyecto especíco de la nube, existe un proceso relativamente sencillo y de alto nivel para administrar la seguridad en la nube:

• Identicar los requisitos de seguridad y cumplimiento necesarios y cualquier control existente.

• Seleccione su proveedor de servicios en la nube, servicio y modelos de implementación.

• Denir la arquitectura.

• Evaluar los controles de seguridad.

• Identicar las lagunas de control.

• Diseñar e implementar controles para llenar los vacíos.

• Gestionar cambios a lo largo del tiempo.

Dado que los diferentes proyectos en la nube, incluso en un solo proveedor, probablemente aprovecharán conjuntos de conguraciones y tecnologías completamente diferentes, cada proyecto debe evaluarse por sus propios méritos. Por ejemplo, los controles de seguridad para una aplicación implementada en IaaS puro en un proveedor pueden parecer muy diferentes de un proyecto similar que en su lugar usa más PaaS de ese mismo proveedor.

La clave es identicar los requisitos, diseñar la arquitectura e identicar los vacíos en función de las capacidades de la plataforma subyacente de la nube. Es por eso por lo que necesita conocer la arquitectura y el proveedor de servicios en la nube antes de comenzar a traducir los requisitos de seguridad en controles.

1.3 Áreas de enfoque crítico

Los otros 13 dominios que componen el resto de la Guía CSA resaltan áreas de preocupación para la computación en la nube y están ajustados para abordar los “puntos problemáticos” de seguridad estratégicos y tácticos dentro de un entorno de nube, y pueden aplicarse a cualquier combinación de servicio en la nube y modelo de implementación.

Los dominios se dividen en dos grandes categorías: Gobierno y Operaciones. Los dominios de gobierno son amplios y abordan cuestiones estratégicas y de políticas dentro de un entorno de computación en la nube, mientras que los dominios operacionales se centran en preocupaciones de seguridad e implementación más tácticas dentro de la arquitectura.

1.3.1 1.3.1 Gobernando la nube

Dominio

Título Descripción

Gobernanza y gestión de riesgos empresariales

Asuntos legales: Contratos y descubrimiento electrónico

Gestión de cumplimiento y auditoría

La capacidad de una organización para gobernar y medir el riesgo empresarial introducido por la computación en la nube. Elementos como la precedencia legal para infracciones de acuerdos, capacidad de las organizaciones de usuarios para evaluar adecuadamente el riesgo de un proveedor de servicios en la nube, responsabilidad de proteger datos condenciales cuando tanto el usuario como el proveedor pueden tener la culpa, y cómo las fronteras internacionales pueden afectar estos problemas.

Posibles problemas legales al usar la computación en la nube. Las cuestiones que se abordan en esta sección incluyen los requisitos de protección para la información y los sistemas informáticos, las leyes de divulgación de violaciones de seguridad, los requisitos reglamentarios, los requisitos de privacidad, las leyes internacionales, etc.

Mantener y probar el cumplimiento cuando se utiliza la computación en la nube. Aquí se tratan cuestiones relacionadas con la evaluación de cómo la computación en la nube afecta al cumplimiento de las políticas de seguridad interna, así como los diversos requisitos de cumplimiento (normativo, legislativo y de otro tipo). Este dominio incluye alguna dirección para probar el cumplimiento durante una auditoría.

Gobierno de la información

Gobernando los datos que se colocan en la nube. Aquí se discuten los elementos que rodean la identicación y el control de los datos en la nube, así como los controles de compensación que se pueden usar para lidiar con la pérdida de control físico cuando se mueven datos a la nube. Se mencionan otros elementos, como quién es responsable de la condencialidad de los datos, la integridad y la disponibilidad.

1.3.2. Operando la nube

Dominio

9 Respuesta a

Título Descripción

Plan de Gestión y Continuidad del Negocio

Seguridad de Infraestructura

Virtualización y contenedores

incidentes, noticación y remediación

Seguridad de aplicaciones

Asegurar el plan de gestión y las interfaces administrativas utilizadas al acceder a la nube, incluidas las consolas web y las API. Garantizar la continuidad del negocio para implementaciones en la nube.

Seguridad del núcleo de la infraestructura de la nube, incluidas las redes, la seguridad de la carga de trabajo y las consideraciones de la nube híbrida. Este dominio también incluye fundamentos de seguridad para nubes privadas.

Seguridad para hipervisores, contenedores y redes denidas por software.

Detección, respuesta, noticación y reparación adecuada de incidentes. Esto intenta abordar los elementos que deberían estar en su lugar, tanto a nivel de proveedor como de usuario, para permitir el manejo adecuado de incidentes y análisis forense. Este dominio lo ayudará a comprender las complejidades que trae la nube a su programa actual de manejo de incidentes.

Asegurar el software de la aplicación que se ejecuta o se está desarrollando en la nube. Esto incluye elementos tales como si es apropiado migrar o diseñar una aplicación para que se ejecute en la nube y, de ser así, qué tipo de plataforma en la nube es la más adecuada (SaaS, PaaS o IaaS).

Seguridad y cifrado de datos

Identidad, derecho y administración de acceso.

Seguridad como servicio

Tecnologías relacionadas

Implementando la seguridad y el cifrado de datos, y garantizando la administración escalable de claves.

Administrar identidades y aprovechar los servicios de directorio para proporcionar control de acceso. La atención se centra en los problemas que se encuentran al extender la identidad de una organización a la nube. Esta sección proporciona información sobre cómo evaluar la preparación de una organización para llevar a cabo una Gestión de acceso, idoneidad e identidad (IdEA) basada en la nube.

Proporcionar aseguramiento de seguridad facilitado por terceros, administración de incidentes, certicación de cumplimiento y supervisión de identidad y acceso.

Tecnologías establecidas y emergentes con una estrecha relación con la computación en la nube., incluidas el Big Data, el Internet de las cosas y la informática móvil.

1.4 Recomendaciones

• Comprender las diferencias entre la computación en la nube y la infraestructura tradicional o la virtualización, y cómo la abstracción y la automatización afectan la seguridad.

• Familiarizarse con el modelo NIST para computación en la nube y la arquitectura de referencia CSA.

• Usar herramientas tales como el Cuestionario de la Iniciativa de Evaluaciones de Consenso de CSA (CAIQ) para evaluar y comparar proveedores de servicios en la nube.

• Los proveedores de servicios en la nube deben documentar claramente sus características y controles de seguridad y publicarlos utilizando herramientas como CSA CAIQ.

• Usar herramientas como la Matriz de Controles de Nube de CSA para evaluar y documentar los requisitos y controles de cumplimiento y seguridad del proyecto en la nube, así como también quién es responsable de cada uno.

• Usar un modelo de proceso de seguridad en la nube para seleccionar proveedores, arquitecturas de diseño, identicar brechas de control e implementar controles de seguridad y cumplimiento.

1.5 Créditos

• Arquitectura de referencia y modelo lógico basado en el trabajo de Christofer Ho.

DOMINIO 2

Gobierno y Gestión del Riesgo Corporativo

2.0 Introducción

El gobierno o gobernanza y la gestión del riesgo son temas increíblemente amplios. Esta guía se focaliza en cómo cambian en la computación en la nube; esta guía no es ni debería ser considerada un manual o una exploración amplia de estos temas fuera de la nube.

Para profesionales de la seguridad, la Computación en la nube impacta en cuatro áreas del gobierno y la gestión del riesgo:

• El Gobierno incluye las políticas, los procesos y controles internos que incluyen cómo está funcionando una organización. Todo desde las estructuras y políticas hasta el liderazgo y otros mecanismos de gestión.

Para más Información sobre la gobernanza por favor ver

* ISO/IEC 38500:2015 - Information Technology - Governance of IT for the organization * ISACA - COBIT - A Business Framework for the Governance and Management of Enterprise IT * ISO/IEC 27014:2013 - Information Technology - Security techniques - Governance of

information security

• La Gestión del riesgo empresarial incluye gestionar el riesgo global para la organización, alineado con el gobierno de la organización y su tolerancia al riesgo. La gestión del riesgo empresarial incluye todas las áreas de riesgo, no únicamente las relacionadas con la tecnología.

• La Gestión del riesgo de la información cubre la gestión del riesgo de la información incluyendo la tecnología de la información. Las organizaciones encaran todo tipo de riesgos, desde los nancieros a los físicos, y la información solamente es uno de los múltiples activos que una organización necesita gestionar.

• La Seguridad de la Información es el conjunto de instrumentos y prácticas para la gestión del riesgo de la información. La seguridad de la información no es la razón de ser de la gestión de los riesgos de la información; políticas, contratos, seguros, y otros mecanismos que también tienen un rol (incluyendo la seguridad física para la información no digital).

Sin embargo, el rol principal, si es que no es el único rol, de la seguridad de la información es proveer de procesos y controles para proteger la información electrónica y los sistemas que se usan para acceder a ella. En una jerarquía simplicada, la seguridad de la información es una herramienta para la gestión del riesgo de la información, que es un instrumento para la gestión del riesgo empresarial, y que a su vez es una herramienta de gobernanza. Las cuatro están estrechamente relacionadas, pero requieren un enfoque, procesos e herramientas individuales.

Gobernanza

Gestión del Riesgo

Empresarial

Gestión del Riesgo

de la Información

Seguridad de la

Información

2.1: Jerarquía Simplicada del Riesgo y de la Gobernanza

Las cuestiones legales y el cumplimiento están cubiertas en los Dominios 3 y 4 respectivamente. La gestión del riesgo y la gobernanza de los datos están cubiertas en el Dominio 5. La seguridad de la información es esencialmente en el resto de esta guía.

2.1 Visión general

2.1.1 Gobierno

La computación en la nube afecta al gobierno, ya que introduce una tercera parte dentro del proceso (en el caso de una nube pública o nube privada hospedada) o posiblemente altera las estructuras internas de gobernanza en el caso de nube privada auto-hospedada. La primera cuestión a recordar en el gobierno de la Computación en la nube es que una organización nunca puede externalizar la responsabilidad del gobierno, incluso cuando se utilizan proveedores externos. Esto es siempre cierto, nube o no, pero es útil tenerlo presente cuando se navega por los conceptos de la Computación en la nube de modelos de responsabilidad compartida.

Los proveedores de servicio en la nube intentan aprovechar economías de escala para gestionar los costes y las capacidades. Esto signica crear servicios extremadamente estandarizados (incluyendo contratos y acuerdos de nivel de servicio) que son homogéneos para todos los clientes. Los modelos de gobierno necesariamente no pueden tratar de la misma forma a los proveedores de servicios en la nube que en la que tratan a los proveedores externos de servicio dedicados, los cuales típicamente personalizan sus ofertas, incluyendo los acuerdos legales, para cada cliente.

La computación en la nube cambia las responsabilidades y los mecanismos para la implementación

Contrato

y la gestión del gobierno. Las responsabilidades y mecanismos para la gobernanza se denen en el contrato, como en cualquier otra relación de negocio. Si el área afectada no está en el contrato, no hay mecanismos disponibles para hacer cumplir al proveedor, y es una brecha de gobernanza. Las brechas de gobernanza no necesariamente excluyen utilizar el servicio del proveedor, pero requieren que el cliente ajuste sus propios procesos para cerrar las brechas o aceptar los riesgos asociados.

2.1.1.1 Herramientas para el gobierno de la nube

Como con cualquier otra área, hay herramientas de gestión especícas para la gobernanza. Esta relación se focaliza más en herramientas orientadas a proveedores externos, pero estas mismas herramientas pueden a menudo utilizarse internamente para despliegues privados:

• Contratos: la herramienta principal es el contrato entre el proveedor de servicios en la nube y el cliente de la nube (esto es aplicable para las nubes públicas y privadas). El contrato es su única garantía de cualquier nivel de servicio o compromiso – asumiendo que no hay un incumplimiento de contrato, que mete todo en un escenario legal. Los contratos son las principales herramientas para extender la gobernanza entre los socios de negocio y proveedores.

Proveedor Cliente

Controles

internos

Los contratos denen las relaciones entre los proveedores y clientes y son la herramienta principal para que los clientes extiendan la gobernanza a sus proveedores.

• Evaluaciones de proveedores (proveedor de servicios en la nube): El cliente potencial de la nube realiza las evaluaciones utilizando la información disponible y los procesos y técnicas permitidas. Combinan investigaciones contractuales y manuales con análisis de terceros (las declaraciones legales a menudo utilizadas para comunicar los resultados de una evaluación o auditoría) e investigación técnica. Son muy similares a cualquier evaluación de proveedores y pueden incluir aspectos como viabilidad nanciera, historia, características de las ofertas, declaraciones de terceros, retroalimentación entre colegas, y otras. Más adelante en este Dominio y en el Dominio 4 se desarrollan más detalladamente las evaluaciones.

+ 141 hidden pages

CSA Guía de Seguridad User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual