Tanto en la Nube pública como privada, se requieren dos partes para administrar la Identidad y la gestión de Accesos sin comprometer la seguridad.
La computación en la nube introduce múltiples cambios a la forma en que tradicionalmente hemos administrado IAM para sistemas internos. No es que estos sean necesariamente temas nuevos, sino que son cuestiones más importantes cuando se trata de la cloud.
La diferencia clave es la relación entre el proveedor de la nube y el usuario de la nube, incluso en la nube privada. La gestión de identidad y el control de accesos no puede ser administrada únicamente por uno u otro y por lo tanto una relación de confianza y responsabilidades, requiere habilitar los mecanismos técnicos necesarios, donde en la mayoría de las veces esto se reduce a la federación.
La cloud es un entorno que tiende a cambiar rápidamente con frecuencia, estar altamente distribuida (incluso a través de límites jurisdiccionales legales), aumentando la complejidad del plano de gestión y las comunicaciones de red, lo que abre las infraestructura de este tipo a los ataques. Todo ello, obtiene mucha más complejidad al existir amplias diferencias entre los distintos proveedores, los diferentes modelos de servicio y los distintos despliegues.

¿Por qué la gestion de identidad es distinta en cloud?

La gestión de identidad y acceso siempre es complicada. En el kernel de todo esto, estamos mapeando alguna forma de entidad (persona, sistema, fragmento de código, etc.) a una identidad verificable asociada con varios atributos (que puede cambiar en función de las circunstancias actuales), tomando luego una decisión sobre lo que puede o no hacer basada en los derechos y los accesos que esta tiene. Incluso cuando controlas toda la cadena de ese proceso, administrar los distintos sistemas y la tecnologías de una manera segura y verificable, es un autentico desafío.
Uno de loss principales problema en cloud, es que no se está gestionando
la identidad y los acceso a los recursos, lo que puede complicar enormemente el proceso. Por ejemplo, imaginemos que tenemos que provisionar al mismo usuario en docenas o cientos de diferentes servicios Cloud. La federación es la herramienta principal utilizada para gestionar este problema, al crear relaciones de confianza entre las organizaciones y aplicarlas a través de tecnologías basadas en estándares.
La federación y otras técnicas y tecnologías IAM llevan conviviendo con nosotros desde hace mucho tiempo, pero el problema de ello es que se han creado parches y silos de IAM a medida que los departamentos TI han ido evolucionado. La adopción de la cloud, pero impulsa rápidamente a las organizaciones a confrontar y actualizar las mejores prácticas de gestión de identidad y accesos para lidiar con las diferencias Cloud, trayendo consigo varias oportunidades y desafíos.

La migración a la nube es una oportunidad para construir nuevas infraestructuras y procesos de arquitectura y estándares modernos. Se han producido enormes avances en identidad y accesos a lo largo de estos últimos años, sin embargo, la gran mayoria de organizaciones solo han podido implementarlos en casos de uso limitados debido principalmente a restricciones presupuestarias y de infraestructuras heredadas legacy. La adopción de computación en la nube, ya sea con un proyecto pequeño o una migración completa de nuestro CPD, significa la construcción de nuevos sistemas en nuevas infraestructuras que generalmente se diseñan utilizando las últimas prácticas de gestión de identidad. Pero no todo es tan sencillo, estos cambios también traen grandes desafíos consigo.
Moverse a una federación a escala con múltiples partes internas y externas puede ser complejo y difícil de manejar debido a la pura matemática de todas las variables involucradas. La determinación y aplicación de atributos y derechos en sistemas y tecnologías dispares acarrea problemas tanto de proceso como técnicos. Incluso las decisiones arquitectónicas fundamentales pueden verse obstaculizadas por la amplia variación en el soporte entre proveedores y plataformas en la nube.

Una visión general de la gestión de identidad

La IAM es una amplia área de práctica con su propio léxico que puede ser confusa para aquellos que no son especialistas en la materia, especialmente, dado que algunos términos tienen diferentes significados en diferentes contextos. Incluso el término "IAM" (Identity and acess manager) no es universal y a menudo se lo denomina Gestió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 por las razones correctas"

Antes de entrar en detalles, debemos conocer los términos más relevantes para continuar hablando de la gestión de identidad y accesos en Cloud:

• 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 una sola persona que tiene una identidad de trabajo, una identidad de redes sociales y una identidad personal. Por ejemplo, una sola entrada en un único servidor de directorio activo, sería una identidad.
• Identificador: El medio por el cual se puede afirmar una identidad. Para las identidades digitales, esto a menudo es un token criptográfico. En el mundo real, podría ser el DNI.
• Atributos: Facetas de una identidad. Los atributos pueden ser relativamente estáticos (como una unidad organizativa) o altamente dinámicos (dirección IP, dispositivo utilizado, si el usuario se autenticó con MFA, ubicación, etc.).
• Persona: La expresión de una identidad con atributos que indica el contexto. Por ejemplo, un desarrollador que inicia sesión en el trabajo y luego se conecta a un entorno Cloud 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 el contexto.
• Papel: Es un término confuso y usado en exceso que se usa de muchas maneras diferentes. Para nuestros propósitos, lo consideraremos similar a una persona, o como un subconjunto de una persona. Por ejemplo, un desarrollador dado en un proyecto, puede tener diferentes roles, tales como "superadmin" y "dev", que deberemos utilizar para tomar las decisiones de acceso.
• Autenticación: El proceso de confirmación de una identidad. Cuando se inicia sesión en un sistema, se debe presenta un nombre de usuario (el identificador) y una contraseña (un atributo al que nos referimos como un factor de autenticación). También conocido como Authn.
• Autenticación multifactorial (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 físico o virtual (OTP), 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 administración de acceso es el proceso de administrar el acceso a los recursos.
• Autorización: Permite un acceso de identidad a algo (por ejemplo, datos o una función). También conocido como Authz.
• Derecho: Asignar una identidad (incluidos roles, personajes y atributos) a una autorización. El derecho es lo que están autorizados a hacer, y para fines de documentación los mantenemos en una matriz de derechos o roles.
• Gestión de identidad federada: El proceso de afirmar una identidad en diferentes sistemas u organizaciones. Este es el habilitador clave de Single Sign On y también fundamental para administrar la gestión de identidad y accesos en Cloud.
• Fuente autoritativa: La fuente "raíz" de una identidad, como el servidor de directorio que administra las identidades de los empleados. Un claro ejemplo nos vendría de RRHH.
• Proveedor de identidad: La fuente de la identidad en la federación. El proveedor de identidad no es siempre la fuente autorizada, pero a veces puede confiar en la fuente autorizada, especialmente si se trata de un agente en el proceso.
• Parte que confía: El sistema que se basa en una afirmación de identidad de un proveedor de identidad.

Con estos y algunos terminos más que nos iran saliendo, trataremos los principales estándares para la Gestión de Identidad.

Estandares de Gestión de Identidad y Accesos Cloud

Existen bastantes estándares de gestión de identidad y acceso, y muchos de ellos se pueden usar en Cloud. A pesar de la amplia gama de opciones, la industria se está fortaleciendo en un conjunto básico que se ve con mayor frecuencia en varias implementaciones y que cuentan con el respaldo de la mayoría de los proveedores.

Hay algunos estándares que son prometedores pero que aún no se usan con tanta frecuencia.

Esta lista no refleja particularidades y tampoco incluye todas las opciones, pero si refleja las opciones que comúnmente son admitidas por una amplia gama de proveedores:

• Security Assertion Markup Language (SAML) 2.0: Es un estándar OASIS para la administración de identidades federadas que admite autenticación y autorización. Utiliza XML para realizar afirmaciones entre un proveedor de identidad y una parte dependiente. Las afirmaciones pueden contener declaraciones de autenticación, declaraciones de atributos y declaraciones de decisión de autorización. SAML es ampliamente compatible con la gran mayoria de herramientas empresariales y la Cloud, pero suele ser compleja de configurar inicialmente.
• OAuth: Es un estándar de IETF para la autorización que se usa ampliamente para servicios web. OAuth está diseñado para funcionar a través de HTTP y actualmente está en la versión 2.0, que no es compatible con la versión 1.0 por lo que significa que las implementaciones pueden no ser compatibles. Se usa 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. Está basado en HTTP con URLs usadas 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 muy comúnmente en los servicios al consumidor.

Hay otros dos estándares que no son tan comunes, pero que pueden ser útiles para la Cloud:

• eXtensible Access Control Markup Language (XACML): Es un estándar para definir los atributos basados en controles de acceso / autorizaciones. Es un lenguaje de políticas para definir controles de acceso en una Policy Enforcement Point y luego pasarlos a un punto de aplicación de políticas. Se puede usar con ambos SAML y OAuth ya que resuelve una parte diferente del problema, por ejemplo, decidir qué está permitido hacer en una entidad con un conjunto de atributos, a diferencia de manejar inicios de sesión o delegaciones de autoridad.
• System for Cross-domain Identity Management (SCIM): Es un estándar para intercambiar información de identidad entre dominios. Se puede usar para provisionar y desaprovisionar cuentas en sistemas externos y para intercambiar información de atributos.

1. El usuario envía su URL OpenID
2. IP y RP establecen secreto compartido
3. Navegador redirigido para obtener el token del proveedor
4. Solicitud de IP para el token del sitio
5. Inicia sesión si es necesario
6. Token devuelto al navegador
7. Token entregado al sitio solicitante

Todo esto no implica que no haya otras técnicas o estándares utilizados en la computación Cloud para identidad, autenticación y autorización. La mayoría de los proveedores Cloud, especialmente IaaS, tienen sus propios sistemas internos de IAM que pueden no utilizar ninguno de estos estándares o que pueden conectarse a una organización que utiliza estos estándares. Por ejemplo, la firma de solicitudes HTTP se usa muy comúnmente para autenticar API REST y las decisiones de autorización son administradas por políticas internas en el lado proveedor Cloud.
La firma de la solicitud aún podría admitir SSO a través de SAML, o la API podría estar completamente basada en OAuth, o usar su propio mecanismo de token. Todos se encuentran comúnmente, pero la mayoría de los proveedores en la nube de clase empresarial ofrecen soporte de federación de algún tipo.

Los conceptos esenciales al elegir un protocolo de identidad son:

• Ningún protocolo es la panacea que soluciona todos los problemas de identidad y control de acceso.
• Los protocolos de identidad deben analizarse en el contexto de casos de uso. Por ejemplo, el inicio de sesión único basado en el navegador, las claves API o la autenticación de móvil a Cloud podría llevar a distintos enfoques diferente.
• El supuesto operativo clave debería 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 "complicado" y resistir los ataques de los malos.

Administrar usuarios e identidades para infraestructuras Cloud

La parte de "identidad" de la gestión de identidad se centra en los procesos y las tecnologías para registrar, provisionar, propagar, gestionar y desprogramar identidades. Administrar identidades y provisionamiento de los mismos en los sistemas son problemas que la seguridad de la información ha estado abordando durante décadas. No hace muchoo, los administradores TI necesitaban provisionar individualmente a los usuarios en cada sistema interno diferente. Incluso hoy en día, con servidores de directorio centralizados y una variedad de estándares, el verdadero inicio de sesión único para todo es relativamente "extraño", donde los usuarios aún administran un conjunto de credenciales, aunque mucho más pequeño que en el pasado.

Los proveedores Cloud y los usuarios de la nube deben comenzar con la decisión fundamental sobre cómo administrar las identidades:

• Los proveedores Cloud casi siempre deben administrar identidades internas, identificadores y atributos para los usuarios que acceden directamente al servicio, a la vez que respaldan la federación para que las organizaciones no tengan que provisionar y administrar manualmente todos los usuarios en el sistema del proveedor y emitir credenciales separadas.
• Los usuarios de la nube deben decidir dónde quieren administrar sus identidades y qué modelos arquitectónicos y tecnologías desean admitir para integrarse con los proveedores.

Como usuario, puedes iniciar sesión en un proveedor y crear todas las identidades en el 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 tenga sentido mantener todas o algunas de las identidades con el proveedor de la nube aislado, como cuentas de administrador de respaldo para ayudar a resolver problemas con la conexión de identidad federada.

Al usar federación, el usuario Cloud debe determinar la fuente autorizada que contiene las identidades únicas que federarán, donde a menudo es un servidor de directorio interno.

La siguiente decisión sería si usar directamente la fuente autorizada como proveedor de identidad, usar una fuente de identidad diferente que se alimenta desde la fuente autorizada (como un directorio alimentado desde un sistema de recursos humanos), o integrar un intermediario de identidad.

Hay dos arquitecturas posibles, Free-form vs. hub and spoke :

• Forma libre: Los proveedores / fuentes de identidad interna (a menudo servidores de directorio) se conectan directamente a los proveedores Cloud.
• Hub and Spoke: Los proveedores / fuentes de identidad interna se comunican con un intermediario central o repositorio que luego sirve como el proveedor de identidad para la federación a los proveedores en la nube.

Pero 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 accedan a una VPN de red corporativa antes de acceder a los servicios en la nube.
• Dependiendo del servidor de directorio existente, y especialmente si tiene múltiples servidores de directorio en silos organizativos diferentes, la federación a un proveedor externo puede ser compleja y técnicamente difícil.

Los Identity broker manejan la federación entre los proveedores de identidad y las partes que confian (que pueden no ser siempre un servicio en la nube). Se pueden ubicar en el borde de la red o incluso en la nube para habilitar SSO web.
Los proveedores de identidad no necesitan ubicarse solo en las instalaciones, muchos proveedores Cloud ahora admiten servidores de directorio basados en la nube que admiten la federación internamente y con otros servicios Cloud. 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 identity broker y luego a un directorio alojado en Cloud, que luego sirve como un proveedor de identidad para otras conexiones federadas.

Después de determinar el modelo a gran escala, se requieren decisiones arquitectónicas y de proceso para cualquier implementación:

• Cómo administrar identidades para código de aplicación, sistemas, dispositivos y otros servicios. Se puede aprovechar el mismo modelo y los mismos estándares, o decidir tomar 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 a los servicios que se comunican con servicios, sistemas o dispositivos, o para componentes de aplicaciones dentro de una implementación IaaS.
• Definir el proceso de aprovisionamiento de identidad y cómo integrarlo en las implementaciones en la nube.
  También puede haber múltiples procesos de aprovisionamiento para diferentes casos de uso, aunque el objetivo debe ser tener un proceso lo más unificado posible.
  • Si la organización cuenta con un proceso de aprovisionamiento efectivo para la infraestructura tradicional, idealmente debería extenderse a implementaciones en la nube. Sin embargo, si los procesos internos existentes son problemáticos, la organización debería usar el cambio a la Cloud como una oportunidad para construir un proceso nuevo y más efectivo.
• Provisionamiento y soporte de implementaciones y proveedores individuales. Debe haber un proceso formal para agregar nuevos proveedores a la infraestructura de IAM. Esto incluye el proceso de establecer cualquier conexión de federación necesaria, así como:
  • Asignación de atributos (incluidos los roles) entre el proveedor de identidad y la parte que confía.
  • Habilitación de monitorización / registro requerido, incluida la supervisión de la seguridad relacionada con la identidad, como el análisis del comportamiento.(Ya hablamos de UEBA, en este aspecto)
  • Construyendo una matriz de derechos
  • Documentar cualquier escenario de desconexión / arreglo en caso de que haya una falla técnica de cualquier parte de la federación (u otras técnicas) utilizada para la relación.
  • Asegurar planes de respuesta a incidentes para potenciales tomas de cuentas, incluidas adquisiciones de cuentas privilegiadas.(El ejemplo de Indra)
• Implementar procesos de desprovisionamiento o cambio de titularidad para las identidades y el proveedor Cloud. Con federación, esto requiere trabajar 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 apoyar. Algunos proveedores solo admiten 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 las empresas deberán admitir una identidad federada y, muy probablemente, SAML.

Autenticación Cloud y credenciales

Autenticación es el proceso de probar o confirmar una identidad. En la autenticación de seguridad de la información se suele referir al acto de un usuario que inicia sesión, pero también se refiere esencialmente a cada vez 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 una autenticación sólida mediante múltiples factores. Esto es por dos razones:

• El amplio acceso a la red significa que los servicios en la nube siempre se acceden 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 la toma de posesión de la cuenta por parte de un atacante, ya que los ataques no están restringidos a la red local.
• Un mayor uso de la federación para Single Sign On significa que un conjunto de credenciales puede comprometer 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 la panacea, pero depender de un solo factor (contraseña) para los servicios Cloud es un riesgo muy alto. Al usar MFA con federación, el proveedor de identidad puede y debe pasar el estado de MFA como un atributo a la parte que confía.

Hay múltiples opciones para MFA(Como vemos en el enlace de Amazon), que incluyen:

• Los Hard tokens son dispositivos físicos que generan contraseñas de un solo uso para el ingreso humano o que deben conectarse a un lector. Estas son la mejor opción cuando se requiere el más alto nivel de seguridad.
• Los Soft tokens funcionan de manera similar a los Hard tokens, pero son aplicaciones de software que se ejecutan en un teléfono o computadora. Los Soft tokens también son una excelente opción, pero podrían verse comprometidos si el dispositivo del usuario se ve comprometido, y este riesgo debe considerarse en cualquier modelo de amenaza.
• Las Out-of-band Passwords son mensajes de texto o de otro tipo que se envían al teléfono de un usuario (generalmente) y luego se ingresan como cualquier otra contraseña de un solo uso 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, el biométrico es una protección local que no envía información biométrica al proveedor de la nube y, en cambio, es un atributo que se puede enviar al proveedor. Como tal, se debe tener en cuenta la seguridad y la propiedad del dispositivo local.

Gestión de derechos y accesos

Los términos titulación, autorización y control de acceso se superponen y se definen de manera diferente según el contexto.

Una autorización es un permiso para hacer algo: Acceder a un archivo o red, o realizar una determinada función, como una llamada 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). Comúnmente nos referimos a un mapa de estos derechos como una matriz de derechos. Los derechos a menudo se codifican como políticas técnicas de distribución y cumplimiento.

También utilizamos el término gestión de acceso como la parte "A" de IAM y se refiere a todo el proceso de definición, propagación y aplicación de autorizaciones.

La nube impacta en los derechos, las autorizaciones y la administración de acceso de múltiples maneras:

• Los proveedores y las plataformas Cloud, como cualquier otra tecnología, tendrán su propio conjunto de autorizaciones potenciales específicas para ellos. A menos que el proveedor admita XACML (algo raro en la actualidad), el usuario Cloud generalmente necesitará configurar los derechos dentro de la plataforma 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 las autorizaciones y configurarlas adecuadamente dentro de la plataforma.
• Las plataformas Cloud tienden a tener mayor soporte para el modelo de control de acceso basado en atributos (ABAC - Attribute-Based Access Control) para IAM, que ofrece mayor flexibilidad y seguridad que el modelo de control de acceso basado en roles (RBAC - Role-Based Access Control). RBAC es el modelo tradicional para imponer autorizaciones y se basa en lo que a menudo es un único atributo (un rol definido). ABAC permite decisiones más detalladas y contextuales mediante la incorporación de múltiples atributos, como el rol, la ubicación, el método de autenticación y más.
  • ABAC es el modelo preferido para la administración de acceso Cloud.
• Al usar la federación, el usuario de la nube es responsable de asignar los atributos, incluidos los roles y grupos, al proveedor Cloud y asegurarse de que se comunican correctamente durante la autenticación.
• Los proveedores de la nube son responsables de admitir atributos granulares y autorizaciones para habilitar ABAC y una seguridad efectiva para los usuarios Cloud.

Gestión de usuarios privilegiados

En términos de controlar el riesgo, pocas cosas son más esenciales que la administración de usuarios privilegiados. Los requisitos mencionados anteriormente para una autenticación sólida deben ser una consideración importante para cualquier usuario con privilegios. Además, se debe implementar la recodificación de la cuenta y la sesión para aumentar la responsabilidad y la visibilidad de los usuarios con privilegios.

En algunos casos, será beneficioso para un usuario privilegiado el iniciar sesión a través de un sistema separado y estrictamente controlado que utilize niveles más altos de seguridad para el control de credenciales, certificados digitales, puntos de acceso físicos y lógicamente separados, y/o maquinas de salto.

Recomendaciones Identidad y Acceso Cloud

• Las organizaciones deben desarrollar un plan integral y formal ademas de procesos para gestionar identidades y autorizaciones con servicios Cloud.
• Cuando se conecte a proveedores externos de la nube, debemos usar la federación, si es posible, para extender la administración de identidad existente. Tratando de minimizar los silos de identidades en los proveedores que no están vinculados a las identidades internas.
• Debemos considerar el uso de intermediarios de identidad cuando nos corresponda.
• Los usuarios Cloud son responsables de mantener el proveedor de identidades y definir identidades y atributos.
  • Estos deben basarse en una fuente autorizada.
  • Las organizaciones distribuidas deben considerar el uso de servidores de directorio hospedados en Cloud cuando las opciones disponibles no esten o no cumplan con los requisitos.
• Los usuarios Cloud deben usar de forma predeterminada MFA para todas las cuentas cloud externas y enviar el estado de MFA como un atributo cuando usan la autenticación federada.
• Las identidades privilegiadas siempre deben usar MFA.
• Desarrollar una matriz de derechos para cada proveedor y proyecto Cloud, con énfasis en el acceso a la metaestructura y/o plano de gestión.
• Traducir matrices de derechos a políticas técnicas cuando sean compatibles con el proveedor o la plataforma Cloud.
• Es preferible ABAC sobre RBAC para computación Cloud.
• Los proveedores de nube deben ofrecer tanto identidades internas como federación usando estándares abiertos.
• No hay protocolos mágicos: debemos elejir los casos de uso y las restricciones primero y posteriormente elegir los protocolo correctos.