HK CLOUD DATA CO., LIMITED が提供するホスト型キャパシティはラック、トランジット、修復時間に依然依存する

概要

• HK CLOUD DATA CO., LIMITED は、公衆インターネット番号体系において AS151206 として確認でき、これは2023年5月に登録された香港の自律システムである。同社の APNIC レコードには社名が記載されているが、BeeCloud によるスポンサー、管理、経路維持、および abuse 連絡先チェーンも示されている。
• 現在の経路観測では、AS151206 は11の IPv4 プレフィックス、3,072 IPv4 アドレス、1つの IPv6/32をアナウンスしており、RIPEstat で見える唯一の隣接アップストリームは AS140570（Hong Kong Beecloud System Technology Services Limited）である。
• 同社固有の公的証拠は依然として薄い。AS151206 の公開 PeeringDB エントリはなく、設備リスト、顧客ステータスページ、公表されたインシデント履歴、利用状況の測定値、そしてマルチサイトのキャパシティや独立した修復権限を証明する文書は存在しない。
• したがって、運用リスクは純粋なデジタル上のものではなく、物理的かつ契約的なものである。ホスト型キャパシティは、実際のラック、電力、アップストリームハンドオフ、リースまたは委任されたアドレス空間、ハードウェアインベントリ、サポートスタッフ、課金管理、そして顧客がワークロードを復旧または移行するためのテスト済みのパスに裏付けられていなければならない。

公的な情報の追跡は、クラウドキャンパスではなく自律システムから始まる

HK CLOUD DATA CO., LIMITED は、大規模な製品マニュアルや設備リスト、正式な耐障害性開示を備えた成熟したクラウド事業者のように公に自社を示してはいない。同社固有の最も強力な証拠は、より限定的かつ技術的なものである。AS151206 の APNIC RDAP レコードには、HKCLOUDDATA-AS-APと記載され、HK CLOUD DATA CO., LIMITED の社名、国名として Hong Kong、aut-num がアクティブであること、2023年5月2日の登録日と2023年9月の最終更新日が記録されている。

このレコードは重要だが、クラウドキャパシティの証明書ではない。自律システムはネットワークにルーティング上の識別性を与えるが、どのラックに顧客サーバが収容されているか、どのデータセンター契約が同社に電力を与えクロスコネクトを提供しているか、どのアップストリームポートが本番トラフィックを運んでいるか、深夜にどのエンジニアがケージに入れるか、あるいはホストされたサーバが故障した際に誰がディスクを所有しているかまでは特定できない。

また、APNIC の詳細からは、HK Cloud Data を自己完結的なプラットフォームとして素朴に読むことはできない。同じAPNIC WHOIS ビューでは、登録者としてORG-HCDC1-APが特定される一方で、スポンサー組織として Hong Kong Beecloud System Technology Services Limited が挙げられ、BeeCloud ロールが管理・技術連絡先、経路維持はMAINT-HKBCS-HKに割り当てられ、2026年2月に検証されたメールボックスを使用した BeeCloud 関連のインシデント対応連絡先が使用されていることが示されている。住所は No. 9 Lai Yip Street, Kwun Tong であり、香港の商業地域の住所である。この連絡パターンは、「HK Cloud Data が単独で開示されたクラウド環境を運用している」のではなく、「HK Cloud Data は BeeCloud のネットワークコンテキストを通じて、あるいは少なくとも BeeCloud によって管理されるルーティングされた企業レコードである」ことを意味する。

この区別は、ディレクトリカード、経路検索、リースされた IPv4 ブロック、ホスティングの請求書、またはクラウドサーバの提案を通じて同社に出会った読者にとって重要である。小規模なクラウドプロバイダがキャパシティを販売するとき、顧客は抽象的な ASN を購入するのではない。顧客は依存関係の束を購入するのである。データセンタースペース（リースであっても）が必要である。電力、冷却、トランジット、ルーター、スイッチ、サーバ、スペアパーツ、アクセス制御手順、チケット処理、課金権限が存在しなければならない。もしこの企業が他社のオペレータの管理チェーン内にネストされているならば、購入者は、変更を承認し、緊急の移行を許可し、故障したハードウェアを交換し、トラフィックを再ルーティングし、経路起点レコードを更新し、または紛争後にデータをリリースできる法的または運用上の当事者が誰であるかを知る必要もある。

公開記録は、ルーティングされた香港のネットワークアイデンティティの存在を支持するが、HK Cloud Data が独自の独立したマルチサイトクラウドプラットフォームを持つという強い主張をまだ裏付けてはいない。したがって、本稿では同社を可視的なホスティングキャパシティの主体として扱うが、証拠の格下げを明示する。トラフィックをルーティングするには十分実在するが、回復力、ローカリティ、キャパシティの主張をサービルレベル証明なしに受け入れるには開示が少なすぎるのである。

AS151206 はアクティブだが、BeeCloud の一歩後ろに位置しているように見える

ルーティング層は、証拠の中で最も新しい部分である。RIPEstat の AS 概要では、AS151206 はホルダー文字列「HKCLOUDDATA-AS-AP - HK CLOUD DATA CO., LIMITED」の下でアナウンスされている。ルーティング状況ビューでは、2026年7月12日にこの ASN が完全な IPv4 および IPv6 コレクター可視性で観測され、最初に経路が確認されたのは2023年5月、11の IPv4 プレフィックス、3,072 IPv4 アドレス、1つの IPv6 プレフィックス、および1つの観測されたネイバーが示されている。

アナウンスされたプレフィックスリストは、件数よりも多くを明らかにする。AS151206 は103.150.210.0/23、2406:7c0::/32、複数のレジストリプールからの10個の IPv4/24サイズの断片、そして203.168.235.0/24を発信していた。ルーティングされた/231つと10の/24の合計は、観測された3,072 IPv4 アドレスに相当する。これは、ホスティング、トランジット再販、仮想専用サーバ、専用サーバ、または顧客向け BGP サービスにとって意味のあるアドレスキャパシティである。しかし、3,072アドレスが稼働中の顧客に割り当てられていることや、障害状況下で全てのアドレスを使用するのに十分なコンピュートと帯域幅が存在することの証明にはならない。

隣接関係のビューはより注意を要する。RIPEstat の AS ネイバークエリは、可視な隣接 AS が1つだけであることを示した。AS140570 だ。AS140570 のAPNIC RDAP レコードでは、そのネットワークがHKBCS-AS-AP、Hong Kong Beecloud System Technology Services Limited であることが特定される。これは、AS151206 の連絡先および保守トレイルに現れるのと同じ BeeCloud 運営名である。経路観測のレイヤーでは、HK Cloud Data はしたがって、広範なアップストリームミックスを直接公衆インターネットに提示しているネットワークというよりは、BeeCloud の背後にあるダウンストリームまたは顧客に類似したルーティングアイデンティティのように見える。

このことは、ネットワーク自体が弱いことを意味しない。小規模なクラウドプロバイダが、より強力な親またはスポンサーオペレータの背後に顧客向け ASN を配置することは合理的である。BeeCloud 自身の公衆相互接続プロファイルは AS151206 よりも幅広い。PeeringDB は AS140570を「Hong Kong Beecloud」として、選択的ポリシー、いくつかの Exchange および施設エントリ、2026年5月の更新とともに掲載している。RIPEstat も AS140570 の周囲に多くのネイバーを確認している。しかし、BeeCloud の幅広い接続性が、物理的に多様な形で全ての HK Cloud Data の顧客に自動的に継承されるわけではない。決定的な問題は、AS151206 が使用可能なハンドオフを複数持ち、複数の施設パスを持ち、生き残った側に十分な予備キャパシティがあり、BeeCloud または BeeCloud のサプライヤーに問題が発生したときにサービスを復旧できるサポートパスが存在するかどうかである。

AS151206 の公開 PeeringDB エントリが存在しないことは、この注意をさらに強める。PeeringDB の不在は、ピアリングが存在しない証拠ではない。多くの小規模ネットワークは公開プロファイルを維持していない。これは、購入者が AS151206 の公開施設リストを使用して、どこに存在するか、どのインターネット Exchange に到達可能か、あるいは BeeCloud とは独立したクロスコネクトを持っているかを確認できないことを意味する。公開 BGP グラフは ASN がアクティブであることを示すが、ホスト型製品が耐障害性を備えていることを示してはいない。

アドレスミックスは、複数のプールから組み立てられたホスト型キャパシティのように見える

プレフィックスミックスもまた、ホスティングの経済的ストーリーを示唆している。プロバイダは、自身の割り当て、委任された空間、リースされたアドレスブロック、あるいは顧客所有のプレフィックスを発信することができる。これらは異なる故障モードを持つ異なる商業的取り決めである。もしアドレス範囲が別の所有者に属し、合意に基づいて AS151206 によってルーティングされているだけならば、顧客はそのリース、認可、または経路オブジェクトが撤回されたときに何が起こるかを知らなければならない。

APNIC と RDAP の追跡からは、可視なアドレス空間すべてが HK Cloud Data に直接登録されているわけではないことがわかる。RDAPおよびIPv6 ブロックの RDAPを通じて返された103.150.210.0/23と2406:7c0::/32のレコードは、Shenzhen Tuteng Network Co., Ltd.を示している。いくつかの45.200.*および156.*プレフィックスは、RDAP において Cloud Innovation Support と香港の国コードに関連付けられている。203.168.235.0/24レコードは、HK Cable コンテキストを通じた BeeCloud 運用ロールへの APNIC の非ポータブル割り当てである。154.18.162.0/24と209.146.7.0/24のレコードは、ARIN RDAP の Cogent 割り当ての下にある。

これらのどれもが不適切なことを証明するわけではない。ホスティングとトランジットの市場では、委任、リース、再割り当て、または顧客ルーティングのアドレスブロックが一般的である。しかし、これは「キャパシティ」という言葉を正直に保つ。アドレスキャパシティはコンピュートキャパシティではない。また、それは契約の永続性でもない。委任された空間に結びつけられた仮想サーバは、プロバイダが起点認可、レジストリの正確性、アップストリームフィルタ、およびアドレス所有者との課金関係を維持することに依存する可能性がある。これらのいずれかが失敗すれば、マシンは稼働し続けるかもしれないが、そのパブリックアドレスは機能しなくなる。

RPKI は部分的なチェックを提供する。RIPEstat の103.150.210.0/23の RPKI 検証、45.200.123.0/24、156.230.15.0/24、203.168.235.0/24は、AS151206 に対する有効な起点認可を返している。サンプルした154.18.162.0/24と209.146.7.0/24の経路は、レビュー時点で有効ではなく未知を返した。未知はハイジャックの所見ではないが、RFC 6811の下では、バリデータがその経路に対する一致する経路起点認可を持っていないことを意味する。しかし、顧客が全ての本番プレフィックスに対して暗号的な経路起点の証拠を期待するならば、依然としてオペレーション上のギャップである。

この混合は、HK Cloud Data の役割について実務的な読み方を支持する。同社は、BeeCloud のコンテキストの下で、クラウドサーバ、IP トランジット、専用インターネットアクセス、アドレスリース、またはマネージド BGP を販売またはサポートしている可能性がある。しかし、公開記録からでは、顧客が所有するリソースとルーティングされるリソース、恒久的な割り当てとリースブロック、予備アドレスとライブサービスキャパシティを区別することはできない。ミッションクリティカルなワークロードにとって、この区別は単なる経理上の話ではない。それは、プロバイダ自身のチームによって修復可能な経路と、別の所有者、アップストリーム、またはレジストリオブジェクトの調整を必要とする経路との違いである。

BeeCloud の公開サービス文言はオファーを説明するのに役立つが、リカバリ計画までは示さない

AS151206 がクラウドサービスの一群に現れる理由を理解する上で、BeeCloud 周辺の公開サービスコンテクストが役立つ。BeeCloud の英語ホームページは、DDoS 緩和、OFCA サービスベースの事業者番号、BGP 技術、デュアルローカルループプロバイダの表現、専用国際帯域共有、IP トランジットと IP 経路管理、マネージドセキュリティオペレーション、DDoS 検知と自動ブラックホール、そしてプライベートまたはパブリッククラウドソリューションを宣伝している。サービスページでは、デュアルローカルループ、共有インターネットプラットフォームアクセス、マルチ IP サポート、専用インターネットアクセス、スマートルートインターネットアクセス、中国向け経路サービス、95パーセンタイル課金、ASN と IPv4 リース、BGP 設定と管理、そして24時間セキュリティオペレーションセンターについて説明している。中国語のBCTSHK サイトは、BeeCloud Global Telecom Service として、香港商業ブロードバンド、IP トランジット、グローバル SD-WAN の表現とともに説明している。

これらのページは、AS151206 レコード周辺の商業製品ファミリーの型を示しているため有用である。帯域幅、経路、セキュリティフィルタリング、クラウドキャパシティ、IP リース、マネージドネットワーキングである。しかし、それらは HK Cloud Data 自身の資産を認定するには十分ではない。これらのページは AS151206 の施設リストを公開していない。HK Cloud Data が使用するラックやデータセンターを明示していない。ルーターの冗長性、障害時キャパシティ、スイッチハードウェア、ストレージレプリケーション、バックアップ保持、顧客移行権、サポート人員、スペアパーツ、インシデントメトリクスを開示していない。また、耐障害性の主張を裏付ける前にエンジニアリング的事実に翻訳する必要のある幅広いマーケティング文言も含まれている。

BeeCloud のショッピングページは、なぜ注意が必要かの良い例である。IPv4 パッケージ価格を提示し、同時に異なるプロバイダを通じてルーティングをブロードキャストできると述べつつ、検証済みの機器在庫として扱うべきではない一般的なサーバシャーシのテキストも表示している。顧客は、このページを BeeCloud がアドレス関連のホスティングまたはルーティングサービスを販売しているシグナルとして合理的に読むことができる。しかし、AS151206 が Cisco ブレードキャパシティ、ローカルスペアブレード、テスト済みのマルチプロバイダフェイルオーバー計画を持っていることの証明として読むべきではない。

製品メニューと運用証明の違いは、とりわけ香港において顕著である。この地域は、極めて高密度なキャリアとデータセンター市場を有する。政府のデータセンターポータルは、「香港を選ぶ理由」ページで、香港が堅牢な通信インフラ、約300のブロードバンドサービスプロバイダ、12の外部海底ケーブルシステム、非常に高い電力供給信頼性を有すると述べている。OFCA の海底ケーブルページも、2025年7月時点で香港には12の海底ケーブルシステムと10のケーブルランディングステーションがあると述べている。この環境は、小規模プロバイダがクロスコネクト、トランジット、コロケーション、データセンターサービスを購入することを容易にするが、購入者が市場の豊富さを特定のプロバイダの冗長性と間違えることも容易にする。

もし HK Cloud Data が、1つのリースされたケージ内のラックからホスト型サーバを販売しているなら、そのリスクプロファイルは、複数の独立した香港施設にアクティブなキャパシティを持つプロバイダとは異なる。もし BeeCloud のアドレスとトランジットサービスを使用しているなら、その復旧パスは、すべてのアップストリームセッションとルーター在庫を所有するプロバイダとは異なる。もしサービスが委任されたアドレス空間に依存しているなら、移行パスは、自身の集約を単に移動できるプロバイダとは異なる。公開資料はこれらの選択肢を解決しない。これらは、妥当なサービスファミリーと、顧客による直接的なデューデリジェンスを必要とする BeeCloud オペレーティングバウンダリーを特定する。

香港のローカリティは価値があるが、ローカリティはデータ主権と同じではない

HK Cloud Data の地域が重要である理由は、香港が主要なアジアのデータセンター・接続ハブであり続けているからだ。香港の Exchange への低遅延アクセス、中国本土向け経路、地域海底ケーブル、そして地元のビジネス顧客は、商業的に価値があり得る。香港ホスティングを必要とする顧客にとって、その約束は法的というより実務的かもしれない。ワークロードを香港のユーザの近くに置き、慣れた市場で支払い、地元のパートナーに接続し、地元のサポート時間を利用する。

しかし、ローカリティは定義されなければならない。香港で登録された企業、香港の ASN、香港の連絡先住所、香港ルーティングのプレフィックスは、それ自体では、顧客データがどこに保存され、バックアップがどこに複製され、サポートスタッフがシステムにアクセスできる場所、あるいは各サプライヤをどの管轄が管理しているかを証明しない。仮想サーバは、香港の IP アドレスを持ちながら、そのコントロールプレーン、サポートツール、バックアップ、監視、またはディザスタリカバリコピーが顧客の可視施設外のシステムに依存する可能性がある。また、プロバイダは香港でホストしながらも、管理や abuse 処理を別の運営会社を通じて行うこともできる。

これが、データ主権とローカリティの話題がトランジットやラックと同じ記事に属する理由である。香港個人情報プライバシーコミッショナー（PCPD）のクラウドコンピューティングに関するガイダンスは、クラウドサービスを利用する組織に対し、クラウドプロバイダによって個人データが処理される際の契約上およびセキュリティ上の対策を検討するよう求めている。これには、データ処理が香港域外で行われるケースも含まれる。このガイダンスはクラウド利用を禁止するものではない。責任をデータ利用者としての顧客に戻している。すなわち、顧客はプロバイダが何をしているか、誰がデータを処理するか、データがどこに行き得るか、そして不正アクセス、喪失、消去、保持がどのように防止されるかを把握しなければならない。

HK Cloud Data の顧客にとって、証拠のギャップはしたがって二重である。第一に、物理的なギャップがある。公開記録は、どの香港のデータセンター、ラック、ストレージプラットフォーム、あるいはバックアップサイトがワークロードを保持しているかを示さない。第二に、制御のギャップがある。AS151206 レコードは管理上および技術上の責任を BeeCloud の連絡先チェーンに置く一方、公開製品ページは BeeCloud ブランドの下に位置している。もし購入者が香港ローカリティの約束に依存しているなら、契約はホスティングサイトまたは許可されたホスティングゾーン、バックアップと複製の場所、サポートアクセスモデル、サブプロセッサ、データ返却手順、そして削除検証プロセスを明記すべきである。

顧客はまた、アドレスのローカリティとサービスのローカリティを分離すべきである。経路データベースはアドレスが香港で発信されたことを示すかもしれないが、アプリケーションは依然としてリモート DNS、リモートバックアップストレージ、国外管理のセキュリティツール、あるいはリモートスタッフに依存し得る。逆に、香港の施設は国際トランジットとリモート監視を使用しながらも、契約とリスク評価が許せば顧客のニーズを侵害しない可能性もある。公開情報源は違反も強みも証明しない。それらは、HK Cloud Data のローカリティの話が AS151206 だけから推論できないことを示している。

主な障害パスはスタックであり、単一の停止ではない

小規模なホスト型キャパシティプロバイダにとって、障害パスは通常、クラウドインターフェースの下から始まる。顧客は「サーバダウン」、「IP 到達不能」、「VPS 停止」、「パケットロス」、「課金失敗」、または「移行遅延」を見るかもしれない。これらの症状の背後には、いくつかの異なる障害がある。

第一に、施設依存である。ラックはデータセンタースペース、電力供給、冷却、消防設備、建物アクセス、クロスコネクト、リモートハンズサポートを必要とする。もし HK Cloud Data がリースされたラックや BeeCloud 管理下のスペースを使用しているなら、プロバイダの復旧能力は施設契約と、アクセスを承認できる当事者に依存する。単一の過負荷の電力供給、故障した PDU、冷却の問題、または施錠されたケージは、BGP が健全であってもサーバを停止させ得る。香港の全般的な電力信頼性は市場に役立つが、それが一つの小規模プロバイダのラックレベルの設計を保証するものではない。

第二に、アップストリーム依存である。RIPEstat は、AS151206 が1つの可視ネイバーAS140570 を持つことを示している。BeeCloud はより幅広いアップストリームと Exchange の多様性を持つかもしれないが、顧客向け AS151206 パスは、公開グラフにおいて BeeCloud に可視的に依存している。BeeCloud のポリシーミス、ポート障害、経路フィルタ、DDoS 緩和の誤設定、課金紛争、またはクロスコネクトの問題は、HK Cloud Data のサーバが稼働していても AS151206 に影響を与える可能性がある。RFC 4271は BGP を自律システム間の到達可能性プロトコルと説明している。それは、プレフィックスがどこに到達可能かをインターネットに伝えるが、物理ポートを修復できる人や、経路が消失する原因となった商業的問題を解決できる人を伝えない。

第三に、アドレス制御依存である。発信されたいくつかのプレフィックスは、HK Cloud Data 以外の当事者に登録または関連付けられているように見える。もしリースまたは委任されたプレフィックスが撤回されたり、経路起点認可が変更されたり、アップストリームが文書化が不十分だと判断したりした場合、顧客はマシンが無事であっても公衆到達性を失い得る。多くのプレフィックスに対する有効な RPKI は肯定的な兆候である。一部のルーティングされたプレフィックスに対する未知のステータスと、不均一なアドレスプールは、顧客がどのプレフィックスが恒久的で、どれがリースであり、アドレス権が変更された場合にどのような通知または移行パスが適用されるかを尋ねるべきことを意味する。

第四に、ハードウェア在庫である。ホスト型キャパシティは、交換部品と展開可能なサーバが必要な場所に存在する場合にのみ使用可能である。BeeCloud のサービス文言はクラウドとサーバの提供に言及しているが、どの公開ページも、HK Cloud Data に割り当てられた予備のコンピュート、ディスク、メモリ、光トランシーバ、ルーティング機器の量を証明していない。プロバイダは仮想プランを即座に販売できるが、互換性のある部品がローカルにない場合、故障した物理ホストの交換に数時間から数日かかることがある。

第五に、サポート労働力である。24時間オペレーションの声明は有用だが、復旧は適切な権限を持つ適切な人物に依存する。対応者は、障害が仮想マシン、ストレージアレイ、ハイパーバイザ、ToR スイッチ、クロスコネクト、アップストリーム経路、DDoS フィルタ、課金保留、アドレスリース、または施設インシデントのいずれであるかを把握しなければならない。もし障害がデータセンター事業者、ホールセールキャリア、またはアドレス所有者に属するなら、HK Cloud Data または BeeCloud は、単にそれを修正するのではなく、調整しなければならない。エスカレーションチェーンはネットワークの一部である。

第六に、顧客移行である。プロバイダが顧客が許容できる時間より長くラック、プレフィックス、またはアップストリームを失った場合、復旧の問いはポータビリティになる。顧客は完全なディスクイメージをエクスポートできるか？IP アドレスを移動できるか、それともデータのみか？課金アカウントが紛争中の場合、バックアップにアクセスできるか？DNS、逆引き DNS、経路オブジェクト、ファイアウォールポリシー、セキュリティログのための文書化された引き継ぎはあるか？公開経路の可視性はこれらの質問に答えない。

単一の可視アップストリーム証拠は、障害後のキャパシティテストを促すべきである

主要な設計上の問いは、BeeCloud 自体がアップストリームを1つしか持っていないかどうかではない。BeeCloud はより幅広い相互接続プロファイルを持つように見える。問いは、そのプロファイルのどの部分が、最大の信頼できる障害の後で AS151206 とその顧客に実際に利用可能かである。

小規模なダウンストリーム AS は、いくつかの方法でアップストリームネットワークに接続され得る。それは、BeeCloud への1つの物理クロスコネクトを持ち、その先の BeeCloud のアップストリームに依存するかもしれない。同じ BeeCloud ルーターペアへの冗長ポートを持つかもしれない。2つの物理的に分離されたハンドオフを2つの施設に持ち、両方ともネクスト AS として AS140570 を使用しているかもしれない。RIPEstat が観測時に見なかった直接のバックアップトランジットを持つかもしれない。公開 BGP は、可視な隣接 AS が1つしかない場合、これらの可能性を区別できない。

これが、キャパシティの問いが障害状態テストとして表現されなければならない理由である。通常のアナウンスされたキャパシティだけでは不十分である。購入者は、1つのラックが電力を失った後、1つのアクセススイッチが故障した後、1つの BeeCloud 相互接続が撤回された後、1つのアップストリームプロバイダがプレフィックスをフィルタした後、1つのアドレスリースが更新できない後、1つの DDoS 緩和ポリシーがトラフィックをブラックホール化した後、あるいは1つの施設がリモートハンズにとって到達不能になった後に何が残るかを知る必要がある。

プロバイダは、通常の設置キャパシティ、コミットされた顧客キャパシティ、および最大の単一障害後の生存キャパシティを述べることができるべきである。もし答えが「BeeCloud を使用している」なら、次の問いはどの BeeCloud 施設とリンクかである。もし答えが「2つのローカルループがある」なら、次の問いはそれらが別々の管路、建物入口、集約ノードを使用しているかどうかである。もし答えが「異なるプロバイダを通じてブロードキャストできる」なら、次の問いは AS151206 が署名された経路認可、テスト済みフィルタ、および本番負荷を運ぶのに十分な帯域幅を両方のパスで持っているかどうかである。

香港の地下環境は、この物理層を重要にする。OFCA の地下通信回線保護に関するページは、都市の地下空間には管路、光ファイバケーブル、銅線が含まれ、それらの偶発的な損傷が深刻な混乱を引き起こす可能性があり、地下回線の位置特定と保護に関する義務を定めている。これは、2つの論理サービスが依然として1つの物理回廊を共有し得ることを思い出させるものである。クラウドサーバは、図面上では2つの経路を持ちながら、両方の経路が同じ建物入口、同じライザー、同じ電源室、または同じ土木工事上の露出に依存する可能性がある。

同じ論理が海底ケーブルおよび地域経路にも適用される。OFCA は、事業者がケーブルランディングステーションとデータセンターを接続するリングネットワークを必要とし得るとし、統一キャリアライセンス事業者からサービスを調達し得ることを指摘している。小規模なホスティングプロバイダは、香港の多くのケーブルを所有せずに恩恵を受けることができる。しかし、中国本土へのアクセス、地域レイテンシ、または国際トランジットに依存する顧客は、そのパスのどの部分がプロバイダの管理下にあり、どの部分が BeeCloud によって供給され、どの部分が別のキャリアから購入されているかを知るべきである。

耐障害性の主張には、形容詞ではなく修復ウィンドウが必要である

「クラウド」という言葉は、修復の現実を曖昧にし得る。顧客は、クラウドキャパシティが自動的に移動すると想定するかもしれない。小規模なホスト型サーバや VPS の市場では、多くのプラットフォームはリースされた物理キャパシティに管理レイヤを加えたものに近い。仮想化、スナップショット、そしていくらかの予備ホストが存在するかもしれないが、故障したラックは依然として給電、冷却、アクセス、修復されなければならない。故障した経路は依然としてフィルタされ、認可され、アナウンスされなければならない。

有用な耐障害性の証拠は具体的であろう。それは、ケージに敏感な詳細を明らかにすることなく、HK Cloud Data のワークロードに使用されているデータセンターサイトを特定するだろう。同社がサーバを所有しているのか、ベアメタルキャパシティをリースしているのか、BeeCloud のインフラを再販しているのか、あるいはこれらのモデルを組み合わせているのかを述べるだろう。AS151206 のための通常のアップストリームとバックアップアップストリームをリストし、アップストリームが別々の施設を通じて入ってくるかどうかを説明し、どのプレフィックスが有効な経路起点認可の下で発信されているかを述べるだろう。サポートエスカレーションパスとステータス履歴ページを公開するだろう。保守ウィンドウ、顧客通知、計画された移行サポート、データエクスポート権を定義するだろう。

公開記録は現在、これらの資料を示していない。現在の証拠は、AS151206 がアクティブであり、多くのプレフィックスに対して経路保護されていること、BeeCloud がそれを管理し隣接していること、そして BeeCloud がこのビジネスをサポートし得る種類のブロードバンド、トランジット、BGP、IPv4 リース、DDoS、クラウドサービスを販売していることを示している。それは、HK Cloud Data が2つの独立した香港データセンター、AS151206 エッジにおける2つの独立したアップストリーム、ラック喪失を吸収するのに十分な予備サーバ、またはテスト済みの復旧計画を持っていることは示していない。

顧客は、これを調達条件として扱うべきであり、サービスを却下する理由として扱うべきではない。小規模プロバイダは、焦点の合ったキャパシティ、IPv4 ブロック、香港ルート、ローカルサポート、および柔軟な BGP ヘルプを、大規模なクラウドプラットフォームが一致できないかもしれない価格や速度で販売できるからこそ、有用であり得る。トレードオフは、購入者が依存関係の開示を購入の一部としなければならないことである。「vCPU はいくつか？」や「IP はいくつか？」だけでは十分ではない。より強力な問いは、サーバがどこにあり、誰がホストを所有し、誰がプレフィックスを所有し、誰がアップリンクを所有し、BeeCloud が到達不能になったときに何が起こり、最長の復旧ウィンドウはどれくらいか、そして回答が遅すぎる場合にワークロードが離脱できるかどうかである。

ルーティング衛生は沈黙よりは良いが、それでも不完全である

経路証拠には肯定的な兆候がある。AS151206 は単なる古いレジストリオブジェクトではなく、現在の RIPEstat 観測はライブ発信を示している。そのプレフィックスの多くは、AS151206 に対する RPKI の下で有効化される。APNIC の abuse メールボックスは最近の検証日付を持つ。BeeCloud の管理チェーンは隠されるのではなく、明示的である。これらは、小規模なクラウドサービスアイデンティティにとって有用な兆候である。

残る経路のギャップもまた具体的である。サンプルされた Cogent 関連の経路は未知の RPKI ステータスを返したため、起点検証は全ての可視経路をカバーしていない。公開グラフは、AS151206 に隣接する第二のアップストリームを示していない。AS151206 の公開 PeeringDB プロファイルはない。いくつかのアドレスブロックは他の保持者に関連付けられているように見えるため、アドレス権の継続性は契約によって確認されなければならない。逆引き DNS、経路オブジェクト、RPKI ROA、abuse 連絡先が、HK Cloud Data、BeeCloud、アドレス 貸主、またはアップストリームのいずれによって管理されているかを説明する公開文書はない。

ルーティングセキュリティの実践は重要である。なぜなら、ホスト型キャパシティプロバイダの顧客は、しばしばアナウンスに対する制御をほとんど持たないからである。RFC 7454は、BGP オペレーションのためにプレフィックスフィルタリング、最大プレフィックス制限、パスフィルタリング、経路ポリシー規律といった運用管理を推奨している。顧客はルートコレクタからこれらのプライベートな設定を検証できない。彼らは、プロバイダに意図されたプレフィックスを文書化し、正しい連絡先を維持し、可能な限り経路起点認可を公開し、そして本番ワークロードがそれに依存する前に撤回とフェイルオーバー手順をテストするよう要求できる。

また、セキュリティとは別の課金および停止リスクもある。アドレスリースや低コストホスティングの市場では、顧客はケーブルが切れたからではなく、プレフィックスリース、abuse 苦情、支払い方法、アップストリームの請求書、またはリセラーアカウントが失敗したためにインターネットから姿を消すことがある。BeeCloud の公開資料には IPv4 リースと BGP 管理の文言が含まれているため、購入者はアドレス権がサーバにバンドルされているのか、別途課金されるのか、期限付きなのか、ポータブルなのか、第三者承認の対象となるのかを尋ねるべきである。課金とレジストリ権限を無視した復旧計画は不完全である。

最善の解釈はバランスが取れている。HK Cloud Data のルーティング衛生は否定的ではない。部分的に可視であり、部分的に安心させる。しかし、エンタープライズグレードのクラウド耐障害性を推測するには十分に完全ではない。

システムが故障したとき、誰が影響を受けるか

影響を受ける利用者は、香港ローカリティ、IP アドレス、専用インターネットアクセス、クラウドサーバ、BGP 管理、または中国向け経路を購入する小中規模の顧客である可能性が高い。公開情報源は HK Cloud Data の顧客を名指ししておらず、特定の組織が推測されるべきではない。影響プロファイルは依然として記述可能である。

ウェブホスティングの顧客にとって、障害は公衆到達不能、迅速に行えない DNS 変更、失われた SEO トラフィック、故障したチェックアウトページ、またはアクセスできない管理パネルであるかもしれない。香港の VPS キャパシティを使用する SaaS オペレータにとって、障害はセッション喪失、キュー蓄積、失敗したデータエクスポート、またはカスタマーサポート負荷であるかもしれない。アドレス空間を購入している企業にとって、障害は経路撤回、ブロックされた送信メール、ジオロケーションのずれ、abuse リスト入り、または長期間維持された顧客許可リストを保持できないことかもしれない。ローカリティ管理として香港サービスを利用する購入者にとって、障害はデータがどこに保存されているか、またはどれだけ迅速に返却できるかについての信頼の喪失かもしれない。

最も結果の大きいケースは、いくつかの依存関係を組み合わせるものである。顧客は、同じプロバイダチェーンから仮想サーバ、リースされた IPv4 ブロック、DDoS フィルタリング、中国向け経路トランジットを購入するかもしれない。もし BeeCloud のエッジ問題がサーバ経路と DDoS コントロールプレーンの両方に影響を与えるなら、顧客は本番パスと緩和パスの両方を失う。もしリースされたプレフィックスがポータブルでなければ、顧客はサーバイメージを別のクラウドに単に移動して同じアドレスを保持することはできない。もしバックアップが同じ施設やアカウントに保存されているなら、移行ウィンドウは拡大する。

そのため、真剣な顧客は、プロバイダが正直で有能である場合でも、自身の復旧計画を設計すべきである。プロバイダ外部にバックアップを保持する。顧客が管理する認証情報で DNS を使用する。インフラストラクチャ・アズ・コードまたは構築ノートをホスト型サーバの外部に保持する。どの IP アドレスが移動可能で、どれが不可能かを理解する。エクスポートをテストする。サービスがレイテンシに敏感なら、第二の香港または地域ホスティングプロバイダを事前認定する。サービスがデータに敏感なら、データとバックアップの保管が許可される場所を文書化する。

プロバイダは、これらの現実を一般的なクラウド文言の背後に隠すのではなく、可視化することで支援できる。明確な開示は小規模なプロバイダを弱めるのではない。それは、適切な顧客が適切な製品を購入できるようにする。一部のワークロードは安価な香港の到達可能性のみを必要とし、手動の復旧を許容できる。他のワークロードは、契約されたマルチサイト継続性を必要とし、異なるアーキテクチャに支払うべきである。

実用的な証拠グレードは中低であり、改善への明確な方法がある

HK Cloud Data は否定的な証拠ケースではない。同社は、ライブな APNIC 登録 ASN、現在の経路発信、一貫した BeeCloud の連絡先とスポンサーのトレイル、多くの RPKI 有効経路、そして BeeCloud ブロードバンド、トランジット、BGP、DDoS、クラウド提供をめぐる妥当なサービスコンテクストを有する。これらの事実は、それを運営中のネットワークアイデンティティとして扱うことを正当化する。

証拠はまた、自信を持ってクラウド耐障害性を結論付けるには十分に強くない。AS151206 施設の独立した公開マップ、公開データセンターサイトのリスト、直接の PeeringDB エントリ、第二の可視隣接アップストリーム、全てのサンプルされたプレフィックスに対する完全な RPKI カバレッジ、公開されたアップタイムやインシデント記録、ハードウェア在庫、ストレージやバックアップの説明、サポート指標、顧客移行ポリシーが存在しない。いくつかのアドレスブロックは他の所有者やサプライヤに関係しているように見え、アドレス管理のデューデリジェンスを耐障害性レビューの一部としている。

次なる最善の開示は、控えめで実務的であろう。AS151206 の日付入りサービス声明で、運営当事者、ホスティングモデル、市レベルで使用されている施設、アップストリームと BeeCloud 依存モデル、プレフィックスの所有権またはリース状況、RPKI カバレッジ、バックアップとデータエクスポートの条件、サポートエスカレーションパス、保守ウィンドウポリシー、障害状態キャパシティを明記するものだ。機密のラック番号やルーター設定を明らかにする必要はないだろう。それは、まばらな公開経路トレイルを調達グレードのサービス記述に変えるだろう。

それまでは、正しい結論は慎重である。HK CLOUD DATA CO., LIMITED は、香港の BeeCloud オペレーティング軌道内でホスト型キャパシティを販売またはサポートしており、AS151206 はインターネット上で真正に可視である。しかし、そのキャパシティの価値は依然として通常のインフラに依存している。すなわち、稼働し続けるラック、認可され続けるトランジット、有効であり続けるアドレス権、交換可能なハードウェア、行動できるサポートスタッフ、経路を中断させない課金、そしてプロバイダの隠れた依存関係が故障する部分である場合に復旧または移動可能な顧客データである。