APRENDER. PRATICAR. EVOLUIR.1. Desenhar o percurso antes de investigar
Imagina uma aplicação de reconciliação de fundos cujo suporte entra pelo IdP, assume uma role de diagnóstico e depois uma role numa conta de recuperação. Desenha cada salto: credencial apresentada, operação STS, trust policy do destino e ação sobre o recurso. Uma falha no segundo salto exige uma investigação diferente de uma falha GetObject depois de obter a sessão. GetCallerIdentity ajuda a confirmar qual principal o processo realmente usa, incluindo situações em que o perfil da shell difere do perfil do serviço. O sucesso dessa chamada não demonstra autorização para a operação de negócio. Regista também conta, Região, hora e identificador do pedido. Usa dados fictícios no exercício e protege os identificadores reais no trabalho.
2. Origem persistente e atribuição controlada
SourceIdentity pode manter a origem através de role chaining, mas a qualidade dessa evidência começa no ponto onde o valor é definido. Um texto que qualquer operador pode escolher não prova autoria. Decide qual atributo controlado do IdP fornece a origem e quem pode alterar esse mapeamento. Para a cadeia entre contas, verifica a permissão SetSourceIdentity no caller e na confiança do destino. Não confundas esse controlo com o nome da sessão. Também não prometas que todas as ações subsequentes de serviços AWS terão o atributo: ações em nome do utilizador através de serviços e service-linked roles têm limites documentados. Num incidente, correlaciona eventos e mantém explícitas as ligações ainda não demonstradas.
3. Atributos e validade da sessão
Uma tag de sessão usada por ABAC é uma entrada de segurança. Se o caller puder escolher Department=Finance, a tag estática Operations na role não constitui uma proteção suficiente contra essa sobreposição. Restringe TagSession e os valores e chaves autorizados. Quando Project precisa de acompanhar uma cadeia, configura a chave como transitiva; a simples existência da tag inicial não garante transporte. Faz um teste positivo e outro com valor proibido. Se um batch demora duas horas, não assumes que MaxSessionDuration=12h resolve uma cadeia STS: esse percurso tem limite de uma hora. Planeia renovação autorizada, tratamento de expiração e repetição segura do trabalho, sem guardar credenciais permanentes como atalho.
4. Permission sets e diferenças entre contas
Identity Center pode provisionar uma inline policy do permission set. Uma referência a customer managed policy exige que a política já exista na conta com o nome e path correspondentes. Daqui resulta uma tarefa operacional: distribuir e controlar o documento local. Num rollout para quatro contas, três documentos podem permitir apenas leitura e o quarto incluir escrita. O mesmo nome não demonstra equivalência. Antes do handover, compara versões aprovadas, verifica as restantes políticas aplicáveis e executa ações representativas permitidas e proibidas. Mantém um owner da distribuição e uma forma de detetar divergência. A aceitação deve dizer quais contas foram observadas e que exceções continuam abertas, em vez de usar uma captura de login como prova global.
5. Identidades de pipelines e workloads externos
Para GitHub OIDC, a confiança deve delimitar audiência e subject. No fluxo padrão de branch, o subject identifica organização, repositório e referência; ao usar um environment, o formato e a proteção necessária mudam. Aplica regras de proteção desse environment para limitar os deployments permitidos. Para um workload externo com Roles Anywhere, a CA confiável não distingue sozinha todos os consumidores dessa CA. Avalia atributos de certificado aprovados, como subject ou SAN, e a governação da emissão. Neste percurso, aws:SourceArn refere o trust anchor indicado em CreateSession. Não o substituas pelo ARN do recurso que a aplicação quer consultar depois. A autorização do recurso continua a ser outra decisão.
6. Exercício guiado e passagem a RUN
O modelo Python abaixo compara uma referência de política com um inventário fictício e assinala ausência ou divergência do documento aprovado. Não avalia IAM: hashes iguais de um documento não incluem SCPs, resource policies ou contexto de sessão. Prevê o resultado antes de executar: a conta pilot deve ficar ready, recovery deve ficar drift e new deve ficar missing. Depois altera a entrada recovery para o hash aprovado e repete. Explica porque isso resolve apenas a comparação documental. No trabalho real, junta o resultado à matriz de acessos, evidência de testes comportamentais, contactos de escalada e procedimento de renovação de credenciais. O resumo para o comité deve distinguir preparação do acesso, validação do acesso e limitações de atribuição.
# Local document-inventory exercise; not an IAM evaluator.
# No credentials, network calls, or AWS mutations.
reference = ("/support/", "APSRead")
approved = "reviewed-document-v3"
accounts = {
"pilot": {reference: approved},
"recovery": {reference: "local-write-variant"},
"new": {},
}
def compare(inventory):
actual = inventory.get(reference)
if actual is None:
return "missing"
return "ready" if actual == approved else "drift"
result = {name: compare(policies) for name, policies in accounts.items()}
assert result == {"pilot": "ready", "recovery": "drift", "new": "missing"}
print(result)
Uma conta recebe APSRead com escrita por divergência local. O handover fica condicionado até demonstrar leitura permitida e escrita negada.
Armadilhas comuns
Persistência como autenticidade; nome como documento; tag estática como limite; sucesso STS como autorização do recurso.
Tópicos relacionados: Políticas, tags e análise de acesso · Resposta e preservação de evidência
Confirma origem, confiança, atributos e ação efetiva; fecha o handover com evidência em cada conta.
Referência: Monitor and control actions taken with assumed roles · SCS-C03