O que é a Base de Dados RIPE?
A RIPE Database é uma base de dados de registo pública que armazena informações sobre recursos de numeração da Internet e objetos técnicos relacionados. É operada pelo RIPE NCC, o Registo Regional da Internet que serve a Europa, o Médio Oriente e partes da Ásia Central. O seu objetivo é ajudar a manter a transparência, a responsabilização e a coordenação técnica em toda a Internet pública.A base de dados inclui registos de espaço de endereços IPv4 e IPv6, ASNs, organizações, contactos de rede, políticas de encaminhamento, anúncios de rotas, delegações de DNS inverso, contactos de segurança e outras informações técnicas. Estes registos estão organizados como objetos estruturados. Cada objeto tem um tipo, uma chave ou identificador único, um conjunto de atributos e um ou mais mantenedores que controlam quem tem autorização para o atualizar.
Por exemplo, uma atribuição de endereço IPv4 pode ser representada por um inetnum object. An IPv6 allocation may be represented by an inet6num objecto. Um ASN é geralmente representado por um aut-num objeto. Uma política de rotas BGP pode ser representada por um rota object for IPv4 or a route6 object for IPv6. A company itself may be represented by an organização objeto, enquanto um contacto técnico pode ser representado através de um pessoa ou função objeto. Estes objetos estão ligados entre si. Um bloco de endereços IP pode fazer referência a um objeto de organização. O objeto de organização pode estar associado a contactos administrativos e técnicos. Um objeto de rota pode ligar um prefixo IP a um ASN. Um objeto de mantenedor pode definir quem tem permissão para modificar o registo. Esta estrutura interligada é o que torna a Base de Dados RIPE útil tanto para operações técnicas como para a administração de recursos.
É importante compreender que a RIPE Database é um sistema de registo e coordenação, não um simples certificado de propriedade. Um registo público pode indicar a organização responsável por um recurso ou a entidade registada como utilizador final, mas o contexto jurídico, contratual e regulamentar pode ser mais complexo. As empresas não devem basear-se exclusivamente numa consulta à base de dados ao realizar uma transferência de IPv4 de elevado valor, uma aquisição, uma análise de litígio ou um processo importante de diligência devida. Nessas situações, a base de dados é uma fonte importante de elementos de prova, mas deve ser analisada em conjunto com os procedimentos de registo em vigor, a documentação contratual e o aconselhamento profissional, quando apropriado.
RIPE NCC, a Comunidade RIPE e a Base de Dados RIPE
Os termos “RIPE”, “RIPE NCC” e “RIPE Database” são frequentemente utilizados em conjunto, mas não significam exatamente a mesma coisa. RIPE refere-se à comunidade mais ampla de operadores de redes, fornecedores de serviços de Internet, especialistas técnicos e outras partes interessadas envolvidas no desenvolvimento e coordenação das operações da Internet na região. RIPE NCC, ou Réseaux IP Européens Network Coordination Centre, é a organização que presta serviços de registo e coordenação, incluindo a operação da RIPE Database.
O RIPE NCC é um dos cinco Registos Regionais da Internet do mundo. Os outros quatro são o ARIN, para os Estados Unidos, o Canadá e partes das Caraíbas e do Atlântico Norte; o APNIC, para a região da Ásia-Pacífico; o LACNIC, para a América Latina e grande parte das Caraíbas; e o AFRINIC, para África e a região do Oceano Índico. Cada RIR gere recursos de numeração da Internet na sua região de serviço, ao abrigo de políticas desenvolvidas através de processos comunitários.A RIPE Database é, por isso, uma ferramenta operacional essencial para a região do RIPE NCC. Por exemplo, uma empresa que receba um ASN através de um LIR patrocinador do RIPE NCC pode ter informações introduzidas ou atualizadas na RIPE Database como parte do processo de registo. Mais tarde, a empresa poderá precisar de manter registos da organização, contactos técnicos, objetos de rota, autorizações RPKI, informações de contacto para casos de abuso e dados relacionados com BGP.
Para os operadores de rede, a base de dados apoia as decisões operacionais do dia a dia. Um fornecedor de trânsito pode utilizar dados de objetos de rota ao criar filtros de prefixos. Um analista de segurança pode utilizar a base de dados para identificar um contacto de abuso relevante. Uma empresa pode pesquisar um ASN antes de estabelecer uma relação de peering ou de prestação de serviços. Um centro de dados pode verificar os registos de atribuição de endereços durante uma análise de transferência de IP. Um engenheiro que esteja a resolver problemas num anúncio de rota pode comparar o prefixo IP, o ASN de origem, o objeto de rota, o estado do RPKI e os requisitos do fornecedor upstream.
Porque é que a Base de Dados RIPE é importante para as empresas
A Base de Dados RIPE é importante porque a infraestrutura da Internet precisa de responsabilização pública. Quando uma empresa opera um prefixo IP ou um ASN, as outras redes precisam de uma forma fiável de determinar quem é responsável por esse recurso. Isto é particularmente importante quando ocorre um incidente de encaminhamento, um ataque DDoS, uma queixa de spam, uma denúncia de abuso, um padrão de tráfego suspeito, um sequestro de BGP, uma falha de conectividade ou uma investigação de segurança.
Um registo bem mantido na RIPE Database pode facilitar a identificação e o contacto com uma empresa. Também pode reduzir a fricção ao trabalhar com fornecedores de trânsito upstream, Pontos de Troca de Internet, parceiros de conectividade na nuvem, fornecedores de mitigação de DDoS e outros operadores de rede. Se os registos de uma organização estiverem incompletos, incorretos ou desatualizados, esta poderá enfrentar atrasos ao tentar anunciar prefixos, validar o encaminhamento BGP, comprovar o controlo dos recursos, atualizar contactos ou responder a um incidente.
A base de dados também é importante para a gestão da reputação. Os endereços IP públicos podem desenvolver uma reputação com base na sua utilização histórica. Um fornecedor de alojamento, operador de VPN, plataforma de correio eletrónico, empresa de serviços na nuvem ou serviço de proxy poderá ter de demonstrar que possui uma estrutura organizacional legítima, um contacto funcional para abusos, contactos técnicos claros e registos de encaminhamento devidamente mantidos. Embora uma entrada na RIPE Database não garanta uma boa reputação, pode contribuir para uma presença de rede mais transparente e profissional.Para as organizações que utilizam BGP, os objetos de rota e os registos RPKI precisos são especialmente valiosos. Muitos fornecedores upstream utilizam informações do registo de encaminhamento para criar filtros de prefixos. Se uma rede anunciar um prefixo, mas não tiver um objeto de rota adequado ou uma autorização de rota, o fornecedor poderá rejeitar a rota. Isto pode provocar interrupções, atrasar a integração ou resultar numa conectividade global incompleta.
A RIPE Database também apoia a governação interna. Uma empresa pode ter várias pessoas envolvidas nas operações de rede, conformidade, gestão jurídica, faturação, tratamento de abusos e manutenção da infraestrutura. Relações claras entre objetos e controlos de manutenção podem ajudar a empresa a definir quem pode atualizar determinados registos. Isto reduz o risco de antigos funcionários, consultores externos ou partes não autorizadas manterem o controlo de registos de recursos críticos da Internet.
Tipos de objectos importantes da base de dados RIPE
A Base de Dados RIPE contém muitos tipos diferentes de objectos. Alguns são utilizados principalmente pelos administradores do registo, enquanto outros são utilizados regularmente por engenheiros de rede e gestores de recursos IP. Os objectos mais importantes para uma empresa típica que opera espaço IP público e um ASN são o objecto de organização, o objecto de endereço IP, o objecto ASN, o objecto de contacto, o objecto de mantenedor e o objecto de rota.
An organização objeto representa uma entidade jurídica, um titular de recursos, um utilizador final ou outra organização reconhecida envolvida no registo de recursos de numeração da Internet. Pode incluir o nome, o tipo e as referências de endereço e de contacto da organização, bem como informações sobre a entidade mantenedora. Este objeto ajuda a associar intervalos de endereços IP e ASNs a uma organização responsável.
An inetnum o objeto representa um intervalo de endereços IPv4. Pode conter o próprio intervalo, um nome descritivo, uma referência à organização, contactos administrativos e técnicos, informações de estado, referências de contactos de abuso e controlos do responsável pela manutenção. Um inet6num object performs a similar function for IPv6 address space. These records are critical because they identify the network operator or organization associated with an address block.
An aut-num O objeto representa um Número de Sistema Autónomo. Pode incluir o ASN, a organização responsável por este, informações sobre a política de encaminhamento, referências a políticas de importação e exportação, contactos técnicos e informações sobre o mantenedor. Uma empresa que utilize BGP deve garantir que os dados relacionados com o seu ASN são exatos, uma vez que este registo faz parte do contexto público que envolve a identidade de encaminhamento da rede.
A pessoa objeto identifica um contacto individual, enquanto um função o objeto identifica um contacto funcional, como “Centro de Operações de Rede”, “Departamento de Abusos”, “Suporte Técnico” ou “Administração de Recursos IP”. Em muitos casos, os objetos de função são mais práticos do que os contactos pessoais, porque permanecem válidos mesmo quando os funcionários mudam. Uma empresa bem gerida utiliza frequentemente endereços de função para as operações de rede e o tratamento de abusos, em vez de depender inteiramente dos dados pessoais de um único funcionário.
A mntner objeto, abreviatura de objeto de maintainer, é um dos controlos de segurança mais importantes da RIPE Database. Especifica os requisitos de autenticação e autorização para alterar objetos relacionados. Se um maintainer não estiver configurado corretamente, a empresa poderá perder a capacidade de atualizar os seus registos na base de dados ou expor-se a tentativas de alteração não autorizadas. As credenciais do maintainer, as palavras-passe, as credenciais da API e os procedimentos de autorização devem ser geridos cuidadosamente e nunca expostos em código-fonte público, scripts do lado do navegador ou documentação não protegida.
A rota object documents the relationship between an IPv4 prefix and an origin ASN. A route6 o objecto fornece o registo equivalente para um prefixo IPv6. Por exemplo, um objecto de rota pode indicar que 203.0.113.0/24 destina-se a ser anunciado por AS64500. Estes objetos são normalmente utilizados por fornecedores e pares ao criar filtros de rotas. Um objeto de rota não é o mesmo que um anúncio BGP ativo, mas é uma declaração importante da intenção de encaminhamento.
Como pesquisar na base de dados RIPE
A Base de Dados RIPE pode ser pesquisada através da sua interface web, de ferramentas de consulta ao estilo WHOIS e da API REST. O método escolhido depende da finalidade do utilizador. Um gestor de uma empresa poderá preferir a interface web porque é fácil de ler. Um engenheiro de redes poderá utilizar consultas na linha de comandos ou a API REST para automatização. Uma equipa de segurança poderá utilizar uma combinação de pesquisas na base de dados, ferramentas de validação RPKI, plataformas de monitorização BGP e sistemas internos de resposta a incidentes.
Uma consulta básica de IP pode apresentar as informações de registo associadas a um intervalo público de endereços IPv4 ou IPv6. Se um utilizador pesquisar um endereço IP, a base de dados poderá devolver um objeto de intervalo de endereços que contenha o intervalo alocado ou atribuído, o nome da rede, o código do país, a referência da organização, os contactos técnicos, as referências de contactos de abuso e as informações do mantenedor. Dependendo do objeto e das regras de privacidade aplicáveis, alguns dados de contacto poderão estar ocultados ou ser limitados.
Uma pesquisa de ASN pode mostrar o aut-num objecto associado a uma rede. Isto pode incluir o próprio ASN, uma descrição, referências relevantes a organizações, contactos técnicos, informações sobre políticas de encaminhamento e detalhes do responsável pela manutenção. Um registo de ASN pode ser útil ao investigar a identidade de encaminhamento de uma rede ou ao preparar uma relação BGP.
Uma consulta de rotas pode ajudar a determinar se um prefixo está documentado como sendo anunciado por um determinado ASN. Isto é útil quando um fornecedor upstream solicita um objeto de rota antes de aceitar um anúncio BGP. Também pode ajudar os engenheiros a diagnosticar por que motivo um prefixo está a ser filtrado, rejeitado ou tratado como inesperado.
No entanto, os utilizadores devem compreender os limites dos dados. Um objeto de rota não prova que a rota esteja atualmente visível na Internet global. Não prova que todos os fornecedores aceitem a rota. Também não substitui a validação RPKI. Para compreender a visibilidade do encaminhamento em tempo real, o utilizador poderá ter de consultar sistemas de monitorização BGP, coletores de rotas, looking glasses de fornecedores, validadores RPKI ou plataformas de inteligência de encaminhamento.
De forma semelhante, um registo de endereço IP pode apresentar uma organização registada, mas não revela necessariamente todas as empresas que utilizam serviços por detrás desse endereço. Os fornecedores de alojamento, as plataformas de computação na nuvem, os serviços de VPN e os revendedores podem operar infraestruturas para muitos clientes utilizando um bloco partilhado ou delegado.
Como utilizar a API REST da Base de Dados RIPE
Aprenda o formato de URI REST, as chaves de objeto, as consultas seguras apenas de leitura, as atualizações autenticadas, a validação em modo de simulação, os formatos de resposta e as salvaguardas operacionais.
A API REST da RIPE Database fornece acesso programático aos objetos da RIPE Database através de HTTPS. É útil para inventários de ativos, ferramentas de gestão de redes, portais internos, fluxos de trabalho de monitorização e administração controlada de recursos. Cada objeto da RIPE Database tem um URI de localização único, pelo que uma aplicação pode obter ou gerir um objeto específico quando conhece a fonte da base de dados, o tipo de objeto e a chave primária.
1 Compreender o formato URI REST
O formato padrão do URI do objeto é https://rest.db.ripe.net/source/objecttype/key. O origem identifica a fonte da base de dados, como RIPE para dados de produção ou TESTE ao utilizar o ambiente de teste. O tipo de objeto identifica o objeto da Base de Dados RIPE, como inetnum, inet6num, aut-num, pessoa, função, mntner, rota, ou route6. O chave é o identificador principal do objeto.
https://rest.db.ripe.net/source/objecttype/key
A maioria dos tipos de objeto utiliza um valor de chave primária. Os objetos de pessoa e de função utilizam o nic-hdl valor como chave. Os objetos route e route6 utilizam uma chave combinada: o prefixo da rota seguido imediatamente pelo ASN de origem. Por exemplo, um objeto route para o prefixo 193.0.22.0/23 originado por AS3333 utiliza a chave combinada 193.0.22.0/23AS3333. Utilize a codificação de URL quando necessário, quando uma chave incluir caracteres como barras, espaços ou outros caracteres reservados de URL.
https://rest.db.ripe.net
Utilize este endpoint para objetos ativos da Base de Dados RIPE e atualizações de produção autorizadas.
https://rest-test.db.ripe.net
Utilize este endpoint para praticar pedidos e validar a lógica de integração sem alterar os dados de produção.
2 Comece com uma consulta de objetos só de leitura
A recuperação apenas de leitura é o ponto de partida mais seguro para uma integração. O comando seguinte solicita o público aut-num objeto para o ASN de exemplo AS3333 e solicita à API que devolva JSON. Substitua o ASN de exemplo apenas por um ASN público real que esteja autorizado a consultar. Este comando não cria, altera nem elimina qualquer objeto da base de dados.
curl -H "Accept: application/json" \
"https://rest.db.ripe.net/ripe/aut-num/AS3333.json"Pode solicitar XML utilizando Aceitar: application/xml ou utilizando um .xml extensão. O JSON pode ser solicitado com Aceitar: application/json ou um .json extensão. Se o formato da resposta não for especificado, a API utiliza XML por predefinição. As aplicações devem solicitar explicitamente o seu formato preferido para que o comportamento da análise permaneça previsível.
3 Pesquisar dados quando não sabe a chave exacta do objecto
Um pedido de pesquisa é útil quando tem um ASN, um endereço IP, um prefixo, um identificador de organização ou outro valor de pesquisa, mas ainda não sabe o URI exato do objeto. O exemplo abaixo pesquisa a fonte RIPE por registos relacionados com AS3333. O flags=no-referenced o parâmetro solicita uma resposta simplificada que não inclua os objetos referenciados.
curl --get "https://rest.db.ripe.net/search.json" \
--data-urlencode "query-string=AS3333" \
--data-urlencode "source=ripe" \
--data-urlencode "flags=no-referenced".Para uma pesquisa de encaminhamento, restrinja a resposta por tipo de objeto. O exemplo seguinte procura IPv4 rota objetos associados ao prefixo da documentação 203.0.113.0/24. Um objeto de rota documenta as informações de encaminhamento pretendidas; deve ser avaliado em conjunto com a visibilidade BGP ativa e o estado do RPKI antes de tomar uma decisão de encaminhamento.
curl --get "https://rest.db.ripe.net/search.json" \
--data-urlencode "query-string=203.0.113.0/24" \
--data-urlencode "type-filter=route" \
--data-urlencode "source=ripe"۔4 Utilize apenas POST, PUT e DELETE com a autorização adequada
A API REST suporta PUBLICAR para criar um objeto, PUT para atualizar um objeto existente, e ELIMINAR para remover um objeto. Estas operações requerem HTTPS, autorização adequada e um corpo de pedido ou objeto-alvo válido. O corpo do pedido para a criação ou atualização de objetos é uma representação WhoisResource do objeto. Para pedidos POST, PUT e DELETE, especifique o apropriado Tipo de conteúdo e Aceitar cabeçalhos. As representações de objetos suportadas incluem application/json e application/xml.
Criar um objeto
Utilizar POST /{fonte}/{tipodeobjeto} para criar um novo objeto. Um pedido bem-sucedido devolve o objeto recém-criado, sem filtros.
Atualizar um objeto
Utilizar PUT /{source}/{objecttype}/{key} submeter uma nova versão de um objeto existente.
Remover um objecto
Utilizar ELIMINAR /{source}/{objecttype}/{key} apenas quando o objeto já não for necessário e a eliminação estiver autorizada.
Não coloque uma chave de API, um valor de Autenticação Básica, um certificado, uma palavra-passe ou uma credencial de mantenedor em HTML do WordPress, JavaScript do front-end, num repositório Git público, numa captura de ecrã ou num e-mail. Os pedidos autenticados devem ser efetuados num serviço seguro do lado do servidor, num executor de automação controlado ou num ambiente profissional de gestão de segredos.
5 Validar primeiro as alterações com uma execução de teste
Utilize o dry-run=true parâmetro de consulta para validar um pedido POST, PUT ou DELETE proposto sem efetuar a atualização. Esta é a forma preferida de testar a estrutura do pedido, o conteúdo do objeto e o comportamento da autorização antes de qualquer alteração em produção. O exemplo abaixo destina-se intencionalmente ao endpoint de teste e utiliza valores de marcador de posição. Só deve ser adaptado por um administrador autorizado que esteja a trabalhar com um objeto de teste válido e credenciais seguras.
curl -X PUT \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
--data @object.json \
"https://rest-test.db.ripe.net/test/person/EXAMPLE-TEST?dry-run=true"O opcional não formatado o parâmetro pode ser utilizado quando uma aplicação precisa de preservar a formatação fornecida no pedido, incluindo espaços e quebras de linha. Para pedidos de eliminação, o parâmetro opcional razão pode ser fornecido um parâmetro para documentar o motivo pelo qual o objeto está a ser removido. Uma execução a seco valida o pedido, mas não cria, atualiza ou elimina o objeto de destino.
6 Interpretar códigos de estado HTTP e respostas da API
As aplicações cliente devem utilizar códigos de estado HTTP para determinar o resultado de uma operação e devem ler o corpo da resposta quando ocorre um erro. O corpo da resposta é devolvido no formato JSON ou XML solicitado. Uma resposta de atualização bem-sucedida contém o objeto tal como aparece na base de dados após a operação, o que é útil quando uma aplicação necessita de uma confirmação imediata do resultado armazenado.
7 Plano para a codificação e a latência das atualizações
As respostas da API REST são devolvidas em UTF-8. Os objetos da Base de Dados RIPE são armazenados utilizando o conjunto de caracteres Latin-1, pelo que o conteúdo do pedido deve utilizar UTF-8, mantendo-se dentro dos caracteres Latin-1 válidos. Se for necessário converter um carácter não suportado, o serviço pode substituí-lo por um ponto de interrogação e devolver um aviso. Após uma operação de escrita, execute uma consulta de seguimento ou confie na resposta de mutação bem-sucedida para confirmar o que foi armazenado.
As actualizações da base de dados podem não ficar visíveis imediatamente nas operações de consulta e pesquisa. O atraso máximo documentado pode ser de até dez segundos. Os objectos não hierárquicos, como os objectos person, role e organisation, são frequentemente visíveis mais rapidamente. Os tipos de objectos hierárquicos, incluindo os objectos inetnum, inet6num, route, route6 e domain, podem demorar vários segundos a aparecer em pesquisas posteriores. Por conseguinte, a automatização em produção deve incluir lógica de novas tentativas e não deve considerar que uma falha imediata na consulta comprova que uma actualização bem-sucedida falhou.
Como os objetos de rota da Base de Dados RIPE suportam a filtragem de BGP
O BGP é o protocolo de encaminhamento que permite aos Sistemas Autónomos trocar informações de acessibilidade através da Internet. Quando uma empresa anuncia um prefixo IPv4 ou IPv6, o seu fornecedor upstream tem de decidir se aceita essa rota. Para reduzir o risco de fugas de rotas, sequestro de prefixos, anúncios acidentais e violações de políticas, muitos fornecedores utilizam filtros de encaminhamento.
Um objecto de rota é uma das entradas que pode suportar este processo de filtragem. O objecto indica que um determinado prefixo se destina a ser originado por um determinado ASN. Por exemplo, se uma empresa operar AS64500 e anuncia 203.0.113.0/24, um objeto de rota pode documentar essa relação. Um fornecedor pode utilizar o objeto de rota ao criar um filtro de prefixos que permita ao ASN anunciar apenas esse prefixo esperado.Isto não significa que todos os fornecedores utilizem a mesma política de filtragem. Alguns fornecedores utilizam extensivamente objetos de rota IRR. Outros dependem mais fortemente de RPKI. Muitos utilizam uma combinação de RPKI, dados IRR, regras de política internas, contratos com clientes, limites de prefixos e revisão manual. Por conseguinte, uma empresa não deve presumir que a criação de um objeto de rota garante automaticamente a aceitação de rotas em todo o lado.A melhor abordagem operacional é coordenar com o fornecedor upstream antes do anúncio. A empresa deve confirmar quais os prefixos que serão anunciados, qual o ASN que os irá originar, se o fornecedor exige objetos de rota IRR, se são necessários ROAs RPKI, qual o comprimento máximo de prefixo permitido e se o fornecedor tem algum processo de registo de rotas ou de abertura de tickets.
Um erro comum é configurar o BGP primeiro e tratar dos registos de rotas mais tarde. Isto pode causar atrasos, porque o fornecedor pode rejeitar o anúncio até que os dados de registo estejam completos. Um processo melhor é preparar o objeto de rota, criar ou validar o ROA, verificar os registos do ASN e da organização, depois configurar a sessão BGP e realizar testes controlados.
Base de Dados RIPE e RPKI: Semelhantes mas Diferentes
A Base de Dados RIPE e o RPKI estão relacionados com a segurança do encaminhamento, mas desempenham funções diferentes. A Base de Dados RIPE contém informações de registo e de políticas de encaminhamento mantidas publicamente. O RPKI, ou Resource Public Key Infrastructure, é uma estrutura criptográfica utilizada para criar Autorizações de Origem de Rotas.
Um objeto de rota pode indicar que um prefixo IP específico se destina a ser originado por um ASN específico. Uma ROA autoriza criptograficamente um ASN a originar um prefixo específico e também pode definir o comprimento máximo do prefixo que pode ser anunciado. As redes que efetuam a validação da origem das rotas RPKI podem utilizar ROAs para classificar as rotas recebidas como válidas, inválidas ou não encontradas.
Por exemplo, uma organização pode deter um prefixo IPv6 e operar um ASN. Pode criar um objeto route6 na RIPE Database para documentar o ASN de origem pretendido. Pode também criar um ROA que autorize esse ASN a anunciar o prefixo. O objeto route6 pode ajudar na filtragem baseada em IRR, enquanto o ROA suporta a validação criptográfica da origem da rota.Os dois devem ser mantidos de forma consistente. Se o objeto de rota apontar para um ASN, mas o ROA autorizar outro ASN, os fornecedores upstream e os operadores de rede poderão observar sinais contraditórios. Se o ROA tiver um comprimento máximo de prefixo incorreto, os anúncios legítimos de prefixos mais específicos poderão ser marcados como inválidos. Se um objeto de rota estiver desatualizado, um fornecedor que utilize filtros baseados em IRR poderá rejeitar um anúncio que, de outro modo, seria legítimo.
As organizações devem rever os seus objetos de rota e ROAs sempre que alterem os seus acordos de ASN, mudem de LIR patrocinador, transfiram recursos IPv4, reestruturem a empresa, adicionem um novo fornecedor upstream ou alterem a sua política de anúncio de prefixos. Os registos de encaminhamento devem ser tratados como dados operacionais vivos, e não como tarefas de configuração pontuais.
Utilizar a API REST da Base de Dados RIPE
A API REST da Base de Dados RIPE permite que os sistemas de software obtenham e, quando devidamente autorizados, gerem objetos da Base de Dados RIPE através de pedidos programáticos. A API pode ser útil para organizações que operam muitas redes, mantêm grandes portefólios de recursos IP, executam sistemas de monitorização, desenvolvem portais de clientes ou precisam de integrar dados do registo em fluxos de trabalho internos.
Um fluxo de trabalho simples de uma API REST pode começar com um pedido de pesquisa. O sistema envia uma consulta para um ASN, endereço IP, prefixo, identificador de organização, nome de rede ou outro valor conhecido. A base de dados devolve dados estruturados, normalmente em formato JSON ou XML. A aplicação pode então analisar o resultado e apresentar atributos relevantes a um operador ou comparar o resultado com registos internos.
Por exemplo, um fornecedor de serviços cloud pode utilizar consultas à API apenas para leitura para verificar se existe um ASN fornecido pelo cliente e se os registos de encaminhamento públicos correspondem às informações de integração. Um sistema de segurança de rede pode utilizar consultas à API para identificar um contacto de abuso registado para um intervalo de endereços. Uma plataforma de gestão de recursos IP pode comparar o seu inventário interno com os registos de registo públicos para identificar contactos desatualizados ou objetos de rota em falta.
A API deve ser utilizada de forma responsável. Os sistemas automatizados devem evitar um volume excessivo de consultas, devem lidar com os erros de forma adequada e não devem considerar um único resultado da base de dados como prova conclusiva de propriedade, autorização ou estado de encaminhamento em tempo real. Um fluxo de trabalho robusto pode combinar resultados da API da RIPE Database com validação de RPKI, dados de monitorização do BGP, contratos internos, verificação de clientes e análise manual.
Para pedidos apenas de leitura, uma ferramenta de linha de comandos como o cURL pode ser suficiente. Um programador pode enviar um pedido GET para o endpoint de pesquisa, definir um valor de pesquisa, aplicar um filtro de origem e solicitar uma resposta JSON. A resposta pode depois ser analisada em Python, PHP, JavaScript, Go, Java ou qualquer outra linguagem de programação capaz de ler JSON.Quando se trabalha com atualizações de objetos, o risco é maior. As alterações aos objetos de rota, contactos, registos de organizações ou responsáveis pela manutenção podem afetar o encaminhamento em produção, a resposta a incidentes e a continuidade do negócio. As operações de escrita requerem uma autorização adequada através do responsável pela manutenção relevante ou do processo de registo. As credenciais devem ser armazenadas de forma segura no lado do servidor ou num sistema aprovado de gestão de segredos. Nunca devem ser incorporadas em HTML de websites, JavaScript do front-end, repositórios públicos, armazenamento local do navegador, capturas de ecrã, modelos de e-mail ou ficheiros de configuração não encriptados.
Uma empresa deve também estabelecer procedimentos de gestão de alterações. Antes de atualizar um objeto de rota ou um registo relacionado com ASN, o engenheiro responsável deve verificar o prefixo pretendido, o ASN de origem, o estado do RPKI, os requisitos do fornecedor upstream, o processo de autorização e o impacto potencial da alteração. Para organizações de maior dimensão, uma revisão por uma segunda pessoa pode ajudar a evitar erros acidentais nas políticas de encaminhamento.
Qualidade dos Dados da Base de Dados RIPE e Erros Comuns
A qualidade dos dados é uma das questões mais importantes na RIPE Database. Uma empresa pode ter recursos IP legítimos e um ASN ativo, mas se os objetos associados estiverem desatualizados, forem inconsistentes ou forem mal mantidos, a empresa pode ainda enfrentar problemas técnicos e operacionais.Um erro comum é utilizar os dados pessoais de funcionários como o único contacto técnico ou administrativo. Os funcionários mudam de funções, deixam as empresas, alteram os endereços de e-mail ou ficam indisponíveis durante incidentes. Um objeto de função funcional, como um Centro de Operações de Rede ou um contacto do Serviço de Abusos, é frequentemente mais duradouro. A empresa pode atualizar as pessoas por detrás da função sem ter de alterar todos os objetos de recursos associados.
Outro erro comum é não atualizar as informações da organização após uma alteração da denominação legal, aquisição, fusão ou reestruturação empresarial. Se a entidade legal associada a um ASN ou bloco de IP mudar, os registos do registo podem ter de ser revistos. A empresa deve coordenar-se com o seu LIR patrocinador ou prestador de serviços de registo, em vez de presumir que uma alteração legal interna é automaticamente refletida nos registos públicos da Internet. Algumas organizações também criam objetos de rota, mas não os mantêm. Podem adicionar um novo fornecedor upstream, alterar um ASN, transferir um prefixo ou alterar a sua arquitetura BGP sem atualizar os registos de encaminhamento. Isto pode criar uma discrepância entre a política de encaminhamento pretendida e as informações disponíveis nas bases de dados públicas.
Uma questão relacionada é tratar objetos de rota IRR e ROAs RPKI como intercambiáveis. Não são. Ambos podem ser úteis, e cada um pode ser exigido por diferentes fornecedores ou sistemas de validação. Um processo moderno de segurança do encaminhamento deve analisar ambos.
Por fim, as organizações devem proteger cuidadosamente o acesso do responsável pela manutenção. Os controlos do responsável pela manutenção associados a um objeto podem determinar quem o pode atualizar. Perder o acesso a um responsável pela manutenção pode dificultar futuras atualizações. Partilhar de forma insegura as credenciais do responsável pela manutenção pode criar um risco de segurança inaceitável. As empresas devem documentar a titularidade, armazenar as credenciais de forma segura e manter um processo interno claro para a recuperação do acesso e para alterações autorizadas.
Base de Dados RIPE, Transferências de IPv4 e Diligência Devida sobre Recursos
A Base de Dados RIPE é especialmente relevante durante uma transferência de IPv4. Antes de adquirir espaço de endereçamento IPv4, um comprador deve examinar os registos públicos associados ao prefixo. Estes podem incluir o objeto de endereço atual, a referência da organização, o nome da rede, o estado do recurso, os contactos técnicos, o contacto de abuso, os objetos de rota e os detalhes do mantenedor.
O objetivo não é apenas confirmar que o prefixo existe. O comprador deve verificar se as informações de registo parecem consistentes, se o bloco de endereços tem objetos de rota existentes, se a sua utilização histórica pode suscitar preocupações de reputação e se o processo de transferência pode ser tratado corretamente através do processo de registo relevante.
Por exemplo, um comprador pode descobrir que um bloco IPv4 tem objetos de rota activos associados a um ASN que já não será utilizado após a transferência. O comprador poderá ter de coordenar a remoção ou substituição desses registos, criar novos objectos de rota para o seu próprio ASN e actualizar as ROAs de RPKI antes de anunciar o prefixo a partir da sua rede.
O comprador deve também considerar a reputação do correio eletrónico e da segurança. Um intervalo de IP público pode ter sido utilizado para alojamento, entrega de correio eletrónico, serviços de proxy, serviços de VPN ou outras cargas de trabalho. Se o bloco tiver sido associado a abuso, spam, malware ou tráfego suspeito, o novo operador poderá ter de dedicar tempo a recuperar a reputação após a transferência. A RIPE Database não fornece um histórico completo da reputação, mas pode ajudar a identificar operadores anteriores e pontos relevantes para uma investigação mais aprofundada.Um processo profissional de transferência de IPv4 deve, por conseguinte, incluir diligência devida junto do registo, verificação jurídica, planeamento técnico, preparação da segurança do encaminhamento, análise do contrato e validação pós-transferência. A RIPE Database constitui uma base valiosa para este processo, mas deve ser utilizada em conjunto com outras fontes de informação.
Como as Empresas Devem Manter os Seus Registos na Base de Dados RIPE
Uma empresa deve tratar da manutenção da RIPE Database como uma responsabilidade operacional contínua. A abordagem mais eficaz consiste em atribuir uma responsabilidade interna clara. Uma equipa ou função designada deve ser responsável por monitorizar alterações aos dados da empresa, recursos IP, ASNs, contactos, objetos de rota e registos RPKI.A empresa deve rever periodicamente os seus registos públicos. Deve confirmar que os nomes das organizações estão atualizados, que os contactos técnicos estão contactáveis, que os contactos de abuso são monitorizados, que os controlos dos maintainers estão acessíveis, que os objetos de rota correspondem aos anúncios BGP reais e que as ROAs RPKI são consistentes com a política de encaminhamento.
Uma revisão é especialmente importante antes de alterações significativas na rede. Se a empresa estiver a adicionar um segundo fornecedor de trânsito, a mudar para um novo centro de dados, a alterar a sua arquitetura BGP, a adquirir um novo bloco IPv4, a receber recursos IPv6, a mudar o seu LIR patrocinador ou a reestruturar a sua entidade jurídica, os registos no registo devem ser revistos como parte do plano do projeto.As empresas que não disponham de conhecimentos especializados internos sobre recursos de Internet podem trabalhar com um LIR patrocinador, um consultor de redes, um fornecedor de serviços geridos ou um engenheiro BGP experiente. O objetivo não é simplesmente preencher um formulário do registo. O objetivo é garantir que os registos jurídicos, os registos técnicos, a política de encaminhamento, os controlos de segurança e os processos operacionais funcionam em conjunto.
A Base de Dados RIPE Faz Parte da Sua Infraestrutura de Internet
A Base de Dados RIPE é muito mais do que uma ferramenta pública de consulta. É um registo central de endereços IP, prefixos IPv6, ASNs, registos de encaminhamento, organizações, contactos e mantenedores na região de serviço do RIPE NCC. Para as empresas que operam infraestruturas públicas da Internet, os seus registos podem influenciar a aceitação de encaminhamento, a resposta a incidentes, a conformidade, a gestão de recursos IP e a reputação da rede.
Uma presença devidamente mantida na Base de Dados RIPE promove a transparência e a confiança técnica. Ajuda os fornecedores upstream a compreender que prefixos se espera que uma rede anuncie. Ajuda as equipas de segurança a identificar os contactos relevantes. Ajuda as empresas a validar os recursos antes de uma transferência de IPv4. Ajuda os operadores de rede a manter informações consistentes sobre ASN, objetos de rota e RPKI.As empresas devem utilizar a base de dados com cuidado e ter em mente as suas limitações. Um objeto da base de dados não é uma garantia de visibilidade BGP ativa, propriedade legal ou qualidade da reputação. É uma parte importante de um processo mais abrangente de gestão da infraestrutura da Internet. O modelo operacional mais sólido combina objetos corretos da Base de Dados RIPE com uma configuração BGP correta, ROAs RPKI válidos, acesso seguro aos maintainer, documentação organizacional atualizada, tratamento fiável de abusos e monitorização contínua.
Para qualquer empresa que utilize um ASN do RIPE NCC, recursos IPv4, prefixos IPv6 ou encaminhamento BGP, a manutenção de registos precisos na Base de Dados do RIPE deve ser considerada uma responsabilidade central de gestão da rede.