O gerenciamento de identidade e acesso (IAM) determina qual identidade pode se autenticar e quais ações essa identidade pode executar em um recurso específico. Em um ambiente multi-cloud, um provedor de identidade corporativo pode estabelecer o login da força de trabalho, enquanto AWS, Azure e Google Cloud tomam suas próprias decisões de autorização dentro de seus respectivos limites administrativos. Um login bem-sucedido não autoriza, por si só, uma solicitação de API para um recurso. Na AWS, o SSO para a força de trabalho é normalmente configurado por meio do IAM Identity Center, e funções (roles) do IAM, em conjunto com o AWS Security Token Service (STS), emitem as credenciais temporárias resultantes.
[fontes][/fontes]
Uma distinção útil de limites ocorre entre o provedor de identidade, o plano de controle de cada nuvem e o plano de dados de cada nuvem. Um plano de controle gerencia os recursos da nuvem e suas configurações. Um plano de dados processa as solicitações aos próprios recursos; cada nuvem avalia uma entidade (principal), uma ação, um recurso e as condições relevantes em seu próprio sistema de IAM quando tal solicitação é feita. Esses planos podem compartilhar informações de identidade, mas não compartilham um conjunto universal de permissões.
[fontes][/fontes]
Agora podemos definir os limites de login sem que isso implique acesso aos recursos.
[fontes][/fontes]
Falhas de IAM em ambientes multinuvem frequentemente começam com termos familiares que possuem escopos diferentes. Uma conta AWS é um limite administrativo para recursos da AWS. Um tenant do Azure é o limite do diretório do Microsoft Entra ID, enquanto o acesso a recursos do Azure é comumente autorizado por meio do controle de acesso baseado em função do Azure (Azure RBAC) nos escopos de grupo de gerenciamento, assinatura, grupo de recursos ou recurso. No Google Cloud, uma organização e um projeto fornecem escopos distintos para a associação de políticas do Cloud IAM e para a propriedade de recursos.
Essa distinção é importante porque o pertencimento a uma identidade não equivale a uma permissão de recurso. No Azure, o Microsoft Entra ID pode autenticar um usuário e indicar o pertencimento a grupos, mas o Azure RBAC ainda precisa conceder uma função aplicável para autorizar a ação solicitada no Azure. Na AWS, as políticas do AWS Identity and Access Management (IAM) e as credenciais do AWS Security Token Service (STS) participam da autorização na AWS. No Google Cloud, o Cloud IAM avalia as associações de suas políticas em relação à hierarquia de recursos relevante. Nomes de grupos semelhantes não criam acessos equivalentes entre esses limites.
Evidências operacionais também possuem limites específicos. Um evento de login em um provedor de identidade corporativo pode demonstrar que a autenticação ocorreu, mas não consegue, por si só, comprovar que a AWS, o Azure ou o Google Cloud permitiram uma solicitação de API subsequente. Um registro de auditoria na nuvem pode mostrar uma tentativa de acesso ao plano de controle ou à API de recursos nessa nuvem, mas não prova que os dados de ciclo de vida do provedor de identidade corporativo estavam corretos. Precisamos de evidências provenientes do plano que tomou a decisão, incluindo a identidade, o recurso, a ação e o intervalo de tempo envolvidos.
Regra de decisão Diagnostique o acesso analisando uma nuvem e uma solicitação de cada vez. Primeiro, identifique o principal, o recurso de destino, a ação da API e o plano de autorização que realizou a avaliação.
Utilizaremos uma carga de trabalho com limites definidos, em vez de tratar todas as identidades da mesma forma. O serviço orders-api escuta na porta 8080. Uma identidade de força de trabalho (workforce identity), orders-workforce-user, representa um operador que necessita de acesso interativo por meio do provedor de identidade corporativo. O grupo app-operators representa a função operacional pretendida, enquanto o grupo cloud-admins é mantido deliberadamente separado, pois o acesso administrativo envolve riscos e requisitos de aprovação distintos.
A identidade automatizada é orders-ci, representando um trabalho de integração contínua que implanta ou gerencia a carga de trabalho. Suas solicitações não correspondem a sessões de navegador da força de trabalho. Ela recebe credenciais federadas de curta duração para cada nuvem, em vez de manter chaves de acesso à nuvem de longa duração. Os limites dos nossos provedores são a conta AWS dev, o tenant Azure contoso e o projeto Google Cloud orders-prod; cada consulta de autorização subsequente deve especificar explicitamente um desses destinos.
Agora podemos examinar como os caminhos de identidade de força de trabalho e de CI chegam a cada nuvem.