要約

  • 現在の調査で保存された資料は、RIPE Database、RIPEstat、PeeringDB、Google Public DNS、対象ウェブサイト、Certificate Transparencyへの確認経路を示すが、各エンドポイントの現在値や取得時点のペイロードを含んでいない。
  • したがって、AS210328の経路、広告プレフィックス、近隣AS、almazcloud.networkのDNS、ウェブ、証明書、ホスティング、クラウドサービスの稼働について、今回の資料だけから肯定も否定もできない。

調査の問いは「登録されているか」ではない

今回の中心的な問いは、登録された識別情報が存在するかどうかではない。委託時点では、almazcloud.networkはAS210328と関連づけられている。しかし、この関連づけは今回の取得で独立に再確認された事実ではなく、調査対象を定めるための文脈である。より重要なのは、その識別情報が、第三者から観測できる運用上の足跡へ移行しているかどうかだ。

この区別は、ネットワーク資源をクラウドサービスの証拠として扱う場合に決定的になる。RIRやレジストリの記録は、管理上の主体、割り当て、登録状態を示し得る。一方、経路情報は、あるASが一定時点に到達可能性を広告していたかを示す。DNSは名前解決や委任の状態を示し、ウェブや証明書はその名前に結びついた公開サービスの継続性を示す可能性がある。それでも、これらを積み重ねただけで、顧客向けのクラウド基盤が稼働していることにはならない。

四つの証拠層を分ける

第一層は行政的・登録上のネットワーク識別である。今回の調査では、RIPE DatabaseのAS210328記録を確認経路の候補として保存した。ただし、保存された資料には現在のエンドポイント・ペイロードやタイムスタンプ付きの属性値がない。従って、登録記録があることと、現在そのASが運用されていることを同一視できない。

第二層は時間付きの経路可視性である。RIPEstatのrouting-statusエンドポイント、発表プレフィックスのエンドポイント、ASN近隣関係のエンドポイントは、ASが実際に経路空間に現れているかを検証するための候補である。しかし今回の保存資料からは、到達性、プレフィックス数、近隣AS、観測時刻のいずれも読み取れない。ここで「確認できなかった」という状態を「存在しない」と書き換えることはできない。

第三層はDNS、ウェブ、証明書の連続性である。PeeringDBのAS210328ネットワーク記録は運用者が申告するネットワーク・プロフィールの候補、Google Public DNSのAレコード照会はドメインのアドレス連続性の候補、NSレコード照会はDNS委任の候補である。対象ドメインのウェブサイトとCertificate Transparencyの照会は、公開ウェブサービスや証明書発行の継続性を調べる入口になる。

だが、これらもそれぞれ異なる事実を測る。DNSレコードは名前とアドレスの関係を示すだけで、アドレス上でクラウド基盤が提供されていることを示さない。証明書は暗号化された接続のための認証材料であり、顧客向けサービスの規模、利用状況、運用主体を単独では証明しない。ウェブサイトが応答したとしても、それがAS210328の設備から提供されているとは限らない。

第四層が、直接確認されたクラウドサービスの運用である。そこでは、対象に帰属できる現在のエンドポイント、サービス説明、顧客向け機能、可用性、運用主体、またはそれに相当する一次資料が必要になる。今回の資料には、その判断に必要な現在の値がない。ゆえに、almazcloud.networkを稼働中のクラウド事業者、ホスティング基盤、あるいは顧客向けクラウドサービスとして断定することはできない。

不在の証拠と未取得の証拠は違う

この調査の最も重要な結果は、否定的な観測ではなく、観測の空白である。現在のエンドポイント・ペイロードが保存されていないことは、経路が存在しないことを意味しない。DNS障害、ウェブサイト停止、証明書の不存在、ホスティングの終了、クラウドサービスの停止、休眠、あるいは意図的な秘匿を意味するものでもない。

同じ理由で、登録情報や候補URLが存在することも、運用の肯定的証拠にはならない。調査では少なくとも三つの状態を分ける必要がある。第一は「取得されていない」。第二は「取得され、否定的な値が返った」。第三は「取得され、対象に帰属可能な肯定的観測が得られた」である。今回確認できるのは、主として第一の状態である。

この境界を守らなければ、登録データからクラウド提供を推測し、逆に現在値がないことから停止を推測するという、両方向の誤りが起きる。技術的な調査で重要なのは、空白を結論に変えず、次に何を取得すれば判断が進むのかを明示することだ。

次に必要なタイムスタンプ付き確認

第一に、AS210328の登録属性を取得時刻とともに保存し、origin、管理主体、更新日、関連する連絡先などを確認する必要がある。第二に、複数の観測地点からRIPEstatその他の経路データを取得し、経路状態、広告プレフィックス、近隣AS、観測時刻を記録する必要がある。単一時点の観測は、短時間の広告や撤回を捉え損なう可能性がある。

第三に、almazcloud.networkのA、AAAA、NS、SOA、MXなどを同一時刻帯に取得し、権威ネームサーバー、解決結果、TTL、アドレスの変化を記録する必要がある。第四に、ウェブ応答の証明書チェーン、HTTP応答、リダイレクト、名前解決先を取得し、それらがAS210328または別の提供者にどう結びつくかを明示する必要がある。第五に、サービスの直接証拠がある場合でも、ドメインやASとの帰属関係を別途立証しなければならない。

重要なのは、これらを一つの「稼働」フラグに圧縮しないことである。ASの経路広告、ドメインの名前解決、ウェブ応答、証明書発行、クラウド機能の提供は、別々の時系列として保存されるべきだ。連続性が確認できた場合にも、それは「いつ、どの観測地点から、どの主体に帰属する何が見えたか」という形で記述されなければならない。

結論：今回の確かな発見は、判断の境界である

今回の資料から、almazcloud.networkとAS210328に関する現在のネットワーク値やクラウド運用を確認することはできない。だからといって、対象が運用されていないとも、登録だけの存在とも言えない。今回確認できるのは、登録情報、経路、DNS・ウェブ・証明書、直接的なクラウド運用が同じ証拠ではなく、相互に代替できないという点である。

登録されたアイデンティティが独立に観測可能な運用フットプリントへ移行したのか。その答えには、タイムスタンプ付きの再取得と、層をまたぐ帰属関係の確認が必要だ。現段階では、最も正確な結論は「未確認」であり、「停止」でも「稼働」でもない。