Resumo

  • A Hosting-27 Hosting-27 LTD não é uma empresa visível apenas nos registros de roteamento. A página inicial ao vivoHosting27.compromove serviços de hospedagem e nuvem búlgaros, apágina de contatofornece um endereço em Sófia, telefone e e-mails de suporte, aárea do clienteexibe um portal de login e faturamento, e apágina de tickets de suportedescreve um serviço de suporte que funciona todos os dias. Essa superfície de vendas pública é real, mas não prova por si só onde os servidores estão localizados nem como as falhas são reparadas.
  • A identidade de rede é concreta e compacta. O banco de dados RIPEobjeto AS42347nomeia Hosting-27, vincula o AS aORG-HA629-RIPE, lista Hosting-27 LTD como organização, fornece o país BG, o número de registro 204354361 e um endereço em Sófia, e registra as importações e exportações com AS57344 e AS31083. Oinetnum 217.174.144.0 - 217.174.144.255e oobjeto route 217.174.144.0/24vinculam o bloco IPv4 visível à Hosting-27 e AS42347.
  • A visão de roteamento ao vivo é mais estreita do que o menu de marketing. Avisão geral do ASdo RIPEstat mostrou AS42347 anunciado em 12 de julho de 2026, e sua visãorouting-statusmostrou um prefixo IPv4 visível, 256 endereços IPv4, nenhum IPv6 visível e um vizinho observado. A visãoASN-neighboursdo RIPEstat identificou esse vizinho como AS57344, e avisão geral do AS57344do RIPEstat identifica AS57344 como Telehouse EAD. Um segundo peer, AS31083 Telepoint, aparece na política de registro do AS42347, mas não na visão de consistência BGP atual.
  • O nível operacional é médio qualificado, não forte. As páginas de produtos parahospedagem compartilhada,Cloud VPS,Cloud VPS gerenciado,nuvem privadaeKubernetesmostram uma ampla oferta de capacidade hospedada. As evidências públicas não mostram sala de data center nomeada, número de racks, projeto elétrico, estoque de hardware, condições de retenção de backups de clientes, trânsito ativo duplo, serviço IPv6 ou caminho de portabilidade por escrito.

A superfície de serviço é visível, mas deve ser lida do rack para fora

Hosting-27 Hosting-27 LTD não deve ser confundido com um registro de número da Internet vazio. O site público Hosting27.com está ao vivo, datado por seus próprios metadados de cabeçalho e páginas visíveis, e construído como uma vitrine de hospedagem operacional. Apágina inicialapresenta a marca como um provedor de serviços de hospedagem e nuvem. Ela orienta os compradores para hospedagem WordPress, clusters Kubernetes, nuvem privada, Cloud VPS, Cloud VPS gerenciado, hospedagem revenda, domínios, uma área do cliente, faturas e tickets de suporte. A navegação não é um espaço reservado de página única abandonado; é uma superfície de vendas de hospedagem com níveis de produtos, botões de pedido, uma conta no estilo WHMCS e um portal de suporte.

Isso torna a investigação mais exigente, não menos. Quando uma empresa vende hospedagem web ou servidores em nuvem, a dependência do cliente não é a página web. A dependência é a pilha escondida sob a fatura: um nó host, um back-end de armazenamento, switches, roteadores, um estoque de IPv4, trânsito upstream, energia, refrigeração, mãos remotas, status de faturamento, tratamento de abusos e uma equipe de suporte com autoridade para agir. O material público da Hosting27 descreve vários produtos destinados a clientes, mas não identifica a instalação ou instalações por trás deles.

Não diz se a Hosting-27 opera seus próprios racks, aluga espaço em rack, depende de outro operador de data center búlgaro ou revende capacidade montada por um provedor relacionado.

O menu de produtos é importante porque indica aos clientes que tipo de sistema físico deve existir. Apágina de hospedagem compartilhadaoferece três tamanhos de planos com 20 GB, 50 GB e 165 GB de espaço, cPanel, sites ilimitados, caixas de correio ilimitadas, certificados SSL gratuitos, CDN, ajuda com migração, várias versões do PHP e backups de um mês. Apágina de hospedagem WordPressoferece níveis semelhantes de 20 GB, 50 GB e 165 GB, adiciona gerenciamento WordPress e promete ajuda para mover sites WordPress. Apágina de hospedagem revendaoferece planos de 40 GB, 75 GB e 130 GB com acesso WHM, tráfego ilimitado e contas ilimitadas. Esses não são slogans abstratos de nuvem. São afirmações de que hosts físicos ou virtuais compartilhados existem, que contas podem ser criadas neles e que migrações e backups fazem parte da promessa de serviço.

O menu de nuvem aumenta os riscos. Apágina Cloud VPSoferece instâncias de um a quatro CPUs virtuais, 1 GB a 6 GB de RAM, 30 GB a 85 GB de armazenamento totalmente SSD, backups diários, painel de gerenciamento, OpenStack, KVM e Ceph. Ela também vende endereços IP adicionais, backups de sistema adicionais e blocos de administração de sistema de trinta minutos. Apágina Cloud VPS gerenciadooferece servidores gerenciados com painel de controle, suporte técnico, backups diários, monitoramento 24 horas e migração gratuita. Apágina de nuvem privadavai mais longe, descrevendo uma oferta de data center virtual baseado em OpenStack com armazenamento definido por software, uma alegação de nível de serviço de 99,99%, rede duplamente segura e serviços de API como Cinder, Nova, Heat, Glance, Magnum, Neutron e Keystone. Apágina Kubernetesdescreve ajuda com instalação, configuração e manutenção de um ambiente Kubernetes altamente disponível e indica que o serviço cobre infraestrutura, rede e balanceadores de carga como uma de suas camadas.

Essas páginas dão à Hosting27 uma superfície de vendas pública mais forte do que muitas redes de hospedagem pequenas. Elas também criam uma lacuna de evidência maior. Um vendedor de VPS de nó único pode falhar silenciosamente. Um vendedor de OpenStack, Ceph, nuvem privada e Kubernetes precisa responder a mais perguntas: quantos nós físicos estão disponíveis, como a replicação de armazenamento é isolada, se os componentes do plano de controle têm domínios de falha independentes, onde os backups estão localizados, qual pool de endereços atende os clientes, qual roteador carrega a rota e quem pode reparar o sistema quando a camada física falha.

Portanto, o ponto de partida mais seguro não é nem a rejeição nem a confiança cega. A Hosting-27 tem um site visível e um AS visível. O registro público apoia a existência de uma operação de hospedagem búlgara. Ele não apoia uma conclusão sólida sobre capacidade de nuvem instalada, recuperação multi-site ou independência de provedor.

O registro RIPE dá à Hosting-27 uma borda de rede pequena, mas real

A evidência de infraestrutura mais clara está no banco de dados RIPE e RIPEstat. Oregistro aut-num para AS42347nomeia o AS "Hosting-27", lista Hosting-27 LTD via ORG-HA629-RIPE, registra o status ASSIGNED, fornece a criação em 24 de agosto de 2017 e a última modificação em 7 de abril de 2021, e registra a política de importação e exportação para AS57344 e AS31083. Oregistro de organizaçãovinculado nomeia Hosting-27 LTD, país BG, número de registro 204354361, tipo de organização OTHER, um endereço em Sófia na Todor Aleksandrov 133, e um contato de abuso em GLAC2-RIPE. Foi criado em agosto de 2017 e modificado pela última vez em maio de 2026.

A alocação IPv4 é igualmente explícita. Oinetnum do RIPE para 217.174.144.0 - 217.174.144.255usa netname Hosting-27, país BG, organização ORG-HA629-RIPE e status ASSIGNED PA. Oobjeto route do RIPE para 217.174.144.0/24descreve Hosting27 e autoriza a origem AS42347. A visãoannounced-prefixesdo RIPEstat mostrou 217.174.144.0/24 visível na janela de duas semanas terminando em 12 de julho de 2026. Sua visãorouting-statusmostrou um prefixo IPv4, 256 endereços IPv4 e visibilidade IPv4 completa em 326 peers RIPE RIS de 326 no momento verificado.

Esse /24 não é apenas um registro passivo. O domínio Hosting27.com resolve no mesmo bloco. A visãoDNS-chain do RIPEstat para hosting27.comresolveu hosting27.com em 217.174.144.181, associou inversamente esse endereço a shared-11.cpaneler.com e listou servidores de nomes autoritativos incluindo ns1-pns.hosting27.com e ns2-pns.hosting27.com. Oregistro RDAP de domínio para hosting27.commostra o domínio registrado em 12 de julho de 2013, expirando em 12 de julho de 2027, com PublicDomainRegistry.com como registrador e servidores de nomes sob hosting27.com. O site visível, o DNS e o prefixo roteado estão alinhados em torno da mesma pegada de rede pública.

O pool de endereços é pequeno. Um /24 contém 256 endereços IPv4 antes de contar interfaces de roteador, hosts de infraestrutura, servidores de nomes, IPs de hospedagem compartilhada, alocações de clientes, endereços de reserva e capacidade reservada. É suficiente para um negócio de hospedagem real, especialmente se muitos clientes de hospedagem compartilhada estiverem por trás de hosts virtuais baseados em nome e se planos VPS pequenos puderem compartilhar hosts sem receber vários endereços públicos cada um. Não é suficiente para deduzir grande capacidade instalada.

Uma oferta de nuvem privada, uma oferta Kubernetes, contas de revenda, VPS gerenciado e hospedagem compartilhada podem ser vendidos a partir de um pool de endereços públicos compacto se endereçamento interno, NAT, hospedagem virtual e alocação cuidadosa forem usados. Eles também podem ser supervendidos se o planejamento for frouxo. A rota pública não distingue esses casos.

Existe também um segundo objeto route que deve ser tratado com cuidado. A visãoAS-routing-consistencydo RIPEstat lista 45.151.89.0/24 como presente no whois, mas não no BGP para AS42347 no momento da consulta. Umapesquisa RIPE para 45.151.89.0/24mostra um objeto route para AS42347, mas o inetnum pertence à Geytit OOD, não à Hosting-27 LTD, e a rota não fazia parte do conjunto anunciado visível atual. Isso significa que pode ser que uma política de rota tenha sido preparada para outro pool, ou que a rota estava inativa, reservada, histórica ou não visível no momento da consulta. Ela não deve ser contada como capacidade disponível da Hosting-27 para clientes a menos que evidências BGP e comerciais atuais a apoiem.

Portanto, a borda de rede é real, mas estreitamente delimitada: um AS visível, um /24 IPv4 visível, um objeto route válido, um site ao vivo no bloco e nenhum prefixo IPv6 visível para AS42347 na visão de rota do RIPEstat.

O escritório, o site e o nome contratual não são o mesmo que uma sala de dados verificada

A trilha de endereço público é útil, mas não identifica um data center. Apágina de contatoda Hosting27 fornece Sófia, Todor Aleksandrov Boulevard 133, andar 2, mais um número de telefone e e-mails de suporte e vendas. O registro de organização RIPE para Hosting-27 LTD fornece um endereço correspondente Todor Aleksandrov 133. Oregistro de organização RIPEda Geytit OOD também usa Todor Aleksandrov 133 e aparece como a organização patrocinadora no registro AS42347. Esses registros são significativos para contato e administração de registro. Eles não provam que os servidores dos clientes estão nesse prédio, que a Hosting-27 possui racks lá, ou que a empresa tem acesso direto a energia e infraestrutura de cross-connect.

Os termos legais públicos adicionam outro limite. Apágina de termos e condiçõesda Hosting27 incorpora um PDF, e ostermos PDFestipulam que as condições de serviço regem hospedagem compartilhada, certificados SSL, registro de domínio, servidores virtuais e servidores virtuais gerenciados através do site Hosting27.com. O PDF nomeia Cloud Systems OOD como provedor nos termos búlgaros e fornece um número de registro de empresa diferente. Este artigo não trata isso como uma conclusão de relação empresarial. Trata isso como um problema de diligência do comprador: a marca, a organização RIPE, o LIR patrocinador, os termos do site e o emissor da fatura devem estar alinhados antes que um cliente considere o serviço como um contrato de infraestrutura confiável.

Esse limite é importante em caso de falha, não apenas na compra. Se uma VM falhar às 2h, o cliente precisa saber qual entidade controla a fila de suporte, qual entidade possui ou aluga o hardware, quem pode autorizar mãos remotas, quem pode substituir um disco, quem controla a sessão do roteador, quem fatura o serviço e quem pode preservar os dados em caso de disputa de faturamento. Uma incompatibilidade entre a marca, o titular do AS e o provedor contratual não é intrinsecamente ruim; muitos grupos de hospedagem usam veículos legais separados para recursos de endereço, contratos de clientes, instalações e operações.

Mas os documentos públicos examinados aqui não explicam essa estrutura. Os clientes devem perguntar diretamente.

Os termos também indicam que o serviço hospedado é uma oferta limitada, não uma garantia de que cada cliente recebe um ambiente totalmente independente. O PDF indica que a hospedagem compartilhada implica que os clientes compartilham recursos comuns de servidor, como velocidade, RAM e conectividade de rede com outros usuários. Sua seção sobre servidores virtuais gerenciados descreve a administração de um servidor virtualmente separado com painel de controle, suporte 24 horas, recursos garantidos não compartilhados com outras aplicações de clientes, monitoramento, reação a problemas e backups regulares.

É uma linguagem útil para entender as classes de serviço pretendidas. Ainda deixa em aberto o tempo de restauração, localização dos backups, duração da retenção de snapshots, replicação fora do local, formato de exportação do cliente e créditos de interrupção na visão pública.

O enquadramento "data center virtual" da página de nuvem privada é particularmente importante de qualificar. Um cliente lendo essa frase pode imaginar uma zona de data center dedicada. A página em si descreve uma abstração OpenStack: redes criadas pelo cliente, roteadores, balanceadores de carga e serviços de armazenamento. Essas são funcionalidades virtuais do plano de controle. Elas ainda dependem de nós físicos, discos, placas de rede, switches de topo de rack, fontes de alimentação e links de trânsito.

Sem uma instalação nomeada ou declaração de arquitetura, a alegação deve ser tratada como uma oferta de plano de controle de nuvem, não como evidência de um site físico separado.

A dependência upstream visível é a Telehouse, enquanto a Telepoint é uma possibilidade política

A imagem de roteamento é simples no ponto de observação atual. A visãoASN-neighboursdo RIPEstat para AS42347 relatou um único vizinho no último momento disponível: AS57344. Avisão geral do AS do RIPEstat para AS57344identifica AS57344 como TELEHOUSE-AS Telehouse EAD. Oaut-num AS57344do RIPE mostra Telehouse com uma ampla política upstream e de troca, incluindo Arelion, Cogent, GTT, Level 3, Liberty Global, NTT, Orange, PCCW, RETN, Seabone, Tata, Telxius e várias malhas de troca. Oregistro AS57344no PeeringDB descreve Telehouse como tendo escopo global, suporte IPv6, muitas presenças de troca e entradas de instalação.

Essa amplitude da Telehouse ajuda a explicar como o /24 da Hosting-27 pode ser visível de coletores globais. Isso não torna automaticamente a Hosting-27 multi-homed. A dependência imediata observada para AS42347 é ainda um vizinho. Se a rota AS42347 é carregada apenas pela Telehouse na borda ativa, então um problema do lado da Telehouse, uma sessão, um filtro de rota, um incidente de instalação, um problema de cross-connect, um congelamento comercial ou uma janela de manutenção pode afetar todos os clientes usando o prefixo visível da Hosting-27.

Os coletores de rota públicos podem perder caminhos de backup privados, sessões temporariamente inativas ou arranjos que só se tornam ativos em caso de falha. Mas o ônus recai sobre o provedor para mostrar tal redundância, pois a visão BGP pública atual não a mostra.

AS31083 é o segundo nome a ser tratado com precisão. O aut-num RIPE do AS42347 lista a política de importação e exportação com AS31083, e avisão geral do AS31083do RIPEstat identifica AS31083 como Telepoint Ltd. Oaut-num AS31083do RIPE mostra Telepoint conectado a vários upstreams, e oregistro Telepointno PeeringDB relata um perfil de escopo europeu menor. Mas a visão AS-routing-consistency do RIPEstat mostra AS31083 como presente na política whois e não presente no BGP para AS42347 no momento da consulta. Isso significa que a política de registro sozinha não deve ser descrita como diversidade ativa.

A ausência de PeeringDB para Hosting-27 reforça a necessidade de cautela. Umaconsulta PeeringDB para AS42347não retornou nenhum objeto de rede público. Muitas redes pequenas operam sem perfil no PeeringDB, então a ausência não é uma falha. Isso significa que não há lista pública de instalações da Hosting-27, lista de troca, página de looking-glass, estimativa de tráfego, política de peering ou perfil NOC neste diretório. A única trilha de interconexão pública é a política RIPE, os coletores de rota e as identidades dos upstreams observados ou registrados.

O resultado de segurança de origem de rota é positivo. Avalidação RPKI para 217.174.144.0/24relata um ROA válido para AS42347 originando o /24 exato com comprimento máximo /24. Isso ajuda redes que aplicam validação de origem de rota a aceitar a rota como autorizada. Isso não protege contra falha de host, falha de armazenamento, má configuração de roteador, contas upstream não pagas, comprometimento do painel de controle ou bloqueio de conta de cliente. RPKI responde a quem pode anunciar o prefixo, não se o serviço de hospedagem pode se recuperar.

Para os compradores, a questão de diligência sobre trânsito é prática: Telehouse é o upstream ativo para todos os serviços da Hosting27? AS31083 é uma entrada de política de backup ou histórica? Algum dos caminhos pode transportar a carga de trabalho do cliente durante a manutenção? As rotas são anunciadas de pontos de entrega fisicamente separados ou da mesma sala e cadeia de dependência?

As funcionalidades de nuvem anunciadas não equivalem a capacidade instalada, utilizável ou recuperável

A economia de hospedagem recompensa o compartilhamento eficiente. A hospedagem compartilhada vende disco, e-mail e gerenciamento de site agrupando muitas contas de clientes em um ou mais servidores. A hospedagem VPS vende fatias de CPU virtual, RAM e armazenamento de hosts maiores. O VPS gerenciado adiciona mão de obra de suporte, monitoramento e administração. A nuvem privada adiciona uma camada de orquestração e uma promessa mais forte de controle do cliente. Kubernetes adiciona outra camada de orquestração por cima. Cada camada pode ser real enquanto depende de um pequeno número de nós físicos.

As páginas da Hosting27 fazem afirmações amplas que são plausíveis para um pequeno provedor búlgaro, mas impossíveis de dimensionar de fora. Os planos de hospedagem compartilhada anunciam sites, caixas de correio e tráfego ilimitados, mas são regras de plano, não capacidade infinita. O serviço ainda depende de CPU, RAM, E/S de armazenamento, limites de inodes, regras de uso justo, controle de spam e gerenciamento de abuso.

Os planos de revenda anunciam tráfego e contas ilimitados, mas os limites de armazenamento são 40 GB, 75 GB e 130 GB; a restrição real pode ser E/S, reputação de e-mail de saída, densidade de contas ou desempenho do host compartilhado antes que o disco bruto se esgote.

As páginas VPS são mais concretas, pois listam valores de CPU virtual, RAM e SSD. Um plano Cloud VPS com 1 vCPU, 1 GB de RAM, 30 GB de SSD e um plano com 4 vCPU, 6 GB de RAM, 85 GB de SSD podem ser provisionados a partir de um cluster OpenStack modesto. Mas uma tabela de planos não mostra quantas instâncias podem ser vendidas sem contenção, quantos nós existem, se a CPU é superalocada, como a replicação de armazenamento é ajustada, se o Ceph se estende por domínios de energia independentes, ou se os backups são armazenados no mesmo sistema físico que deveriam proteger.

A página indica que o Ceph mantém dados replicados em vários lugares; um cliente ainda precisa saber se esses lugares são discos separados, chassi separados, racks separados ou instalações separadas.

A linguagem de nível de serviço de 99,99% da página de nuvem privada deve ser tratada como uma afirmação a ser verificada, não como evidência do estado operacional alcançado. Quatro nove de disponibilidade permitem apenas uma pequena quantidade de tempo de inatividade em um ano, e isso exige tanto arquitetura quanto disciplina operacional: energia redundante, caminhos de rede redundantes, armazenamento gerenciado com cuidado, recuperação testada do plano de controle, gerenciamento de mudanças, monitoramento e uma equipe de suporte capaz de agir rapidamente.

O site público não publica o documento SLA, a programação de crédito, o método de medição, as exclusões, o tratamento de manutenção planejada ou o histórico de incidentes que permitiriam a um comprador avaliar essa promessa.

O estoque de endereços limita alguns casos de uso. Um cliente que precisa de muitos endereços IPv4 públicos, separação de serviços de e-mail, compatibilidade SSL herdada baseada em IP, isolamento anti-abuso ou endpoints VPN deve perguntar quantos IPv4 estão realmente disponíveis. A contagem deRIPEstat routing-statusde 256 endereços IPv4 não é a mesma que 256 IPs de cliente vendáveis. Alguns são consumidos por infraestrutura, DNS, hospedagem compartilhada, gerenciamento, reservas e alocações de clientes. IPs adicionais são vendidos na página Cloud VPS, tornando o pool operacionalmente importante. Se problemas de abuso ou lista negra afetarem uma parte do /24, o pequeno pool de endereços pode tornar a recuperação mais difícil.

IPv6 é outra lacuna. As páginas de produtos públicos da Hosting27 examinadas aqui não fazem uma promessa forte de IPv6, e o RIPEstat não mostra nenhum espaço IPv6 anunciado visível para AS42347 no momento verificado. Um cliente que precisa de hospedagem compatível com IPv6 não deve deduzir isso da palavra nuvem. Deve solicitar um endereço de teste IPv6, cobertura SLA, gerenciamento de firewall, DNS reverso, evidências de roteamento e se o suporte IPv6 está disponível em hospedagem compartilhada, VPS, nuvem privada e Kubernetes da mesma forma que o IPv4.

Portanto, a conclusão de capacidade do artigo é conservadora: a Hosting27 vende um conjunto real de produtos de hospedagem e nuvem, e o AS42347 dá a esses produtos uma verdadeira borda de rede pública. Mas não há nenhuma evidência pública que traduza o menu de planos em nós instalados, capacidade de reserva disponível, design multi-site ou imagens recuperáveis pelo cliente.

As alegações de suporte e backup são úteis, mas a autoridade de reparo é a questão central

As evidências de suporte são melhores que o silêncio. Apágina de contatoda Hosting27 lista endereços de suporte, incluindo caixas de correio support e devops, e um endereço de vendas separado. Apágina de tickets de suporteindica que clientes que não conseguem resolver um problema na documentação podem enviar uma solicitação ao departamento apropriado. Ela descreve o suporte como funcionando todos os dias sem interrupção e as solicitações de vendas como tratadas de segunda a sexta, das 09h às 18h. Abase de conhecimentotem categorias para cPanel, Virtualmin, servidores VPS, WordPress, domínios e hospedagem compartilhada. Apágina de anúncioscontém um anúncio de site mais antigo de 2018, o que mostra pelo menos que o portal do cliente faz parte da superfície de serviço há anos.

Esses são sinais operacionais úteis. Eles não são suficientes para responder ao risco de janela de reparo. A distinção mais importante é entre um canal de suporte que recebe tickets e uma equipe de operações com autoridade sobre o componente falho. Se a falha é uma configuração do cPanel, o help desk do provedor pode repará-la rapidamente. Se a falha é um disco morto, um switch defeituoso, um problema de energia, um problema de quorum de cluster de armazenamento, um filtro de rota upstream ou uma conta de faturamento bloqueada, o reparo depende de quem controla o hardware, o acesso à instalação, as sessões de rota e as permissões contratuais.

Os termos e condições também são úteis, mas incompletos para o planejamento de incidentes. O PDF indica que servidores virtuais gerenciados incluem suporte técnico 24 horas, monitoramento e reação a problemas, backups regulares e a capacidade de hospedar aplicações de clientes. Indica que a hospedagem compartilhada inclui suporte técnico e especifica que usuários compartilhados compartilham recursos. As páginas públicas anunciam adicionalmente backups diários no Cloud VPS e Cloud VPS gerenciado, backups de um mês na hospedagem compartilhada e migração gratuita para alguns planos. Isso é valioso.

Ainda deixa em aberto questões práticas: os backups estão no mesmo cluster ou fora do local, quantas gerações existem, um cliente pode restaurar em autoatendimento, uma imagem de VM pode ser exportada, o que acontece após a suspensão da conta e qual é o tempo de restauração alvo?

A promessa de migração também é mais estreita do que parece. A Hosting27 afirma que pode mover uma conta de hospedagem ou site WordPress gratuitamente. Isso ajuda na integração. Não cria necessariamente um caminho de saída. Um cliente que sai mais tarde pode precisar de um backup completo do cPanel, dump de banco de dados, arquivos de zona DNS, caixas de correio, imagem de disco VM, snapshot de armazenamento em bloco, dados de objeto, manifests do Kubernetes, imagens de contêiner, segredos e renumeração de IP.

O site público não descreve os formatos de exportação, janelas de retenção, taxas de migração após cancelamento ou se os clientes podem extrair imagens do OpenStack.

O tratamento de abuso é importante porque provedores de hospedagem vivem e morrem pela reputação compartilhada. O registro de organização RIPE para Hosting-27 aponta abuso paraGLAC2-RIPE, um contato de abuso GateIT. Este é um caminho de abuso de registro, não necessariamente o mesmo que um help desk de varejo. Um cliente operando e-mail, comércio eletrônico ou APIs públicas deve perguntar quem gerencia o DNS reverso, quem lida com a limpeza de listas negras, quem decide se uma conta comprometida causa suspensão mais ampla e se os problemas de reputação de IP podem ser isolados dentro do /24.

Portanto, a postura de suporte público é suficientemente crível para contar, mas não detalhada o suficiente para remover o risco operacional. Os compradores devem testar o help desk antes de mover cargas de trabalho importantes, solicitar um caminho de contato de incidente e solicitar termos escritos de backup e exportação em vez de confiar na linguagem abreviada das páginas de plano.

A localização dos dados não é resolvida por um endereço búlgaro ou IP búlgaro

A superfície búlgara da Hosting27 é relevante. O site está em búlgaro, a página de contato fornece detalhes em Sófia, a organização RIPE e o endereço são búlgaros, o SN está na região RIPE e o bloco IPv4 visível está registrado com o país BG. Para clientes com usuários búlgaros, fatura búlgara, suporte em idioma local e latência para Sófia ou redes regionais podem ser razões para considerar o serviço. Para clientes com requisitos regulatórios ou contratuais de localização de dados, esses sinais são apenas o começo.

O contexto da UE e da Bulgária torna a distinção importante. A visão geral da Comissão Europeia sobre oquadro jurídico de proteção de dados da UEexplica o regime de proteção de dados em toda a UE. Sua página sobrecontroladores e processadores de dadosexplica a distinção entre a parte que decide como os dados pessoais são processados e uma parte que os processa em nome de outra. A página da Comissão sobrecláusulas contratuais padrãocobre ferramentas de transferência de dados para situações fora do Espaço Econômico Europeu. AComissão Búlgara de Proteção de Dados Pessoaisé a autoridade de supervisão nacional. Este artigo não é aconselhamento jurídico, mas essas referências públicas mostram por que a localização da infraestrutura, o acesso ao suporte e a geografia dos backups não são detalhes cosméticos.

Um endereço IP búlgaro não prova que todos os dados permanecem na Bulgária. Backups de hospedagem compartilhada podem ser armazenados em outra instalação. O monitoramento pode ser feito de outro lugar. Um ticket de suporte pode incluir dados pessoais. Um painel de controle pode depender de software de terceiros ou autenticação externa. Um recurso de CDN pode intencionalmente colocar conteúdo estático em outros países. Um serviço de registro de domínio interage necessariamente com registros e registradores fora do nó de hospedagem.

Um cliente de nuvem privada pode criar redes e volumes em um console de aparência búlgara enquanto alguns componentes de gerenciamento ou backup estão em outro lugar.

Portanto, as boas perguntas de diligência são concretas. Onde está o nó de computação principal? Onde estão armazenados snapshots e backups? A equipe de suporte e administradores remotos estão na UE? O provedor oferece um acordo de processamento de dados? Qual entidade legal é o processador para serviços de hospedagem? O contrato nomeia a mesma parte que fatura o cliente? Se os dados saírem da Bulgária ou do EEE, qual mecanismo de transferência se aplica? O que acontece se o cliente solicitar exclusão ou exportação de dados? Quais logs são mantidos e por quanto tempo?

Essas perguntas não são suspeita particular em relação à Hosting-27. São normais para qualquer pequeno provedor de nuvem ou hospedagem que comercializa localidade. As evidências públicas aqui apoiam uma zona de serviço búlgara e uma borda roteada búlgara. Elas não provam uma arquitetura completa de residência de dados na Bulgária.

Os caminhos de falha a testar são rack, upstream, estoque de hardware, suporte, faturamento e migração

O primeiro caminho de falha é o rack. Se um servidor de hospedagem compartilhada ou host VPS falhar, quem toca na máquina? Um cliente deve perguntar onde o rack está localizado, quem possui o hardware do host, como a energia é protegida, se há nós de reserva, se o armazenamento é local ou distribuído e se um nó com falha pode ser evacuado sem alterar o IP do cliente. O site público anuncia backups e funcionalidades de nuvem, mas não nomeia a instalação física, o rack, o provedor de mãos remotas ou o plano de hardware de reposição.

O segundo caminho é o trânsito upstream. O RIPEstat atualmente vê AS42347 via AS57344. O provedor deve ser capaz de dizer se a rota tem um segundo upstream ativo, se a Telepoint está ativa, é backup ou histórica, se a rota de backup é testada, se a validação de origem de rota é monitorada e se os clientes recebem aviso prévio antes da manutenção de rede. Um resultado RPKI válido é bom. Não é o mesmo que um segundo caminho.

O terceiro caminho é o estoque de hardware e armazenamento. As ofertas de VPS e nuvem privada dependem da relação entre planos vendidos e computação disponível, RAM, E/S de disco e replicação de armazenamento. Um cliente deve perguntar se os recursos anunciados são garantidos, se a CPU é superalocada, se o Ceph se estende por hosts separados ou racks separados, quantas falhas podem ser toleradas e se há capacidade de reserva suficiente para restaurar um host durante um período movimentado. A página pública nomeia OpenStack, KVM e Ceph, mas esses nomes podem descrever qualquer coisa, de um pequeno cluster a um ambiente multi-rack maior.

O quarto caminho é a escalada de suporte. A Hosting27 expõe páginas de suporte, vendas, base de conhecimento e tickets. O comprador ainda deve testar a qualidade da resposta, perguntar quem está de plantão, identificar o caminho de emergência para uma VM com falha e perguntar se o suporte pode contatar diretamente operadores de rede e instalação. Uma resposta comercial não é o mesmo que autoridade de incidente.

O quinto caminho é a continuidade de faturamento e legal. Os termos PDF do site nomeiam Cloud Systems OOD como provedor, enquanto a RIPE nomeia Hosting-27 LTD como organização de rede. Os clientes devem perguntar qual parte assina o contrato, qual parte fatura, qual parte controla a suspensão do serviço e qual parte é responsável pela exportação e exclusão após o cancelamento. Se a conta for suspensa por faturamento ou abuso, o cliente deve saber por quanto tempo os dados permanecem recuperáveis.

O sexto caminho é a migração. Para hospedagem compartilhada, o caminho de saída deve incluir backup do cPanel, DNS, caixas de correio e bancos de dados. Para WordPress, deve incluir arquivos, banco de dados, redirecionamentos e tempo de DNS. Para VPS, deve incluir exportação de imagem de disco, formato de snapshot, renumeração de IP e atualizações de firewall. Para nuvem privada e Kubernetes, deve incluir volumes, redes, balanceadores de carga, manifests, segredos e registros de imagem. A Hosting27 comercializa migração de entrada gratuita, mas o material público não publica uma promessa completa de portabilidade de saída.

O sétimo caminho é a reputação de endereço. Um /24 compacto pode ser eficiente, mas dá menos espaço para isolar clientes comprometidos. Problemas de e-mail, proxy, varredura e abuso podem levar a listas de bloqueio, filtragem upstream ou suspensões internas. Clientes com cargas de trabalho de e-mail ou transacionais devem perguntar sobre controle de DNS reverso, procedimento de resposta a abuso, política de limpeza de listas negras e se endereços IP adicionais vêm do mesmo pool 217.174.144.0/24.

Essas não são preocupações teóricas. São os modos de falha comuns escondidos sob hospedagem de baixo custo: um rack inacessível, uma sessão upstream que desaparece, um cluster de armazenamento que perde o quorum, um backup que existe mas não pode ser restaurado rapidamente, uma fila de tickets que não consegue alcançar a instalação e um cliente que descobre tarde demais que sair significa reconstruir em torno de novos endereços IP.

O que tornaria as evidências sólidas

Hosting-27 Hosting-27 LTD tem evidências públicas suficientes para um perfil operacional real: o site está ao vivo, o portal do cliente está ao vivo, as páginas de produtos são específicas, a rota é visível, o domínio resolve dentro do bloco IPv4 visível da empresa, a organização RIPE está atualizada e a autorização de origem de rota é válida. Isso é materialmente mais forte do que uma empresa cujo único vestígio é um registro AS desatualizado.

As evidências públicas não são fortes o suficiente para uma dependência de infraestrutura de alta confiança sem diligência direta.

Um perfil mais forte incluiria uma página legal atualizada que alinhe a marca, a organização RIPE e o provedor contratual; uma declaração de instalação nomeando o operador do data center ou explicando o acordo de hospedagem; um SLA com condições de medição e crédito; uma página de status ou arquivos de incidentes; objetivos explícitos de retenção e restauração de backups; disponibilidade IPv6 se oferecida; um segundo upstream ativo ou uma explicação escrita da política de rota da Telepoint; formatos de exportação para dados VPS e nuvem privada; e um procedimento claro de abuso e reputação de IP.

O conjunto provável de clientes deve ser escalonado por risco. Um pequeno site búlgaro, um servidor de staging, um site WordPress não crítico ou um VPS experimental pode avaliar a Hosting27 por testes de serviço comuns: pedir um plano pequeno, testar o suporte, verificar a latência, restaurar um backup e verificar o cancelamento. Um sistema crítico para os negócios não deve confiar apenas na tabela de planos. Deve obter respostas escritas sobre instalação, backups, diversidade de trânsito, contrato legal e portabilidade de dados antes de mover a produção.

A leitura final é equilibrada. Hosting-27 Hosting-27 LTD é visível como um vendedor búlgaro de capacidade hospedada com AS42347 e uma plataforma ao vivo Hosting27.com. Sua história operacional pública não está vazia. Mas os fatos de infraestrutura decisivos permanecem atrás da camada de vendas.

Até que esses fatos sejam divulgados ou verificados em um contrato de cliente, a Hosting27 deve ser entendida como um provedor compacto e búlgaro de serviços de hospedagem e nuvem cuja promessa ao cliente ainda depende de racks invisíveis, trânsito visível via Telehouse, um estoque finito de IPv4, mão de obra de suporte, contratos de fornecedores e janelas de reparo.