La gestión de identidades y accesos (IAM) determina qué identidad puede autenticarse y qué acciones puede realizar dicha identidad sobre un recurso específico. En un entorno multinube, un proveedor de identidades corporativo puede gestionar el inicio de sesión de la fuerza laboral, mientras que AWS, Azure y Google Cloud toman sus propias decisiones de autorización dentro de sus respectivos límites administrativos. Un inicio de sesión correcto no autoriza por sí mismo una solicitud a la API de un recurso. En AWS, el inicio de sesión único (SSO) para la fuerza laboral suele configurarse mediante IAM Identity Center, y los roles de IAM junto con AWS Security Token Service (STS) emiten las credenciales temporales resultantes.
[fuentes][/fuentes]
Una distinción útil se establece entre el proveedor de identidades, el plano de control de cada nube y el plano de datos de cada nube. El plano de control gestiona los recursos de la nube y su configuración. El plano de datos procesa las solicitudes dirigidas a los propios recursos; cuando se realiza una solicitud de este tipo, cada nube evalúa el sujeto (principal), la acción, el recurso y las condiciones pertinentes dentro de su propio sistema IAM. Aunque estos planos pueden compartir información de identidad, no comparten un conjunto universal de permisos.
[fuentes][/fuentes]
Ahora es posible delimitar los límites del inicio de sesión sin que ello implique necesariamente el acceso a los recursos.
[fuentes][/fuentes]
Los fallos de IAM en entornos multicloud a menudo comienzan con términos familiares que tienen alcances distintos. Una cuenta de AWS constituye un límite administrativo para los recursos de AWS. Un inquilino (tenant) de Azure representa el límite del directorio de Microsoft Entra ID, mientras que el acceso a los recursos de Azure se autoriza habitualmente mediante el control de acceso basado en roles de Azure (Azure RBAC) en el ámbito de grupo de gestión, suscripción, grupo de recursos o recurso individual. En Google Cloud, la organización y el proyecto proporcionan ámbitos separados para la asignación de políticas de Cloud IAM y la propiedad de los recursos.
Esta distinción es importante porque la pertenencia a una identidad no equivale a un permiso sobre un recurso. En Azure, Microsoft Entra ID puede autenticar a un usuario y revelar su pertenencia a grupos, pero Azure RBAC debe asignar un rol aplicable para autorizar la acción solicitada en Azure. En AWS, las políticas de AWS Identity and Access Management (IAM) y las credenciales de AWS Security Token Service (STS) intervienen en la autorización. En Google Cloud, Cloud IAM evalúa las vinculaciones de políticas según la jerarquía de recursos correspondiente. Nombres de grupo aparentemente similares no implican un acceso equivalente entre estos distintos límites.
La evidencia operativa también está sujeta a estos límites. Un evento de inicio de sesión en un proveedor de identidad corporativo puede demostrar que se produjo la autenticación, pero por sí solo no confirma que AWS, Azure o Google Cloud permitieran una solicitud posterior a la API. Un registro de auditoría en la nube puede mostrar un intento de acceso al plano de control o a la API de recursos en dicha nube, pero no prueba que los datos del ciclo de vida en el proveedor de identidad corporativo fueran correctos. Se requiere evidencia proveniente del plano que tomó la decisión, incluyendo la identidad, el recurso, la acción y el intervalo de tiempo.
Regla de decisión Diagnostique el acceso analizando una nube y una solicitud cada vez. Identifique primero el principal, el recurso de destino, la acción de la API y el plano de autorización que realizó la evaluación.
Utilizaremos una carga de trabajo delimitada en lugar de tratar a todas las identidades por igual. El servicio orders-api escucha en el puerto 8080. Una identidad de fuerza laboral, orders-workforce-user, representa a un operador que requiere acceso interactivo a través del proveedor de identidad corporativo. El grupo app-operators representa el rol operativo previsto, mientras que cloud-admins se mantiene separado deliberadamente, ya que el acceso administrativo conlleva un perfil de riesgo y un límite de aprobación diferentes.
La identidad automatizada es orders-ci, la cual representa una tarea de integración continua que despliega o gestiona la carga de trabajo. Sus solicitudes no corresponden a sesiones de navegador de usuarios de la fuerza laboral. Esta identidad recibe credenciales federadas de corta duración para cada nube, en lugar de utilizar claves de acceso a la nube de larga duración. Los límites de nuestros proveedores son la cuenta de AWS dev, el inquilino de Azure contoso y el proyecto de Google Cloud orders-prod; cualquier consulta de autorización posterior deberá especificar explícitamente uno de estos destinos.
Ahora podemos examinar cómo llegan a cada nube las rutas de identidad de la fuerza laboral y de CI.