Enmilocalfunciona

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.

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:

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:

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:

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:

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

Las características clave son:

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

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:

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:

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.

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.