AS60077 torna Cloud.ir visível na Internet, sem revelar o

Resumo

Em 20 de julho de 2026, RIPE RDAP e RIPEstat descreviam AS60077 como um sistema autônomo ativo e anunciado, origem de 18 prefixos IPv4 representando 14.080 endereços, com visibilidade junto a 324 dos 325 peers RIS IPv4 observados.
O dossiê público não mostrava nenhum prefixo IPv6 atualmente originado pelo AS60077, apenas AS43754 como vizinho observado e não revelava no PeeringDB nem ponto de troca nem site declarado. Essas constatações, no entanto, não provam a ausência de IPv6, sites ou outros caminhos privados.
As páginas ativas da Cloud.ir estabelecem a existência de uma oferta comercial ampla e o SLA detalha alguns de seus limites. Elas não vinculam cada serviço ao AS60077 nem demonstram o percurso físico, a capacidade utilizável, a diversidade independente de acessos ou o comportamento de recuperação.
Portanto, a questão útil não é saber se a Asre Dadeha Asiatech possui uma presença de rede pública – essa presença está bem documentada. É determinar até onde essa visibilidade permite avaliar a entrega concreta de um serviço em nuvem e onde começam as áreas que as vinte fontes não permitem verificar.

Uma prova de rede que não deve se tornar uma prova universal

A pegada do AS60077 oferece um ponto de partida excepcionalmente preciso em comparação com muitas ofertas em nuvem cuja rede permanece difícil de atribuir. Um sistema autônomo anunciado deixa rastros que vários registros e observatórios podem comparar: um nome, uma organização declarante, prefixos, uma origem BGP, vizinhos observados e, para algumas rotas, uma autorização RPKI. Esses elementos permitem testar parte do relato público sem depender apenas do vocabulário comercial da Cloud.ir.

Essa precisão, no entanto, tem uma fronteira. O BGP indica como os destinos são anunciados para o resto da Internet; ele não descreve automaticamente os edifícios, os servidores, os sistemas de armazenamento ou os contratos que estão por trás deles. Uma rota pode ser estável e amplamente vista, enquanto um produto específico pode seguir uma arquitetura diferente. Por outro lado, uma função de serviço pode estar disponível sem ser diretamente identificável como um prefixo originado pelo AS60077. As fontes não fornecem uma tabela que relacione cada produto, cada endereço e cada site.

Portanto, é necessário ler o dossiê em várias camadas. A primeira diz respeito à identidade administrativa da rede. A segunda se refere ao seu comportamento público observado no momento da coleta. A terceira trata da superfície comercial da Cloud.ir. A quarta, mais difícil de documentar, seria a da entrega física e da recuperação: localização exata, caminhos independentes, capacidade disponível, failover e restauração. As três primeiras camadas contêm evidências concretas. A quarta é composta principalmente por declarações do operador e questões em aberto.

Essa separação não enfraquece os resultados positivos. Ela lhes dá um alcance preciso. Dizer que o AS60077 está ativo, anunciado e muito visível na amostra RIS é uma conclusão sólida. Dizer que essa visibilidade por si só comprova a resiliência de todos os serviços da Cloud.ir seria uma extrapolação que o dossiê não permite. O desafio da análise é justamente manter a força da primeira constatação sem deslizar para a segunda.

A identidade administrativa do AS60077 é clara e atual

O RIPE RDAP registra AS60077 sob o nomeAT-CLOUD, com status ativo. A organização declarante éORG-ADA42-RIPE/ Asre Dadeha Asiatech. O registro do ASN data de 27 de junho de 2022 e a última modificação indicada é de 23 de janeiro de 2026. Essas datas não comprovam uma atividade comercial diária, mas mostram que o objeto do registro não é anônimo nem está congelado desde uma época distante.

A visão geral do RIPEstat complementava essa identidade. No momento da consulta em 20 de julho de 2026 às 8h UTC, ele associava AS60077 ao detentorAT-CLOUD Asre Dadeha Asiateche retornavaannounced=true. O registro e a observação de roteamento contavam, portanto, uma história compatível: o número é atribuído à entidade estudada e é anunciado publicamente no momento considerado.

Essa compatibilidade é importante porque as diferentes fontes não desempenham a mesma função. O RIPE RDAP descreve um registro administrativo. O RIPEstat agrega observações e dados de roteamento. O bgp.tools oferece uma síntese pública adicional. Quando convergem em nome, status e número de prefixos IPv4, aumenta a confiança na identificação do controle da rede. Não se trata mais de inferir o operador a partir de um logotipo ou de uma página de vendas.

A convergência, no entanto, não transforma a organização declarante no proprietário comprovado de cada recurso físico que serve ao produto. Um ASN identifica um domínio de política de roteamento. Ele não constitui nem um inventário de ativos nem um organograma operacional completo. O dossiê permite atribuir o AS60077 à Asre Dadeha Asiatech; não permite concluir sobre a propriedade dos edifícios, das fibras, dos geradores, dos equipamentos ou de toda a capacidade mencionada nas páginas de serviço.

O nomeAT-CLOUDnaturalmente fortalece a associação com a oferta da Cloud.ir, mas o nome não substitui um mapeamento técnico. A ligação documental é plausível e coerente: os registros identificam a Asre Dadeha Asiatech, enquanto as páginas oficiais apresentam a Cloud.ir como uma oferta de serviços baseada nos data centers da Asiatech. Essa aproximação estabelece um contexto comum. Ela ainda não fornece o caminho de ponta a ponta de um servidor, de um VPS, de um objeto armazenado ou de um tráfego de CDN.

Dezoito anúncios IPv4 formam uma pegada substancial

O status de roteamento do RIPEstat contava 18 prefixos IPv4 originados pelo AS60077 e 14.080 endereços IPv4. A lista de anúncios mostra como esse total se compõe. Ela inclui78.110.112.0/21, depois85.198.8.0/22,85.198.12.0/22,85.198.16.0/23,85.198.19.0/24,85.198.20.0/23e85.198.22.0/23.

No espaço193.151, os anúncios incluem os blocos193.151.128.0/22,193.151.132.0/22,193.151.136.0/22,193.151.140.0/22,193.151.144.0/22,193.151.148.0/22e193.151.152.0/22. Quatro prefixos mais específicos completam o conjunto:193.151.156.0/24,193.151.157.0/24,193.151.158.0/24e193.151.159.0/24. Essa enumeração não descreve o uso de cada bloco, mas mostra que o número global se baseia em uma série de anúncios identificáveis, e não em uma estimativa comercial.

Às 16h UTC de 20 de julho de 2026, o RIPEstat fornecia193.151.156.0/24como o último prefixo observado. O mesmo status indicava que 324 dos 325 peers RIS IPv4 selecionados viam o AS60077. Tal proporção significa que a origem era amplamente visível nesse sistema de coleta no momento da medição. Não garante que cada usuário da Internet dispunha de um caminho com bom desempenho, mas exclui a imagem de um anúncio apenas marginal ou invisível na amostra.

O bgp.tools também apresentava o AS60077 como uma rede ativa, com 18 prefixos IPv4 originados, nenhum prefixo IPv6 originado e o AS43754 como upstream. A ficha utilizava, inclusive, uma etiqueta relacionada à hospedagem de servidores. Essa síntese é útil como corroboração pública, mas não acrescenta uma prova de capacidade para o cliente. Uma etiqueta de categoria descreve a forma como a rede é classificada; ela não mede o número de máquinas ativas, a taxa de ocupação ou o volume de recursos ainda disponíveis.

A pegada pode servir como base para monitoramento. Uma variação no número de prefixos, uma mudança de origem ou uma evolução na visibilidade RIS seriam observáveis ao longo do tempo. Para uma equipe de due diligence, esses indicadores são mais úteis quando possuem carimbo de tempo e são comparados a observações posteriores. Isoladamente, eles fornecem uma fotografia. Comparados ao longo do tempo, podem sinalizar uma expansão, uma contração, uma migração ou um incidente a ser examinado.

Mesmo nesse papel de monitoramento, a prudência ainda é necessária. Os coletores não observam cada sessão BGP privada e sua visão depende de seus pontos de observação. Uma rota vista por quase todos os peers RIS não é sinônimo de um serviço sem falhas. Ela indica que uma informação de controle é amplamente propagada. A qualidade da entrega ainda depende dos caminhos de dados, da congestão, dos equipamentos, dos sites e das aplicações que esses anúncios não descrevem.

O espaço de endereçamento não é uma medida de capacidade em nuvem

O número de 14.080 endereços IPv4 parece quantitativo, o que o torna fácil de ser superinterpretado. Ele mede o tamanho teórico dos prefixos atualmente atribuídos à origem na visão utilizada. Não revela quantos endereços estão alocados, reservados, não utilizados, compartilhados, filtrados ou dedicados a funções internas. Também não diz quantos clientes, máquinas virtuais ou serviços correspondem a esse espaço.

Um endereço público pode representar uma máquina, um equipamento de borda, uma função de tradução, uma terminação compartilhada ou um recurso temporário. Várias cargas podem compartilhar um mesmo endereço, enquanto uma única arquitetura pode consumir vários endereços. Portanto, a relação entre espaço anunciado e capacidade de computação não é fixa nem diretamente calculável a partir das rotas. A mesma ressalva vale para armazenamento, memória, largura de banda vendável e energia elétrica.

Essa distinção é central no caso da Cloud.ir, pois o catálogo apresenta várias famílias de produtos. Um servidor em nuvem, um VPS, um serviço de armazenamento, um CDN e um gerenciamento de domínios não expõem necessariamente seus recursos da mesma forma. As vinte fontes não vinculam os 18 prefixos a um detalhamento por produto. Também não permitem identificar a parcela do espaço reservada à infraestrutura de controle, aos serviços internos ou aos clientes.

A capacidade realmente utilizável é um conceito operacional e econômico. Ela depende do hardware instalado, dos limites de superalocação, das reservas de segurança, da demanda de pico e das restrições do site. Depende também da capacidade de rede disponível para os usuários, não apenas do número de endereços. Nenhum desses parâmetros é quantificado no corpus estudado.

Uma análise rigorosa deve, portanto, recusar dois atalhos. O primeiro seria tratar os 14.080 endereços como 14.080 unidades comerciais. O segundo seria considerar que a ausência de dados de capacidade significa que não existe capacidade significativa. O dossiê estabelece uma superfície IPv4 de tamanho mensurável; não permite converter essa superfície em oferta vendável ou carga sustentável.

Para um comprador, o uso correto do número é mais modesto. Pode servir para verificar se o operador controla uma pegada pública coerente e para identificar os prefixos associados a um serviço durante testes. Não substitui um compromisso sobre recursos, uma arquitetura de capacidade, limites de contenção ou evidências de desempenho. Um dado de roteamento torna-se útil para a due diligence quando está vinculado a um produto específico, não quando é transformado em um indicador universal.

O prefixo RPKI válido alinha três tipos de evidência

O prefixo193.151.156.0/24oferece um ponto de controle particularmente instrutivo. A validação RPKI do RIPEstat retornava o statusvalid, com ROA cobrindo a origem 60077. Isso significa que, para essa amostra, a associação entre o prefixo anunciado e o AS60077 respeita a autorização de origem publicada.

O RIPE RDAP vinculava o mesmo prefixo à faixa PA ativaIR-AT-20210316, registrada para o Irã e cobrindo193.151.128.0a193.151.158.255. O registro mencionavaASIATECH-MNTe os contatos administrativos e técnicos do Asiatech NOC. Uma observação BGP, uma autorização RPKI e uma atribuição de recurso administrativo se encontram, assim, em torno de um mesmo exemplo.

Esse alinhamento é mais convincente do que uma única linha de registro. Mostra que a origem efetivamente vista corresponde à origem autorizada para o prefixo testado e que o espaço está vinculado a uma faixa gerenciada sob identificadores Asiatech. Para a atribuição de rede, é um resultado positivo. Reduz o risco de confundir o AS60077 com um número apenas mencionado em uma página ou com uma origem não autorizada para esse exemplo.

O escopo da validação, no entanto, deve permanecer restrito. O resultado diz respeito ao193.151.156.0/24no momento da consulta. O corpus não fornece uma auditoria RPKI detalhada de cada um dos 18 prefixos. Portanto, seria incorreto afirmar que toda a pegada é necessariamente válida com base apenas nessa amostra. A conclusão verificável é que pelo menos uma rota corrente importante possui uma autorização RPKI coerente.

O RPKI também não certifica o serviço por trás do endereço. O mecanismo ajuda as redes a julgar se uma origem é autorizada para um prefixo. Não testa nem a disponibilidade de um servidor nem a integridade dos dados. Não confirma o edifício, o proprietário do hardware, a energia de reserva, o isolamento entre clientes ou a qualidade do suporte. Uma rota pode ser RPKI válida e ainda assim levar a um serviço indisponível por outro motivo.

Essa limitação não é uma fraqueza do RPKI; reflete seu objetivo. Uma boa análise não pede a um mecanismo de segurança de roteamento que resolva uma questão de continuidade de negócios. Ela utiliza o resultado pelo que ele prova: a autorização da origem. Em seguida, busca outros elementos para capacidade, redundância e recuperação.

Para uma equipe de cliente, esse prefixo pode, no entanto, tornar-se um ponto de referência concreto. Ela pode verificar se seus próprios endereços ou destinos da Cloud.ir estão entre os anúncios atribuídos ao AS60077, se a origem permanece estável e se o status RPKI continua coerente. Esse controle não responde a todas as perguntas, mas transforma parte da relação em um sinal observável, em vez de uma simples promessa.

BGP e RIPE Whois não descrevem o mesmo estado

A visão de consistência do RIPEstat traz outra distinção essencial. Os prefixos IPv4 do AS60077 vistos no BGP também apareciam no RIPE Whois. Essa aproximação sustenta a consistência administrativa dos anúncios correntes. Ela reduz a lacuna entre as rotas observadas e os objetos publicados no registro.

A mesma visão mostrava, no entanto, várias faixas mais amplas ou componentes presentes no RIPE Whois sem serem vistas no BGP. Esse descompasso não é necessariamente uma anomalia. Um objeto de registro pode cobrir um recurso reservado, um agregado, uma política potencial ou uma configuração que não está sendo anunciada atualmente nessa forma. O registro descreve o que é declarado; o BGP mostra uma parte do que é efetivamente propagado.

Essa diferença impõe uma disciplina de vocabulário. Uma faixa registrada no Whois não é automaticamente uma rota ativa. Uma política de importação não é automaticamente uma sessão visível. Por outro lado, a ausência de uma relação na visão pública não prova que não existe nenhuma relação privada ou temporária. É necessário especificar se estamos falando de um objeto administrativo, de uma política declarada ou de uma observação de roteamento.

AS43754 ilustra uma convergência: ele aparece nas informações de import e export tanto no BGP quanto no Whois. AS212895 ilustra o caso oposto: ele figurava nos dados de import do Whois, mas não no BGP. O dossiê permite, portanto, afirmar que o AS43754 é tanto declarado quanto observado no papel examinado. Não permite apresentar o AS212895 como um caminho ativo com base apenas na declaração.

Essa nuance se torna determinante quando se avalia a redundância. Uma lista de políticas pode dar a impressão de várias opções, mas uma opção registrada ainda não é um caminho disponível, testado e dimensionado. Para apoiar uma afirmação de failover, seria necessário observar o caminho, conhecer sua independência e dispor de elementos sobre seu funcionamento em caso de falha. Nenhum desses três níveis está estabelecido para o AS212895 no corpus.

A comparação entre Whois e BGP funciona, assim, como um filtro contra a leitura literal dos registros. Ela preserva o valor das declarações sem confundi-las com o estado real da rede. No caso do AS60077, ela fortalece a confiança nos prefixos atualmente vistos, ao mesmo tempo que impede de transformar cada objeto ou cada import declarado em capacidade operacional.

O IPv6 é um sinal pontual, não uma origem corrente demonstrada

A fotografia IPv6 contrasta fortemente com a superfície IPv4. O status de roteamento do RIPEstat não contava nenhum prefixo IPv6 atualmente visível como originado pelo AS60077. Nenhum dos 321 peers RIS IPv6 da amostra via o sistema autônomo nesse papel. O bgp.tools também indicava zero prefixo IPv6 originado.

A lista de prefixos anunciados, no entanto, continha2a05:1a30::/34para um único carimbo de tempo, em 13 de julho de 2026. Essa observação é suficientemente precisa para ser preservada, mas muito limitada para sustentar uma conclusão de serviço duradouro. Pode corresponder a um anúncio breve, a um teste, a uma transição ou a um evento que as fontes não descrevem. As fontes reunidas não fornecem explicação nem continuidade.

Dois erros simétricos são possíveis. O primeiro seria usar essa entrada única para afirmar que o AS60077 opera atualmente uma origem IPv6 estável. O status de roteamento atual não estabelece isso. O segundo seria afirmar que nenhum serviço da Cloud.ir possui IPv6. Os produtos poderiam usar outra origem, utilizar caminhos que a coleta não vincula ao AS60077 ou oferecer funções que não são visíveis nesses dados.

A formulação defensável é, portanto, limitada no tempo e no objeto: no momento da fotografia, o dossiê não mostrava um prefixo IPv6 atualmente originado pelo AS60077, apesar de um aparecimento pontual de2a05:1a30::/34uma semana antes. Essa frase descreve exatamente a observação sem transformar a ausência atual em ausência universal.

Para um cliente que exige conectividade dual stack, essa incerteza deve levar a uma verificação por produto. Seria necessário perguntar quais endereços IPv6 são atribuídos, qual sistema autônomo os origina, quais serviços são cobertos e como a conectividade é testada. Uma simples menção ao IPv6 não seria suficiente; por outro lado, a visão do AS60077 não é suficiente para descartar toda possibilidade.

O episódio de 13 de julho também pode servir como ponto de monitoramento. Se o prefixo reaparecer de forma estável, a conclusão poderá evoluir. Se permanecer ausente, o dossiê continuará descrevendo uma pegada pública essencialmente IPv4. Uma análise com carimbo de tempo permite essa atualização sem apagar o que foi realmente observado.

AS43754 é a dependência visível, não uma prova de diversidade independente

A visão de vizinhos do RIPEstat retornava apenas AS43754 para o AS60077. RIPEstat e RIPE RDAP descreviam AS43754 como ativo e detido pela Asiatech Data Transmission company. O bgp.tools também o apresentava como upstream do AS60077. Várias fontes convergem, portanto, para uma relação visível e para a identidade da outra rede.

Essa convergência permite nomear a dependência pública observada. Não permite traçar toda a topologia. Os coletores podem perder relações privadas, sessões de backup, caminhos não exportados ou configurações que são ativadas apenas em caso de incidente. O fato de apenas um vizinho aparecer não é uma prova matemática de que não existem outros.

Mas a ressalva sobre os pontos cegos não deve ser invertida. Não se pode usar a possibilidade de caminhos invisíveis para afirmar uma redundância independente. No dossiê, nenhum segundo upstream ativo e independente é verificado. O AS212895 aparece em uma declaração Whois, mas não é observado no BGP. O AS43754 continua sendo o único vizinho que os dados públicos reunidos mostram efetivamente.

A identidade do AS43754 adiciona uma questão de domínio de falha. Ele é atribuído à Asiatech Data Transmission company, enquanto o AS60077 é atribuído à Asre Dadeha Asiatech. Os nomes indicam uma proximidade Asiatech, mas as fontes não fornecem a estrutura jurídica ou operacional detalhada que permitiria mapear todas as suas dependências comuns. Portanto, seria excessivo declarar que eles compartilham necessariamente cada equipamento ou cada site.

Seria igualmente excessivo tratar o AS43754 como prova de independência externa. Uma diversidade útil se julga pelos recursos realmente separados: operadora, fibras, entradas de edifício, equipamentos, alimentação, controle e capacidade. O número diferente de um sistema autônomo não estabelece por si só que essas dimensões são independentes. O corpus não traz as informações necessárias para realizar esse teste.

A diferença entre redundância e independência é importante. Uma arquitetura pode ter vários equipamentos ou vários links sob o mesmo controle e oferecer proteção real contra certas falhas. Essa proteção pode ser valiosa. Ela não cobre necessariamente uma falha comum que afete a mesma operadora, o mesmo site, a mesma vala de fibra ou o mesmo plano de controle. As fontes não descrevem os cenários cobertos.

Para um comprador, a questão não deveria ser apenas: «Existe um segundo link?» Seria necessário perguntar quem o opera, por onde ele passa, onde termina, que capacidade mantém durante uma falha e quando o failover foi testado. Também seria necessário saber se os serviços abrangidos pelo contrato realmente utilizam esses caminhos. Os dados públicos fornecem um ponto de partida com o AS43754, não as respostas completas.

O vizinho visível também é um lembrete de que a grande difusão dos prefixos não é sinônimo de grande diversidade. Uma rota pode alcançar 324 peers RIS passando por uma dependência concentrada a montante. Os coletores veem o resultado da propagação; não revelam todas as vulnerabilidades físicas que existem antes dessa propagação.

O PeeringDB documenta principalmente o que não é divulgado

O PeeringDB possuía uma ficha de rede corrente para o ASN 60077 em nome da Asre Dadeha Asiatech. Os camposstatus=okerir_status=okindicavam que o registro estava em conformidade no âmbito da plataforma e do registro em questão. A presença da ficha é um sinal adicional de identidade.

O conteúdo operacional público dessa ficha era, no entanto, muito limitado. O PeeringDB indicavaix_count=0efac_count=0. Nenhum site web, looking glass, servidor de rotas ou URL de política era fornecido. A ficha também não divulgava estimativa de tráfego ou abrangência. Para uma base projetada para descrever interconexões, essa falta de detalhes deixa poucos elementos utilizáveis para reconstruir uma implantação.

Os zeros devem ser lidos como zeros de declaração nessa fonte, e não como prova de ausência física. O PeeringDB depende das informações inseridas e mantidas por seus participantes. Uma rede pode utilizar um site sem publicá-lo em sua ficha, conectar-se de forma privada ou optar por não detalhar sua política.fac_count=0não significa, portanto, «nenhum Data Center».

Da mesma forma,ix_count=0não demonstra que não existe nenhuma interconexão. Significa que a ficha não declarava um attachment público a um ponto de troca. As relações de trânsito e as interconexões privadas não se resumem às linhas de ponto de troca. O único vizinho AS43754 observado pelo RIPEstat traz outro tipo de sinal, mas ainda não fornece localização.

Essa ausência de divulgação tem, no entanto, uma consequência prática. Um analista externo não pode usar o PeeringDB para verificar o edifício de origem, a diversidade metropolitana, a separação das entradas de fibra ou a participação em uma matriz pública de troca. A rota é visível em escala da Internet, enquanto seu ponto de partida físico permanece opaco nessa base.

A ficha também não fornece um looking glass que permita a um terceiro examinar a visão de roteamento a partir da própria rede. Ela não publica uma política que explicaria as condições de peering. Essa lacuna não prova uma má operação; ela simplesmente reduz as possibilidades de validação independente a partir de informações abertas.

Para a due diligence, o PeeringDB funciona aqui menos como um mapa e mais como um limite documental. Ele confirma que uma identidade de rede tem uma ficha atual e, em seguida, mostra que os campos capazes de vincular essa identidade a sites e trocas estão vazios. Essa combinação reforça a tese do artigo: o controle IPv4 é visível, mas o caminho físico não é.

Um operador poderia reduzir essa incerteza publicando informações precisas, mas a publicação por si só ainda não provaria a resiliência. Uma declaração de site deveria ser confrontada com uma prova de presença atual; uma declaração de ponto de troca deveria ser confrontada com dados de interconexão. O PeeringDB seria então uma pista melhor, não um certificado universal.

A Cloud.ir possui uma superfície comercial ativa e identificável

O lado comercial do dossiê não é um simples arquivo. O site Cloud.ir respondia em HTTPS no momento da coleta. Sua página inicial, sua página de apresentação, sua página de contato e seu mapa do site de serviços formavam uma superfície acessível a prospects e clientes. Essa disponibilidade distingue a oferta de uma marca que deixaria apenas vestígios históricos.

O mapa do site referenciou páginas dedicadas ao servidor em nuvem, ao VPS, ao data center em nuvem, ao switch em nuvem, ao gerenciamento de domínios, ao CDN e ao armazenamento em nuvem. Os valoreslastmoddas principais páginas estavam em 2025 e 2026. Essas datas não garantem que cada produto foi modificado em profundidade, mas mostram que o catálogo é mantido em um período recente.

As páginas oficiais indicam que o serviço em nuvem começou durante o ano 1399 do calendário iraniano e que oferece mais de vinte produtos. Elas também afirmam que a oferta funciona sobre os data centers da Asiatech no Irã. Esses elementos descrevem o relato operacional da empresa e permitem entender como ela apresenta sua dependência da infraestrutura da Asiatech.

O dossiê sustenta, portanto, duas constatações distintas. Por um lado, o AS60077 possui uma presença IPv4 pública atribuída à Asre Dadeha Asiatech. Por outro lado, a Cloud.ir apresenta atualmente um catálogo em nuvem vinculado, em seus próprios textos, aos data centers da Asiatech. A proximidade dos nomes e das declarações torna a associação pertinente.

Essa associação não constitui, no entanto, uma correspondência serviço por serviço. As fontes não dizem que todo endereço de um servidor em nuvem pertence a um dos 18 prefixos. Elas não dizem que um VPS, um CDN e o armazenamento utilizam exatamente a mesma rede. Elas não revelam os sistemas autônomos eventualmente utilizados para funções externas, mitigação ou distribuição.

A página de contato adiciona uma superfície de relação, mas as fontes não medem a qualidade ou o prazo das respostas. Uma página acessível prova que um canal é publicado; não prova que uma equipe responde a cada hora nem que um incidente complexo será resolvido em um prazo determinado. A mesma distinção deve se aplicar a todo elemento comercial visível.

O interesse do catálogo é, portanto, real, mas circunscrito. Ele estabelece que a Cloud.ir vende e descreve uma gama de serviços. Ajuda a identificar os produtos para os quais uma due diligence mais precisa deveria ser realizada. Não substitui a arquitetura de cada produto. Quanto mais amplo o catálogo, mais arriscada se torna uma atribuição global a um único caminho de rede.

As afirmações sobre data centers continuam sendo declarações do operador

As páginas da Cloud.ir empregam referências à ISO27001, TIA-942 e a níveis apresentados em um vocabulário do tipo Tier 2/3. Elas também associam os serviços a data centers da Asiatech no Irã. Essas afirmações são relevantes porque indicam os padrões e a resiliência que o operador deseja destacar.

O corpus não contém, no entanto, nem certificado independente, nem relatório de auditoria, nem lista exata dos sites aos quais cada afirmação se aplica. Não fornece o escopo de uma eventual certificação, seu período de validade, a entidade certificada ou as exclusões. Uma referência a uma norma em uma página de serviço não é suficiente para estabelecer que cada componente de cada produto é coberto.

A mesma prudência vale para os níveis do tipo Tier 2/3. Essas expressões podem descrever um projeto, uma ambição, um nível reivindicado ou uma classificação aplicada a um site específico. Sem documento independente e sem identificação do site, é impossível saber precisamente o que foi avaliado. O artigo deve, portanto, atribuí-las à Cloud.ir, e não apresentá-las como resultados verificados pelas vinte fontes.

Os dados também não descrevem a topologia de alimentação e resfriamento. Não fornecem nem o número de caminhos elétricos, nem a duração do backup, nem a separação dos grupos, nem a capacidade térmica disponível. Não documentam as entradas de fibra, a distância entre sites ou as dependências comuns. Todos esses elementos seriam necessários para converter uma reivindicação de data center em análise de resiliência.

A ausência desses documentos não refuta as afirmações. Indica apenas que o observador público não pode verificá-las com este corpus. Uma conclusão negativa absoluta seria tão injustificada quanto uma aceitação sem reservas. A formulação correta é que as páginas fazem essas declarações e que o corpus não as verifica de forma independente.

Essa atribuição explícita também protege o valor de futuras evidências. Se a Cloud.ir publicar posteriormente um certificado com escopo, site e data claros, o dossiê poderá ser enriquecido sem reescrever a observação atual. Se outra fonte confirmar uma implantação, ela poderá ser adicionada como corroboração. Hoje, a camada física continua sendo uma afirmação a ser verificada.

Para um cliente, a necessidade de precisão depende do produto. Um domínio gerenciado, uma máquina virtual crítica e uma cópia de backup não têm as mesmas exigências. Seria necessário saber em qual site cada componente reside, quais controles se aplicam e quais dependências são compartilhadas. A marca global de um data center não atende a essa granularidade.

Nenhum documento ainda vincula cada produto à sua rota e ao seu site

A principal lacuna do dossiê está entre as evidências de rede e as páginas de serviço. De um lado, as fontes fornecem uma lista de prefixos e um sistema autônomo. Do outro, fornecem nomes de produtos e promessas comerciais. Entre os dois falta uma matriz de atribuição.

Uma tal matriz indicaria, para o servidor em nuvem, as faixas utilizadas, o sistema autônomo de origem, o(s) site(s), o upstream principal e o mecanismo de backup. Faria o mesmo trabalho para o VPS, o armazenamento, o CDN e os demais serviços. Também precisaria se o plano de controle e o plano de dados compartilham as mesmas dependências.

Sem essa matriz, várias arquiteturas permanecem possíveis. Alguns produtos poderiam usar o AS60077 diretamente. Outros poderiam se basear no AS43754, em redes terceiras ou em recursos que não são visíveis no corpus. O CDN poderia ter uma distribuição diferente do servidor em nuvem. O armazenamento poderia ter um caminho interno distinto. As fontes não permitem escolher entre essas possibilidades.

Essa incerteza impede de usar um sucesso de roteamento como substituto para um teste de produto. O fato de193.151.156.0/24ser amplamente visível e RPKI válido não prova que uma determinada instância esteja disponível. Por outro lado, uma instância disponível não prova que esteja nesse prefixo. A avaliação deve partir do recurso efetivamente adquirido.

Um método de verificação poderia começar pelos endereços observados pelo cliente. Ele os confrontaria com os prefixos, sua origem e seu status RPKI. Em seguida, pediria ao operador que confirmasse o site e os caminhos aplicáveis. Por fim, compararia essas respostas com os compromissos contratuais e os testes de failover. Cada uma dessas etapas cobre uma camada diferente.

O controle também deve abranger as funções de gerenciamento. Um portal, uma API, um sistema de backup e o tráfego de uma máquina podem depender de redes diferentes. Uma falha que poupa o plano de dados, mas atinge a autenticação, pode impedir uma intervenção. As páginas estudadas não fornecem essa decomposição; portanto, não permitem creditar uma independência que não é demonstrada.

Essa lacuna documental explica por que a tese não trata da existência da Cloud.ir. A oferta e a rede são bem visíveis. Ela trata da ligação entre ambas. Uma infraestrutura em nuvem se torna avaliada de ponta a ponta apenas quando as rotas, os sites, a capacidade e os procedimentos de recuperação podem ser vinculados aos serviços efetivamente utilizados.

O SLA traça uma fronteira de responsabilidade, mais do que um plano de recuperação

O SLA da Cloud.ir é uma peça essencial porque mostra o que o operador escolhe cobrir e excluir. O texto limita as garantias de disponibilidade à rede e ao servidor em nuvem no âmbito das operações ordinárias. Esse escopo é mais estreito do que a ideia geral de disponibilidade de toda a experiência do cliente.

O documento exclui, em particular, os softwares e sistemas operacionais do cliente, erros de configuração e falhas de equipamentos pertencentes ao cliente. Essa repartição é clássica em um modelo de infraestrutura: o provedor protege certas camadas, enquanto o cliente permanece responsável pelo que instala e administra. Isso significa, no entanto, que uma interrupção visível pelo usuário pode estar fora da garantia se sua causa for atribuída à camada do cliente.

Os ataques de negação de serviço também estão entre as exclusões. Essa menção é importante para um serviço exposto à Internet. Ela não diz que não existe proteção; indica que a garantia descrita não deve ser lida como uma cobertura universal desse cenário. As fontes não detalham nem um serviço de mitigação nem as condições nas quais um ataque seria coberto.

A manutenção e as correções críticas também são excluídas. Uma janela planejada e uma intervenção urgente podem, portanto, produzir indisponibilidade sem se enquadrar na mesma contabilização de uma falha comum. Para avaliar a disponibilidade experimentada, um cliente deve conhecer não apenas a porcentagem anunciada, mas também as categorias retiradas do cálculo, a frequência das intervenções e o aviso prévio.

O SLA menciona ainda força maior, suspensões, paradas solicitadas pelo cliente, falta de pagamento e certas injunções legais ou de segurança. Essas exclusões mostram que o acesso ao serviço depende de fatores técnicos, contratuais e regulatórios. Uma arquitetura pode funcionar corretamente e ainda assim se tornar indisponível por uma causa externa ao hardware.

Essa lista não deve ser apresentada como anormal em si. Um SLA serve precisamente para definir uma fronteira. Seu valor analítico reside no fato de que impede de transformar uma promessa de disponibilidade em garantia absoluta. Dois incidentes idênticos do ponto de vista do usuário podem ser classificados de forma diferente de acordo com sua causa e a parte responsável.

O documento consultado não fornece as sequências de failover para cada serviço. Não dá objetivo de tempo de recuperação, objetivo de ponto de recuperação, resultado de exercício ou histórico de incidentes. Não especifica qual capacidade permanece disponível quando um componente importante é perdido. A fronteira contratual é visível; o mecanismo técnico de recuperação permanece opaco.

Essa distinção é especialmente importante para os dados. Uma garantia de disponibilidade do servidor ou da rede não responde automaticamente à questão da persistência, replicação ou restauração. O corpus não permite estabelecer onde estão as cópias, se compartilham um site ou como são testadas. Portanto, seria incorreto deduzir a recuperação dos dados a partir de uma garantia de acesso.

O SLA também não estabelece que todos os produtos do catálogo tenham a mesma cobertura. Sua linguagem aborda a rede e o servidor em nuvem em condições definidas. Um cliente de VPS, armazenamento ou CDN deve verificar os compromissos aplicáveis ao seu serviço específico. O catálogo comercial e o escopo contratual não devem ser presumidos idênticos.

Para comparar ofertas, um comprador deveria solicitar três conjuntos de informações. O primeiro é a fórmula de cálculo da disponibilidade, com as exclusões. O segundo é a arquitetura de recuperação, com as dependências. O terceiro é a prova de funcionamento, na forma de testes e incidentes documentados. O SLA estudado fornece uma parte do primeiro conjunto, mas não os outros dois.

A visibilidade do controle não prediz o comportamento durante uma falha

O AS60077 pode continuar anunciando seus 18 prefixos enquanto um serviço específico enfrenta um problema interno. Por outro lado, uma rota pode mudar enquanto o serviço permanece acessível por outro caminho. O BGP e a disponibilidade da aplicação evoluem em camadas diferentes. Sua relação deve ser observada, não presumida.

Uma falha de servidor, armazenamento ou software não retira necessariamente a rota. Os coletores continuariam a ver a origem, mesmo que o cliente não possa mais utilizar seu recurso. Uma falha de upstream poderia, ao contrário, modificar a visibilidade enquanto deixa os sistemas internos operacionais. As fontes não contêm uma cronologia de incidentes que permita comparar esses sinais.

A mesma ressalva vale para o failover. Um segundo equipamento ou um segundo site pode existir sem assumir a carga corretamente. A prova útil não é apenas sua existência, mas o resultado de um exercício ou evento real. É necessário conhecer o tempo de detecção, o tempo de decisão, o tempo de convergência e o estado dos dados após a recuperação.

O único vizinho público observado, o AS43754, concentra a atenção no caminho upstream, mas não permite modelar todo o comportamento. Uma redundância oculta poderia intervir. Uma dependência comum também poderia limitar o failover. Sem topologia e sem teste, ambas as hipóteses permanecem em aberto. A análise deve registrar essa incerteza, em vez de escolher o cenário mais favorável ou o mais alarmante.

A própria visibilidade RIS é um indicador externo. Mostra que muitos pontos de observação recebem o anúncio. Não mede a latência, as perdas, a saturação ou o sucesso de uma conexão com uma aplicação. Uma rede pode estar visível e degradada. Uma medida de controle deve ser complementada por medidas de dados e de serviço.

Essa distinção permite evitar uma confusão frequente na economia da nuvem. Os recursos que tornam uma oferta vendável não se reduzem ao endereçamento e ao roteamento. Eles incluem computação, armazenamento, energia, refrigeração, operações, suporte e a capacidade de substituir um componente. O corpus mostra uma parte do primeiro plano, mas não o conjunto.

A conclusão não deve ser, portanto, que os dados de roteamento são secundários. Eles são indispensáveis para atribuir e monitorar a rede. Sua utilidade aumenta quando seu limite é reconhecido. Eles detectam certas rupturas e tornam certas afirmações verificáveis; não substituem um plano de continuidade.

O que um comprador pode verificar a partir das evidências disponíveis

O primeiro passo consiste em identificar o produto realmente envolvido. Uma organização que compra um servidor em nuvem não tem exatamente as mesmas dependências que uma organização que utiliza o CDN ou o armazenamento. É necessário obter os endereços, os nomes de serviço, os pontos de administração e os compromissos contratuais próprios desse recurso.

Os endereços observados podem então ser comparados aos 18 prefixos do AS60077. Se estiverem presentes, o comprador dispõe de um vínculo concreto entre seu serviço e a pegada analisada. Se não estiverem, ele não deve concluir automaticamente por uma anomalia: o serviço pode utilizar outra origem. Ele deve perguntar qual entidade e qual sistema autônomo garantem então a entrega.

Para os endereços que pertencem ao AS60077, a origem BGP e o status RPKI podem ser monitorados. O exemplo193.151.156.0/24mostra como cruzar RIPEstat, RIPE RDAP e os ROAs. O mesmo trabalho deve ser realizado sobre o prefixo exato do cliente. O objetivo é verificar a atribuição e as mudanças, não deduzir a disponibilidade completa.

A questão seguinte diz respeito aos sites. Qual edifício abriga o serviço principal? Onde está a cópia de backup? Os dois locais compartilham alimentação, refrigeração, uma entrada de fibra ou uma operadora? O PeeringDB não fornece essas respostas para o AS60077. Elas devem, portanto, vir de uma documentação precisa ou de uma evidência independente adequada.

O upstream deve ser tratado com a mesma granularidade. O AS43754 é o vizinho visível, mas o comprador deve saber se existe outro caminho para seu serviço, se está ativo, se dispõe de capacidade suficiente e se segue uma rota fisicamente distinta. Uma política Whois ou um número de AS adicional não constitui prova de failover.

A capacidade deve ser expressa nas unidades do produto. Para computação, isso pode incluir recursos garantidos, limites de superalocação e reservas. Para a rede, inclui as taxas de transferência, os pontos de contenção e a capacidade mantida durante uma falha. Para o armazenamento, inclui replicação, integridade e restauração. Os 14.080 endereços IPv4 não respondem a nenhuma dessas perguntas.

A recuperação deve ser verificada por objetivos e resultados. Qual prazo se aplica a um incidente coberto? Qual perda máxima de dados está prevista? Quando um failover foi testado? Quais exclusões do SLA se aplicam? O corpus mostra as exclusões, mas não os resultados de teste. Uma resposta comercial deve estar vinculada ao contrato e a um serviço específico.

O IPv6 requer uma verificação separada. O sinal pontual de2a05:1a30::/34não demonstra uma oferta atual; a ausência corrente de origem pelo AS60077 não demonstra a ausência de qualquer produto IPv6. Um cliente deve solicitar endereços e testar a conectividade no recurso que pretende utilizar.

Por fim, o cliente deve manter um caminho de saída. A capacidade de exportar dados, mover o DNS, recuperar configurações e revogar acessos reduz a dependência de uma recuperação perfeita do provedor. As fontes não descrevem os mecanismos da Cloud.ir nesses pontos. Elas mostram por que essas perguntas devem ser feitas antes de um incidente.

Essa abordagem transforma a incerteza pública em programa de due diligence. Não presume que as respostas serão negativas. Apenas distingue os elementos já observáveis dos que necessitam de confirmação direta. A rede pública fornece pontos de referência; o contrato, a arquitetura e os testes devem completar a cadeia.

O que as vinte fontes não permitem afirmar

O dossiê não permite afirmar o caminho exato até um data center. Nenhum prefixo está associado a um endereço de site, sala, rack ou entrada de fibra. As páginas da Cloud.ir falam de data centers da Asiatech no Irã, mas não fornecem o mapeamento necessário para vincular cada serviço a um local.

Não permite afirmar a propriedade das instalações ou dos equipamentos. Uma organização pode operar, alugar, revender ou compartilhar recursos. Os registros de rede não arbitram esses modelos. Os termos comerciais também não são suficientes para estabelecer o título de propriedade.

Não permite provar uma redundância upstream independente. AS43754 é o único vizinho observado; AS212895 continua sendo uma declaração Whois não vista no BGP. Caminhos não públicos podem existir, mas não são demonstrados. A independência física e operacional é ainda menos documentada.

Não permite calcular a capacidade disponível para os clientes. O número de endereços não mede nem processadores, nem memória, nem armazenamento, nem energia, nem largura de banda restante. As páginas de serviço não fornecem, no corpus, um inventário verificado que supriria essa falta.

Não permite afirmar que nenhum serviço IPv6 existe. Apenas estabelece a ausência de uma origem IPv6 pelo AS60077 atualmente visível na fotografia e a existência de um sinal pontual em 13 de julho de 2026. As demais arquiteturas não são testadas.

Não permite apresentar ISO27001, TIA-942 ou os níveis do tipo Tier 2/3 como independentemente certificados para toda a oferta. Essas referências vêm das páginas do operador e seu escopo não é documentado por um documento externo no corpus.

Não permite deduzir o comportamento de recuperação. O SLA descreve fronteiras e exclusões, mas não uma sequência verificada de restauração. Nenhuma medida de exercício, nenhum histórico detalhado e nenhum objetivo por produto são incluídos.

Por fim, não permite atribuir todos os serviços da Cloud.ir ao AS60077. A relação entre a marca, a Asre Dadeha Asiatech e a rede é sustentada em vários níveis, mas a matriz por produto está ausente. Esse limite deve acompanhar todo uso da pegada.

Essas proibições de conclusão não constituem uma lista de suspeitas. São a consequência normal de uma investigação baseada em fontes públicas limitadas. Elas impedem que uma ausência de evidência se torne uma acusação, assim como impedem que uma declaração se torne uma certeza.

Os sinais que permitiriam reduzir a incerteza

Uma primeira melhoria seria um mapeamento público ou contratual vinculando os produtos aos prefixos e sistemas autônomos. Ele permitiria saber quais conclusões sobre o AS60077 se aplicam efetivamente ao servidor em nuvem, ao VPS, ao armazenamento ou ao CDN. Também tornaria visíveis as diferentes dependências entre produtos.

Uma segunda melhoria seria uma divulgação precisa dos sites e das interconexões. Uma ficha do PeeringDB mais completa poderia fornecer pistas, mas deveria ser corroborada. Uma confirmação de presença, uma arquitetura de caminhos e uma descrição dos domínios de falha trariam uma evidência mais forte do que o simples nome de um data center.

Uma terceira melhoria diria respeito ao upstream. A observação estável de um segundo vizinho independente, acompanhada de uma descrição da diversidade física e de testes de failover, modificaria a avaliação. Uma política Whois sozinha não seria suficiente. Seria necessário mostrar que o caminho está ativo, dimensionado e realmente utilizável quando o AS43754 não está disponível.

Para IPv6, um anúncio estável de2a05:1a30::/34ou de outro prefixo, visível no status atual e vinculado a produtos, constituiria um sinal mais forte. Endereços atribuídos e testes complementariam a observação. A entrada única de 13 de julho se tornaria então um episódio em uma trajetória documentada, em vez de um sinal isolado.

As afirmações sobre data centers ganhariam valor com certificados cujo escopo, entidade, site e validade são claramente identificados. Elementos sobre alimentação, refrigeração, fibras e capacidades de backup permitiriam passar de um rótulo para uma arquitetura analisável.

Por fim, objetivos de recuperação, resultados de testes e históricos de incidentes reduziriam a lacuna entre o SLA e o comportamento real. Uma garantia é mais informativa quando associada à forma como o serviço retorna, à capacidade disponível durante a degradação e à qualidade dos dados após a restauração.

Cada um desses sinais deve permanecer em sua camada. Uma nova rota não estabelece uma certificação de site. Um certificado não estabelece uma diversidade upstream. Um teste de failover não prova a capacidade comercial permanente. A força do dossiê viria de sua combinação, não da transformação de um único indicador em resposta total.

Uma pegada verificável, uma cadeia de entrega ainda incompleta

O caso da CLOUD Asre Dadeha Asiatech mostra por que os dados de roteamento são ao mesmo tempo poderosos e insuficientes. Eles identificam o AS60077, confirmam sua atividade IPv4, detalham 18 anúncios, medem uma visibilidade junto a 324 dos 325 peers RIS IPv4 e fornecem um exemplo RPKI válido. Também vinculam a origem a objetos do RIPE RDAP e a contatos da Asiatech.

Esses resultados estabelecem uma verdadeira superfície de controle pública. Permitem monitorar a rede, verificar uma atribuição e distinguir uma rota observada de uma simples declaração. Constituem uma base mais sólida do que um catálogo comercial tomado isoladamente.

Os mesmos dados evidenciam os limites da visão. Nenhum prefixo IPv6 corrente era visível como originado pelo AS60077, apesar de um sinal pontual. O AS43754 era o único vizinho observado. O PeeringDB não divulgava nem site nem ponto de troca. O caminho físico, a capacidade utilizável e a diversidade independente não podiam, portanto, ser reconstruídos.

A Cloud.ir adiciona uma superfície de cliente ativa, um catálogo de mais de vinte produtos reivindicados e páginas recentemente mantidas. Seu SLA esclarece várias exclusões. Mas o corpus não vincula cada produto a uma rota, um site, uma capacidade e um mecanismo de recuperação. Não verifica independentemente as referências a data centers.

A conclusão mais robusta é, portanto, assimétrica. Existem evidências suficientes para dizer que a rede IPv4 do AS60077 está ativa e amplamente visível, e que a Cloud.ir apresenta uma oferta comercial atual. Não existem evidências suficientes para dizer como cada serviço atravessa as instalações, qual redundância independente o protege, qual capacidade permanece mobilizável ou como ele se recupera após uma falha.

Essa assimetria não é um veredito de fraqueza nem uma aprovação de resiliência. É uma fronteira de conhecimento. Para transpô-la, um comprador deve vincular seu serviço concreto aos prefixos, aos sites, aos caminhos, ao contrato e aos testes. Enquanto essa cadeia não for fornecida, o AS60077 torna a Cloud.ir visível na Internet sem tornar transparente toda a infraestrutura que entrega seus serviços.

AS60077 torna o Cloud.ir visível na Internet, sem revelar o caminho físico de seus serviços