Resumo

  • A CLOUD COLIBRI S.A tem uma identidade pública específica em registros de internet. A LACNIC registra a empresa em La Ceiba, Honduras, como a titular ativa do AS269866 e de2803:6760::/32, com Julian Palacios nomeado como representante legal e contato administrativo, técnico e de abuso.
  • A rede não está meramente reservada. O RIPEstat observou o IPv6/32originado pelo AS269866 durante todo o período de 1 a 15 de julho de 2026, visível para todos os 322 pares IPv6 reportantes no ponto capturado. Sua origem exata também retornouválidosob RPKI, com uma autorização limitada ao/32.
  • A prova do serviço é muito mais enxuta. O provedor anuncia servidores virtuais KVM e Xen, redimensionamento automatizado, hospedagem gerenciada, backup diário, suporte 24 horas e 100% de uptime, mas suas páginas mantêm um rodapé de 2019, não fornecem nenhum resultado nomeado de cliente ou histórico de status de serviço e roteiam o site público sobre um agregado IPv4 de um operador diferente.
  • Localização e responsabilidade precisam de respostas em nível de contrato. Um endereço de registro hondurenho não localiza os dados do cliente; o registro também publica um contato técnico em Nova York, medições de terceiros colocam endpoints IPv6 visíveis em Nova York, e o contato de cobrança público retornou um erro de servidor durante a revisão. Os compradores precisam de um mapa de dados cópia por cópia, um diagrama de rede atual, evidências de recuperação e obrigações de suporte específicas por gravidade.

Um verdadeiro detentor de recursos está por trás do nome

Compradores de nuvem frequentemente encontram um nome de empresa antes de encontrar evidências de que a empresa controla alguma infraestrutura. A CLOUD COLIBRI S.A supera esse primeiro obstáculo. Oregistro LACNIC para AS269866identifica uma alocação direta ativa para CLOUD COLIBRI S.A, com um endereço no Boulevard 15 de Septiembre ao lado do INFOP em La Ceiba, Honduras. O sistema autônomo foi registrado em 5 de dezembro de 2019. O registro nomeia Julian Palacios como representante legal e atribui ao mesmo contato as funções administrativa, técnica e de abuso através de um endereço de e-mail emcloudcolibrisa.com.

Oregistro LACNIC para2803:6760::/32torna a identidade mais concreta. Ele marca a alocação IPv6 como ativa, data seu registro em 24 de outubro de 2019 e nomeia a mesma empresa, endereço e representante. A alocação e o sistema autônomo, portanto, unem-se por mais do que um rótulo semelhante: eles compartilham o identificador da organização no registro, a cadeia de contato público e o representante legal.

Essa é uma atribuição útil, mas seu escopo importa. Um registro de internet é autoritativo para o registro de recursos; não é um registro corporativo, declaração de propriedade auditada ou certificado de instalação. O registro público não expõe detalhes de incorporação, acionistas, autoridade de assinatura, contas ou a relação entre a CLOUD COLIBRI S.A e cada ativo usado para prestar serviço. Um cliente ainda deve obter um extrato atual da empresa hondurenha, verificar quem pode vincular a empresa e garantir que o nome contratante corresponda ao detentor do recurso que espera operar a rede.

A distinção é prática, não cerimonial. Se um incidente envolver reputação de endereço, controle de rota ou tratamento de abuso, o AS269866 fornece ao comprador um operador de rede identificável e um contato de escalação publicado. Se a disputa envolver, em vez disso, um backup falho, um hypervisor indisponível ou um reembolso não pago, o registro não pode estabelecer qual empresa possuía o servidor, empregava o engenheiro ou aceitou a obrigação de serviço. Um único registro de identidade pode apoiar uma cadeia de responsabilidade sem completá-la.

O catálogo expõe um modelo operacional, mas não seus resultados

Apágina inicial da Cloud Colibridescreve máquinas virtuais abstraídas do hardware físico. Diz que cada servidor recebe CPU garantida de acordo com o tamanho, pode usar capacidade do host sobressalente quando disponível e pode ser redimensionado através de um clique ou chamada de API. O processo de redimensionamento declarado brevemente coloca o servidor offline, altera sua alocação de RAM, disco e CPU, e o reinicia automaticamente. Essa é uma superfície de controle concreta: os clientes podem inferir que o provedor vende máquinas virtuais mutáveis em vez de apenas contas de hospedagem compartilhada estáticas.

Apágina de serviçosdá à oferta uma forma reconhecível. Ela lista seis planos KVM e Xen com um ou dois núcleos de CPU, 10 GB a 50 GB de disco, 1 GB a 4 GB de memória garantida, Linux ou Windows, acesso root SSH ou RDP, hospedagem gerenciada, backups diários com uma restauração gratuita por mês, tolerância a falhas e transferência de dados ilimitada. Os preços mensais exibidos variam de $11 a $33. A página também diz que as cargas de trabalho são distribuídas em um cluster, com servidores designados a tarefas individuais para que uma conta não dependa de uma única máquina.

Esses detalhes são melhores do que um rótulo de nuvem vazio. Eles revelam escolhas de virtualização, privilégios do cliente, um mecanismo de redimensionamento e pelo menos um direito de backup. Eles também deixam o limite de responsabilidade excepcionalmente aberto. O acesso root sugere que o cliente pode administrar o sistema operacional; a hospedagem 'gerenciada' sugere que o provedor pode fazê-lo. As páginas não dizem quem corrige o convidado, gerencia chaves privilegiadas, monitora a saúde do aplicativo, aprova uma reinicialização de emergência ou possui a configuração após o término.

A promessa de backup tem ambiguidade semelhante. 'Diário' não identifica o horário de captura, período de retenção, local de armazenamento, autoridade de criptografia, imutabilidade ou objetivo de ponto de recuperação. Uma restauração gratuita por mês é uma permissão comercial, não um compromisso de tempo de recuperação. Um comprador precisa saber se restaurações adicionais são meramente cobráveis ou operacionalmente limitadas, se uma restauração pode ser solicitada 24 horas por dia, como a identidade é verificada antes de sobrescrever dados e quando o provedor recuperou com sucesso um servidor comparável pela última vez.

O site também faz alegações substanciais sobre a instalação. Ele lista energia ininterrupta, fornecimento de múltiplas redes, um gerador Caterpillar de alta capacidade, disjuntores dedicados, controles biométricos, sensores de movimento, patrulhas de guardas, alarmes, notificação policial e acesso contínuo para administradores de sistema e equipe de monitoramento no local. Nenhuma dessas declarações é acompanhada por um nome de instalação, endereço, figura de capacidade, registro de manutenção, auditoria, fotografia vinculada ao site ou resultado de teste. Elas definem perguntas de diligência; não as respondem.

A idade e condição da superfície de vendas também importam. Ambas as páginas públicas estavam ativas durante a revisão, mas cada uma mantinha um rodapé de direitos autorais de 2019. Oendpoint de contato do clientevinculado retornou um erro de servidor HTTP 500 na captura. Um rodapé desatualizado não prova infraestrutura desatualizada, e uma falha de aplicativo transitória não prova que o suporte está indisponível. Juntos, no entanto, eles tornam inseguro tratar planos, preços ou caminhos de pedido publicados como atuais sem confirmação de uma pessoa responsável.

AS269866 é pequeno, visível e autorizado criptograficamente

A evidência mais forte no presente é a própria rota. Aobservação de prefixo anunciado do RIPEstatmostrou2803:6760::/32originado pelo AS269866 durante toda a janela de observação de 1 a 15 de julho de 2026. Oregistro de status de roteamentodatou a primeira origem observada em 6 de janeiro de 2022 e a mais recente em 15 de julho de 2026. No ponto capturado, 322 de 322 pares IPv6 reportantes viram a rota.

Essa visibilidade estabelece uma presença no plano de controle durável e globalmente propagada. Ela não estabelece quantos clientes usam o prefixo, quanto tráfego ele carrega ou se os aplicativos respondem de forma confiável. Um/32é uma grande alocação IPv6 em termos de endereços, mas a contagem de endereços é especialmente enganosa em IPv6: nunca deve ser convertida em contagem de servidores, utilização ou escala comercial.

A rota também tem um sinal de segurança positivo. Avalidação RPKI do RIPEstatretornouválido, apoiada por uma autorização de origem de rota nomeando AS269866 para o/32exato com um comprimento máximo de 32. Redes que aplicam validação de origem de rota podem, portanto, verificar que este agregado está autorizado a originar do ASN da empresa.

A configuração de comprimento máximo é conservadora: autoriza o agregado, não rotas mais específicas arbitrárias. Isso pode reduzir a exposição acidental, embora também signifique que um anúncio de emergência ou engenharia de tráfego mais longo que/32precisaria de uma autorização alterada para validar. O RPKI não protege um hypervisor, criptografa dados, mede latência ou evita todo vazamento de rota. Ele responde a uma pergunta estreita e valiosa: se a origem observada é criptograficamente consistente com a intenção publicada do detentor do recurso.

A rede tem uma dependência visível estreita. Aobservação de vizinhos do RIPEstatencontrou uma rede adjacente em 15 de julho, AS265680. O IPinfo identifica essa rede como HNTELCO S.A e classifica AS269866 como um sistema autônomo single-homed. Coletores públicos não veem toda interconexão privada ou backup inativo, então isso não é prova de que existe apenas um circuito físico. Mostra que o conjunto de fontes não contém um segundo caminho visível independentemente.

Para uma carga de trabalho em nuvem, as próximas perguntas são diretas. A AS269866 tem um segundo provedor de trânsito e, em caso afirmativo, esse caminho é normalmente visível ou ativado apenas durante uma falha? Os circuitos entram no edifício através de dutos independentes? A autorização RPKI válida é atualizada como parte do failover? A empresa testou perder a AS265680 sem perder acesso de gerenciamento, DNS ou rotas do cliente? Um upstream visível é evidência de serviço; uma alternativa independente e testada é evidência de resiliência.

O site público usa um caminho operacional IPv4 diferente

A própria pegada de recursos visível da AS269866 é apenas IPv6. Operfil AS269866 do IPinfonão relata prefixos IPv4 para o ASN e um upstream IPv6, AS265680. Enquanto isso,cloudcolibrisa.come seu subdomínio de cobrança resolveram durante a revisão para45.186.152.254, um endereço IPv4 fora da AS269866.

O rastro do registro não torna esse endereço não relacionado. Oregistro LACNIC para o bloco45.186.152.0/23diz que a faixa foi realocada para Julian Palacios e publica o mesmo endereço em Nova York, número de telefone e contato NOCcloudcolibrisa.comque aparecem na cadeia de contato da AS269866. Mas avisualização de rota do RIPEstatvê o endereço apenas através do menos específico45.186.152.0/22, originado pela AS266842.LACNIC identifica AS266842como HNHOSTING.NET S.A., outra organização registrada em La Ceiba com um representante legal diferente.

A conclusão mais justa é limitada. Há uma relação de contato observável entre o endereço do site público da Cloud Colibri e seu representante nomeado, enquanto a rota é operada sob o ASN da HNHOSTING.NET. As fontes não estabelecem propriedade comum, acordo de revenda, contrato de hospedagem ou divisão de responsabilidade operacional entre as duas empresas.

Essa separação é importante porque o site não pode servir como demonstração de que a AS269866 entrega os servidores virtuais anunciados pela Cloud Colibri. Isso prova que uma página de serviço com a marca da empresa é acessível através de um recurso IPv4 associado ao seu representante. A rota IPv6 ativa prova separadamente que a empresa controla uma presença ativa de sistema autônomo. Um comprador deve perguntar qual ASN e prefixos seu próprio servidor realmente usará, quem lida com um incidente de abuso ou rota IPv4 e se o portal de gerenciamento depende de uma rede fora do limite de resiliência anunciado do serviço.

A divisão pode ser perfeitamente comum. Provedores pequenos frequentemente combinam endereços próprios, espaço realocado, trânsito upstream e sistemas de controle hospedados. A garantia vem de documentar essa combinação: detentor do recurso, origem da rota, upstream, operador de DNS, host do portal, provedor de mitigação e proprietário da escalação. Sem esse mapa, um cliente não pode saber se uma falha em uma empresa afeta apenas o site de marketing ou também o caminho para seu servidor de produção.

Honduras é uma âncora de identidade, não uma resposta de localização de dados

O registro de recursos da Cloud Colibri é hondurenho. Tanto a empresa quanto a AS269866 estão associadas a La Ceiba na LACNIC, e a empresa também apareceu entre as organizações hondurenhas noregistro eleitoral de 2024 da LACNIC. Esses fatos apoiam uma identidade institucional hondurenha. Eles não localizam um rack, disco, backup ou sessão de suporte.

O registro público aponta para várias jurisdições. A LACNIC dá à organização um endereço em La Ceiba, mas dá ao seu contato técnico, administrativo e de abuso nomeado um endereço na 25 Broadway em Nova York. O IPinfo diz que a rede está registrada em Honduras, enquanto os endpoints IPv6 que pôde medir estavam nos Estados Unidos; suas amostras pingáveis recentes foram observadas em Nova York. O espaço IPv4 que serve o site oficial também é realocado para o representante nomeado no endereço de Nova York.

A geolocalização IP é uma inferência, não uma escritura de instalação. Endereços podem ser registrados em um país, anunciados em outro, tunelados, anycast ou rotulados incorretamente por um banco de dados. Uma observação de sonda de um milissegundo de Nova York é consistente com infraestrutura próxima, mas não identifica o edifício ou quem possui o hardware. A conclusão correta não é que o serviço da Cloud Colibri está definitivamente em Nova York. É que o registro público não justifica a suposição de que os dados do cliente permanecem em Honduras.

Um cliente com requisitos de residência, soberania ou latência precisa de um mapa de dados para o plano adquirido. Ele deve localizar discos primários, réplicas, backups diários, painéis de controle, registros de autenticação, dados de monitoramento, anexos de tickets e logs do provedor. Deve identificar subprocessadores e administradores remotos, distinguir dados em repouso de dados acessados durante o suporte e explicar o que se move durante o failover. O contrato também deve dizer se um cliente pode escolher uma localização e quais evidências comprovam a exclusão após a saída.

A linguagem da instalação no site torna essa solicitação mais importante. Alegações sobre múltiplas redes elétricas, geradores, controles biométricos e pessoal no local implicam um local físico, mas a página não o nomeia. O endereço de registro em La Ceiba pode ser um escritório, contato de rede ou instalação; o conjunto de fontes não pode decidir qual. Os compradores devem solicitar o endereço do serviço sob confidencialidade, se necessário, e então reconciliá-lo com a latência da rede, o local do backup e o cronograma legal.

Suporte 24 horas precisa de uma rota funcional e um relógio definido

O provedor promete suporte ao cliente 24 horas por dia, 7 dias por semana, acesso para administradores de sistema e equipe de monitoramento no local. A LACNIC adiciona um e-mail NOC público e contato telefônico para questões de roteamento e abuso. Isso é mais responsável do que uma marca anônima sem pessoa nomeada ou contato de rede.

Ainda não é evidência de desempenho de suporte. O site não publica níveis de gravidade, tempos de resposta, metas de restauração, etapas de escalação ou créditos de serviço. '24x7' pode descrever quando uma fila aceita mensagens, quando um agente de primeira linha responde ou quando um engenheiro com autoridade de hypervisor e rede está disponível. Esses são compromissos materialmente diferentes durante uma interrupção.

A página de contato do cliente com falha aguça a questão. Um formulário web quebrado pode ser temporário, e clientes existentes podem ter um portal, e-mail ou canal telefônico separado. Mas a rota pública oferecida para contato não estava utilizável no ponto de revisão. Antes da compra, um cliente deve testar cada canal, registrar o número do incidente, verificar a escalação após o expediente e descobrir quem pode autorizar alterações na rede, restaurar dados e aprovar uma solução de serviço.

O suporte local também precisa de um modelo de mão de obra. A empresa diz que o pessoal monitora no local continuamente, mas o conjunto de fontes não estabelece número de funcionários, profundidade de turno, cobertura de idioma, local de emprego ou dependência de um contato nomeado. Um cronograma confiável deve identificar a cobertura de papéis em vez de expor detalhes privados da equipe: operações de rede, virtualização, armazenamento, segurança, faturamento e um comandante de incidente. Deve definir regras de handover e garantir que um evento grave não espere uma pessoa acordar ou viajar.

Evidências medidas podem substituir uma grande quantidade de linguagem de vendas. Os compradores devem solicitar distribuições de resposta e restauração por gravidade, avisos de manutenção recentes, um relatório de incidente redigido e uma restauração testemunhada. Devem ligar para a rota de escalação durante a integração e incluir falha do portal em um exercício de mesa. O suporte se torna um controle operacional quando seu relógio, autoridade e canais de fallback sobrevivem à mesma falha que gerou o ticket.

O que os compradores devem exigir antes do uso em produção

A Cloud Colibri tem mais substância do que apenas um nome. Sua identidade de registro é específica, sua alocação IPv6 está ativa, sua rota está visível há anos e seu estado RPKI é válido. O site descreve uma oferta plausível de pequeno provedor com máquinas virtuais, acesso root, escalonamento automatizado, backup e controles físicos. Esses fatos justificam diligência adicional.

Eles não validam as promessas mais fortes do provedor. A página de serviços diz que os clientes podem desfrutar de 100% de uptime, mas não publica janela de medição, exclusões, tratamento de manutenção, mapa de dependência ou remédio. 'Tolerância a falhas' é um rótulo de recurso sem um design de domínio de falha. A transferência 'ilimitada' não tem definição de uso justo ou capacidade de porta. Um backup diário sem retenção e resultados de restauração não pode ser precificado como garantia de recuperação.

Um pedido de produção deve, portanto, anexar evidências a cada alegação. O cronograma legal deve nomear a empresa contratante e sua autoridade de assinatura. O cronograma de rede deve listar prefixos do cliente, origens de rota, provedor IPv4, upstreams, responsabilidade RPKI e failover testado. O cronograma de infraestrutura deve nomear a instalação, caminhos de energia, propriedade de hardware e limites de manutenção. O cronograma de dados deve localizar cada cópia e administrador. O cronograma de suporte deve definir gravidades, relógios, escalação e créditos de serviço.

O cronograma de saída deve garantir a exportação de imagem de máquina e dados em um formato utilizável.

Os clientes também devem buscar provas que vão além das próprias páginas do provedor: uma referência para uma carga de trabalho comparável, uma fatura ou registro de serviço vinculando a instalação e rede propostas à entidade contratante, dados de uptime de um monitor independente e uma restauração observada de acordo com o plano solicitado. A ausência de um cliente nomeado no registro público disponível não é prova de que os clientes não existem. Isso significa que os compradores em potencial não devem tomar emprestada confiança de depoimentos que não viram.

O julgamento central é equilibrado. A CLOUD COLIBRI S.A é um detentor de recursos de rede atribuível com uma presença IPv6 pequena, mas genuína e bem autorizada. Seu caso de serviço público é mais antigo, mais amplo e menos testável do que essa evidência de rede. O nome pode identificar quem deve responder à primeira pergunta. A garantia operacional começa apenas quando a empresa pode responder às próximas com um contrato atual, um mapa de localização, suporte funcional e recuperação medida.