Principal — quem faz a request

Toda ação na AWS parte de alguém: esse alguém é o principal. É a primeira peça do modelo IAM, porque toda policy responde à pergunta “o que este principal pode fazer?”.

A documentação oficial chama isso de AWS account root user, IAM user, IAM role, or federated user.

• IAM User — identidade de longa duração, com credenciais fixas (access key ou senha).
  Ex.: arn:aws:iam::111122223333:user/alice.
• IAM Role — identidade assumível, sem credenciais permanentes. Quem a assume recebe credenciais temporárias.
  Ex.: arn:aws:iam::111122223333:role/AppRole.
• AWS Service — um serviço AWS agindo em seu nome (ex.: Lambda executando sua função). Identificado por um service principal: lambda.amazonaws.com.
• Usuário federado — identidade vinda de um IdP externo (SAML, OIDC, Google, SSO corporativo). Assume uma role após autenticar.
• Anônimo — sem credenciais. Só consegue algo se um recurso (ex.: bucket S3) permitir explicitamente com "Principal": "*".

O tipo de principal define como você protege e audita o acesso:

• User → tem senha/chave. Precisa de MFA, rotação e monitoramento.
• Role → sem segredo permanente. Padrão recomendado para aplicações, serviços e federação.
• Service principal → define o que um serviço AWS pode fazer no seu nome, via trust policy.

Antes de escrever qualquer policy, pergunte: “quem é o principal?”. A resposta muda tudo — o tipo de credencial, onde a permissão é escrita e como você audita.

Esta lição está alinhada com a boa prática Define access requirements do Well-Architected Framework: entender os tipos de principal é o primeiro passo para definir quem precisa acessar o quê.

• Ver boa prática no Well-Architected Framework

• Understanding how IAM works (AWS Docs)
• IAM identities: users, groups, and roles
• Security best practices in IAM