Resumo

  • O RIPE NCC está atualizando o painel RPKI para OpenID Connect e iniciou a substituição das chaves atuais de API por credenciais baseadas em OIDC, integradas ao RIPE NCC Access. O trabalho continua em andamento.
  • Uma iniciativa separada de baliza RPKI foi interrompida porque a API disponível permitiria editar ROAs em todo o espaço do RIPE NCC. O caso mostra que autenticar melhor não equivale a delegar menos poder.

Uma credencial pode ser curta, bem auditada e vinculada à pessoa certa — e ainda assim abrir uma superfície de mudança grande demais. Para quem governa infraestrutura, essa é a diferença entre higiene de identidade e menor privilégio.

O RIPE NCC tornou essa distinção concreta em seu planejamento RPKI do quarto trimestre de 2026. A página, atualizada em 17 de setembro, informa que o painel será adaptado para usar OpenID Connect fornecido pelo RIPE NCC Access. A equipe também começou a substituir as chaves atuais da API RPKI por chaves baseadas em OIDC e integradas ao SSO. Haverá uma área de gestão no próprio painel, enquanto detalhes técnicos e de prazo serão apresentados numa próxima RIPE Meeting. O status publicado é “em andamento”.

A direção é defensável. O RIPE NCC Access já exige autenticação de dois fatores. A política de segurança de contas limita chaves de API a um ano, associa cada chave a uma conta e prevê sua desativação quando a conta é desabilitada ou o usuário perde a função de mantenedor no sistema correspondente. Uma gestão unificada pode tornar expiração, titularidade e revogação mais visíveis.

OIDC, porém, é uma camada de identidade sobre OAuth 2.0. Ele permite verificar a autenticação realizada por um servidor de autorização e receber declarações sobre o usuário. Isso não determina, por si só, se uma credencial pode apenas consultar, preparar mudanças ou publicar; tampouco define quais certificados e prefixos estão dentro do seu alcance.

Mesmo no OAuth, há fronteiras diferentes. O indicador de recurso aponta o servidor protegido para o qual o token se destina. O escopo descreve o acesso pedido. As recomendações atuais defendem tokens restritos a uma audiência específica. Ainda falta a regra da aplicação: dentro do serviço RPKI, qual LIR, certificado ou conjunto de prefixos pode ser alterado?

O outro item do planejamento fornece o teste. A comunidade pediu uma baliza conhecida cuja validade RPKI pudesse mudar para apoiar pesquisas. O RIPE NCC diz que ainda não a implementou porque a API usada permitiria editar ROAs para todo o seu espaço. A capacidade foi considerada inaceitável; uma solução será investigada com a equipe RIS.

Esse fato não prova que a futura solução OIDC terá o mesmo alcance. A API da baliza é um caso separado, e os detalhes do novo modelo ainda não foram publicados. O que ele prova é mais útil: o próprio RIPE NCC reconhece que uma função desejável não justifica autoridade de mutação desproporcional.

Uma ROA merece esse rigor. Trata-se de um objeto assinado que autoriza um AS de origem para um prefixo, com comprimento máximo opcional. No serviço hospedado, cada configuração combina um AS, um prefixo e um comprimento máximo; o sistema assina, publica e renova os objetos. A API atual pode incluir várias adições e exclusões numa só chamada de publicação.

Também existem controles que ajudam a desenhar a migração. O serviço retorna 403 quando alguém tenta criar uma ROA para um prefixo que não detém. O painel permite manter mudanças pendentes, revisar anúncios afetados e aplicar o conjunto de modo atômico. A API consegue estimar os efeitos de uma ROA ainda não criada.

Por isso, a prova completa deve ser repartida. Primeiro vem a identidade do principal. Depois, a audiência do token, o tipo de ação e o limite dos recursos. Em seguida, a aceitação ou recusa da mutação. Só então aparecem a publicação do objeto, a coleta por validadores, a política ROV de cada rede e o resultado observado no BGP. Login, publicação e rota não são sinônimos.

A leitura editorial deste texto usa as notas de Heng Lu sobre especificação inicial mínima, camadas da realidade e o problema de agência na governança da Internet. Aplicada ao RPKI, essa abordagem favorece autoridade inicial estreita e decisões futuras mantidas perto do recurso afetado. Não se trata de uma posição atribuída ao RIPE NCC.

Fontes