概要
- LUNAR HOSTING LTD は2026年4月19日に設立された活動中の英国企業です。その AS198685 は現在、2つの IPv4 /24ルートを発信しており、1つはドイツの国タグとファルケンシュタインのジオフィードが登録され、もう1つはオランダの国タグが登録されています。現在の公開観測では、IPv6 ルートはなく、可視の隣接ネットワークは1つだけです。
- ネットワークの証拠は限定的な結論を支持しています。Lunar という名前で小さなルーティングされたホスティングフットプリントが運用されています。データセンターの所有、サーバー在庫、冗長電源、独立したトランジット、バックアップ適用範囲、スタッフによるサポート、またはテストされた終了経路を証明するものではありません。
- 購入者は、回復力、データローカリティ、および回復可能性を未解決の契約上の問題として扱うべきです。最も重要な証拠は、指定された施設、ハードウェアと上流の責任、テストされた復元結果、サービス固有の可用性条件、サポートエスカレーション時間、および完全なワークロードをエクスポートするための文書化された方法です。
企業は回復力を構築するよりも速く ASN を取得できる
LUNAR HOSTING LTD は、圧縮されたインフラストーリーを提示しています。現在の英国企業は、2026年4月19日に設立され、会社番号17166654、ロンドンの Rupert Street 42に登記上の事務所があります。登記簿は活動中と記載し、情報技術コンサルタント、およびデータ処理、ホスティングおよび関連活動という2つの事業分類を与えています。AS198685 の RIPE レコードは翌日に作成されました。7月までに、ルートコレクターはその自律システムによって発信された2つの IPv4 /24を確認できるようになりました。
これらは些細な成果ではありません。自律システム番号により、事業者は自身の識別子の下でルーティングポリシーを表現できます。可視ルートは、他のネットワークがそのアドレスへの経路を受け入れ、伝搬していることを意味します。ルートオリジン認証は、検証ネットワークに対して、指定された AS がプレフィックスを発信することを許可されていることを伝えます。これらを合わせると、企業名、ソーシャルメディアページ、休眠ドメインよりも強力な運用証拠となります。
しかし、これらはホスティングサービスのネットワークエッジにすぎません。Lunar が一台のサーバーを所有しているかどうかは示しません。ラックのリース、電力割り当て、予備ドライブ、リモートハンド条件、バックアップメディア、ハイパーバイザークラスター、オンコールの技術者を示すものではありません。マシンを取り巻く商業的メカニズムについてはさらに少なくしか示しません。請求書の紛争でラックが停止される可能性、サプライヤーがアドレスを回収できる可能性、顧客が契約終了前に動作イメージを抽出できるかどうかなどです。
この区別は重要です。なぜなら、小規模ホスティング企業はしばしば一つの商業オブジェクトを販売しながら、それを複数の物理的および契約的オブジェクトから組み立てているからです。顧客は仮想プライベートサーバー、専用マシン、またはマネージドサービスを見ます。プロバイダーは、レンタルハードウェア、サブ割り当てアドレススペース、スポンサー付き ASN、サードパーティトランジット、施設契約、アンチ DDoS フィルタリング、課金パネルを組み合わせている可能性があります。各コンポーネントは正当で適切に運営されている可能性があります。しかし、それぞれに独自の更新日、障害モード、およびそれを切断する権限を持つ当事者があります。
したがって、公開証拠は狭い記述を支持します。Lunar は最近割り当てられた ASN と小さなグローバルに可視な IPv4 フットプリントに関連する、新しく設立された英国のホスティング関連企業です。Lunar がデータセンターを所有し、複数の独立したサイトを制御し、障害下での継続性を実証したという大きな主張を支持するものではありません。その大きな主張には、ルーティングテーブルが提供するものよりもマシンと契約に近い証拠が必要です。
また、同じ名前の古い英国企業（会社番号15058184）があり、2025年1月14日に解散しました。その登記上の住所と事業分類は活動中の企業とは異なります。現在のネットワーク記録には、2つの企業が関連していることを要求するものは何もないため、解散した同名企業を会社17166654の履歴、負債、継続性を推測するために使用すべきではありません。最も安全なアンカーは、現在の RIPE 組織記録に繰り返し記載されている活動中の会社番号です。
2つの/24は可視容量であり、マシンの台帳ではない
2026年7月12日、RIPEstat のアナウンスドプレフィックスビューは、AS198685 の下に144.31.136.0/24と94.183.224.0/24をリストしました。これはルーティング可能なブロックで512の IPv4 アドレスです。そのルーティングステータスビューは、両方のプレフィックスが関連する RIPE ルーティング情報サービスサンプルのすべての326 IPv4 ピアに可視であることを示しました。IPv6 スペースのアナウンスはありませんでした。
アドレス数は有用ですが、厳しい制限内でのみです。/24は多くの顧客アドレス、少数のネットワークアドレス変換サービス、インフラインターフェース、予備割り当て、またはレピュテーションや運用ポリシーにより保留されたアドレスをサポートできます。大規模な仮想化クラスターまたは非常に小規模なホストセットの前に置くことができます。また、顧客向け IP が変わらないまま物理サプライヤー間を移動することもできます。アドレスを数えても、プロセッサコア、メモリ、ストレージスループット、オーバーサブスクリプション、ラック密度、または支払いテナントの数は明らかになりません。
設置容量と利用可能容量の差はさらに大きくなります。設置容量はラックまたはサプライヤーアカウントに存在するもの：マシン、ディスク、ポート、ライセンスソフトウェアです。利用可能容量は、性能目標、冗長性予備、または修理前提に違反せずに販売できるものです。10台のサーバーが設置されていても、すべての顧客が同じストレージコントローラーまたはトップオブラックスイッチに依存している場合、有効な障害耐性はサーバー数が示唆するよりもはるかに小さい可能性があります。すべてのアドレスが1つの外部経路を通って出ていく場合、マシンを追加することでルート多様性を増やすことなく収益容量を増やします。
Lunar はどちらの尺度を計算するにも十分な検証可能な資料を公開していません。2つのプレフィックスをホスト数、プロセッサ世代、ストレージ設計、または予備の予備容量に結び付ける公開インベントリはありません。サービスが空いているか、快適に負荷がかかっているか、リソース境界近くで稼働しているかを示す公開利用率系列はありません。二次ネットワークデータサービスであるIPinfoは、AS をホスティングとして分類し、少数のホストされたドメインをカウントし、観測時に24時間活動を説明しました。これらはアドレスがトラフィックを運んでいるという有用な兆候です。顧客を特定したり、請求書を検証したり、宣伝された商用容量が利用可能であることを証明したりすることはできません。
ここでホスティング経済学は物理的になります。低コストの仮想サーバーは、誰かが以前にシャーシを購入またはレンタルし、電源を入れ、接続し、ストレージをインストールし、別のゲストを受け入れるのに十分なメモリを予約したからこそ、数秒で作成できます。限界的な行為はデジタルですが、その下にある容量はそうではありません。プロバイダーの公開フットプリントが薄い場合、顧客は持続的な余裕の証拠としてプロビジョニングの速さを安全に代用することはできません。
真剣な容量表明は、サービス区分とその制限リソースを特定します。仮想サーバーの場合、CPU が専用か共有か、ストレージがローカルかネットワークか、IOPS 制限が適用されるか、ホスト障害予備がどれだけあるかなどが含まれます。ベアメタルの場合、在庫状況、交換部品目標、および同等のハードウェアを別のサイトで提供できるかどうかが含まれます。マネージドサービスの場合、労働境界が含まれます。誰がホストにパッチを適用するか、時間外に誰が対応するか、顧客がマシンに到達できないときにプロバイダーがどれだけ迅速に行動するかなどです。
これらの開示がない場合、最も強い表明は、Lunar が2つのグローバルに可視な IPv4 ルートの現在の起点を制御しているというものです。それは本当のネットワーク容量です。それは計算能力、ストレージ耐久性、またはサービスが吸収できる障害数の信頼できる代理指標ではありません。
ロケーション証拠はドイツとオランダを示すが、重要な注意点がある
2つのアドレスブロックは、RIPE レコードにおいて異なるロケーシティシグナルを持ちます。144.31.136.0/24の inetnum オブジェクトはブロックをlunar-cloudとラベル付けし、ドイツの国コードを与え、/24をファルケンシュタインに配置するジオフィードにリンクしています。94.183.224.0/24の inetnum オブジェクトはブロックをLUNAR_HOSTING_LTDとラベル付けし、オランダの国コードを与えます。これらのフィールドは、アドレスリソースに添付された特定の表明であるため、関連性があります。
これらは施設アドレスの代わりにはなりません。RIPE の国フィールドは管理属性であり、ジオフィードは IP 地理位置情報を改善するために事業者が公開するロケーション表明です。どちらも、ディスクがラックにどのように固定されているか、バックアップがどこにコピーされているか、または管理者がどこから顧客データにアクセスできるかを確立するものではありません。NCSC の資産保護と回復力に関するガイダンスは、ストレージ、処理、管理の国を、プロバイダーの法的基盤、サポート場所、物理データセンターの所有権から明確に分離しています。Lunar の公開記録は、それらのレイヤーのほとんどを名前なしのままにしています。
ファルケンシュタインは、テスト可能な仮説を形成するのに十分具体的です。144.31.136.0/24の少なくとも一部のアドレスは、そのドイツの都市にあると表現されることを意図されています。Lunar のハードウェアを特定の施設事業者に帰属させるには十分ではありません。いくつかの企業が主要な欧州ホスティングロケーションとその周辺でインフラを運用しており、IP ロケーションだけでは、家主、サーバー所有者、またはリモートハンド契約者を識別できません。2番目のブロックのオランダタグはより広範であり、この記事でレビューした RIPE オブジェクトでは公開の都市レベルのアンカーを提供していません。
企業およびウェブのレイヤーは、物理的な問題を解決することなく、さらに多くの地理を追加します。Lunar は英国で登録されています。そのlunarhost.proドメインは、7月12日にテストした時点でlunarcloud.ruにリダイレクトされ、その宛先はアンチ DDoS 検証ページを表示しました。ストアフロントの DNS エンドポイントは AS198685 にはありませんでした。この分離はホスティングでは普通です。販売サイトは、顧客サーバーがプロバイダー自身のルートを使用している場合でも、保護エッジを使用する場合があります。これはまた、ウェブページの継続的な可用性が顧客マシンの健全性についてほとんど何も語らず、AS198685 の障害が販売サイトをダウンさせる必要がないことを意味します。
個人情報を扱う英国の顧客にとって、正しい質問は単に「プロバイダーは英国企業か」ではありません。ICO の更新された国際移転ガイダンスは、組織に対して、関与する別個の法的実体、契約、情報フローを理解するよう求めています。別個の海外組織によるリモートアクセスは、バイトがヨーロッパのサーバーに留まっている場合でも重要になり得ます。逆に、他国を単に通過するトラフィックは、自動的に制限付き移転と同じではありません。事実のマップには、ストレージ、バックアップ、管理、サポートを含める必要があります。
Lunar の2つの国タグ付きプレフィックスは、データローカリティを、解決された販売ポイントではなく、一次のデューデリジェンス問題にします。必要な証拠は具体的です。各サービスに選択された施設の国、ロケーションが変更可能かどうか、レプリカとサポートアクセスがどこにあるか、どの下請け業者がシステムに触れることができるか、移行に伴う通知、および終了後の残存コピーに何が起こるかです。地域を指定する請求書は、技術的および契約上の取り決めがそれを強制する場合にのみ有用です。
所有権の境界がリスクの中心である
現在の RIPE レコードは、Lunar のネットワークが企業自体を超えたリソースと組織に依存していることを示しています。AS198685 はスポンサー付き割り当てです。2つの IPv4 ブロックは、Lunar が完全に所有する明確に文書化された直接割り当てではなく、プロバイダー集約可能スペースです。144.31.136.0/24オブジェクトはサブ割り当てされたプロバイダー集約可能スペースとしてマークされ、94.183.224.0/24オブジェクトは割り当てられたプロバイダー集約可能スペースです。これらのラベルはサービスを劣ったものにするわけではありません。継続的使用が上流の商業およびレジストリ関係に依存していることを示しています。
その依存性はルート履歴に可視です。AS198685 が安定した観測起点になる前に、同じ/24が異なる時期に他の起点の下に現れました。144.31.136.0/24の履歴は、Lunar ルートの前にいくつかの起点変更を示しています。94.183.224.0/24の履歴は2026年にさらに活発で、AS198685 の現在のアナウンスに先行する複数の起点があります。アドレスリースと再起点化は、IPv4 の希少性がブロックを価値あるものにし、ポータブルにした市場では一般的です。顧客にとって、運用上の質問は、プロバイダーがアドレスを使用する権利が、それらが支えるサービスと少なくとも同じ期間続くかどうかです。
公開aut-numオブジェクトは、AS212743 および AS213529 とのインポートおよびエクスポートの取り決めを宣言しています。しかし、RIPEstat の観測近隣ビューは、レビュー日に対して1つの現在の近隣 AS202413 を示しました。レジストリポリシー宣言と観測経路は異なる質問に答え、異なる速度で変化する可能性があります。不一致は障害の証明ではありません。静的レコードをライブトポロジマップとして読むべきではないという証拠です。
これが、顧客が理解する必要のある実用的な所有権スタックです。Lunar は顧客契約を所有し、AS198685 を運用している可能性があります。別の当事者が AS をスポンサーしている可能性があります。1つ以上の当事者がアドレスブロックを供給している可能性があります。別の当事者がトランジットを提供している可能性があります。施設会社が電力、冷却、物理的アクセスを制御している可能性があります。ハードウェア賃貸人がサーバーを所有している可能性があります。軽減プロバイダーが公開ウェブサイトまたはサービストラフィックを保護している可能性があります。すべてのレイヤーは、自身の請求書、虐待ポリシー、または契約に違反した場合にサービスを停止する権利を持つ可能性があります。
この構造における最悪の障害は常に技術的とは限りません。ディスクは交換できます。ファイバーは修理できます。サプライヤーの紛争により、プロバイダーへの物理的アクセスが拒否されたり、整然とした移行のための時間がほとんどなくアドレスが削除されたりする可能性があります。小規模事業者は技術的に有能でありながら、家主や賃貸人との交渉力が弱い場合があります。そのため、企業存在の証明とルート制御の証明には、耐久性のあるサプライヤー権利の証明を加える必要があります。
顧客はすべての商業条件が公開される必要はありません。しかし、依存関係に対応する契約上の保証が必要です。可能な場合のアドレスまたは施設移行前の通知、サプライヤーがサービスを終了した場合の定義された対応、秩序ある退出中の顧客データへの継続的アクセス、および機器、電力、トランジット、物理的介入の責任を負う当事者の明確な説明です。これらの境界を名前できないプロバイダーは、顧客に監視できないリスクを負わせることになります。
ルートセキュリティは前向きなシグナルだが、経路多様性は実証されていない
観測された両方のプレフィックスは、RIPEstat を通じて確認したときに AS198685 の有効なルートオリジン認証を持っていました。144.31.136.0/24の場合、検証結果は AS198685 を有効な起点として名前を挙げ、他のいくつかの可能な起点を現在の認証の下で無効として扱いました。94.183.224.0/24の場合、有効な認証も同様に AS198685 を指しました。これは価値のある管理です。ルートオリジン検証を実行するネットワークは、起点が認可された AS と矛盾するアナウンスを拒否し、偶発的または悪意のある誤発信の1つのクラスを減らすことができます。
ルートオリジン有効性は、経路が冗長、短い、または混雑していないことを示すものではありません。プレフィックスと起点 AS の間の関係を検証するものであり、トラフィックを運ぶネットワークの全シーケンスではありません。ルーターの電源喪失、トランジット請求書の未払い、または唯一の外部セッションのリセットにより、正しく発信されたルートが消失するのを防ぐものではありません。また、アドレスの背後にあるサーバーを保護するものでもありません。
主な回復力の警告は、単一の観測近隣です。RIPEstat は一意の隣接 AS を1つカウントし、IPinfo は独立して AS198685 をシングルホームドスタブとして説明しました。測定は、プライベート相互接続やアイドル状態のバックアップセッションを見逃す可能性があり、事業者は1つのトランジットネットワークに複数の物理回線を持つ場合があります。これらの注意点があっても、公開ビューは独立した上流の多様性を実証していません。PeeringDB ネットワークレコードがないことは、事業者が施設、交換ポイント、およびピアリングポリシーを開示する別の一般的な場所を取り除きます。
2つのリンクと2つの運命の区別は重要です。同じ上流ルーターへの2本のケーブルは一緒に障害が発生する可能性があります。同じ部屋の2台のルーターは同じ電力供給を失う可能性があります。2つのキャリアが同じダクトをリースする可能性があります。異なる/24の2つのアドレスが同じホストで終端する可能性があります。真の多様性には、各関連レイヤー（物理経路、ルーター、上流ネットワーク、電力ドメイン、施設、運用チーム）での分離が必要です。ルートテーブルはその構造の一部を公開できますが、すべてではありません。
IETF のサイトマルチホーミング目標は、冗長性が耐えるべき障害（物理的切断、ルーター障害、ルーティングセッション障害、プロバイダー障害、交換障害）を説明しています。その基準に対して、Lunar の公開証拠は到達可能性を確立しますが、継続性は確立しません。トラフィックが2番目の独立したトランジットプロバイダーにフェールオーバーするという可視の証拠も、収束にかかる時間と既存のセッションが存続するかどうかを示す公開テストもありません。
IPv6 の欠如は別の制約です。IPv4 ホスティングサービスを使用不可にするわけではなく、多くの顧客は依然として IPv4 で快適に運用しています。しかし、公開ネットワークフットプリントがデュアルスタックではなく、ネイティブ IPv6 を必要とする顧客が ASN レコードからルートを推測できないことを意味します。また、公開観測されるすべてのサービスアドレッシングを、サプライヤー条件が重要な2つの希少な IPv4 ブロックに集中させます。
適切な結論はバランスが取れています。Lunar は現在の起点を認可し、両方のルートをグローバルに可視に保つことで、前向きなことを行いました。それは1つのルーティングリスクを減らします。同じ証拠は2番目の独立した経路を実証せず、現在の観測トポロジーは、上流または隣接ネットワークの障害が依然として重要な共通モードイベントであることを示唆しています。
ラック障害は仮想の約束をハードウェアに戻す
仮想化は販売される単位を変えますが、その下にある物理を変えるわけではありません。顧客は vCPU、RAM、ストレージを月額で購入するかもしれませんが、それらのリソースは依然としてプロセッサ、メモリモジュール、ドライブ、ネットワークカード、スイッチ上に存在します。それらの継続性は、電力供給、冷却、ファームウェア、ハイパーバイザー、および障害コンポーネントに到達できる人の能力に依存します。
Lunar は、顧客容量が自社所有サーバー、レンタル専用マシン、ネステッド仮想サーバー、またはそれらの混合のいずれにあるかを公開していません。各モデルは異なる障害経路を生み出します。自社所有サーバーは事業者に設定と予備部品に対するより多くの制御を与えますが、資本と物流を必要とします。レンタルハードウェアは拡張を加速できますが、交換タイミングとアクセスをサプライヤーに委ねます。ネステッド仮想化は容量を非常に柔軟にすることができますが、別の制御プレーンと、その限界がエンド顧客に不可視である可能性がある別のプロバイダーを追加します。
単一ホスト障害を考えてみてください。顧客ディスクがローカルでライブレプリカがない場合、そのホスト上のすべてのゲストは、マシンが修理されるか、ドライブが移動されるまで利用できません。ストレージが共有されている場合、コンピュートは別の場所で再起動できますが、共有ストレージはより大きなリスクの集中になります。レプリカが同じラックに存在する場合、ラック電源またはトップオブラックスイッチ障害により両方のコピーが無効になる可能性があります。レプリカが別の施設に存在する場合、回復は強力ですが、レプリケーションラグ、帯域幅、オーケストレーションにより、失われるデータ量と時間が決まります。
「バックアップ」と「スナップショット」という言葉は特に過大評価されやすいです。同じストレージシステム上のスナップショットは顧客のエラーを取り消すのに役立つかもしれませんが、ストレージ損失には耐えられないかもしれません。同じ管理アカウント内のバックアップは、同じ侵害された資格情報によって削除される可能性があります。レプリカは忠実に破損をコピーする可能性があります。NCSC の回復力ガイダンスは、既知の良好な状態に戻る能力を推奨し、可用性クレジットではなくサービス設計が損失を防ぐことを強調しています。したがって、有用な主張には、復旧ポイント目標、復旧時間目標、プライマリ障害ドメインからの分離、および復元がテストされたという証拠が必要です。
ハードウェア在庫はもう一つの隠れた制約です。プロバイダーは予備の計算容量を持っていても、互換性のあるドライブ、電源、またはネットワークカードをサイトに持っていない可能性があります。交換は、宅配業者、税関、サプライヤーの倉庫、施設アクセスウィンドウに依存する可能性があります。ハードウェアベースが未公開の新しく設立された事業者の場合、在庫された予備部品や保証された交換時間の公開証拠はありません。顧客は、チケットが確認されたことだけを意味する可能性のあるサポート応答目標と、修理または復元目標を区別する必要があります。
メンテナンスは、同じリスクの計画されたバージョンを導入します。ファームウェア変更、スイッチ交換、電力作業は、容量がドレインされ、冗長経路が証明されている場合には無害です。バックアップ経路が本番負荷を運んでいない場合、またはストレージやプロセッサの非互換性のためにゲストが移動できない場合、これらは障害になる可能性があります。Lunar は、このレビューで検証できるメンテナンスポリシー、通知期間、または最大緊急ウィンドウを公開していません。
したがって、ラックレベルの結論は、Lunar のマシンが信頼できないということではなく、その正体が判断するのに十分公開されていないということです。サービス約束は未検証の物理的依存性から分離できないということです。企業が施設モデル、ハードウェア責任、予備ポリシー、復元設計を名前で示すまで、顧客は障害がサードパーティの労働を必要とする可能性があり、復旧時間はコントロールパネルの速度によって確立されないと想定すべきです。
トランジット障害は健全なサーバーを隔離する可能性がある
サーバーは、電源が入り、冷却され、正しく動作していても、すべての顧客から到達不能になる可能性があります。それがトランジット依存性の決定的なリスクです。ホストは依然として命令を実行しますが、そのアドレスに意味を与えるルートが消失または劣化しています。
AS198685 の場合、公開ルートコレクターは1つの隣接ネットワークを確認しました。これにより、いくつかのシナリオが重要になります。BGP セッションがリセットされる可能性があります。隣接が Lunar のプレフィックスを撤回する可能性があります。物理的なクロスコネクトが障害する可能性があります。上流が輻輳または内部ルーティング障害を経験する可能性があります。DoS 対応が攻撃とともに正当なトラフィックを廃棄する可能性があります。契約上の問題により、上流がサービスの停止を引き起こす可能性があります。エンドユーザーにとっての結果は各ケースで類似しています。IP が応答を停止するか、使用できないほど遅くなることです。
両方が同じ隣接を通って出ていく場合、2つのアナウンスされた/24はその問題を解決しません。有効なルートオリジン認証も解決しません。2番目のブロックはアドレス管理とサプライヤー移行に役立ちますが、冗長性は、ルートを運ぶか運ぶ準備ができている実行可能な代替経路から来ます。公開観測はその代替経路を示していません。
公開ビューでは見えない可能性のある緩和策があります。Lunar はコールドバックアップセッションを維持したり、2番目のネットワークへのトンネルを使用したり、同じプロバイダーから複数の回線を購入したり、緊急再発信を手配したりする可能性があります。それぞれがいくつかのリスクを減らすことができます。それぞれにテストも必要です。コールドルートは伝搬に時間がかかる場合があります。トンネルは同じ障害キャリアを横断する可能性があります。2番目の回線は同じダクトを通って建物に入る可能性があります。緊急再発信は、事前に準備されていなかった場合、ルートフィルターまたは現在の認証と競合する可能性があります。
顧客はまた、DoS 保護を、独自の容量とルールを持つ経路として理解する必要があります。公開ウェブドメインのアンチ DDoS エッジは、このレビューで観測されたストアフロントを保護しますが、2つの顧客サービスプレフィックスが同じ保護を受けることを証明するものではありません。スクラビングは常時オン、オンデマンドでアクティブ化、または攻撃タイプと契約ボリュームによって制限される場合があります。プロバイダーは、顧客アドレスがヌルルーティングされている間もサポートサイトで到達可能である可能性があります。逆も起こり得ます。
性能障害は完全な撤退よりも微妙です。単一の上流は、ある地域の経路でパケット損失を被りながらもルートコレクターに可視のままである可能性があります。ある国の顧客は深刻なレイテンシを見る一方、他の顧客は通常のサービスを見る可能性があります。ルートの存在はアプリケーション品質を測定するものではなく、単一のグローバルルッキンググラストレースはサービスレベル履歴ではありません。有用な証拠には、多様なプローブ、時間経過に伴う損失とレイテンシ、インシデント記録、および1つの経路が完全に消失せずに劣化した場合にトラフィックを移動する能力が含まれます。
Lunar にとって最も示唆に富む質問は、「冗長なネットワーキングはありますか？」ではなく、「現在の設計は、顧客 IP を変更せずにどの正確な障害に耐えることができ、各フェールオーバーは負荷下で最後にいつテストされましたか？」です。信頼できる回答は、独立したトランジットプロバイダー、物理的ハンドオフ、施設、ルートポリシー、予想収束を名前で示すでしょう。その回答がない場合、可視の1近隣トポロジーは集中リスクとして扱われるべきです。
サポート労働力はインフラの一部である
ホスティングはしばしばマシンを通じて説明されます。マシンは数えられるからです。インシデント中、労働力が希少なリソースになります。誰かが障害を分類し、それが顧客設定かプロバイダーインフラかを判断し、施設に連絡し、再起動を承認し、ハードウェアを交換し、ルートを変更し、バックアップを復元し、ステータスを伝達し、急いだ回復が損害を悪化させないようにしなければなりません。
Companies House の役員ページは、レビュー時点で Lunar の活動中の取締役を1名リストしました。それは人員配置について決定的なことを何も言いません。企業は従業員を雇用したり、請負業者を使用したり、別のサービスと運用を共有したりできます。しかし、公開企業記録が広範なリーダーシップ層を明らかにしていないことを意味します。サービスサイトは、この調査中に検証可能な公開人員配置ローテーション、ネットワークオペレーションセンターの説明、またはエスカレーションマップを提供しませんでした。
薄い開示は通常の時間外に最も重要です。自動モニターは障害ホストを即座に検出するかもしれませんが、復旧は依然として権限とアクセスに依存します。ファーストレスポンダーはルートを変更できますか？その人は施設に入るか、リモートハンドに指示できますか？破壊的なストレージコマンドをレビューするために2番目のエンジニアが利用可能ですか？上流は24時間緊急要求を受け入れますか？顧客コミュニケーションは障害を修理している同じ人によって処理されますか？
小規模チームは、変動を減らし、ルーティンアクションを自動化し、サプライヤー連絡先を文書化し、強力な施設サポートを購入することで、信頼性の高いサービスを運用できます。また、複数の顧客が同じインシデントを報告すると、技術作業が最も緊急になるちょうどその時にチケット量が増加するため、過負荷になる可能性があります。1時間のファーストレスポンスは1時間の復元と同じではありません。継続的サポートの主張は、チャネル、応答目標、エスカレーションレベル、カバーされる活動を特定する場合にのみ意味があります。
虐待処理はホスティングネットワークにとって別の労働依存性です。RIPE レコードは虐待連絡先を公開しており、これは報告のための必要な公開ルートです。ホスティングアドレスは、侵害されたウェブサイトからスキャンや著作権紛争に至るまでの苦情を引き寄せます。不適切な処理はアドレスの評判を損なったり、上流の停止を引き起こしたりする可能性があります。過剰に攻撃的な処理は無実の顧客を切断する可能性があります。事業者は、タイムリーで比例した決定を下すために十分なスタッフと証拠を必要とします。
課金サポートは、サービスアクセスが自動化されている場合に運用サポートになり得ます。更新失敗、不正フラグ、または決済プロバイダーエラーにより、すべての技術コンポーネントが健全であってもサーバーが停止される可能性があります。顧客は、停止後にデータが復元可能かどうか、どのくらい保持されるか、異議申し立てが削除を一時停止するかどうか、緊急の課金エラーがどのようにエスカレーションされるかを知る必要があります。これらのポリシーは、プロバイダーの公開容量と所有権チェーンが十分に文書化されていない場合に特に重要です。
NCSC の運用セキュリティ原則は、脆弱性管理、監視、インシデント対応、変更管理をサービスの特性として扱います。その枠組みはここで有用です。人と決定はホストされた製品の一部です。Lunar の公開ネットワーク記録はアドレスとルートを示しますが、同等の公開証拠はまだパッチ時間、インシデント通知、変更通知、サポート深度を確立していません。
移行はプロバイダーが修正できない障害からの回復経路である
すべてのホスティング評価は最終的に終了質問に達します。冗長性はプロバイダー内部でサービスを稼働し続けようとします。移植性は、プロバイダー、サプライヤー関係、または商業的取り決め自体が障害コンポーネントである場合に顧客が回復することを可能にします。
移植性はファイルのダウンロード以上のものです。動作中のサービスには、仮想ディスク、オブジェクトデータ、リレーショナル状態、DNS ゾーン、証明書、ファイアウォールルール、プライベートネットワーク、割り当てられた IP、監視履歴、アクセスログ、自動化資格情報、およびそれを構築した人のみが知っているドキュメントが含まれる場合があります。これらの要素の多くが独自のコントロールパネルまたはアクセスできないプロバイダーアカウントに閉じ込められているほど、移行にかかる時間は長くなります。
Lunar は、レビューされたサービスフットプリントの検証可能なエクスポート仕様を公開していません。したがって、顧客が完全なディスクイメージを取得できるかどうか、どのフォーマットがサポートされているか、大規模なエクスポートに転送料金が発生するかどうか、終了したアカウントがどれだけ迅速に消去されるか、障害サーバーがまだエクスポート可能かどうかは不明です。また、顧客 IP アドレスが移植可能かどうかも不明です。可視プレフィックスが他の当事者を通じて供給されるプロバイダー集約可能スペースであることを考えると、典型的な小規模顧客は、契約に別段の定めがない限り、割り当てられた IP はプロバイダーに留まると想定すべきです。
その想定には結果が伴います。ウェブサーバーを新しいアドレスに移動するには、DNS 変更、証明書チェック、ファイアウォール更新、許可リスト変更、およびキャッシュの期限切れの時間が必要になる場合があります。メールサービスを移動すると、送信者レピュテーションと逆 DNS が混乱する可能性があります。パートナーが IP にハードコードしたアプリケーションを移動するには、そのディスクを移動するよりも長い時間がかかる場合があります。プロバイダーはコンピュートを移植可能にしながら、アドレスを最も強力なロックインとして残すことができます。
最も安全な移行設計はインシデントの前に始まります。顧客はインフラ定義をプロバイダーの外部に保持し、暗号化キーと DNS アクセスの独立したコピーを維持し、アプリケーションデータを定期的にエクスポートし、2番目の環境への復元をテストできます。これらのアクションは顧客の責任であり、プロバイダーの明確さの代わりにはなりません。NCSC の共有責任モデルの下では、セキュリティと可用性の義務はサービスモデルに依存し、両当事者によって理解されなければなりません。
終了テストは時間を計り、完全であるべきです。関連する尺度は、ファイルがどれだけ速くダウンロードできるかではなく、許容可能なデータ損失で別の場所に機能するサービスを復元するのにどれだけ時間がかかるかです。テストには、最大の現実的なデータセット、DNS や証明書などの依存関係、および元のデプロイメントを設計した人以外の誰かによる検証を含めるべきです。これが一度も行われたことがない場合、移植性は願望のままです。
プロバイダー契約障害には独自のシナリオがあります。Lunar がラック、アドレスサプライヤー、またはトランジット契約を失った場合、終了前に顧客データを取得し、サービスを移動できますか？契約上の治癒期間がありますか？顧客は基盤となる施設に連絡できますか、それともそれはセキュリティと商業的境界に違反しますか？バックアップはプライマリサプライヤー紛争を生き残る別のアカウントの下に保持されていますか？公開記録はこれらの質問に答えませんが、階層化されたリソース構造はそれらを重要にします。
顧客にとって、移行経路が依存の究極の制限です。ワークロードが他の場所で簡単に再作成できる場合、低い月額料金は控えめな冗長性でも合理的であり得ます。同じサービスは、終了に数週間かかる場合、ユニークなデータやハードコードされた公開エンドポイントにとっては悪い取引になる可能性があります。Lunar の現在の証拠は、顧客のためにそのリスクを価格設定するのに十分強力ではありません。サービス条件と復元テストだけがそれができます。
データ主権は IP 上の旗ではなく、制御の地図である
Lunar のフットプリントは、いくつかの管理的シグナルを横断しています。英国企業、ファルケンシュタインジオフィード付きドイツタグブロック、オランダタグブロック、およびロシアの国コードドメイン下のウェブ宛先です。これらの事実のどれも単独では、顧客データのすべてのコピーを管理する管轄区域を識別しません。
データ主権はロケーションから始まりますが、制御にまで及びます。ディスクはドイツにありながら、別の国のサポートスタッフがその管理コンソールを開くことができるかもしれません。バックアップは第2のリージョンにコピーされるかもしれません。ログは他の場所の監視サービスに送られるかもしれません。課金プロバイダーは顧客の身元と支払いデータをさらに別の管轄区域に保持するかもしれません。法人化された英国の再販業者は、英国以外のインフラサプライヤーと契約するかもしれません。各関係は、どの組織が情報にアクセスできるか、およびどの法的プロセスが情報に到達できるかを変更します。
ICO は移転と通過の間の有用な区別を行っています。他国を経由してルーティングされるパケットは、情報がアクセスまたは保存されることなく英国組織間で移動している場合、必ずしも制限付き移転ではありません。個人情報を別個の海外組織にアクセス可能にすることは、一括コピーがなくても移転となり得ます。これが、traceroute と IP 地理位置情報が法的評価を完了できない理由です。契約とアクセス設計が重要です。
Lunar の公開資料は、処理者チェーン、サポート国、バックアップロケーション、または顧客選択可能なレジデンシーコントロールを特定していません。したがって、ドイツとオランダのタグは手がかりとして扱うのが最善です。特定のレジデンシー結果を求める顧客は、サービス注文に対して、選択されたロケーションの名前指定、移動とリモートアクセスの制限、サブプロセッサの特定、バックアップ地理の説明、および変更の通知を要求すべきです。同じ条件が、プライマリストレージだけでなくメタデータとログもカバーする必要があります。
暗号化は露出を変更しますが、すべてのローカリティ問題を消去するわけではありません。顧客保有キーは、スナップショット、ログ、メモリが一貫して扱われる場合、プロバイダーが保存データを読み取る能力を減らすことができます。しかし、施設停止中にアプリケーションを利用可能に保つことはできず、宣言されていない移転をそれ自体で許容可能にするわけでもありません。また、キー管理が不十分な場合、復旧を不可能にする可能性があります。ロケーション、アクセス、暗号化、復元可能性は一緒に分析されるべきです。
ネイティブ IPv6 の欠如は直接主権を決定するわけではありませんが、より広いポイントを示しています。サービスの特性は、クラウドラベルから推測されるのではなく、観察され契約される必要があります。同様に、英国の会社番号はすべてのサーバーを英国リージョンにするわけではなく、ドイツのジオフィードはドイツのみの管理を証明するわけではありません。
規制対象または機密データを持たない顧客は、価格またはパフォーマンスと引き換えに広範なロケーション柔軟性を合理的に受け入れる可能性があります。法的、契約上、またはクライアントから課されたレジデンシー義務を持つ顧客は、より高い証明基準を必要とします。現在のところ、Lunar の公開フットプリントはその証明を提供していません。しかし、サービスがいずれかの管轄区域にローカルとして扱われる前に回答しなければならない質問を知るのに十分な情報を提供しています。
証拠グレードを動かすもの
Lunar のルート可視性は、その一般的な公開プロフィールよりも強力です。企業は活動中であり、AS198685 がアナウンスされ、2つの/24が可視であり、両方の現在の起点がルートオリジン認証の下で検証されます。これらの事実は、稼働中の小さなネットワークフットプリントを説明することを正当化します。グレードは Weak のままです。なぜなら、証拠がサービスの物理的、契約的、および回復レイヤーに達していないからです。
いくつかの開示が信頼を大幅に改善するでしょう。まず、各サービス区分に使用される国と施設事業者を名前で示し、自社所有機器とレンタルサーバーを区別するロケーションと所有権の表明です。ラック番号やセキュリティに敏感な図を明らかにする必要はありません。電力、冷却、リモートハンド、交換ハードウェアを誰が制御するかを特定すべきです。
2つ目は現在のネットワークステートメントです。AS198685 に1つまたは複数の独立した上流があるかどうか、物理経路とエッジルーターが多様かどうか、どのプレフィックスが DoS 保護を受けるか、ネイティブ IPv6 が計画されているか、別のサービスを通じて利用可能かを説明すべきです。公開 PeeringDB エントリと一貫した RIPE ポリシーオブジェクトにより、トポロジーの検証が容易になりますが、観測されたルートは依然として必要です。
3つ目はサービス固有の可用性とメンテナンス条件です。有用な文書は、何が利用不可とみなされるか、測定ポイント、除外イベント、計画作業の通知、緊急メンテナンス処理、サポート応答目標、および救済策を定義するでしょう。クレジットだけでは回復力を生み出しませんが、正確な条件はプロバイダーが何を測定しようとしているかを示します。
4つ目は回復証拠です。バックアップ範囲、分離、保持、顧客コントロール、復旧ポイントと復旧時間目標、日付入り復元テスト結果です。最も強力なバージョンは、ホスト、ラック、サイト障害を分離し、各サービス階層がどれに耐えるかを述べるでしょう。バックアップが存在するという表明は、復元結果がなければわずかな改善にすぎません。
5つ目は移植性条件です。顧客は、利用可能なエクスポートフォーマット、転送制限と料金、停止後の保持、削除タイミング、終了中のアクセス、および IP アドレスが移動可能かどうかを知るべきです。別のプロバイダーへの文書化された移行演習は、抽象的な終了約束を運用証拠に変換するでしょう。
最後に、Lunar は簡潔なサプライヤーと管轄区域の説明を公開できます。顧客と契約する法的実体、ネットワークを運用する実体、インフラとサポート下請け業者のカテゴリ、および顧客データが保存またはアクセスされる可能性のある国です。これにより、顧客は英国企業とドイツおよびオランダのネットワークタグを調整するのに役立つでしょう。
これらの要求のどれも、若いまたは小規模なプロバイダーが不健全であると想定していません。小規模事業者は、密接なサポート、シンプルな製品、良い価値を提供できます。ポイントは、主張を証拠と一致させることです。今日、可視ネットワークは単なる登録以上のものを証明しますが、回復力のあるクラウドには及びません。最も防御可能な解釈は、LUNAR HOSTING LTD が、そのラック、トランジット、修理労働力、サプライヤー権利が大部分公開視野の外にあるチェーンの最上部で容量を販売しているということです。
購入決定はワークロードの不確実性に対する許容度に従うべき
簡単に再構築できる開発サーバー、一時的なリレー、またはレプリケートされたエッジノードの場合、価格と直接のサービス体験が良ければ、Lunar の小さな公開フットプリントは許容可能なリスクかもしれません。顧客は信頼できるデータを他の場所に保持し、交換を自動化し、アドレス変更をルーチンとして扱うことができます。そのユースケースでは、欠落した公開詳細は、サービスを完全に拒否するのではなく、露出を制限する理由です。
ビジネスデータの唯一のコピー、レイテンシに敏感な本番システム、規制対象の個人情報、または迅速に変更できない公開エンドポイントの場合、同じ不確実性は異なるコストを持ちます。単一の観測近隣、未検証のサイト冗長性、未知の予備在庫、文書化されていないエクスポート経路は、システム自身のリスクの一部になります。顧客は、サービスに依存する前に、直接的な契約証拠と独立したバックアップを必要とするでしょう。
関連する質問は具体的です。どの法的実体が注文に署名しますか？どの施設と国がプライマリデータとバックアップを保持しますか？誰がサーバーを所有しますか？ホスト、ラック、ルート、またはサプライヤーが障害した場合どうなりますか？どの経路が真に独立していますか？認可されたエンジニアはどれだけ迅速に行動できますか？どの正確な状態をエクスポートできますか？停止後、データはどのくらい保持されますか？完全な復元が最後に行われたのはいつで、どれくらい時間がかかりましたか？
回答は公開記録と一致すべきです。サービスがドイツに配置されているとして販売されている場合、施設とバックアップの表明はファルケンシュタインジオフィードと一致するか、そうでない理由を説明すべきです。プロバイダーが多様なトランジットを主張する場合、現在のルート観測は最終的に複数の実行可能な近隣を示すか、プロバイダーがスタンバイ設計を説明すべきです。可用性の主張が複数のサイトに依存する場合、サービスアーキテクチャは障害ドメインとレプリケーション動作を特定すべきです。
顧客はまた、変化を監視すべきです。現在の企業と ASN はわずか数ヶ月前です。アドレス起点、近隣、ウェブ宛先、サプライヤー関係はすでに短期間で変化しています。それは若いネットワークの通常の構築を反映する可能性があります。また、一度行われた評価はすぐに古くなることを意味します。ルート可視性、認証、サービス条件、エクスポート能力は、更新時および宣言された移行後に再確認されるべきです。
最終判断は意図的に限定されています。LUNAR HOSTING LTD は、ペーパーカンパニー以上のものとして扱われるのに十分な現在の証拠を持っています。自律システムはグローバルに可視なアドレススペースを発信し、起点は認証され、二次測定はホスティングのような活動を見ます。提供される容量をマルチサイト、独立接続、または実証可能に復元可能として扱うのに十分な公開証拠はまだありません。
そのギャップがストーリーの中心です。ホストされた容量は、すべての依存関係が機能している間だけ抽象的で感じられます。ラック障害はそれをハードウェアにします。ルート撤回はそれをトランジットにします。ドライブ障害はそれを予備在庫にします。未回答のインシデントはそれを労働力にします。終了したサプライヤー契約はそれを契約法にします。テストされていないエクスポートはそれを顧客ロックインにします。Lunar の公開ネットワークは可視です。その背後にある回復力はまだ十分に可視ではありません。