Résumé

  • Les sources publiques identifiées couvrent l’enregistrement de l’ASN, les objets de routage, les observations BGP, le DNS, les certificats et les archives web, mais elles ne constituent pas encore une mesure actuelle et synchronisée de l’exploitation.
  • Le lien entre une identité enregistrée, un réseau observable, des points d’accès techniques et une offre cloud destinée à des clients doit être établi par des observations distinctes et datées.

Une enquête sur un fournisseur cloud ne peut pas commencer ni s’achever avec un seul registre. Le nom d’une organisation dans un objet aut-num n’est pas une preuve de trafic. Un ASN visible dans un agrégateur BGP n’est pas, à lui seul, la preuve d’un catalogue de machines virtuelles. Un certificat pour un sous-domaine ne démontre pas qu’une console est active. Même une page web accessible ne suffirait pas à établir qu’un client peut obtenir, utiliser et maintenir une ressource informatique.

Pour almazcloud.network et AS210328, les éléments réunis dans cette enquête permettent surtout de dessiner une méthode de vérification. Ils identifient les endroits où la chaîne opérationnelle pourrait être observée : registre Internet, objets IRR, annonces de préfixes, voisinage BGP, délégation DNS, adresses IPv4 et IPv6, DNSSEC, certificats, services HTTP, archives et traces publiques. Ils ne fournissent pas les réponses actuelles de ces systèmes. Cette différence est essentielle : une source candidate n’est pas une observation positive, et une observation non obtenue n’est pas un résultat négatif.

Quatre propositions différentes

La première proposition est administrative : une organisation, un contact ou un mainteneur est associé à AS210328 ou au domaine. Le point de départ approprié est l’objet aut-num de la RIPE NCC, qui pourrait indiquer le nom du réseau, son statut, une organisation, des mainteneurs et des dates de création ou de modification (objet aut-num RIPE). Les objets d’organisation, de personne et de rôle liés à cet enregistrement pourraient préciser la responsabilité administrative. Mais une fiche tenue dans un registre décrit d’abord une déclaration de gestion de ressources. Elle ne prouve pas que le réseau est actuellement annoncé ni qu’il fournit un service commercial.

La deuxième proposition est liée au routage : des préfixes sont-ils effectivement observés avec AS210328 comme origine ? Les objets route et route6 de la RIPE peuvent montrer les déclarations IRR associées à l’ASN (objets route et route6). Les données RIPEstat peuvent ensuite donner une vue d’ensemble de l’état observé de l’ASN (vue d’ensemble RIPEstat), une liste de préfixes annoncés (préfixes annoncés), un historique de visibilité et d’espace annoncé (état du routage), ainsi que les systèmes autonomes observés à proximité dans les chemins BGP (voisins BGP).

Ces ensembles ne répondent pas exactement à la même question. Un objet IRR est une déclaration. Une annonce BGP est une observation faite depuis certains collecteurs. Un voisin dans un chemin ne constitue pas automatiquement la preuve d’une relation commerciale directe. Une absence dans un collecteur ne prouve pas l’absence mondiale d’un préfixe. La bonne analyse doit donc conserver la date, le point de vue et la méthode de chaque mesure.

Des agrégateurs indépendants pourraient compléter cette vérification. BGP.tools propose une vue de l’ASN, de ses préfixes, de ses relations et éventuellement de ses indicateurs de sécurité (profil BGP.tools). BGPView peut fournir une autre liste de préfixes associés (préfixes BGPView). CAIDA AS Rank peut contextualiser l’organisation inférée, le degré et les relations topologiques (fiche CAIDA). Cloudflare Radar offre une autre perspective sur la visibilité et les changements de routage (profil Cloudflare Radar). Ces systèmes peuvent diverger sans que l’un soit nécessairement faux : ils n’ont ni les mêmes collecteurs, ni les mêmes intervalles de mise à jour, ni les mêmes règles d’inférence.

PeeringDB occupe une place différente. Sa fiche pourrait contenir un nom de réseau fourni par l’opérateur, un site, un type de réseau, une politique de peering, des installations ou des points d’échange (fiche PeeringDB). Une mention d’almazcloud.network dans cette base renforcerait le lien entre le domaine et l’ASN comme élément déclaré par l’opérateur. Elle ne démontrerait toutefois pas, à elle seule, la disponibilité d’une plateforme cloud ni l’existence de clients actifs. Les répertoires volontaires décrivent une identité ou une intention opérationnelle ; ils ne remplacent pas la mesure du service.

Le domaine comme point de jonction — pas comme preuve finale

La troisième proposition concerne le domaine. Le RDAP de almazcloud.network peut fournir le registrar, les événements d’enregistrement et d’expiration, les statuts et les serveurs de noms (RDAP du domaine). Les requêtes DNS auprès de Google Public DNS peuvent montrer la délégation NS (requête NS), les réponses A et leurs éventuelles chaînes CNAME (requête A), la présence d’une réponse AAAA (requête AAAA) et certains éléments liés à DS et DNSSEC (requête DS). DNSViz pourrait fournir une analyse indépendante de la délégation, de la chaîne DNSSEC et des erreurs de configuration (analyse DNSViz).

Ces résultats seraient utiles pour reconstruire le chemin technique entre un nom et une adresse. Ils ne suffiraient pas encore à relier l’adresse à AS210328. Une adresse A peut être hébergée ailleurs, protégée par un CDN, répartie entre plusieurs réseaux ou utilisée uniquement pour un site institutionnel. Une adresse AAAA absente à l’apex ne dirait rien, à elle seule, sur d’éventuels sous-domaines ou réseaux de clients. Une délégation DNS fonctionnelle ne prouve pas qu’un plan de contrôle cloud, une API ou une infrastructure de calcul est disponible.

Le test le plus instructif serait une comparaison simultanée : réponses DNS datées, adresses observées, origine BGP des préfixes correspondants et comportement des points d’accès. Si l’adresse de almazcloud.network se trouvait dans un espace annoncé par AS210328 au même moment, cela soutiendrait une relation technique entre le domaine et l’ASN. Si elle se trouvait ailleurs, plusieurs explications resteraient possibles : hébergement web externalisé, CDN, séparation entre site public et infrastructure client, ou simple absence de lien opérationnel direct. Dans aucun cas une seule comparaison ne suffirait à prouver une offre cloud.

Les certificats révèlent des pistes de déploiement

La quatrième proposition est celle du déploiement. Les journaux Certificate Transparency peuvent révéler des certificats émis pour le domaine et ses sous-domaines, avec leurs noms alternatifs, leurs autorités et leurs périodes de validité (recherche Certificate Transparency). Censys pourrait fournir des observations complémentaires sur les certificats, les adresses, les ports et les dates de détection (recherche Censys). SSL Labs peut apporter des éléments sur la configuration TLS du domaine (analyse SSL Labs).

Les sous-domaines sont particulièrement importants pour une hypothèse cloud. Des noms comme api, console, auth, panel, storage ou region pourraient signaler une surface de produit. Mais un certificat ne prouve pas qu’un service est actuellement déployé, qu’il accepte des connexions ou qu’il sert des clients. Il prouve au mieux qu’un certificat a été demandé pour un nom à une date donnée. Il faut encore établir la résolution DNS, l’adresse, le port, la réponse TLS, le comportement HTTP et la fonction réellement exposée.

Les scans publics peuvent compléter la chronologie. URLScan peut contenir des recherches ou des captures liées au domaine (recherche URLScan). La Wayback Machine peut montrer des captures historiques de pages ou de ressources (index des archives web). AlienVault OTX et VirusTotal peuvent fournir des traces passives ou des relations observées autour du domaine (données passives OTX; fiche VirusTotal). Les recherches GitHub et grep.app peuvent révéler des références textuelles ou des fragments de configuration (recherche GitHub; recherche grep.app).

Ces sources sont des pistes, non des preuves homogènes. Une capture ancienne ne décrit pas l’état actuel. Une mention dans un dépôt peut être un exemple, un test ou une chaîne abandonnée. Une relation passive peut être issue d’un scan tiers et ne pas établir le contrôle de l’infrastructure. La valeur de ces traces dépend de leur date, de leur contenu brut, de leur contexte et de la possibilité de les reproduire sans confondre découverte et exploitation.

Ce qu’il faudrait pour établir la chaîne opérationnelle

Une démonstration convaincante de l’exploitation cloud devrait relier au moins cinq niveaux.

D’abord, une identité administrative : l’ASN, le domaine et les objets associés devraient présenter des liens cohérents, idéalement avec des dates et des mainteneurs comparables. Ensuite, une visibilité réseau : des préfixes devraient être observés comme annoncés par l’ASN, depuis plusieurs sources et à un moment défini. Troisièmement, une jonction technique : les adresses et les noms de domaine devraient être associés à ces préfixes, en tenant compte des CDN, du multi-hébergement et des changements de routage.

Quatrièmement, un déploiement accessible : DNS, TLS et HTTP devraient montrer des points d’accès entretenus, avec des fonctions identifiables. Enfin, un parcours client devrait être démontré — par exemple une documentation exploitable, une API, un portail, un mécanisme d’allocation de ressources ou une preuve indépendante d’utilisation.

Cette chaîne est causale. L’identité donne une responsabilité déclarée. Le routage rend une ressource joignable depuis certaines perspectives. Le DNS et les certificats relient des noms à des points d’accès. Le protocole applicatif expose une fonction. Le parcours client transforme cette fonction en service utilisable. Retirer un maillon ne prouve pas que l’opération n’existe pas ; cela limite seulement ce que les sources permettent d’affirmer.

Dans le dossier actuel, les réponses dynamiques n’ont pas été récupérées. Les valeurs courantes de l’enregistrement RIPE, des préfixes, des voisins BGP, du DNS, des certificats et du comportement HTTP ne doivent donc pas être présentées comme des faits observés. Le résultat n’est ni une preuve d’activité, ni une preuve d’inactivité. C’est une frontière de preuve : les bons tests sont identifiés, mais leurs résultats synchronisés manquent encore.

Cette limite est aussi une information opérationnelle. Pour un acheteur, un partenaire ou un analyste de risque, la question n’est pas seulement de savoir si un nom et un ASN existent. Il faut savoir quelle couche est effectivement démontrée, à quelle date, depuis quelle perspective et avec quelle possibilité de recours si le service disparaît. Un registre peut aider à attribuer une responsabilité administrative. Il ne garantit ni la capacité, ni la redondance, ni le support, ni la continuité d’une plateforme.

La prochaine étape devrait être une collecte coordonnée : horodatage UTC unique, réponses brutes conservées, hachage des artefacts, comparaison de plusieurs collecteurs BGP, résolution DNS depuis plusieurs points, vérification prudente des endpoints et séparation stricte entre les résultats positifs, les résultats négatifs et les tests non effectués. Sans cette discipline, l’apparence d’une chaîne d’infrastructure risque d’être prise pour la chaîne elle-même.