Auditar identidades e permissões cloud

Transformar uma afirmação em critérios observáveis

A afirmação «o prestador só tem leitura» deixa perguntas importantes por responder. Leitura de quê, em nome de que cliente, durante que período e através de que caminhos? Num serviço fictício de custos de um banco, separa quatro critérios: o cliente autenticado só alcança a sua conta; a operação de custos continua disponível; o prestador não consegue escrever dados por caminhos diretos ou delegados; a manutenção interna conserva a capacidade de reparação aprovada.

Regista identidades, operações, recursos, condições e versões antes de selecionar testes. Uma captura de uma política de leitura cobre apenas parte deste modelo. O papel de auditoria é avaliar evidência contra critérios acordados.

A equipa responsável aprova e executa alterações; a auditoria não ganha autoridade operacional por conhecer a solução.

Uma concessão e um limite têm funções diferentes

Considera um utilizador com GetObject na política de identidade e GetObject mais PutObject na permissions boundary. Sem outras concessões aplicáveis, a leitura cabe no limite e está concedida; a escrita cabe no limite mas não está concedida.

A boundary não atribui essa capacidade. Acrescenta agora uma recusa de GetObject quando aws:SecureTransport=false: o mesmo objeto e utilizador podem produzir leitura permitida por HTTPS e recusada por HTTP. Mantém o contexto do pedido no papel de trabalho, pois a condição explica a diferença.

Esta matriz é delimitada: políticas de recurso, tipo de principal, sessões e controlos organizacionais podem alterar a análise. Antes de usar uma regra de interseção como fórmula universal, identifica quais mecanismos realmente participam no pedido.

Seguir o principal entre contas

Num acesso direto, um role da conta A tenta escrever num bucket da conta B. B já permite a operação no prefixo aprovado, mas A concede apenas leitura. Alargar o prefixo em B aumenta exposição sem preencher a concessão em falta em A.

O ensaio útil compara a escrita aprovada antes e depois da alteração específica de identidade, mantendo as restantes condições. Distingue este caminho de assumir um role em B: nesse segundo caso é necessário avaliar a confiança para a assunção e depois as permissões da identidade assumida.

O diagrama do auditor deve mostrar quando o principal muda. Uma linha que apenas liga «conta A» a «conta B» esconde a diferença e pode levar a pedir a correção na política errada.

Auditar quem controla os atributos

Num repositório documental fictício, a regra permite leitura quando departamento do utilizador e departamento do documento coincidem. Testar repetidamente essa comparação não avalia quem pode alterar os valores. Se o utilizador puder atribuir a si próprio outro departamento, pode satisfazer corretamente um predicado cuja entrada não é fiável.

Usa documentos sintéticos de dois departamentos e uma identidade autorizada para o ensaio: confirma a leitura esperada, tenta alterar o próprio atributo através do caminho exposto e repete a leitura do segundo documento. Regista separadamente a autorização da alteração do atributo e a decisão de leitura.

Em implementações AWS, verifica o suporte de tags e condition keys do serviço e operação concretos; uma regra demonstrada num serviço não prova suporte uniforme em todos.

ExternalId depende da associação ao cliente

O identificador bank-7 é uma etiqueta fictícia do exercício, não uma palavra-passe. A política do banco pode exigir esse valor e ainda assim existir um problema se o portal do prestador copiar qualquer ARN e ExternalId fornecidos pelo cliente.

A comparação cloud não conhece a sessão autenticada no portal. O prestador precisa de obter o identificador da associação que administra para esse cliente. O teste negativo deve tentar uma combinação que pertença a outro cliente, através do mesmo broker, com autorização e dados sintéticos.

Um teste que omite completamente ExternalId avalia a condição na cloud, mas não testa sozinho a associação no portal. Conserva ambos os resultados e descreve qual fronteira cada um observou.

OIDC: identidade emitida, confiança e operação

Em GitHub Actions, id-token: write permite pedir um token OIDC; não concede por si só escrita em AWS. Se a emissão funciona e a assunção falha, compara aud e sub emitidos com a confiança esperada antes de alterar permissões de objetos. A documentação consultada distingue subjects legados e subjects com IDs imutáveis, incluindo repositórios criados após 15 de julho de 2026 e os que adotaram o formato por opt-in; esta alteração não se aplica a GitHub Enterprise Server.

Confirma a configuração do repositório concreto. Num subject legado repo:lab/payments:environment:prod, o ambiente está identificado mas main não aparece. Para demonstrar deployments limitados a main, avalia a proteção de branches no ambiente e testa uma origem permitida e outra recusada.

Aceitar toda a organização para resolver uma divergência de formato expande confiança sem necessidade.

Permissões delegadas podem alcançar mais recursos

O operador do exercício não lê diretamente documentos, mas pode criar uma função, escolher o código, executá-la e passar-lhe VaultReader na mesma conta. O serviço consegue assumir esse role e ler os documentos. A conclusão de leitura impossível seria incorreta porque ignoraria a composição dessas capacidades.

O ensaio deve acompanhar quem controla o código, quem autoriza a criação, que role é passado e o que o serviço consegue fazer. Para investigar operações históricas, procura a criação ou alteração do recurso que recebeu o role: PassRole é uma permissão, não uma chamada de API com evento autónomo.

Limitar apenas a duração da sessão reduz uma janela, mas não elimina a capacidade descrita enquanto a sessão é válida.

Distinguir origem do serviço e cobertura dos registos

Um bucket de logs autorizado para a conta A pode continuar demasiado aberto se o requisito permite apenas o trail T dessa conta. A identidade do serviço e a conta de origem não distinguem necessariamente T de outro trail; avalia a condição de recurso de origem suportada.

Separadamente, a ausência de GetObject num trail não prova ausência de leituras. No exercício, o seletor cobre apenas escrita em /inbound/, mas a auditoria pergunta por leitura em /archive/. Corrigir só o prefixo deixa a operação fora do seletor.

O ensaio de aceitação usa um objeto sintético no prefixo certo, executa a leitura autorizada e confirma o evento recebido. Documenta o atraso observado e o período de retenção sem inventar uma garantia universal de entrega.

Explicar uma divergência entre simulação e ambiente

Uma simulação Allow e um teste AccessDenied podem avaliar conjuntos diferentes de políticas. No exemplo, a simulação omitiu a SCP existente no destino. Regista identidade, ação, recurso, condições, políticas incluídas, hora e versões de ambos os ensaios.

Depois identifica a diferença que prevê os resultados. Repetir a mesma simulação não acrescenta a regra ausente; retirar a SCP para obter sucesso pode comprometer o objetivo que ela protege. Define com a equipa responsável um novo ensaio autorizado, preservando os controlos necessários.

O simulador ajuda a decompor hipóteses. O resultado observado num ambiente também tem âmbito: uma operação permitida num recurso de teste não demonstra automaticamente todas as combinações da conta de produção.

Caso guiado: manter custos e manutenção separados

Retoma o serviço de custos, com Meter, Repair e o serviço de jobs na mesma conta AWS. Meter lê custos, mas também cria jobs com código escolhido pelo prestador e passa Repair, que escreve dados. A correção precisa de resolver duas causas: o broker aceita contexto de cliente escolhido pelo pedido e Meter controla um caminho de escrita através de Repair.

No desenho proposto, o broker associa o contexto ao cliente autenticado e Meter perde criação de jobs e PassRole; a manutenção conserva o seu caminho independente. Testa cliente correto, cliente trocado, tentativa de escrita delegada e manutenção autorizada.

Uma recusa global sobre Repair poderia proteger os dados e simultaneamente falhar continuidade operacional. A conclusão deve declarar quais critérios ficaram demonstrados, quais resultados faltam e quem decide a aceitação.

Prática local: comparar cinco desenhos de delegação

Descarrega e extrai o laboratório desta aula. O README apresenta o exercício em português e inglês; começa pelo modelo de delegação, policy_model.py. Antes de executar, prevê quatro resultados para cada configuração: leitura pelo cliente correto, acesso com contexto trocado, escrita indireta pelo prestador e manutenção interna.

Compara original, broker-only, meter-only, global-write-deny e separated-paths. Explica por que motivo eliminar toda a escrita não satisfaz o requisito de continuidade. O modelo calcula apenas as arestas Boolean fornecidas: não interpreta políticas IAM, não emite credenciais e não chama AWS.

Na passagem para um ambiente real, terias de comprovar cada aresta e a ausência de caminhos adicionais com a autorização apropriada. Regista esses pressupostos no teu papel de trabalho.

Avaliar o caminho que responde a partir da cache

Um controlo correto na origem não protege uma resposta que nunca chega a essa origem. Num serviço partilhado, examina a chave de cache, a origem fiável do contexto de cliente e a autorização aplicada antes de servir uma resposta. IDs de relatório podem repetir-se entre clientes.

Uma cache indexada só pelo caminho pode devolver dados de um cliente a outro mesmo quando a origem verifica corretamente ambos. Corrigir a chave exige também tratar as entradas antigas que não conservam a separação. Reduzir a duração limita exposição, mas não prova isolamento quando qualquer leitura cruzada é proibida.

Exercício: aquece a cache com um cliente e repete o mesmo ID com outro, num ambiente e com dados autorizados; confirma também que ambos continuam a ler os seus dados. Resumo: inclui caminhos rápidos e estado já materializado no âmbito da proteção. Relaciona com arquitetura cloud, autorização e invalidação de dados.

Armadilhas comuns

Confundir limite com concessão; ignorar mudanças de principal; testar o predicado sem testar quem controla os atributos; tratar token emitido como operação autorizada; inferir ausência de atividade de logs não configurados.