APRENDER. PRATICAR. EVOLUIR.Escolher o serviço pela credencial necessária
Um portal fictício permite que parceiros consultem posições e carreguem documentos. Desenha primeiro o caminho: navegador, login, API, armazenamento. Um user pool Cognito autentica utilizadores e emite tokens para a aplicação; um identity pool pode trocar identidade federada por credenciais AWS temporárias, limitadas por IAM. Se o navegador só chama a API, não precisas de lhe conceder acesso direto ao bucket. Se existe uma necessidade justificada de upload direto, define o recurso e as operações permitidas na função temporária. Regista separadamente quem administra utilizadores, quem aprova permissões e quem revoga o acesso do parceiro.
Validar o token e depois a operação
Ler JSON de um JWT não verifica a assinatura. Usa uma biblioteca adequada, com emissor esperado, chave de assinatura, expiração, tipo de token e cliente configurados. Num ID token, confirma aud; num access token Cognito, confirma client_id e os scopes exigidos, além de quaisquer restrições de audience do desenho. Um token assinado para outro cliente não se torna aceitável por vir do mesmo pool. No exercício, positions.read permite consulta, não submissão de ordens. Mesmo um scope correto não decide sozinho a titularidade do fundo: a API deve aplicar as regras de acesso aos objetos. Estas regras de negócio são decisões do nosso desenho fictício.
Desenhar o percurso de login no navegador
Uma aplicação executada apenas no navegador não consegue guardar um client secret confidencial. Para o cliente público deste exemplo, usa authorization code com PKCE e S256, o método suportado pelo Cognito. Guarda o verifier associado à transação e apresenta-o na troca do código; não o confundas com um segredo permanente do cliente. O callback enviado deve corresponder ao URI previamente registado. Uma mudança de /callback para /login/return exige rever essa configuração. No ensaio de aceitação, inclui callback não registado, código sem verifier correto e cliente incorreto. O responsável de produção precisa de saber a quem encaminhar cada falha, sem copiar tokens para o relatório.
Percorrer a ordem e o âmbito do WAF
No web ACL, começa pela prioridade numérica mais baixa. Count regista uma correspondência e deixa a avaliação continuar; Allow e Block terminam-na. Assim, um Allow demasiado amplo antes de uma regra de bloqueio pode impedir que essa regra seja avaliada. Para CloudFront, configura o âmbito global em us-east-1; para um ALB regional, usa a região do ALB. Cada recurso associa-se a um único web ACL, embora este possa conter várias regras e grupos. Duas equipas devem combinar as suas proteções nesse desenho, não tentar associar um segundo ACL. Segue manualmente o pedido até à ação final antes de alterar prioridades.
Compreender os limites de inspeção
Um limite por IP agrega os utilizadores que partilham esse endereço, como colaboradores atrás do mesmo NAT. O rate limiting WAF é aproximado e não serve como contador exato de uma quota comercial. Para um IP vindo de header, distingue ausente, inválido e válido: numa condição positiva simples, o header ausente não corresponde e não usa fallback; NOT inverteria esse resultado. Confirma quem escreve o header, pois o cliente pode falsificá-lo se a fronteira não o impedir. Continue numa inspeção de corpo demasiado grande examina apenas a parte disponível. Define o tratamento de uploads legítimos e dos bytes não inspecionados antes de aprovar a política.
Entregar proteção utilizável à produção
Antes do bloqueio, testa regras em ambiente de ensaio e observa Count com tráfego representativo. Investiga uma correspondência num upload legítimo; ajusta a regra específica e repete a aceitação, em vez de criar um Allow geral que evita outras inspeções. Associar WAF ao CloudFront não fecha automaticamente o acesso direto ao ALB. No exemplo de origem pública, o desenho inclui restrições de rede e header secreto validado pelo listener, protegido por HTTPS; testa também o caminho direto. Por fim, redigir um header nos logs WAF não o oculta nas amostras: configura proteção de dados para sampling ou desativa-o. Entrega responsáveis, métricas e condição de rollback ao RUN.
Oficina: o token tem positions.read, mas o pedido submete uma ordem. A API deve rejeitar a operação. Depois segue duas regras WAF que correspondem ao mesmo upload: prioridade 10 Allow e 30 Block. O resultado é Allow; o Block não é alcançado. Altera a exceção para que não autorize todo o parceiro antecipadamente e define um teste de regressão para o upload legítimo e outro para o pedido malicioso. Valores, regras e parceiros são fictícios.
Armadilhas comuns
Confundir JWT com credenciais IAM; confiar em decode sem verificar assinatura; aceitar outro aud; esconder um segredo no JavaScript; considerar Count um bloqueio; tratar um IP como uma pessoa; confiar num header enviado pelo cliente; supor inspeção integral de uploads; ocultar logs e esquecer sampling.
Tópicos relacionados: Identidade, confiança e permissões · Proteção e recuperação de dados · CloudFront: cache, privacidade e origem
Decide separadamente quem é o utilizador, o que pode fazer e quais os pedidos que atravessam a proteção. Aceita a solução com exemplos permitidos e recusados, limites de inspeção explícitos e um procedimento de recuperação. A oficina é documental; não executa Cognito ou WAF na AWS.
Referência: Amazon Cognito user pools · SAA-C03