Résumé

  • Les sources conservées pour AS210328 et almazcloud.network décrivent des points de contrôle pertinents, mais leurs réponses actuelles n’ont pas été récupérées dans cette passe.
  • Cette absence de contenu horodaté ne prouve ni l’inactivité ni le fonctionnement : elle fixe seulement la limite de ce que l’enquête peut affirmer.

La question a changé

Les précédentes enquêtes consacrées à almazcloud.network et à AS210328 ont déjà établi une distinction essentielle : une ressource enregistrée n’est pas nécessairement une ressource exploitée. Un domaine, une zone DNS, un certificat ou une page web peuvent signaler une présence technique sans démontrer qu’un opérateur contrôle un réseau actif ou livre une capacité cloud à des clients.

L’enquête actuelle pousse cette distinction d’un cran. Elle cherche à savoir comment relier quatre couches qui sont souvent confondues : l’identité administrative du réseau, la visibilité du routage dans les collecteurs publics, la continuité des services DNS et web, puis la preuve directe d’une prestation cloud. Pour chacune, il faut une observation située dans le temps et attribuable à la bonne source. Une réponse absente n’est pas une réponse négative.

Le dossier associe almazcloud.network à AS210328 dans le cadre de la commission. Cette association constitue le sujet de l’enquête, et non un résultat indépendant de la présente collecte. Pour éviter de transformer le contexte en fait renouvelé, le rapport distingue explicitement ce qui provient de la commission, ce que les artefacts du runtime permettent de vérifier et ce qui demeure à récupérer.

Ce que les sources devraient permettre de tester

Le premier niveau est administratif. L’objet aut-num d’AS210328 dans la base de données du RIPE NCC pourrait documenter l’existence persistante d’un objet ASN, son nom, ses références organisationnelles, ses mainteneurs, son statut et ses dates de création ou de modification. Un tel objet établirait une identité de ressource enregistrée. Il ne suffirait pas à démontrer des annonces BGP actuelles, du trafic client ou une activité cloud. Consulter l’objet aut-num du RIPE NCC.

Le deuxième niveau est le routage observable. Les services RIPEstat peuvent indiquer si AS210328 est vu par les collecteurs RIS, quels préfixes lui sont attribués comme origine et quels autres systèmes autonomes apparaissent dans les chemins observés. La recherche inverse des préfixes, les données de routage et les voisins répondent à des questions différentes. Une route enregistrée dans un IRR peut exprimer une intention ou une autorisation sans être annoncée. Une annonce observée peut prouver une activité de routage à un instant donné, sans prouver que l’opérateur vend une plateforme cloud.

Les trois contrôles doivent donc être lus ensemble : statut de routage, préfixes annoncés et voisins visibles. Les résultats peuvent diverger selon la couverture des collecteurs, le moment de la mesure et les politiques d’annonce. Un résultat négatif, s’il était récupéré, devrait être formulé comme « non observé par ce service à cette date », et non comme « inexistant ». Les réponses actuelles de ces contrôles n’ont pas été exposées dans les artefacts disponibles pour cette passe. Voir le statut de routage RIPEstat, les préfixes annoncés et les voisins ASN.

Le profil PeeringDB constitue une couche différente. Une entrée non vide pourrait révéler des informations déclarées par l’opérateur sur ses politiques, ses installations, ses échanges, ses contacts ou son niveau de trafic. Une entrée vide ne prouverait pas l’inactivité : la participation à PeeringDB est volontaire. Une entrée remplie ne serait pas non plus une mesure indépendante de la circulation du trafic. Elle serait une déclaration opérateur à comparer avec les observations de routage. Consulter la recherche PeeringDB pour AS210328.

DNS, web et certificats : la continuité n’est pas le déploiement

Le troisième niveau concerne la continuité technique du domaine. Une requête A peut fournir une adresse IPv4, une absence de données ou une erreur. Une requête NS peut montrer les serveurs faisant autorité. Ces réponses aideraient à déterminer si le domaine reste délégué et vers quelles infrastructures il pointe. Elles ne permettraient pas, à elles seules, de conclure que le domaine est hébergé dans AS210328, ni qu’il représente un service cloud exploité par le titulaire du réseau.

Le fait qu’un site web soit hébergé chez un fournisseur tiers est parfaitement compatible avec l’existence d’un opérateur réseau distinct. Inversement, le fait qu’un domaine résolve vers une adresse associée à l’ASN étudié ne démontrerait pas que celui-ci fournit une infrastructure de cloud aux clients. Il faudrait encore établir la fonction du service, son attribution et sa continuité. Examiner la réponse A de Google Public DNS et la délégation NS.

La page d’accueil pourrait fournir des indices supplémentaires : une description de produit, une documentation technique, une interface client, une offre tarifaire ou des canaux de support. Mais ces éléments resteraient en partie auto-déclarés. Une page accessible est une preuve de présence web au moment de la capture, non une preuve indépendante de clients, de charges hébergées ou de capacité de calcul. L’artefact conservé pour le site ne fournit pas, dans cette passe, un contenu actuel permettant d’établir ces points. Voir le site almazcloud.network.

Les certificats TLS peuvent compléter cette chronologie. Les journaux de transparence peuvent révéler des noms d’hôtes, des dates d’émission et des périodes de validité. Une émission récente peut soutenir l’hypothèse d’un contrôle continu d’un nom de domaine. Elle ne prouve pas que ce nom résout encore, qu’il sert une application ou qu’il est relié à AS210328. Les certificats anciens et les entrées dupliquées peuvent aussi donner une impression exagérée de l’empreinte actuelle. Consulter la recherche Certificate Transparency.

L’état précis de cette collecte

La collecte actuelle a préservé des artefacts de source pour l’objet RIPE Database, les contrôles RIPEstat, PeeringDB, les requêtes DNS A et NS, le site web et Certificate Transparency. Mais les artefacts disponibles contiennent des descriptions de sources et des candidats de revendication, pas les réponses d’endpoint récupérées ni des valeurs actuelles horodatées.

Cette différence est décisive. Le dossier ne permet pas d’affirmer qu’AS210328 n’annonce aucun préfixe. Il ne permet pas davantage d’affirmer qu’il en annonce. Il ne permet pas de confirmer ou d’infirmer des voisins, une délégation DNS, une adresse d’hébergement, un certificat récent, une disponibilité web ou une offre cloud. La bonne conclusion n’est donc pas « réseau dormant » ou « fournisseur opérationnel », mais « l’observation nécessaire n’est pas encore disponible dans cette passe ».

Cette formulation peut sembler moins spectaculaire qu’un verdict. Elle est pourtant plus utile pour un suivi d’infrastructure. Elle préserve la différence entre trois états : une information non récupérée, une réponse récupérée avec un résultat négatif et une observation positive. Les confondre détruirait la chronologie que les analystes devront utiliser pour détecter un changement réel.

Comment établir la jonction entre identité et service

Une future collecte devrait commencer par récupérer les réponses brutes et horodatées de chaque endpoint. Pour AS210328, cela signifie comparer l’objet administratif avec le statut de routage, les préfixes observés et les chemins vus par plusieurs collecteurs. Pour almazcloud.network, cela signifie conserver les réponses DNS, les adresses, les chaînes de redirection, les certificats et le contenu servi. La jonction entre les deux objets ne devrait être retenue que si elle est démontrée par une observation indépendante, et non simplement suggérée par un nom commun.

La deuxième étape consisterait à rechercher la continuité. Une seule réponse positive peut montrer un état ponctuel. Des captures répétées à des dates distinctes peuvent montrer une persistance, une activation, une migration ou une interruption. Les numéros de série DNS, les périodes de validité des certificats, les changements d’adresse et l’historique des préfixes sont utiles parce qu’ils donnent une dimension temporelle au dossier.

La troisième étape serait d’identifier la fonction réellement fournie. Un réseau qui annonce un préfixe n’est pas automatiquement un fournisseur cloud. Il faudrait des indices directs et attribuables : documentation de services, points d’accès, interfaces, contrats ou déclarations concordantes avec une infrastructure observable. Même une page commerciale ne suffirait pas seule à prouver l’existence de clients actifs ; elle devrait être mise en regard de la connectivité, de la résolution, de la réponse applicative et, lorsque c’est possible, d’éléments indépendants.

Ce que les acteurs doivent surveiller

Pour les analystes réseau, les déclencheurs les plus importants sont l’apparition d’un préfixe originaire d’AS210328 dans plusieurs collecteurs, la répétition de cette observation dans le temps et l’existence de chemins cohérents vers des transitaires ou des pairs. Les changements RPKI peuvent améliorer l’analyse de l’autorisation, mais ils ne démontrent pas à eux seuls une activité commerciale.

Pour les équipes qui évaluent un fournisseur cloud potentiel, les indicateurs sont différents : une documentation stable, des endpoints fonctionnels, une attribution claire des adresses, une politique de support, une continuité de service et des preuves indépendantes de déploiement. Le DNS et le certificat sont des signaux de continuité de nom, pas des substituts à ces preuves.

Pour les observateurs de gouvernance Internet, le point central est la traçabilité. Une ressource enregistrée peut rester durablement dans les registres alors que son utilisation opérationnelle change, disparaît ou n’est jamais publiquement visible. La surveillance doit donc conserver les captures positives et négatives avec leur date, leur source et leur portée. Elle doit éviter d’écrire une histoire d’exploitation à partir de simples possibilités techniques.

Conclusion : une identité surveillable, pas encore une opération démontrée

Le dossier public autour d’almazcloud.network et d’AS210328 peut être structuré autour d’une hypothèse raisonnable : une identité réseau enregistrée pourrait, avec le temps, devenir un réseau observable puis un service identifiable. Mais la transition entre ces étapes doit être prouvée séparément.

Dans la collecte présente, les réponses nécessaires n’ont pas été récupérées. Il serait donc incorrect d’en déduire l’absence de routage, une panne DNS, l’abandon du domaine, l’absence de certificats, une interruption du site ou l’inexistence d’un service cloud. Il serait tout aussi incorrect de présenter les endpoints comme preuve d’une activité opérationnelle actuelle.

La conclusion la plus solide est plus étroite : les sources et les tests nécessaires sont identifiés, mais l’empreinte opérationnelle indépendante et le lien horodaté avec un service cloud ne sont pas vérifiés dans cette passe. La prochaine observation utile ne sera pas un nouveau récit. Ce sera une récupération reproductible des réponses, suivie d’une comparaison entre identité, routage, continuité technique et prestation effectivement observable.