← SecurityX/CASP+: arquitetura e operação segura
13 / 15 · 65 MIN

Revogação, chaves e evidência operacional

Distingue validade criptográfica, estado atual de acesso e propagação de alterações.

Uma assinatura não consulta o estado atual

Um operador sai da equipa, mas o seu access token ainda não expirou. A assinatura continua matematicamente válida: desativar a conta não altera os bytes já assinados. Se o recurso só verificar assinatura e prazo, pode continuar a aceitar o token até expirar. A arquitetura precisa de uma estratégia explícita para alterações de estado, proporcional ao risco e à disponibilidade requerida. Pode combinar tokens curtos, consultas de estado, revogação e distribuição de eventos. Nenhuma dessas opções deve ser assumida apenas por existir SSO. Identifica onde a decisão é aplicada, que informação usa, durante quanto tempo pode ficar desatualizada e quem confirma a propagação quando um acesso é retirado.

Ver a diferença entre identidade e mecanismo

O laboratório inclui jti, mas aceita o mesmo token duas vezes enquanto este cumpre as regras. O identificador não cria automaticamente uma cache de replay nem uma lista de revogação. Quando o exercício acrescenta o par emissor e jti à denylist, o mesmo token passa a ser recusado. Uma cópia antiga da lista continua a aceitá-lo. Isto demonstra uma consequência lógica de informação desatualizada, sem medir uma infraestrutura distribuída. O recurso também recusa um sujeito que deixou de estar ativo no estado consultado. Mantém separados o identificador do token, a conta, o grant e a chave de assinatura: mudar um deles pode ter efeitos diferentes sobre credenciais já emitidas.

Escolher a frescura com impacto conhecido

A introspeção permite ao recurso consultar informação sobre um token, mas acrescenta uma dependência. Guardar respostas em cache reduz tráfego e latência, criando uma janela em que o estado pode mudar sem a decisão o refletir. O RFC 7662 exige que uma resposta com exp não seja mantida para além desse instante. Um tempo de cache inferior a exp ainda pode ser demasiado longo para o risco do serviço. Define também o comportamento quando a consulta falha. Neste exercício, a ausência de estado necessário produz recusa; isso não demonstra que a continuidade do negócio esteja resolvida. O plano operacional deve incluir observabilidade, diagnóstico, recuperação da dependência e eventual procedimento de exceção com âmbito e autoridade explícitos.

Separar rotação planeada de resposta a compromisso

O ensaio começa com a chave old no conjunto de confiança. Tokens assinados com new são recusados até essa chave ser publicada no conjunto local. Durante a sobreposição, ambas são aceites; depois de retirar old, os tokens antigos são recusados mesmo que exp ainda esteja no futuro. Não existe obtenção remota de JWKS neste laboratório. Numa rotação planeada, coordena emissão, distribuição de confiança, caches e validade das credenciais existentes. Num compromisso, prolongar confiança na chave antiga pode prolongar a capacidade de produzir tokens aceites. A decisão precisa de considerar exposição e interrupção, com responsáveis e critérios definidos. Não confundas apagar a chave privada no emissor com removê-la de todos os validadores.

Preparar diagnóstico sem expor credenciais

O evento sintético regista identificador do pedido, ação, recurso, decisão e versão da política. Não inclui bearer, chave privada ou conjunto completo de claims. Em produção, aplica classificação e retenção aos próprios metadados, que também podem revelar atividade sensível. Um pico de recusas após rotação pode indicar chave não distribuída; após mudança de configuração, pode indicar audience ou scope divergente. Correlaciona a categoria de falha com a mudança antes de desativar controlos. No handover, entrega procedimentos para expiração, deriva de relógio, indisponibilidade de estado e revogação urgente, com critérios de escalada. Os 51 checks locais são evidência do modelo; não provam o SLA de propagação, segurança de um IdP ou resistência a replay de uma API real.

# Compare current and stale authorization state using the same synthetic token.
# A valid signature does not query revocation or subject status.
# No remote identity provider or introspection endpoint is used.
NA PRÁTICA

A denylist atualizada recusa o token; a cópia antiga aceita-o. Retirar a chave old também o recusa, independentemente da expiração futura.

Armadilhas comuns

Jti como prevenção automática de replay; logout como revogação universal; apagar a chave no emissor como retirada de confiança; cache sem limite.

Tópicos relacionados: Fronteiras de confiança · Autorização de APIs · Revogação e operação

Leva esta ideia contigo

A retirada de acesso precisa de mecanismos, propagação e evidência nos pontos de decisão.

Criar conta

Referência: OAuth 2.0 Token Introspection · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17

CompTIA® e CASP+ são marcas comerciais ou marcas registadas de CompTIA, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por CompTIA. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.