Resumo

  • O Relatório Anual de 2025 da AFRINIC registra a redução planejada da presença física em data centers, maior uso de nuvem e arquitetura híbrida, Bacula modernizado, cobertura de serviços críticos, backups externos no AWS S3, testes trimestrais e automação com Ansible.
  • Esses passos fortalecem a continuidade, mas não são equivalentes: um job concluído, um objeto legível, um snapshot restaurado, uma aplicação iniciada e uma operação de membro aceita são evidências sucessivas.
  • Um mapa público e não sensível de serviço para recuperação poderia mostrar metas, cenários, verificações, etapas controladas por fornecedores, exceções e o último exercício em ambiente independente, preservando credenciais, nomes de buckets, chaves e procedimentos de emergência.

Menos máquinas, mais pontos de passagem

A narrativa mais fácil seria tratar a nuvem como perda de controle. O relatório da AFRINIC não sustenta essa simplificação. Ele descreve a retirada de ativos obsoletos e em fim de vida, a substituição de peças defeituosas de rede e armazenamento, a implantação de peering de 10 Gbit/s, o aumento de capacidade de backup e a preparação de roteamento e uplinks redundantes. O trabalho passou por Maurício, Joanesburgo, Parklands, Mombasa e Isando. Algumas iniciativas ainda dependiam de cronogramas e aprovações de fornecedores.

Há benefícios concretos. Hardware antigo concentra falhas e conhecimento de manutenção. Uma cópia externa não desaparece com um incidente físico local. Capacidade elástica pode acelerar a criação de um destino de recuperação. Bacula e Ansible ajudam a transformar uma sequência artesanal em procedimento repetível. Testar a restauração a cada três meses é muito mais rigoroso do que exibir somente a taxa de sucesso dos backups.

O problema de controle começa justamente porque a estratégia é plausível. Ao diminuir a infraestrutura própria, a AFRINIC pode retirar riscos físicos e assumir novas dependências de conta, identidade, permissão, região, criptografia, contrato e suporte. Nenhuma delas é defeito por definição. Mas cada uma é uma fronteira que o teste precisa atravessar ou declarar que não atravessou.

O documento público informa que serviços críticos têm cobertura integral de backup e que o S3 é usado como destino externo. Não publica quais classes de dados seguem esse caminho, as metas de ponto e tempo de recuperação, os snapshots ensaiados, a região, a custódia de contas e chaves, a versão restaurada, o ambiente de destino, os resultados por verificação ou uma prova de saída independente. Não se deve preencher essas lacunas com suposições. Deve-se usá-las para definir uma prestação de contas útil.

O verbo restaurar esconde nove resultados

Uma tarefa de backup pode terminar sem que ninguém tenha lido o objeto gravado. Um objeto pode ser legível sem que o snapshot correto seja restaurado. O snapshot pode surgir no destino e falhar em esquema, assinatura ou integridade referencial. A aplicação pode iniciar e o endpoint não responder. O endpoint pode responder e ainda impedir a ação autenticada de um membro. A ação pode funcionar depois da meta de tempo ou com perda superior à meta de ponto.

Existe ainda o teste que mede independência: o mesmo estado autoritativo consegue produzir um serviço mínimo em ambiente fora do controle cotidiano? Uma restauração dentro da conta e da região normais continua sendo valiosa. Ela apenas responde a uma hipótese diferente da perda desse plano de controle.

Em um registro regional da Internet, essa escada não é preciosismo. Uma página aberta não demonstra que um membro consegue executar a operação que altera seus recursos. Um banco iniciado não demonstra que delegações, assinaturas e vínculos continuam coerentes. Bytes recuperados não carregam sozinhos a autoridade que o sistema representa. O critério final deve ser funcional e temporal.

É possível publicar a prova sem publicar o caminho de ataque. Classes de serviço, tipos de destino e categorias de custódia são suficientes. Não há necessidade de divulgar contas, buckets, chaves, instalações, diagramas ou comandos de crise.

A fronteira do terceiro já aparece no compromisso

O Compromisso de Nível de Serviço da AFRINIC se identifica como Versão 1, de novembro de 2015. Abrange registro, atendimento, bancos de dados, serviços públicos on-line, DNS reverso, faturamento e infraestrutura. Entre os serviços mantidos estão WHOIS, MyAFRINIC, sites, IRR, DNS, DNSSEC, e-mail e RPKI. O compromisso estabelece 99,8% de disponibilidade por serviço e para a rede.

O cálculo exclui indisponibilidade causada por terceiros. O texto também afirma que a AFRINIC não pode assumir compromissos de nível de serviço em nome de fornecedores, embora busque refletir suas próprias obrigações nas relações comerciais que afetam serviços essenciais. Isso não mostra inadimplência de fornecedor. Mostra uma divisão formal da medição.

Quando o serviço vivido pelo membro inclui uma espera externa, a métrica deve explicar se essa espera faz parte do tempo de recuperação. Um contrato pode alocar responsabilidade; não pode encurtar retrospectivamente a interrupção. O relatório de 2025 observa que algumas iniciativas dependem de prazos e aprovações de fornecedores, tornando a questão mensurável antes de uma emergência.

O mesmo cuidado vale para disponibilidade. A AFRINIC informou que os serviços críticos ficaram tipicamente acima de 99,7% em 2025. Na captura, o status público mostrava WHOIS Database, MyAFRINIC Portal, AFRINIC Web Sites, Mailing Lists, New Member Registration Portal, DNS Services, RPKI Systems e Other Systems como operacionais, sem resumo de métricas nos componentes raiz. O número anual não é teste de recuperação, e o verde atual não é história de disponibilidade. Cada evidência tem seu campo.

As condições do S3 precisam acompanhar o resultado

A documentação da AWS esclarece a responsabilidade compartilhada sem revelar a arquitetura da AFRINIC. A AWS opera a camada de infraestrutura dos serviços gerenciados, como o S3. O cliente continua responsável pela resiliência dos dados, inclusive pelas decisões de backup, versionamento e replicação.

As ferramentas documentadas podem oferecer cópias contínuas ou periódicas, recuperação a um ponto no tempo e acesso direto. O caminho do AWS Backup para S3 exige S3 Versioning. Permissões, papéis, ACLs, versão do destino, região e disponibilidade de chaves de criptografia podem alterar uma restauração. Objetos podem ser ignorados quando o destino já contém o mesmo nome ou identificador de versão. A restauração no bucket original é não destrutiva e não substitui tudo de modo uniforme.

Essas condições não provam que a AFRINIC use AWS Backup, Versioning, Replication, cópias entre regiões, certa região, um desenho de IAM ou uma configuração específica de chaves. Elas mostram por que a frase “backup S3 restaurado” é insuficiente. O resultado precisa dizer se testou leitura de objeto, reconstrução de aplicação, aceitação funcional ou independência do ambiente normal.

Uma prestação de contas compacta

Um mapa público pode ter uma linha por componente de serviço. Ela indicaria a classe de dado autoritativo, RPO e RTO, identificador não sensível do exercício, momento de referência, hash de integridade e classe de retenção. Depois separaria etapas sob controle da AFRINIC das que pertencem ao fornecedor.

O cenário registraria a classe do destino e se atravessou limite de conta, região ou provedor. Permissões e chaves apareceriam como classes de custódia. Os testes distinguiriam completude, esquema, assinatura, referências, início da aplicação, resposta externa e aceitação pelo usuário. Hora de início, hora de serviço utilizável e hora de aceitação impediriam que o cronômetro terminasse cedo demais.

Exceções não deveriam desaparecer: objetos ignorados, aprovações pendentes, responsável, prazo e caminho de correção. A linha final apontaria o último exercício em ambiente independente. Não é necessário manter uma segunda plataforma completa; é necessário provar periodicamente que dados e serviço mínimo sobrevivem à indisponibilidade do controle habitual.

Um mapa não garante o próximo teste. Pode ficar desatualizado e precisa de amostragem ou verificação independente. Sua função é menor e importante: tornar comparáveis as afirmações e permitir que uma falha corrigida permaneça como aprendizado.

O que as fontes não permitem afirmar

Não há evidência, no material examinado, de indisponibilidade, restauração fracassada, backup ausente, violação ou perda de dados da AFRINIC. Não sabemos se o S3 contém todos os serviços críticos ou todos os dados de registro. Não se demonstrou uso de uma função específica, dependência irreversível, incapacidade de deixar a AWS ou descumprimento por fornecedor. O valor de 99,7% não foi refutado, e a página de status não deve ser tratada como arquivo histórico.

O argumento é preventivo e construtivo. A modernização já contém boas peças: retirar ativos frágeis, criar distância física, automatizar e testar. O passo seguinte é mostrar até onde o teste chegou. A nuvem só se torna fronteira de governança quando o relatório para antes dela.

Fontes