Resumo

  • A versão de 28 de julho de 2026 acrescentou autenticação do Reg-RWS pelo cabeçalho Authorization. No dia seguinte, a ARIN encerrou a sugestão ACSP 2022.5, mas registrou que continuaria aceitando tokens enviados como parâmetros da URL.
  • As fontes públicas consultadas confirmam a alternativa mais segura e a recomendação de mudança, mas não apresentam data de retirada, marcos de migração, volume de chamadas pelo formato antigo ou taxa de adoção do cabeçalho. O encerramento documenta a entrega de uma funcionalidade; não demonstra que o transporte anterior acabou nem que os clientes migraram.

O encerramento de uma sugestão não encerra a migração

Uma chamada ao registro faz duas coisas distintas: aponta para o recurso que se quer consultar ou alterar e demonstra que quem chamou tem autorização. O Reg-RWS automatiza atividades que incluem gestão de RPKI e IRR, reatribuições e realocações, além de atualizações de blocos de rede. Por muito tempo, o formato documentado permitiu que a chave de API aparecesse na parte de consulta da URL. Em julho de 2026, a ARIN passou a oferecer outro caminho: a URL identifica o recurso e a credencial segue separada no cabeçalho Authorization.

O resultado da operação pode ser idêntico. O caminho percorrido pela credencial não é. URLs costumam parar no histórico do navegador, em registros de requisições, proxies e materiais de diagnóstico. Na explicação publicada em agosto, a própria ARIN cita histórico do navegador e logs de servidores e proxies como lugares onde uma chave na URL pode persistir. Transferi-la para um cabeçalho diminui a possibilidade de exposição acidental. Não torna o segredo invisível: uma aplicação, um proxy, um coletor de rastreamento ou um pacote de suporte ainda pode registrar o valor de Authorization se a configuração permitir.

O ganho é reduzir a exposição padrão, não dispensar o cuidado com credenciais.

A cronologia separa entrega e migração. A sugestão ACSP 2022.5 foi apresentada em 11 de fevereiro de 2022. Ela pediu uma alternativa ao envio do token na URL das chamadas REST e observou que sistemas que registram a URL completa podem expor uma chave válida a qualquer pessoa com acesso aos logs, criando a possibilidade de acesso não autorizado. O pedido não fixou prazo. Em 23 de fevereiro, a ARIN respondeu que o cabeçalho HTTP seria a melhor opção, incluiria o trabalho entre os itens a priorizar no roteiro de engenharia de 2023 e manteria a sugestão aberta até a implementação.

Em 28 de julho de 2026, a ARIN anunciou o uso de Authorization com o esquema ApiKey em chamadas REST. No dia 29, a resposta que encerrou a sugestão afirmou que a alternativa preferida havia sido implantada e que os tokens em parâmetros de URL continuariam aceitos. O pedido foi considerado cumprido porque a nova opção passou a existir; isso não significa que a opção anterior tenha sido desligada. A explicação técnica de 11 de agosto e o ARIN Bits de setembro repetem a mesma situação: o formato URL ainda é aceito, deverá ser retirado no futuro e a mudança já é recomendada.

Há, portanto, dois relógios. O primeiro mede a entrega institucional: a sugestão é recebida, avaliada, implementada e encerrada. O segundo mede a migração real: os clientes tomam conhecimento, localizam as integrações, mudam os programas, validam o novo formato, removem o token das URLs e param de usar o caminho antigo. O registro público dá uma data final ao primeiro relógio. Para o segundo, não apresenta prazo nem indicador de andamento.

Isso não torna incorreto encerrar a sugestão. Se a solicitação era acrescentar uma alternativa e ela foi entregue, o item pode ser concluído mesmo que os clientes precisem de tempo para adotá-la. A questão de governança começa depois desse ponto. Enquanto o método antigo continuar disponível, a transição deixa de ser apenas uma alteração de código e passa a ser um acordo operacional entre a ARIN e as organizações cujos scripts, plataformas de automação e fornecedores chamam o registro.

O que muda quando o token sai da URL

Uma chave API não é um campo comum da requisição. A ARIN a descreve como um segredo que identifica o usuário e observa que certas ações REST dependem de uma conta vinculada a um Point of Contact com a autoridade correspondente. Quando o token está na cadeia de consulta, ele viaja junto com o endereço do recurso. Qualquer sistema que armazene ou copie a URL pode conservá-lo depois que o processo original terminou. O histórico do navegador e os logs de servidores e proxies citados pela ARIN são exemplos concretos desse tipo de retenção acidental.

O novo método muda o local da credencial, não o objeto da chamada. A documentação da ARIN especifica o campo Authorization e o esquema ApiKey. O cliente, a ferramenta de automação ou o serviço de provisionamento precisa enviar esse campo sem alterar o endpoint ou a semântica do pedido. A URL deixa de carregar o segredo como mais um parâmetro.

Há um paralelo técnico útil, mas ele tem limites. O RFC 6750 da IETF trata de tokens bearer do OAuth, e não do esquema ApiKey da ARIN. O padrão recomenda o cabeçalho Authorization e desaconselha colocar esses tokens em parâmetros URI porque URLs têm alta probabilidade de serem registradas. Isso não quer dizer que o Reg-RWS use OAuth nem que o RFC se aplique diretamente à implementação da ARIN. O paralelo mostra uma diferença conhecida em operações HTTP: um valor sensível dentro do URI pode entrar em registros de uso geral com mais facilidade do que uma credencial em um campo próprio da requisição.

Um cabeçalho, por si só, não é uma política de segurança. Administradores podem registrar todos os cabeçalhos; ferramentas de rastreamento podem capturá-los; arquivos de depuração podem preservá-los; e um cliente pode voltar a colocar o segredo na URL antes de seguir um redirecionamento. A migração deve vir acompanhada de filtros para os valores de Authorization nos logs, armazenamento protegido das chaves, validação de certificados e um procedimento para substituir uma chave exposta. São controles do operador, não funções novas que este artigo atribui à ARIN.

O trabalho também varia muito entre organizações. Uma equipe que mantém um único cliente talvez precise alterar uma configuração e testar algumas chamadas. Um operador de rede com scripts antigos, software de fornecedores, tarefas agendadas, operação terceirizada e ferramentas separadas para RPKI e IRR precisa descobrir todos os locais que montam a cadeia de consulta. Esse esforço é invisível para o registro a menos que seja medido. Por isso, a permanência da compatibilidade não prova que cada cliente informado decidiu continuar usando a alternativa mais exposta.

O que as fontes permitem afirmar

Quatro estados diferentes aparecem nas fontes:

  1. A autenticação pelo cabeçalho está disponível no Reg-RWS. A versão de julho e a documentação atual de métodos REST a descrevem.
  2. A ARIN prefere essa forma e recomenda a migração. A explicação de agosto e o resumo de setembro afirmam isso.
  3. O token na URL continua sendo aceito no material público consultado. A resposta de encerramento de 29 de julho diz isso explicitamente; a página atual de métodos REST também.
  4. As fontes consultadas não publicam uma data de retirada, uma sequência de marcos, quantas chamadas ainda usam parâmetros de URL ou qual é a taxa de adoção do cabeçalho.

O quarto ponto tem escopo limitado de propósito. Quer dizer que esses dados não aparecem nas fontes públicas citadas; não prova que a ARIN não possua informações internas, planos reservados ou conversas com clientes. As fontes tampouco descrevem um incidente. A sugestão de 2022 apontou um mecanismo plausível de exposição. Os materiais de 2026 explicam por que a ARIN prefere a alternativa. Nenhum deles relata uma chave efetivamente divulgada ou uma operação não autorizada no registro.

Esse cuidado evita dois erros. Um seria tratar os quatro anos como prova de fracasso. A sugestão não determinou um prazo e o registro mostra que a alternativa foi implantada. O outro seria tomar o encerramento como prova de que o risco desapareceu. A resposta preserva expressamente a aceitação da URL e a publicação de setembro fala em retirada futura, sem data. Uma opção melhor pode existir enquanto um caminho de maior exposição permanece ativo.

Compatibilidade também é compromisso de serviço

Manter o método antigo durante uma transição pode ser a decisão responsável. Um corte imediato poderia interromper um processo automatizado, mas importante para a administração de recursos. Uma falha pode atrasar mudanças no registro, operações de RPKI ou IRR, reatribuições ou outras rotinas construídas sobre o Reg-RWS. As fontes públicas confirmam esses usos em termos gerais, mas não quantificam o impacto de uma interrupção específica. A API do registro integra a infraestrutura diária dos operadores, não é uma interface de demonstração descartável.

Compatibilidade tem custo. Cada formato aceito cria um estado que a documentação, o suporte, os mantenedores dos clientes e as equipes usuárias precisam entender. Se um método é recomendado e outro permanece funcional sem prazo, “preferido” pode virar uma orientação sem data para decisão. Novas integrações podem copiar exemplos antigos; scripts esquecidos podem nunca ser revisados; uma avaliação interna de segurança pode considerar o assunto resolvido só porque existe uma opção com cabeçalho.

A resposta não é supor que a ARIN deva publicar dados identificáveis de cada cliente, potencialmente sensíveis. É possível tornar o progresso visível sem expor identidades ou segredos. A ARIN poderia, no mínimo, explicar as fases previstas, o evento que iniciaria o prazo de retirada, quanto aviso será dado, como alterações de compatibilidade serão comunicadas e quais evidências poderiam justificar uma extensão. Se ainda não existe data, dizer isso claramente ajuda mais do que deixar cada cliente interpretar “no futuro”.

As fontes consultadas não mostram que a ARIN tenha se comprometido com essas etapas. São recomendações para que uma retirada futura seja previsível, não uma descrição de um plano atual. Essa diferença importa: anunciar uma data cria uma obrigação. Se a ARIN ainda não decidiu, o texto analítico não deve apresentar a decisão como tomada.

A retirada precisa de mais do que uma nota de versão

Uma migração não está concluída só porque existe um exemplo de cabeçalho que funciona. Operadores precisam saber quais endpoints e ferramentas o aceitam, se bibliotecas conhecidas têm incompatibilidades, que erro aparece quando o cabeçalho falta ou vem malformado e se uma chamada pode enviar o cabeçalho e o token na URL ao mesmo tempo. Os guias públicos da ARIN respondem à questão central da sintaxe. No material revisto para esta análise, não há uma lista pública de compatibilidade por cliente nem um painel de adoção.

Esse painel não precisaria identificar cada cliente. Números agregados poderiam indicar se as chamadas pelo cabeçalho estão substituindo as chamadas com parâmetro de URL, se existe uma longa cauda de uso antigo e se a migração depende de poucas integrações. Um aviso de retirada poderia reunir essas medidas com datas: anúncio, fim de novos exemplos com URL, fase de advertência, revisão final da compatibilidade e uma janela proposta para o encerramento. Se publicar certos números expuser informações operacionais, a ARIN poderia publicar os critérios de decisão e indicar se cada fase foi atingida.

Para os clientes, esperar uma data universal não é uma estratégia de segurança. A recomendação atual já é clara: retirar a chave das URLs quando o cliente oferecer autenticação por cabeçalho. As equipes podem procurar em código e configurações onde as cadeias de consulta são montadas, atualizar primeiro as bibliotecas compartilhadas, confirmar que logs e rastreamentos ocultam Authorization, testar operações representativas sob seus controles de mudança e substituir chaves expostas. Essas ações continuam úteis qualquer que seja a data final.

É importante testar a migração em vez de trocar uma string e presumir que todos os clientes se comportarão igual.

O registro também não deve transformar a data final em surpresa. Uma transição por etapas permite localizar clientes que a organização não mantém, falar com fornecedores, atualizar procedimentos e validar a monitoração. Alertas podem preceder a rejeição; a rejeição pode ficar para uma fase posterior; um processo documentado de exceção pode atender uma dependência real sem tornar permanente, por omissão, o método temporário. As fontes não dizem que a ARIN escolheu esses controles. São medidas usuais quando o efeito de compatibilidade ultrapassa a organização que implementa a mudança.

O que significa “encerrada”

A sugestão de 2022 pedia uma maneira mais segura de autenticar chamadas REST. A ARIN a forneceu e encerrou o registro. Nesse sentido restrito, o estado está correto. Mas um status de acompanhamento não mede uma migração. Ele confirma que a alternativa foi implementada; não informa quantas chamadas ainda usam o formato antigo, que prazo de aviso será dado ou quando a aceitação termina.

Para clientes da ARIN, a conclusão prática é simples: usar o cabeçalho em clientes novos ou mantidos e tratar a URL como compatibilidade, não como opção de segurança equivalente. Para a ARIN, resta tornar a retirada futura visível o bastante para que uma recomendação vire uma migração coordenada. As fontes não justificam alegar um vazamento ou atribuir culpa. Justificam perguntar qual sinal público indicará que o segundo relógio começou a contar.

Fontes