Résumé

  • Les registres administratifs, la visibilité BGP, le DNS, le TLS, le HTTP et l’activité client mesurent des couches distinctes et ne peuvent pas être fusionnés en une seule preuve.
  • Les sources publiques identifiées permettent de construire un protocole de vérification, mais les éléments disponibles ne contiennent pas les valeurs actuelles nécessaires pour établir le routage, la disponibilité du site ou la fourniture effective de ressources cloud.

L’enquête sur un opérateur cloud commence souvent par deux identifiants : un nom de domaine et un numéro de système autonome. Dans ce cas, almazcloud.network et AS210328 semblent constituer le point de départ naturel. Mais leur juxtaposition ne prouve pas, à elle seule, qu’une même organisation contrôle le domaine, annonce des préfixes, exploite les serveurs auxquels le domaine mène et fournit effectivement des ressources à des clients.

La question utile n’est donc pas : « Existe-t-il une trace publique ? » Elle est plus exigeante : « Quelle proposition précise cette trace permet-elle de vérifier, à quelle date, avec quelle méthode et dans quelles limites ? »

Une identité administrative n’est pas une preuve d’exploitation

Le registre RIPE Database constitue le premier niveau de l’examen. L’objet aut-num associé à AS210328 peut, en principe, exposer un nom enregistré, une organisation de référence, des contacts, des attributs de politique de routage ainsi que des dates de création ou de modification. La recherche d’objets route et route6 peut ensuite montrer quelles assertions administratives associent des préfixes à cet ASN. Ces éléments sont importants, mais ils décrivent des enregistrements et des assertions de gestion, non nécessairement un trafic actuellement observable.

Les services RIPEstat, BGPView, bgp.tools et le BGP Toolkit de Hurricane Electric ont des fonctions complémentaires. Ils peuvent fournir des vues sur l’annonce de l’ASN, les préfixes, les voisins, les fournisseurs de transit, les dates de première ou dernière observation et la portée apparente des routes. Une comparaison entre ces sources doit cependant conserver les fenêtres d’observation et les ensembles de collecteurs. Une divergence peut venir du cache, du moment de la requête ou de la couverture des sondes ; elle ne constitue pas automatiquement une contradiction substantielle.

La distinction est essentielle : un objet de route peut rester enregistré alors qu’aucun préfixe correspondant n’est visible dans les collecteurs examinés. À l’inverse, une annonce BGP observée ne prouve pas que le détenteur de l’ASN fournit un service cloud à des clients. Elle établit seulement une visibilité de routage bornée par des préfixes, des collecteurs et une période.

Le domaine ajoute une autre chaîne de vérification

Le RDAP du domaine devrait permettre d’examiner la création, les mises à jour, l’expiration, les statuts, le registrar et les serveurs de noms d’almazcloud.network. Les requêtes A, AAAA et NS auprès de Google Public DNS peuvent montrer les réponses visibles par ce résolveur, avec leurs éventuelles adresses, leurs TTL et leur état de délégation. DNSViz peut compléter cette image en examinant la cohérence de la délégation et, le cas échéant, DNSSEC.

Même une délégation maintenue ou une adresse IP résolue ne suffirait pas à démontrer un service cloud opérationnel. Un domaine peut être enregistré sans site fonctionnel. Une adresse peut appartenir à un hébergeur tiers, à un CDN, à un reverse proxy ou à une infrastructure qui ne correspond pas directement à AS210328. La résolution DNS doit donc être rapprochée des préfixes réellement observés, sans supposer que le nom de domaine révèle à lui seul le lieu ou le propriétaire de l’infrastructure.

Le niveau TLS mesure encore autre chose. Les journaux de Certificate Transparency peuvent montrer des certificats émis pour le domaine ou ses sous-domaines. Un test SSL Labs pourrait documenter une poignée de main TLS, une chaîne de certificats, des protocoles pris en charge, une adresse d’extrémité et une date de scan. Mais l’émission d’un certificat n’est pas la preuve qu’un hôte répond actuellement ; un certificat peut être renouvelé automatiquement ou rester enregistré après l’arrêt d’un service.

Le site web ne prouve pas la fourniture de ressources

Une réponse HTTPS, une page de présentation, des tarifs ou un formulaire d’inscription constitueraient des indices plus directs d’une surface destinée aux clients. Les scans urlscan.io, les archives de l’Internet Archive et un rapport Netcraft pourraient ajouter des dates, des adresses, des statuts HTTP, des titres de pages, des technologies ou des captures historiques.

Mais une page marketing reste une déclaration de première partie. Elle ne démontre pas qu’un utilisateur peut créer une machine virtuelle, obtenir un volume de stockage, recevoir des identifiants, payer, ouvrir un ticket, renouveler une ressource ou récupérer ses données. Pour établir l’exploitation cloud, il faudrait une procédure reproductible : inscription, authentification, provisionnement, ressource utilisable, fonctionnement dans le temps, cycle de facturation ou de support, puis éventuellement un lien contemporain avec le routage observé.

Les éléments disponibles pour cette enquête ne contiennent pas de réponse HTTP actuelle, de chaîne de redirection, de poignée de main TLS, de résultat DNS, de préfixe observé, de réponse RDAP ou de preuve indépendante de provisionnement client. Cette absence est une limite de l’observation, pas une preuve d’inactivité, de panne, de non-routage ou de non-existence.

Le mécanisme qui relie les couches

La chaîne causale complète ressemble à ceci : une organisation maintient une identité administrative ; elle obtient ou contrôle des ressources réseau ; des routes correspondantes sont annoncées et visibles ; le DNS dirige des noms vers des points d’accès ; TLS et HTTP rendent ces points accessibles ; enfin, une chaîne commerciale et technique permet à un client d’obtenir une ressource utilisable.

Chaque transition peut échouer ou être assurée par un tiers. Un registre peut être exact tandis que le routage est absent. Un ASN peut annoncer des préfixes tandis que le domaine utilise une plateforme extérieure. Un site peut répondre tandis qu’aucun provisionnement n’est disponible. Une plateforme peut fournir des ressources tandis que le frontend commercial est hébergé ailleurs. C’est pourquoi l’article ne doit pas transformer une succession de traces plausibles en récit certain d’intégration verticale.

Le résultat défendable, avec les pièces disponibles, est plus limité : vingt-deux sources publiques candidates couvrent les registres, le routage, le DNS, le TLS, le HTTP, les archives et la présence de première partie ; elles définissent un protocole d’examen pertinent ; mais elles n’établissent pas les valeurs actuelles nécessaires pour conclure sur l’exploitation effective d’almazcloud.network ou d’AS210328.

Ce qui changerait l’évaluation

Des champs bruts RIPE ou RDAP, avec leur provenance et leur horodatage, préciseraient uniquement le lien administratif. Des observations BGP répétées depuis plusieurs points de vue, avec préfixes et intervalles, renforceraient ou affaibliraient l’évaluation du routage. Des réponses A, AAAA et NS actuelles, un test TLS et une capture HTTP datée permettraient d’évaluer la présence des endpoints.

Enfin, un parcours reproductible de création de compte et de provisionnement, accompagné d’éléments attestant l’usage de la ressource et d’un lien contemporain avec le réseau, serait nécessaire pour parler avec davantage d’assurance d’une activité cloud destinée aux clients.

La discipline analytique importe ici davantage qu’une conclusion spectaculaire. Lorsque les valeurs ne sont pas disponibles, le bon résultat n’est ni « opérationnel » ni « inexistant », mais une carte précise de ce qui reste à mesurer.

Sources et limites

Les sources ci-dessous ont été identifiées comme points de vérification publics. Les éléments conservés pour cette enquête ne reproduisent pas leurs réponses actuelles et ne doivent donc pas être présentés comme des résultats observés.