Comparación de AWS, Azure y GCP (III): Identidad y Acceso

Continuamos el recorrido comparativo después de haber visto

1. Comparación de AWS, Azure y GCP (I): Conceptos generales
2. Comparación de AWS, Azure y GCP (II): Redes

En este tercer capítulo de la serie voy a tratar diferentes conceptos y servicios relacionados con la gestión de la identidad y del acceso.

Gestión de la identidad y del acceso

Cuando se empieza a trabajar en el ámbito de un entorno cloud, un aspecto que cobra especial importancia es la necesidad de controlar el acceso tanto a la propia plataforma cloud, como a los recursos aprovisionados en la plataforma, también es necesario controlar el acceso a los activos desplegados. Este acceso podrá ser realizado por entidades que pueden ser personas, organizaciones, aplicaciones, dispositivos u otros recursos.

El control se realiza mediante la identificación (autenticación), y el otorgamiento (autorización) para poder realizar aquellas acciones para las que se le conceden permiso. La gestión de la identidad consiste en comprobar que la entidad que se presenta en la plataforma es quien dice ser, para llevar a cabo la gestión de la identidad es necesario dotar a las entidades de una identidad y gestionar el acceso de dicha entidad. La gestión de acceso permite regular las operaciones permitidas dentro del entorno de la plataforma, y mantener la auditoria necesaria de dichos accesos. Para ello es necesario otorgar a la entidad los permisos necesarios que le darán autorización para realizar las acciones que se le permiten.

Otro aspecto relevante en relación con la gestión de la identidad y del acceso es el seguimiento de las acciones realizadas. Por lo tanto, el registro y la supervisión son partes esenciales.

Para llevar a cabo este control las plataformas ofrecen soluciones de gestión de identidad y accesos (Identity and Access Management), que permiten definir quien puede acceder, a que puede acceder, y que puede hacer durante ese acceso. La solución ofrecida diverge entre las tres plataformas que estoy comparando ofreciendo diferentes capacidades, restricciones y terminología.

Por lo general, los sistemas IAM proporcionan la siguiente funcionalidad básica:

• Administración de identidades: proceso de creación, almacenamiento y administración de información de identidad.
• Federación de identidades: puede permitir que los usuarios que ya tengan contraseñas en otro lugar (por ejemplo, en la red empresarial o con un proveedor de identidades sociales o proveedor de Internet) obtengan acceso al sistema.
• Creación y eliminación de usuarios: el proceso de creación y administración de cuentas de usuario, que incluye especificar qué usuarios tienen acceso a qué recursos y asignar permisos y niveles de acceso.
• Autenticación de usuarios: autentica un usuario, máquina o componente de software al confirmar que efectivamente son quién o lo que dicen ser.
• Autorización de usuarios: la autorización garantiza que se concede a un usuario el nivel exacto y el tipo de acceso a una herramienta a la que tiene derecho de acceso.
• Control de acceso: el proceso para determinar quién o qué tiene acceso a los recursos. Esto incluye la definición de roles y permisos de usuario, así como la configuración de mecanismos de autenticación y autorización. Los controles de acceso regulan el acceso a sistemas y datos.
• Informes y supervisión: genere informes después de las acciones realizadas en la plataforma (como el tiempo de inicio de sesión, los sistemas a los que se accede y el tipo de autenticación) para garantizar el cumplimiento y evaluar los riesgos de seguridad.

A continuación voy a analizar las soluciones ofrecidas en cada caso, es necesario tener en mente la estructura de cada una de las plataformas por lo que se deberá recordar lo que abordé en el primer capítulo de la serie Comparación de AWS, Azure y GCP (I): Conceptos generales.

En cualquier caso se pueden usar IAM de terceros, el ámbito de este artículo son las soluciones ofrecidas por las propias plataformas.

Identidad

La identidad se refiere a quién puede autenticarse (iniciar sesión) en una cuenta, aplicación o recurso. Para permitir un acceso, se debe asegurar de que la entidad que intenta autenticarse sea quien dice ser. La autenticación puede implementarse utilizando tecnologías como Single Sign-On (SSO) y Multi-Factor Authentication (MFA) para aumentar la seguridad.

La identidad a grandes rasgos es la información relacionada con la entidad, información necesaria para poder identificar y autenticar a esta entidad cuando se persone en la plataforma o en algún activo. De una forma u otra las diferentes soluciones gestionan un directorio de identidades.

Después de que una entidad se autentica, se necesita la gestión de acceso ya que por el hecho de que una entidad se haya autenticado con éxito no significa que deba tener acceso completo a todos los recursos disponibles.

A alto nivel hay tres tipos de identidades:

• Las identidades humanas representan a personas como empleados y usuarios externos (clientes, consultores, proveedores y asociados).
• Las identidades de carga de trabajo representan cargas de trabajo de software, como una aplicación, un servicio, un script o un contenedor.
• Las identidades de dispositivo representan dispositivos, como teléfonos móviles, cajeros automáticos, sensores de IoT y dispositivos administrados de IoT. Las identidades de dispositivo son distintas de las identidades humanas.

Gestión de la identidad (autenticación)

A continuación detallo el funcionamiento de los diferentes servicios IAM proporcionados por las tres plataformas. También ofrecen servicios específicos para la gestión de clientes (terceros que deben acceder a las aplicaciones desplegadas) estas soluciones Customer Identity and Access Management, difieren de los IAM entre otras cosas en que generalmente no se permite el acceso a los recursos de la plataforma, únicamente se puede acceder a las aplicaciones para las que se dispone de permisos. Durante el análisis diferenciare los dos tipos de identidades necesitan acceso: usuarios, es decir, identidades humanas, y servicios, es decir, máquinas, otros servicios o aplicaciones.

AWS

AWS ofrece un directorio de usuarios que está integrado con sus servicios de identidad global, y su «cuenta raíz» (que es la cuenta de nivel superior para la organización en la que trabaja) puede ser la misma cuenta que usa para crear la cuenta de AWS.

AWS dispone de tres tipos de identidades, usuarios (raíz y de IAM), grupos de usuarios y roles.

Tipo de Identidad	Descripción
Usuario raíz	Un usuario raíz es aquel con el que se crea una cuenta de AWS, tiene acceso completo a todos los recursos y Servicios de AWS de la cuenta. Para acceder con este usuario se utiliza el email y la contraseña que utilizó para crear la cuenta.
Usuario de IAM	Un usuario de IAM es una identidad de la cuenta de AWS que dispone de permisos específicos para una sola persona, recursos o aplicación, generalmente el acceso para un solo usuario de IAM está limitado al nivel de la cuenta. A diferencia de GCP y Azure, AWS no distingue entre «cuentas de servicio» y usuarios de IAM. Cada usuario puede tener ser de tipo no interactivo sin acceso a la consola, o interactivo con acceso habilitado a la consola o ambas.
Grupo de usuarios de IAM	Un grupo de usuarios de IAM es una identidad que especifica un conjunto de usuarios de IAM. No puede iniciar sesión como grupo. Los grupos permiten especificar permisos para varios usuarios a la vez. Los grupos facilitan la administración de los permisos de grandes conjuntos de usuarios.
Rol de IAM	Un rol de IAM es una identidad de la Cuenta de AWS que dispone de permisos específicos. Es similar a un usuario de IAM, pero no está asociado a una determinada persona. Un rol actúa como una capa de abstracción entre políticas y cuentas. Permite agrupar las políticas en roles y luego asignar roles a grupos y usuarios según sea necesario. Un ejemplo sería la organización de políticas por servicio, y luego adjuntar el servicio a los grupos que trabajan con él en lugar de tener que rastrear cada política en todos los grupos y usuarios potenciales que la necesitan.

Una característica única de AWS IAM es que las cuentas creadas en la organización (no a través de la federación) solo se pueden usar dentro de esa organización. Esto contrasta con GCP y Azure. Como aspecto positivo, cada organización es autónoma. Como aspecto negativo, los usuarios pueden terminar con múltiples conjuntos de credenciales que necesitan administrar para acceder a diferentes organizaciones.

Para la identificación de clientes AWS ofrece un servicio específico AWS Cognito, plataforma de identidad para aplicaciones web y móviles. Es un directorio de usuarios, un servidor de autenticación y un servicio de autorización para los tokens y credenciales de AWS de acceso de OAuth 2.0.

Sus principales características son:

Administración de identidades
Autorregistro	Los usuarios pueden registrarse con un correo electrónico, número de teléfono o nombre de usuario para su aplicación. El proceso de autorregistro permite a los usuarios ver y actualizar sus datos de perfil, incluidos los atributos personalizados.
Almacén de identidades (grupos de usuarios de Amazon Cognito)	Amazon Cognito proporciona un almacén de identidad seguro. Es un repositorio de usuarios basado en API.
Opciones de migración	Los usuarios pueden migrar a Amazon Cognito mediante una importación por lotes (importación de CSV) o una migración Just In Time (trigger Lambda).
Multi-Tenant y aislamiento de usuarios	Amazon Cognito permite interacciones B2B compatibles con multi tenant
Autenticación de usuarios
Aspecto personalizable	Proporciona una interfaz de usuario integrada y personalizable. Se puede usar SDK de Android, iOS y JavaScript con Amazon Cognito para añadir páginas de registro e inicio de sesión de usuarios.
Autenticación multifactor (MFA)	Permite habilitar MFA en un grupo de usuarios de Amazon Cognito. Los usuarios pueden verificar sus identidades mediante SMS o un generador de contraseña temporal de un solo uso (TOTP).
Federación	Permite a los usuarios iniciar sesión a través de proveedores de identidad social, como Apple, Facebook, Google y Amazon, y proveedores de identidad empresarial a través de SAML y OIDC. Una vez que sus usuarios inician sesión en Amazon Cognito se puede usar OAuth/OIDC para acceder a los recursos federados.
Autenticación personalizada	Se puede crear un flujo de autenticación personalizado que utiliza funciones de Lambda para autenticar usuarios en función de uno o varios ciclos de desafío-respuesta.
Personalización de los flujos de trabajo del grupo de usuarios con trigger Lambda	Se pueden utilizar triggers Lambda para personalizar el comportamiento de Cognito. También se pueden utilizar triggers Lambda para personalizar los mensajes que se envían a los usuarios o para integrarse con proveedores de correo electrónico y SMS de terceros.
Control de acceso
Integración de última milla con aplicaciones	AWS Application Load Balancer y Amazon API Gateway ofrecen puntos de cumplimiento de políticas integrados que brindan acceso basado en tokens y scopes de Amazon Cognito.
Acceso a los recursos de AWS	Amazon Cognito, proporciona acceso de inicio de sesión único a los recursos de AWS
Autenticación de máquina a máquina	Proporciona autenticación de máquina a máquina.
Experiencia del cliente
Comunicación con el cliente	Permite lanzar campañas de contacto con los clientes y realizar un seguimiento del compromiso con Amazon Pinpoint.
Agilidad comercial amplificada	AWS Amplify es un conjunto de herramientas y características creadas específicamente para que los desarrolladores web y móviles de frontend puedan crear aplicaciones completas en AWS.
Extensibilidad	Proporciona un conjunto de enlaces y extensiones para personalizar completamente los flujos de autenticación, registro y migración de usuarios. El SDK de Amazon Cognito está disponible con Java, C++, PHP, Python, Golang, Ruby, .NET y JavaScript.
Seguridad
Protección contra vulnerabilidades web mediante AWS WAF	Ofrece funciones avanzadas de detección de bots.
Protección de credenciales comprometidas	Puede detectar y evitar, en tiempo real, la reutilización de credenciales comprometidas cuando los usuarios se registran, inician sesión o cambian su contraseña. Cuando Amazon Cognito detecta que el usuario ha especificado credenciales que se han visto comprometidas en otro sitio, le solicita que cambie la contraseña..
Conformidad	Se alinea con múltiples requisitos de seguridad y cumplimiento, incluidos los de organizaciones altamente reguladas, como empresas de atención médica y comerciantes. Amazon Cognito cumple los requisitos de HIPAA, PCI DSS, SOC, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018 e ISO 9001.
Autenticación adaptativa basada en el riesgo	Cuando Amazon Cognito detecta una actividad de inicio de sesión inusual, como intentos desde nuevas ubicaciones y dispositivos, asigna una puntuación de riesgo a la actividad y permite elegir solicitar a los usuarios una verificación adicional o bloquear la solicitud de inicio de sesión.

Azure

En Azure las identidades pueden provenir de varios lugares dentro de la familia de productos de Microsoft, incluido Office 365. El núcleo de Azure es el  servicio Azure AD, que contiene información de configuración de aplicaciones y entidades.  Las entidades que usan las aplicaciones y otros servicios no interactivos para acceder a los recursos dentro de Azure se denominan entidades de servicio. Azure permite que las cuentas de usuario cambien entre varios directorios sin necesidad de volver a iniciar sesión. Cada directorio puede tener sus propias suscripciones sin tener que administrar varios conjuntos de credenciales.

Conceptos relacionados con Azure AD:

Concepto	Descripción
Inquilino (tenant)	Un inquilino (tenant) tiene un directorio de Azure AD predeterminado al que está asociada, que es una instancia de Azure AD. Este directorio contiene los usuarios y grupos que accederán a cada uno de los servicios que la empresa ha comprado. Este directorio predeterminado se conoce como inquilino. Un inquilino representa la organización y el directorio predeterminado asignado.
Subscripcion	La suscripción en Azure es al mismo tiempo una entidad de facturación y un límite de seguridad. Los recursos se asocian con una sola suscripción. Cada suscripción tiene también un solo propietario de cuenta responsable de los cargos en los que incurren los recursos de esa suscripción. Una suscripción está asociada con un único directorio de Azure AD. Varias suscripciones pueden confiar en el mismo directorio, pero una suscripción confía solo en un único directorio.
Azure AD User	Un usuario de Azure es una representación de algo que se administra mediante Azure AD.
Azure AD Group	Un grupo de Azure permite conceder acceso y permisos a un grupo de usuarios en lugar de hacerlo para cada usuario individual. Existen tres tipos de pertenencia de usuarios a grupos: Asignado: permite agregar usuarios específicos como miembros de un grupo y que tengan permisos exclusivos. Usuario dinámico: permite usar reglas de pertenencia dinámicas para agregar y quitar miembros automáticamente. Dispositivo dinámico: permite usar reglas de grupo dinámico para agregar y quitar dispositivos automáticamente.
Cuentas de servicio	Hay dos tipos de cuentas de servicio nativas para Azure AD: identidades administradas (Managed Identity) y entidades de servicio (Service Principal)
Entidades de Servicio (Service Principal)	Las entidades de servicio es una identidad para una aplicación.
Identidades Administradas (Managed Identity)	Las identidades administradas son otra característica de Azure AD que actúa de forma similar a las entidades de servicio de una aplicación. Proporcionan identidades para los recursos de Azure y permiten una manera sencilla de que los servicios que admiten la autenticación de Azure AD compartan credenciales.

Como solución CIAM Azure ofrece Azure AD B2C. Se basa en la misma tecnología que Azure AD, pero para un propósito diferente. Azure AD B2C permite crear aplicaciones orientadas al cliente y, a continuación, permite que cualquiera se suscriba a esas aplicaciones sin restricciones en la cuenta de usuario.

Las principales características de Azure Active Directory B2C son:

Solución de identidad de marca personalizada	Permite personalizar toda la experiencia del usuario con su marca para que se fusione sin problemas con las aplicaciones web y móviles.
Acceso de inicio de sesión único con una identidad proporcionada por el usuario	Utiliza protocolos de autenticación basados en estándares, como OpenID Connect, OAuth 2.0 y el Lenguaje de marcado de aserción de seguridad (SAML). Se integra con la mayoría de las aplicaciones modernas y el software comercial.
Integración con almacenes de usuarios externos	Permite delegar en una base de datos externa de administración de relaciones con el cliente (CRM) o de fidelización de clientes como el origen de veracidad para los datos de los clientes.
Generación de perfiles progresiva	Permite a los clientes completar rápidamente la primera transacción mediante la recopilación de una cantidad mínima de información. Posteriormente, se recopilarán gradualmente más datos de perfil del cliente en los inicios de sesión futuros.
Comprobación y prueba de identidades de terceros	Facilita la comprobación de identidades y su prueba mediante la recopilación de datos de usuario y, a continuación, pasarlos a un sistema de terceros para realizar la validación, la puntuación de confianza y la aprobación para la creación de cuentas de usuario.
Federación	Permite que los usuarios inicien sesión en su aplicación con las credenciales de proveedores de identidades de redes sociales o de empresa. Azure AD B2C puede federarse con proveedores de identidades que admitan los protocolos OAuth 1.0, OAuth 2.0, OpenID Connect y SAML. Por ejemplo, Facebook, cuenta Microsoft, Google, Twitter y AD FS.
Dominio personalizado	Se puede personalizar el dominio de Azure AD B2C en los URI de redireccionamiento para su aplicación.
Localización	La personalización del idioma en Azure AD B2C permite albergar distintos idiomas a fin de satisfacer las necesidades de los clientes. Microsoft proporciona las traducciones de 36 idiomas, pero el usuario también puede proporcionar sus propias traducciones en cualquier idioma.
Autenticación multifactor (MFA)	ayuda a proteger el acceso a los datos y las aplicaciones de forma sencilla para los usuarios. Ofrece seguridad adicional al exigir una segunda forma de autenticación.

GCP

GCP depende de los grupos de Google y de la infraestructura de cuentas de Google para la gestión de usuarios el servicio ofrecido como IAM es Cloud Identity. Las identidades de GCP pueden provenir de casi cualquier parte del ecosistema de Google, desde usuarios de G Suite hasta cuentas de consumidores de Google y cuentas de servicios no interactivos. Si es usuario de G Suite, tiene acceso a los servicios de federación. Si no es usuario de G Suite, la funcionalidad para federarse con un proveedor de autenticación externo se denomina Cloud  Identity Domain.

Cuando un usuario con una cuenta de Google Workspace o Cloud Identity crea un proyecto de Google Cloud, se crea automáticamente una organización, como vimos en el primer artículo de la serie es el contenedor de las carpetas , proyectos y recursos que se estructuran juntos en una jerarquía.

Los usuarios se identifican de forma única por su correo electrónico y se dividen en unidades organizativas (OU), lo que es útil para establecer políticas como MFA y acceso a aplicaciones. Sin embargo, las unidades organizativas se usan para gestionar el acceso a los recursos de Google. El mecanismo utilizado para administrar el acceso de los usuarios a los recursos de GCP es el de grupo.

Los grupos son muy diferentes de las unidades organizativas, las unidades organizativas son rígidas y un usuario solo puede pertenecer a una de ellas, pero un usuario puede pertenecer a varios grupos simultáneamente.

Las cuentas de servicio permiten que otras entidades, como los recursos, puedan acceder a otros recursos.

Los diferentes conceptos de GCP dentro de la identificación son:

Concepto	Descripción
Unidad organizativa	La unidad organizativa es un subcontenedor para cuentas de usuario que te permite segmentar las cuentas de usuario definidas en la cuenta de Cloud Identity o Google Workspace en conjuntos inconexos para facilitar su administración. Las unidades organizativas se organizan de forma jerárquica.
Cuenta de administrador avanzado	La cuenta de administrador avanzado de Google Workspace o Cloud Identity permite configurar el recurso de organización de Google Cloud. Las cuentas de administrador avanzado tienen permisos administrativos irrevocables.
Identidad	Una identidad es un nombre que identifica de forma exclusiva a la entidad que interactúa con un servicio de Google. Google usa direcciones de correo electrónico para este fin. La dirección de correo electrónico de una entidad se considera su identidad de Google.
Cuenta de usuario	Una cuenta de usuario es una estructura de datos que realiza un seguimiento de los atributos, las actividades y las configuraciones que se deben aplicar cuando una identidad determinada interactúa con un servicio de Google. La relación entre las cuentas de usuario y las identidades no es fija. Puedes cambiar la dirección de correo electrónico principal de una cuenta de usuario, que asocia una identidad diferente con el usuario.
Grupo	Un grupo permite agrupar a varios usuarios. Se pueden usar grupos a fin de administrar una lista de distribución o para aplicar un control de acceso o una configuración comunes a varios usuarios. Cloud Identity y Google Workspace identifican grupos por dirección de correo electrónico, por ejemplo, billing-admins@example.com. Al igual que la dirección de correo electrónico principal del usuario, la dirección de correo electrónico del grupo debe usar uno de los dominios principales, secundarios o de alias de la cuenta de Cloud Identity o de Google Workspace. No es necesario que la dirección de correo electrónico corresponda a un buzón, a menos que el grupo se use como lista de distribución. Un grupo puede tener las siguientes entidades como miembros: Usuarios (usuarios administrados o cuentas personales). Otros grupos. Cuentas de servicio A diferencia de una unidad organizativa, los grupos no actúan como un contenedor: Un usuario o grupo puede ser miembro de cualquier cantidad de grupos, no solo de uno. Borrar un grupo no borra ninguno de los usuarios o grupos miembros.
Cuenta de servicio	Una cuenta de servicio (o cuenta de servicio de Google Cloud) es un tipo especial de cuenta de usuario destinada a aplicaciones y otros tipos de usuarios de máquinas. Cada cuenta de servicio pertenece a un proyecto de Google Cloud. Las cuentas de servicio también usan una dirección de correo electrónico como su identidad, pero, a diferencia de las cuentas de usuario administradas, la dirección de correo electrónico siempre usa un dominio de Google, como developer.gserviceaccount.com.

La solución CIAM proporcionada por GCP es Identity Platform.

Las características clave son:

Autenticación como servicio	Ofrece un servicio de autenticación directo y personalizable para el registro y acceso de los usuarios. Gracias a diversas opciones de SDKs para apps (Android, iOS y Web) y de administración (Node.js, Java, Python y muchos más), facilita las actividades administrativas y de desarrollo.
Amplia compatibilidad con protocolos	Compatible con varios métodos de autenticación (SAML, OIDC, correo electrónico y contraseña, redes sociales, teléfono y autenticación personalizada)
Multiusuario	Admite la creación de sistemas aislados de usuarios y configuraciones en una sola instancia. Estos sistemas aislados podrían representar a diferentes clientes, unidades de negocios, filiales o alguna otra división.
Protección inteligente de cuentas	Usa la inteligencia y los indicadores de amenazas de Google para ayudar a detectar cuentas de usuario vulneradas.

Gestión del acceso (autorización)

Los tres proveedores implementan alguna variante de Control de Acceso Basado en Roles (RBAC) cada entidad asume roles que son agrupaciones de políticas que definen permisos de acceso, y se basan en el principio de privilegios mínimos concepto utilizado en seguridad de la información por el cual solo se reducen los permisos otorgando exclusivamente aquellos que son necesarios para llevar a cabo con éxito una tarea.

Para facilitar la gestión del acceso es recomendable disponer de grupos (de usuarios) con reglas y privilegios bien definidos en diferentes niveles de granularidad. De esta forma, no se tienen que asignar permisos a cada nuevo usuario, sino agregarlos al grupo apropiado que ya tiene los permisos correctos.

Los roles son un concepto central en RBAC, donde las identidades de las entidades, de forma predeterminada, no tienen acceso ni autorización para un recurso determinado. Mediante algún mecanismo de autenticación, las entidades «asumirán» un rol, donde vienen todas las políticas de acceso y autorización que están vinculadas al rol.

La configuración de la política se define mediante el lenguaje JSON por las tres plataformas.

AWS

En AWS, el documento de permisos, denominado Política de IAM, incluye los detalles de los permisos y los recursos en el mismo archivo JSON. Esto significa que no hay desacoplamiento de los recursos a los que se otorga acceso a la identidad y las acciones que los permisos permiten que la identidad realice, ambos se administran en un solo documento.

En AWS, los roles son la forma principal de los mecanismos de identidad. Las políticas de IAM denominadas políticas de confianza de rol en AWS se utilizan para controlar qué entidades (podría ser un usuario o un servicio) pueden asumir roles. Los permisos a los recursos se asignan a una identidad a través de una política.

Hay varios tipos de políticas que se pueden aplicar en AWS. Se pueden crear políticas personalizadas o usar las que ofrece AWS. Los diferentes tipos de políticas existentes son:

1. Basado en identidad (adjunto a identidades de IAM)
2. Basado en recursos (adjunto a los recursos)
3. Límites de permisos (definen el nivel más alto de permisos que puede aplicar una política basada en identidad)
4. Políticas de control de servicios de la organización (utilizadas para definir el nivel más alto de permisos que una política basada en la identidad o en los recursos puede aplicar para los miembros de la cuenta de una organización)
5. Listas de control de acceso o ACL (son similares a las políticas basadas en recursos y definen qué principales pueden acceder a un recurso)
6. Políticas de sesión (limitan los permisos otorgados por políticas basadas en identidad en una sesión de AWS CLI o API)

A continuación se indican los diferentes elementos de las políticas de AWS, ver el detalle y explicación de a gramática en https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/reference_policies_grammar.html

Nombre	Descripción
Version	Especifica las reglas de sintaxis que se utilizarán para procesar una política. Admite los siguientes valores: 2012-10-17. Esta es la versión actual del lenguaje de la política. 2008-10-17. Esta era una versión anterior del lenguaje de la política.
Id	Identificador opcional para la política.
Statement	Elemento principal y obligatorio de una política. Puede contener una declaración única o una matriz de declaraciones individuales. Cada bloque de instrucción individual debe encerrarse entre llaves { }. Para declaraciones múltiples, la matriz debe estar encerrada entre corchetes [ ].
Sid	(ID de declaración) es un identificador opcional para la declaración de política. Se puede asignar un Sid a cada declaración en una matriz de declaraciones.
Effect	Es obligatorio y se utiliza para especificar si la declaración da como resultado un permiso o una denegación explícitos. Los valores válidos son Allow y Deny.
Principal	Se utiliza en una política basada en recursos para especificar la entidad de seguridad a la que se le permite o deniega el acceso a un recurso.
NotPrincipal	Permite denegar el acceso a todas las entidades principales excepto el usuario de IAM, el usuario federado, el rol de IAM, la cuenta de AWS. No se puede utilizar en una política basada en identidad de IAM ni en una política de confianza de roles de IAM.
Action	describe la acción o acciones específicas que se permitirán o denegarán. Ejemplos: «Action»: «sqs:SendMessage» «Action»: «ec2:StartInstances» «Action»: «s3:GetObject» «Action»: [ «sqs:SendMessage», «sqs:ReceiveMessage», «ec2:StartInstances», «iam:ChangePassword», «s3:GetObject» ]
NotAction	Elemento que coincide explícitamente con todo excepto con la lista de acciones especificada. Ejemplos: Permite a los usuarios acceder a todas las acciones en todos los servicios de AWS excepto IAM. «Effect»: «Allow», «NotAction»: «iam:*», «Resource»: «*»
Resource	Especifica el objeto u objetos que la instrucción abarca.
NotResource	Coincide explícitamente con todos los recursos excepto los especificados.
Condition	Permite especificar condiciones que se aplican cuando la política surte efecto.

A continuación se muestra una política basada en identidad que permite a los usuarios de Amazon Cognito acceder a objetos de un bucket de S3 específico.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListYourObjects",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": [
        "arn:aws:s3:::bucket-name"
      ],
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
          ]
        }
      }
    },
    {
      "Sid": "ReadWriteDeleteYourObjects",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject",
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
      ]
    }
  ]
}

Cuando se haya creado una política se puede asignar directamente a usuarios individuales, grupos de usuarios, roles o recursos.

Azure

En Azure la lista de permisos está desvinculada de los recursos. Los recursos para los que se aplicaría una asignación de permisos se denominan «alcance». Además, debido a que Azure sigue los permisos de RBAC, permite la herencia, si un rol tiene un alcance superior, tiene un conjunto más amplio de permisos.

El concepto Azure Policy es ligeramente diferente al concepto política de AWS y GCP y se centra en las propiedades de los recursos durante la implementación y para los recursos ya existentes. Como ejemplo, se puede emitir una política para garantizar que los usuarios solo puedan implementar máquinas virtuales de la serie DS dentro de un recurso específico si el usuario tiene permiso para implementar las máquinas virtuales.

Una definición de roles es una recopilación de permisos. Suele denominarse un rol. Una definición de roles enumera las acciones que se pueden realizar, por ejemplo, de lectura, escritura y eliminación. Los ejemplos de control de acceso basado en roles (RBAC) incluyen:

• Permitir a un usuario la capacidad de administrar solo máquinas virtuales en una suscripción y no la capacidad de administrar redes virtuales
• Permitir que un usuario administre todos los recursos, como máquinas virtuales, sitios web y subredes, dentro de un grupo de recursos específico
• Permitir que una aplicación acceda a todos los recursos en un grupo de recursos

Azure también tiene un modelo único para asignar permisos que se ubica entre GCP y AWS en términos de flexibilidad. Hay bastantes roles estándar disponibles en Azure.

En la siguiente tabla se muestra la información necesaria para definir un rol:

Nombre	Descripción
Id	Identificador único del rol, asignado por Azure.
IsCustom	True si se trata de un rol personalizado, False si es un rol integrado.
Description	Descripción del rol que se puede leer.
Actions []	Permisos permitidos; * indica todos.
NotActions []	Permisos denegados.
DataActions []	Permisos específicos permitidos según se aplican a los datos, por ejemplo, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
NotDataActions []	Permisos específicos denegados según se aplican a los datos.
AssignableScopes []	Ámbitos en los que se aplica este rol; / indica global, pero puede llegar a un árbol jerárquico.

A continuación se muestra la definición del rol Contributor

{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [""],
"NotActions": ["Microsoft.Authorization//Delete","Microsoft.Authorization/*/Write","Microsoft.Authorization/elevateAccess/Action"],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": ["/"]
}

GCP

GCP también separa los permisos de los recursos en el documento llamado «rol». Al igual que en Azure, el documento de roles no enumera los recursos. Al colocar los roles en un proyecto o carpeta de GCP, los permisos enumerados se aplicarán a todos los recursos, los recursos para los que se aplica una asignación de permisos se llama ámbito, que puede ser, por ejemplo, un recurso o un contenedor de recursos. Debido a que GCP sigue los permisos de RBAC, permite la herencia, si un rol tiene un ámbito más alto, tiene un conjunto más amplio de permisos.

Como vimos en el primer artículo, GCP utiliza el concepto de proyecto. Cada proyecto tiene su propia facturación y su propia configuración de IAM, y todos los permisos se aplican a todos los recursos dentro de ese proyecto específico. Una cuenta de usuario puede ser miembro de varios proyectos y tener un rol diferente en cada proyecto. Se pueden crear y definir roles personalizados que se pueden asignar a usuarios y grupos.

En GCP, los permisos no se pueden aplicar directamente a las entidades, deben asignarse a roles y, por lo tanto, recibir todos los permisos permitidos para ese rol.

Contenido de la definición de un rol:

Concepto	Descripción
Título	Un nombre legible para el rol. El nombre del rol se usa para identificar el rol en la consola de Google Cloud.
Nombre	Un identificador para el rol en uno de los siguientes formatos: Roles predefinidos: roles/SERVICE.IDENTIFIER Roles personalizados a nivel de proyecto: projects/PROJECT_ID/roles/IDENTIFIER Roles personalizados a nivel de la organización: organizations/ORG_ID/roles/IDENTIFIER El nombre del rol se usa para identificar el rol en permitir políticas.
ID	Es un identificador único para el rol. Para los roles básicos y predefinidos, el ID es el mismo que el nombre del rol. Para los roles personalizados, el ID es todo lo que se encuentra después de roles/ en el nombre del rol.
Descripción	Una descripción legible del rol.
Etapa	La etapa del rol en el ciclo de vida de lanzamiento, como ALPHA, BETA o GA.
Permisos	Los permisos incluidos en el rol. Los permisos se usan para permitir a los principales realizar acciones específicas en los recursos de Google Cloud. Cuando otorgas un rol a un principal, esta obtiene todos los permisos del rol. Los permisos tienen el siguiente formato: ICE.RESOURCE.VERB Por ejemplo, el permiso compute.instances.list permite que un usuario enumere las instancias de Compute Engine que posee y compute.instances.stop permite que un usuario detenga una VM.
ETag	Un identificador de la versión del rol que ayuda a evitar que las actualizaciones simultáneas se reemplacen entre sí. Los roles básicos y predefinidos siempre tienen el AA== de ETag. Los ETag para los roles personalizados cambian cada vez que modificas los roles.

Ejemplo del rol predefinido roles/iam.roleViewer

description: Read access to all custom roles in the project.
etag: AA==
includedPermissions:
- iam.roles.get
- iam.roles.list
- resourcemanager.projects.get
- resourcemanager.projects.getIamPolicy
name: roles/iam.roleViewer
stage: GA
title: Role Viewer

El servicio CIAM proporcionado por GCP es Identity Platform.

Comparación

En la siguiente tabla muestro de forma resumida una comparación de los diversos conceptos vistos a lo largo del artículo.

Dado que los limites existentes en la creación de usuarios, roles, grupos puede modificarse a lo largo del tiempo indico la página de cada proveedor en la que consta esta información.

	AWS	Azure	GCP
Identidad
Gestión de identidad	AWS Identity and Access Management (IAM)	Azure Active Directory (Azure AD)	Cloud Identity and Access Management (IAM)
Federación de identidad	AWS Identity Federation	Azure Active Directory (Azure AD)	Identity-Aware Proxy (IAP)
Gestión de identidad	AWS Identity and Access Management (IAM)	Azure Active Directory (Azure AD)	Cloud Identity and Access Management (IAM)
Gestión de identidad de clientes (CIAM)	AWS Cognito	Azure AD B2C	GCP Identity Platform
Usuario	IAM User	Azure AD User	Google Account Cloud Identity Account
Aplicación	IAM User	Service Principal	Service Account
Recurso/Servicio	IAM User	Managed Identity	Service Account
Agrupación de usuarios	IAM User Groups	Azure AD Group	Google Group
Acceso de terceros	Resource-based policy	Service Principal	Service Account
Límites o cuotas	Cuotas AWS	Límites Azure	Cuotas GCP
Gestión de acceso
Control de Acceso Basado en Roles	AWS Identity and Access Management (IAM)	Azure Role-Based Access Control	Cloud Identity and Access Management (IAM)
Asignación de política	Usuario Grupo	Recurso	Recurso
Separación permisos/ámbito	No	Sí	Sí
Herencia de permisos	No	Sí	Sí

Para poder decidir que plataforma se adapta mejor a las necesidades, o si alguna de ellas presenta dificultades que nos hagan valorar que no es la plataforma cloud mas idónea, es necesario identificar los requisitos tanto a nivel de identificación como de otorgamiento existentes.

Es decidir tipos de entidades usuarias, como hemos visto pueden ser personas tanto usuarios de la plataforma y de las aplicaciones como clientes es decir solo usuarios de las aplicaciones. Las entidades también pueden ser servicios de la propia plataforma, otras aplicaciones etc.

Respecto a la gestión del acceso, es necesario saber tipos de usuarios, tipos de accesos que se deben de gestionar, necesidades de automatización. En este caso AWS por su modelo acoplado de definición y asignación de política puede dificultar la mantenibilidad, por lo que deberá de ser tenido en cuenta a la hora del diseño de la autorización.

En el caso de que se disponga a nivel empresarial ADFS, puede ser interesante optar por Azure AD en un modelo híbrido.

En el caso de que se decida optar por una plataforma cloud y su modelo de IAM no cubra las necesidades se puede valorar el utilizar un IAM diferente.