APRENDER. PRATICAR. EVOLUIR.1. Escolher a identidade certa
Num portal fictício de operações, separa três necessidades: autenticar uma pessoa, obter credenciais para serviços AWS e autorizar uma ação da aplicação. Um user pool Cognito fornece o diretório e tokens OIDC; um identity pool pode fornecer credenciais AWS temporárias associadas a roles. Não introduzas credenciais AWS no browser se o desenho apenas exige chamar a tua API com um token. Para um batch sem interação humana que usa o token endpoint, considera client credentials e scopes próprios com um segredo protegido. Esse fluxo representa a máquina, não um operador. O inventário do projeto deve indicar quem emite cada credencial, onde é validada, quem gere a sua duração e que operações permite. Uma resposta a estas perguntas evita tratar todos os tokens como equivalentes.
2. Interpretar claims no contexto correto
Uma role de identity pool precisa de limitar a origem através de aud. Nesse contexto, aud é o ID do identity pool; amr distingue authenticated de unauthenticated e sub identifica a identidade desse pool. O sub original do user pool não é intercambiável. Uma role guest com escrita privada continua perigosa mesmo que as sessões sejam curtas. Nos JWTs do user pool, a assinatura deve ser verificada antes de confiar em grupos e outros claims. Confirma issuer, destinatário, validade e token_use conforme o contrato. Em ID tokens, aud identifica o app client; em access tokens sem resource binding, verifica client_id. Guarda um exemplo fictício de cada contexto no runbook e identifica claramente que verificador o processa.
3. Tratar rotação e revogação
Descodificar um JWT revela conteúdo, mas não demonstra integridade. Usa uma biblioteca de verificação adequada e chaves obtidas da origem confiável. Um kid desconhecido pode refletir rotação legítima: atualiza a cache JWKS do pool esperado e verifica novamente, sem aceitar o token só porque o texto de issuer parece correto. Assinatura válida e expiração futura também não detetam, por si só, uma revogação posterior. Define o prazo de corte de acesso e o mecanismo que o sustenta; não prometas corte imediato com uma verificação exclusivamente offline. Para authorization code com PKCE, preserva o verifier original até à troca do código. Gerar outro verifier nesse momento quebra a relação com o challenge enviado. Nunca uses tokens reais nos exemplos partilhados da reunião de incidente.
4. Expressar a regra da API
No HTTP API JWT authorizer, aud tem precedência sobre client_id quando ambos existem. O mesmo authorizer não distingue universalmente ID tokens de access tokens; scopes apropriados ou valores exclusivos de issuer/audience ajudam a expressar o contrato. Uma lista de authorizationScopes aceita pelo menos um dos scopes, não exige todos. Se a regra de release exige duas condições simultâneas, essa lista não basta. Não deduzas permissões a partir dos nomes GET e POST sem configuração. Na rotação de chaves do IdP, considera a cache pública do API Gateway e uma sobreposição de validade. No ensaio, apresenta tokens com destinatário errado, scope insuficiente e finalidade errada, além do caso permitido. O teste negativo demonstra a restrição que o sponsor realmente aprovou.
5. Delimitar decisões em cache
Um Lambda authorizer de HTTP API pode reutilizar resultados através das identity sources. Com simple responses, um booleano em cache aplica-se aos pedidos que correspondem à mesma chave. Se consulta e release exigem regras diferentes, acrescenta routeKey à chave e avalia a rota, ou usa uma política granular adequada. Reduzir TTL limita a duração da falha, mas não corrige partilha indevida entre rotas. Um header obrigatório ausente produz 401 antes da invocação; um 500 com erro de permissão de invocação aponta para a integração do authorizer. O exercício abaixo demonstra colisões numa cache fictícia, não valida JWTs nem implementa um authorizer pronto para produção. Para revogação, considera igualmente quanto tempo uma decisão antiga pode continuar a ser reutilizada.
6. Reduzir permissões com evidência suficiente
Uma ausência no relatório não tem sempre o mesmo significado. Unused access respeita uma janela configurada e a idade das permissões; uma permissão recente pode ainda não ser avaliada. Service last accessed inclui tentativas negadas, e action last accessed não cobre data-plane events. Para concluir que houve leitura, procura os eventos relevantes e o resultado. Para retirar acesso, combina observação com os ciclos reais, incluindo fechos trimestrais e recuperação de incidentes. A política gerada a partir de CloudTrail também tem limites: iam:PassRole não é incluído. Trata-a como candidata a rever e ensaiar. Um plano de redução deve identificar o owner de cada exceção, o fundamento da dependência e a data em que essa justificação será reavaliada.
7. Entregar um controlo que possa ser demonstrado
ValidatePolicy ajuda a encontrar problemas de gramática e boas práticas. CheckNoNewAccess compara uma política proposta com uma referência para procurar acesso adicional. Nenhum deles substitui todos os testes funcionais no contexto de políticas e condições reais. Uma API key de usage plan também não substitui autenticação e autorização; as quotas são best effort, não uma garantia rígida de custo. No resumo para APS, liga cada requisito a uma prova: login, operação permitida, operação negada, comportamento após alteração de permissões e diagnóstico de erros. Mantém registos sem segredos e indica responsáveis por IdP, gateway e aplicação. A conclusão desta aula é uma autorização delimitada por identidade, operação e tempo, com evidência de que as restrições continuam válidas quando a cache ou as chaves mudam.
# Original fictional cache-key model, not a JWT verifier or AWS authorizer.
# No credentials, network calls, or AWS changes.
def key(identity, route, per_route):
return (identity, route) if per_route else (identity,)
def allowed(route):
return route == "GET /status"
cache = {key("demo-user", "GET /status", False): True}
assert cache[key("demo-user", "POST /release", False)] is True
scoped = {key("demo-user", "GET /status", True): True}
assert key("demo-user", "POST /release", True) not in scoped
assert allowed("GET /status") is True
assert allowed("POST /release") is False
assert key("other-user", "GET /status", True) not in scoped
print("five cache-scope cases passed; no token was verified")
Uma consulta preenche a cache e permite indevidamente uma release. O ensaio por rota revela a diferença entre login válido e operação autorizada.
Armadilhas comuns
aud fora de contexto; descodificar como verificar; scopes como AND; ausência de tracking como desuso provado.
Tópicos relacionados: Identidade e dados · Aceitação e continuidade
Autentica a identidade e demonstra autorização da operação no contexto e durante o período pretendidos.
Referência: Amazon Cognito user pools · SCS-C03