APRENDER. PRATICAR. EVOLUIR.Começar pelo pedido que falhou
Num batch fictício de reconciliação, o operador consegue listar o bucket, mas o processo não lê o ficheiro esperado. Escreve primeiro uma linha de evidência: hora, identidade efetiva, ação, recurso e resultado. Listar e ler são operações diferentes; o êxito de uma não comprova a outra. Se o processo usa credenciais temporárias, inclui a validade e a presença do token na investigação, sem registar segredos. Compara o contexto do batch com o do operador. Uma reprodução com a identidade pessoal do administrador pode esconder a falha. A primeira entrega ao APS é uma hipótese verificável e uma reprodução limitada, sem alterar permissões antes de identificar o pedido. Para o batch EC2, associa uma role através de um instance profile e limita ações e recursos ao prefixo necessário. O SDK deve obter e renovar as credenciais temporárias dessa role; uma chave fixa num ficheiro pode fazer o processo usar outra identidade. Para pessoas que trabalham em várias contas, IAM Identity Center permite ligar o fornecedor de identidade empresarial e atribuir acesso por funções. Separa este acesso humano da identidade do batch.
Separar a entrada no role da operação seguinte
Um fornecedor deve consultar relatórios através de um role dedicado. Desenha duas setas: identidade do fornecedor para AssumeRole; sessão resultante para o relatório. A primeira depende da autorização do chamador e da confiança do role no cenário entre contas. A segunda depende das permissões aplicáveis à sessão e ao recurso. No exercício, STS devolve credenciais, mas GetObject falha. A equipa deve investigar a segunda seta e confirmar que o cliente realmente usa as credenciais devolvidas. Não precisa de alargar a confiança para resolver uma operação S3. Regista responsáveis distintos para integração, permissões do role e dados, evitando que cada equipa altere uma camada diferente ao mesmo tempo.
Ler limites sem inventar concessões
Considera um role com uma política de identidade que permite leitura e escrita e uma permissions boundary que apenas admite leitura. Neste exemplo não existe concessão por política de recurso: a escrita fica fora da interseção. Uma boundary que admite escrita também não cria uma concessão ausente. Não transformes esta regra limitada num avaliador universal: políticas de recurso e o tipo de principal exigem análise própria. Uma SCP aplicável pode ainda limitar o role de uma conta membro; não concede acesso. No comité de mudança, apresenta a ação bloqueada, a restrição responsável e a exceção mínima proposta. Remover todos os limites torna a experiência menos informativa e aumenta o âmbito da alteração. Um Deny explícito aplicável prevalece sobre um Allow para o mesmo pedido. Antes de concluir que a exceção resolveu o incidente, confirma ação, recurso e condições da proibição; acrescentar outro Allow não a remove.
Associar o fornecedor ao cliente certo
Na oficina, um integrador fictício gere duas entidades, Norte e Sul. Ambas usam o mesmo serviço do integrador, mas este atribui identificadores externos diferentes. O role de Norte deve verificar o identificador de Norte e confiar apenas no principal acordado. O identificador externo contextualiza o pedido; não é uma palavra-passe nem substitui a autenticação do fornecedor. Prepara três tentativas previstas: identificador correto, ausente e de Sul. Só a primeira deve satisfazer esta condição de confiança. Se as três passam, a integração ainda não demonstrou a separação pretendida. Pede ao integrador a correspondência que utiliza e procura outras concessões na confiança, em vez de trocar repetidamente o valor sem diagnóstico.
Incluir a chave no caminho de acesso
Um role de análise precisa de decifrar um resultado com uma chave KMS pertencente a outra conta. Para o caminho por políticas aqui estudado, compara a key policy do proprietário com a política IAM da identidade externa; não existem grants no exercício. A autorização de leitura do objeto é outra decisão. O dossier de mudança deve identificar a chave concreta e a operação necessária, sem converter acesso a dados em administração da chave. Num cenário de indisponibilidade, reúne primeiro a mensagem exata e a identidade. O sucesso ao ler um ficheiro cifrado com outra chave não elimina a hipótese de autorização KMS. Testa também a recusa de uma chave fora do âmbito antes do handover. Também na mesma conta, uma permissão S3 não substitui autorização KMS: verifica a key policy e se esta autoriza a utilização ou permite a delegação através de IAM, além das restantes políticas aplicáveis.
Oficina: decidir o que a evidência permite concluir
Reserva quinze minutos para desenhar as duas contas e os pedidos, quinze para rever as políticas fornecidas e dez para preparar a aceitação. Os resultados são previstos em papel; esta aula não executou pedidos AWS. Uma simulação pode ajudar a analisar políticas com entradas explícitas, mas não prova que o batch usa esse contexto nem que o serviço está operacional. Entrega uma matriz com leitura permitida, escrita recusada, prefixo vizinho recusado e credenciais renovadas. Em execução futura autorizada, guarda resultados sanitizados, versão da configuração e responsável pela decisão. Se surgir acesso inesperado, suspende a aceitação e investiga. O resumo final deve distinguir o que foi observado, apenas previsto e ainda não ensaiado.
Batch fictício: AssumeRole funciona, ListBucket funciona, GetObject falha. Confirma a sessão usada e o ARN do objeto antes de alterar a confiança. Se existe SSE-KMS, inclui a chave concreta na análise.
Armadilhas comuns
Testar como administrador; confundir entrada no role com acesso aos dados; tratar external ID como segredo; apresentar previsão do simulador como execução real.
Tópicos relacionados: Proteção e recuperação de dados · Acesso privado e arranque sem dependências escondidas
Identifica o pedido e a identidade, separa concessões de limites e prepara testes positivos e negativos com âmbito explícito.
Referência: IAM security best practices · SAA-C03