APRENDER. PRATICAR. EVOLUIR.Seguir a identidade até ao efeito
Numa plataforma fictícia de reporting, a pipeline cria uma função e escolhe a execution role. A pipeline não consegue ler diretamente dados sensíveis, mas a role que pode passar tem esse acesso. A revisão que olha apenas para as ações diretas do criador perde o privilégio delegado ao runtime. Desenha as identidades de origem, as relações de confiança, a operação que recebe a role e as ações do serviço resultante. Para cada ligação, pergunta quem a pode alterar e que evidência demonstra o uso. O objetivo é compreender o caminho de autorização, sem concluir que uma policy isolada representa todas as permissões efetivas do sistema.
Aplicar limites no âmbito correto
Uma SCP define limites organizacionais; não concede acesso a uma role que não tenha grants aplicáveis. Um Deny aplicável não é ultrapassado por mais Allow de identidade. O âmbito importa: SCPs não afetam identidades da conta de gestão e não restringem service-linked roles. Uma conta membro com delegated administrator continua dentro do âmbito das SCPs. Não generalizes a exceção para qualquer role usada por um serviço. Ensaios devem usar identidades representativas das contas afetadas e considerar as políticas herdadas. No comité de mudança, distingue necessidade de negócio, autorização existente e pedido de alteração ao limite. Uma falha de acesso não justifica remover indiscriminadamente a restrição organizacional.
Delimitar a delegação com PassRole
PassRole permite passar uma role a um serviço; não é o mesmo que a assumir diretamente. Limita as roles de execução aprovadas e, quando aplicável, o destinatário com iam:PassedToService. Confirma também que as permissões dessas roles correspondem ao trabalho do runtime e que a trust aceita o serviço certo. O exercício local compara uma proposta com uma lista de pares aprovados de role e serviço. É uma revisão de intenção, não um simulador IAM: não avalia policies, conditions ou grants reais. Para auditoria, procura a operação que criou ou alterou o recurso, como CreateFunction. PassRole é uma permissão e não produz uma chamada API independente com esse nome.
Preservar confiança sem depender do nome
Uma trust que referencia diretamente uma role é associada à identidade única dessa role. Apagar e recriar com o mesmo nome pode deixar um principal ID antigo na policy. Confirma a nova identidade e atualiza a relação delimitada, em vez de abrir Principal para ultrapassar a janela. Em pipelines federadas por OIDC, verifica claims que representam a origem autorizada. Para GitHub, aud identifica o destinatário e sub permite restringir organização, repositório e branch no formato utilizado. Se o workflow usa environments, as respetivas proteções também fazem parte do desenho. O nome escolhido para uma sessão não substitui a verificação da origem do token e das condições da trust.
Planear sessões e limites temporais
Uma session policy pode reduzir permissões da role no percurso de identity policies, mas não acrescentar ações que a role não permite. Nos exercícios sem grants de recursos, aplica-se a interseção declarada; não transportes essa simplificação para todos os grants diretos de sessões. Planeia também duração e renovação. Uma sessão que usa AssumeRole para obter outra sessão por role chaining tem limite de uma hora nas chamadas API, mesmo que a role de destino permita doze. Um job longo precisa de um mecanismo de renovação suportado ou de outro desenho autorizado. Testa expiração durante uma fase controlada e conserva identidade e correlação nas operações seguintes.
Relacionar autorização e contexto criptográfico
Em KMS, o statement da key policy que delega à conta permite usar IAM para conceder acesso; não distribui Decrypt automaticamente por todas as roles. Verifica key policy, grants relevantes e identidade efetiva antes de alterar permissões. Encryption context é metadado não secreto, associado criptograficamente ao ciphertext, e pode aparecer em texto simples nos logs. Não coloques palavras-passe ou dados sensíveis nesse campo. Para decifrar dados que o exigem, fornece o context correspondente; permissões amplas não corrigem um context incompatível. O resumo de revisão deve indicar quem assume, quem delega, qual o serviço que atua, que dados estão no âmbito e onde fica a evidência da operação.
# Original intention-review exercise, not an IAM policy evaluator.
approved = {("report-reader", "lambda.amazonaws.com"),
("batch-writer", "ecs-tasks.amazonaws.com")}
def review_delegation(role, service):
if (role, service) in approved:
return "within approved design; live authorization still requires validation"
return "outside approved design"
assert review_delegation("report-reader", "lambda.amazonaws.com").startswith("within")
assert review_delegation("administrator", "lambda.amazonaws.com").startswith("outside")
assert review_delegation("report-reader", "ecs-tasks.amazonaws.com").startswith("outside")
assert review_delegation("batch-writer", "ecs-tasks.amazonaws.com").startswith("within")
A pipeline só cria reporting, mas pode escolher uma role administrativa. A revisão segue o privilégio até à função e restringe os pares de role e serviço aprovados.
Armadilhas comuns
SCP como grant; delegated administrator como isenção; nome de role como identidade; PassRole como AssumeRole; encryption context como local para segredos.
Tópicos relacionados: Segredos, chaves e evidência de auditoria
A revisão de acesso precisa de seguir delegação, âmbito e identidade efetiva. Um Allow isolado ou um nome conhecido não prova autorização correta.
Referência: Organizations service control policies · DOP-C02