Arquiteturas seguras · tema 2 de 7
IAM além do básico
40 min · 2 vídeos · 12 cards · 1 drill
Por que cai
IAM está em todo cenário do Domínio 1, que vale 30% da prova, e aparece escondido nos outros três: acesso entre contas, permissão de uma Lambda a um bucket, quem pode assumir o quê. A prova não pede a sintaxe da política; pede que você saiba qual mecanismo resolve cada cenário e o que uma negação explícita faz com todo o resto.
Pré-teste · 1 de 2
responda antes de verUm usuário tem a política gerenciada AdministratorAccess. Uma segunda política, anexada ao grupo dele, contém um Deny explícito para s3:DeleteObject. Ele consegue apagar objetos no S3?
Vídeo · português · 11 min
Em uma frase
O IAM decide cada chamada assim: negação explícita vence tudo; sem ela, é preciso um Allow explícito; sem Allow, nega. Todo cenário de segurança da prova é uma variação de quem concede, quem limita e por qual mecanismo.
A lógica de avaliação, que resolve metade das questões
Quando uma chamada chega, a AWS junta todas as políticas aplicáveis — de identidade, de recurso, SCPs, limites de permissão, políticas de sessão — e avalia:
- 1Há um Deny explícito em qualquer uma delas? Então nega, e acabou. Não importa quantos Allow existam.
- 2Não há Deny. Há um Allow explícito que cubra a ação e o recurso? Então permite.
- 3Não há Allow. Nega, por padrão. É o 'implicit deny': tudo que não foi permitido está proibido.
Isso explica o cenário favorito da prova: um administrador com AdministratorAccess barrado de um serviço por um Deny numa SCP ou numa política de grupo. Não é bug; é a regra.
Quem concede e quem limita
| Mecanismo | Concede? | Limita? | Onde mora |
|---|---|---|---|
| Política de identidade | Sim | Sim (com Deny) | Usuário, grupo, role |
| Política de recurso | Sim | Sim (com Deny) | Bucket, fila, tópico, chave KMS |
| SCP | Não | Sim | Organizations: raiz, OU, conta |
| Limite de permissão | Não | Sim | Usuário ou role |
| Política de sessão | Não | Sim | A sessão de uma role assumida |
A coluna "Concede?" é a que a prova testa. A alternativa que usa SCP para dar acesso está sempre errada. A alternativa que usa boundary para dar acesso também. Esses dois só definem tetos.
SCP— Service control policy: política do Organizations que define o máximo que qualquer identidade de uma conta pode fazer, inclusive o root. Não concede nada; só limita. limite de permissão— Permissions boundary: política anexada a um usuário ou role que define o teto do que ele pode receber. A permissão efetiva é a interseção com a política de identidade.Roles: o mecanismo que a prova mais espera
Uma role é uma identidade que se assume, com credencial temporária. É a resposta para três famílias de cenário:
- Serviço da AWS agindo por você. EC2, Lambda, ECS acessando S3, DynamoDB, SQS. A role é anexada ao serviço (perfil de instância no EC2). Nunca chave de acesso no código: esse é o distrator mais repetido da SAA.
- Acesso entre contas. A conta dona do recurso cria a role com as
permissões e uma política de confiança para a conta de origem. A
identidade de origem precisa de
sts:AssumeRole. Duas metades; a prova costuma perguntar as duas. - Federação. Pessoas de um diretório corporativo entram via IAM Identity Center; usuários de app entram via Cognito. Ninguém vira usuário IAM.
Condições: onde o menor privilégio fica preciso
A prova cobra três chaves de condição com nome:
aws:SourceVpceeaws:SourceVpc: bucket policy que só permite acesso vindo do endpoint da VPC. É o par de "tráfego privado para o S3".aws:SecureTransport: negar quando forfalse, para exigir HTTPS.aws:MultiFactorAuthPresent: exigir MFA para ações destrutivas.
Se quiser outro ângulo1 vídeo
Como cai na sabatina
“Uma aplicação na conta A precisa ler um bucket na conta B com o menor privilégio. Qual é a solução?”
Erros comuns
- Achar que Allow numa política vence Deny em outra. Uma negação explícita vence qualquer permissão, em qualquer política: é a primeira regra da lógica de avaliação.
- Tratar SCP como se concedesse permissão. SCP só limita o teto do que a conta pode fazer; a permissão em si vem das políticas de IAM dentro da conta.
- Criar usuário IAM com chave de acesso para uma aplicação em EC2. O mecanismo certo é role de instância: credencial temporária, rotacionada pela AWS, sem chave no código.
- Copiar credenciais entre contas para acesso cross-account. O desenho é uma role na conta de destino com política de confiança para a conta de origem, e AssumeRole via STS.
- Confundir limite de permissão com política de identidade. O boundary define o máximo que a identidade pode receber; não dá permissão nenhuma sozinho.
- Usar usuários IAM para pessoas quando a empresa tem um diretório. Para pessoas, a prova espera federação com o IAM Identity Center; usuário IAM é para exceções.
Flashcards
Card 1 de 12
0 certos · 0 a reverDrill
Qual mecanismo resolve?
Para cada cenário, diga qual mecanismo do IAM ou do Organizations é a resposta esperada.
1.Impedir que qualquer conta da unidade organizacional 'sandbox' crie recursos fora de uma região.
2.Uma Lambda na conta A precisa publicar num tópico SNS da conta B.
3.Funcionários do diretório corporativo devem acessar cinco contas com login único.
4.Desenvolvedores podem criar roles, mas nenhuma role criada por eles pode ter mais permissão do que um conjunto definido.
5.Permitir que um serviço da AWS de outra conta leia um bucket, sem criar role para ele.
Quiz · 1 de 5
Uma empresa usa AWS Organizations com várias contas. A equipe de segurança quer garantir que nenhuma conta, incluindo usuários administradores, consiga desativar o CloudTrail. Qual solução atende com o MENOR esforço operacional?
Explique para um gerente
Explique em um minuto para alguém de negócio por que um usuário com 'AdministratorAccess' pode, ainda assim, ser barrado de um serviço.
Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.
Prefiro falar em voz alta
00:00
Toque para gravar, ou responda em voz alta sem gravar