O cache da LACNIC ganha tempo sem receber uma nova decisão de acesso

Resumo

• O cliente PAI publicado pela LACNIC usa um cache de permissões com duração de dois minutos. Em uma falha de atualização abrangida pelo tratamento previsto, pode reiniciar esse prazo e devolver os mesmos dados.
• O teste incluído espera essa continuidade diante de JSON malformado. Uma negativa nova, decodificada corretamente, cria uma entrada nova e substitui a anterior.
• A leitura não comprova implantação em produção, persistência de um acesso revogado nem invasão. Mostra que a última renovação do cache não é necessariamente a última decisão de autorização.

A negativa que não deve desaparecer da análise

Há um detalhe que precisa vir antes da crítica: se o cliente recebe e consegue decodificar uma resposta nova de autorização, ele armazena os dados novos. Isso também vale para uma resposta negativa. Não seria correto apresentar o mecanismo como uma regra que sempre deixa o acesso antigo vencer uma recusa atual.

O caso interessante ocorre quando a tentativa de atualizar não produz uma resposta que o caminho previsto consiga ler. O cliente pode então recorrer ao resultado anterior. A continuidade mantém o trabalho em andamento, mas não faz a autoridade de origem tomar uma decisão nova. O problema passa a ser explicar quanto tempo aquele resultado já tem.

Esta análise está fixada no commit b85523718bfdbd834c85add8e06c3b4a1b813e59 do repositório público pai-auth-ws-client, observado na sua branch principal em 14 de setembro de 2026. O README descreve um cliente Java para autenticação, autorização e funções de sessão do PAI. A descrição estabelece a finalidade do projeto. Não estabelece quais aplicações instalaram essa versão.

Um repositório público permite uma leitura reproduzível do código. Não permite saltar diretamente para uma contagem de usuários afetados, uma cronologia de implantação ou uma afirmação sobre todos os serviços da LACNIC. Para isso seria necessário ligar versão, aplicação e ambiente, além de examinar o que cada consumidor valida depois de receber os dados.

O que o prazo de dois minutos mede

Em PortalWSClient, as entradas ficam em uma ConcurrentHashMap estática e local ao processo. A chave é o token fornecido à chamada. Cada entrada guarda um objeto TokenData e um timestamp modificável. A constante CACHE_DURATION_MS define os dois minutos, e a expiração compara a hora atual com esse timestamp.

Enquanto a entrada não expirou, a chamada retorna o que já está guardado. Nesse caminho, o método não busca uma nova resposta em /authorization. É uma função normal de cache: economiza chamadas e evita que uma pequena oscilação na dependência afete todo pedido. A existência dessa otimização, sozinha, não demonstra uma deficiência de controle de acesso.

Ao expirar, a entrada é removida do mapa. Entretanto, o método ainda mantém uma referência local ao objeto antigo durante a tentativa de obter e decodificar o substituto. Remover do mapa compartilhado não é apagar aquilo que a execução atual ainda tem em mãos. Essa referência permite que o tratamento de falha encontre o resultado anterior.

Uma resposta nova decodificada com sucesso gera uma entrada nova. Se ocorrer uma IOException abrangida pelo bloco externo e houver a referência antiga, o método chama cached.extend(). A extensão muda o timestamp para a hora corrente, recoloca a entrada no mapa e devolve seus dados anteriores. Não há uma nova decisão de autorização decodificada nesse passo.

O recipiente acaba de ganhar outro período de dois minutos. A resposta dentro dele não ganhou uma confirmação equivalente. Caso ocorram novas falhas desse mesmo tipo em tentativas posteriores, o caminho pode se repetir. Essa classe não guarda separadamente uma data imutável da resposta original bem decodificada, um teto absoluto contado desde ela ou um contador de extensões.

É importante manter o sujeito dessa observação: a classe examinada. Uma aplicação que a utilize pode impor um limite próprio. Pode registrar a idade da última resposta e exigir uma verificação adicional. A ausência de tais campos no cache não prova a ausência de todas as proteções possíveis no sistema que o envolve.

O teste protege uma intenção legítima

O caso testGetTokenDataReturnsCachedDataWhenRefreshFails, em PortalWSClientTest, começa com uma resposta HTTP simulada que produz dados positivos de autenticação. Depois coloca artificialmente a data da entrada cinco minutos no passado. A próxima resposta simulada traz JSON malformado.

As asserções esperam o mesmo objeto autenticado e duas execuções HTTP. Os cinco minutos não são uma duração observada em produção: são um ajuste da preparação do teste. Para esta reportagem, o arquivo foi lido, mas o teste não foi executado. Nenhum endpoint de autorização em produção foi consultado e nenhum token real foi empregado.

Ainda assim, a expectativa é evidência útil. O código quer preservar o resultado anterior nessa situação. A continuidade não é apenas um efeito que o leitor imaginou ao examinar a exceção; é um comportamento defendido pelo teste incluído no projeto. Ignorar isso levaria a uma avaliação injusta do objetivo de engenharia.

Uma dependência temporariamente ilegível não significa que todas as pessoas perderam seus direitos. Encerrar imediatamente sessões legítimas pode multiplicar o impacto de um defeito restrito. Aceitar por algum tempo o último resultado é uma decisão plausível. O ponto a explicitar é a origem desse tempo, seu limite e o conjunto de operações que ainda podem continuar.

Também existe um aviso de log sobre o uso temporário do cache estendido. Portanto, não cabe dizer que o mecanismo é inteiramente silencioso ou que não há nenhum sinal para observá-lo. Operadores podem monitorar esse aviso. O aviso, porém, não acrescenta ao objeto retornado uma data da última decisão bem recebida.

O consumidor recebe dados, não um histórico

TokenData contém estado de autenticação, token, papéis, erro e ipAllowed. Não expõe uma classificação de frescor, a hora da última resposta bem-sucedida ou uma marca de retorno do valor antigo durante falha. Esses campos não contam, por si, a idade da decisão preservada.

Há três coisas diferentes a comprovar: que o token está dentro de sua validade, que o cache está dentro de sua janela atual e que os papéis continuam válidos no emissor. O prazo de uma delas não certifica as demais. Renovar o timestamp do cache não responde quando uma mudança de permissões administrativa deve passar a valer.

O consumidor pode verificar o vencimento criptográfico do token, aplicar restrições de IP, guardar datas fora do cliente ou buscar outra confirmação antes de uma escrita sensível. São possibilidades que esta leitura não comprova nem exclui. Tampouco é correto imaginar uma operação não autorizada apenas porque o teste devolve o mesmo objeto positivo.

O resultado do cliente e a decisão final da aplicação são dois pontos de observação diferentes. Entre eles podem existir controles próprios. Para avaliar consequências reais, é preciso examinar essa ligação, em vez de preencher suas lacunas com uma acusação ou com uma garantia de segurança igualmente não demonstrada.

Nem toda falha segue o mesmo caminho

O teste fornece JSON malformado. Isso não cobre automaticamente ausência de corpo, falhas de conexão e todos os erros de transporte. readUrlToken captura exceções mais amplamente e pode retornar null; o tratamento externo que prolonga a entrada captura IOException. Não se executaram aqui esses diferentes caminhos.

Por isso, dizer que o cliente sempre funciona quando o serviço cai exageraria a garantia de disponibilidade. Dizer que qualquer falha mantém acessos revogados exageraria o risco. Ambas as frases confundiriam o caso publicado com ambientes e validações que não foram investigados.

Outra delimitação aparece em PortalHttpClient, que constrói o cliente usando TrustAllStrategy e NoopHostnameVerifier. Nessa implementação auxiliar, uma URL HTTPS e um conteúdo decodificado não comprovam, sozinhos, verificação criptográfica da identidade do emissor por esse componente.

Esse é um achado separado sobre o código, não uma auditoria de TLS em produção nem evidência de interceptação. Sua importância para a idade é definir o que pode contar como uma resposta confiável. Uma política que conserva a última resposta autenticada precisa especificar a autenticação da origem, não apenas registrar quando chegaram bytes legíveis.

Uma carência que possa ser explicada

Uma interface mais clara manteria separadas a hora da última resposta de autorização autenticada e bem decodificada e a hora do último toque no cache. Prolongar uma entrada mudaria apenas a segunda. O chamador poderia distinguir dados novos, dados aceitos durante uma carência e indisponibilidade, sem deduzir tudo de um estado de autenticação positivo.

O limite da carência poderia ser absoluto, contado desde a resposta confiável. Novas falhas não reiniciariam esse limite. A tolerância também poderia variar por operação: uma leitura reversível não exige necessariamente o mesmo tratamento de uma mudança administrativa irreversível. São exemplos de classes de decisão, não a identificação de funções da LACNIC que executem este caminho.

Logs poderiam relacionar avisos, idade da resposta e modo degradado sem armazenar tokens brutos. Uma resposta confiável nova encerraria a carência; uma negativa fresca continuaria negativa. Essas são propostas editoriais, não medidas anunciadas pela LACNIC. O objetivo não é abolir o cache, e sim evitar que um recipiente renovado seja tratado como um direito recém-confirmado.

Fontes

As cinco fontes primárias ligadas acima são o README, PortalWSClient, PortalWSClientTest, TokenData e PortalHttpClient, no mesmo commit. Elas permitem analisar uma implementação pública e um cenário simulado. Não estabelecem execução dos testes, adoção em produção, comprometimento de credenciais, contorno de revogação ou operação sem autorização.