Resumen
- Global Cloud Ltd es un operador de red real visible a través de RIPE, no simplemente un nombre en un directorio. Elobjeto de organización RIPE para ORG-GCL12-RIPEmenciona a Global Cloud Ltd, proporciona el número de registro israelí
514919729, indica el tipo de organizaciónLIRy facilita la dirección HaMasik St 4, Emek Hefer, Israel, con el mismo número de teléfono que aparece en el sitio web de la empresa. - La empresa está vinculada a AS61365, cuyoresumen de AS de RIPEstatespecifica al titular como
GC-5222 Global Cloud Ltdy mostraba el AS como anunciado en la fecha de consulta del 11/07/2026. Lavista del estado de enrutamientode RIPEstat mostraba cuatro prefijos IPv4, 1.024 direcciones IPv4 visibles, ningún prefijo IPv6 visible y dos vecinos observados. - El espacio de direccionamiento de la empresa no es un bloque de terceros independiente. Elregistro de prefijo RDAP RIPE para 185.184.16.0/22y lavista whois de RIPEstatidentifican
IL-GLOBAL-20170102, país IL, organizaciónORG-GCL12-RIPE, estadoALLOCATED PAy un archivo geofeed engeofeed.xprsit.netque asocia el /22 y cada /24 con Emek Hefer. - La garantía del origen de las rutas es mejor que la de muchas pequeñas huellas alojadas. Las respuestas de validación RPKI de RIPEstat para185.184.16.0/24,185.184.17.0/24,185.184.18.0/24y185.184.19.0/24devolvieron todas
validbajo una ROA 185.184.16.0/22 con longitud máxima 24. - La situación de los proveedores de tránsito aún requiere pruebas por parte del cliente. Elobjeto aut-num RIPEenumera políticas para AS1680, AS212616 y AS8551, mientras que lavista de vecinos de ASNde RIPEstat mostraba AS1680 y AS212616 como vecinos observados y suvista de consistencia de enrutamiento de ASmostraba AS8551 en la política whois pero no en BGP en el momento de la consulta.
- El nivel de evidencia es medio. Las fuentes públicas respaldan con fuerza la identidad jurídica, el control de los recursos de red, la conectividad IPv4 actual y la validación del origen de las rutas. No prueban la cantidad de racks, la propiedad de las instalaciones, la amplitud del hardware de repuesto, la recuperación probada en varios sitios, el abanico real de cargas de trabajo de los clientes, el tiempo de respuesta del soporte contractual o los límites de portabilidad de los datos.
Los registros públicos son concretos, pero la capacidad cloud queda por demostrar
Global Cloud Ltd merece un tratamiento diferente al de los nombres de cáscara vacía de alojamiento que solo aparecen en listas agregadas. La empresa tiene una identidad de red pública, un sitio web oficial, el estatus de LIR RIPE, un número de registro israelí en el objeto de organización RIPE, un sistema autónomo activo y una asignación IPv4 registrada. Elregistro RDAP aut-num RIPE para AS61365nombra el ASGC-5222, lista a Global Cloud Ltd como entidad organizativa y repite la dirección HaMasik St 4, Emek Hefer, Israel. Lapágina de inicio en inglés de la empresaindica la línea de contacto como Hamasek 4, Emek Hefer Industrial Park, publica el número de teléfono 072-274-3030 y describe servicios relacionados con el desarrollo, el almacenamiento y la seguridad.
Esta combinación hace que la empresa sea lo suficientemente observable como para ser analizada. Pero no hace que el servicio sea completamente verificable desde el exterior. Un cliente que compra cloud, alojamiento, escritorios virtuales o un servicio gestionado no compra solo un número de AS. Apuesta por racks, circuitos, ópticas, enrutadores, hipervisores, almacenamiento, trabajos de copia de seguridad, licencias, equipos de soporte, fuentes de alimentación, control de acceso, sistemas de facturación y procedimientos de migración.
La Internet pública puede mostrar que AS61365 es alcanzable; no puede mostrar si una carga de trabajo particular de un cliente puede restaurarse tras la avería de un estante de almacenamiento, un litigio con un proveedor, un corte de electricidad o un cambio de enrutamiento.
La forma más útil de interpretar a Global Cloud es, por tanto, verla como una superficie de infraestructura de tamaño medio con suficientes pruebas públicas para evitar la especulación y suficientes detalles operativos ausentes como para exigir diligencia debida. Lapágina de servicios cloud en inglésdel sitio web de la empresa indica que ofrece servicios de centro de datos y cloud, DaaS, PaaS, Infraestructura como Servicio, servicios de colaboración, servicios informáticos y servicios de software. También afirma que el equipo de soporte trabaja 24/7 y que Global Cloud pone el acento en la seguridad y la capacidad de supervivencia. Se trata de afirmaciones de servicio pertinentes, pero no sustituyen una prueba de recuperabilidad.
Las pruebas también contienen un pequeño indicio editorial revelador. Algunas partes de la página de cloud en inglés hacen referencia a «Xpress Technologies» mientras que el dominio, los registros RIPE y el pie de página hablan de Global Cloud. Podría tratarse de contenido heredado, un remanente de plantilla, una marca vinculada o un artefacto de traducción; las pruebas públicas no permiten decidirlo.
El punto de riesgo para el cliente no es que esta incoherencia de nombre demuestre algo negativo, sino que las amplias promesas de cloud deberían conciliarse con los contratos de servicio actuales, los esquemas de plataforma vigentes y los límites del soporte reales, en lugar de inferirse a partir de contenido web antiguo o inconsistente.
Para este artículo, la tesis operativa es sencilla: Global Cloud Ltd tiene una huella de red israelí real y un catálogo de servicios público lo bastante amplio como para crear dependencia en el cliente. La tarea del comprador es verificar qué parte de ese catálogo está implantada, dónde se aloja físicamente, cómo conmutan las rutas, cómo responde el personal fuera del horario laboral y cómo pueden las cargas de trabajo abandonar el servicio si éste deja de ser adecuado.
AS61365 otorga a Global Cloud una ventaja medible
Las pruebas más sólidas específicas de la empresa comienzan con AS61365. Elresumen de AS de RIPEstatdesigna al titularGC-5222 Global Cloud Ltdy mostraba el AS anunciado a las 08:00 UTC del 11 de julio de 2026. Elpunto final de estado de enrutamientode RIPEstat mostraba cuatro prefijos IPv4, 1.024 direcciones IPv4, ningún prefijo IPv6, 326 pares de un total de 327 en el flujo completo RIS IPv4 que veían la ruta, y una visibilidad IPv6 nula. Los cuatro prefijos anunciados actualmente en larespuesta de prefijos anunciadoseran 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 y 185.184.19.0/24.
Se trata de un punto de entrada de red significativo. No es, sin embargo, una huella a escala hiperescalar. Un /22 dividido en cuatro anuncios /24 puede soportar servicios de clientes, plataformas alojadas, VPN, correo electrónico, servicios de escritorio, redes de gestión, clientes de acceso estático o una mezcla de usos. Eso no prueba por sí solo un extenso dominio público en la nube. La cantidad de direcciones IPv4 anunciadas no equivale al número de servidores, máquinas virtuales, inquilinos, repositorios de copias de seguridad u objetivos de restauración.
La ausencia de IPv6 visible en RIPEstat también es relevante, ya que la preparación para IPv6 forma ahora parte de la planificación de red de muchos compradores, incluso si el servicio inmediato puede funcionar en IPv4.
Elpunto final de recuento de prefijosde RIPEstat añade un historial útil. Muestra el modelo actual de Global Cloud con cuatro prefijos IPv4 tras cambios de visibilidad anteriores y ningún contador de prefijos IPv6 durante la ventana de consulta del 11/07/2026. Elpunto final de historial de enrutamientomuestra una antigua visibilidad de AS61365 para 94.30.220.0/24 en 2012-2014, luego la familia 185.184.16.0/22 a partir de 2017. Este historial es una señal positiva a nivel de enrutamiento: AS61365 no es un experimento de una semana.
Pero la continuidad de ruta no es continuidad de servicio. El paso de un historial antiguo en 94.30.220.0/24 a la familia 185.184.16.0/22 puede reflejar un cambio de proveedor, de servicio, de adquisición de recursos de direccionamiento, de clientela o simplemente el registro visible de prefijos diferentes. El BGP público no explica la razón comercial. Solo muestra que el AS ha tenido rutas observadas en diferentes periodos y que la huella enrutada actual se compone de los cuatro /24 bajo 185.184.16.0/22.
Por consiguiente, los clientes deben considerar AS61365 como un hecho de partida sólido y una prueba final débil. Puede justificar el planteamiento de preguntas detalladas. No puede reemplazar las respuestas. Si Global Cloud vende servidores virtuales, el comprador necesita la arquitectura de los hosts y del almacenamiento. Si vende escritorio como servicio, el comprador necesita la capacidad de sesión de usuario, las dependencias de identidad y el rendimiento del enlace. Si vende aplicaciones gestionadas, el comprador necesita la propiedad operativa y el detalle de las copias de seguridad.
Si vende IaaS, el comprador debe saber qué parte de la pila está automatizada y qué parte es un dominio de alojamiento gestionado manualmente.
La asignación /22 respalda el control, no una escala ilimitada
Las pruebas relacionadas con el espacio de direccionamiento son particularmente útiles porque vinculan los prefijos enrutados a Global Cloud y no a un arrendador de direcciones completamente distinto. Elregistro de prefijo RDAP RIPEpara 185.184.16.0/22 muestra el identificador185.184.16.0 - 185.184.19.255, el nombreIL-GLOBAL-20170102, el tipoALLOCATED PA, el país IL y la entidad organizativa Global Cloud. Elobjeto inetnum RIPE RESTrepite la misma asignación y añade una URL de geofeed. Elobjeto de organizaciónpresenta Global Cloud Ltd como LIR. Esto es importante porque supone una posición de identidad más sólida que la de un pequeño proveedor que simplemente anuncia el bloque de otro.
Las etiquetas más específicas del registro aportan color sin probar el uso por clientes. Larespuesta de jerarquía del espacio de direccionesde RIPEstat enumera 185.184.16.0/24 comoSHVDOM-1-Subnet, 185.184.17.0/24 comoSHVDOM-Core-Subnet, 185.184.18.0/24 comoLNS-Static-Subenty 185.184.19.0/24 comoSHVDOM-Subnet. Estos nombres sugieren una segmentación interna y al menos una etiqueta de servicio estático o de red. No prueban qué productos se venden desde cada subred, qué clientes los utilizan o si las etiquetas son descripciones operativas actuales y no nombres administrativos.
Esta distinción es central en la economía del alojamiento. Un proveedor puede poseer o explotar una asignación de direcciones y, sin embargo, tener una capacidad de servidores instalada limitada detrás de ella. Un proveedor puede usar un /24 para el servicio de cliente estático, otro para la gestión o funciones centrales y otro para las cargas de trabajo alojadas. Un proveedor también puede vender servicios cuyo plano de control o sitio web se encuentre en una red diferente. El mapa de direcciones públicas indica al comprador por dónde empezar, no dónde termina cada dependencia.
El sitio web público de la empresa ilustra este punto. Una simple consulta DNS durante la investigación mostró queglobalcloud.meywww.globalcloud.mese resolvían a 212.29.210.119, y lavista whois de RIPEstat para 212.29.210.119sitúa esa dirección enIL-NETVISION-980831, y no en la asignación 185.184.16.0/22 de Global Cloud. Esto no tiene nada de inusual. Muchos proveedores alojan su sitio web de marketing en otro operador o en otra plataforma. La cuestión es simplemente que el extremo del sitio web no debe tomarse como prueba de dónde residen las cargas de trabajo cloud de los clientes.
Para los clientes, la pregunta adecuada no es, por tanto, «¿Tiene Global Cloud direcciones?». Las tiene. La pregunta mejor es cómo se asignan esas direcciones a los servicios, si las asignaciones de direcciones IP de cliente son portables, cómo se gestionan el DNS inverso y la reputación, cómo funcionaría una renumeración y si el comprador recibe un preaviso suficiente si Global Cloud cambia de proveedores de tránsito, de subredes o de plataformas de servicios.
RPKI es una verdadera fortaleza en las pruebas públicas actuales
La validación del origen de las rutas es uno de los pocos controles públicos en los que la huella de Global Cloud parece más sólida que la línea de base pobre en información. El punto final de validación RPKI de RIPEstat devolvióvalidpara 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 y 185.184.19.0/24 al ser consultado para AS61365. Cada respuesta apuntaba a una ROA validante para 185.184.16.0/22, origen AS61365, longitud máxima 24. Esto significa que los cuatro anuncios /24 actuales coinciden con la autorización de origen de ruta publicada en el momento de la consulta.
El valor técnico es limitado pero real. LaRFC 6811explica la validación del origen de los prefijos BGP como un medio para que un enrutador determine si el AS que pretende anunciar el prefijo está autorizado por el titular del prefijo. RPKI no cifra los paquetes, no impide todas las fugas de rutas, no prueba que el camino sea el mejor, que un centro de datos sea resiliente ni resuelve la seguridad de las aplicaciones. Sin embargo, reduce una clase de riesgos de anuncios de origen erróneos cuando las redes aplican políticas de validación.
Para Global Cloud, esto importa porque la huella enrutada es compacta. Si un proveedor tiene cuatro /24 visibles actualmente y ninguna IPv6 visible, los errores de origen de ruta pueden afectar a una gran parte de la superficie de servicio público. Las ROA válidas para los anuncios /24 actuales sitúan a los clientes en una mejor posición de partida que un resultadounknownoinvalid. También muestran que la relación entre el titular de la dirección y el origen dispone de al menos un control moderno de seguridad del enrutamiento en marcha.
La salvedad es que RPKI no es un SLA de cliente. No dice si AS1680, AS212616 o cualquier otro camino de tránsito tiene suficiente capacidad para encaminar el tráfico tras una avería. No dice si los enrutadores son redundantes. No dice si el filtrado anti-DDoS está activo. No dice si las copias de seguridad de los clientes son recuperables. Ni siquiera dice si cada objeto de ruta operativo está en orden. Larespuesta de consistencia de enrutamiento de prefijosde RIPEstat mostraba el objeto de ruta agregado 185.184.16.0/22 en el whois, 185.184.19.0/24 tanto en BGP como en el whois, y los anuncios 185.184.16.0/24, 185.184.17.0/24 y 185.184.18.0/24 en BGP sin objetos de ruta whois correspondientes en esa vista de consistencia específica. Larespuesta de consistencia de enrutamiento de ASde RIPEstat presenta la misma divergencia.
Esta divergencia no es una crisis porque el estado RPKI es válido y existe el objeto de ruta agregado. Sigue siendo una prueba operativa útil. Los clientes deben preguntar si Global Cloud se apoya intencionadamente en el objeto de ruta agregado más RPKI para los /24, si los filtros IRR utilizados por los proveedores de tránsito aceptan los anuncios actuales y qué proceso de control de cambios protege las actualizaciones de ROA y de objetos de ruta.
Una pequeña incoherencia en una vista de registro puede convertirse en un incidente importante si un filtro de proveedor, un servidor de rutas o un proveedor de tránsito la interpreta de manera diferente durante el mantenimiento.
La versión resumida: RPKI es una fortaleza. Hay que saludarla como un control actual y después ponerla en su justo lugar.
La diversidad de tránsito es visible, pero el historial de conmutación por error sigue sin completarse
La pregunta operativa más importante no es cuántos nombres de proveedores aparecen en un objeto de política, sino qué caminos pueden encaminar el tráfico cuando un camino, un enrutador, una interconexión o un contrato comercial falla. Los registros públicos de Global Cloud proporcionan suficientes pruebas para formular esta pregunta con precisión.
Elobjeto aut-num RIPE para AS61365incluye entradas de política para AS1680, AS212616 y AS8551. RIPEstat identificaAS1680como Cellcom Fixed Line Communication L.P,AS212616como K.M.A ADVANCED TECHNOLOGIES LTD, yAS8551como Bezeq International Ltd. Se trata de nombres de redes israelíes importantes. Elpunto final de vecinos de ASNmostraba, sin embargo, dos vecinos observados en el último momento de consulta disponible: AS1680 y AS212616. El punto final de consistencia de enrutamiento de AS mostraba AS1680 y AS212616 tanto en BGP como en el whois, mientras que AS8551 aparecía en el whois pero no en BGP en ese momento.
Las muestras de caminos afinan la imagen. Para 185.184.16.0/24, los caminos BGP muestreados terminaban en AS1680 AS61365. Para 185.184.17.0/24 y 185.184.18.0/24, el patrón de último salto dominante visible terminaba también en AS1680 AS61365. Para 185.184.19.0/24, el patrón visible terminaba en AS1680 AS212616 AS61365. No se trata de un mapa completo de operadores, y los colectores públicos pueden perderse sesiones privadas o de baja visibilidad. Aun así, es un indicio útil: diferentes /24 pueden seguir caminos diferentes adyacentes o cuasiadyacentes, y AS212616 es visible en el camino de ruta al menos para la vista 185.184.19.0/24.
Los clientes no deben interpretar esto como «conectado a una sola red» o «totalmente redundante» sin más pruebas. Es preferible leerlo como «multihoming parcialmente visible o complejidad de política de proveedor». El cliente debe preguntar qué ASN son tránsitos de producción activos, cuáles son de respaldo, cuáles son históricos y cuáles transportan servicios de cliente específicos. La respuesta debe incluir los compromisos de ancho de banda, la diversidad de enrutadores, la diversidad física de las interconexiones, las ventanas de mantenimiento, la gestión de DDoS, los contactos de escalado y las pruebas de conmutación por error recientes.
El camino de fallo es concreto. Si AS1680 sufre un incidente regional o un problema de filtro de enrutamiento, ¿pueden los cuatro /24 continuar a través de AS212616 u otro camino? Si AS212616 forma parte del camino 185.184.19.0/24, ¿qué servicio de cliente depende de ese /24? Si AS8551 está en el objeto de política pero no es visible actualmente en BGP, ¿se trata de una sesión de reserva, de un acuerdo histórico inactivo, de un camino planificado o de un artefacto de política? Si el tráfico conmuta tras un fallo, ¿tiene el proveedor suficiente capacidad aguas arriba y preferencia de ruta limpia para evitar pérdidas de paquetes?
Estas preguntas no son acusatorias. Son la diferencia entre un catálogo de servicios y un diseño operativo. Un proveedor de alojamiento puede vender honestamente un servicio resiliente desde una periferia pública compacta si ha probado rutas, capacidad de reserva y escalados claros. También puede vender un catálogo amplio desde una cadena de dependencia estrecha que funciona bien hasta el primer incidente grave de rack o de proveedor. Los datos públicos sitúan a Global Cloud en algún punto entre estas dos conclusiones. La diligencia debida del cliente determina de qué lado se acerca más la realidad.
Emek Hefer es una señal de localidad fuerte, no un certificado de rack
Global Cloud tiene varias señales de localidad israelíes que se superponen. Elobjeto de organización RIPEindica HaMasik St 4, 3877701, Emek Hefer, Israel. Laentidad aut-num RDAPrepite esta dirección. Lapágina de inicio de Global Cloudda Hamasek 4, Emek Hefer Industrial Park, y el mismo número de teléfono. Elarchivo geofeed referenciado en el objeto inetnum RIPEasocia 185.184.16.0/22 y cada uno de los cuatro /24 conIL, IL-HA, Emek Hefer.
Esto es suficiente para discutir Israel y Emek Hefer como la señal de localización pública dominante para la empresa y su espacio de direccionamiento. No basta para decir que cada carga de trabajo de cliente, copia de seguridad, registro, sesión de administrador o copia de recuperación ante desastres se encuentra físicamente en Emek Hefer. La dirección del registro IP, la localidad del geofeed y los datos de contacto no constituyen una auditoría de instalaciones.
Un proveedor puede explotar racks en un sitio, alquilar capacidad en otro, utilizar servicios de copia de seguridad remotos, ejecutar herramientas de soporte a través de plataformas cloud o alojar algunos servicios públicos en otros operadores.
La geolocalización muestra también por qué es necesaria la prudencia. Lavista geolocde RIPEstat y lavista MaxMind GeoLitesituaban el /22 en Israel pero en Ar Rayna, no en Emek Hefer. Esta discordancia no refuta el geofeed. Las bases de datos de geolocalización IP difieren a menudo, y los datos de geofeed pueden representar la intención del operador o una localidad autopublicada. Esto demuestra que los compradores no deben utilizar una consulta de geolocalización IP como garantía de ubicación física.
La localidad importa porque el catálogo de servicios de Global Cloud incluye servicios de tipo centro de datos, cloud, escritorio, plataforma, software y copia de seguridad. Lapágina oficial de la Autoridad Israelí de Protección de la Privacidad relativa a la seguridad de los datosdescribe regulaciones de seguridad de datos que se aplican a los sectores público y privado y establecen mecanismos organizativos en torno a la seguridad de las bases de datos. El mismo portal gubernamental publicadocumentos regulatorios sobre privacidad relativos a los datos transferidos a Israel desde el Espacio Económico Europeo. Estas páginas oficiales no nos dicen qué clientes de Global Cloud tratan datos personales o si Global Cloud actúa como encargado del tratamiento en un contrato específico. Explican por qué un comprador no puede dejar la localización de los datos como una simple frase de marketing.
Para un cliente, las preguntas prácticas son sencillas. ¿Dónde se alojan las cargas de trabajo principales? ¿Dónde se almacenan las copias de seguridad? ¿Están cifradas y probadas las copias de seguridad? ¿Qué empleados, subcontratistas o proveedores pueden acceder a los sistemas desde fuera de Israel? ¿Se tratan los registros, los flujos de supervisión, los tickets de soporte o los sistemas de identidad en plataformas extranjeras? Si el cliente debe probar el manejo de datos israelíes, del EEE o específicos de un sector, ¿qué piezas contractuales y qué controles técnicos proporciona Global Cloud?
Las pruebas públicas de Global Cloud respaldan el tema de la soberanía y la localización de los datos porque la empresa tiene una huella de red y de oficina israelí y vende servicios adyacentes a la nube. No respaldan una declaración de conformidad global.
El catálogo de servicios es lo bastante amplio como para crear una dependencia de cliente seria
Lapágina de cloud en inglésde Global Cloud no se limita a una simple propuesta de alojamiento web. Describe servicios de centro de datos y cloud, la integración entre los sistemas empresariales y los terminales, la supervisión y el mantenimiento continuos, la virtualización en plataformas de tipo VMware y KVM/XEN/Hyper-V, una conexión a Internet segura, almacenamiento seguro, DaaS, PaaS, Infraestructura como Servicio, un servicio de colaboración, IT as a Service y Software as a Service. Lapágina de alojamiento en inglésrepite el tema del centro de datos y cloud y enumera alojamiento, DaaS y servicios de telefonía. Lapágina acerca deindica en hebreo que Global Cloud Ltd fue fundada en 2013 y posiciona a la empresa en torno a un servicio personalizado por expertos locales.
Estas afirmaciones importan porque sitúan a Global Cloud en la capa de dependencia y no en la del nombre de dominio banalizado. Una empresa que utiliza DaaS depende del intermediario de sesión, de la identidad, del almacenamiento, del rendimiento de los terminales y del soporte. Una empresa que utiliza IaaS depende del cálculo, del almacenamiento, de la red, de la gestión de imágenes y de la recuperación. Una empresa que utiliza servicios de colaboración o de telefonía depende de la disponibilidad, de los flujos de llamadas, de los directorios, del aprovisionamiento de usuarios y de la exportación de configuración.
Una empresa que utiliza software gestionado depende de los parches, de las copias de seguridad, del control de acceso y de la aprobación de cambios.
La huella de red pública puede soportar dichos servicios, pero no revela su profundidad instalada. Cuatro /24 visibles pueden soportar una plataforma regional significativa, en particular para un proveedor israelí orientado. También pueden ocultar un dominio mucho más reducido si los servicios se prestan a través de plataformas de terceros o de capacidad alquilada.
Las afirmaciones del sitio web en materia de seguridad, capacidad de supervivencia y soporte 24/7 deben convertirse en compromisos mensurables: canales de soporte, tiempos de respuesta, notificación de incidentes, frecuencia de las copias de seguridad, tiempo de restauración, punto de restauración, exportación de datos, conmutación por error del lado del cliente y asistencia a la rescisión.
Una tensión práctica en las pruebas del sitio web se refiere a los horarios de soporte. La cabecera de la página de inicio en inglés indica horarios de oficina de domingo a jueves, de 09:00 a 18:00, con cierre los viernes y sábados. La página de cloud indica que el equipo de soporte trabaja 24/7. Puede haber una explicación sencilla: los horarios de la oficina comercial difieren de la cobertura del soporte técnico. El comprador debe explicitar esta distinción en el contrato. ¿Qué está asegurado 24/7? ¿Qué está en guardia localizada? ¿Qué nivel de gravedad obtiene una respuesta inmediata?
¿Qué vía de contacto funciona durante una avería de red? ¿Está alojado el portal de soporte fuera del entorno afectado? ¿Quién puede aprobar cambios de emergencia fuera del horario normal de oficina?
El catálogo de servicios crea también una dependencia en materia de licencias y de plataforma. La página de cloud hace referencia al soporte de infraestructura de tipo VMware, XEN y Microsoft. Un cliente debe preguntar si su servicio es dedicado, multiinquilino o subcontratado; si las licencias de plataforma están incluidas; si las instantáneas son portables; si las imágenes de máquina virtual pueden exportarse en formatos estándar; y si los datos de identidad, de telefonía o de colaboración pueden migrarse sin un largo proyecto manual.
La lección central para el riesgo del cliente es que las pruebas públicas de Global Cloud son lo bastante creíbles como para tomarlas en serio, pero también lo bastante amplias como para que el comprador no deba aceptar una única garantía genérica de «cloud». Cada servicio del catálogo tiene un modo de fallo diferente.
La capacidad instalada y la capacidad utilizable pueden divergir rápidamente
Los compradores de cloud confunden a menudo la capacidad instalada con la capacidad utilizable. La capacidad instalada es lo que un proveedor ha construido, alquilado o configurado en condiciones normales. La capacidad utilizable es la que sigue disponible cuando algo falla, cuando un cliente crece, cuando un proveedor cambia sus condiciones o cuando una migración debe hacerse bajo presión. La huella visible de Global Cloud es lo bastante grande para un verdadero servicio alojado y lo bastante pequeña como para que los clientes pregunten cuánto margen de reserva existe detrás.
El /22 contiene 1.024 direcciones IPv4. La IPv4 pública es escasa y el control de un /22 es valioso para un proveedor de alojamiento regional. Pero el número de direcciones no equivale al número de cálculos. Si algunas direcciones se utilizan para infraestructura, acceso de cliente estático, NAT, gestión, correo electrónico, VPN, pasarelas de escritorio o equipos de red, el conjunto de direcciones públicas disponibles para nuevos servicios alojados puede ser menor de lo que sugiere el número bruto. Si algunos servicios se direccionan en privado detrás de pasarelas, el conjunto de direcciones públicas puede subestimar la capacidad de cálculo.
El BGP público por sí solo no puede resolver esto.
Las etiquetas de subred más específicas añaden preguntas.SHVDOM-Core-Subnetparece una infraestructura central;LNS-Static-Subentsugiere una función de acceso estático o de abonado;SHVDOM-SubnetySHVDOM-1-Subnetsugieren una segmentación específica del servicio. No son más que etiquetas de registro, pero deberían llevar al comprador a cartografiar el servicio adquirido con la dependencia real. ¿Se sirve a un cliente DaaS desde una granja de escritorios en un /24? ¿Está vinculada una función de acceso estático o LNS a la conectividad del cliente? ¿Están separadas la gestión cloud y las cargas de trabajo de los clientes? ¿Son visibles o privadas las redes de copia de seguridad?
La capacidad utilizable depende también del stock de hardware. Si un servidor falla, ¿puede Global Cloud reemplazarlo localmente o la reparación depende del stock del proveedor y de los plazos de importación? Si un enrutador o un cortafuegos falla, ¿hay un equipo de repuesto en el sitio con una configuración actualizada? Si un estante de almacenamiento se degrada, ¿hay margen suficiente para reconstruir sin aplastar el rendimiento? Si un clúster de hipervisores pierde un nodo, ¿los hosts restantes están dimensionados para N+1 o solo para una carga media?
Ninguna de estas preguntas encuentra respuesta en los registros RIPE o en las afirmaciones del sitio web. Precisamente por eso deben formularse. Los registros públicos prueban la existencia de un operador real y una conectividad actual. El contrato debe probar la capacidad de servicio y la capacidad de recuperación.
Los racks, los proveedores de tránsito, el hardware, el soporte y la facturación son los verdaderos caminos de fallo
El principal camino de fallo de este expediente no es teórico. Para Global Cloud, los caminos de fallo público más plausibles son una interrupción de rack o de instalación, un problema de proveedor de tránsito o de filtro de ruta, una escasez de hardware, un fallo de escalado de soporte, un litigio de facturación o de contrato de proveedor y límites de migración.
Un fallo de rack o de instalación pondría a prueba el acceso físico. Si la capacidad cloud de Global Cloud está concentrada en una sola sala o en un solo proveedor de centro de datos, un problema de alimentación, de refrigeración, de fibra, de control de acceso o de teleoperación podría convertirse en una interrupción del servicio. El sitio web de la empresa reivindica seguridad y capacidad de supervivencia, y su contenido cloud en hebreo reivindica varios centros de datos geográficamente separados y opciones de recuperación ante desastres. Los registros públicos no verifican el número, la identidad o la independencia de esos sitios.
Un cliente debe solicitar una lista de sitios bajo confidencialidad si es necesario, pero la respuesta debe indicar si los sistemas primarios, de copia de seguridad y de gestión comparten un mismo dominio de fallo.
Un fallo de proveedor de tránsito pondría a prueba la dependencia de AS1680 y AS212616. Los registros públicos de vecinos y de consistencia muestran dos pares observados, con AS8551 en la política pero no visible en BGP en el momento de la consulta. Un cliente debe preguntar si cada /24 enrutado tiene al menos dos caminos activos, si esos caminos entran por enrutadores y edificios diferentes, si todos los caminos están dimensionados para la conmutación por error y si la mitigación de DDoS depende de un solo operador. La respuesta debe ser un diseño de red actual, no solo un objeto de registro.
Una escasez de stock de hardware pondría a prueba la economía subyacente al servicio. Los proveedores de pequeño tamaño pueden ofrecer un excelente servicio con piezas de repuesto locales prudentes y una cobertura clara del proveedor. También pueden tener dificultades si un disco, una fuente de alimentación, un módulo de enrutador o una carcasa de cortafuegos defectuoso debe adquirirse después del incidente.
El cliente debe solicitar objetivos de reemplazo por tipo de servicio: host virtual, servidor dedicado, estante de almacenamiento, conmutador de parte superior de rack, enrutador de periferia, cortafuegos, dispositivo de copia de seguridad y equipo de sitio de cliente si procede.
Un fallo de soporte pondría a prueba la diferencia entre la expresión 24/7 y el escalado real. La reivindicación de soporte 24/7 en el sitio web es útil, pero los clientes deben definir los niveles de gravedad, los canales de ticket, el escalado telefónico, la cobertura lingüística, la autoridad fuera del horario laboral y las comunicaciones de incidentes. Si el sitio de soporte o el correo electrónico dependen de la misma red del proveedor, el cliente debe conocer la vía fuera de banda.
Un fallo de facturación o de contrato de proveedor es menos dramático que un corte de electricidad, pero puede ser igual de perturbador. Dado que Global Cloud es un LIR y posee su propio espacio de direccionamiento, la dependencia de los recursos de direccionamiento parece más controlada que en el caso de los proveedores que anuncian bloques alquilados. Sin embargo, el tránsito aguas arriba, las licencias de software, los alquileres de centros de datos, los servicios de copia de seguridad y los servicios de tipo Microsoft pueden crear dependencias contractuales.
Los clientes deben preguntar qué preaviso se aplica antes de que los cambios de precios, de direcciones IP, de plataforma o de proveedor les afecten.
Un fallo de migración es el riesgo más silencioso. Si un cliente desea irse, ¿puede exportar las imágenes de máquina virtual, los perfiles de escritorio, los datos de correo electrónico, las bases de datos de software, la configuración telefónica, la política de cortafuegos, las zonas DNS, los registros y las copias de seguridad en formatos utilizables? ¿Ofrece Global Cloud una ventana de solapamiento de pago? ¿Se pueden mover las direcciones IP del cliente o solo los nombres DNS? El momento adecuado para responder a estas preguntas es antes de que el servicio se vuelva crítico.
Quiénes se ven afectados cuando este tipo de proveedor falla
Los usuarios afectados probablemente no son clientes hiperescalares abstractos. El sitio web de Global Cloud se dirige a empresas que necesitan integración, escritorios virtuales, sistemas de software, telefonía, colaboración, alojamiento e informática gestionada. Esto apunta a organizaciones de tamaño pequeño y mediano, centros de llamadas, equipos de desarrollo, minoristas, gabinetes de servicios profesionales y empresas locales que pueden no querer explotar su propia infraestructura. Para estos clientes, el proveedor no es solo un vendedor.
Puede ser el lugar donde los empleados se conectan cada mañana, donde se ejecutan las aplicaciones, donde reposan las copias de seguridad o donde las herramientas de telefonía y colaboración dependen de la identidad y del acceso a la red.
El impacto operativo de un fallo depende, por tanto, del servicio. Un cliente de alojamiento web puede sufrir una indisponibilidad pública y cambios de DNS. Un cliente DaaS puede perder las sesiones de trabajo de los empleados. Un cliente de aplicación gestionada puede perder la continuidad de los procesos de negocio. Un cliente de telefonía puede perder el enrutamiento de llamadas. Un cliente IaaS puede tener que enfrentarse a la recuperación del servidor, a la coherencia del almacenamiento y a la reconstrucción del cortafuegos. Un cliente de servicio de software puede encontrarse con cuestiones de exportación de datos y de licencias.
Por eso el amplio catálogo de servicios de Global Cloud aumenta la carga de la diligencia debida. Un proveedor que vende únicamente alojamiento web estático puede evaluarse con un solo conjunto de verificaciones. Un proveedor que vende servicios de centro de datos, cloud, escritorio, plataforma, software, colaboración e informática requiere un mapa de riesgos por servicio. La misma periferia AS61365 puede ser pertinente para varios productos, pero cada producto tiene exigencias diferentes en materia de estado, recuperación y migración.
El impacto difiere también según la sensibilidad de los datos. Un cliente que maneja expedientes de empleados, información relacionada con la salud, registros financieros o datos personales europeos tiene más que verificar que un cliente que gestiona un sitio web escaparate público. Los documentos oficiales israelíes sobre privacidad citados más arriba indican claramente que la seguridad de las bases de datos y el tratamiento transfronterizo de datos son temas regulados.
El comprador debe exigir un desglose escrito de las responsabilidades: qué parte actúa como responsable del tratamiento o como encargado, quién gestiona el acceso, cómo se protegen las copias de seguridad, cómo se notifican los incidentes y adónde se transfieren los datos.
Global Cloud puede ser un proveedor regional práctico para los clientes que desean un soporte local y un enrutamiento israelí. Las pruebas públicas respaldan esta posibilidad. No eliminan la necesidad de probar los caminos de fallo antes de que el proveedor se convierta en un punto único de continuidad del negocio.
Qué mejoraría el nivel de evidencia
Las pruebas públicas actuales merecen un nivel medio porque la capa de recursos de red es sólida mientras que la capa de capacidad de servicio está subdocumentada. El nivel mejoraría si Global Cloud publicara o proporcionara varios tipos de pruebas operativas verificables.
En primer lugar, podría proporcionar un resumen actual de las instalaciones y de las plataformas. Esto no requiere exponer planos de planta sensibles. Debería identificar los sitios principales y secundarios, si los sitios son propios o en colocación, si son independientes geográficamente y en términos de dominio de alimentación, qué servicios se ejecutan dónde y cómo se separan las copias de seguridad. Las alegaciones del sitio web sobre varios centros de datos y la recuperación ante desastres serían mucho más convincentes si vinieran acompañadas de los roles actuales de los sitios y de los tipos de servicios.
En segundo lugar, podría proporcionar un resumen actual del enrutamiento y del tránsito. AS1680 y AS212616 son visibles en BGP; AS8551 figura en la política. El proveedor podría decir cuáles están activos, en reserva o son históricos; si cada /24 tiene diversidad de rutas activas; si se prueba la conmutación por error; y qué deben esperar los clientes durante el mantenimiento. También podría publicar un perfil PeeringDB. Unaconsulta a la API PeeringDB para el ASN 61365devolvió una respuesta 404 de entidad no encontrada en el momento de la investigación, lo que significa que no había disponible ningún perfil de red PeeringDB público a través de esa consulta API. PeeringDB es voluntario, por lo que la ausencia no es una prueba de inexistencia. Sigue siendo una oportunidad perdida de divulgación para la información de interconexión, de instalación y de contacto.
En tercer lugar, podría documentar los objetivos de copia de seguridad y de restauración para cada producto. DaaS, IaaS, alojamiento, software y telefonía no deberían compartir una única promesa genérica de copia de seguridad. Cada uno debería tener una fecha de última restauración probada, un objetivo de tiempo de recuperación, un objetivo de punto de recuperación, exclusiones y responsabilidades del cliente. Si la restauración depende de opciones de copia de seguridad adquiridas por el cliente, eso debe quedar claro.
En cuarto lugar, podría documentar los derechos de migración. La confianza en un servicio alojado mejora cuando los clientes saben cómo pueden irse. Los formatos de exportación, las ventanas de transición de DNS e IP, la portabilidad de las imágenes, las extracciones de bases de datos, las exportaciones de perfiles, las exportaciones de correo electrónico, las exportaciones de configuración telefónica y la retención de registros deben quedar claros antes de un litigio o de una avería.
En quinto lugar, podría limpiar y alinear el lenguaje de los servicios públicos. La página de servicios en inglés es utilizable, pero la mezcla de formulaciones Global Cloud y Xpress Technologies, los problemas de ortografía y el contenido parcialmente traducido hacen más difícil para terceros saber qué afirmaciones son actuales. Un catálogo de servicios más limpio no probaría la resiliencia, pero reduciría la ambigüedad.
Estas mejoras no son cosméticas. Transformarían una huella enrutada creíble en una dependencia de cliente más verificable.
Las preguntas prácticas del comprador
Un cliente que se plantea Global Cloud debe comenzar por los hechos que ya son buenos. Preguntar a la empresa que confirme que AS61365 y 185.184.16.0/22 son la periferia de producción actual para el servicio adquirido. Preguntar cuáles de 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 y 185.184.19.0/24 se utilizan para el servicio. Preguntar si las ROA RPKI siguen siendo válidas y quién aprueba los cambios de ruta. Preguntar si el estado de los objetos de ruta y del IRR es suficiente para todos los filtros de los proveedores de tránsito.
A continuación, formular las preguntas físicas. ¿Dónde se aloja el servicio principal? ¿El rack, la jaula o la sala de datos es propia, alquilada o subcontratada? ¿Qué fuentes de alimentación, SAI, grupos electrógenos, sistemas de refrigeración y procesos de teleoperación están implicados? ¿Qué piezas de repuesto hay en el sitio? ¿Quién puede entrar fuera del horario laboral? ¿Qué servicios comparten el mismo edificio y cuáles están separados?
A continuación, formular las preguntas de red. ¿Qué proveedores de tránsito transportan el tráfico de producción hoy? ¿Cuáles están en reserva? ¿Pueden AS1680 o AS212616 soportar independientemente la plena carga? ¿Cuál es el papel actual de AS8551? ¿Hay enrutadores e interconexiones separados? ¿Los controles anti-DDoS son específicos de un operador? ¿Se revisan por pares y se prueban los cambios BGP?
A continuación, formular las preguntas de soporte. ¿Qué significa 24/7 en la práctica? ¿Cubre el soporte telefónico, la respuesta de los ingenieros, la supervisión, los cambios de emergencia y las comunicaciones con los clientes? ¿Qué ocurre el viernes o el sábado cuando la línea telefónica pública del horario de oficina indica cierre? ¿Cuál es la vía de contacto fuera de banda si la red del proveedor falla?
A continuación, formular las preguntas de datos. ¿Dónde se encuentran los datos primarios, las copias de seguridad, los registros y los datos de los tickets de soporte? ¿Qué plataformas tratan los datos de identidad, de correo electrónico, de supervisión o de colaboración? ¿Qué regulaciones debe satisfacer el cliente y qué pruebas puede proporcionar Global Cloud? ¿Cómo se cifran, restauran y eliminan las copias de seguridad?
Por último, formular las preguntas de salida. ¿Cómo puede el cliente exportar los sistemas, los datos y la configuración? ¿Puede conservar las direcciones IP o debe renumerar? ¿Cuál es la duración de la ventana de solapamiento? ¿Qué asistencia está incluida? ¿Qué ocurre si la rescisión es consecuencia de un litigio de facturación, un incidente de servicio o un cambio de proveedor?
Estas preguntas no presuponen que Global Cloud sea débil. Presuponen que la capacidad alojada es física, contractual y operativa incluso cuando se vende como cloud.
La conclusión: red creíble, prueba de recuperabilidad incompleta
Global Cloud Ltd es más sustancial en los registros públicos de lo que sugeriría la hipótesis de una huella tenue del expediente. La empresa tiene un objeto de organización LIR RIPE, un AS activo, una asignación IPv4 clara, cuatro anuncios /24 actualmente visibles, una cobertura de origen de ruta RPKI válida, señales de localidad israelíes y un catálogo de servicios oficial en torno al cloud, alojamiento, escritorio, software, colaboración e informática gestionada. Esto basta para establecer un sujeto de infraestructura-empresa creíble.
La incertidumbre restante no recae en la existencia del nombre, sino en la cantidad de servicios recuperables que se esconden detrás de ese nombre. Los datos públicos no prueban el número de racks, de sitios, de servidores, de sistemas de almacenamiento, de ingenieros de soporte, de pruebas de conmutación por error o de cargas de trabajo de clientes. No prueban si el amplio catálogo de servicios se presta desde una infraestructura propiedad de Global Cloud, una infraestructura en colocación, plataformas asociadas o una mezcla. No prueban si un cliente puede migrar limpiamente en situación de estrés.
Por eso el título del artículo es intencionadamente físico. Global Cloud vende capacidad alojada, pero el valor de esa capacidad depende aún de los racks, del tránsito y de las ventanas de reparación. AS61365 puede ser visible mientras un cliente sufre aún un problema de restauración. Un /22 puede estar bien registrado mientras un comprador necesita aún una prueba de hardware de repuesto. Una ROA válida puede proteger la validación del origen mientras un incidente del proveedor de tránsito pone a prueba la conmutación por error. Una reivindicación de soporte 24/7 puede ser cierta mientras el cliente necesita aún detalles sobre el escalado.
El nivel de evidencia debe permanecer Medio hasta que Global Cloud o sus clientes puedan verificar la independencia de las instalaciones, la conmutación por error de las rutas, el escalado del soporte, la restauración de las copias de seguridad y los derechos de migración. La capa de red pública es real y está relativamente bien documentada. La capa de resiliencia de los servicios sigue siendo una tarea de diligencia debida.