APRENDER. PRATICAR. EVOLUIR.1. Identificar quem pede, quem decide e quem executa
Uma mudança fictícia de pagamentos falha com acesso negado e a primeira sugestão é conceder Owner. Antes de mudar permissões, desenha o percurso: workflow, identidade, emissão do token, confiança no destino, autorização do recurso e execução da ação. Regista a etapa que falhou e a identidade que a executou. O utilizador que iniciou a pipeline pode não ser a identidade de build nem a identidade cloud usada pela tarefa. No GitHub Actions, id-token: write permite pedir o token OIDC; não concede escrita no Azure. Um login bem-sucedido também não demonstra autorização para qualquer recurso. Pede evidência específica da operação pretendida, sem copiar tokens para tickets. Num relatório de L3, separa falha de autenticação de acesso insuficiente a um recurso identificado e indica quem gere cada configuração. Esta separação permite corrigir a causa sem tornar toda a subscrição acessível à pipeline.
2. Comparar a confiança com o contexto realmente emitido
O exemplo usa um repositório GitHub.com criado em setembro de 2026. O subject observado inclui IDs do proprietário e do repositório, enquanto o destino ainda espera só nomes. A referência atual descreve o formato imutável aplicável a novos repositórios desde julho de 2026, com diferenças para repositórios anteriores e exclusão de GitHub Enterprise Server. Não transformes um template antigo numa regra universal. Confirma a configuração aplicável e a correspondência dos campos antes de alterar confiança. A adoção de um environment pode também mudar o contexto do subject. Se a intenção era permitir apenas main, mantém essa intenção através dos controlos apropriados do environment, em vez de assumir que o nome Production prova a branch. No exercício, issuer e subject estão corretos, mas audience diverge. Corrige a correspondência pretendida e ensaia o acesso autorizado. Aumentar uma função Azure não corrige uma credencial federada que não corresponde ao token.
3. Dar acesso explícito às dependências entre projetos
A pipeline do projeto A precisa de ler Tools em B. Após limitar a identidade ao projeto, o clone deixa de funcionar. Confirma a identidade de build, o acesso necessário ao projeto de destino e Read no repositório específico. Voltar a uma identidade de collection pode esconder a dependência mal configurada e alargar muito mais acesso do que o necessário. Com proteção de repositórios Azure Repos em YAML, revê também a declaração explícita do checkout e a autorização da pipeline. O acesso do utilizador humano ao portal não prova que o job tem acesso equivalente. Durante o handover, mantém um inventário com repositório, motivo da leitura, identidade consumidora e responsável pela autorização. Inclui dependências indiretas quando existirem. Ao retirar uma dependência, revê a permissão que deixou de ser necessária. O resultado pretendido é um percurso reproduzível e restrito, não apenas um clone que passou uma vez.
4. Separar rotação de valores e seleção de nomes
Um variable group ligado ao Key Vault seleciona nomes de segredos. Na nova execução, um valor atualizado de um nome já mapeado pode ser obtido em runtime; criar api-password-next não acrescenta automaticamente esse novo nome à seleção do grupo. O exercício pede que identifiques qual dos dois tipos de alteração ocorreu. Antes de editar scripts, verifica mapeamento, acesso e evidência da obtenção, sem imprimir valores. Para uma pipeline nova que usa um grupo com segredos, autoriza o consumidor específico e revê quem pode alterar o código que os utiliza. Open access não é uma forma neutra de eliminar pedidos de autorização. O contrato operacional deve indicar quem roda a credencial, quem atualiza consumidores e como se confirma funcionamento sem divulgar o segredo. Se uma credencial já apareceu num log, corrigir a próxima execução não invalida o valor exposto. Trata a rotação ou revogação e o acesso ao log pelo processo de resposta.
5. Manter dados não confiáveis fora da geração de código
O título de um PR parece texto descritivo, mas pode ser controlado por alguém externo. Se a expressão for interpolada diretamente no script gerado, o título participa na construção de código que o runner executa. Para a verificação de prefixo do exercício, passa o valor por uma variável de ambiente intermédia e trata-o como dados, com expansão entre aspas. Não uses eval para voltar a interpretar o conteúdo. Reduzir permissões do token ajuda a limitar operações, mas não corrige por si só essa interpretação indevida. Na revisão de um workflow, pergunta quais os campos que vêm do PR, onde são expandidos e que processos os consomem. Pede exemplos benignos com espaços e aspas para discutir a diferença entre texto e instrução. O objetivo pedagógico é reconhecer a fronteira, não executar comandos fornecidos por um autor externo. Aplica o mesmo raciocínio a nomes de branches e outros metadados recebidos.
6. Separar validação externa de execução privilegiada
No cenário, pull_request_target tem segredos de deployment e faz checkout do head de um PR externo. Fixar a action de checkout por SHA não torna confiável o código que ela obtém. Separa a validação de contributos externos do job privilegiado e não executes scripts desse head com segredos de produção. Trocar apenas o evento para workflow_run também não resolve conteúdo não confiável recebido como artefacto. Segue a cadeia do produtor até ao consumidor. Um segundo risco aparece quando os dois contextos partilham um runner persistente. Limpar o workspace não prova que o sistema operativo, os processos e os acessos ficaram repostos. Uma aprovação de environment é uma decisão de acesso, não uma limpeza do host. Planeia fronteiras de execução e evidência de ambiente limpo adequadas ao risco, incluindo quem pode agendar trabalho no runner e a que serviços esse host consegue chegar.
7. Resolver o caso sem confundir hipótese e evidência
O caso de pagamentos deixa quinze minutos de janela e não demonstra que o runner ficou limpo depois do PR externo. Suspende a entrega nesse host e procura um percurso confiável, com os responsáveis pela mudança e pela segurança. A evidência permite afirmar que a integridade não foi demonstrada; não permite declarar automaticamente que houve compromisso. Preserva os registos necessários para investigar. Rodar um segredo e colocar logo o novo valor no mesmo runner pode repetir a exposição. Se não houver alternativa pronta dentro da janela, adia a mudança e comunica o impacto, o responsável e as condições para retomar. O pacote aprovado pode continuar a ser o pretendido, mas ainda precisa de um executor confiável. Para valores sensíveis derivados, evita logs e revê a ocultação explícita das transformações quando aplicável. Base64 é uma codificação, não uma autorização para publicar credenciais.
8. Ensaiar uma decisão com pressupostos explícitos
O modelo local abaixo compara três campos fornecidos e quatro condições de decisão. Não valida JWT, assinatura, expiração ou autenticidade; também não faz login nem aplica RBAC. Os dados são fictícios e a confiança criptográfica é um pressuposto externo, não um resultado do código. Antes de executar, prevê o efeito de uma audience diferente e de um subject antigo sem IDs. Depois mantém os campos iguais e troca host_clean para falso. A aprovação continua verdadeira, mas a decisão não deve permitir a entrega. As dezasseis combinações mostram que cada condição pode bloquear independentemente. Usa o exercício para construir uma tabela de evidências reais que precisarias de recolher para preencher cada entrada. Fecha a aula com identidade, recurso, contexto de código, estado do executor e próximo responsável. Relaciona este modelo com a aula de artefactos: confiar nos bytes do pacote é uma dimensão diferente de confiar em quem os executa.
# Fictional decision model over supplied facts; no JWT validation or cloud login.
# Signature, expiry and authenticity are explicitly assumed, never checked here.
# Do not use this exercise as an authentication or authorization implementation.
from itertools import product
def trust_fields_match(observed, expected):
fields = ('iss', 'sub', 'aud')
return all(expected.get(k) and observed.get(k) == expected[k] for k in fields)
def release_ready(fields_match, resource_authorized, host_clean, change_approved):
return all((fields_match, resource_authorized, host_clean, change_approved))
expected = {'iss': 'https://token.actions.githubusercontent.com',
'sub': 'repo:dr-lab@110/funds@220:ref:refs/heads/main',
'aud': 'api://AzureADTokenExchange'}
assert trust_fields_match(dict(expected), expected)
assert not trust_fields_match({**expected, 'aud': 'another-service'}, expected)
assert not trust_fields_match({**expected, 'sub': 'repo:dr-lab/funds:ref:refs/heads/main'}, expected)
assert not trust_fields_match({**expected, 'iss': 'https://example.invalid'}, expected)
assert not trust_fields_match({**expected, 'sub': expected['sub'].replace('main', 'Main')}, expected)
assert not trust_fields_match({}, expected)
assert not trust_fields_match(dict(expected), {})
assert release_ready(True, True, True, True)
assert not release_ready(True, False, True, True)
assert not release_ready(True, True, False, True)
assert not release_ready(True, True, True, False)
assert not release_ready(False, True, True, True)
combinations = list(product((False, True), repeat=4))
assert len(combinations) == 16
assert [c for c in combinations if release_ready(*c)] == [(True, True, True, True)]
print('14 checks and 16 decision combinations passed; supplied facts, not authenticated tokens')
A aprovação da mudança está concluída, mas o runner persistente executou código de um PR externo e não há prova de limpeza do host. O aluno decide como conter o risco e retomar uma entrega autorizada.
Armadilhas comuns
Aumentar funções para resolver mismatch de tokens; assumir subject universal; abrir grupos a todas as pipelines; confundir rotação com novo nome; confiar em código externo por causa do evento; tratar aprovação como limpeza do host.
Tópicos relacionados: Privilégio mínimo · Resposta a exposição de segredos · Supply chain de software · Gestão de mudanças
Confirma identidade, confiança e autorização em separado. A entrega exige também código e executor confiáveis; a pressão da janela não substitui essa evidência.
Referência: Configuring OpenID Connect in Azure · AZ-400 objectives 2026-07-27