要約
- RIPE の公開記録は、Medyabim に一貫した法的およびネットワークのアイデンティティを与えている。AS44922 の RIPE RDAP 登録では MEDYABIM-AS が指定され、Emre Erim が管理および技術連絡先としてリストされ、「Emre Erim trading as Medyabim データセンター」の名称で ORG-MIH2-RIPE が含まれている。RIPE 組織登録では国が TR、ステータスが LIR、住所はブルサ、連絡先が示されている。
- 現在のルーティング範囲は実際に存在するが狭い。RIPEstat のAS 概要は AS44922 がアナウンスされているとマークし、一方ルーティングステータスは、IPv4 プレフィックス 1 つ、IPv6 プレフィックスなし、256 個の IPv4 アドレス、確認スナップショット時点で観測されたピア 1 つを示した。アナウンスされたプレフィックスのビューには、現在 37.247.116.0/24 のみがリストされていた。
- 最も強力な肯定的な検証は、現在の /24 に対するルートオリジンセキュリティである。37.247.116.0/24 の AS44922 経由の RIPEstat RPKI 検証は有効を返し、ROA で AS44922 が許可され、最大長 /24 となっている。
- Medyabim の自社ページでは、現在の AS44922 のルーティング範囲が証明するよりも広範な運用規模を宣伝している。データセンターページでは、Medyabim ラックに専用ハードウェアが用意されていること、Linux DirectAdmin サーバーの長年の経験、トルコおよび海外でのサーバーオプション、合計 50 Gbit/s の出力容量、Turk Telekom や Superonline などの名前入りプロバイダーパス、顧客トラフィックの監視を主張している。コロケーションページでは、帯域幅付きの 99% のサービス継続性、24 時間年中無休のサポート、ファイアウォール背後への配置、無料リブートポート、5 つの IP アドレスを主張している。
- 公開保証は依然として不完全である。公式ページでは、二重電源、発電機の稼働時間、冷却トポロジー、消火設備、キャリア接続室、メンテナンス時間枠、測定されたフェイルオーバー結果、施設認証、現在の PeeringDB 相互接続プロファイルは公開されていない。Medyabim 自身のドメインは 185.7.83.213 に解決されるが、RIPEstat は 185.7.83.0/24 が現在 AS44922 ではなく DATAFOREST によってアナウンスされていることを示しており、したがってクライアント側の依存関係マップでは、Medyabim ブランド、AS44922 エンドポイント、割り当てられたアドレス空間、およびサードパーティによってアナウンスされているサービス範囲を分離する必要がある。
役に立つ問いは、Medyabim が存在するかどうかではない
地域ホスティングプロファイルには、まず企業が単なるディレクトリの一行以上のものであることを証明することが第一の任務となるカテゴリーが存在する。Medyabim はそれほど脆弱ではない。公開登録には、実名の個人、商号、RIPE 組織登録、自律システム、割り当てられたアドレス資源、公式サービスページ、ブルサの連絡先住所、そして動作状態にある製品提供が含まれている。問題は異なる。公開登録はアイデンティティと限定的なルーティングの一端を証明するが、企業のマーケティング文言は、顧客に、より広範なデータセンター能力の物語を信じるよう求めている。
最も強力なアイデンティティの情報源は RIPE である。AS44922 の RDAP 登録は、自律システムを MEDYABIM-AS と命名し、「Emre Erim trading as Medyabim データセンター」という組織をリストしている。また、Emre Erim を管理および技術連絡先として、ブルサの住所と電話番号と共にリストしている。ORG-MIH2-RIPE の RIPE REST 組織登録は、同じ商号、国 TR、LIR タイプ、ブルサの住所、電話、ファックス、Medyabim メンテナー参照、2008 年 3 月の作成日を記載している。これはウェブから取得したホスティングディレクトリエントリよりもはるかに強力である。
Medyabim 自身の連絡先ページも、公開運用住所を独立して固定している。「Medyabim データセンター ve Internet Hizmetleri」と記載され、Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa の住所、電話番号、公開メールアドレス[email protected]が示されている。この住所は RIPE の住所と密接に一致している。これは、エンティティが顔の見えないオフショアクラウドレーベルとして提示されていないために重要である。その公開証拠は、ネットワーク資源登録と商業サイトが少なくとも相互に一貫しているブルサベースの事業者を示している。
企業の沿革ページは自己説明を追加する。Medyabim の会社概要ページは、同社が 2000 年からインターネットサービス、ソフトウェア製品、Linux ベースのターンキーシステムを中心に事業を展開してきたと述べ、その後ドメイン登録、ウェブホスティング、専用サーバー、サーバー管理、コンサルティングに注力するようになったとし、2006 年からはブルサに自社リソースで 500 台以上のサーバーを収容するデータセンターを自社およびウェブホスティング会社のサーバー用に構築したと述べている。これは設置ラックや電力容量の独立した証明ではないが、具体的で検証可能な運用主張である。
したがって問題は「Medyabim は存在するか」ではない。「電力、冷却、ルーティング、サポート、上位依存関係が途絶えたときに、顧客は Medyabim が販売する能力のどの部分に頼れるのか」である。データセンターやコロケーションの購入者にとって、アイデンティティは最初の扉に過ぎない。より困難なテストは回復可能な能力、つまりハードウェア、ラック給電、冷却、ファイバー、ルーティング、そして障害時に利用可能であり続ける人的プロセスである。
AS44922 は可視だが、現在の公開ルーティング範囲は小さい
RIPEstat は AS44922 がアナウンスされていることを確認している。AS 概要エンドポイントは、ホルダーを「MEDYABIM-AS Emre Erim trading as Medyabim データセンター」とラベル付けし、確認スナップショットでリソースがアナウンスされているとマークしている。これはポジティブなネットワークの結論である。Medyabim はルーティングシステムが可視できる公開自律システム端を持っている。
その端の規模は控えめである。RIPEstat のルーティングステータスエンドポイントは、IPv4 プレフィックス 1 つ、IPv4 アドレス 256 個、IPv6 プレフィックス 0 個、観測されたピア 1 つを示した。アナウンスされたプレフィックスエンドポイントは、37.247.116.0/24 を AS44922 の現在のアナウンスとしてリストした。ASN ネイバーエンドポイントは、観測された左側ピア 1 つとして AS16276 を示した。RIPEstat のAS16276 の AS 概要は、このピアを OVH SAS と特定している。
これは Medyabim が顧客 256 人、ラック 1 つ、またはサービス 1 つしか持たないことを意味しない。公開 BGP はプライベート VLAN、リセラー在庫、プロバイダーアドレスホスティング、サーバー在庫、顧客相互接続、または外部委託されたウェブ領域を可視しない。しかし、可視の AS44922 端は、検証時点では、大規模なマルチプレフィックス、マルチピアの公開バックボーンではないことを意味する。購入者が Medyabim をデータセンター依存関係として評価している場合、公開 BGP マップだけではマルチキャリアレジリエンスを証明できない。
RIPEstat のAS ルーティング一貫性ビューは、ギャップをより明確にする。37.247.116.0/24 は BGP と RIPE Whois/IRR の両方に存在するものとしてリストされた。また、37.247.117.0/24 と 2a03:400::/32 は Whois/IRR に存在するが、検証時点で BGP には存在しなかったとリストされた。同じ一貫性ビューでは、古い Whois インポート/エクスポートピアである AS9121 と AS53667 が BGP では見られず、AS16276 は BGP で見られたが Whois インポート/エクスポートポリシーでは見られなかった。これは古いルーティング記録における通常の乖離の一種であるが、まさにそのために、顧客はレジストリの履歴ポリシーテキストに頼るのではなく、現在のダイアグラムを要求すべきである。
ポジティブなチェックは RPKI である。現在の AS44922 ルート 37.247.116.0/24 は、RIPEstat のRPKI 検証チェックを有効で通過した。これは、ルートオリジン認可が、ホスティング購入者がプライベート施設文書を見ることなく検証できる数少ない公開チェックの一つであるために重要である。有効な ROA は電力、冷却、フェイルオーバーを証明しない。現在の可視 AS44922 オリジンが、公開検証レイヤーにおいて未確認のルートオリジン主張として放置されていないことを示す。
したがって、ルートに関する結論は狭く役立つ。AS44922 は実在する。現在の可視 IPv4 ルートは RPKI 有効である。観測された上流面は薄い。IPv6 証拠は現在アナウンスされていない。公開ルーティングポリシー記録は、キャリアの多様性やフェイルオーバーを証明するのに十分ではない。顧客はこれをファントムネットワークとも、証明されたレジリエントなデータセンターネットワークとも扱うべきではない。
IPv6 と休眠プレフィックスの証拠は格下げを要求する
Medyabim は IPv6 レジストリ証拠を持っている。2a03:400::/32の RIPE 検索レコードは、TR-MEDYABIM-20110107 下の 2a03:400::/29 割り当てと、オリジン AS44922 での 2a03:400::/32 の route6 エントリを示している。これは堅牢に見えるが、現在のルーティング可視性と比較するまでである。
RIPEstat の2a03:400::/32 のプレフィックス概要エンドポイントは、検証時点でプレフィックスがアナウンスされていないとマークした。ルーティングステータスビューは、現在のオリジンがなく、RIS ピアがゼロで見ており、AS44922 の最終観測イベントが 2026 年 4 月 1 日であると報告した。これはそれ自体失敗の結論ではない。一部の顧客は IPv6 サービスを購入しないかもしれない。一部の事業者は休眠 IPv6 計画を持っているかもしれない。一部のアドレスブロックは後日の使用のために保持されている。しかし、これは公的に証明できることを変える。公式現在ページがホスティングおよびサーバーサービスを宣伝しているが、可視 AS 端が現在の IPv6 アナウンスを持たないデータセンタープロバイダーは、IPv6 サポート、その不利用可能性、選択的可用性、または別プロバイダー経由の提供について問われるべきである。
IPv4 休眠プレフィックスの状況もまちまちである。37.247.117.0/24の RIPE 検索結果は、NET-MEDYABIM-DC5 と、2025 年 6 月作成のオリジン AS44922 の RIPE ルートエントリを示している。だが RIPEstat の一貫性チェックは、現在の BGP でそれを見なかった。これは予約容量、計画された移行、最近引き出されたルート、バックアップ範囲、または単に未使用のアドレス空間を表す可能性がある。公開証拠はこれらの説明のいずれかを選ぶことができない。
重要な区別は、割り当てられた能力と運用能力の間である。RIPE 割り当て、ルートエントリ、またはアドレス割り当ては、管理統制または準備を示すことができる。今日、そのアドレス範囲が顧客にサービスを提供していること、複数のキャリア経由で到達可能であること、または停止時に起動できることを証明するものではない。回復可能な能力を必要とする購入者は、どのプレフィックスが本番稼働中か、どれが予約か、どれが他のオリジンに移行中か、どれが顧客向けか、どれが管理用か、どれがテスト済みの DDoS、ファイアウォール、RPKI プロセスでカバーされているかを Medyabim に尋ねるべきである。
Medyabim の自社サービスページは具体的だが、施設のレジリエンスを公開していない
Medyabim のデータセンターページは、一般的なホスティングホームページよりも詳細である。専用サーバーモデルは支払い確認後に提供され、Medyabim ラックにハードウェアが準備されていると述べている。Medyabim は Linux 専用サーバーの 15 年以上の経験があり、2003 年から DirectAdmin を積極的に使用しているという。トルコ国内では自社サーバーハードウェアでサービスを提供し、専用サーバーサービスは需要に応じてトルコまたは海外で選択できると述べている。また、「高い回線容量」と高可用性を、実際のサーバーハードウェアを迅速に提供する理由として説明している。
同じページは大きな接続性の主張を行っている。データセンターの主要インターネット接続は、トルコおよび世界からの高速アクセスを提供するために選択されたと述べ、Turk Telekom、Superonline、Level3、Tinet、Lambdanet、Cogent Communications、AMS-IX、ECIX Duesseldorf を挙げ、合計回線出力容量 50,000 Mbit、すなわち 50 Gbit/s を示している。専用サーバーの顧客は、自身のトラフィックを 24 時間年中無休で監視するためのネットワーク管理パネルに入ることができ、データセンターは Foundry Networks および HP Procurve のネットワークハードウェアを使用しているとしている。
これは有益な証拠だが、企業が公開するマーケティング・運用テキストとして読まなければならず、ライブキャリア監査ではない。このページは、挙げられたプロバイダーのうちどれが現在の物理キャリアか、どれがトランジットプロバイダーか、どれがピアリングまたはルート関係か、どれが歴史的トランジットオプションか、どれがトルコのサービスを支え、どれが海外配置を支えているかを開示していない。施設の接続室、多様化されたファイバーエントリ、相互接続マップ、またはライブポート在庫を示していない。検証時点の公開 BGP は、AS44922 に観測されたピア 1 つを示し、ページ上のすべてのプロバイダー名の可視公開マップを示していない。
施設エンジニアリングについては、このページはさらに薄い。二重電源、UPS 容量、バッテリ稼働時間、発電機燃料稼働時間、冷却冗長性、消火クラス、床荷重、ラック密度、物理セキュリティ層、メンテナンス時間枠ルール、または災害復旧演習を公開していない。これらの省略は、管理策が存在しない証拠ではない。多くの小規模プロバイダーはそのような詳細を公開しない。しかし、データセンターのレジリエンスを評価する顧客は、「データセンター」という言葉からこれらの管理策を想定すべきではない。
Medyabim のコロケーションページは、顧客向けの運用主張を追加している。Medyabim はコロケーションサービスについて、帯域幅付きの 99% の可用性またはサービス継続性保証を提供すると述べ、Medyabim データセンター内のサーバーを持つ企業は 24 時間年中無休の企業サポートを受けることができ、トラフィック統計はオンラインで観察でき、サーバーはファイアウォールの背後にあり、無料リブートポートが割り当てられ、割り当て接続は専用で非制限であり、データセンター内のサーバーには 5 つの IP アドレスが無料で割り当てられるとしている。
これらは実際のサービス主張であり、購入者がサービスに依存する前に尋ねるべき質問を特定する。99% の継続性約束は、現代の高可用性 SLA と同じではなく、99% でも年間でかなりのダウンタイムを許容しうる。リブートポートは、電力供給、リモートアクセス、コンソール認証情報、サポート手順がインシデントを生き延びる場合にのみ有用である。ファイアウォールの背後に置くことは顧客を保護しうるが、共有ボトルネックにもなりうる。5 つの IP アドレスはシンプルなホスティングには十分かもしれないが、ルーテッドサブネットの可搬性やフェイルオーバーについては何も語らない。このページは顧客に質問すべき材料を与えるが、完全なレジリエンスの証明ではない。
公式サイトは提供品目の幅を証明するが、回復可能な能力は証明しない
公開提供の範囲は広い。Medyabim のウェブホスティングパックページは、ウェブスペース、トラフィック、FTP、MySQL、Web メール、DirectAdmin、オプションの SSL、メールバックアップ製品、サーバーごとの追加 IP サービス、300 GB サーバーバックアップサービス、無制限 24 時間年中無休 FTP 転送、毎週・毎月の自動バックアップ、高度な統計、スパムフィルタリング、転送レポートを備えたホスティングパックを告知している。リセラーページは、ウェブスペース、POP3 メール枠、月間トラフィック、MySQL データベース、トルコ語コントロールパネル、Web メール、オプションの DNS コントロール、SSL オプション、スパムフィルター、トラフィックレポートを備えたリセラーパックを提供している。
VDS ページは、仮想専用サーバーを物理ハードウェア上の論理的に分離されたサーバーとして説明し、VDS パックの機能をリストしている。コントロールパネル情報ページは、サーバーが Medyabim DC 内にある場合に DirectAdmin がサーバーにインストールされると述べ、プロアクティブなサーバー管理、セキュリティ設定、スパムブラックリスト監視について説明し、PHP、MySQL、Linux、ionCube、DirectAdmin がすべてのサーバーにインストール・設定されていると述べている。
これらを総合すると、Medyabim は小規模プロバイダーの古典的なスタックを販売していることがわかる。ドメイン、共有ホスティング、リセラーホスティング、VDS、専用サーバー、コロケーション、メールストレージ、SSL、バックアップ、および管理された Linux/DirectAdmin サポート。この組み合わせは 2 種類の依存関係を生む。1 つは物理的:ラック、電力、冷却、アップリンク、ファイアウォール、リブートポート、予備サーバー、技術者アクセス。もう 1 つは管理的:顧客ポータル、課金、アカウントステータス、サポートチケット、ドメイン制御、DNS、メール、バックアッププロセス。
公開提供は、購入者にどの依存関係が同じ障害ドメインにあるかを教えない。顧客は、ウェブサイト、メール、バックアップ、DNS、チケットアクセスがすべて同じプロバイダーシステムに依存するウェブホスティングパックを購入するかもしれない。リセラーは、最終顧客がリセラーのブランドだけを見ていても、Medyabim のコントロールパネルとメールシステムに依存するかもしれない。専用サーバー購入者はリモートリブートを持っているかもしれないが、マシンが POST しない、ディスクコントローラーが故障する、またはファイアウォールポリシーがリカバリアクセスをブロックする場合、依然として技術者を必要とする。コロケーション顧客はサーバーを所有しているかもしれないが、依然として Medyabim の建物、電力、アップリンク、ファイアウォール、サポート対応に依存する。
これが、設置容量では十分でない理由である。概要ページの 500 台以上のサーバー容量主張と、データセンターページの 50 Gbit/s 出力容量主張は、可能な規模を説明する。回復可能な能力は、単一の給電経路、UPS 経路、スイッチ、ファイアウォール、アップリンク、認証経路、サポートチャネルが失われた後に何が起こるかを問う。公開ページはそれに答えない。
Medyabim 自身の DNS 面は AS44922 外部を指している
最も明らかなチェックの 1 つは、Medyabim 自身のドメインである。medyabim.com.tr の公開 DNS ルックアップは、Apex と www 名が 185.7.83.213 に解決され、mail.medyabim.com.tr も 185.7.83.213 に解決され、ネームサーバーが ns1.medyabim.com と ns2.medyabim.com であり、SPF レコードが 37.247.112.0/24 と 185.7.83.0/24 を参照していることを示した。これらの DNS 事実は、Medyabim が自身のサービス面をインターネットにどのように提示しているかを示すため、運用隣接証拠として扱われなければならない。
RIPEstat は解釈を変える。185.7.83.0/24 のプレフィックス概要は、当該プレフィックスが AS58212 によってアナウンスされていることを示し、185.7.83.0/24 のルーティングステータスエンドポイントは、現在のオリジンを AS58212 とリストしつつ、プレフィックスが 2012 年に AS44922 から初めて観測され、検証時点では AS58212 から最後に観測されたと注記した。RIPEstat のAS58212 の AS 概要は、このオリジンを DATAFOREST dataforest GmbH と特定している。同様に、37.247.112.0/24 のプレフィックス概要は、現在のオリジンを AS29141 と示し、そのAS29141 の AS 概要は Bradler & Krantz GmbH & Co. KG を特定している。
これは Medyabim が自社のサービスを偽って伝えていることを意味しない。アドレス空間は割り当てられ、リースされ、移行され、トランジットプロバイダーによってルーティングされ、海外でホストされ、レガシーサービスに使用される可能性がある。Medyabim の RIPE 検索結果は、37.247.115.0/24、37.247.118.0/24、185.7.82.0/24、185.7.83.0/24 を含む、Medyabim ラベル付きの複数のアドレスブロックを示しており、その一部は現在、公開ルーティングによって異なるオリジン ASN に帰属している。正しい結論はスキャンダルではない。依存関係のマッピングである。
Medyabim のウェブ、メール、または DNS 面が現在他のネットワークによってアナウンスされているプレフィックスに依存している場合、顧客は、自身のサービスのどの部分が AS44922 上にあり、どの部分が外部オリジンのアドレス空間上にあり、どの部分が海外にあるのかを知る必要がある。これは停止分析にとって重要である。AS44922 に問題がある場合でも、Medyabim の公開ウェブサイトやサポートメールは、別のプロバイダー経由で依然として到達可能かもしれない。外部オリジンパスに問題がある場合、ブルサの AS44922 ルートがアクティブであっても、Medyabim ブランド面はダウンする可能性がある。顧客が「トルコ」配置を購入するが、サポート、バックアップ、DNS、またはメール依存関係が他所にある場合、顧客はそれをサービス設計で示される必要がある。
より広いポイントは、DNS と BGP が異なるストーリーを語ることである。ブランドドメインはオンラインでありながら、AS 端は狭い可能性がある。RIPE ホルダーは、現在自身の ASN によってアナウンスされていない割り当てアドレス範囲を持つことができる。プロバイダーは、自身のスタックの一部についてサードパーティのルートオリジンに依存しながら、ホスティングを販売することができる。これらの事実のいずれも失格ではない。すべては、障害分析が正確でなければならないことを意味する。
PeeringDB の沈黙は、サイトが多くのパスを挙げているために重要である
PeeringDB は任意のディレクトリであるため、ネットワークオブジェクトの不在は、ネットワークが相互接続を欠いている証拠ではない。しかし、公式データセンターページが多数の接続関係と合計 50 Gbit/s 出力容量の主張を挙げているため、Medyabim にとっては重要である。ASN 44922 の PeeringDB API クエリは、調査時点でネットワークオブジェクトを返さなかった。これにより、IX プレゼンス、施設プレゼンス、ピアリングポリシー、トラフィック比率、情報プレフィックス、自己申告相互接続ロケーションを示しうる公開情報源が削除される。
PeeringDB プロファイルがなければ、購入者は RIPE/RDAP 記録、RIPEstat BGP 観測、Medyabim の自社ページ、DNS、契約文言だけを頼りにする。これは実行可能だが、キャリア接続室への多様なアクセスを証明するには十分ではない。公開 BGP は、AS16276 が現在観測されたピアであることを示した。Medyabim のデータセンターページは、Turk Telekom、Superonline、Level3、Tinet、Lambdanet、Cogent、AMS-IX、ECIX Duesseldorf を挙げている。本記事は、公開証拠のみからこれらの層を現在の物理トポロジーに調整することはできない。
正しい調達質問は、挙げられたプロバイダーがすべて偽物かどうかではない。現在の本番サービスが、独立してプロビジョニングされたパスを複数持ち、それらのパスが意味のある形で多様化されているかどうかである。顧客サービス用にアクティブな複数の有償トランジットプロバイダーがあるか、可視の単一上流プロバイダーだけか?挙げられた名前の一部は歴史的なものか?一部のルートは上流プロバイダー、リセラー、遠隔相互接続経由で配送されているか?ブルサの施設は多様化されたファイバーエントリを持っているか?トルコとヨーロッパのパスは物理的に分離されているか?停止時に生存パスがどれだけのトラフィックを運べるか?ファイアウォールパスは冗長か、リブートポートパスは顧客本番ルーティングから独立しているか?
公開証拠はこれらの質問に答えられない。質問の必要性を特定できる。50 Gbit/s の主張は、現在のポート、契約、使用率余裕、フェイルオーバーの証拠があるまで容量の仮定である。挙げられたプロバイダーのロゴやテキストはルート多様性と等価ではない。観測された単一の AS ピアは単一ホーミングの証明ではないが、直接確認を要求するには十分である。
サービス契約はリスクを顧客に転嫁している
Medyabim のサービス契約は、公開技術約束が契約リスクとどのように出会うかを示すため重要である。契約は、Medyabim が支払いと受諾後に注文されたサービスを提供すると述べているが、アカウント認証情報、ホストコンテンツ、法的遵守、税金、サービス利用について顧客に責任を負わせている。レジリエンスにとってより重要なのは、顧客のデータバックアップとストレージ義務は、契約書に別段の定めがない限り顧客に属するとしつつ、Medyabim は定期的に顧客データをバックアップ・維持するが、サービス中断やデータ損失から生じる誤り、損失、損害について責任を負わないと述べていることである。
この組み合わせはホスティング契約では一般的だが、結果を伴う。公開ホスティングページは、毎週・毎月の自動バックアップ、オプションのバックアップサービス、トラフィックレポート、管理サポートを告知するかもしれない。サービス契約は、顧客が正しいバックアップとリストアプロセスを購入・設定していない場合、依然としてプロバイダーの責任を制限する可能性がある。したがって、顧客はバックアップの正確な範囲、保持、リストアテスト、復旧時間、バックアップの隔離、そしてバックアップが同じ施設、同じプロバイダーネットワーク、同じアカウントコントロールプレーン、同じ障害ドメインにあるかどうかを尋ねるべきである。
同じ契約は、支払い問題、違法コンテンツ、スパム、その他の契約違反に対して Medyabim に停止権限を与えている。これは自社ネットワークを保護するホスティングプロバイダーには期待されることである。また、サービスの継続性が物理システムと同様に管理状態に依存することを意味する。顧客は、ラックやルートが健全であっても、不払い、不正利用処理、スパムインシデント、アカウントロック、認証情報喪失、サポート紛争によってサービスを失う可能性がある。クリティカルなワークロードにとって、課金、不正利用連絡先、エスカレーション手順は、管理的詳細ではなく運用管理策である。
Medyabim のサポートシステムヘルプページとオンラインヘルプページは、チケットベースのサポート姿勢を示している。データセンターページは、電話サポートは営業時間(09:00 ~ 18:00)に利用可能であり、それ以外の時間帯は 24 時間年中無休のチケットおよびメールによるサポートシステムを通じてプロバイダーに連絡できると述べている。コロケーションページは、Medyabim データセンターにサーバーを持つ企業は 24 時間年中無休の企業サポートを受けられると述べている。これらの声明は、顧客がサービスを信頼する前に、インシデント手順に変換されるべきである:誰が電話できるか、誰が緊急チケットを開けるか、時間外の電話エスカレーションがあるか、プロバイダーがリブート、ネットワーク、ハードウェア、ファイアウォール、DNS、不正利用のインシデントをどのように区別するか。
電力と冷却が最大の公開死角である
この企業の任務はデータセンターインフラストラクチャの調査であり、主な物理的依存関係は電力、冷却、ファイバー接続室アクセス、施設運用、および現地許可である。Medyabim の公開ページはいくつかの施設タイプの主張を提供しているが、高いレジリエンス信頼スコアを裏付けるのに十分なエンジニアリング詳細はない。会社概要ページは、同社がブルサに自社リソースで 500 台以上のサーバー容量のデータセンターを構築したと述べている。データセンターページは、ハードウェアが Medyabim ラックに準備されており、同社は自社サーバーハードウェアを使用していると述べている。コロケーションページは、サーバーはファイアウォールの背後にあり、トラフィック統計を持ち、無料リブートポートを受け取ると述べている。
これらの声明は依然として物理施設をほとんど観測不能にしている。二重電源の公開主張はない。公開された UPS トポロジーやバッテリ稼働時間はない。発電機の数、燃料容量、給油契約はない。冷却冗長設計はない。煙感知、消火、漏水検知の詳細はない。フロアプランや施設認証はない。多様化されたファイバーエントリや接続室設計に関する声明はない。計画作業、緊急作業、顧客要求作業を区別するメンテナンス時間枠ポリシーはない。測定された回復を示す公開インシデント履歴はない。
ブルサの小規模プロバイダーにとって、この沈黙の一部は理解できる。施設の詳細を公開しすぎるとセキュリティリスクを生じうる。小規模事業者はまた、上流施設、賃借室、オフィス電源配置、またはローカルと海外の混合サーバー配置に依存するかもしれない。しかし、顧客にとってのリスクは同じである。「500 台以上のサーバー容量」という主張は、1 つの配電経路の障害後に使用可能な電力容量と等価ではない。「高可用性」という主張は、テストされた発電機稼働時間と等価ではない。「リブートポート」は、リモートコンソールアクセス、予備ディスク、ホットスワップ手順、または技術者の可用性を置き換えない。
実用的なテストは、4 つの能力を分離することである。設置容量は、プロバイダーが構築したか、収容できると言うものである。販売容量は、顧客がすでに使用しているものである。使用可能容量は、通常負荷、熱限界、電力予約、メンテナンス、オーバーサブスクリプションの後に残るものである。回復可能容量は、1 つのコンポーネントの障害後に残るものである。公開ページは主に設置容量を説明する。顧客は使用可能かつ回復可能な容量を必要とする。
Medyabim の現在の公開証拠はこの問題を解決できない。証拠の要求を定義することだけができる:電力単線結線図、UPS と発電機の稼働時間、冷却設計、ラック密度ポリシー、火災・水管理策、キャリアエントリの多様性、メンテナンス履歴、リモートハンド手順、予備部品ポリシー、そして少なくとも 1 つの文書化されたフェイルオーバーまたは復旧演習。
Medyabim が停止したときに影響を受けるのは誰か
影響を受けるユーザーは、Medyabim の直接のアカウント保持者だけではない。ドメイン、ホスティング、リセラーパック、VDS、専用サーバー、コロケーション、メールストレージ、バックアップを販売するプロバイダーは、多数の下流サービスの下に位置しうる。リセラーパックは、所有権者が Medyabim の存在を知らないかもしれない数十から数百の小規模ウェブサイトをサポートしうる。専用サーバーは、企業アプリケーション、データベース、代理店ポートフォリオ、メールサービス、または E コマースストアを運ぶかもしれない。コロケーション顧客はハードウェアを所有しているかもしれないが、電力、ラックアクセス、ファイアウォールパス、トラフィック監視、リブート制御について Medyabim に依存する。
障害パスも一次元ではない。電力イベントは、上流ルートが健全であってもサーバーを停止させうる。冷却イベントは、シャットダウンを強制したり、許可されるラック密度を減少させたりする。ファイアウォール障害は、一度に多数の顧客を隔離しうる。単一の上流プロバイダー停止は、影響を受けるプレフィックスに対してアクティブな代替パスがない場合、AS44922 に影響を与えうる。サポートやチケットの障害は、施設が無傷であっても復旧を遅らせうる。外部オリジンのアドレス空間での DNS やメールの停止は、他の場所の本番トラフィックがまだ動いている間、Medyabim への連絡を困難にしうる。契約上または不正利用による停止は、物理的障害なしにサービスを除去しうる。
これが DNS 発見が重要である理由である。公開ブランドドメインとメールサービスが、現在 DATAFOREST によってアナウンスされているプレフィックス下の 185.7.83.213 を使用し、SPF が現在 Bradler & Krantz によってアナウンスされている 37.247.112.0/24 プレフィックスを参照している場合、顧客は「Medyabim ネットワーク」が 1 つの AS、1 つの都市、1 つの施設、1 つの法域を意味すると仮定すべきではない。一部のコンポーネントが AS44922 の外部にあるため、サービスはよりレジリエントかもしれない。また、インシデント所有権がプロバイダー境界を越えるため、より複雑かもしれない。
回答を必要とするのは、調達チーム、ウェブ代理店、リセラーナペレーター、中小企業経営者、システム管理者、コンプライアンス責任者、インシデント対応者である。彼らは、Medyabim がホストするサービスが、第二のパス、最近のリストアテスト、帯域外サポートチャネル、最新のバックアップ、ドメイン転送アクセス、DNS エクスポート、メール継続性、ルートオリジン認可を持っているかどうかを知る必要がある。これらの質問は敵対的ではない。ホスティング関係を、悪い日を生き延びることができるインフラ依存関係に変えるために必要な最低限の作業である。
顧客が Medyabim に証明を求めるべきこと
第一に、最新のネットワークマップを要求する。AS44922、37.247.116.0/24、37.247.117.0/24 などの予約済みまたは休眠中の AS44922 プレフィックスすべて、2a03:400::/32 またはより広範な割り当ての IPv6 計画すべて、AS29141、AS58212 またはその他のオリジン下でルーティングされた顧客サービスすべてを特定すべきである。AS16276 が AS44922 ルートのアクティブな唯一の上流プロバイダーかどうか、プライベートまたは非観測契約を通じて他のプロバイダーがアクティブかどうか、データセンターページのプロバイダー名が現行か、履歴的か、間接的か、製品固有かを特定すべきである。
第二に、施設のレジリエンスを要求する。回答には、給電、UPS 設計、バッテリ稼働時間、発電機稼働時間、冷却冗長性、ラック密度限界、物理セキュリティ、火災・水管理策、メンテナンス時間枠、リモートハンド可用性、予備部品ポリシー、コロケーションの 99% 継続性主張が実際に何をカバーするかを含めるべきである。サービスがブルサにある場合、建物と公共サービスの依存関係を尋ねる。サービスが海外にある場合、どの国、どの施設、どのプロバイダー、どの法的条件が適用されるかを尋ねる。
第三に、顧客レベルのフェイルオーバー証拠を要求する。Medyabim は、上流プロバイダーが停止したとき、ファイアウォールが故障したとき、サーバーが電力喪失したとき、ディスクが故障したとき、顧客がポータルに到達できないとき、サポートキューが混雑しているとき、アカウントに不正利用フラグが立ったとき、または顧客が緊急移行を必要とするときに何が起こるかを示すことができるべきである。公開ページはトラフィック監視、バックアップ、リブートポート、チケットについて言及している。購入者は、障害時にこれらのツールがどのように動作するかを知る必要がある。
第四に、データとエグジットの管理策を要求する。ホスティングページは、毎週・毎月の自動バックアップ、オプションのバックアップ、メールバックアップ製品、サーバーバックアップサービスについて言及している。サービス契約は、契約に別段の定めがない限り、サービス中断とデータ損失に関する Medyabim の責任を制限している。顧客は、リストアテスト、バックアップの範囲、保持、オフサイトステータス、暗号化、アクセス制御、エクスポートプロセス、ドメイン転送プロセス、DNS エクスポート、メール継続性を要求すべきである。
第五に、通常のウェブサイトやメールが利用できないときにサポートに連絡できることの証明を要求する。連絡先ページは電話番号とメールを提供している。データセンターページは、営業時間内の電話サポートと時間外のチケット/メールサポートについて説明している。クリティカルな顧客は、指名緊急エスカレーション、認証済み連絡先、帯域外電話手順、通常のポータルのみに頼らずにリモートハンドを許可する手段を要求すべきである。
合理的な証拠パッケージは、機密のフロアプランを開示する必要はない。Medyabim は、どの施設がワークロードを担当しているか、どのプレフィックスとオリジン ASN が使用されているか、どの DNS とメールサービスが関係しているか、どの上流プロバイダーがアクティブか、どのコンポーネントが単一障害点か、どのサービスがトルコ国外か、を示す顧客固有の付属文書を提供できる。顧客サーバー、共有ファイアウォール、リブートコントローラー、バックアップ目標、サポートポータル、権威 DNS、公開ウェブサイトを分離する匿名化された単線結線図を提供できる。また、発電機テスト、UPS メンテナンス、冷却メンテナンス、上流フェイルオーバーテスト、バックアップリストアテスト、ルートオリジン変更の最近の日付を提供できる。これらのアーティファクトは、顧客名や機密セキュリティ構成を露出することなく、運用上の質問に答えるだろう。
同じ付属文書は、標準ホスティングとコロケーションおよび専用サーバーを区別すべきである。共有ホスティングでは、購入者は Medyabim のプラットフォーム選択とバックアップポリシーに依存する。リセラーホスティングでは、下流の顧客は別のブランドから購入する場合でも Medyabim に依存しうる。専用サーバーでは、購入者は OS を制御できるが、ラック、ルーター、給電経路、予備部品は制御できない。コロケーションでは、購入者はサーバーを所有しうるが、建物、電力、サポートアクセス、ネットワーク端については依然として Medyabim に依存する。これらの違いが、停止時に誰が最初に行動するかを決定する。
証拠格付け
Medyabim は、施設とレジリエンスの証拠に関する格下げを伴い、公開ネットワーク証拠格付け「中」を獲得する。アイデンティティ層は小規模プロバイダーとしては強固である:RIPE RDAP および RIPE 組織登録は、AS44922 と ORG-MIH2-RIPE を Emre Erim trading as Medyabim データセンター に結び付け、ブルサの住所は Medyabim の連絡先ページと一致する。現在の AS44922 ルート層も実在する:RIPEstat は AS をアナウンス状態とマークし、37.247.116.0/24 を現行としてリストし、確認スナップショットで完全な IPv4 RIS 可視性を示し、RPKI 下でルートを有効と検証する。
格付けは「高」にはできない。なぜなら、運用証拠はその直後から薄くなるからである。RIPEstat は現在の IPv4 /24 を 1 つだけ、現在の IPv6 アナウンスはなし、観測された AS44922 ピアは 1 つだけを示した。PeeringDB は AS44922 のネットワークオブジェクトを返さなかった。RIPEstat の一貫性ビューは、BGP で現行でない IPv4 ルートエントリと IPv6 route6 エントリを示した。Medyabim 自身の DNS 面は、現在他のネットワークによってアナウンスされているアドレス空間を指している。Medyabim の公式ページは有用なサービス主張を公開しているが、制約下で販売されるデータセンター能力を信頼するために必要な電力、冷却、キャリア接続、メンテナンス、フェイルオーバーの証拠を公開していない。
実際的な結論は、Medyabim を却下することではない。証拠は、長期の RIPE 登録、可視 AS 端、公式サービスページ、具体的な顧客提供を備えた、ブルサを拠点とする真のホスティング・データセンター事業者を支持している。また、500 台以上のサーバーと 50 Gbit/s の主張をレジリエンスの証明として受け入れることでもない。顧客はこれらの主張を、最新のキャリアダイアグラム、施設証拠、プレフィックスマッピング、RPKI チェック、リストアテスト、契約固有のサポート手順を通じて検証すべき仮説として扱うべきである。
Medyabim の公開フットプリントは、アイデンティティ、サービス、現在のルートを挙げる点で最も強い。顧客が停止時に最も証拠を必要とする点、すなわち給電、冷却、物理ファイバー多様性、アクティブなキャリア冗長性、現在の IPv6、サポートエスカレーション、バックアップ、エグジット、テストされた復旧において最も弱い。これはまさに、クリティカルなワークロードがブランドの背後に配置される前に、デューデリジェンスが集中すべき場所である。

