Resumen

  • La existencia de un registro administrativo, un ASN, una delegación DNS o una página web no demuestra por sí sola que exista un servicio cloud operativo para clientes.
  • La investigación identificó 22 fuentes públicas que podrían comprobar distintas capas, pero los artefactos disponibles no contienen valores actuales de respuestas, observaciones BGP, handshakes TLS, respuestas HTTP ni pruebas de aprovisionamiento.

La pregunta correcta no es si existe una etiqueta

La pregunta relevante es si puede seguirse una cadena verificable desde una identidad administrativa hasta una operación que entregue recursos utilizables a clientes. Esa cadena tendría, como mínimo, cuatro eslabones: quién aparece asociado con el recurso, si el recurso es visible en Internet, si los puntos finales responden de forma coherente y si una persona externa puede contratar, aprovisionar y utilizar un recurso cloud.

Para almazcloud.network y AS210328, el expediente de investigación no permite completar esa cadena. No establece que el servicio esté inactivo, que el ASN no anuncie rutas, que el dominio no resuelva o que no haya clientes. Establece algo más limitado: las fuentes candidatas han sido identificadas, pero sus valores actuales no están disponibles en los artefactos examinados.

Identidad administrativa: una capa necesaria, no suficiente

El objeto aut-num de RIPE para AS210328 sería el punto de partida para comprobar nombre registrado, organización, contactos, política de encaminamiento y fechas de creación o modificación. La consulta de objetos route y route6 permitiría revisar las afirmaciones administrativas sobre prefijos asociados al ASN. RIPEstat, BGPView, bgp.tools y el BGP Toolkit de Hurricane Electric ofrecen rutas alternativas para contrastar nombre, prefijos, visibilidad y relaciones de red. Las consultas relevantes están disponibles en RIPE Database, objetos route y route6, RIPEstat AS Overview, prefijos anunciados, estado de encaminamiento, historial de rutas, BGPView, sus prefijos, bgp.tools y Hurricane Electric.

Pero un objeto administrativo no equivale a una observación de tráfico. Puede existir un registro actualizado sin anuncios visibles en los colectores examinados. También puede existir una ruta observada que no pruebe quién presta capacidad a un cliente concreto. Por eso la fecha, el colector, el prefijo y el intervalo de observación importan tanto como el nombre del titular.

Ruta observada: visibilidad acotada

Una afirmación sólida sobre AS210328 tendría que especificar qué prefijo fue observado, por qué colector, en qué momento y durante cuánto tiempo. Una sola instantánea no demostraría continuidad. Del mismo modo, una ausencia en una fuente concreta no demostraría que nunca hubo un anuncio: puede haber diferencias de cobertura, caché, filtros o ventanas temporales.

La comparación entre RIPEstat y agregadores externos podría fortalecer o debilitar la hipótesis de una presencia operativa. La coincidencia entre varias fuentes y varios momentos sería más informativa que una etiqueta aislada. Aun así, la visibilidad BGP demostraría una propiedad de encaminamiento, no la existencia de máquinas virtuales, almacenamiento, soporte, facturación o clientes.

DNS, TLS y HTTP: el punto final tampoco es el producto

El dominio introduce otra cadena de pruebas. RDAP puede aportar fechas de registro, renovación, estados y servidores de nombres. Las consultas de RDAP, A, AAAA y NS permitirían observar la delegación y las direcciones devueltas por un resolver concreto. DNSViz ofrece otra vista sobre delegación y DNSSEC en su análisis público.

La emisión de certificados añade una señal distinta. crt.sh puede mostrar nombres y periodos de certificados registrados en Certificate Transparency, mientras que SSL Labs podría aportar una prueba contemporánea de handshake, cadena de certificados y configuración del endpoint. Ninguna de las dos cosas demuestra por sí sola que el servicio acepte clientes o aprovisione capacidad.

La página de almazcloud.network podría contener descripciones, precios, términos, identidad legal, contactos o controles de registro. urlscan.io, el índice de Internet Archive y Netcraft podrían aportar observaciones históricas o independientes. Sin embargo, una página de marketing puede permanecer publicada cuando el aprovisionamiento está suspendido, y un frontend alojado en otra red no probaría ni refutaría la operación del backend.

La prueba decisiva: una operación reproducible

La afirmación más fuerte —que existe un servicio cloud operativo— exige más que una página accesible. Haría falta un flujo reproducible: registro o contratación, autenticación, aprovisionamiento de un recurso, acceso funcional, evidencia de ciclo de vida y, cuando sea material, relación temporal con la red o infraestructura examinada. También importan los límites: región, tipo de recurso, capacidad, condiciones de pago y duración de la disponibilidad.

Nada de eso aparece demostrado en los artefactos revisados. Tampoco aparece demostrado lo contrario. El resultado correcto es una frontera de incertidumbre: se conocen las pruebas que deberían ejecutarse, pero no se dispone de sus resultados actuales.

Qué sí puede decirse

El expediente identifica 22 fuentes públicas distribuidas entre registros de Internet, encaminamiento, DNS, TLS, HTTP, archivos y material de primera parte. Los artefactos de fuente conservan las URL y la procedencia de esas candidatas. No exponen valores actuales de registro, respuestas DNS, observaciones de rutas, handshakes TLS, respuestas HTTP ni pruebas de clientes.

Por tanto, no es defendible presentar como hechos actuales que AS210328 anuncia determinados prefijos, que almazcloud.network resuelve a una dirección concreta, que el certificado está vigente, que la web está disponible o que AlmazCloud aprovisiona recursos cloud. El lenguaje preciso debe distinguir “fuente identificada para comprobar” de “hecho observado”.

Qué cambiaría la evaluación

Cuatro tipos de evidencia modificarían por separado la conclusión:

  1. Registros RIPE o RDAP actuales, con valores y fechas, actualizarían la evaluación de identidad administrativa.
  2. Observaciones BGP repetidas desde varios colectores actualizarían la evaluación de visibilidad de rutas.
  3. Respuestas A, AAAA y NS, handshakes TLS y capturas HTTP contemporáneas actualizarían la evaluación de presencia de endpoints.
  4. Un flujo reproducible de contratación y aprovisionamiento, con recursos utilizables y relación de red contemporánea, actualizaría la evaluación de operación cloud.

La disciplina importante es no convertir una señal de una capa en una conclusión sobre otra. Un dominio registrado no es una ruta; una ruta no es un producto; una página no es una cuenta con recursos; y una cuenta no prueba por sí sola la continuidad futura.

Fuentes públicas identificadas

Las fuentes candidatas preservadas para esta investigación son: RIPE Database aut-num, objetos route y route6, RIPEstat AS Overview, prefijos anunciados, estado de encaminamiento, historial de rutas, BGPView, prefijos de BGPView, bgp.tools, Hurricane Electric, PeeringDB, RDAP, DNS A, DNS AAAA, DNS NS, DNSViz, crt.sh, SSL Labs, sitio de almazcloud.network, urlscan.io, Internet Archive y Netcraft.