Os arquivos de alocação antes do escândalo: Como a AFRINIC perdeu o controle sobre seu próprio registro

Resumo

• A auditoria posterior da AFRINIC mostrou que o problema central de governança era uma cadeia interrompida entre uma solicitação válida, a avaliação de política, a aprovação, a alteração de inventário e o registro público WHOIS; o risco de corrupção aumentou onde um único papel podia alterar vários elos sem verificação independente.
• O WHOIS era uma declaração pública de custódia, não uma prova auto-validante de uma alocação legítima. Um registro alterado podia parecer autoritário mesmo que o ticket subjacente, a aprovação ou a justificativa de inventário estivessem ausentes ou contestados.
• A diferença entre endereços retirados do pool disponível da AFRINIC e alterações em registros históricos é importante: o primeiro diz respeito à criação de um direito aparente, enquanto o segundo diz respeito à substituição de identidade e custódia em registros historicamente frágeis.
• Os controles descritos pela AFRINIC após o escândalo – verificação final por um supervisor, rastreabilidade de alterações, reconciliação diária, privilégios escalonados e um mecanismo de auditoria contínuo – devem ser lidos como um mapeamento das áreas de controle que precisavam de proteção reforçada antes de 2019, e não como prova de que todas as salvaguardas estavam anteriormente ausentes.
• A responsabilidade do conselho deve ser medida pela exigência de relatórios de auditoria operacional, relatórios de exceção e evidências de fechamento para o principal ativo do registro, e não pelo conhecimento pessoal sobre o nome associado a um bloco suspeito.

O arquivo de alocação deveria ser a instituição

Um registro de Internet não produz espaço de endereçamento. Ela gerencia um estoque finito e registra quem está autorizado a usar partes definidas dele. Essa descrição modesta esconde uma concentração incomum de poder. Um hostmaster pode avaliar uma necessidade, uma equipe operacional pode mover um bloco do status 'disponível' para 'delegado', e um registro público pode fazer o resultado parecer definitivo para redes, corretores, pesquisadores de segurança e o suposto titular.

Quando essas ações são devidamente segregadas e documentadas, o arquivo de alocação é a instituição: ele preserva as justificativas, aprovações e históricos que legitimam um registro. Quando não são, o registro público pode se tornar uma ficção atraente.

O escândalo que surgiu em torno da AFRINIC em 2019 é frequentemente reduzido a uma história de vilão. Isso é emocionalmente conveniente e institucionalmente inútil. Um determinado funcionário pode ser demitido. Uma denúncia criminal pode ser feita. Nenhuma dessas ações explica por que alterações não autorizadas foram possíveis, por que anomalias persistiram, por que as evidências internas não desencadearam uma revisão decisiva, ou por que pessoas de fora ajudaram a montar um quadro que o próprio registro não havia apresentado publicamente.

Um registro que trata o episódio como uma biografia de um culpado deixa o sistema facilitador em grande parte não examinado.

A questão mais sofisticada é o que um arquivo de alocação precisava provar entre 2013 e 2019. Ele precisava mostrar que um solicitante identificável era elegível; que existia uma solicitação de recurso; que a equipe havia avaliado a solicitação de acordo com a política vigente; que a quantidade aprovada correspondia à necessidade demonstrada; que as condições contratuais e de pagamento, se aplicáveis, foram atendidas; que o inventário havia sido alterado por uma pessoa autorizada; e que o registro público WHOIS refletia o resultado autorizado, em vez de inventá-lo.

Cada alteração subsequente precisava ter sua própria autoridade, ator, carimbo de data/hora, evidências e aprovação. Um auditor precisava ser capaz de se mover para frente e para trás nessa cadeia.

O Relatório de Precisão do Banco de Dados WHOIS de 2021 da AFRINIC fornece o relato institucional público mais robusto do que a auditoria posterior revelou. Ele afirma que a auditoria verificou os registros de 2.824 prefixos IPv4 delegados a membros de recursos de 2005 a 2019. Nove deles não tinham número de ticket e estavam associados a alocações Fiber-Grid de 2012–13; entre os 2.815 registros com referências de ticket, 2.800 continham uma solicitação de recurso avaliada, enquanto discrepâncias em 15 registros afetavam prefixos importados de outros registros por meio do projeto anterior de transferência de registro.

Esses números não mostram que a totalidade das alocações era caótica. Eles mostram algo mais preciso: um arquivo predominantemente preenchido continha um pequeno número de arquivos de exceção com consequências muito grandes, e a instituição precisava de uma maneira de detectar as exceções antes que uma crise externa o fizesse.

Uma taxa de exceção pode ser reconfortante quando expressa em porcentagem. É o denominador errado para um registro. Um /14 injustificado equivale a 262.144 endereços. Um /16 injustificado equivale a 65.536 endereços. O risco de controle segue o volume, o status e a reversibilidade dos recursos afetados, e não apenas o número de tickets defeituosos. Uma auditoria que relata 99% de completude documental ainda pode esconder uma falha material se o 1% ausente incluir grandes blocos, alterações privilegiadas ou entradas monetizáveis.

A escassez transformou um pequeno número de arquivos de exceção em tentações contábeis, sem que os endereços se tornassem propriedade privada.

Quatro ações que nunca devem ser misturadas

A integridade de uma alocação depende da separação de quatro ações: avaliação, aprovação, execução e publicação. A avaliação pergunta se um solicitante e uma solicitação atendem à política. A aprovação transforma essa avaliação em uma decisão institucional. A execução altera o inventário e os registros internos associados. A publicação altera o que o mundo exterior vê no WHOIS e serviços relacionados. Um funcionário pode contribuir para várias etapas em uma pequena organização, mas nenhuma alocação significativa deve depender apenas da ação não verificada desse funcionário.

A primeira separação é entre o analista que prepara a operação e a pessoa que a aprova. Os hostmasters inevitavelmente exercem julgamento. A política não pode prever todos os planos de rede, padrões de uso ou formas corporativas. É por isso que uma segunda revisão é importante. O revisor não deve apenas confirmar que as caixas estão marcadas. O revisor deve questionar identidade, elegibilidade, quantidade, organizações associadas, alocações anteriores, velocidade incomum, indicadores extra-regionais e conflitos de interesse. Uma solicitação grande ou incomum deve ser escalada para um nível de aprovação superior.

A identidade e a justificativa do aprovador devem ser registradas antes que o recurso possa sair do pool.

A segunda separação é entre a aprovação e a execução técnica. Uma interface operacional deve aceitar apenas uma referência de aprovação imutável cujo prefixo e organização aprovados correspondam à alteração proposta. Se a equipe puder criar diretamente a organização alvo, classificar um bloco, alterar o inventário e publicar o registro WHOIS, a instituição substituiu uma cadeia de autoridade por uma conta poderosa. Registrar essa conta não é suficiente. Logs que são consultados somente depois que surge uma suspeita são resíduos forenses, não um controle preventivo.

A terceira separação é entre a execução e a reconciliação. Um arquivo diário de estatísticas delegadas, o inventário interno de recursos, o sistema de associação e o WHOIS são representações diferentes do mesmo ato institucional. Discrepâncias são esperadas ocasionalmente, pois os sistemas se atualizam em momentos diferentes. No entanto, elas também devem ser visíveis, datadas e resolvidas. Uma discrepância não resolvida sobre o status do recurso, o handle da organização ou o tamanho do prefixo deve gerar uma exceção que pertence a alguém fora da equipe que fez a alteração.

A exceção deve permanecer aberta até que a autoridade justificadora seja anexada ou a entrada seja revertida.

A quarta separação é entre a gestão e a garantia. A equipe responsável pela alocação não pode ser a única equipe a decidir que seus controles são adequados. A auditoria interna precisa de acesso de leitura a toda a sequência, um mandato que cubra os serviços de registro e a tecnologia, e uma linha de reporte a um comitê capaz de exigir ações da gestão. A auditoria financeira externa pode examinar receitas, passivos e contas sem reconstruir as alterações nos recursos digitais. Um conselho que recebe um parecer financeiro positivo ainda não tem certeza de que o registro central está correto.

Essas separações não são enfeites burocráticos. Elas criam uma contradição no momento em que a contradição é mais barata. Um revisor pode parar uma solicitação injustificada antes da publicação. Um conciliador pode detectar uma discrepância antes que os endereços sejam roteados, alugados ou vendidos. Um auditor pode detectar um padrão antes que as contrapartes acumulem interesses de confiança protegíveis. Quando anos se passaram, cada correção se torna um conflito entre titulares históricos, usuários atuais, compradores, redes e o próprio registro.

O WHOIS podia publicar confiança que não merecia

ARFC 7020publicada em 2013 descreve a precisão do registro como um requisito fundamental do sistema de registros de números da Internet. O registro deve garantir a exclusividade e fornecer informações precisas sobre as alocações. O requisito é operacional, não decorativo. Redes, equipes de resposta a incidentes e titulares de recursos usam os dados do registro para entender quem é responsável por um bloco. No entanto, um registro WHOIS é apenas a afirmação final. Ele não pode provar a autoridade que o produziu.

Essa distinção é central no caso da AFRINIC. Reportagens públicas rastrearam alterações suspeitas por meio de registros históricos do WHOIS, endereços de contato, registros de domínio e observações de roteamento. Essas fontes foram úteis porque revelaram contradições. Elas não substituíram o arquivo de alocação. Um registro público que afirma que uma organização detém um prefixo representa o que o registro representava naquele momento. Ele não estabelece que a organização fez uma solicitação válida, que a solicitação foi aprovada, ou que a pessoa que alterou o registro estava autorizada a fazê-lo.

A natureza pública do WHOIS também pode criar uma falsa sensação de segurança dentro da instituição. Se a equipe vê um bloco registrado sob uma organização aparentemente coerente, e a interface trata o registro atual como verdade básica, o registro começa a se autovalidar. Uma solicitação de suporte posterior pode ser aceita porque vem do contato que uma alteração não autorizada anterior havia inserido. Um identificador de mantenedor pode então permitir mais alterações. A cada transação, a premissa falsa ganha um histórico administrativo mais longo.

O antídoto não é simplesmente uma autenticação mais forte para o contato atual. Uma reivindicação comprometida pode ser perfeitamente autenticada. O registro deve preservar a raiz da autoridade: a solicitação original, a identidade legal verificada, a avaliação de política, a aprovação, o contrato (se aplicável), o pagamento, a decisão do prefixo e qualquer transferência ou atualização subsequente. Alterações em um contato ou mantenedor merecem atenção especial, pois alteram quem pode autorizar a próxima alteração.

Uma solicitação para substituir simultaneamente a identidade da organização e suas credenciais de acesso não é manutenção de rotina; é uma potencial mudança de controle.

O relatório posterior da AFRINIC afirma que cada objeto WHOIS estava protegido por um mantenedor desde agosto de 2017 e descreve a autenticação PGP para alterações de pessoal e mantenedores poderosos. Essas são salvaguardas úteis contra edição não autenticada. Elas não respondem à questão de saber se um funcionário autenticado estava materialmente autorizado a fazer uma determinada alteração. O controle de acesso prova qual identificador agiu. A governança deve provar por que a ação era permitida.

Essa diferença explica por que a supervisão não pode ser reduzida à segurança da conta. Os alertas relevantes são tanto semânticos quanto técnicos. Um bloco grande que muda de 'disponível' para 'delegado' sem uma solicitação aprovada vinculada; um recurso reclassificado como histórico; uma organização histórica adormecida com um domínio de e-mail recém-registrado; vários titulares não relacionados compartilhando dados de contato; um handle de organização alterado pouco antes de uma transferência; ou um prefixo que aparece no WHOIS, mas não no sistema de associação – tudo isso requer investigação, mesmo que cada login tenha sido bem-sucedido.

O pool livre e a área histórica eram problemas de controle diferentes

A auditoria posterior distinguiu duas grandes classes de recursos afetados. A primeira incluía endereços que, de acordo com a AFRINIC, foram desviados de seu pool disponível e atribuídos a organizações sem autorização. O relatório os estimou em 2.371.584 endereços IPv4. A segunda incluía recursos históricos: alocações feitas antes do sistema maduro de registros regionais, migradas para a administração da AFRINIC, muitas vezes sem contrato vigente e às vezes associadas a organizações que mudaram de nome, fundiram, dissolveram ou perderam contatos competentes.

A distinção é importante porque os testes de controle diferem. Mover um bloco do pool disponível requer uma solicitação e uma decisão contemporâneas. O inventário começa com a AFRINIC como administradora do espaço não alocado. Uma delegação injustificada é, portanto, visível pela ausência de um evento de alocação válido. A auditoria pode perguntar: onde está a solicitação, quem a avaliou, quem a aprovou, qual política a justificou e como o arquivo interno de recursos mudou?

Uma alteração histórica apresenta um problema jurídico mais difícil. O bloco já tem um titular histórico. O registro pode ser solicitado a atualizar um nome, um contato, um sucessor corporativo ou um mantenedor. Um endereço de e-mail que não existe mais não é prova de que o recurso foi abandonado. Um novo reivindicante ativo não é prova de sucessão. O arquivo decisivo pode incluir dados de registro antigos, documentos corporativos, registros de fusão, correspondência e evidências de outro registro.

Um funcionário que pode substituir dados de contato desatualizados sem verificação independente pode efetivamente escolher quem fala por um titular ausente.

O relatório da AFRINIC descreveu as características que tornavam a área histórica vulnerável: alguns titulares não tinham acordo contratual com o registro; os contatos podiam estar aposentados ou ter saído; as organizações podiam ter sido dissolvidas ou reestruturadas; e algumas transações suspeitas envolviam a transferência de senhas de mantenedor. O relatório também observou que contatos históricos entre 2012 e 2015 às vezes foram atualizados para domínios de e-mail que pareciam corresponder ao nome do titular, mas que haviam sido registrados muito recentemente para serem consistentes com a história presumida da organização.

Este é exatamente o tipo de anomalia que um registro pode testar automaticamente.

Ambos os problemas podem convergir. A auditoria sugeriu que alguns recursos que deveriam ter permanecido no pool da AFRINIC foram marcados como espaço presumivelmente histórico antes de se tornarem objeto de transações de venda. Se isso for verdade, essa sequência mostra por que os campos de status são variáveis de controle e não meras descrições. A reclassificação de um bloco pode movê-lo de um processo que requer uma nova decisão de alocação para um processo mais ambíguo apresentado como manutenção de um direito antigo.

Um sistema que protege a alocação, mas permite a reclassificação descontrolada, deixa uma porta dos fundos ao redor de sua barreira mais forte.

Um design robusto trataria, portanto, as alterações de status como transações privilegiadas. Nenhum analista deveria ser capaz de declarar sozinho que um bloco do pool é histórico. A alteração exigiria evidências dos registros históricos delegados, pelo menos duas aprovações, uma reconciliação automatizada com o histórico do pool do registro e uma notificação a uma função de garantia. O status anterior deve permanecer imutável. Se um auditor posterior não puder ver a classificação antiga e a nova e a autoridade para a transição, o registro não preservou a história; ele a reescreveu.

A escassez mudou a ameaça, não o mandato

Entre 2013 e 2019, a escassez de IPv4 tornou as fraquezas de controle cada vez mais valiosas. A AFRINIC entrou na primeira fase de sua política de /8 final em 2017. Mercados públicos e transações privadas atribuíram preços significativos aos endereços, enquanto muitas alocações antigas permaneciam não utilizadas, mal documentadas ou associadas a organizações adormecidas. A lacuna entre o tratamento administrativo e o valor comercial criou um risco óbvio de corrupção.

No entanto, o preço de mercado não deve definir o dano institucional. Os endereços IPv4 não são barras em um cofre. O registro gerencia identificadores exclusivos sob a política da comunidade. O dano imediato de uma alocação injustificada é que a instituição faz afirmações contraditórias ou falsas sobre a custódia, priva solicitantes legítimos de espaço escasso do pool e expõe as redes a uma possível anulação posterior. Um mercado secundário amplifica o incentivo e multiplica a confiança, mas a falha começa no registro de autoridade.

Isso é importante porque avaliações espetaculares podem distorcer os remédios. Uma manchete pode multiplicar o número de endereços por um preço observado e declarar uma perda de dezenas de milhões de dólares. Tal estimativa pode expressar uma ordem de magnitude, mas não estabelece uma reivindicação legal, receita realizada ou danos indenizáveis. Também não diz ao conselho qual controle falhou. A unidade relevante para a governança é a decisão não autorizada: como o bloco mudou de status, quais evidências estavam faltando, qual conta agiu, qual revisão deveria tê-lo impedido e por quanto tempo a exceção permaneceu visível.

A escassez deveria ter levado a AFRINIC a intensificar a supervisão antes do escândalo. Grandes alocações, atualizações históricas e alterações em registros adormecidos tornaram-se transações economicamente sensíveis. Uma instituição não precisa presumir que todo funcionário é corrupto. Ela precisa presumir que um privilégio valioso acabará atraindo erros, pressão, conluio ou abuso. Aprovação dupla (maker-checker), ausência obrigatória, rotação em filas de alto risco, divulgação de conflitos, amostragem independente de exceções e detecção automatizada de anomalias são respostas comuns a essa suposição.

A ameaça se estendeu além do ato inicial. Um bloco com um registro duvidoso podia ser roteado por uma rede não relacionada, alugado a clientes, usado como garantia em um acordo comercial ou vendido a um comprador que acreditava no registro público. Cada parte adicional aumenta o custo da correção. Isso significa que a rapidez faz parte da eficácia do controle. Um alerta investigado três anos depois pode ajudar a explicar o passado, mas faz pouco para evitar complicações legais e operacionais.

O que a auditoria posterior realmente prova

O relatório de 2021 da AFRINIC é indispensável e limitado. É indispensável porque identifica as próprias categorias, métodos, números e controles corretivos da instituição. Afirma que a revisão posterior utilizou arquivos internos de recursos, logs e históricos do WHOIS, estatísticas delegadas, entradas de tickets, solicitações de associação e recursos, DNS reverso, o Registro de Roteamento da Internet, registros históricos externos, relatórios públicos e informações de denunciantes. Isso se aproxima do conjunto de evidências que um sistema de controle contínuo eficaz deve conciliar.

É limitado porque a AFRINIC o produziu após a crise, quando ainda havia litígios e uma investigação policial em andamento. Ele contém conclusões sobre desvio e custódia legítima que podem ter sido contestadas pelas partes afetadas. Os leitores devem distinguir uma conclusão administrativa de um registro de uma determinação judicial final. O relatório pode estabelecer o que a AFRINIC encontrou e quais medidas alega ter tomado. Ele não pode, por si só, resolver todos os blocos contestados ou estabelecer a responsabilidade criminal de um indivíduo.

Os números do relatório revelam a complexidade do reparo. Em novembro de 2020, ele listava 1.060.864 endereços recuperados do pool e colocados em quarentena, 1.310.720 endereços do pool ainda em revisão, 467.968 endereços históricos cujas alterações injustificadas foram revertidas, 394.496 endereços históricos consolidados a pedido das empresas holding e 936.704 endereços históricos disputados até que a custódia fosse esclarecida. Essas categorias mostram que a correção não foi uma simples operação de exclusão. Algumas entradas puderam ser restauradas, outras exigiram consolidação corporativa e muitas envolviam reivindicações concorrentes.

A AFRINIC reconheceu que as reversões foram lentas. Se várias organizações reivindicassem a custódia, ela bloqueava os endereços contra novas alterações no WHOIS até que um acordo ou uma decisão competente fosse alcançada. Se os titulares não respondessem às solicitações de atualização e nenhuma objeção fosse recebida, afirmou que as atualizações suspeitas eram revertidas e os endereços bloqueados até que um titular legítimo realizasse a devida diligência.

Essas medidas podem preservar o status quo, mas também mostram por que a prevenção era importante: um arquivo de alocação que poderia ter esclarecido a autoridade antes da disputa não era mais suficiente para fazê-lo de forma limpa depois.

O relatório também descreveu os controles introduzidos ou reforçados após a descoberta.

Referiu-se à automação, a uma política de controle de mudanças planejada para revisão e rastreabilidade adicionais, à verificação final de solicitações de recursos e associação por um supervisor, a uma política de fraude e corrupção aprovada em junho de 2019, a uma linha direta independente lançada em 2020, à revisão reforçada de atualizações históricas, a relatórios diários de inconsistência entre MyAFRINIC e WHOIS, à reconciliação com estatísticas delegadas, à autenticação PGP, a restrições de acesso baseadas em funções e ao escalonamento de alterações fora dos privilégios normais da equipe.

Essas medidas não devem ser lidas como uma admissão de que nenhuma existia anteriormente. As instituições frequentemente descrevem melhorias sem publicar uma matriz de controle anterior-posterior precisa. Mas a lista é analiticamente reveladora. Cada medida responde a um modo de falha reconhecível: a automação limita atalhos arbitrários; a verificação final interrompe a autoaprovação; a rastreabilidade preserva quem alterou o quê; a reconciliação detecta entradas divergentes; os privilégios escalonados reduzem o acesso excessivo; a denúncia independente contorna a supressão pela gestão.

A lista de reformas aponta diretamente para as áreas onde a salvaguarda anterior era insuficiente.

Logs que ninguém questiona são apenas arquivos

É tentador imaginar que logs técnicos completos teriam resolvido o problema. Eles teriam ajudado, mas um log só é um controle se uma instituição define o que detectar, quem verifica, com que rapidez e o que acontece em seguida. Um registro mostrando que um identificador de funcionário autorizado alterou um handle de organização é neutro. Um alerta mostrando que a mesma pessoa avaliou a solicitação, aprovou a alteração e alterou um bloco grande é uma informação de governança.

Um log eficaz de um registro requer pelo menos três níveis. O nível de evento registra autenticação, ator, hora, interface, objeto, valor antigo e novo valor. O nível de autoridade vincula o evento ao ticket, versão da política, aprovação e evidências. O nível de garantia registra se as verificações automatizadas foram aprovadas, se um revisor inspecionou a alteração, quais exceções ocorreram e como foram encerradas. Sem o nível de autoridade, um auditor sabe o que aconteceu, mas não se deveria ter acontecido. Sem o nível de garantia, a instituição não pode provar que alguém olhou.

Os logs também devem ser à prova de falsificação e retidos durante a vida útil da reivindicação relevante. A custódia de IPv4 pode sobreviver a pessoas, sistemas e empresas. Um curto período de retenção operacional pode ser apropriado para logs de aplicativos de rotina, mas é devastador para o histórico autoritativo de um /16. O registro deve preservar um histórico assinado e somente anexável de status, organização, contatos, mantenedores, tickets e aprovações. Documentos de solicitação confidenciais podem ser protegidos separadamente, enquanto hashes e referências mantêm a integridade.

O design de alertas deve seguir o valor e o padrão. Prefixos grandes, alterações repetidas pelo mesmo ator, atualizações fora do horário comercial normal, organizações recém-criadas recebendo espaço extenso, domínios de contato registrados recentemente, reutilização de endereços entre titulares não relacionados, mudanças de status com classificação histórica e discrepâncias entre inventários autoritativos são sinais de alto valor. Nenhum sinal isolado prova má conduta. Seu propósito é exigir um segundo par de olhos enquanto as evidências estão frescas.

O encerramento é tão importante quanto a detecção. Cada alerta deve terminar com um de quatro resultados documentados: autorizado e justificado, corrigido como erro, escalado para investigação ou aceito como exceção documentada por um executivo nomeado. Explicações inofensivas repetidas devem melhorar a regra. Exceções repetidas envolvendo o mesmo ator, organização ou corretor devem ampliar a auditoria. Uma lista de alertas crescente sem responsabilidade dá uma aparência de supervisão enquanto o risco envelhece.

O conselho não precisava ser um hostmaster

Os conselhos não podem revisar cada alocação. Não devem tentar. Sua responsabilidade é exigir que a gestão demonstre que o registro central permanece correto e que as exceções estão contidas. Em um registro de números, esse dever não pode ser cumprido apenas pelas demonstrações financeiras anuais. O estoque escasso e o registro de autoridade são ativos operacionais cuja corrupção pode causar passivos, litígios e perda de legitimidade sem aparecer primeiro como uma divergência contábil.

O conselho deveria ter exigido um relatório de controle resumido em cada reunião. Ele poderia incluir o número e o volume de endereços de novas alocações, alterações históricas de alto risco, alterações fora das interfaces padrão, registros não reconciliados entre inventário, associação e WHOIS, alertas abertos por idade, aprovações de exceção, contas privilegiadas, relatórios de conflitos não resolvidos e descobertas de auditoria por gravidade. O relatório não divulgaria segredos do solicitante. Ele diria aos conselheiros se o controle estava funcionando.

Os mandatos dos comitês de auditoria publicados no período referiam-se a demonstrações financeiras, controle financeiro interno, gestão de riscos, auditoria interna, sistemas de informação e governança de tecnologia. Esse escopo era amplo o suficiente para fazer perguntas sobre os serviços de registro. No entanto, as atas públicas de 2018 mostram o comitê discutindo a contratação de um auditor interno, enquanto as atas de abril de 2019 descrevem um plano de auditoria interna cobrindo conformidade corporativa, finanças e contabilidade, serviços de registro e continuidade de negócios.

A existência de um plano não é prova de que os testes relevantes foram concluídos antes que o problema se tornasse público.

Essa distinção – mandato, plano, execução, descoberta, remediação – é a cadeia de responsabilidade adequada. Os conselhos frequentemente proclamam uma carta e assumem que a salvaguarda segue. Não é o caso. O comitê deve aprovar um plano baseado em riscos, garantir que o auditor tenha acesso e independência, receber as descobertas, atribuir responsabilidades e prazos e revisar a conclusão. Se os serviços de registro só foram incluídos no plano de auditoria de 2019 após anos de escassez crescente, os conselheiros devem perguntar por que o principal ativo não foi submetido a testes operacionais semelhantes antes.

Se foi testado, devem perguntar quais testes não detectaram as alterações injustificadas de status e identidade.

O conhecimento individual permanece relevante, mas não é o único teste. Um conselheiro que recebeu um aviso específico e não agiu tem uma responsabilidade diferente daquele que nunca foi informado. A instituição ainda não pode se defender alegando que o conselho não tinha conhecimento detalhado, se seu sistema de relatórios mantinha exceções materiais fora da vista do conselho. A governança consiste, em parte, em construir essa linha de visão.

A reportagem pública era um controle externo de último recurso

As reportagens publicadas pelo MyBroadband, KrebsOnSecurity e outros meios de comunicação juntaram registros públicos e disponíveis comercialmente em um quadro preocupante. Eles rastrearam entradas históricas, empresas, domínios, contatos e roteamento. Seu trabalho foi valioso porque forçou inconsistências a uma forma que as instituições e titulares afetados não podiam mais ignorar facilmente. Não deveria ter sido o principal mecanismo de detecção do registro.

O jornalismo investigativo tem padrões de evidência diferentes de uma decisão de alocação. Os jornalistas podem identificar anomalias, solicitar comentários e publicar conclusões fundamentadas. Um registro que anula uma entrada deve estabelecer a autoridade bloco por bloco e oferecer um processo justo aos reivindicantes concorrentes. Essa diferença não é motivo para rejeitar a reportagem. É uma razão para o registro incorporar sinais externos críveis como pistas, enquanto realiza sua própria auditoria documentada.

A reportagem também tem limitações. As estimativas de preço variam com a data, a reputação do bloco, os termos da transação e a liquidez do mercado. Os serviços históricos de WHOIS podem conter instantâneos incompletos. Os vínculos corporativos podem mostrar controle ou uma conexão sem provar que uma transação específica de recurso foi autorizada. O roteamento de um bloco não identifica por si só a parte que alterou o registro. Uma análise institucional responsável, portanto, atribui reivindicações, separa observação de conclusão e evita tratar repetição como confirmação.

As conclusões posteriores da AFRINIC forneceram suporte institucional para a preocupação central: o relatório afirma que o pessoal interno pode ter agido em conluio com terceiros, que a investigação da APNIC levou a ações disciplinares e que um ex-hostmaster abusou de seus direitos e privilégios. Ele também quantificou os recursos do pool que, em sua conclusão, foram atribuídos sem autorização. Essas são conclusões graves. Elas não eliminam a necessidade de examinar os controles. Pelo contrário, quanto mais forte a conclusão contra um insider, mais clara a evidência de que a resistência interna tinha que fazer parte do design do registro.

A questão pública mais útil não é por que um funcionário gostaria de lucrar. Recursos escassos criam incentivos óbvios. É por que uma instituição que tinha o inventário diário, os tickets, o histórico de alterações e os dados de conta não transformou anomalias em um desafio independente e oportuno. Pessoas de fora podiam ver fragmentos; o registro possuía os pontos de junção. Um sistema de controle deveria ter tornado essas junções rotineiras.

O reparo requer um registro demonstrável, não uma aparência mais limpa

Após um escândalo, há pressão para corrigir o WHOIS rapidamente. Essa pressão pode repetir o erro original ao tratar a publicação como verdade. Um registro não deve substituir um titular não autorizado por outro apenas porque a segunda reivindicação parece mais plausível. Ele precisa de um padrão de restauração que preserve evidências, proteja a continuidade e torne a incerteza visível.

Primeiro, o estado original e o histórico completo de alterações devem ser congelados. Os investigadores precisam de cópias dos tickets, mensagens, aprovações, documentos de identidade, logs, estatísticas delegadas, observações de roteamento e registros corporativos relevantes. Segundo, o acesso associado a um risco crível de adulteração deve ser restrito sem excluir evidências. Terceiro, cada bloco deve receber um arquivo que separe a origem do pool, o histórico, a entrada atual, o uso atual, as evidências do reivindicante e o status legal.

Quarto, a remediação deve corresponder à confiabilidade. Um bloco do pool sem solicitação válida e com um caminho não autorizado claro pode ser recuperado, sujeito a anúncio e revisão. Um bloco histórico com sucessores concorrentes pode exigir bloqueio até que um tribunal ou um processo acordado esclareça a custódia. Um usuário atual que aparentemente comprou de boa-fé pode não ter uma reivindicação superior ao titular legítimo, mas uma interrupção técnica abrupta pode prejudicar clientes. A correção do registro, a realidade do roteamento e a remediação comercial são questões relacionadas, mas separadas.

Quinto, o registro deve publicar o progresso agregado sem pré-julgar casos. Contagens por status, volume de endereços, idade e remediação permitem que os membros avaliem se a instituição está trabalhando no problema. O público não precisa de evidências privadas ou detalhes acusatórios sobre reivindicantes não resolvidos. Precisa saber o escopo, as regras de decisão, o caminho de revisão e se as correções estão acelerando.

Finalmente, o arquivo restaurado deve ser mais robusto do que o arquivo pré-escândalo. Ele deve conter as evidências que suportam a posição final, cada declaração, objeção, decisão, revisor e mudança operacional. A restauração não está completa quando a entrada atual do WHOIS parece limpa. Está completa quando uma pessoa independente pode explicar por que essa entrada agora é autoritativa.

Uma arquitetura de controle para um registro público e escasso

As reformas práticas não são exóticas nem punitivas. A verificação de identidade deve ser independente do analista que representa a solicitação. Grandes alocações e alterações de controle histórico devem exigir duas aprovações. O sistema deve vincular o prefixo, a organização e o status aprovados ao comando de execução. Os registros atuais e históricos devem ser somente anexáveis no nível autoritativo. Os privilégios devem ser limitados por função, revisados trimestralmente e revogados imediatamente quando as funções mudam. Ninguém deve gerenciar seu próprio acesso.

A reconciliação deve ser realizada diariamente entre o inventário de recursos, os registros de membros, o sistema de tickets, as estatísticas delegadas e o WHOIS. Discrepâncias de alto risco devem bloquear mais alterações até esclarecimento. O auditor interno deve examinar arquivos comuns como amostras e inspecionar cada exceção material, não apenas confirmar que um procedimento existe. O comitê de auditoria deve receber as descobertas diretamente e acompanhar a remediação. Um canal de denúncia independente deve permitir que funcionários, membros e pessoas de fora apresentem preocupações com proteção contra retaliação.

Os controles de conflito merecem igual atenção. Os funcionários envolvidos na avaliação de recursos devem divulgar empresas externas, interesses financeiros próximos e relacionamentos com corretores ou solicitantes. As divulgações devem ser atualizadas, verificadas em relação a contrapartes conhecidas e revisadas por alguém fora da linha direta do funcionário. Uma divulgação não é uma formalidade ritual; ela deve alterar a atribuição de casos e o acesso quando surge um conflito.

As métricas devem resistir a médias que ocultam o risco. O conselho precisa de números de exceção focados em endereços, não apenas a porcentagem de entradas de ticket. Ele deve ver os maiores blocos não justificados ou não resolvidos, as exceções mais antigas, a frequência de aprovações de exceção, a concentração por ator e o tempo entre o primeiro alerta e a contenção. Uma única anomalia /12 merece mais atenção do que centenas de correções de contato inofensivas.

Uma auditoria independente deve tentar periodicamente uma reconstrução a frio. Escolha um bloco no WHOIS e prove seu caminho de volta ao inventário recebido ou delegação histórica. Em seguida, escolha um ticket de aprovação e prove seu caminho adiante até o bloco exato publicado. Ambas as direções capturam falhas diferentes. Os testes diretos encontram ações aprovadas que foram executadas incorretamente. Os testes reversos encontram entradas públicas para as quais não existe autoridade suficiente.

Os membros devem ter um papel de revisão sem suportar o fardo do registro. Extratos de conta regulares podem solicitar que um titular confirme recursos, contatos e mantenedores. A falta de resposta deve desencadear acompanhamento e escrutínio reforçado, não exclusão automática. Um titular deve ser capaz de obter um histórico de alterações de seus recursos e contestar uma alteração não autorizada em tempo hábil. Isso distribui a detecção enquanto preserva a responsabilidade do registro por suas próprias ações.

O veredito institucional

Entre 2013 e 2019, a AFRINIC gerenciou um recurso cuja escassez e valor comercial aumentaram acentuadamente. Seu registro público carregava uma autoridade muito além do escritório que o mantinha. Evidências posteriores mostram que alguns arquivos e alterações não podiam suportar as alegações que o registro havia publicado, e que o reparo exigiu uma auditoria retroativa abrangente, ajuda externa, ação disciplinar, bloqueios, reversões e decisões contenciosas.

Chamar esse resultado de obra de uma única pessoa má é uma evasão. Um insider pode iniciar o abuso, mas apenas uma instituição confere autoridade duradoura a esse abuso. O arquivo de alocação deveria ter exigido cada solicitação por meio de avaliação, aprovação, execução, reconciliação e auditoria independentes. O histórico de alterações deveria ter tornado as ações excepcionais rapidamente visíveis. O conselho deveria ter conhecido o estado do ambiente de controle sem precisar conhecer cada prefixo.

A lição vai além da AFRINIC. A governança descentralizada da Internet frequentemente exalta a confiança, a comunidade e a competência técnica. Essas virtudes não substituem os controles. A legitimidade de um registro depende da capacidade de provar que a pessoa indicada em seu registro recebeu a autoridade por meio de um processo justo, documentado e verificável. Se não puder fazê-lo, a perda não é apenas um número de endereços. A instituição perdeu o controle sobre sua própria palavra.

Fontes e limites analíticos

A principal evidência institucional é oRelatório de Precisão do Banco de Dados WHOISda AFRINIC, a ser lido como um relato retrospectivo de uma instituição interessada e não como um julgamento final sobre cada disputa de recurso. ARFC 7020fornece os requisitos do sistema de registro quanto à exclusividade e precisão dos registros. OManual de Política Consolidada Versão 1.0arquivado da AFRINIC mostra o ambiente de política pública no qual a equipe exercia a responsabilidade de alocação. ORelatório Anual de 2018e os documentos do conselho publicados descrevem o mandato formal de auditoria e a construção da capacidade de auditoria interna. Ainvestigação de dezembro de 2019do MyBroadband fornece conclusões atribuídas de registros públicos e não é tratada como uma decisão judicial.

Esta análise não estabelece responsabilidade criminal, propriedade beneficiária, danos ou o custodiante legítimo de um prefixo contestado. Não presume que todos os controles descritos após 2019 estavam totalmente ausentes antes. Ela avalia a cadeia de autoridade publicamente visível e as implicações institucionais das próprias conclusões posteriores da AFRINIC. Se a evidência suporta apenas uma alegação, uma conclusão administrativa ou uma inferência, ela é tratada como tal.