Amazon SCS-C02: Gerenciamento de Identidade e Acesso — Guia de estudos

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Faz parte do AWS Security Specialty SCS-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Identidades, Principals e Avaliação de Políticas

O IAM distingue entre identidades (usuários, grupos, roles) e principals (a entidade autenticada que faz uma solicitação). Usuários são de longa duração com credenciais estáticas; roles não têm credenciais próprias e são assumidas para gerar tokens STS de curta duração. Grupos são contêineres para anexar políticas a usuários — eles nunca são principals e não podem ser assumidos.

Toda chamada de API passa por uma cadeia de avaliação determinística: um Deny explícito em qualquer lugar prevalece, depois os SCPs no nível da organização devem permitir, depois os limites de permissões devem permitir, depois as políticas de sessão (se houver) devem permitir e, finalmente, pelo menos uma política baseada em identidade ou em recurso deve conter um Allow. A ausência de qualquer camada de Allow resulta em uma negação implícita. É por isso que a sobreposição de camadas é importante: uma política de identidade que concede s3:* não tem efeito se um SCP nega s3:DeleteBucket ou se um limite de permissões omite o S3 completamente.

Políticas baseadas em recursos (políticas de bucket do S3, políticas de chave do KMS, políticas de tópico do SNS, políticas de função do Lambda) podem conceder acesso diretamente a um principal sem nenhuma política de identidade do lado do chamador — dentro da mesma conta. Para acesso entre contas, tanto a política de identidade na conta de origem quanto a política de recurso na conta de destino devem permitir a ação.

Roles, Políticas de Confiança e AssumeRole

Uma role tem dois documentos de política: a política de confiança (quem pode assumi-la) e uma ou mais políticas de permissões (o que podem fazer uma vez que a assumem). A política de confiança é uma política baseada em recurso na própria role, usando a ação sts:AssumeRole. Sem uma política de confiança correspondente, o AssumeRole falha com AccessDenied, mesmo que o chamador tenha sts:AssumeRole em sua política de identidade.

Para delegação entre contas, a política de confiança nomeia a conta confiável ou um ARN de role/usuário específico nessa conta e — o que é crítico para acesso de terceiros — impõe um ExternalId:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

O ExternalId protege contra o problema do “confused deputy”: sem ele, um provedor de SaaS de terceiros que assume roles em várias contas de clientes poderia ser enganado para agir na role do cliente errado. Omitir sts:ExternalId na condição, ou passar o valor errado durante o sts:AssumeRole, produz um AccessDenied na tentativa de assumir a role — uma configuração incorreta comum ao integrar fornecedores como ferramentas de monitoramento ou CSPM.

Para serviços da AWS (Lambda, EC2, tarefas do ECS), a política de confiança nomeia um principal de serviço, por exemplo, "Service": "lambda.amazonaws.com". Uma função Lambda que precisa de acesso ao S3 deve assumir uma role de execução cuja política de permissões concede s3:GetObject e s3:PutObject no bucket; de forma equivalente, uma política de bucket do S3 pode nomear o ARN da role da função como principal. Qualquer um dos mecanismos funciona isoladamente dentro de uma única conta.

Limites de Permissões

Um limite de permissões (permissions boundary) é um controle avançado anexado a um usuário ou role que estabelece o teto máximo de permissões que essa identidade pode ter, independentemente do que as políticas baseadas em identidade concedem. As permissões efetivas são a interseção da política de identidade e do limite. Se uma política de grupo concede ec2:*, mas o limite permite apenas ec2:Describe*, o usuário só pode descrever recursos.

Os limites são comumente usados para delegação de permissões: permitir que desenvolvedores criem roles do IAM para suas aplicações, mas exigir que cada role criada por eles carregue um limite específico. A política do IAM para o desenvolvedor inclui uma condição como "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" em iam:CreateRole e iam:PutRolePolicy. Isso impede a escalação de privilégios, ao mesmo tempo que habilita o autoatendimento (self-service).

Um equívoco frequente é pensar que a associação a um grupo ou políticas adicionais anexadas podem “sobrepor” um limite de permissões ou um SCP. Elas não podem — o limite e o SCP são tetos, não pisos.

Aplicação de MFA por Meio de Condições

Duas chaves de condição orientam a política de MFA: aws:MultiFactorAuthPresent (booleano, verdadeiro se a sessão foi obtida usando MFA) e aws:MultiFactorAuthAge (numérico, segundos desde que o MFA foi validado). A aplicação de MFA para APIs sensíveis e a limitação da duração da sessão se parecem com isto:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Duas horas equivalem a 7.200 segundos. Usar BoolIfExists em vez de Bool é sutilmente perigoso para chamadas de principal de serviço que nunca carregam essa chave — ele avalia como verdadeiro e efetivamente ignora a verificação para esses chamadores, portanto, prefira Bool quando a intenção é a aplicação para usuários humanos.

Como as solicitações da CLI e do SDK que usam chaves de acesso de longa duração não carregam o contexto de MFA, os usuários devem primeiro chamar sts:GetSessionToken (com --serial-number e --token-code) ou sts:AssumeRole com --serial-number/--token-code para obter credenciais temporárias que incluam o contexto de MFA. Essas credenciais de curta duração então satisfazem a condição MultiFactorAuthPresent:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

Funções do IAM e Políticas de Confiança: PassRole e AssumeRole

Uma função (role) do IAM tem duas superfícies de política distintas, e confundi-las é a causa raiz da maioria das falhas de autorização entre contas. A política de confiança (o AssumeRolePolicyDocument) responde quem pode assumir a função e sob quais condições. A política de permissões responde o que a função pode fazer uma vez assumida. Ambas devem permitir a ação; a política de confiança por si só nunca concede acesso ao S3, KMS ou qualquer outra coisa.

Quando uma entidade principal (principal) chama sts:AssumeRole, o STS avalia a política de confiança da função de destino em relação à identidade chamadora mais o contexto da sessão (IP de origem, estado do MFA, tags de sessão, ID externo). A entidade principal chamadora também deve ter uma permissão Allow baseada em identidade para sts:AssumeRole naquele ARN da função. Esse requisito duplo é o que torna a assunção de função (role assumption) segura entre os limites das contas.

Uma política de confiança canônica entre contas que exige MFA e um ID externo se parece com isto:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

A chave aws:MultiFactorAuthPresent só tem significado na política de confiança de uma função que pode ser assumida, porque o contexto do MFA é estabelecido na chamada do STS, não nas chamadas de serviço subsequentes. Adicionar condições de MFA à política do bucket S3 ou à política de permissões da função é um erro comum: a sessão da função assumida geralmente não carrega aws:MultiFactorAuthPresent=true, mesmo que o usuário humano original tenha se autenticado com MFA, então essas condições negam tudo silenciosamente. Exija o MFA no momento da assunção; use aws:MultiFactorAuthAge para forçar a reautenticação em sessões de longa duração.

PassRole é o segundo portão que causa confusão nos cenários de exame. Quando você instrui um serviço como CloudFormation, EC2, Lambda ou CodeBuild a executar como uma função, a identidade chamadora deve ter a permissão `iam:PassRole

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera uma AWS Organization com várias contas, com contas separadas para produção, desenvolvimento e ferramentas de CI/CD; eles usam funções do IAM centralizadas para implantações entre contas e agentes de CI de terceiros que assumem funções para realizar alterações na infraestrutura. Os limites de identidade são impostos por políticas de confiança de função, e algumas equipes usam perfis de instância (instance profiles) e funções Lambda de longa duração que recebem a permissão iam:PassRole para anexar funções a instâncias ou tarefas.

Desafio: Uma auditoria recente descobriu que uma permissão iam:PassRole excessivamente ampla permitiu que uma entidade principal de CI/CD passasse uma função de Administrador para um perfil de instância do EC2, e um invasor explorou uma confiança de AssumeRole para obter privilégios excessivos entre contas.

Abordagem Recomendada:

1. Use o AWS CloudTrail e o Amazon EventBridge para identificar chamadas de API iam:PassRole e sts:AssumeRole recentes, e execute consultas no CloudTrail Lake ou no Athena para listar quais entidades principais passaram quais ARNs de Função e quando.
2. Execute o IAM Access Analyzer (para o IAM) entre contas para descobrir exposições em políticas de confiança baseadas em recursos e listar funções que podem ser assumidas de fora da Organization ou por entidades principais externas.
3. Substitua políticas iam:PassRole amplas por políticas do IAM de privilégio mínimo que especifiquem os ARNs exatos da Função no Resource, e adicione chaves de condição como aws:PassedToService ou aws:PrincipalOrgID para limitar quem e o que pode receber a função.
4. Reforce as políticas de confiança da função para exigir condições — use aws:PrincipalOrgID, sts:ExternalId para terceiros, exija aws:SourceIdentity e imponha durações máximas de sessão — para impedir AssumeRole amplo por entidades principais desconhecidas.
5. Configure regras do Amazon EventBridge para detectar anomalias de iam:PassRole e AssumeRole, envie alertas para o Amazon SNS e crie playbooks automatizados com Lambda para revogar ou remediar políticas excessivamente amplas, e registre os achados no AWS Security Hub e no AWS Config para conformidade contínua.

Justificativa: Esta abordagem impõe o princípio do privilégio mínimo e da defesa em profundidade, restringindo os alvos de PassRole e as políticas de confiança, ao mesmo tempo que permite a detecção e a remediação automatizada por meio de logs e monitoramento — alinhada com as melhores práticas da AWS para IAM e federação.

Todos os domínios · Detecção de Ameaças e Alertas →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →