要約

  • AS210328の登録情報、経路の可視性、ドメインのDNS、TLS証明書、HTTPエンドポイント、顧客向けサービスは、相互に関連し得るが同じ事実ではない。
  • 今回の調査では、これらを検証する28の公開ソース候補を特定した。しかし、候補ソースのライブ応答は取得されておらず、現在のプレフィックス、DNS回答、証明書、HTTP動作、顧客向けサービスの稼働を断定できない。

登録主体からサービス提供者へは、いくつものリンクが必要になる

クラウド事業者を調べるとき、最初に見つかりやすいのはドメイン名や自律システム番号（ASN）である。ASNはインターネット上の経路を識別する番号で、AS210328のような登録オブジェクトには、名称、状態、管理組織、連絡先、ルーティングポリシーなどが記録される可能性がある。RIPE NCCのデータベースは、その登録状態を確認するための主要な公開情報源になる。

しかし、ASNが割り当てられていることは、現在そのASNが経路を発信していることを意味しない。登録オブジェクトが存在しても、顧客向けサービスが提供されていることまでは示さない。逆に、実際に経路が観測されても、それだけで、そのASNを使う組織が顧客向けクラウド基盤を運営しているとはいえない。

この調査で必要な証拠の連鎖は、少なくとも次のようになる。

  1. 登録データがAS210328の管理主体を示す。
  2. 経路観測が、一定時点にAS210328から発信されたプレフィックスを示す。
  3. almazcloud.networkのDNS回答やサブドメインが、観測されたアドレス空間に結び付く。
  4. TLS証明書、HTTP応答、アーカイブ、スキャン記録などが、実際のエンドポイントの存在を補強する。
  5. サービス仕様、顧客導線、利用規約、料金、API、コンソールなどが、単なるネットワーク資源を顧客向けクラウドサービスへと結び付ける。

この五つの層のどこかが欠けていれば、結論の強さも変わる。

BGPの可視性は、運用の一部を示すが、事業の全体像ではない

RIPEstatのAS概要、発信プレフィックス、ルーティング状態、観測された隣接ASNは、AS210328がインターネットの経路情報にどのように現れるかを調べるための候補ソースである。BGP.tools、BGPView、Cloudflare Radar、CAIDAのAS Rankも、異なる観測地点や推定手法から結果を比較するために使える。

ここで重要なのは、経路の「観測」と商業上の「関係」を分けることだ。ASパス上で隣接しているASNは、上流や下流の候補になり得るが、直接の商取引関係を証明しない。経路サーバー、経路の付加、集約、観測地点の違いが結果に影響するためである。PeeringDBに登録されたネットワーク名、ウェブサイト、施設、交換ポイント、接続方針も有用だが、同じく運営者が入力する情報であり、法的な所有や現在の稼働を独立に証明するものではない。

したがって、記事で「AS210328が運用中である」と書くには、少なくとも取得時刻を持つ経路観測と、複数ソースの比較が必要になる。プレフィックス一覧だけでは足りず、そのプレフィックスがどの観測地点から、いつ、どの程度見えていたのかを示す必要がある。逆に、あるサービスで見つからないことも、ただちに運用停止を意味しない。小規模なASN、新規経路、地域的な可視性、更新間隔の違いがあるからだ。

ドメインはインフラへの入口だが、所有と配置を同時には示さない

RDAPは、ドメインの登録者、レジストラ、状態、登録・更新・期限、委任ネームサーバーを調べる候補になる。Google Public DNSのNS、A、AAAA、DSクエリは、ある再帰リゾルバーから見える現在のDNS回答を記録するために使える。DNSVizは、委任、権威ネームサーバー、DNSSECの検証経路や設定エラーを補助的に確認する候補である。

ただし、ドメイン登録はAS210328の運用を証明しない。登録者情報が非公開であったり、再販業者や第三者DNS事業者が介在したり、ウェブサイトだけが外部CDNやホスティング事業者に置かれていたりする可能性がある。AレコードのアドレスがAS210328の発信プレフィックス外にあっても、他のサブドメインや顧客ネットワークで同ASNが使われていないとはいえない。

このため、DNSの調査では、名前解決結果を単独の所有証拠として扱わない。権威サーバーと複数リゾルバーの結果、TTL、CNAME連鎖、同時刻の経路情報を照合し、どのサービス名がどのアドレスへ向かうのかを分解する必要がある。DNSSECのDSやDNSKEYの存在も、運用管理の一要素を示すにとどまり、クラウドサービスの機能や規模を示すものではない。

証明書とアーカイブは、サービスの存在時点を補強する

Certificate Transparencyの検索結果は、almazcloud.networkとそのサブドメインに対して発行された証明書、SAN、発行者、有効期間、ログ記録を調べる候補になる。crt.sh、Censys、SSL Labsの結果を比較すれば、特定のホスト名が証明書の対象になった時期や、公開TLS設定を検証する手がかりが得られる。URLScan、Wayback Machine、OTX、VirusTotal、GitHub、grep.appも、過去のページ、DNS、スキャン、コードや文字列の痕跡を探すための候補である。

しかし、証明書の発行は、証明書が実際に配備されたことを証明しない。ホスト名が現在も稼働していることも、証明書の申請者がAS210328の運用者であることも、そこから直接は分からない。アーカイブにページが残っていることも、現在の顧客向けサービスの提供を意味しない。

この区別は、クラウド事業の調査で特に重要になる。サービス名らしいサブドメイン、たとえばAPI、コンソール、認証、ストレージ、パネル、地域名を含むホスト名が見つかっても、それは検証すべき導線であって、稼働確認そのものではない。安全なHTTP検証、証明書の有効期間、DNS回答、経路の同時観測、公開文書や利用者向け画面がそろって初めて、顧客向け運用について強い主張ができる。

今回、何が確認され、何が確認されていないのか

今回の独立調査は、RIPE NCC、BGP.tools、PeeringDB、BGPView、CAIDA、Cloudflare Radar、RDAP、Google Public DNS、DNSViz、crt.sh、Censys、SSL Labs、公式ドメイン、Wayback Machine、URLScan、OTX、VirusTotal、GitHub、grep.appなど、28の公開ソース候補を特定した。

一方で、調査結果には明確な制約がある。ライブWebやAPIの応答はこの実行では取得されていない。各候補の取得時刻も記録されていない。そのため、AS210328の現在の登録値、現在発信されているプレフィックス、DNS回答、証明書、HTTP挙動、顧客向けクラウドサービスの稼働を、この記事の事実として提示することはできない。

これは「何も存在しない」という結論ではない。正確には、検証に使える公開窓口は特定されたが、今回の観測として保存されたライブ値がない、という状態である。未観測、観測したが否定的、観測して肯定的という三つの状態を混同してはならない。

事業の実行を検証するための次のテスト

次の調査では、UTC時刻をそろえて、RIPE Databaseのaut-numと関連組織オブジェクトを取得する。同時に、RIPEstatの発信プレフィックスとルーティング状態、少なくとも一つの独立BGP集約サービス、可能なら複数観測地点の結果を保存する。各レスポンスは生データと暗号学的ハッシュを伴って保管するべきである。

その後、RDAPと権威DNSを確認し、A・AAAA・NS・DSの回答を同じ時刻系列に置く。アドレスをBGPプレフィックスへ対応させ、ドメインのエンドポイントがAS210328に直接結び付くのか、第三者CDNやホスティングを経由するのかを分ける。証明書のSANとHTTP応答は、公開されたサービス名や機能の記録と照合する。

最後に必要なのは、顧客に対する提供実態の証拠である。料金、API文書、コンソール、利用規約、サポート窓口、公開された顧客導線、稼働情報などが、ネットワーク資源とサービスの間をつなぐ。登録、ルーティング、名前解決、暗号化、ウェブ表示のいずれか一つだけで、クラウド事業の実行を語ることはできない。

結論

公開情報から事業者の実像を描くには、名前を見つけることより、証拠の連鎖を保つことが重要である。AS210328、almazcloud.network、DNS、証明書、経路、エンドポイント、顧客導線が同じ運用主体に結び付くなら、クラウドサービスの実行を示す説明は強くなる。現時点でライブ値が取得されていない以上、その結論を先取りすることはできない。

本件で最も堅い結論は、調査対象と検証方法が明確になったこと、そして登録情報やソース候補の存在だけでは現在のクラウド運用を証明できないことである。次の判断には、時刻付きの観測と、各インフラ層をつなぐ独立証拠が必要になる。

調査に用いた公開ソース候補