CAPÍTULO 1

Este dominio proporciona el marco conceptual para el resto de la guía de Cloud Security Alliance. Describe y define la
computación en la nube, establece nuestra terminología básica y detalla los marcos lógicos y arquitectónicos generales
que se utilizan en el resto del documento.
Hay 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 negocios, solo por nombrar algunos. Es, en esencia, transformador y disruptivo. También
está creciendo muy, muy rápidamente y no muestra signos de desaceleración. Si bien los modelos de referencia que
incluimos en la primera versión de esta Guía son todavía relativamente precisos, ciertamente ya no están completos. E
incluso esta actualización posiblemente no pueda dar cuenta de todas las posibles evoluciones en los próximos años.
La computación en la nube ofrece enormes beneficios potenciales en agilidad, resistencia y economía. Las organizaciones
pueden moverse más rápido (ya que no tienen que comprar y aprovisionar hardware, y todo está definido por software),
reducir el tiempo de inactividad (gracias a la elasticidad inherente y otras características de la nube) y ahorrar dinero
(debido a la reducción de los gastos de capital y una mejor demanda y coincidencia de capacidad). También vemos
beneficios de seguridad, ya que los proveedores de la nube tienen importantes incentivos económicos para proteger a los
clientes.
Sin embargo, estos beneficios solo aparecen si comprende y adopta modelos nativos de la nube y ajusta 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 un activo existente y simplemente trasladarlo a un proveedor de nube sin ningún cambio a menudo reducirá
la agilidad, la resistencia e incluso la seguridad, al tiempo que aumenta los costos.
El objetivo de este dominio es sentar las bases en las que se basan el resto del documento y sus recomendaciones. La
intención es proporcionar un lenguaje común y una comprensión de la computación en la nube para los profesionales de la
seguridad, comenzar a resaltar las diferencias entre la computación en la nube y la tradicional, y ayudar a guiar a los
profesionales de la seguridad hacia la adopción de enfoques nativos de la nube que resulten en una mejor seguridad (y
esos otros beneficios). en lugar de crear más riesgos
Este dominio incluye 4 secciones:
• Definición de 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 cumplimiento y seguridad en la nube
Cloud Security Alliance no se propone crear una taxonomía o un modelo de referencia completamente nuevos. Nuestro
objetivo es destilar y armonizar los modelos existentes, sobre todo el trabajo en la Publicación especial NIST 800-145,
ISO / IEC 17788 e ISO / IEC 17789, y centrarnos en lo que es más relevante para los profesionales de la seguridad.
1.1.1 Definición de computación en la nube
La computación en la nube es un nuevo modelo operativo 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, la agilidad, la escalabilidad y la
disponibilidad, además de brindar oportunidades para la reducción de costos a través de una computación optimizada y
eficiente. El modelo de nube prevé un mundo en el que los componentes se pueden orquestar, aprovisionar, implementar y
retirar rápidamente, y escalar hacia arriba o hacia abajo para proporcionar un modelo de asignación y consumo similar a la
utilidad bajo demanda.

NIST define la computación en la nube como:

La computación en la nube es un modelo para permitir el acceso a la red, ubicuo, conveniente y bajo demanda a un grupo
compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y
servicios) que se pueden aprovisionar y liberar rápidamente con un mínimo esfuerzo de administración o interacción del
proveedor de servicios.
La definición de ISO / IEC es muy similar:
Paradigma para permitir el acceso de la red a un grupo elástico y escalable de recursos físicos o virtuales compartibles con
aprovisionamiento de autoservicio y administración a pedido.
Una forma (un poco) más sencilla de describir la nube es que toma un conjunto de recursos, como procesadores y
memoria, y los coloca en un grupo grande (en este caso, mediante la virtualización). Los consumidores piden lo que
necesitan del grupo, como 8 CPU y 16 GB de memoria, y la nube asigna esos recursos al cliente, que luego se conecta y
los usa a través de la red. Cuando el cliente haya terminado, puede devolver los recursos al grupo para que los use otra
persona.
Una nube puede constar de casi cualquier recurso informático, desde nuestros ejemplos de "computación" de procesadores
y memoria hasta redes, almacenamiento y recursos de nivel superior como bases de datos y aplicaciones. Por ejemplo,
suscribirse a una aplicación de gestión de relaciones con el cliente para 500 empleados en un servicio compartido por
cientos de otras organizaciones es tanto informática en la nube como lanzar 100 servidores remotos en una nube
informática.
Definición: Un usuario de la nube es la persona u organización que solicita y usa los recursos, y el proveedor de la nube es
la persona u organización que los entrega. A veces también usamos los términos cliente y consumidor para referirnos al
usuario de la nube, y servicio o simplemente nube para describir al proveedor. NIST 500-292 utiliza el término "actor de
la nube" y agrega roles para los agentes, operadores y auditores de la nube. ISO / IEC 17788 utiliza los términos cliente de
servicios 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. Extraemos los recursos de la infraestructura
física subyacente para crear nuestros grupos y usamos la orquestación (y la automatización) para coordinar la creación y
entrega de un conjunto de recursos de los grupos a los consumidores. Como verá, estas dos técnicas crean todas las
características esenciales que usamos para definir algo como una "nube".
Ésta es la diferencia entre la computación en la nube y la virtualización tradicional; La virtualización abstrae los recursos,
pero por lo general carece de la orquestación para agruparlos y entregarlos a los clientes a pedido, en lugar de depender de
procesos manuales.
Las nubes son multiusuario por naturaleza. Múltiples grupos de consumidores diferentes comparten el mismo conjunto de
recursos, pero están segregados y aislados entre sí. La segregación permite al proveedor de la nube dividir los recursos
entre los diferentes grupos, y el aislamiento garantiza que no puedan ver ni modificar los activos de los demás. La
tenencia múltiple no solo se aplica en diferentes organizaciones; también se utiliza para repartir recursos entre diferentes
unidades en una sola empresa u organización.
1.1.2 Modelo de definición
Cloud Security Alliance (CSA) utiliza el modelo NIST para la computación en la nube como su estándar para definir la
computación en la nube. La CSA también respalda 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 la Definición de trabajo de NIST de
Computación en la Nube (NIST 800-145) para brindar coherencia y consenso en torno a un lenguaje común para centrarse
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 organizaciones de
todo el mundo. Si bien el NIST es una organización del gobierno de EE. UU., La selección de este modelo de referencia
no debe interpretarse como una sugerencia de la exclusión de otros puntos de vista o geografías.
NIST define la computación en la nube al describir 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.

1.1.2.1 Características esenciales

Estas son las características que hacen de una nube una nube. Si algo tiene estas características, lo consideramos cloud
computing. Si carece de alguno de ellos, es probable que no sea una nube.
• La agrupación de recursos es la característica más fundamental, como se discutió anteriormente. El proveedor
extrae recursos y los recopila en un grupo, partes del cual se pueden asignar a diferentes consumidores
(generalmente según las políticas).
• Los consumidores suministran los recursos del grupo mediante el autoservicio bajo demanda. Administran sus
recursos ellos mismos, sin tener que hablar con un administrador humano.
• Amplio acceso a la red significa que todos los recursos están disponibles a través de una red, sin necesidad de
acceso físico directo; la red no es necesariamente parte del servicio.
• La elasticidad rápida permite a los consumidores expandir o contraer los recursos que utilizan del grupo
(aprovisionamiento y desaprovisionamiento), a menudo de forma completamente automática. Esto les permite
hacer coincidir más estrechamente el consumo de recursos con la demanda (por ejemplo, agregar servidores
virtuales a medida que aumenta la demanda y luego apagarlos cuando disminuye la demanda).
• El servicio medido mide lo provisto, para asegurar que los consumidores solo usen lo que se les asigna y, si es
necesario, cobrarles por ello. De aquí es de donde proviene el término computación de servicios públicos, ya que
los recursos informáticos ahora se pueden consumir como agua y electricidad, y 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 la tenencia múltiple, que es distinta de la agrupación de recursos.
1.1.2.2 Modelos de servicio
NIST define tres modelos de servicio que describen las diferentes categorías fundamentales de servicios en la nube:
• El software como servicio (SaaS) es una aplicación completa administrada y alojada por el proveedor. Los consumidores
acceden a él con un navegador web, una aplicación móvil o una aplicación cliente ligera.
• La plataforma como servicio (PaaS) resume y proporciona plataformas de desarrollo o aplicaciones, como bases de
datos, plataformas de aplicaciones (por ejemplo, un lugar para ejecutar Python, PHP u otro código), almacenamiento y
colaboración de archivos, o incluso procesamiento de aplicaciones patentadas (como aprendizaje automático,
procesamiento de big data o acceso directo de interfaces de programación de aplicaciones (API) a las funciones de una
aplicación SaaS completa). El diferenciador clave es que, con PaaS, no administra los servidores, redes u otra
infraestructura subyacente.
• Infraestructura como servicio (IaaS) ofrece acceso a un grupo de recursos de infraestructura informática fundamental,
como computación, red o almacenamiento.
A veces los llamamos niveles "SPI".
ISO / IEC utiliza una definición más compleja con un tipo de capacidades en la nube que se relaciona estrechamente con
los niveles de SPI (tipos de capacidad de aplicación, infraestructura y plataforma). Luego se expande a categorías de
servicios en la nube que son más granulares, como Compute as a Service, Data Storage as a Service, e incluso incluye
IaaS / PaaS / SaaS.
Estas categorías son algo permeables: algunos servicios en la nube abarcan estos niveles, otros no encajan perfectamente
en un solo modelo de servicio. Hablando en términos prácticos, no hay razón para intentar asignar todo en estas tres
categorías amplias, o incluso en las categorías más granulares en el modelo ISO / IEC. Esta 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 definición que se usa predominantemente en la investigación de CSA.
1.1.2.3 Modelos de implementación
Tanto NIST como ISO / IEC utilizan los mismos cuatro modelos de implementación en la nube. Así es como se
implementan y consumen las tecnologías, y se aplican a toda la gama de modelos de servicio:
• Nube pública. La infraestructura en la nube está disponible para el público en general o para un gran grupo industrial 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 dentro o fuera de las instalaciones.
• Community Cloud. La infraestructura de la nube es compartida por varias organizaciones y es compatible con una
comunidad específica que tiene preocupaciones compartidas (por ejemplo, misión, requisitos de seguridad, políticas o
consideraciones de cumplimiento). Puede ser administrado por las organizaciones o por un tercero y puede estar ubicado
dentro o fuera de las instalaciones.

Nube híbrida. La infraestructura de la nube es una composición de dos o más nubes (privadas, comunitarias o públicas)
que siguen siendo entidades únicas, pero están unidas por normas estandarizadas o
Guía de seguridad v4.0 © Copyright 2017, Cloud Security Alliance. Todos los derechos reservados 12 tecnología
patentada que permite la portabilidad de datos y aplicaciones (p. Ej., Explosión en la nube para equilibrar la carga entre
las nubes). Híbrido también se usa comúnmente para describir un centro de datos que no está en la nube conectado
directamente a un proveedor de la nube.
Los modelos de implementación se definen en función del usuario de la nube, es decir, quién usa la nube. Como muestra
el diagrama a continuación, la organización que posee y administra la nube variará incluso dentro de un solo modelo de
implementación.

1 La gestión incluye: gobernanza, operaciones, seguridad, cumplimiento, etc.

2 Infraestructura implica infraestructura física, como instalaciones, redes informáticas y equipos de almacenamiento.
3 La ubicación de la infraestructura es física en relación con el paraguas de gestión de una organización y habla de
propiedad versus control
4 Los consumidores confiables del servicio son aquellos que se consideran parte del paraguas legal / contractual / de
políticas de una organización, incluidos los empleados, contratistas y socios comerciales. Los consumidores que no son de
confianza son aquellos que pueden estar autorizados a consumir algunos / todos los servicios, pero no son extensiones
lógicas de la organización.
1.1.3 Modelos de referencia y arquitectura
En estos días existe una amplia gama de técnicas tecnológicas en constante evolución para la construcción de servicios en
la nube, haciendo que cualquier modelo arquitectónico o de referencia quede obsoleto desde el principio. El objetivo de
esta sección es proporcionar algunos fundamentos para ayudar a los profesionales de la seguridad a tomar decisiones
informadas, así como una línea de base para comprender modelos más complejos y emergentes. Para un modelo
arquitectónico de referencia en profundidad, nuevamente recomendamos ISO / IEC 17789 y NIST 500-292, que
complementan el modelo de definició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.
1.1.3.1 Infraestructura como servicio
Las instalaciones físicas y el hardware de infraestructura 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. Estos recursos se agrupan mediante abstracción y orquestación. La abstracción, a menudo
a través de la virtualización, libera los recursos de sus limitaciones físicas para permitir la agrupación. Luego, un conjunto
de herramientas centrales de conectividad y entrega (orquestación) une estos recursos abstractos, crea los grupos y
proporciona la automatización para entregarlos a los clientes.
Todo esto se facilita mediante interfaces de programación de aplicaciones. Las API suelen ser el método de comunicación
subyacente para los componentes dentro de una nube, algunos de los cuales (o un conjunto completamente diferente)
están expuestos al usuario de la nube para administrar sus recursos y configuraciones. La mayoría de las API en la nube
en estos días usan REST (Representational State Transfer), 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 API son accesibles de forma remota y están integradas 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 utilizan para administrar y
configurar los recursos de la nube, como el lanzamiento de máquinas virtuales (instancias) o la configuración de redes
virtuales. Desde una perspectiva de seguridad, es tanto la mayor diferencia con la protección de la infraestructura física
(ya que no puede confiar en el acceso físico como control) como la principal prioridad al diseñar un programa de
seguridad en la nube. Si un atacante ingresa a su plano de administración, es posible que tenga acceso remoto completo a
toda su implementación en la nube.
Por lo tanto, IaaS consta de una instalación, hardware, una capa de abstracción, una capa de orquestación (conectividad
central y entrega) para unir los recursos abstraídos y API para administrar de forma remota los recursos y entregarlos a los
consumidores.
A continuación, se muestra un ejemplo arquitectónico simplificado de una plataforma de computación IaaS:

Este es un diagrama muy simple que muestra los controladores de computación y almacenamiento para la orquestación,
los hipervisores para la abstracción y la relación entre las agrupaciones de computación y almacenamiento. Omite muchos
componentes, como el administrador de red.
Cada uno de una serie de servidores físicos ejecuta 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 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 del grupo de almacenamiento y lo conecta al servidor host apropiado y la instancia a través de la
red (una red dedicada para el tráfico de almacenamiento). La red, incluidas las interfaces y direcciones de red virtual,
también se asigna y se conecta a la red virtual necesaria.
Luego, el controlador envía una copia de la imagen del servidor a la máquina virtual, la inicia y la configura; esto crea una
instancia que se ejecuta en una máquina virtual (VM), con almacenamiento y redes virtuales configurados correctamente.
Una vez que se completa todo este proceso, el controlador de la nube gestiona los metadatos y la información de
conectividad y los pone a disposición del consumidor, que ahora puede conectarse a la instancia e iniciar sesión.
1.1.3.2 Plataforma como servicio
De todos los modelos de servicio, PaaS es el más difícil de caracterizar definitivamente debido tanto a la amplia gama de
ofertas de PaaS como a las muchas formas de construir servicios 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 compatibles con la pila.
Una opción, que se ve con frecuencia en el mundo real e ilustrada en nuestro modelo, es construir una plataforma sobre
IaaS. Una capa de integración y middleware se crea en IaaS, luego se agrupa, organiza y expone a los clientes que utilizan
API como PaaS. Por ejemplo, una base de datos como servicio podría construirse mediante la implementación de un
software de sistema de administración de base de datos modificado en instancias que se ejecutan en IaaS. El cliente
administra 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, nuevamente, a través de API.
En PaaS, el usuario de 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. Ese es un lugar donde los desarrolladores pueden
cargar y ejecutar el código de la aplicación sin administrar los recursos subyacentes. Existen servicios para ejecutar casi
cualquier tipo de aplicación en cualquier idioma en PaaS, lo que libera a los desarrolladores de configurar y construir
servidores, mantenerlos actualizados o preocuparse por complejidades como la agrupación en clústeres y el equilibrio de
carga.
Este diagrama de arquitectura simplificado muestra una plataforma de aplicación (PaaS) que se ejecuta sobre nuestra
arquitectura IaaS:
No es necesario que PaaS se construya sobre IaaS; no hay ninguna razón por la que no pueda ser una arquitectura
independiente diseñada a medida. La característica definitoria es que los consumidores acceden y administran la
plataforma, no la infraestructura subyacente (incluida la infraestructura en la nube).
1.1.3.3 Software como servicio
Los servicios SaaS son aplicaciones completas para múltiples inquilinos, con todas las complejidades arquitectónicas de
cualquier gran plataforma de software. Muchos proveedores de SaaS se basan en IaaS y PaaS debido a la mayor agilidad,
resistencia y beneficios económicos (potenciales).
La mayoría de las aplicaciones de nube modernas (SaaS o de otro tipo) utilizan una combinación de IaaS y PaaS, a veces
en diferentes proveedores de nube. Muchos también tienden a ofrecer API públicas para algunas (o todas) las funciones. A
menudo, los necesitan para admitir 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, 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 a API públicas.
El diagrama de arquitectura simplificado que se muestra a continuación se tomó de una plataforma SaaS real, pero se
generalizó para eliminar las referencias a los productos específicos en uso:
1.1.4 Modelo lógico
A un alto nivel, tanto la computación en la nube como la tradicional se adhieren a un modelo lógico que ayuda a
identificar diferentes capas en función de la funcionalidad. Esto es útil para ilustrar las diferencias entre los diferentes
modelos informáticos en sí mismos:
• Infraestructura: los componentes centrales de un sistema informático: computación, red y almacenamiento. La base
sobre la que se construye todo lo demás. Las partes móviles.
• Metaestructura: 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 gestión y la configuración.
• Infraestructura: Los datos y la información. Contenido en una base de datos, almacenamiento de archivos, etc.
• Applistructure: las aplicaciones implementadas en la nube y los servicios de aplicaciones subyacentes que se usan para
construirlas. Por ejemplo, la plataforma como servicio incluye colas de mensajes, análisis de inteligencia artificial o
servicios de notificación.
Los diferentes enfoques de seguridad se asignan a las diferentes capas lógicas. La seguridad de la aplicación se asigna a la
estructura de la aplicación, la seguridad de los datos a la infraestructura y la seguridad de la infraestructura a la
infraestructura.
La diferencia clave entre la nube y la computación tradicional es la metaestructura. La metaestructura de la nube incluye
los componentes del plano de gestión, que están habilitados para la red y son accesibles de forma remota. Otra diferencia
clave es que, en la nube, tiende a duplicarse 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 la nube. En la nube
privada, la misma organización puede necesitar administrar ambos; en la nube pública, el proveedor administra la
infraestructura física mientras que el consumidor administra su parte de la infraestructura virtual.
Como veremos más adelante, esto tiene profundas implicaciones sobre quién es responsable de la seguridad y quién la
gestiona.
Estas capas tienden a correlacionarse con diferentes equipos, disciplinas y tecnologías que se encuentran comúnmente en
las organizaciones de TI. Si bien las diferencias de administración de seguridad más obvias e inmediatas se encuentran en
la metaestructura, la nube difiere ampliamente de la computación tradicional dentro de cada capa. La escala de las
diferencias dependerá no solo de la plataforma en la nube, sino de cómo exactamente el usuario de la nube utiliza la
plataforma.
Por ejemplo, una aplicación nativa de la nube que hace un uso intensivo de los productos PaaS de un proveedor de nube
experimentará más diferencias en la estructura de la aplicación que la migración de una aplicación existente, con cambios
mínimos, a la infraestructura como servicio.
1.2 Alcance, responsabilidades y modelos de seguridad en la nube
1.2.1 Alcance y responsabilidades de cumplimiento y seguridad en la nube
Puede sonar simplista, pero la seguridad y el cumplimiento en la nube incluyen todo lo que un equipo de seguridad es
responsable hoy en día, solo en la nube. Todos los dominios de seguridad tradicionales permanecen, pero la naturaleza de
los riesgos, roles y responsabilidades, y la implementación de controles cambian, a menudo de manera dramática.
Aunque el alcance general de la seguridad y el cumplimiento no cambia, las piezas de las que cualquier actor de la nube es
responsable ciertamente sí lo hacen. Piénselo de esta manera: la computación en la nube es un modelo de tecnología
compartida donde diferentes organizaciones son frecuentemente responsables de implementar y administrar diferentes
partes de la pila. Como resultado, las responsabilidades de seguridad también se distribuyen entre la pila y, por lo tanto,
entre 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 nube 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 asigna al grado de control que cualquier actor determinado tiene sobre
la pila de arquitectura:
• Software como servicio: el proveedor de la nube es responsable de casi toda la seguridad, ya que el usuario de 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 las aplicaciones, mientras que el consumidor solo puede administrar la autorización y los derechos.
• Plataforma como servicio: el proveedor de la nube es responsable de la seguridad de la plataforma, mientras que el
consumidor es responsable de todo lo que implementan en la plataforma, incluida la forma en que configuran las
características de seguridad ofrecidas. Por lo tanto, las responsabilidades se dividen de manera más equitativa. Por
ejemplo, cuando se usa una base de datos como servicio, el proveedor administra la seguridad fundamental, los parches y
la configuración del núcleo, mientras que el usuario de la nube es responsable de todo lo demás, incluidas las
características de seguridad de la base de datos que debe usar, la administración de cuentas o incluso los métodos de
autenticación. .
• Infraestructura como servicio: al igual que PaaS, el proveedor es responsable de la seguridad fundamental, mientras que
el usuario de la nube es responsable de todo lo que construyen en la infraestructura. A diferencia de PaaS, esto coloca
mucha más responsabilidad en el 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 definen e implementan la seguridad de su red
virtual, según las herramientas disponibles en el servicio.

Estos roles se complican aún más cuando se utilizan corredores en la nube 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 algún proveedor de la nube en particular ofrece un control de seguridad específico,
siempre y cuando sepa con precisión lo que ofrecen y cómo funciona. Puede llenar las lagunas 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 nube y un consumidor. ¿Qué hace el proveedor? ¿Qué
debe hacer el consumidor? ¿El proveedor de la nube permite al consumidor hacer lo que necesita? ¿Qué se garantiza en el
contrato y los acuerdos de nivel de servicio, y qué implica la documentación y los detalles de la tecnología?
Este modelo de responsabilidad compartida se correlaciona directamente con dos recomendaciones:
• Los proveedores de la nube deben documentar claramente sus controles de seguridad internos y las funciones de
seguridad del cliente para que el usuario de la nube pueda tomar una decisión informada. Los proveedores
también deben diseñar e implementar adecuadamente esos controles.
• Los usuarios de la nube deben, para cualquier proyecto de nube dado, construir una matriz de responsabilidades
para documentar quién está implementando qué controles y cómo. Esto también debe alinearse con los estándares
de cumplimiento necesarios.
Cloud Security Alliance proporciona dos herramientas para ayudar a cumplir estos requisitos:
• El Cuestionario de la Iniciativa de Evaluaciones de Consenso (CAIQ). Una plantilla estándar para que los
proveedores de la nube documenten sus controles de seguridad y cumplimiento.
• Cloud Controls Matrix (CCM), que enumera los controles de seguridad de la nube y los asigna a múltiples
estándares de seguridad y cumplimiento. El CCM también se puede utilizar para documentar las
responsabilidades de seguridad.
Ambos documentos deberán ajustarse a los requisitos específicos de la organización y del 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 que ayudan a guiar las decisiones de seguridad. El término
"modelo" se puede usar de forma un poco nebulosa, por lo que para nuestros propósitos desglosamos los siguientes tipos:
Los modelos o marcos conceptuales incluyen visualizaciones y descripciones que se utilizan para explicar los conceptos y
principios de seguridad en la nube, como el modelo lógico CSA en este documento.
• Los modelos o marcos de controles categorizan y detallan controles de seguridad específicos en la nube o categorías de
controles, como CSA CCM.
• 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, rayanos en lo conceptual, o
bastante detallados, hasta controles y funciones específicos.
• Los patrones de diseño son soluciones reutilizables para problemas particulares. En seguridad, un ejemplo es la gestión
de registros de IaaS. Al igual que con las arquitecturas de referencia, pueden ser más o menos abstractas o específicas,
incluso 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 bajo el título “modelo” probablemente sea inexacto, pero como vemos que los términos se usan
de manera tan intercambiable en diferentes fuentes, tiene sentido agruparlos.
• La CSA ha revisado y recomendado los siguientes modelos:
• La arquitectura empresarial CSA
• Matriz de controles en la nube de CSA
• El borrador de la Arquitectura de Referencia de Seguridad de Computación en la Nube del NIST (NIST Special
Publicación 500-299), que incluye modelos conceptuales, arquitecturas de referencia y un marco de controles.
• ISO / IEC FDIS 27017 Tecnología de la información - Técnicas de seguridad - Código de prácticas para controles de
seguridad de la información basado en ISO / IEC 27002 para servicios en la nube.
1.2.2.1 Un modelo de proceso de seguridad en la nube simple
Si bien los detalles de implementación, los controles necesarios, los procesos específicos y las diversas arquitecturas de
referencia y modelos de diseño varían mucho según el proyecto de nube específico, existe un proceso de alto nivel
relativamente sencillo para administrar la seguridad de la nube:
• Identificar los requisitos de seguridad y cumplimiento necesarios, y cualquier control existente.
• Seleccione su proveedor de nube, servicios y modelos de implementación.
• Definir la arquitectura.
• Evaluar los controles de seguridad.
• Identificar 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
configuraciones 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 verse muy
diferentes a los de un proyecto similar que, en cambio, usa más PaaS de ese mismo proveedor.
La clave es identificar los requisitos, diseñar la arquitectura y luego identificar las brechas en función de las capacidades
de la plataforma en la nube subyacente. Es por eso que necesita conocer el proveedor y la arquitectura de 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 de CSA destacan áreas de preocupación para la computación en
la nube y están sintonizados para abordar los "puntos débiles" de seguridad estratégica y táctica dentro de un entorno de
nube, y se pueden aplicar a cualquier combinación de servicio en la nube y modelo de implementación.
Los dominios se dividen en dos categorías amplias: gobernanza y operaciones. Los dominios de gobernanza son amplios y
abordan cuestiones estratégicas y políticas dentro de un entorno de computación en la nube, mientras que los dominios
operativos se centran en preocupaciones de seguridad más tácticas y en la implementación dentro de la arquitectura.
1.3.1 Gobernar en la nube

DOMA
TITLE DESCRIPTION
IN
La capacidad de una organización para gobernar y medir el riesgo empresarial
introducido por la computación en la nube. Elementos como precedencia legal por
Gobernanza y
incumplimiento de acuerdos, capacidad de las organizaciones de usuarios para evaluar
2 gestión de riesgos
adecuadamente el riesgo de un proveedor de nube, responsabilidad de proteger datos
empresariales
confidenciales cuando tanto el usuario como el proveedor pueden tener la culpa y
cómo las fronteras internacionales pueden afectar estos problemas.
Cuestiones Posibles problemas legales al utilizar la computación en la nube. Los temas tratados en
legales: contratos esta sección incluyen los requisitos de protección para la información y los sistemas
3
y descubrimiento informáticos, las leyes de divulgación de violaciones de seguridad, los requisitos
electrónico reglamentarios, los requisitos de privacidad, las leyes internacionales, etc.
Mantener y demostrar el cumplimiento al utilizar la computación en la nube. Aquí se
analizan los problemas relacionados con la evaluación de cómo la computación en la
Gestión de
nube afecta el cumplimiento de las políticas de seguridad internas, así como los
4 cumplimiento y
diversos requisitos de cumplimiento (reglamentarios, legislativos y de otro tipo). Este
auditoría
dominio incluye algunas instrucciones sobre cómo demostrar el cumplimiento durante
una auditoría.
Datos de gobierno que se colocan en la nube. Aquí se analizan los elementos
relacionados con la identificación y el control de los datos en la nube, así como los
Gobernanza de la
5 controles de compensación que se pueden utilizar para hacer frente a la pérdida de
información
control físico al mover datos a la nube. Se mencionan otros elementos, como quién es
responsable de la confidencialidad, integridad y disponibilidad de los datos.

1.3.2 Operando en la Nube

DOMA
TITLE DESCRIPTION
IN
Plano de gestión y Asegurar el plano de gestión y las interfaces administrativas que se utilizan al acceder
6 continuidad a la nube, incluidas las consolas web y las API. Garantizar la continuidad empresarial
empresarial para las implementaciones en la nube.
Seguridad de la infraestructura de la nube central, incluidas las redes, la seguridad de la
Seguridad de la
7 carga de trabajo y las consideraciones de la nube híbrida. Este dominio también
infraestructura
incluye los fundamentos de seguridad para nubes privadas.
Virtualización y
8 Seguridad para hipervisores, contenedores y redes definidas por software.
contenedores
Detección, respuesta, notificación y reparación adecuadas y adecuadas de incidentes.
Respuesta a
Esto intenta abordar los elementos que deberían estar en su lugar tanto a nivel de
incidentes,
9 proveedor como de usuario para permitir el manejo y análisis forense adecuados de
notificación y
incidentes. Este dominio lo ayudará a comprender las complejidades que la nube
reparación
aporta a su programa actual de manejo de incidentes.
10 Seguridad de la Protección del software de aplicación que se ejecuta o se desarrolla en la nube. Esto
aplicación incluye elementos 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 Implementar el cifrado y la seguridad de los datos y garantizar una gestión de claves
11
cifrado de datos escalable.
Administrar identidades y aprovechar los servicios de directorio para proporcionar
Gestión de control de acceso. La atención se centra en los problemas que surgen al extender la
12 identidad, identidad de una organización a la nube. Esta sección proporciona información sobre la
derechos y acceso evaluación de la preparación de una organización para llevar a cabo una gestión de
identidad, derechos y acceso (IdEA) basada en la nube.
Seguridad como Proporcionar garantía de seguridad facilitada por terceros, gestión de incidentes,
13
servicio certificación de cumplimiento y supervisión de identidad y acceso.
Tecnologías Tecnologías establecidas y emergentes con una estrecha relación con la computación
14
relacionadas en la nube, incluidos Big Data, Internet de las cosas y computación móvil.

1.4 Recomendaciones
• Comprender las diferencias entre la computación en la nube y la infraestructura o virtualización tradicional, y cómo la
abstracción y la automatización afectan la seguridad.
• Familiarícese con el modelo NIST para computación en la nube y la arquitectura de referencia CSA.
• Utilice herramientas como el Cuestionario de la Iniciativa de Evaluaciones de Consenso de CSA (CAIQ) para evaluar y
comparar proveedores de nube.
• Los proveedores de la nube deben documentar claramente sus controles y funciones de seguridad y publicarlos
utilizando herramientas como CSA CAIQ.
• Utilice herramientas como CSA Cloud Controls Matrix para evaluar y documentar los requisitos y controles de
seguridad y cumplimiento de proyectos en la nube, así como quién es responsable de cada uno.
• Utilice un modelo de proceso de seguridad en la nube para seleccionar proveedores, diseñar arquitecturas, identificar
brechas de control e implementar controles de seguridad y cumplimiento.
CAPÍTULO 6 - MANAGEMENT PLANE AND BUSINESS CONTINUITY

6.0 Introducción
El plano de gestión es la diferencia de seguridad más significativa entre la infraestructura tradicional y la computación en
la nube. Esta no es toda la metaestructura (definida en el Dominio 1), pero es la interfaz para conectarse con la
metaestructura y configurar gran parte de la nube.
Siempre tenemos un plano de gestión, las herramientas y las interfaces que utilizamos para gestionar nuestra
infraestructura, plataformas y aplicaciones, pero la nube abstrae y centraliza la gestión administrativa de los recursos. En
lugar de controlar la configuración de un centro de datos con cajas y cables, ahora se controla con llamadas API y
consolas web.
Por lo tanto, obtener acceso al plano de administración es como obtener acceso sin restricciones a su centro de datos, a
menos que establezca los controles de seguridad adecuados para limitar quién puede acceder al plano de administración y
qué pueden hacer dentro de él.
Para pensarlo en términos de seguridad, el plano de administración consolida muchas cosas que anteriormente
administramos a través de sistemas y herramientas separados, y luego las hace accesibles a través de Internet con un solo
conjunto de credenciales de autenticación. Esto no es una pérdida neta para la seguridad, también hay ganancias, pero
definitivamente es diferente e impacta en la forma en que necesitamos evaluar y administrar la seguridad.
La centralización también trae beneficios de seguridad. No hay recursos ocultos, siempre sabes dónde está todo lo que
tienes en todo momento y cómo está configurado. Esta es una propiedad emergente tanto del acceso amplio a la red como
del servicio medido. El controlador de la nube siempre necesita saber qué recursos hay en el grupo, fuera del grupo y
dónde están asignados.
Esto no significa que todos los activos que coloca en la nube se administran por igual. El controlador de la nube no puede
mirar a los servidores en ejecución o abrir archivos bloqueados, ni comprender las implicaciones de sus datos e
información específicos.
Al final, esta es una extensión del modelo de responsabilidad compartida discutido en el Dominio 1 y a lo largo de esta
Guía. El plano de administración de la nube es responsable de administrar los activos del grupo de recursos, mientras que
el usuario de la nube es responsable de cómo configuran esos activos y de los activos que implementan en la nube.
• El proveedor de la nube es responsable de garantizar que el plano de administración sea seguro y que las funciones de
seguridad necesarias estén expuestas al usuario de la nube, como derechos granulares para controlar lo que alguien puede
hacer incluso si tiene acceso al plano de administración.
• El usuario de la nube es responsable de configurar correctamente su uso del plano de gestión, así como de proteger y
gestionar sus credenciales.
6.0.1 Continuidad comercial y recuperación ante desastres en la nube
La continuidad del negocio y la recuperación ante desastres (BC / DR) es tan importante en la computación en la nube
como para cualquier otra tecnología. Aparte de las diferencias que resultan de la posible participación de un proveedor
externo (algo con lo que a menudo tratamos en BC / DR), existen consideraciones adicionales debido a las diferencias
inherentes al usar recursos compartidos
Los tres aspectos principales de BC / DR en la nube son:
• Garantizar la continuidad y la recuperación dentro de un proveedor de nube determinado. Estas son las
herramientas y técnicas para diseñar mejor su implementación en la nube para mantener todo funcionando si lo
que implementa se rompe o una parte del proveedor de la nube se rompe.
• Preparación y gestión de interrupciones del proveedor de la nube. Esto se extiende desde los problemas más
restringidos que puede diseñar dentro de un proveedor hasta las interrupciones más amplias que acaban con todo o
parte del proveedor de una manera que excede las capacidades de los controles de DR inherentes.
• Considerar opciones de portabilidad, en caso de que necesite migrar proveedores o plataformas. Esto podría
deberse a cualquier cosa, desde el deseo de un conjunto de funciones diferente hasta la pérdida total del proveedor
si, por ejemplo, cierra el negocio o tiene una disputa legal.
6.0.1.1 Arquitecto para fallas
Las plataformas en la nube pueden ser increíblemente resistentes, pero los activos de una sola nube suelen ser menos
resistentes que en el caso de la infraestructura tradicional. Esto se debe a la fragilidad inherentemente mayor de los
recursos virtualizados que se ejecutan en entornos muy complejos.
Esto se aplica principalmente a la computación, las redes y el almacenamiento, ya que permiten un acceso más cercano al
crudo, y los proveedores de la nube pueden aprovechar técnicas de resiliencia adicionales para sus plataformas y
aplicaciones que se ejecutan sobre IaaS.
Sin embargo, esto significa que los proveedores de la nube tienden a ofrecer opciones para mejorar la resiliencia, a
menudo más allá de lo que es alcanzable (por costos equivalentes) en la infraestructura tradicional. Por ejemplo, al
habilitar múltiples "zonas", donde puede implementar máquinas virtuales dentro de un grupo escalado automáticamente
que abarca centros de datos físicamente distintos para alta disponibilidad. Su aplicación se puede equilibrar entre zonas de
modo que si una zona completa deja de funcionar, su aplicación aún permanece activa. Esto es bastante difícil de
implementar en un centro de datos tradicional, donde normalmente no es rentable construir varias zonas físicas aisladas en
las que se puede implementar una aplicación de carga equilibrada entre zonas con conmutación por error automática.
Pero esta resistencia adicional solo se puede lograr si diseña para aprovechar estas capacidades. Es probable que la
implementación de su aplicación en una sola zona, o incluso en una sola máquina virtual en una sola zona, sea menos
resistente que la implementación en un solo servidor físico bien mantenido.
Esta es la razón por la que la migración total de "elevación y cambio" de las aplicaciones existentes sin cambios en la
arquitectura puede reducir la resiliencia. Las aplicaciones existentes rara vez se diseñan e implementan para que funcionen
con estas opciones de resiliencia; sin embargo, la virtualización directa y la migración sin cambios pueden aumentar las
probabilidades de fallas individuales.
La capacidad de gestión es mayor con IaaS y mucho menor con SaaS, al igual que la seguridad. Para SaaS, usted confía en
que el proveedor de la nube mantenga activo todo el servicio de la aplicación. Con IaaS, puede diseñar su aplicación para
tener en cuenta las fallas, poniendo más responsabilidad en sus manos. PaaS, como de costumbre, está en el medio:
algunas PaaS pueden tener opciones de resiliencia que puede configurar, mientras que otras plataformas están
completamente en manos del proveedor.
En general, un enfoque basado en el riesgo es clave:
• No todos los activos necesitan la misma continuidad.
• No se vuelva loco al planificar las interrupciones totales del proveedor solo por la percepción pérdida de control. Mire el
desempeño histórico.
• Esforzarse por diseñar para RTO y RPO equivalentes a los de la infraestructura tradicional.
6.1 Resumen
6.1.1 Seguridad del plano de gestión
El plano de gestión se refiere a las interfaces para gestionar sus activos en la nube. Si implementa máquinas virtuales en
una red virtual, el plano de administración es cómo lanza esas máquinas y configura esa red. Para SaaS, el plano de
administración suele ser la pestaña "admin" de la interfaz de usuario y donde se configuran cosas como usuarios,
configuraciones para la organización, etc.
El plano de gestión controla y configura la metaestructura (definida en el Dominio 1), y también es parte de la
metaestructura misma. Como recordatorio, la computación en la nube es el acto de tomar activos físicos (como redes y
procesadores) y usarlos para crear grupos de recursos. La metaestructura es el pegamento y las agallas para crear,
aprovisionar y desaprovisionar las piscinas. El plano de administración incluye las interfaces para construir y administrar
la nube en sí, pero también las interfaces para que los usuarios de la nube administren sus propios recursos asignados de la
nube.
El plano de administración es una herramienta clave para habilitar y hacer cumplir la separación y el aislamiento en la
tenencia múltiple. Limitar quién puede hacer qué con las API es un medio importante para segregar clientes o diferentes
usuarios dentro de un solo inquilino. Los recursos están en el grupo, fuera del grupo y donde se asignan.
6.1.1.1 Acceso al plano de gestión
Las API y las consolas web son la forma en que se entrega el plano de gestión. Las interfaces de programación de
aplicaciones permiten la gestión programática de la nube. Son el pegamento que mantiene unidos los componentes de la
nube y permite su orquestación. Dado que no todo el mundo quiere escribir programas para administrar su nube, las
consolas web proporcionan interfaces visuales. En muchos casos, las consolas web simplemente usan las mismas API a
las que puede acceder directamente.
Los proveedores y plataformas en la nube también suelen ofrecer kits de desarrollo de software (SDK) e interfaces de
línea de comandos (CLI) para facilitar la integración con sus API.
• Las consolas web son administradas por el proveedor. Pueden ser específicos de la organización [por lo general, utilizan
la redirección del servidor de nombres de dominio (DNS) vinculada a la identidad federada]. Por ejemplo, cuando se
conecta a su aplicación para compartir archivos en la nube, se le redirige a su propia "versión" de la aplicación después de
iniciar sesión. Esta versión tendrá su propio nombre de dominio asociado, lo que le permitirá integrarse más fácilmente
con identidad federada (por ejemplo, en lugar de que todos sus usuarios inicien sesión en "application.com", inician sesión
en "your-organization.application.com").
Como se mencionó, la mayoría de las consolas web ofrecen una interfaz de usuario para las mismas API a las que puede
acceder directamente. Aunque, según la plataforma o el proceso de desarrollo del proveedor, a veces puede encontrar una
discrepancia en la que una función web o una llamada a la API aparecen en una antes que en la otra.
Las API suelen ser REST para servicios en la nube, ya que REST es fácil de implementar en Internet. Las API REST se
han convertido en el estándar para los servicios basados en web, ya que se ejecutan sobre HTTP / S y, por lo tanto,
funcionan bien en diversos entornos.
Estos pueden utilizar una variedad de mecanismos de autenticación, ya que no existe un estándar único para la
autenticación en REST. La firma de solicitudes HTTP y OAuth son las más comunes; ambos aprovechan las técnicas
criptográficas para validar las solicitudes de autenticación.
A menudo, sigue viendo servicios que incorporan una contraseña en la solicitud. Esto es menos seguro y tiene un mayor
riesgo de exposición de credenciales. Se ve con mayor frecuencia en plataformas web más antiguas o mal diseñadas que
construyeron su interfaz web primero y solo agregaron API de consumidor más tarde. Si encuentra esto, debe usar cuentas
dedicadas para el acceso a la API si es posible, a fin de reducir las oportunidades de exposición de credenciales.
6.1.1.2 Asegurar el plano de gestión
La gestión de identidades y accesos (IAM) incluye identificación, autenticación y autorizaciones (incluida la gestión de
acceso). Así es como puede determinar quién puede hacer qué dentro de su plataforma o proveedor en la nube.
Las opciones, configuraciones e incluso conceptos específicos varían mucho entre los proveedores y las plataformas de la
nube. Cada uno tiene su propia implementación y es posible que ni siquiera utilicen las mismas definiciones para cosas
como "grupos" y "roles".
No importa la plataforma o el proveedor, siempre hay un propietario de cuenta con privilegios de superadministrador para
administrar toda la configuración. Esto debe ser propiedad de la empresa (no personal), estar bien cerrado y casi nunca
usarse.
Independientemente del propietario de la cuenta, normalmente puede crear cuentas de superadministrador para uso de
administradores individuales. Utilice estos privilegios con moderación; este también debería ser un grupo más pequeño,
ya que el compromiso o el abuso de una de estas cuentas podría permitir que alguien cambie o acceda esencialmente a
todo y cualquier cosa.
Su plataforma o proveedor puede admitir cuentas administrativas de nivel inferior que solo pueden administrar partes del
servicio. A veces los llamamos "administradores de servicios" o "administradores del día a día". Estas cuentas no exponen
necesariamente toda la implementación si se abusa de ellas o se ven comprometidas y, por lo tanto, son mejores para el
uso diario común. También ayudan a compartimentar las sesiones individuales, por lo que no es inusual permitir que un
solo administrador humano acceda a múltiples cuentas (o roles) de administrador de servicios para que puedan iniciar
sesión solo con los privilegios que necesitan para esa acción en particular en lugar de tener que exponer una gama mucho
más amplia de derechos
Ejemplos de cuentas de usuario del plano de gestión de la nube de referencia, incluidos superadministradores y
administradores de servicios.
Tanto los proveedores como los consumidores deberían permitir de forma coherente solo el mínimo privilegio necesario
para los usuarios, las aplicaciones y otros usos del plano de gestión.
Todas las cuentas de usuarios privilegiados deben utilizar la autenticación multifactor (MFA). Si es posible, todas las
cuentas en la nube (incluso las cuentas de usuarios individuales) deben usar MFA. Es uno de los controles de seguridad
más eficaces para defenderse de una amplia gama de ataques. Esto también es cierto independientemente del modelo de
servicio: MFA es tan importante para SaaS como lo es para IaaS.
(Consulte el dominio de IAM para obtener más información sobre IAM y la función de la federación y la autenticación
sólida, muchas de las cuales se aplican al plano de administración de la nube).
6.1.1.3 Seguridad del plano de gestión al construir / proporcionar un servicio en la nube
Cuando usted es responsable de construir y mantener el propio plano de administración, como en una implementación de
nube privada, eso aumenta sus responsabilidades. Cuando consumes la nube solo configuras las partes del plano de
gestión que te expone el proveedor, pero cuando eres el proveedor de la nube obviamente eres responsable de todo.
Profundizar en los aspectos específicos de la implementación está más allá del alcance de esta Guía, pero en un nivel alto
hay cinco facetas principales para construir y administrar un plano de administración seguro:
• Seguridad perimetral: protección contra ataques contra los propios componentes del plano de gestión, como los
servidores web y API. Incluye tanto defensas de red de nivel inferior como defensas de nivel superior contra ataques de
aplicaciones.
• Autenticación del cliente: proporciona mecanismos seguros para que los clientes se autentiquen en el plano de gestión.
Esto debe usar estándares existentes (como OAuth o firma de solicitudes HTTP) que sean criptográficamente válidos y
estén bien documentados. La autenticación del cliente debe admitir MFA como opción o requisito.
• Autenticación interna y transferencia de credenciales: los mecanismos que utilizan sus propios empleados para
conectarse con las partes del plano de gestión que no están orientadas al cliente. También incluye cualquier traducción
entre la autenticación del cliente y cualquier solicitud de API interna. Los proveedores de la nube siempre deben exigir
MFA para la autenticación de la gestión de la nube.
• Autorización y derechos: los derechos disponibles para los clientes y los derechos para los administradores internos. Los
derechos granulares permiten a los clientes gestionar mejor a sus propios usuarios y administradores de forma segura.
Internamente, los derechos granulares reducen el impacto de que las cuentas de los administradores se vean
comprometidas o el abuso de los empleados.
• Registro, monitoreo y alertas: El registro y el monitoreo sólidos de la administración es esencial para la seguridad y el
cumplimiento efectivos. Esto se aplica tanto a lo que hace el cliente en su cuenta como a lo que hacen los empleados en su
gestión diaria del servicio. La alerta de eventos inusuales es un control de seguridad importante para garantizar que el
monitoreo sea procesable, y no simplemente algo que se observa después del hecho. Idealmente, los clientes de la nube
deberían poder acceder a los registros de su propia actividad en la plataforma a través de API u otro mecanismo para
integrarse con sus propios sistemas de registro de seguridad.
6.1.2 Continuidad comercial y recuperación ante desastres
Al igual que la seguridad y el cumplimiento, BC / DR es una responsabilidad compartida. Hay aspectos que el proveedor
de la nube tiene que gestionar, pero el cliente de la nube también es el responsable último de cómo utiliza y gestiona el
servicio en la nube. Esto es especialmente cierto al planificar las interrupciones del proveedor de la nube (o partes del
servicio del proveedor de la nube).
También similar a la seguridad, los clientes tienen más control y responsabilidad en IaaS, menos en SaaS, con PaaS en el
medio.
BC / DR debe adoptar un enfoque basado en el riesgo. Muchas opciones de BC pueden tener un costo prohibitivo en la
nube, pero también pueden no ser necesarias. Esto no es diferente a los centros de datos tradicionales, pero no es inusual
querer compensar en exceso cuando se pierde el control físico. Por ejemplo, las probabilidades de que un importante
proveedor de IaaS cierre o cambie todo su modelo comercial son bajas, pero esto no es tan infrecuente para un proveedor
más pequeño de SaaS respaldado por empresas.
• Pídale al proveedor estadísticas de interrupciones a lo largo del tiempo, ya que esto puede ayudarlo a informar sus
decisiones de riesgo.
• Recuerde que las capacidades varían entre proveedores y deben incluirse en el proceso de selección de proveedores.
6.1.2.1 Continuidad del negocio dentro del proveedor de la nube
Cuando implementa activos en la nube, no puede asumir que la nube siempre estará allí o que siempre funcionará como
espera. Las interrupciones y los problemas no son más o menos comunes que con cualquier otra tecnología, aunque la
nube puede ser en general más resistente cuando el proveedor incluye mecanismos para permitir la creación de
aplicaciones resistentes.
Este es un punto clave en el que debemos dedicar un poco más de tiempo: como mencionamos en algunos lugares, la
naturaleza misma de virtualizar recursos en grupos generalmente crea menos resiliencia para cualquier activo individual,
como una máquina virtual. Por otro lado, la abstracción de recursos y la gestión de todo a través del software abren la
flexibilidad para habilitar más fácilmente características de resiliencia como el almacenamiento duradero y el equilibrio de
carga intergeográfico.
Hay una gran variedad de opciones aquí, y no todos los proveedores o plataformas son iguales, pero no debe asumir que
"la nube" como término general es más o menos resistente que la infraestructura tradicional. A veces es mejor, a veces es
peor, y conocer la diferencia se reduce a su evaluación de riesgos y cómo usa el servicio en la nube.
Esta es la razón por la que generalmente es mejor rediseñar las implementaciones cuando las migra a la nube. La
resiliencia en sí, y los mecanismos fundamentales para garantizar la resiliencia, cambian. Es menos probable que las
migraciones directas de "elevación y cambio" tengan en cuenta las fallas, ni aprovecharán las mejoras potenciales al
aprovechar las capacidades específicas de la plataforma o el servicio.
La atención se centra en comprender y aprovechar las funciones BC / DR de la plataforma. Una vez que haya tomado la
decisión de implementar en la nube, querrá optimizar el uso de las funciones BC / DR incluidas antes de agregar
capacidades adicionales a través de herramientas de terceros.
BC / DR debe tener en cuenta toda la pila lógica:
• Metaestructura: dado que las configuraciones de la nube están controladas por software, estas configuraciones deben
respaldarse en un formato restaurable. Esto no siempre es posible y es bastante raro en SaaS, pero existen herramientas
para implementar esto en muchas plataformas IaaS (incluidas las opciones de terceros) mediante la infraestructura
definida por software.
• La infraestructura definida por software le permite crear una plantilla de infraestructura para configurar todos o algunos
aspectos de una implementación en la nube. Estas plantillas luego son traducidas de forma nativa por la plataforma en la
nube o en llamadas API que orquestan la configuración. Esto debe incluir controles como IAM y registro, no solo
arquitectura, diseño de red o configuraciones de servicio.
• Infraestructura: como se mencionó, cualquier proveedor ofrecerá características para soportar una mayor disponibilidad
que la que se puede lograr de manera comparable en un centro de datos tradicional por el mismo costo. Pero estos solo
funcionan si ajusta su arquitectura. Las aplicaciones de “elevación y cambio” a la nube sin ajustes arquitectónicos o
rediseño a menudo resultarán en una menor disponibilidad.
Asegúrese de comprender el modelo de costos de estas funciones, especialmente para implementarlas en las ubicaciones /
regiones físicas del proveedor, donde el costo puede ser alto. Algunos activos y datos deben convertirse para que
funcionen en todas las ubicaciones / regiones de la nube, por ejemplo, imágenes de máquinas personalizadas que se
utilizan para iniciar servidores. Estos activos deben incluirse en los planes.
• Infraestructura: la sincronización de datos es a menudo uno de los problemas más difíciles de administrar en todas las
ubicaciones, incluso si los costos de almacenamiento reales son manejables. Esto se debe al tamaño de los conjuntos de
datos (en comparación con una configuración de infraestructura) y a mantener los datos sincronizados entre ubicaciones y
servicios, algo que a menudo es difícil incluso en una única ubicación / sistema de almacenamiento.
• Estructura de la aplicación: la estructura de la aplicación incluye todo lo anterior, pero también los activos de la
aplicación como el código, las colas de mensajes, etc. Cuando un usuario de la nube crea sus propias aplicaciones en la
nube, por lo general, se construyen sobre IaaS y / o PaaS, por lo que la resistencia y la recuperación están inherentemente
vinculados a esas capas.
Pero Applistructure incluye la gama completa de todo en una aplicación. Comprenda las limitaciones y bloqueos de PaaS,
y planifique la interrupción de un componente de PaaS.
Los servicios de plataforma incluyen una variedad de funciones que solíamos implementar manualmente en las
aplicaciones, desde sistemas de autenticación hasta colas de mensajes y notificaciones. No es inusual que las aplicaciones
modernas incluso integren este tipo de servicios de varios proveedores de nube diferentes, creando una red intrincada.
Es razonable discutir la disponibilidad del componente / servicio con sus proveedores. Por ejemplo, es posible que el
servicio de base de datos de su proveedor de infraestructura no comparta el mismo rendimiento y disponibilidad que el
alojamiento de su máquina virtual.
Cuando no sea posible el cambio en tiempo real, diseñe su aplicación para que falle correctamente en caso de una
interrupción del servicio. Existen muchas técnicas de automatización para respaldar esto. Por ejemplo, si su servicio de
cola deja de funcionar, eso debería desencadenar la detención de la interfaz para que los mensajes no se pierdan.
El tiempo de inactividad es siempre una opción. No siempre necesitas una disponibilidad perfecta, pero si planeas aceptar
una interrupción, al menos debes asegurarte de fallar correctamente, con páginas de notificación y respuestas de tiempo de
inactividad de emergencia. Esto puede ser posible usando el modo de espera estático a través de la redirección de DNS.
La “ingeniería del caos” se usa a menudo para ayudar a construir implementaciones en la nube resistentes. Dado que toda
la nube está basada en API, Chaos Engineering utiliza herramientas para degradar de forma selectiva partes de la nube
para probar continuamente la continuidad del negocio.
Esto a menudo se hace en producción, no solo en el entorno de prueba, y obliga a los ingenieros a asumir la falla en lugar
de verla solo como un evento posible. Al diseñar sistemas para fallas, puede absorber mejor las fallas de componentes
individuales.
6.1.2.2 Continuidad del negocio por pérdida del proveedor de nube
Siempre es posible que un proveedor de nube completo o al menos una parte importante de su infraestructura (como una
geografía específica) pueda fallar. La planificación de las interrupciones del proveedor en la nube es difícil, debido al
bloqueo natural de aprovechar las capacidades de un proveedor. A veces, puede migrar a una parte diferente de su
servicio, pero en otros casos, una migración interna simplemente no es una opción, o puede estar totalmente bloqueado.
Según el historial de su proveedor y sus capacidades de disponibilidad interna, aceptar este riesgo suele ser una opción
legítima.
El tiempo de inactividad puede ser otra opción, pero depende de sus objetivos de tiempo de recuperación (RTO). Sin
embargo, debería estar disponible algún tipo de espera estática a través de la redirección de DNS. El error elegante
también debe incluir respuestas de error a las llamadas a la API, si ofrece API.
Tenga cuidado al seleccionar un proveedor o servicio secundario si dicho servicio también puede estar ubicado o depender
del mismo proveedor. No le sirve de nada utilizar un proveedor de almacenamiento de respaldo si dicho proveedor se basa
en el mismo proveedor de infraestructura.
Mover datos entre proveedores puede ser difícil, pero puede ser fácil en comparación con mover la metaestructura, los
controles de seguridad, el registro, etc., que pueden ser incompatibles entre plataformas.
SaaS a menudo puede ser el mayor problema de interrupciones del proveedor, debido a la total confianza en el proveedor.
La extracción y el archivo de datos programados pueden ser su única opción de BC además de aceptar el tiempo de
inactividad. Extraer y archivar en otro servicio en la nube, especialmente IaaS / PaaS, puede ser una mejor opción que
moverlo a un almacenamiento local / local. Nuevamente, adopte un enfoque basado en el riesgo que incluya el historial
único de su proveedor.
Incluso si tiene sus datos, debe tener una aplicación alternativa a la que sepa que puede migrarlos. Si no puede utilizar los
datos, no tiene una estrategia de recuperación viable.
Prueba, prueba y prueba. A menudo, esto puede ser más fácil que en un centro de datos tradicional porque no está
limitado por los recursos físicos y solo paga por el uso de ciertos activos durante la vida de la prueba.
6.1.2.3 Continuidad del negocio para la nube privada y los proveedores
Esto está completamente sobre los hombros del proveedor, y BC / DR incluye todo, hasta las instalaciones físicas. Los
RTO y RPO serán estrictos, ya que, si la nube se cae, todo se cae.
Si está brindando servicios a otras personas, tenga en cuenta los requisitos contractuales, incluida la residencia de datos,
cuando cree sus planes de BC. Por ejemplo, cambiar a una geografía diferente en una jurisdicción legal diferente puede
violar contratos o leyes locales.
6.2 Recomendaciones
• Seguridad del plano de gestión (metaestructura)
• Asegúrese de que exista una sólida seguridad perimetral para las puertas de enlace API y las consolas web.
• Utilice autenticación sólida y MFA.
• Mantenga un control estricto de las credenciales de la cuenta raíz / titular de la cuenta principal y considere
doble autoridad para acceder a ellos.
• Establecer varias cuentas con su proveedor ayudará con la granularidad de la cuenta.
y limitar el radio de explosión (con IaaS y PaaS).
• Utilice cuentas de superadministrador y de administrador diarias separadas en lugar de root /
credenciales del titular de la cuenta principal.
• Implementar constantemente cuentas con privilegios mínimos para el acceso a la metaestructura.
• Esta es la razón por la que separa las cuentas de desarrollo y de prueba con su proveedor de nube.
• Hacer cumplir el uso de MFA siempre que esté disponible
• Continuidad del negocio
• Arquitectura para fallas.
• Adopte un enfoque basado en el riesgo para todo. Incluso cuando asume lo peor, no significa que pueda pagar o
necesite mantener la disponibilidad total si sucede lo peor.
• Diseñe para alta disponibilidad dentro de su proveedor de nube. En IaaS y PaaS, esto suele ser más fácil y
rentable que el equivalente en la infraestructura tradicional.
• Aproveche las funciones específicas del proveedor.
• Comprender el historial, las capacidades y las limitaciones del proveedor.
• Siempre se debe considerar la ubicación cruzada, pero tenga cuidado con los costos que dependen de los
requisitos de disponibilidad.
 • Asegúrese también de que elementos como imágenes e ID de activos se conviertan para que funcionen en el
diferentes ubicaciones.
• La continuidad del negocio para la metaestructura es tan importante como la de los activos.
• Prepárese para fallas agradables en caso de una interrupción del proveedor de la nube.
• Esto puede incluir planes de interoperabilidad y portabilidad con otros proveedores de nube o una región
diferente con su proveedor actual.
• Para aplicaciones de muy alta disponibilidad, comience con BC de ubicación cruzada antes de intentar BC de
proveedor cruzado.
• Los proveedores de nube, incluida la nube privada, deben proporcionar los niveles más altos de disponibilidad y
los mecanismos para que los clientes / usuarios administren aspectos de su propia disponibilidad.
CAPÍTULO 12 - IDENTITY, ENTITLEMENT, AND ACCESS MANAGEMENT

12.0 Introducción
La gestión de identidades, derechos y acceso (IAM) se ve profundamente afectada por la computación en la nube. Tanto
en la nube pública como en la privada, se requieren dos partes para administrar IAM sin comprometer la seguridad. Este
dominio se centra en lo que debe cambiar en la gestión de identidades para la nube. Mientras revisamos algunos conceptos
fundamentales, la atención se centra en cómo la nube cambia la gestión de identidades y qué hacer al respecto.
La computación en la nube introduce múltiples cambios en la forma en que tradicionalmente administramos IAM para
sistemas internos. No es que estos sean problemas necesariamente nuevos, sino que son problemas mayores cuando se
trata de la nube.
La diferencia clave es la relación entre el proveedor de la nube y el usuario de la nube, incluso en la nube privada. IAM no
puede ser administrado únicamente por uno u otro y, por lo tanto, se requiere una relación de confianza, la designación de
responsabilidades y la mecánica técnica para habilitarlas. La mayoría de las veces, esto se reduce a la federación. Esto se
ve agravado por el hecho de que la mayoría de las organizaciones tienen muchos (a veces cientos) de diferentes
proveedores de nube a los que necesitan ampliar su IAM.
La nube también tiende a cambiar más rápido, estar más distribuida (incluso a través de los límites jurisdiccionales
legales), aumentar la complejidad del plano de administración y depender más (a menudo exclusivamente) de las
comunicaciones de red amplias para todo, lo que abre la administración de la infraestructura central a los ataques de red.
Además, existen grandes diferencias entre los proveedores y entre los diferentes modelos de servicio e implementación.
Este dominio se centra en IAM entre una organización y proveedores de nube o entre proveedores y servicios de nube. No
trata todos los aspectos de la gestión de IAM dentro de una aplicación en la nube, como el IAM interno para una
aplicación empresarial que se ejecuta en IaaS. Esos problemas son muy similares a la creación de aplicaciones y servicios
similares en la infraestructura tradicional.
12.0.1 En qué se diferencia IAM en la nube
La gestión de identidades y accesos siempre es complicada. En el fondo, estamos mapeando algún tipo de entidad (una
persona, sistema, código, etc.) a una identidad verificable asociada con varios atributos (que pueden cambiar según las
circunstancias actuales), y luego tomamos una decisión sobre lo que puede o no puede hacer en función de los derechos.
Incluso cuando controla toda la cadena de ese proceso, administrarlo en distintos sistemas y tecnologías de manera segura
y verificable, especialmente a escala, es un desafío.
En la computación en la nube, el problema fundamental es que varias organizaciones ahora están administrando la gestión
de identidad y acceso a los recursos, lo que puede complicar enormemente el proceso. Por ejemplo, imagine tener que
aprovisionar al mismo usuario en docenas, o cientos, de diferentes servicios en la nube. La federación es la herramienta
principal que se utiliza para gestionar este problema, mediante la creación de relaciones de confianza entre las
organizaciones y su aplicación a través de tecnologías basadas en estándares.
La federación y otras técnicas y tecnologías de IAM han existido desde antes de las primeras computadoras (solo
pregúntele a un banco o gobierno) y, con el tiempo, muchas organizaciones han construido parches y silos de IAM a
medida que su TI ha evolucionado. La computación en la nube es una función un poco forzada, ya que la adopción de la
nube empuja rápidamente a las organizaciones a confrontar sus prácticas de IAM y actualizarlas para lidiar con las
diferencias de la nube. Esto trae tanto oportunidades como desafíos.
En un nivel alto, la migración a la nube es una oportunidad para construir nueva infraestructura y procesos en
arquitecturas y estándares modernos. Ha habido avances tremendos en IAM a lo largo de los años, sin embargo, muchas
organizaciones solo han podido implementarlos en casos de uso limitados debido a limitaciones presupuestarias y de
infraestructura heredada. La adopción de la computación en la nube, ya sea un proyecto pequeño o una migración
completa del centro de datos, significa construir nuevos sistemas en una nueva infraestructura que generalmente se
diseñan utilizando las últimas prácticas de IAM.
Estos cambios también traen consigo desafíos. Pasar a la federación a escala con múltiples partes internas y externas
puede ser complejo y difícil de administrar debido a las meras matemáticas de todas las variables involucradas. La
determinación y aplicación de atributos y derechos en distintos sistemas y tecnologías conlleva problemas técnicos y de
proceso. Incluso las decisiones arquitectónicas fundamentales pueden verse obstaculizadas por la amplia variación en el
soporte entre los proveedores y las plataformas de la nube.
IAM abarca prácticamente todos los dominios de este documento. Esta sección comienza con una revisión rápida de
algunos términos básicos con los que no todos los lectores pueden estar familiarizados, luego profundiza en los impactos
de la nube, primero en la identidad, luego en la administración de acceso y derechos.

12.1 Resumen
IAM es un área de práctica amplia con su propio léxico que puede resultar confuso para quienes no son especialistas en
dominios, especialmente porque algunos términos tienen diferentes significados en diferentes contextos (y se usan en
áreas fuera de IAM). Incluso el término "IAM" no es universal y, a menudo, se lo denomina Administración de identidad
(IdM).
Gartner define IAM como "la disciplina de seguridad que permite a las personas adecuadas acceder a los recursos
adecuados en el momento adecuado y por las razones adecuadas". Antes de entrar en detalles, estos son los términos de
alto nivel más relevantes para nuestra discusión sobre IAM en la computación en la nube:
• Entidad: la persona o “cosa” que tendrá una identidad. Podría ser un individuo, un sistema, un dispositivo o un código de
aplicación.
• Identidad: la expresión única de una entidad dentro de un espacio de nombres dado. Una entidad puede tener múltiples
identidades digitales, como que un solo individuo tenga una identidad laboral (o incluso múltiples identidades, según los
sistemas), una identidad en las redes sociales y una identidad personal. Por ejemplo, si tiene una sola entrada en un
servidor de directorio único, esa es su identidad.
• Identificador: el medio por el cual se puede afirmar una identidad. Para las identidades digitales, esto suele ser una ficha
criptológica. En el mundo real, podría ser tu pasaporte.
• Atributos: facetas de una identidad. Los atributos pueden ser relativamente estáticos (como una unidad organizativa) o
muy dinámicos (dirección IP, dispositivo en uso, si el usuario se autenticó con MFA, ubicación, etc.).
• Persona: expresión de una identidad con atributos que indica contexto. Por ejemplo, un desarrollador que inicia sesión en
el trabajo y luego se conecta a un entorno de nube como desarrollador en un proyecto en particular. La identidad sigue
siendo el individuo y la persona es el individuo en el contexto de ese proyecto.
• Rol: las identidades pueden tener múltiples roles que indican contexto. “Rol” es un término confuso y abusado que se
usa de muchas formas diferentes. Para nuestros propósitos, lo consideraremos similar a una persona, o como un
subconjunto de una persona. Por ejemplo, un desarrollador determinado en un proyecto determinado puede tener
diferentes roles, como "superadministrador" y "dev", que luego se utilizan para tomar decisiones de acceso.
• Autenticación: el proceso de confirmar una identidad. Cuando inicia sesión en un sistema, presenta un nombre de
usuario (el identificador) y una contraseña (un atributo al que nos referimos como factor de autenticación). También
conocido como Authn.
• Autenticación multifactor (MFA): uso de múltiples factores en la autenticación. Las opciones comunes incluyen
contraseñas de un solo uso generadas por un dispositivo / token (OTP) físico o virtual, validación fuera de banda a través
de una OTP enviada por mensaje de texto o confirmación desde un dispositivo móvil, datos biométricos o tokens de
complemento.
• Control de acceso: restringir el acceso a un recurso. La gestión de acceso es el proceso de gestionar el acceso a los
recursos.
• Autorización: permitir el acceso de una identidad a algo (por ejemplo, datos o una función). También conocido como
Authz.
• Titularidad: mapeo de una identidad (incluidos roles, personas y atributos) a una autorización. El derecho es lo que se les
permite hacer y, para fines de documentación, los mantenemos en una matriz de derechos.
• Administración de identidad federada: el proceso de afirmar una identidad en diferentes sistemas u organizaciones. Este
es el habilitador clave del inicio de sesión único y también es fundamental para administrar IAM en la computación en la
nube.
• Fuente autorizada: la fuente “raíz” de una identidad, como el servidor de directorio que administra las identidades de los
empleados.
• Proveedor de identidad: la fuente de la identidad en la federación. El proveedor de identidad no siempre es la fuente
autorizada, pero a veces puede confiar en la fuente autorizada, especialmente si es un
corredor para el proceso.
• Parte que confía: el sistema que se basa en una afirmación de identidad de un proveedor de identidad.
Hay algunos términos más que se cubrirán en las secciones relevantes a continuación, incluidos los principales estándares
de IAM. Además, aunque este dominio puede parecer demasiado centrado en la nube pública, se aplican los mismos
principios en la nube privada; el alcance, sin embargo, se reducirá ya que la organización puede tener más control sobre
toda la pila.
12.1.1 Estándares de IAM para computación en la nube
Existen bastantes estándares de administración de identidad y acceso, y muchos de ellos se pueden utilizar en la
computación en la nube. A pesar de la amplia gama de opciones, la industria se está decantando por un conjunto básico
que se ve con mayor frecuencia en varias implementaciones y es compatible con la mayoría de los proveedores. También
hay algunos estándares que son prometedores, pero que aún no se utilizan con tanta frecuencia. Esta lista no refleja ningún
respaldo en particular y no incluye todas las opciones, pero es simplemente representativa de lo que más comúnmente es
respaldado por la gama más amplia de proveedores:
• Security Assertion Markup Language (SAML) 2.0 es un estándar OASIS para la administración de identidades
federadas que admite tanto la autenticación como la autorización. Utiliza XML para realizar afirmaciones entre un
proveedor de identidad y una parte de confianza. Las afirmaciones pueden contener declaraciones de autenticación,
declaraciones de atributos y declaraciones de decisión de autorización. SAML es ampliamente compatible tanto con
herramientas empresariales como con proveedores de nube, pero puede ser complejo de configurar inicialmente.
• OAuth es un estándar IETF de autorización que se utiliza mucho para servicios web (incluidos los servicios al
consumidor). OAuth está diseñado para funcionar a través de HTTP y actualmente tiene la versión 2.0, que no es
compatible con la versión 1.0. Para agregar un poco de confusión a la combinación, OAuth 2.0 es más un marco y menos
rígido que OAuth 1.0, lo que significa que las implementaciones pueden no ser compatibles. Se utiliza con mayor
frecuencia para delegar el control de acceso / autorizaciones entre servicios.
• OpenID es un estándar para la autenticación federada que es ampliamente compatible con los servicios web. Se basa en
HTTP con URL que se utilizan para identificar el proveedor de identidad y el usuario / identidad (por ejemplo,
identity.identityprovider.com). La versión actual es OpenID Connect 1.0 y se ve con mucha frecuencia en los servicios al
consumidor.
Hay otros dos estándares que no se encuentran con tanta frecuencia pero que pueden ser útiles para la computación en la
nube:
• El Lenguaje de marcado de control de acceso extensible (XACML) es un estándar para definir autorizaciones / controles
de acceso basados en atributos. Es un lenguaje de políticas para definir controles de acceso en un punto de decisión de
políticas y luego pasarlos a un punto de aplicación de políticas. Se puede usar tanto con SAML como con OAuth, ya que
resuelve una parte diferente del problema, es decir, decidir qué puede hacer una entidad con un conjunto de atributos, en
lugar de manejar inicios de sesión o delegación de autoridad.
• El sistema para la gestión de identidades entre dominios (SCIM) es un estándar para el intercambio de información de
identidad entre dominios. Se puede utilizar para aprovisionar y desaprovisionar cuentas en sistemas externos y para
intercambiar información de atributos.

Cómo funciona la administración de identidad federada: la federación implica que un proveedor de identidad realice
afirmaciones a una parte de confianza después de establecer una relación de confianza. En el corazón hay una serie de
operaciones criptográficas para construir la relación de confianza e intercambiar credenciales. Un ejemplo práctico es un
usuario que inicia sesión en su red de trabajo, que aloja un servidor de directorio para cuentas. Luego, ese usuario abre
una conexión de navegador a una aplicación SaaS. En lugar de iniciar sesión, hay una serie de operaciones detrás de
escena, donde el proveedor de identidad (el servidor de directorio interno) afirma la identidad del usuario y que el usuario
se autenticó, así como cualquier atributo. La parte que confía en esas afirmaciones e inicia la sesión del usuario sin que el
usuario ingrese ninguna credencial. De hecho, la parte que confía ni siquiera tiene un nombre de usuario o contraseña para
ese usuario; se basa en el proveedor de identidad para hacer valer la autenticación correcta. Para el usuario, simplemente
van al sitio web de la aplicación SaaS y están conectados, asumiendo que se autenticaron exitosamente con el directorio
interno.
Esto no implica que no se utilicen otras técnicas o estándares en la computación en la nube para identificar, autenticar y
autorizar. La mayoría de los proveedores de nube, especialmente IaaS, tienen sus propios sistemas de IAM internos que
pueden no usar ninguno de estos estándares o que pueden conectarse a una organización que usa estos estándares. Por
ejemplo, la firma de solicitudes HTTP se utiliza con mucha frecuencia para autenticar las API REST y las decisiones de
autorización se gestionan mediante políticas internas del lado del proveedor de la nube. La firma de la solicitud aún puede
admitir SSO a través de SAML, o la API puede estar completamente basada en OAuth o usar su propio mecanismo de
token. Todos se encuentran comúnmente, pero la mayoría de los proveedores de nube de clase empresarial ofrecen algún
tipo de soporte de federación.
Los protocolos y estándares de identidad no representan una solución completa por sí mismos, pero son un medio para un
fin.
Los conceptos esenciales a la hora de elegir un protocolo de identidad son:
• Ningún protocolo es una solución milagrosa que resuelva todos los problemas de control de acceso e identidad.
• Los protocolos de identidad deben analizarse en el contexto de los casos de uso. Por ejemplo, el inicio de sesión único
basado en navegador, las claves de API o la autenticación de móvil a nube podrían llevar a las empresas a un enfoque
diferente.
• El supuesto operativo clave debe ser que la identidad es un perímetro en sí mismo, al igual que una DMZ. Por lo tanto,
cualquier protocolo de identidad debe seleccionarse y diseñarse desde el punto de vista de que puede atravesar un
territorio de riesgo y resistir la malicia.

12.1.2 Gestión de usuarios e identidades para Cloud Computing

La parte de "identidad" de la administración de identidades se centra en los procesos y tecnologías para registrar,
aprovisionar, propagar, administrar y desaprovisionar identidades. La gestión de identidades y su aprovisionamiento en
sistemas son problemas que la seguridad de la información ha abordado durante décadas. No fue hace mucho tiempo que
los administradores de TI necesitaban aprovisionar usuarios individualmente en cada sistema interno diferente. Incluso
hoy en día, con servidores de directorio centralizados y una variedad de estándares, el inicio de sesión único real para todo
es relativamente raro; los usuarios aún administran un conjunto de credenciales, aunque un conjunto mucho más pequeño
que en el pasado.
Una nota sobre el alcance: las descripciones en esta sección son genéricas, pero se inclinan hacia la gestión de usuarios.
Los mismos principios se aplican a las identidades de servicios, dispositivos, servidores, código y otras entidades, pero los
procesos y los detalles relacionados con ellos pueden ser más complejos y están estrechamente vinculados a la seguridad y
la arquitectura de las aplicaciones. Este dominio también solo incluye una discusión limitada de todos los problemas de
administración de identidad interna para los proveedores de la nube, por las mismas razones. No es que estas áreas sean
menos importantes; en muchos casos son más importantes, pero también traen consigo una complejidad que no puede
cubrirse completamente dentro de las limitaciones de esta Guía.
Los proveedores de la nube y los usuarios de la nube deben comenzar con la decisión fundamental sobre cómo administrar
las identidades:
• Los proveedores de la nube deben admitir casi siempre identidades, identificadores y atributos internos para los usuarios
que acceden directamente al servicio, al mismo tiempo que admiten la federación para que las organizaciones no tengan
que aprovisionar y administrar manualmente a cada usuario en el sistema del proveedor y emitir credenciales por separado
para todos.
• Los usuarios de la nube deben decidir dónde quieren administrar sus identidades y qué modelos arquitectónicos y
tecnologías quieren admitir para integrarse con los proveedores de la nube.
Como usuario de la nube, puede iniciar sesión en un proveedor de la nube y crear todas sus identidades en su sistema.
Esto no es escalable para la mayoría de las organizaciones, por lo que la mayoría recurre a la federación. Tenga en cuenta
que puede haber excepciones en las que tiene sentido mantener aisladas todas o algunas de las identidades con el
proveedor de nube, como cuentas de administrador de respaldo para ayudar a depurar problemas con la conexión de
identidad federada.
Al usar la federación, el usuario de la nube debe determinar la fuente autorizada que contiene las identidades únicas que
federará. Suele ser un servidor de directorio interno. La siguiente decisión es si utilizar directamente la fuente autorizada
como proveedor de identidad, utilizar una fuente de identidad diferente que se alimente de la fuente autorizada (como un
directorio alimentado desde un sistema de recursos humanos) o integrar un agente de identidad. Hay dos arquitecturas
posibles:
• Forma libre: los proveedores / fuentes de identidad internos (a menudo servidores de directorio) se conectan
directamente a los proveedores de la nube.
• Concentrador y radio: los proveedores / fuentes de identidad internos se comunican con un agente o repositorio central
que luego sirve como proveedor de identidad para la federación a los proveedores de la nube.
La federación directa de servidores de directorios internos en el modelo de forma libre plantea algunos problemas:
• El directorio necesita acceso a Internet. Esto puede ser un problema, dependiendo de la topografía existente, o puede
violar las políticas de seguridad.
• Puede requerir que los usuarios vuelvan a la VPN a la red corporativa antes de acceder a los servicios en la nube.
• Dependiendo del servidor de directorio existente, y especialmente si tiene varios servidores de directorio en diferentes
silos organizacionales, la federación a un proveedor externo puede ser compleja y técnicamente difícil.
Los agentes de identidad se encargan de la federación entre proveedores de identidad y partes de confianza (que no
siempre puede ser un servicio en la nube). Pueden ubicarse en el borde de la red o incluso en la nube para habilitar web-
SSO.
Los proveedores de identidad no necesitan estar ubicados solo en las instalaciones; muchos proveedores en la nube ahora
admiten servidores de directorio basados en la nube que admiten la federación internamente y con otros servicios en la
nube. Por ejemplo, las arquitecturas más complejas pueden sincronizar o federar una parte de las identidades de una
organización para un directorio interno a través de un agente de identidad y luego a un directorio alojado en la nube, que
luego sirve como proveedor de identidad para otras conexiones federadas.
Después de determinar el modelo a gran escala, todavía se requieren decisiones de proceso y arquitectura para cualquier
implementación:
• Cómo administrar identidades para códigos de aplicaciones, sistemas, dispositivos y otros servicios. Puede aprovechar el
mismo modelo y estándares o decidir adoptar un enfoque diferente dentro de las implementaciones y aplicaciones en la
nube. Por ejemplo, las descripciones anteriores se inclinan hacia los usuarios que acceden a los servicios, pero es posible
que no se apliquen por igual para los servicios que se comunican con los servicios, sistemas o dispositivos, o para los
componentes de la aplicación dentro de una implementación de IaaS.
• Definir el proceso de aprovisionamiento de identidad y cómo integrarlo en las implementaciones en la nube. También
puede haber varios procesos de aprovisionamiento para diferentes casos de uso, aunque el objetivo debería ser tener un
proceso lo más unificado posible.

 Si la organización cuenta con un proceso de aprovisionamiento eficaz para la infraestructura tradicional, lo ideal
sería extenderlo a implementaciones en la nube. Sin embargo, si los procesos internos existentes son
problemáticos, la organización debería utilizar el cambio a la nube como una oportunidad para crear un proceso
nuevo y más eficaz.
• Aprovisionamiento y soporte de implementaciones y proveedores de nube individuales. Debe haber un proceso formal
para agregar nuevos proveedores a la infraestructura de IAM. Esto incluye el proceso de establecer las conexiones de
federación necesarias, así como:
- Mapeo de atributos (incluidos roles) entre el proveedor de identidad y la parte que confía.
- Habilitación de la supervisión / registros necesarios, incluida la supervisión de seguridad relacionada con la
identidad, como el análisis de comportamiento.
- Creación de una matriz de derechos (se analiza más en la siguiente sección).
- Documentar cualquier escenario de ruptura / reparación en caso de que haya una falla técnica de cualquiera de
las federaciones (u otras técnicas) utilizadas para la relación.
- Asegurar que se implementen planes de respuesta a incidentes para posibles adquisiciones de cuentas, incluidas
las adquisiciones de cuentas privilegiadas.
• Implementar procesos de desaprovisionamiento o cambio de titularidad para las identidades y el proveedor de la nube.
Con la federación, esto requiere trabajo en ambos lados de la conexión.
Por último, los proveedores de la nube deben determinar qué estándares de gestión de identidades desean admitir. Algunos
proveedores solo admiten la federación, mientras que otros admiten varios estándares de IAM además de su propia
administración interna de usuarios / cuentas. Los proveedores que prestan servicios a los mercados empresariales deberán
admitir la identidad federada y, muy probablemente, SAML.
12.1.3 Autenticación y credenciales
La autenticación es el proceso de probar o confirmar una identidad. En la seguridad de la información, la autenticación se
refiere más comúnmente al acto de un usuario que inicia sesión, pero también se refiere esencialmente a cualquier
momento en que una entidad prueba quiénes son y asume una identidad. La autenticación es responsabilidad del
proveedor de identidad.
El mayor impacto de la computación en la nube en la autenticación es una mayor necesidad de autenticación sólida
utilizando múltiples factores. Esto es por dos razones:
• El acceso amplio a la red significa que siempre se accede a los servicios en la nube a través de la red y, a menudo, a
través de Internet. La pérdida de credenciales podría llevar más fácilmente a que un atacante tome el control de la cuenta,
ya que los ataques no se limitan a la red local.
• Un mayor uso de la federación para el inicio de sesión único significa que un conjunto de credenciales puede
comprometer potencialmente una mayor cantidad de servicios en la nube.
La autenticación multifactor (MFA) ofrece una de las opciones más sólidas para reducir las adquisiciones de cuentas. No
es una panacea, pero confiar en un solo factor (contraseña) para los servicios en la nube es un riesgo muy alto. Cuando se
usa MFA con federación, el proveedor de identidad puede y debe pasar el estado de MFA como un atributo a la parte de
confianza.
Hay varias opciones para MFA, que incluyen:
• Los tokens duros son dispositivos físicos que generan contraseñas de un solo uso para la entrada humana o deben
conectarse a un lector. Éstas son la mejor opción cuando se requiere el más alto nivel de seguridad.
• Los tokens de software funcionan de manera similar a los tokens de hardware, pero son aplicaciones de software que se
ejecutan en un teléfono o computadora. Los tokens de software también son una excelente opción, pero podrían verse
comprometidos si el dispositivo del usuario se ve comprometido, y este riesgo debe tenerse en cuenta en cualquier modelo
de amenaza.
• Las contraseñas fuera de banda son mensajes de texto u otros mensajes que se envían al teléfono de un usuario
(generalmente) y luego se ingresan como cualquier otra contraseña generada por un token. Aunque también es una buena
opción, cualquier modelo de amenaza debe considerar la interceptación de mensajes, especialmente con SMS.
• La biometría está creciendo como una opción, gracias a los lectores biométricos ahora comúnmente disponibles en
teléfonos móviles. Para los servicios en la nube, la biometría es una protección local que no envía información biométrica
al proveedor de la nube, sino que es un atributo que se puede enviar al proveedor. Como tal, se debe considerar la
seguridad y propiedad del dispositivo local.
Para los clientes, FIDO es un estándar que puede agilizar una autenticación más sólida para los consumidores al tiempo
que minimiza la fricción.
12.1.4 Gestión de derechos y acceso
Los términos derechos, autorización y control de acceso se superponen un poco y se definen de manera diferente según el
contexto. Aunque los definimos anteriormente en esta sección, aquí hay una revisión rápida.
Una autorización es un permiso para hacer algo: acceder a un archivo o red, o realizar una determinada función como una
llamada a la API en un recurso en particular.
Un control de acceso permite o niega la expresión de esa autorización, por lo que incluye aspectos como asegurar que el
usuario esté autenticado antes de permitir el acceso.
Un derecho asigna identidades a autorizaciones y cualquier atributo requerido (por ejemplo, el usuario x tiene acceso al
recurso y cuando los atributos z tienen valores designados). Normalmente nos referimos a un mapa de estos derechos
como una matriz de derechos. Los derechos a menudo se codifican como políticas técnicas para la distribución y el
cumplimiento.
Esta es solo una definición de estos términos y es posible que vea que se usan de manera diferente en otros documentos.
También usamos el término administración de acceso como la parte "A" de IAM y se refiere a todo el proceso de
definición, propagación y ejecución de autorizaciones.

A continuación, se muestra un ejemplo de nube del mundo real. El proveedor de la nube tiene una API para lanzar nuevas
máquinas virtuales. Esa API tiene una autorización correspondiente para permitir el lanzamiento de nuevas máquinas, con
opciones de autorización adicionales para la red virtual dentro de la cual un usuario puede lanzar la VM. El administrador
de la nube crea un derecho que dice que los usuarios del grupo de desarrolladores pueden lanzar máquinas virtuales solo
en la red de su proyecto y solo si se autenticaron con MFA. El grupo y el uso de MFA son atributos de la identidad del
usuario. Ese derecho está escrito como una política que se carga en el sistema del proveedor de la nube para su
cumplimiento.
La nube afecta los derechos, las autorizaciones y la gestión de acceso de varias formas:
• Los proveedores y plataformas de nube, como cualquier otra tecnología, tendrán su propio conjunto de posibles
autorizaciones específicas para ellos. A menos que el proveedor admita XACML (poco común hoy en día), el usuario de
la nube normalmente necesitará configurar los derechos dentro de la plataforma de la nube directamente.
• El proveedor de la nube es responsable de hacer cumplir las autorizaciones y los controles de acceso.
• El usuario de la nube es responsable de definir los derechos y configurarlos correctamente dentro de la plataforma de la
nube.
• Las plataformas en la nube tienden a tener un mayor soporte para el modelo de control de acceso basado en atributos
(ABAC) para IAM, que ofrece mayor flexibilidad y seguridad que el modelo de control de acceso basado en roles
(RBAC). RBAC es el modelo tradicional para hacer cumplir las autorizaciones y se basa en lo que a menudo es un
atributo único (un rol definido). ABAC permite decisiones más granulares y conscientes del contexto al incorporar
múltiples atributos, como rol, ubicación, método de autenticación y más.
• ABAC es el modelo preferido para la gestión de acceso basada en la nube.
• Cuando se utiliza la federación, el usuario de la nube es responsable de asignar atributos, incluidos roles y grupos, al
proveedor de la nube y asegurarse de que se comuniquen correctamente durante la autenticación.
• Los proveedores de la nube son responsables de admitir autorizaciones y atributos granulares para habilitar ABAC y una
seguridad eficaz para los usuarios de la nube.
12.1.5 Gestión de usuarios privilegiados
En términos de control de riesgos, pocas cosas son más esenciales que la gestión de usuarios privilegiados. Los requisitos
mencionados anteriormente para una autenticación sólida deben ser una consideración importante para cualquier usuario
privilegiado. Además, se debe implementar la recodificación de cuentas y sesiones para aumentar la responsabilidad y la
visibilidad de los usuarios privilegiados.
En algunos casos, será beneficioso para un usuario privilegiado iniciar sesión a través de un sistema separado
estrictamente controlado utilizando niveles más altos de seguridad para el control de credenciales, certificados digitales,
puntos de acceso separados física y lógicamente y / o hosts de salto.
12.2 Recomendaciones
Las organizaciones deben desarrollar un plan y procesos completos y formalizados para administrar identidades y
autorizaciones con servicios en la nube.
• Cuando se conecte a proveedores de nube externos, utilice la federación, si es posible, para ampliar la gestión de
identidad existente. Intente minimizar los silos de identidades en los proveedores de la nube que no estén vinculados a
identidades internas.
• Considere el uso de agentes de identidad cuando sea apropiado.
• Los usuarios de la nube son responsables de mantener el proveedor de identidad y definir identidades y atributos.
• Estos deben basarse en una fuente autorizada.
• Las organizaciones distribuidas deben considerar el uso de servidores de directorio alojados en la nube cuando las
opciones locales no estén disponibles o no cumplan con los requisitos.
• Los usuarios de la nube deben preferir MFA para todas las cuentas de nube externas y enviar el estado de MFA como un
atributo cuando utilicen la autenticación federada.
• Las identidades privilegiadas siempre deben usar MFA.
• Desarrollar una matriz de derechos para cada proveedor y proyecto de nube, con énfasis en el acceso a la metaestructura
y / o al plano de gestión.
• Traducir matrices de derechos en políticas técnicas cuando sea compatible con la plataforma o el proveedor de la nube.
• Prefiera ABAC sobre RBAC para la computación en nube.
• Los proveedores de la nube deben ofrecer tanto identidades internas como federación utilizando estándares abiertos.
• No hay protocolos mágicos: elija primero sus casos de uso y restricciones y, en segundo lugar, busque el protocolo
correcto.
AMENAZA 1: INSUFFICIENT DUE DILIGENCE

9.1 Descripción
Cuando los ejecutivos crean estrategias comerciales, se deben considerar las tecnologías en la nube y los CSP. Desarrollar
una buena hoja de ruta y una lista de verificación para la debida diligencia al evaluar tecnologías y CSP es esencial para
tener mayores posibilidades de éxito. Una organización que se apresura a adoptar tecnologías en la nube y elegir CSP sin
realizar la debida diligencia se expone a una gran cantidad de riesgos comerciales, financieros, técnicos, legales y de
cumplimiento que ponen en peligro su éxito. Esto se aplica si la empresa está considerando mudarse a la nube o fusionarse
o adquirir una empresa que se mudó a la nube o si está considerando hacerlo.
9.2 Impactos comerciales
Comercial: los servicios al cliente anticipados o de nuevo diseño que dependen del CSP para desarrollar nuevos sistemas
y procesos pueden no ser una prioridad o una experiencia del CSP.
Técnico: Pueden surgir problemas operativos y arquitectónicos desconocidos cuando los diseñadores y arquitectos que no
están familiarizados con las tecnologías de la nube diseñan aplicaciones que se envían a la nube.
Legal: Los datos en uso, en movimiento o en reposo en ubicaciones extranjeras durante las operaciones normales o
incluso durante la recuperación pueden someter a la empresa a una reparación regulatoria.
Cumplimiento: mover aplicaciones que dependen de controles de seguridad y privacidad de datos a nivel de red "internos"
a la nube es peligroso cuando esos controles desaparecen.
La conclusión para las empresas y organizaciones que se trasladan a un modelo de tecnología en la nube es que deben
realizar una diligencia debida exhaustiva para comprender los riesgos que asumen al adoptar este modelo de tecnología e
involucrar a los proveedores que lo proporcionan.
9.3 Anécdotas y ejemplos
Recursos / controles / políticas capaces: en 2012, la nube pública de Amazon Web Service (AWS), en la que Netflix se
basa para transmitir contenido a los clientes, experimentó una interrupción en su región de EE. UU. Este (que abarca
varias zonas en AWS), debido a la eliminación accidental de información que controla el equilibrio de carga.
Viabilidad contractual y financiera: en 2013, Nirvanix, un especialista en almacenamiento en la nube que alojaba datos
para IBM, Dell y sus propios clientes, se declaró en bancarrota del Capítulo 11 y cerró sus operaciones. A los clientes se
les dio menos de dos semanas para mover sus datos a otro servicio, lo que destacó los siguientes problemas:
Pérdida de datos: ¿Qué pasaría con los datos de los clientes de Nirvanix si no pudieran recuperarlos en dos semanas?
Interrupciones operativas: el estudio de producción de cine y televisión Relativity Media estaba utilizando la nube de
Nirvanix como un centro a través del cual los empleados en sus ubicaciones globales podían colaborar y compartir
archivos digitales masivos para acelerar la producción.
Violaciones de seguridad: un proveedor de servicios con problemas de liquidez puede escatimar en tecnología y personal
de seguridad, y una reducción frenética puede significar que los procedimientos de seguridad normales no se cumplen.
Incumplimiento: los servicios de salud y financieros deben conservar los datos para cumplir con las regulaciones de
cumplimiento del gobierno. Si se pierden los datos, estos servicios dejan de ser compatibles.
M&A - En 2011, Facebook resolvió los cargos de la FTC por engañar a los consumidores al no cumplir sus promesas de
privacidad. Según los términos de la orden de la FTC, Facebook debe obtener el consentimiento afirmativo del
consumidor antes de realizar cambios que anulen su configuración de privacidad, entre otros requisitos.
Jason Weinstein, ex vicefiscal general adjunto del Departamento de Justicia de EE. UU., Resumió el tema de la debida
diligencia en ciberseguridad de manera sucinta cuando dijo: "Cuando compras una empresa, estás comprando sus datos y
podrías estar comprando sus problemas de seguridad de datos". " En otras palabras, “el riesgo cibernético debe
considerarse correcto junto con las consideraciones de diligencia debida financiera y legal.
9.4 ID de control de CCM v3.0.1
 AIS-01: Seguridad de aplicaciones e interfaces - Seguridad de aplicaciones
 AIS-04: Seguridad de aplicaciones e interfaces - Seguridad / integridad de los datos
 AAC-01: Aseguramiento y cumplimiento de auditorías - Planificación de auditorías
 AAC-02: Aseguramiento y cumplimiento de auditorías - Auditorías independientes
 AAC-03: Garantía de auditoría y cumplimiento - Información. Mapeo regulatorio del sistema
 BCR-01: Gestión de la continuidad del negocio y resiliencia operativa - Planificación de la continuidad del
negocio
 BCR-02: Gestión de la continuidad del negocio y resiliencia operativa - Pruebas de continuidad del negocio
 BCR-03: Gestión de la continuidad del negocio y resiliencia operativa - Servicios / entornos de centros de datos.
Condiciones
 BCR-04: Gestión de la continuidad del negocio y resiliencia operativa - Documentación
 BCR-05: Gestión de la continuidad del negocio y resiliencia operativa - Riesgos ambientales
 BCR-06: Gestión de la continuidad del negocio y resiliencia operativa - Ubicación de equipos
 BCR-07: Gestión de la continuidad del negocio y resiliencia operativa - Mantenimiento de equipos
 BCR-08: Gestión de la continuidad del negocio y resiliencia operativa - Fallos de alimentación de los equipos
 BSR-09: Gestión de la continuidad del negocio y resiliencia operativa - Análisis de impacto
 BCR-10: Gestión de la continuidad del negocio y resiliencia operativa - Política
 BCR-11: Gestión de la continuidad del negocio y resiliencia operativa - Política de retención
 GRM-01: Gobernanza y gestión de riesgos: requisitos de referencia
 GRM-02: Gobernanza y gestión de riesgos: evaluaciones de riesgos centradas en los datos
 GRM-03: Gobernanza y gestión de riesgos - Supervisión de la gestión
 GRM-04: Gobierno y gestión de riesgos - Programa de gestión
 GRM-05: Gobernanza y gestión de riesgos - Apoyo / participación de la dirección
 GRM-06: Gobernanza y gestión de riesgos - Política
 GRM-07: Gobernanza y gestión de riesgos - Aplicación de políticas
 GRM-08: Gobernanza y gestión de riesgos: impacto de las políticas en las evaluaciones de riesgos
 GRM-09: Gobernanza y gestión de riesgos: revisiones de políticas
 GRM-10: Gobernanza y gestión de riesgos: evaluaciones de la gestión de riesgos
 GRM-11: Gobernanza y gestión de riesgos - Marco de gestión de riesgos
 IVS-06: Seguridad de infraestructura y virtualización - Seguridad de red
 IVS-09: Seguridad de virtualización e infraestructura – Segmentación
AMENAZA 2: ABUSE AND NEFARIOUS USE OF CLOUD SERVICES

10.1 Descripción
Las implementaciones de servicios en la nube con poca seguridad, las pruebas gratuitas del servicio en la nube y los
registros de cuentas fraudulentos a través del fraude de instrumentos de pago exponen los modelos de computación en la
nube como IaaS, PaaS y SaaS a ataques maliciosos.
Los actores malintencionados pueden aprovechar los recursos de computación en la nube para dirigirse a usuarios,
organizaciones u otros proveedores de la nube. Ejemplos de uso indebido de recursos basados en servicios en la nube
incluyen el lanzamiento de ataques DDoS, correo no deseado y campañas de phishing; "Minería" de moneda digital;
fraude de clics automatizado a gran escala; ataques informáticos de fuerza bruta de bases de datos de credenciales
robadas; y alojamiento de contenido malicioso o pirateado.
Las mitigaciones para el uso indebido de los servicios en la nube incluyen la detección de CSP del fraude en los
instrumentos de pago y del uso indebido de las ofertas en la nube, incluidos ejemplos de ataques DoS de red entrantes y
salientes. Un proveedor de nube debe tener un marco de respuesta a incidentes para abordar el uso indebido de recursos,
así como un medio para que los clientes denuncien el abuso que se origina en un proveedor de nube. Un proveedor de
nube debe incluir controles relevantes que permitan al cliente monitorear el estado de su carga de trabajo en la nube.
10.2 Impactos comerciales
El uso malintencionado de los recursos del servicio en la nube puede reducir la capacidad disponible para los clientes
legítimos alojados por los proveedores de servicios en la nube. Responder al uso malintencionado también puede reducir
la disponibilidad de recursos de respuesta para abordar otros problemas de soporte al cliente El uso fraudulento de
instrumentos de pago puede resultar en traspasar mayores costos a partes inocentes como instituciones financieras o
proveedores de la nube y, en última instancia, a clientes y otros.
Los ataques DDoS que se originan o se dirigen a un proveedor de nube pueden provocar falta de disponibilidad,
interrupción del negocio y pérdida de ingresos para otros sitios alojados en la misma plataforma de nube.
Aunque es posible que la propia organización no esté realizando ninguna de estas acciones, debido a la naturaleza
compartida de algunos servicios en la nube, este tipo de amenaza presenta problemas de disponibilidad de datos y
servicios para una organización.
10.3 Anécdotas y ejemplos
El DDoS que casi rompió Internet: "Los atacantes pudieron generar más de 300 Gbps de tráfico, probablemente con una
red propia que solo tenía acceso a una centésima parte de esa cantidad de tráfico".
Los piratas informáticos se infiltran en AWS para el centro de lanzamiento de DDoS: “La división Elastic Cloud
Computing de Amazon estaba sufriendo un ataque altamente sofisticado por parte de un grupo de piratas informáticos
desconocidos, que habían encontrado una manera de aplicar ingeniería inversa al código de prueba de concepto y crear
una puerta trasera de fácil acceso para en el enorme banco de potencia de procesamiento disponible de Amazon.
10.4 CCM v3.0.1 ID de control
 HRS-01: Recursos humanos - Devolución de activos
 HRS-02: Recursos humanos - Investigación de antecedentes
 HRS-03: Recursos humanos - Acuerdos laborales
 HRS-04: Recursos humanos - Terminación del empleo
 HRS-07: Recursos humanos - Roles / Responsabilidades
 HRS-08: Recursos humanos - Uso aceptable de la tecnología
 HRS-10: Recursos humanos - Responsabilidad del usuario
 SEF-01: Gestión de incidentes de seguridad, descubrimiento electrónico y análisis forense en la nube -
Mantenimiento de contactos / autoridades
 SEF-02: Gestión de incidentes de seguridad, descubrimiento electrónico y análisis forense en la nube: gestión de
incidentes
 SEF-03: Gestión de incidentes de seguridad, descubrimiento electrónico y análisis forense en la nube: informes de
incidentes
 SEF-04: Gestión de incidentes de seguridad, descubrimiento electrónico y análisis forense en la nube: preparación
legal