要約
- Global Cloud Ltd は、単なる名簿上の名前ではなく、RIPE で確認できる実際のネットワーク事業者です。RIPE 組織オブジェクト ORG-GCL12-RIPEは Global Cloud Ltd を明記し、イスラエルの登録番号
514919729を提供し、組織タイプLIRを示し、イスラエル、エメク・ヘフェルの HaMasik St 4 という住所を記載し、同社ウェブサイトに表示されている電話番号と同じものを掲載しています。 - 同社は AS61365 に関連付けられており、RIPEstat の AS 概要では、ホルダーが
GC-5222 Global Cloud Ltdと表示され、問い合わせ日（2026年7月11日）時点で AS がアナウンスされていました。RIPEstat のルーティングステータスビューでは、4 つの IPv4 プレフィックス、1,024 の可視 IPv4 アドレス、可視 IPv6 プレフィックスなし、2 つの隣接ノードが表示されました。 - 同社のアドレス空間は独立した第三者ブロックではありません。RIPE RDAP プレフィックス登録 185.184.16.0/22およびRIPEstat の whois ビューでは、
IL-GLOBAL-20170102、国 IL、組織ORG-GCL12-RIPE、ステータスALLOCATED PA、およびgeofeed.xprsit.netの geofeed ファイルが示され、/22 全体と各 /24 がエメク・ヘフェルに関連付けられています。 - ルート起点の保証は、多くの小規模ホスティング事業者よりも優れています。RIPEstat の RPKI 検証応答は、185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24のすべてで、185.184.16.0/22 の ROA（最大長 24）の下で
validを返しました。 - トランジットプロバイダーの状況については、顧客によるテストがまだ必要です。RIPE aut-num オブジェクトには AS1680、AS212616、AS8551 のポリシーがリストされていますが、RIPEstat のASN 隣接ビューでは AS1680 と AS212616 が観測された隣接として表示され、AS ルーティング一貫性ビューでは、whois ポリシーに AS8551 が含まれているものの、問い合わせ時点で BGP には現れていませんでした。
- 証拠レベルは中程度です。公開情報源は、法人格、ネットワークリソースの管理、現在の IPv4 到達性、ルート起点検証を強く裏付けています。しかし、ラック数、施設の所有権、予備ハードウェアの豊富さ、テスト済みのマルチサイト復旧、実際の顧客ワークロードの範囲、契約上のサポート応答時間、データポータビリティの制限を証明していません。
公開記録は具体的だが、クラウド容量は実証が必要
Global Cloud Ltd は、集約リストにしか現れない空のホスティング名とは異なる扱いを受けるに値します。同社は公的なネットワークアイデンティティ、公式ウェブサイト、RIPE LIR ステータス、RIPE 組織オブジェクト内のイスラエル登録番号、アクティブな自律システム、登録済みの IPv4 割り当てを持っています。RIPE RDAP aut-num 登録（AS61365）では、AS 名がGC-5222とされ、Global Cloud Ltd が組織エンティティとしてリストされ、住所 HaMasik St 4、エメク・ヘフェル、イスラエルが繰り返されます。同社の英語版ホームページでは、連絡先として Hamasek 4, Emek Hefer Industrial Park が記載され、電話番号 072-274-3030 が掲載され、開発、ストレージ、セキュリティに関連するサービスが説明されています。
この組み合わせにより、同社は分析可能な程度に十分に観測可能です。しかし、外部から完全に検証可能なわけではありません。クラウド、ホスティング、仮想デスクトップ、マネージドサービスを購入する顧客は、AS 番号だけを購入するのではありません。ラック、回線、光インターフェース、ルーター、ハイパーバイザー、ストレージ、バックアップジョブ、ライセンス、サポートチーム、電源、アクセス制御、課金システム、移行手順に依存します。公衆インターネットは AS61365 が到達可能であることを示せますが、特定の顧客ワークロードがストレージ棚の故障、プロバイダーとの紛争、停電、ルーティング変更後に復旧できるかどうかは示せません。
したがって、Global Cloud を読む最も有用な方法は、それを中規模のインフラストラクチャ表面として捉え、推測を避けるのに十分な公開証拠がありつつ、デューデリジェンスを要求するだけの運用詳細が不足していると見ることです。同社ウェブサイトの英語版クラウドサービスページによると、データセンターおよびクラウドサービス、DaaS、PaaS、Infrastructure as a Service、コラボレーションサービス、IT サービス、ソフトウェアサービスを提供しています。また、サポートチームが 24 時間年中無休で稼働し、Global Cloud がセキュリティと存続可能性を重視していると述べています。これらは関連性のあるサービス主張ですが、回復可能性のテストに取って代わるものではありません。
証拠には、ちょっとした編集上の手がかりも含まれています。英語版クラウドページの一部では「Xpress Technologies」に言及している一方、ドメイン、RIPE 登録、フッターでは Global Cloud と記載されています。これは、古いコンテンツ、テンプレートの残骸、関連ブランド、翻訳の産物である可能性があり、公開証拠では判断できません。顧客にとってのリスクポイントは、この名称の不一致が否定的な意味を持つことではなく、幅広いクラウドの約束を、古いまたは一貫性のないウェブコンテンツから推測するのではなく、現在のサービス契約、現在のプラットフォーム設計、現在のサポート制限と整合させるべきだということです。
この記事における運用上のテーゼは単純です：Global Cloud Ltd は実際のイスラエルのネットワークフットプリントと、顧客依存を生み出すのに十分な広範な公開サービスカタログを持っています。購入者の仕事は、このカタログのどの部分が実際に導入されているか、物理的にどこにホストされているか、ルートがどのようにフェイルオーバーするか、営業時間外にスタッフがどのように対応するか、そしてサービスがもはや適合しない場合にワークロードがどのようにサービスを離れられるかを検証することです。
AS61365 が Global Cloud に計測可能な優位性を与える
企業固有の最も強力な証拠は AS61365 から始まります。RIPEstat の AS 概要では、ホルダーがGC-5222 Global Cloud Ltdと表示され、問い合わせ日（2026年7月11日）08:00 UTC 時点で AS がアナウンスされていました。RIPEstat のルーティングステータスエンドポイントでは、4 つの IPv4 プレフィックス、1,024 の IPv4 アドレス、IPv6 プレフィックスなし、327 の RIS IPv4 フルフィードピア中 326 がルートを認識していること、IPv6 の可視性はゼロであることが示されました。現在アナウンスされている 4 つのプレフィックスは、アナウンスされたプレフィックスの応答によると、185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 でした。
これは重要なネットワークの入り口です。しかし、ハイパースケールレベルのフットプリントではありません。/22 を 4 つの /24 アナウンスに分割すれば、顧客サービス、ホステッドプラットフォーム、VPN、電子メール、オフィスサービス、管理ネットワーク、静的アクセスクライアント、またはこれらの組み合わせに対応できます。それ自体で広大なパブリッククラウドドメインを証明するものではありません。アナウンスされた IPv4 アドレスの数は、サーバー、仮想マシン、テナント、バックアップリポジトリ、復旧ターゲットの数ではありません。RIPEstat に IPv6 が表示されないことも重要です。なぜなら、多くの購入者にとって IPv6 対応は、当面のサービスが IPv4 で動作するとしても、ネットワーク計画の一部となっているからです。
RIPEstat のプレフィックスカウントエンドポイントは有用な履歴を追加します。これは、以前の可視性変更の後、現在の Global Cloud モデルが 4 つの IPv4 プレフィックスであることを示し、2026年7月11日の問い合わせウィンドウ中に IPv6 プレフィックスカウントがないことを示しています。ルーティング履歴エンドポイントは、2012～2014 年に 94.30.220.0/24 の AS61365 の以前の可視性を示し、その後 2017 年から 185.184.16.0/22 ファミリーを示しています。この履歴は、ルーティングレベルでは肯定的な兆候です。AS61365 は 1 週間の実験ではありません。
しかし、ルートの連続性はサービスの連続性ではありません。94.30.220.0/24 の古い履歴から 185.184.16.0/22 ファミリーへの移行は、プロバイダー、サービス、アドレス空間リソースの取得、顧客ベースの変更、または単に異なるプレフィックスの可視登録を反映している可能性があります。パブリック BGP はビジネス上の理由を説明しません。異なる期間にルートが観測されたこと、および現在のルーティングされたフットプリントが 185.184.16.0/22 下の 4 つの /24 で構成されていることだけを示します。
したがって、顧客は AS61365 を強力な出発点の事実であり、弱い最終証拠と見なすべきです。詳細な質問をする根拠にはなりますが、回答の代わりにはなりません。Global Cloud が仮想サーバーを販売する場合、購入者はホストとストレージのアーキテクチャが必要です。サービスとしてのデスクトップを販売する場合、購入者はユーザーセッション容量、アイデンティティ依存関係、リンクパフォーマンスが必要です。マネージドアプリケーションを販売する場合、購入者は運用所有権とバックアップの詳細が必要です。IaaS を販売する場合、購入者はスタックのどの部分が自動化され、どの部分が手動で管理されるホスティング領域かを知る必要があります。
/22 割り当ては制御を裏付け、無制限の規模を保証しない
アドレス空間に関連する証拠は、ルーティングされたプレフィックスを Global Cloud に結びつけるため特に有用であり、全く別のアドレス貸主に結びつけるわけではありません。RIPE RDAP プレフィックス登録185.184.16.0/22 では、ハンドル185.184.16.0 - 185.184.19.255、名前IL-GLOBAL-20170102、タイプALLOCATED PA、国 IL、組織エンティティ Global Cloud が示されています。RIPE REST inetnum オブジェクトは同じ割り当てを繰り返し、geofeed URL を追加しています。組織オブジェクトは Global Cloud Ltd を LIR として提示しています。これは、単に誰かのブロックをアナウンスする小規模プロバイダーよりも強力なアイデンティティポジションです。
レジストリのより具体的なラベルは、顧客の使用を証明せずに色を追加します。RIPEstat のアドレス空間階層応答では、185.184.16.0/24 がSHVDOM-1-Subnet、185.184.17.0/24 がSHVDOM-Core-Subnet、185.184.18.0/24 がLNS-Static-Subent、185.184.19.0/24 がSHVDOM-Subnetとしてリストされています。これらの名前は内部セグメンテーションと、少なくとも 1 つの静的またはネットワークサービスラベルを示唆しています。各サブネットからどの製品が販売されているか、どの顧客がそれを使用しているか、またはラベルが運用上の説明なのか管理上の名前なのかは証明されません。
この区別はホスティング経済の中核をなします。プロバイダーはアドレス割り当てを所有または運用していても、その背後に限定的なインストール済みサーバー容量しか持たない場合があります。プロバイダーは、ある /24 を顧客静的サービスに、別の /24 を管理またはコア機能に、さらに別の /24 をホステッドワークロードに使用するかもしれません。また、コントロールプレーンやウェブサイトが別のネットワークにあるサービスを販売する場合もあります。パブリックアドレスのマップは購入者にどこから始めるかを教えますが、依存関係がどこで終わるかは教えません。
企業のパブリックウェブサイトがこの点を例証しています。調査中に行われた簡単な DNS ルックアップでは、globalcloud.meおよびwww.globalcloud.meが 212.29.210.119 に解決され、RIPEstat の 212.29.210.119 の whois ビューでは、このアドレスが Global Cloud の 185.184.16.0/22 割り当てではなくIL-NETVISION-980831内に配置されています。これは珍しいことではありません。多くのプロバイダーは、マーケティングサイトを別の事業者や別のプラットフォームでホストしています。重要なのは、ウェブサイトのエンドポイントが、顧客のクラウドワークロードが存在する場所の証拠と見なされるべきではないということです。
したがって、顧客にとって正しい質問は「Global Cloud はアドレスを所有しているか？」ではありません。所有しています。より良い質問は、これらのアドレスがサービスにどのように割り当てられているか、顧客の IP アドレス割り当てが移植可能かどうか、逆引き DNS とレピュテーションがどのように管理されているか、番号変更がどのように機能するか、そして Global Cloud がトランジットプロバイダー、サブネット、またはサービスプラットフォームを変更した場合に購入者が十分な事前通知を受け取るかどうかです。
RPKI は現在の公開証拠における真の強み
ルート起点検証は、Global Cloud のフットプリントが情報不足のベースラインよりも堅固に見える数少ない公開チェックの 1 つです。RIPEstat の RPKI 検証エンドポイントは、185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 について、AS61365 で問い合わせた際にvalidを返しました。各応答は、185.184.16.0/22 の有効な ROA（オリジン AS61365、最大長 24）を指していました。これは、現在の 4 つの /24 アナウンスが、問い合わせ時点で公開されたルート起点許可と一致していることを意味します。
技術的価値は狭いが実在します。RFC 6811では、BGP プレフィックス起点検証は、ルーターがプレフィックスをアナウンスしている AS がプレフィックス保持者によって許可されているかどうかを判断する手段と説明しています。RPKI はパケットを暗号化せず、すべてのルートリークを防止せず、パスが最適であること、データセンターが回復力があること、またはアプリケーションセキュリティを解決することを証明しません。しかし、ネットワークが検証ポリシーを適用する場合、誤った起点アナウンスのリスククラスを低減します。
Global Cloud にとって、ルーティングされたフットプリントがコンパクトであるため、これは重要です。現在可視の 4 つの /24 と可視の IPv6 がない場合、ルート起点の誤りは、パブリックサービス表面の大部分に影響を与える可能性があります。現在の /24 アナウンスに有効な ROA があることは、unknownやinvalidの結果よりも良い出発点を顧客に提供します。また、アドレス保持者とオリジンの間の関係に、少なくとも 1 つの現代的なルーティングセキュリティ制御が設定されていることも示しています。
留保すべき点は、RPKI が顧客 SLA ではないことです。RPKI は、AS1680、AS212616、またはその他のトランジットパスに、障害後にトラフィックを伝送するのに十分な容量があるかどうかを示しません。ルーターが冗長化されているかどうかも示しません。DDoS 防御が有効かどうかも示しません。顧客バックアップが回復可能かどうかも示しません。運用上の各ルートオブジェクトが整っているかどうかさえ示しません。RIPEstat のプレフィックスルーティング一貫性応答は、whois 内に集約ルートオブジェクト 185.184.16.0/22 が存在し、BGP と whois の両方に 185.184.19.0/24 が存在し、BGP には 185.184.16.0/24、185.184.17.0/24、185.184.18.0/24 のアナウンスが存在するが、この特定の一貫性ビューでは対応する whois ルートオブジェクトがないことを示しました。RIPEstat のAS ルーティング一貫性応答も同じ不一致を示しています。
この不一致は、RPKI ステータスが有効であり、集約ルートオブジェクトが存在するため、危機ではありません。それでも有用な運用証拠です。顧客は、Global Cloud が /24 に対して意図的に集約ルートオブジェクトと RPKI に依存しているのか、トランジットプロバイダーが使用する IRR フィルターが現在のアナウンスを受け入れるのか、ROA やルートオブジェクトの更新を保護する変更管理プロセスは何かを尋ねるべきです。レジストリビューの小さな不一致は、メンテナンス中にプロバイダーフィルター、ルートサーバー、またはトランジットプロバイダーがそれを異なって解釈する場合、重大なインシデントになる可能性があります。
要するに、RPKI は強みです。現在の制御として認識し、それから適切な場所に位置づけるべきです。
トランジットの多様性は可視だが、フェイルオーバーのストーリーは未完成
最も重要な運用上の質問は、ポリシーオブジェクトに表示されるプロバイダー名の数ではありません。1 つのパス、ルーター、相互接続、または商取引契約に障害が発生した場合に、どのパスがトラフィックを伝送できるかです。Global Cloud の公開記録は、この質問を正確に行うのに十分な証拠を提供します。
RIPE aut-num オブジェクト（AS61365）には、AS1680、AS212616、AS8551 のポリシーエントリが含まれています。RIPEstat は、AS1680を Cellcom Fixed Line Communication L.P、AS212616を K.M.A ADVANCED TECHNOLOGIES LTD、AS8551を Bezeq International Ltd として特定しています。これらは真剣なイスラエルのネットワーク名です。しかし、ASN 隣接エンドポイントでは、利用可能な最後の問い合わせ時点で、観測された隣接ノードは AS1680 と AS212616 の 2 つでした。AS ルーティング一貫性エンドポイントでは、AS1680 と AS212616 が BGP と whois の両方に存在し、AS8551 はその時点で whois には存在するが BGP には存在しませんでした。
パスサンプルは画像を洗練させます。185.184.16.0/24 の場合、サンプリングされた BGP パスは AS1680 AS61365 で終了していました。185.184.17.0/24 と 185.184.18.0/24 の場合、観測された支配的な最終ホップパターンも AS1680 AS61365 で終了していました。185.184.19.0/24 の場合、観測されたパターンは AS1680 AS212616 AS61365 で終了していました。これは完全な事業者マップではなく、パブリックコレクターはプライベートまたは低可視性のセッションを見逃す可能性があります。それでも、異なる /24 が異なる隣接または準隣接パスをとる可能性があり、AS212616 が少なくとも 185.184.19.0/24 ビューではルートパスに表示されるという有用なヒントです。
顧客は、より多くの証拠なしに、これを「単一ネットワーク接続」または「完全冗長」と解釈すべきではありません。「部分的に可視のマルチホーミングまたはプロバイダーポリシーの複雑さ」と読む方が良いでしょう。顧客は、どの ASN がアクティブな本番トランジットであり、どれがバックアップ、どれが履歴、どれが特定の顧客サービスを伝送するかを尋ねるべきです。回答には、帯域幅コミットメント、ルーターの多様性、相互接続の物理的多様性、メンテナンスウィンドウ、DDoS 管理、エスカレーション連絡先、最近のフェイルオーバーテストを含めるべきです。
障害パスは具体的です。AS1680 で地域インシデントやルーティングフィルターの問題が発生した場合、4 つの /24 はすべて AS212616 または別のパスを介して継続できますか？AS212616 が 185.184.19.0/24 パスの一部である場合、どの顧客サービスがこの /24 に依存していますか？AS8551 がポリシーオブジェクト内にあるが現在 BGP で可視でない場合、それはスタンバイセッション、非アクティブな過去の取り決め、計画されたパス、またはポリシーの産物ですか？障害後にトラフィックがフェイルオーバーする場合、プロバイダーはパケット損失を回避するのに十分な上流容量とクリーンなルートプリファレンスを持っていますか？
これらの質問は非難的ではありません。これらはサービスカタログと運用設計の違いです。ホスティングプロバイダーは、テスト済みのルート、予備容量、明確なエスカレーションがあれば、コンパクトなパブリックエッジから回復力のあるサービスを正直に販売できます。また、最初の主要なラックまたはプロバイダーインシデントまでうまく機能する狭い依存関係チェーンから広範なカタログを販売することもできます。公開データは、Global Cloud をこれら 2 つの結論の間のどこかに配置します。顧客の直接的なデューデリジェンスが、現実がどちらに近いかを決定します。
エメク・ヘフェルは強力な地域シグナルだが、ラック証明書ではない
Global Cloud には、重複する複数のイスラエル地域シグナルがあります。RIPE 組織オブジェクトでは、HaMasik St 4, 3877701, エメク・ヘフェル, イスラエルが示されています。RDAP aut-num エンティティもこの住所を繰り返しています。Global Cloud のホームページでは、Hamasek 4, Emek Hefer Industrial Park と、同じ電話番号が記載されています。RIPE inetnum オブジェクトで参照されている geofeed ファイルは、185.184.16.0/22 と各 /24 をIL, IL-HA, Emek Heferに関連付けています。
これは、同社とそのアドレス空間の主要な公開ロケーションシグナルとして、イスラエルとエメク・ヘフェルを議論するのに十分です。しかし、すべての顧客ワークロード、バックアップ、ログ、管理者セッション、または災害復旧コピーが物理的にエメク・ヘフェルにあると言うには十分ではありません。IP レジストリの住所、geofeed の地域、連絡先情報は施設監査にはなりません。プロバイダーは、あるサイトでラックを運用し、別のサイトで容量をリースし、リモートバックアップサービスを使用し、クラウドプラットフォームを介してサポートツールを実行し、他の事業者で一部のパブリックサービスをホストする場合があります。
地理位置情報は、注意が必要な理由も示しています。RIPEstat のgeoloc ビューおよびMaxMind GeoLite ビューでは、/22 がイスラエル内だがエメク・ヘフェルではなく Ar Rayna に配置されていました。この衝突は geofeed を否定するものではありません。IP 地理位置情報データベースはしばしば異なり、geofeed データは事業者の意図または自己公開された地域を表すことがあります。これは、購入者が IP 地理位置情報ルックアップを物理的配置の保証として使用すべきではないことを証明します。
地域性が重要なのは、Global Cloud のサービスカタログにデータセンタータイプ、クラウド、デスクトップ、プラットフォーム、ソフトウェア、バックアップのサービスが含まれているからです。イスラエルプライバシー保護機構のデータセキュリティに関する公式ページでは、民間および公共部門に適用されるデータセキュリティ規制について説明し、データベースセキュリティに関する組織的メカニズムを確立しています。同じ政府ポータルは、欧州経済領域からイスラエルに転送されるデータに関するプライバシー規制文書を公開しています。これらの公式ページは、Global Cloud のどの顧客が個人データを処理しているか、または Global Cloud が特定の契約でプロセッサーとして行動しているかは教えてくれません。それらは、購入者がデータローカリティを単なるマーケティングフレーズにできない理由を説明しています。
顧客にとって、実用的な質問は単純です。プライマリワークロードはどこにホストされていますか？バックアップはどこに保存されていますか？バックアップは暗号化されテストされていますか？イスラエル国外からシステムにアクセスできる従業員、請負業者、ベンダーは誰ですか？ログ、監視フィード、サポートチケット、またはアイデンティティシステムは外国のプラットフォームで処理されていますか？顧客がイスラエル、EEA、またはセクター固有のデータ処理を証明する必要がある場合、Global Cloud はどのような契約および技術的制御を提供しますか？
Global Cloud の公開証拠は、同社がイスラエルのネットワークおよびオフィスフットプリントを持ち、クラウド隣接サービスを販売するため、データ主権とローカリティのテーマをサポートします。包括的なコンプライアンス宣言をサポートするものではありません。
サービスカタログは深刻な顧客依存を生み出すのに十分広い
Global Cloud の英語版クラウドページは、単純なウェブホスティングの提案に限定されていません。データセンターおよびクラウドサービス、エンタープライズシステムとエンドポイント間の統合、継続的な監視とメンテナンス、VMware および KVM/XEN/Hyper-V タイプのプラットフォームでの仮想化、安全なインターネット接続、安全なストレージ、DaaS、PaaS、Infrastructure as a Service、コラボレーションサービス、IT as a Service、Software as a Service について説明しています。英語版ホスティングページは、データセンターとクラウドのテーマを繰り返し、ホスティング、DaaS、テレフォニーサービスを列挙しています。アバウトページはヘブライ語で、Global Cloud Ltd が 2013 年に設立されたと述べ、地元の専門家によるパーソナライズされたサービスを中心に同社を位置づけています。
これらの主張は、Global Cloud をドメイン名のコモディティ層ではなく依存関係層に配置するため重要です。DaaS を使用する企業は、セッションブローカリング、アイデンティティ、ストレージ、エンドポイントパフォーマンス、サポートに依存します。IaaS を使用する企業は、コンピュート、ストレージ、ネットワーク、イメージ管理、復旧に依存します。コラボレーションまたはテレフォニーサービスを使用する企業は、可用性、コールフロー、ディレクトリ、ユーザープロビジョニング、設定エクスポートに依存します。マネージドソフトウェアを使用する企業は、パッチ、バックアップ、アクセス制御、変更承認に依存します。
パブリックネットワークフットプリントはこのようなサービスをサポートできますが、そのインストールされた深さを明らかにしません。4 つの可視 /24 は、特にターゲットを絞ったイスラエルのプロバイダーにとって、有意義な地域プラットフォームをサポートできます。また、サービスがサードパーティのプラットフォームまたはリース容量を通じて提供される場合、それらははるかに狭いドメインを隠すこともできます。ウェブサイトのセキュリティ、存続可能性、24 時間年中無休のサポートに関する主張は、サポートチャネル、応答時間、インシデント通知、バックアップ頻度、復旧時間、復旧ポイント、データエクスポート、顧客側フェイルオーバー、解約支援などの測定可能なコミットメントに変換する必要があります。
ウェブサイト証拠における実際的な緊張は、サポート時間に関するものです。英語版ホームページのヘッダーは、日曜日から木曜日の 09:00～18:00 の営業時間を示し、金曜日と土曜日は休業となっています。クラウドページでは、サポートチームが 24 時間年中無休で稼働していると述べています。単純な説明があるかもしれません。営業時間は技術サポートのカバレッジとは異なります。購入者は、この区別を契約で明確にする必要があります。24 時間年中無休が保証されているのは何ですか？待機対応は何ですか？どの重大度が即時応答を得られますか？ネットワーク障害時にどの連絡パスが機能しますか？サポートポータルは影響を受ける環境の外でホストされていますか？通常の営業時間外に誰が緊急変更を承認できますか？
サービスカタログは、ライセンスとプラットフォームの依存関係も生み出します。クラウドページは VMware、XEN、Microsoft タイプのインフラストラクチャサポートを参照しています。顧客は、サービスが専用かマルチテナントか下請けか、プラットフォームライセンスが含まれているか、スナップショットが移植可能か、仮想マシンイメージが標準形式でエクスポート可能か、アイデンティティ、テレフォニー、コラボレーションデータが長い手動プロジェクトなしで移行可能かを尋ねるべきです。
顧客リスクの中核的教訓は、Global Cloud の公開証拠は真剣に受け止めるのに十分な信頼性があるが、購入者が単一の包括的な「クラウド」保証を受け入れるべきではないほど広範であるということです。カタログの各サービスには異なる障害モードがあります。
インストール済み容量と使用可能容量は急速に乖離する可能性がある
クラウド購入者はしばしば、インストール済み容量と使用可能容量を混同します。インストール済み容量は、プロバイダーが通常の条件下で構築、リース、または構成したものです。使用可能容量は、何かが故障したとき、顧客が成長したとき、プロバイダーが条件を変更したとき、または制約の下で移行が行われなければならないときに残っているものです。Global Cloud の可視フットプリントは、本格的なホステッドサービスには十分な大きさですが、その背後にどれだけの予備スペースが存在するかを顧客が尋ねるべきほど小さいです。
/22 には 1,024 の IPv4 アドレスが含まれます。パブリック IPv4 は希少であり、/22 の制御は地域ホスティングプロバイダーにとって価値があります。しかし、アドレス数はコンピュート数ではありません。一部のアドレスがインフラストラクチャ、静的顧客アクセス、NAT、管理、電子メール、VPN、デスクトップゲートウェイ、またはネットワーク機器に使用されている場合、新しいホステッドサービスに使用可能なパブリックアドレスのプールは、生の数よりも小さい可能性があります。一部のサービスがゲートウェイの背後でプライベートにアドレス指定されている場合、パブリックアドレスプールはコンピュート容量を過小評価する可能性があります。パブリック BGP だけではこれを解決できません。
より具体的なサブネットラベルも疑問を追加します。SHVDOM-Core-Subnetはコアインフラストラクチャのように見えます。LNS-Static-Subentは静的アクセスまたは加入者機能を示唆します。SHVDOM-SubnetおよびSHVDOM-1-Subnetは、サービス固有のセグメンテーションを示唆します。これらはレジストリラベルに過ぎませんが、購入者は購入したサービスと実際の依存関係をマッピングする必要があります。DaaS 顧客は、ある /24 上のデスクトップファームからサービスを受けていますか？静的アクセスまたは LNS 機能は顧客の接続性に関連していますか？クラウド管理と顧客ワークロードは分離されていますか？バックアップネットワークは可視ですかプライベートですか？
使用可能容量はハードウェアの予備在庫にも依存します。サーバーが故障した場合、Global Cloud はローカルで交換できますか、それとも修理はベンダーの在庫と輸入リードタイムに依存しますか？ルーターまたはファイアウォールが故障した場合、最新の構成を備えた予備のオンサイト機器はありますか？ストレージアレイが劣化した場合、パフォーマンスを圧迫せずに再構築するのに十分なヘッドルームがありますか？ハイパーバイザークラスタがノードを失った場合、残りのホストは N+1 用にサイズ設定されていますか、それとも平均負荷用ですか？
これらの質問のいずれも、RIPE レコードやウェブサイトの主張では答えられません。だからこそ、尋ねる必要があります。公開記録は、実際の事業者の存在と現在の到達性を証明します。契約は、サービス容量と復旧容量を証明しなければなりません。
ラック、トランジットプロバイダー、ハードウェア、サポート、課金が真の障害パス
このファイルの主要な障害パスは理論的ではありません。Global Cloud にとって、最も妥当な公開障害パスは、ラックまたは施設の中断、トランジットプロバイダーまたはルートフィルターの問題、ハードウェア不足、サポートエスカレーションの失敗、請求またはベンダー契約の紛争、移行制限です。
ラックまたは施設の障害は、物理的なアクセスをテストします。Global Cloud のクラウド容量が単一の部屋または単一のデータセンタープロバイダーに集中している場合、電力、冷却、ファイバー、アクセス制御、または遠隔操作の問題がサービス中断になる可能性があります。同社のウェブサイトはセキュリティと存続可能性を主張し、ヘブライ語のクラウドコンテンツでは地理的に分離された複数のデータセンターと災害復旧オプションを主張しています。公開記録は、これらのサイトの数、アイデンティティ、または独立性を検証しません。顧客は、必要に応じて秘密保持契約の下でサイトリストを要求する必要がありますが、回答は依然として、プライマリ、バックアップ、および管理システムが共通の障害ドメインを共有しているかどうかを示すべきです。
トランジットプロバイダーの障害は、AS1680 と AS212616 への依存をテストします。公開隣接および一貫性レコードは、2 つの観測されたピアを示し、AS8551 はポリシーにはあるが問い合わせ時点で BGP には表示されません。顧客は、各ルーティングされた /24 に少なくとも 2 つのアクティブパスがあるかどうか、これらのパスが異なるルーターと建物を経由して入るかどうか、すべてのパスがフェイルオーバー用にサイズ設定されているかどうか、DDoS 防御が単一の事業者に依存しているかどうかを尋ねるべきです。回答は、レジストリオブジェクトだけでなく、現在のネットワーク設計であるべきです。
ハードウェア予備在庫の不足は、サービス背後にある経済性をテストします。小規模プロバイダーは、慎重なローカルスペアと明確なベンダーカバレッジにより優れたサービスを提供できます。また、障害が発生したディスク、電源、ルーターモジュール、またはファイアウォールシャーシをインシデント後に調達しなければならない場合、苦労することもあります。顧客は、サービスタイプごとの交換目標を尋ねるべきです：仮想ホスト、専用サーバー、ストレージアレイ、トップオブラックスイッチ、エッジルーター、ファイアウォール、バックアップアプライアンス、必要に応じた顧客構内機器。
サポート障害は、24 時間年中無休というフレーズと実際のエスカレーションの違いをテストします。ウェブサイトの 24 時間年中無休のサポート主張は有用ですが、顧客は重大度レベル、チケットチャネル、電話エスカレーション、言語カバレッジ、営業時間外の権限、インシデントコミュニケーションを定義する必要があります。サポートサイトまたは電子メールが同じプロバイダーネットワークに依存している場合、顧客は帯域外パスを知る必要があります。
請求またはベンダー契約の障害は、停電ほど劇的ではありませんが、同様に混乱を招く可能性があります。Global Cloud は LIR であり、独自のアドレス空間を所有しているため、アドレス空間リソースへの依存は、リースブロックをアナウンスするプロバイダーよりも制御されているように見えます。しかし、上流トランジット、ソフトウェアライセンス、データセンターリース、バックアップサービス、Microsoft タイプのサービスはすべて契約上の依存関係を生み出す可能性があります。顧客は、価格、IP アドレス、プラットフォーム、またはプロバイダーの変更が影響を及ぼす前に、どのような事前通知が適用されるかを尋ねるべきです。
移行障害は最も静かなリスクです。顧客が去りたい場合、仮想マシンイメージ、デスクトッププロファイル、電子メールデータ、ソフトウェアデータベース、テレフォニー設定、ファイアウォールポリシー、DNS ゾーン、ログ、バックアップを使用可能な形式でエクスポートできますか？Global Cloud は有料のオーバーラップウィンドウを提供していますか？顧客の IP アドレスは移動できますか、それとも DNS 名だけですか？これらの質問に答える良いタイミングは、サービスがミッションクリティカルになる前です。
このタイプのプロバイダーが失敗した場合の影響範囲
影響を受けるユーザーは、おそらく抽象的なハイパースケール顧客ではありません。Global Cloud のウェブサイトは、統合、仮想デスクトップ、ソフトウェアシステム、テレフォニー、コラボレーション、ホスティング、マネージド IT を必要とする企業にアピールしています。これは、中小規模の組織、コールセンター、開発チーム、小売業者、専門サービス会社、および独自のインフラストラクチャを運用したくない地元企業を指しています。これらの顧客にとって、プロバイダーは単なるベンダーではありません。それは、従業員が毎朝接続する場所、アプリケーションが実行される場所、バックアップが置かれる場所、またはテレフォニーやコラボレーションツールがアイデンティティとネットワークアクセスに依存する場所になり得ます。
したがって、障害の運用上の影響はサービスによって異なります。ウェブホスティング顧客は、公開のダウンタイムと DNS 変更を経験する可能性があります。DaaS 顧客は従業員の作業セッションを失う可能性があります。マネージドアプリケーション顧客は、ビジネスプロセスの継続性を失う可能性があります。テレフォニー顧客はコールルーティングを失う可能性があります。IaaS 顧客は、サーバーの復旧、ストレージの一貫性、ファイアウォールの再構築に直面する可能性があります。ソフトウェアサービス顧客は、データエクスポートとライセンスの問題に遭遇する可能性があります。
これが、Global Cloud の広範なサービスカタログがデューデリジェンスの負担を増やす理由です。静的ウェブホスティングのみを販売するプロバイダーは、1 セットのチェックで評価できます。データセンター、クラウド、デスクトップ、プラットフォーム、ソフトウェア、コラボレーション、IT サービスを販売するプロバイダーは、サービスごとのリスクマップを必要とします。同じ AS61365 エッジが複数の製品に関連する可能性がありますが、各製品は状態、復旧、移行に関する異なる要件を持っています。
影響はデータの機密性によっても異なります。従業員記録、健康関連情報、財務記録、またはヨーロッパの個人データを処理する顧客は、公開ウェブサイトを運営する顧客よりも多くのことを検証する必要があります。上記で引用したイスラエルのプライバシーに関する公式文書は、データベースセキュリティと国境を越えたデータ処理が規制対象であることを明確にしています。購入者は、責任の書面による分担を要求すべきです：どの部分が管理者か処理者か、誰がアクセスを管理するか、バックアップがどのように保護されるか、インシデントがどのように報告されるか、データがどこに転送されるか。
Global Cloud は、ローカルサポートとイスラエルのルーティングを希望する顧客にとって、便利な地域プロバイダーになる可能性があります。公開証拠はこの可能性をサポートします。プロバイダーが事業継続性の単一障害点になる前に、障害パスをテストする必要性を排除するものではありません。
証拠レベルを改善するもの
現在の公開証拠は、ネットワークリソース層が強固である一方、サービス容量層が文書化不足であるため、中程度のレベルに値します。Global Cloud が検証可能な運用上の証拠のいくつかの種類を公開または提供すれば、レベルは向上するでしょう。
第一に、現在の施設とプラットフォームの要約を提供できます。機密のフロアプランを公開する必要はありません。プライマリおよびセカンダリサイト、サイトが自社所有かコロケーションか、地理的および電力ドメイン的に独立しているか、どのサービスがどこで実行されているか、バックアップがどのように分離されているかを特定する必要があります。複数のデータセンターと災害復旧に関するウェブサイトの主張は、現在のサイトの役割とサービスタイプを伴えば、はるかに説得力が増します。
第二に、現在のルーティングとトランジットの要約を提供できます。AS1680 と AS212616 は BGP で可視、AS8551 はポリシー内にあります。プロバイダーは、どれがアクティブ、スタンバイ、または履歴であるか、各 /24 がアクティブなルート多様性を持っているか、フェイルオーバーがテストされているか、メンテナンス中に顧客が何を期待すべきかを述べることができます。また、PeeringDB プロファイルを公開することもできます。ASN 61365 の PeeringDB API クエリは、調査時点で 404 エンティティ未検出応答を返し、この API クエリを介して公開 PeeringDB ネットワークプロファイルが利用できないことを意味します。PeeringDB は任意であるため、不在は欠如の証拠ではありません。それでも、相互接続、施設、連絡先情報の開示機会を逃しています。
第三に、各製品のバックアップと復旧の目標を文書化できます。DaaS、IaaS、ホスティング、ソフトウェア、テレフォニーは、単一の汎用バックアップの約束を共有すべきではありません。それぞれに、テストされた最終復旧日、目標復旧時間、目標復旧ポイント、除外事項、顧客の責任を設定する必要があります。復旧が顧客が購入したバックアップオプションに依存する場合、それは明確でなければなりません。
第四に、移行権を文書化できます。ホステッドサービスへの信頼は、顧客がどのように離れられるかを知っている場合に向上します。エクスポート形式、DNS および IP の移行ウィンドウ、イメージの移植性、データベース抽出、プロファイルエクスポート、電子メールエクスポート、テレフォニー設定エクスポート、ログ保持は、紛争や障害の前に明確でなければなりません。
第五に、公開サービス言語を整理し整列させることができます。英語のサービスページは使用可能ですが、Global Cloud と Xpress Technologies の表現の混合、スペルの問題、部分的に翻訳されたコンテンツは、第三者がどの主張が現在のものかを知るのを難しくしています。よりクリーンなサービスカタログは回復力を証明しませんが、曖昧さを低減します。
これらの改善は表面的なものではありません。それらは、信頼できるルーティングされたフットプリントを、より検証可能な顧客依存関係に変換するでしょう。
購入者の実践的な質問
Global Cloud を検討している顧客は、すでに良い事実から始めるべきです。AS61365 と 185.184.16.0/22 が、購入されたサービスの現在のプロダクションエッジであることを確認するよう会社に依頼します。185.184.16.0/24、185.184.17.0/24、185.184.18.0/24、185.184.19.0/24 のどれがサービスに使用されているかを尋ねます。RPKI ROA が有効なままか、誰がルート変更を承認するかを尋ねます。ルートオブジェクトと IRR ステータスがすべてのトランジットプロバイダーフィルターに十分かどうかを尋ねます。
その後、物理的な質問をします。プライマリサービスはどこにホストされていますか？ラック、ケージ、またはデータルームは自社所有、リース、または下請けですか？関与する電源、UPS、発電機、冷却システム、遠隔操作プロセスは何ですか？オンサイトのスペアパーツは何ですか？営業時間外に誰が入館できますか？同じ建物を共有するサービスはどれで、どれが分離されていますか？
その後、ネットワークの質問をします。現在、本番トラフィックを伝送しているトランジットプロバイダーはどれですか？どれがスタンバイですか？AS1680 または AS212616 は独立して全負荷をサポートできますか？AS8551 の現在の役割は何ですか？個別のルーターと相互接続はありますか？DDoS 制御は事業者固有ですか？BGP 変更はピアレビューされテストされていますか？
その後、サポートの質問をします。24 時間年中無休は実際に何を意味しますか？電話サポート、エンジニア応答、監視、緊急変更、顧客コミュニケーションをカバーしていますか？営業時間の公衆電話回線が閉まっている金曜日または土曜日に何が起こりますか？プロバイダーのネットワーク自体がダウンしている場合の帯域外連絡パスは何ですか？
その後、データの質問をします。プライマリデータ、バックアップ、ログ、サポートチケットデータはどこにありますか？アイデンティティ、メール、監視、コラボレーションデータを処理するプラットフォームは何ですか？顧客はどのような規制を満たす必要があり、Global Cloud はどのような証拠を提供できますか？バックアップはどのように暗号化、復旧、削除されますか？
最後に、退出の質問をします。顧客はどのようにシステム、データ、設定をエクスポートできますか？IP アドレスを保持できますか、それとも番号変更が必要ですか？オーバーラップウィンドウの期間はどれくらいですか？どのような支援が含まれていますか？解約が請求紛争、サービスインシデント、またはプロバイダー変更に続く場合、何が起こりますか？
これらの質問は、Global Cloud が弱いと仮定しているのではありません。クラウドとして販売されている場合でも、ホステッド容量が物理的、契約的、かつ運用可能であると仮定しています。
結論: ネットワークは信頼できるが、回復性の証拠は不完全
Global Cloud Ltd は、ファイルの薄いフットプリント仮説が示唆するよりも、公開記録において実質的です。同社は RIPE LIR 組織オブジェクト、アクティブな AS、明確な IPv4 割り当て、現在可視の 4 つの /24 アナウンス、有効な RPKI ルート起点カバレッジ、イスラエルの地域シグナル、クラウド、ホスティング、デスクトップ、ソフトウェア、コラボレーション、マネージド IT を中心とした公式サービスカタログを持っています。これらは、信頼できるインフラストラクチャ企業の主題を確立するのに十分です。
残る不確実性は、名前の存在に関するものではありません。その名前の背後にどれだけの回復可能なサービスが存在するかに関するものです。公開データは、ラック、サイト、サーバー、ストレージシステム、サポートエンジニア、フェイルオーバーテスト、または顧客ワークロードの数を証明しません。広範なサービスカタログが、Global Cloud 所有のインフラストラクチャ、コロケーションインフラストラクチャ、パートナープラットフォーム、またはそれらの混合から提供されているかどうかを証明しません。顧客がストレス下でクリーンに移行できるかどうかを証明しません。
これが、記事のタイトルが意図的に物理的である理由です。Global Cloud はホステッド容量を販売していますが、その容量の価値は依然としてラック、トランジット、修復期間に依存します。AS61365 は可視であっても、顧客は依然として復旧の問題を経験する可能性があります。/22 は十分に登録されていても、購入者は依然としてハードウェア予備の証明を必要とします。有効な ROA は起点検証を保護しても、トランジットプロバイダーのインシデントは依然としてフェイルオーバーをテストします。24 時間年中無休のサポート主張は真実であっても、顧客は依然としてエスカレーションの詳細を必要とします。
証拠レベルは、Global Cloud またはその顧客が施設の独立性、ルートフェイルオーバー、サポートエスカレーション、バックアップ復旧、移行権を検証できるまで、中程度に留めるべきです。公開ネットワーク層は実在し、比較的よく文書化されています。サービス回復力層はまだデューデリジェンスのタスクです。