DMAIL Direct Mail LLC が販売するホステッドキャパシティは依然としてラック、トランジット、修理窓口に依存する

概要

• DMAIL Direct Mail LLC は、ロシアの実際の法人かつインターネットルーティング上の存在として確認できる。ロシアの税務サービス企業検索で OGRN 1157746030309 を調べると ООО "ДИРЕКТ ПОЧТА" が識別され、RIPE レコードでは AS205482 が DMAIL Direct Mail LLC の下に登録され、185.11.198.0/24 がロシアの Direct Mail LLC に関連付けられている。
• 公開ネットワークのフットプリントは狭い。RIPEstat では、アナウンスされている IPv4 /24 が 1 つ、256 アドレス、IPv6 は見られず、アナウンスされたプレフィックスに対して検証済みの RPKI ROA もない。これは、小規模なホスティングまたはアプリケーション容量の読み取りにのみ対応することを示している。
• 観測された 2 つの上流ネイバーが存在しても、冗長性は証明されない。RIPE の観測では、ほとんどの可視経路で AS8641（Nauka-Svyaz）が見られ、少数の経路で AS29226（Mastertel）が見られる一方、RIPE レジストリには依然として AS31261（MegaFon）からの古いインポート宣言が記載されている。これらの記録のいずれも、ラック、施設、ポート、契約、個別の物理経路を特定していない。
• 防御可能な購入姿勢とは、明示的な格下げである。DMAIL のキャパシティは、リースラックやプロバイダ管理のインフラに依存するものとして扱い、会社がサイトの場所、電源設計、トランジット契約、予備ハードウェア、サポートエスカレーション、明確なデータポータビリティ条件を示すまで、信頼を置かないことである。

単一プレフィックスのクラウド問題

クラウドという言葉はしばしばインフラを軽やかに聞こえさせる。仮想サーバーはパネルに現れる。メールプラットフォームはキャンペーンを受け入れる。ストレージバケットはファイルを保持する。ビジネスアプリケーションはホスト間を移動する。顧客に見えるのはアドレス、ログイン、月額請求書、サポート窓口である。しかし、その下にある堅い表面はそれほど優雅ではない。そこにはラック、ルーター、上流契約、電力、冷却、リモートアクセス、ハードウェア在庫、そして夜間に障害が起きたときに応答できる人がいる。

DMAIL Direct Mail LLC は、その物理的レンズを通して見るべきである。公開ネットワークの証拠は本物だが小規模だ。RIPEstat のAS205482 の AS 概要は、保有者を DMAIL Direct Mail LLC とし、ASN がアナウンスされていると記している。現在のルーティングステータスでは、IPv4 プレフィックス 185.11.198.0/24 が 1 つ示され、256 アドレスを含み、IPv6 アナウンスは見られない。アナウンスプレフィックスビューでも同じ単一の /24 が表示される。これは利用可能なインターネットリソースだが、広大なクラウドエステートではない。

より狭い解釈が重要なのは、/24 が非常に異なる現実を支えうるからだ。少数の公開向けホスト、メールリレー、アプリケーションフロントエンド、管理インターフェース、顧客仮想サーバー、ネットワークアドレス変換ポイントなどを含むことができる。モスクワのキャリア施設の単一キャビネットから経路設定されるかもしれないし、別のプロバイダの管理サービスの下で設置された機器からかもしれない。慎重なバックアップを備えた冗長ホストに接続することも、ディスク障害がビジネス停止となる老朽化した 1 台のサーバーに接続することもできる。アドレス数だけではどちらのバージョンが存在するかわからない。

NIST の古典的なクラウドコンピューティングの定義は、ネットワーク、サーバー、ストレージ、アプリケーション、サービスといった共有設定可能リソースへのオンデマンドネットワークアクセスを記述している。この定義は、顧客が消費するものとオペレーターが維持しなければならないものを分ける点で有用だ。最小のホステッドサービスであっても、実際のネットワークアクセス、実際の計算、実際のストレージ、実際の運用労力が必要である。DMAIL がホステッドキャパシティを販売しているならば、その販売は単なる 256 アドレスではない。それは、それらのアドレスの背後にある機器と契約に依存する権利なのである。

公開記録には、現在のセルフサービス VPS ストア、ベアメタル在庫、公開データセンターホール、サービスレベルスケジュール、バックアップポリシー、公開ステータスページ、ピアリングポリシー、顧客移行ガイド、または指名されたサポートエスカレーションは示されていない。この不在はサービスが非アクティブであることを意味しない。小規模ビジネスホスティングは関係主導で非公開でありうる。これは、正しい記事が製品カタログではないことを意味する。それは、薄くしか見えないネットワークのための修復マップである。何が失敗しうるか、誰がそれを修復できるか、そして単一プレフィックスの主張を信頼できるホステッドキャパシティのコミットメントに変えるにはどのような証拠が必要か、である。

法的アイデンティティはサービスカタログより明確

法的記録はロシアから始まる。公開のEGRUL 企業検索で OGRN 1157746030309 を照会すると、INN 7714326233 を持つ ООО "ДИРЕКТ ПОЧТА" が特定され、登録日は 2015 年 1 月 16 日、登録地域はモスクワである。同じ OGRN がRIPE 組織オブジェクト ORG-DML13-RIPEにも現れ、Direct Mail LLC を名乗り、国をロシアとし、登録番号 1157746030309 を記録し、モスクワの Vyatskaya Street のアドレスを記載している。したがって、法的記録とインターネットリソース記録は同じ企業アイデンティティを指しており、名前のない経路ではない。

商業的アイデンティティは、インフラ色がより薄い。RIPE の abuse メールボックスに関連付けられたドメインdirectpostcorporate.ruは、Директ Почта - товары почтой от производителяというタイトルの公開ページを表示しており、これはクラウドホスティングの店舗というより、通信販売商品の提案と訳せる。このページは、DMAIL の RIPE abuse ロールが同じドメインのアドレスを使用しているため関連がある。しかし、公開サイトが DMAIL 自身のネットワーク上で動作しているか、同社がデータセンター容量を小売り顧客に販売している証拠にはならない。

この区別は測定可能である。directpostcorporate.ruの公開 DNS は 89.104.80.93 を解決し、RIPEstat のこのアドレスのネットワーク情報ビューは、それを 89.104.80.0/21 に配置し、AS48287 の下で RU-CENTER が保有しており、DMAIL の 185.11.198.0/24 ではない。これは企業ウェブサイトの通常のホスティングアレンジである。また、企業ページを DMAIL 自身の経路容量の場所の証明として使用することを戒める。ウェブプレゼンスと広告された自律システムは別々の証拠層である。

これにより、分裂したプロファイルが生まれる。一方は法人格と公衆向け郵便販売ブランド。もう一方は、小さなロシアのアドレスブロックを持つインターネットルーティングオブジェクトである。公開証拠は、同じ運用チームが両方を運営しているか、アドレスブロックが内部商取引システム、顧客ワークロード、メールインフラ、小規模な管理ホスティングサービス、または将来の使用のために保持された休眠容量をサポートしているかどうかを示さない。安全な結論は、DMAIL には実際の経路ネットワークアイデンティティがあるが、クラウド購入者向けの公開サービスカタログは弱いということだ。

これは、あらゆる調達会話を形作るべきだ。購入者は、DMAIL が登録会社かどうか、AS205482 が見えるかどうかだけを尋ねるべきではない。両方の答えはイエスだ。購入者は、ホスティングまたは容量ラベルの下で実際に何が販売されているのか、サービスが購入者自身のワークロードのためか、DMAIL の通信販売業務のためか、契約が物理的場所、上流サプライヤー、バックアップ方法、サポート経路、退出権を明示しているかどうかを尋ねるべきである。小規模ネットワークは、狭いアプリケーションには完全に適切でありうる。それは、背後にある物理的約束を示さずに一般的なクラウドとして販売されると危険になる。

リソース記録は Mastertel を指し示す

185.11.198.0/24 アドレスブロックは、公衆の目に触れる中で最も具体的なインフラ資産である。RIPEstat のプレフィックス概要では、AS205482 によってアナウンスされ、保有者を DMAIL Direct Mail LLC としている。whois 記録は、ネット名を Direct-Mail-Network とし、Direct Mail LLC と記述し、国を RU とし、ステータスを ASSIGNED PA としている。アドレス空間階層は、/24 が 185.11.196.0/22 の中に位置し、それが Mastertel に登録されたより大きな割り当てであることを示している。

この親子関係は重要である。上流またはスポンサープロバイダからのプロバイダ集約可能アドレス空間は完全に安定しうるが、復旧に関する問題を変える。Direct Mail が Mastertel 管理のアドレス空間を通じてブロックを使用している場合、紛争、契約変更、ルーティングミス、プロバイダ側のインシデントがアドレスへの経路に影響を与える可能性がある。顧客は「DMAIL がダウンした」として停止を経験するかもしれないが、即時の修復アクションは部分的に Mastertel または経路内の別の上流に属する。

ルートオブジェクトも同じ趣旨である。RIPE のAS205482 によって発信された 185.11.198.0/24 のルートオブジェクトは、Direct Mail LLC を記述し、MASTERTEL-MNT によって維持されている。逆引き DNS 委任も、198.11.185.in-addr.arpa に対して Mastertel のネームサーバーをリストしている。abuse 連絡先ファインダーは、プレフィックスに対して Mastertel の[email protected]連絡先を返す。これらのエントリのいずれも悪いものではない。総合すると、Mastertel がアドレス管理、逆引き DNS、abuse ルーティングの主要な運用当事者であることを示している。

AS オブジェクトがもう 1 つの層を追加する。RIPE のAS205482 の aut-num 記録は、DMAIL を名指しし、組織 ORG-DML13-RIPE を関連付け、AS31261 および AS29226 に対するインポートとエクスポートポリシーをリストしている。登録されたポリシーは、現在の公開経路観測と完全には一致しておらず、AS8641 が支配的な可視上流として示されている。この不一致は、停止ではなくドキュメンテーションリスクとして扱うべきである。これは、公式記録だけではライブ設計を知るのに十分ではないことを言っている。

ホステッドキャパシティの顧客にとって、これらの記録は正確な質問を支持する。Mastertel のインフラに対して、DMAIL の機器はどこにあるのか？ Mastertel 接続の施設内か、リースポート上か、顧客ラック内か、プロバイダ管理サービス内か、別のキャリアによって供給されるハンドオフの背後か？公開記録はこの質問に答えない。それらは、DMAIL の 1 つのアナウンスブロックが、所有インフラの孤立した島ではないことを示している。それはプロバイダの文脈にあり、プロバイダの文脈は障害表面の一部となる。

2 つの上流名は 2 つの独立した経路と同じではない

RIPEstat のASN ネイバービューは、AS205482 に対して 2 つの観測されたネイバーを示す。AS8641 と AS29226 である。RIPEstat のAS8641 の AS 概要はそれを LLC "Nauka-Svyaz" と識別し、AS29226 の AS 概要はそれを JSC Mastertel と識別する。ドメイン間ルーティング層では、DMAIL に広域インターネットへの 2 つの可視経路を与える。

バランスは不均等である。RIPE の185.11.198.0/24 のルッキンググラスサンプルは、観測時点で 369 のピア経路を示した。繰り返されるオリジンプリペンドを無視すると、363 の可視経路が AS8641 を通じて AS205482 に入り、6 つが AS29226 を通じて入った。これは、トラフィックの 98% が必ずしも Nauka-Svyaz を使用することを意味しない。経路コレクターはトラフィックメーターではないからだ。しかし、公開ルーティングビューが Nauka-Svyaz に強く偏っていることを意味する。

上流自体は、DMAIL の可視フットプリントと比較してかなり大きい。RIPEstat の現在のAS8641 のルーティングステータスは、60 の IPv4 プレフィックス、IPv6 の可視性、数百の観測されたネイバーを示している。現在のAS29226 のルーティングステータスも、多くの IPv4 および IPv6 プレフィックスと数百の観測されたネイバーを示している。PeeringDB は、Nauka-SvyazとMastertelを、複数の施設とインターネットエクスチェンジプレゼンスを持つネットワークサービスプロバイダーとして提示している。これは有用な文脈だ。DMAIL の到達可能性は、より大きなネットワークによって運ばれている。

しかし、それは物理的な回復力の証明ではない。2 つの BGP ネイバーは、1 つの建物内で終端し、1 つのミートミールームを通って入り、1 つのラック電源チェーンに依存し、または分岐する前にメトロファイバー経路を共有する可能性がある。一方のプロバイダがアドレス管理者であり、他方がほとんどの可視経路を運んでいるかもしれない。顧客のサーバーは両方の経路の背後にありながら、その前にある単一のスイッチ、ハイパーバイザー、ストレージアレイ、または電力分配ユニットが故障すれば、依然として失敗する可能性がある。ルーティングテーブルはグローバルな到達可能性を見るが、ラックの配線、電源ランタイム、予備機器は見ない。

登録ポリシーの不一致も重要である。AS205482 の RIPE 記録は AS31261 と AS29226 からのインポートをリストしているが、現在の公開観測では AS8641 と AS29226 が示されている。RIPEstat のAS31261 の概要はそれを PJSC MegaFon と識別するが、AS31261 は ASN ネイバービューで現在の観測ネイバーの 1 つではなかった。これは、古い関係、非公開または非アクティブなアレンジメント、または可視インターネットと一致しなくなった経路ポリシーを反映している可能性がある。公開ポリシーが古い小規模ネットワークは依然として正常に動作しうるが、購入者はオブジェクトテキストに頼るのではなく、最新の上流図を求めるべきだ。

正しい冗長性テストは運用面である。Nauka-Svyaz 経路が引き出された場合、ホステッドサービスは許容可能なレイテンシとパケットロスで Mastertel を通じて到達可能であり続けるか？ Mastertel の管理チェーンが失敗した場合、経路、逆引き DNS、abuse 処理は依然として維持できるか？ 施設の停止が両方のアップリンクを除去した場合、現在のデータを持つ別のサイトがあるか？ 答えが「上流は多様である」であるなら、顧客は回線 ID、施設名、物理的入口、最近のフェイルオーバー記録を求めるべきである。これらの項目がなければ、AS205482 にはルーティング層の代替手段があるが、物理的な独立性は証明されていない。

ラックは欠けている場所である

IP ブロックの割り当てはサーバーを配置しない。ホステッドサービスには、ハードウェアまたは仮想化されたキャパシティが動作する場所が必要だ。リースラック、ケージ、キャビネット、パブリッククラウドテナント、管理ベアメタルサーバー、共有ホスティングアカウント、またはプロバイダ運営の仮想化クラスターである。DMAIL は、その可視ネットワークのために、施設名、フロア、アベイラビリティゾーン、ラック数、設置電力、冷却設計、キャリアリスト、リモートハンズプロバイダー、ストレージシステム、またはハイパーバイザースタックを公開していない。

この欠けている場所が記事の中心である。キャパシティがリースラックにある場合、最初の障害経路は通常通りだ。ブレーカーが落ちる、電源ユニットが故障する、トップオブラックスイッチがラインカードを失う、ディスクプールが劣化する、またはリモートハンズリクエストが他の作業の後ろに待たされる。キャパシティがプロバイダ管理のハードウェア上にある場合、DMAIL のサポートチームはサービスのトリアージはできても、故障した部品を物理的に交換できないかもしれない。キャパシティが別のプロバイダの仮想マシンの再販である場合、実際の修復クロックはほぼ完全にプロバイダに属するかもしれない。

公開記録はプロバイダ依存の構造に傾いている。アドレスブロックは Mastertel 割り当て内にある。経路と逆引き委任は Mastertel を通じて維持されている。現在の可視経路の大半は Nauka-Svyaz を通じて入り、少数が Mastertel を通じて入る。abuse ドメインに結びついた企業ウェブサイトは、DMAIL 自身の /24 ではなく、RU-CENTER を通じて解決する。これらの事実のいずれも、DMAIL がホステッドキャパシティを運用することを不適格にはしない。しかし、同社を大規模な独立したデータセンターエステートの所有者として扱うことに反論する。

設置容量と使用可能容量は異なる。設置された事実は単純だ。1 つの /24 が見える。使用可能容量は、サーバーの数、コア、メモリ、ストレージメディア、上流のコミット帯域幅、オーバーサブスクリプション、バックアップ帯域幅、サポートカバレッジに依存する。/24 は回復力のあるクラスターの前面に出ることができるが、1 台の控えめなマシンの前面に出ることもできる。ポートサイズ、トランジットコミットメント、ピーク利用率、顧客数、バックアップ保持期間、復元時間、またはサイトに保持されたスペアを示す公開文書はない。したがって、購入者は月額料金だけでなく、不確実性に価格を付ける必要がある。

ラックの場所はデータのローカリティにも影響する。DMAIL がロシアの顧客データをロシアでホストしているなら、顧客がローカリティの期待を満たすのに役立つ。しかし、ここでレビューされた公開証拠は物理サイトを特定していない。ロシアの個人データ規則は、場所を技術的な好み以上にする。Roskomnadzor のオペレーター登録環境と、公開されたGorodissky の第 18 条(5) ローカリティ義務の概要は、関連する個人データシステムがどこに維持されているかを知る必要性を指摘している。個人データを扱う購入者は、「RU」を十分な場所声明として受け入れることはできない。都市、施設、下請け業者、バックアップ場所、移行経路が必要である。

同じ質問がバックアップにも適用される。サービスはモスクワで動作し、別のロシアの都市、同じ施設、外国の場所、またはどこにもバックアップできる。各選択は法的および運用リスクを変える。ローカルのみのバックアップは合法的で高速だが、単一施設の損失に脆弱である。リモートバックアップは回復を改善できるが、ローカリティ、アクセス、レイテンシの問題を生じる可能性がある。DMAIL の公開ソースはバックアップ設計を述べていないため、任意のホステッドキャパシティ契約は、指名された回復場所とテストされた復元経路を要求すべきである。

ホステッドキャパシティは層で失敗する

第 1 層は顧客向けサービスである。DMAIL がアプリケーション、メールプラットフォーム、仮想サーバー、または小規模な管理環境をホストしている場合、顧客の停止は到達不能ドメイン、切断されたセッション、失敗した配信、遅延したジョブ、またはアクセス不能な管理パネルとして現れる。ユーザーは原因がディスク、電源、ソフトウェア、ルーティング、または請求であるかをめったに知らない。サービスプロバイダーの価値は、症状を迅速に故障層にマッピングする能力である。

第 2 層は計算とストレージである。仮想マシンはホストに依存する。データベースはディスク、メモリ、コントローラの健全性、スナップショット、バックアップに依存する。メールプラットフォームはキュー、レピュテーション、ストレージ、上流接続に依存する。単一の物理ホストが複数の顧客ワークロードを運ぶ場合、1 つのハードウェア障害が同時に多数の顧客に影響を与える可能性がある。プロバイダーにスペアホストとワークロードを移動する自動化があれば、停止は小さくなる。DMAIL の公開記録は、ホスト数、クラスタリング、ストレージレプリケーション、または予備ハードウェアを示していない。

第 3 層はラックと施設である。健全なサーバーでさえ、電力、冷却、物理的アクセスなしでは役に立たない。BEREC のネットワークレジリエンス概要は、コアおよびアクセスネットワーク全体でのバックアップ電源と継続性の取り決めの重要性を指摘している。ENISA のテレコムインシデント分析は、通信インシデントの再発原因として、システム障害、停電、ケーブル損傷を強調している。これらは DMAIL 特有のインシデントではないが、任意のホステッドキャパシティ購入者がテストすべき通常の障害タイプである。

第 4 層は上流接続である。DMAIL にとって、これは現在の可視経路セットにおける AS8641 と AS29226、および観測されていないまたはレガシーなアレンジメントを意味する。AS8641 がほとんどすべての観測された経路を運ぶ場合、Mastertel 経路が存在しても、そこの問題が見えるようになる可能性がある。Mastertel が経路オブジェクト、逆引き DNS、プレフィックス管理の中心である場合、AS8641 がトラフィックを転送しているときでさえ、Mastertel 側のアカウント、経路、abuse 処理の問題が問題になりうる。ホステッドサービスは、その支配的な上流、管理メンテナー、バックアップ経路の組み合わせと同じくらい信頼性がある。

第 5 層は請求と契約の継続性である。小規模なホステッドサービスは、劇的な技術的インシデントなしに失敗する可能性がある。プロバイダ契約が期限切れになる。データセンターの請求書が争われる。ドメインまたは証明書の更新が逃される。サプライヤーがアンチ abuse ポリシーを変更する。顧客は、ストレージ形式またはコントロールパネルがプロプライエタリであるため、データをエクスポートできない。DMAIL の公開証拠は、標準条件、サービス クレジット、データエクスポート権、またはサプライヤーバックツーバック義務を示していない。これにより、商業層が回復力の一部となる。

第 6 層は人である。薄い公の足跡は、しばしば小規模なチーム、関係販売、手動サポートを意味する。それは既知の顧客にとって良いことかもしれない。同じエンジニアがサービスを深く理解しているかもしれない。しかし、2 つのインシデントが同時に到着したとき、資格情報を持つ唯一の人が利用できないとき、またはサプライヤーが指名されたアカウント保持者にしか話さないとき、ボトルネックにもなりうる。DMAIL の公開ページは、サポート名簿、緊急電話番号、シフトスケジュール、エスカレーションマトリックス、またはリモートハンズ契約を開示していない。購入者は、サービスにパブリック IP スペースがあるからといって、24 時間のクラウドサポートを想定すべきではない。

ハードウェアストックと移行こそ真の経済的テスト

ホスティングの経済性は小規模では厳しい。顧客はクラウドの振る舞いを望む。迅速なセットアップ、予測可能な価格、短い回復、低いデータ損失、簡単な退出。プロバイダーは物理的なものに支払う。ラックスペース、ポート、電力、サーバー、ディスク、メモリ、ライセンス、監視、バックアップ、サポート時間、スペア、トランジット。小規模な単一プレフィックスプロバイダーは、特定の顧客ニーズに近いことで競争できるが、これらのコストを消すことはできない。

ハードウェア在庫は、回復力を最も簡単に過小投資できる場所だ。予備の電源ユニット、ディスク、スイッチ、サーバー、光学モジュールは、それを救う時までアイドルに見える。スペアを保持することは現金を消費し、互換性の知識を必要とする。サプライヤーの配送に依存することは、運搬コストを下げるが復旧を長くする。DMAIL について、スペアがサイトにあるか、サプライヤーの倉庫にあるか、第 2 施設にあるか、注文されるまで利用できないかを示す公開証拠はない。その不確実性は価格とサービス条件に反映されるべきだ。

トランジットも同じ経済的形状を持つ。より多くの上流容量とより多様なポートはお金がかかる。ほとんどの観測経路が Nauka-Svyaz を通じて DMAIL に到達するなら、真のフェイルオーバー設計には、支配的な経路が利用できないときに重要な負荷を運ぶのに十分な Mastertel または他の容量が必要である。バックアップ経路が到達可能性のためだけであり、全トラフィック用でないなら、インシデント前に顧客はそれを知るべきだ。安価なホスティングプランは、ベストエフォートのフェイルオーバーを賢明に含むかもしれない。ビジネスクリティカルなプランは、テストされたスタンバイキャパシティに支払うべきである。

サポート労力はオプションではない。ホステッドシステムは、BGP が見えているからといって自動的に復旧するわけではない。誰かがアラートを読み、問題が顧客ソフトウェアかプロバイダーインフラかを判断し、上流に連絡し、施設チケットを開き、バックアップを確認し、ハードウェアを交換し、顧客とコミュニケーションする必要がある。プロバイダーはリモートハンズを外注できるが、その場合の応答時間は施設のキューと契約レベルに依存する。DMAIL がハンズオン作業をより大きなネットワークに依存している場合、契約はそう述べるべきである。

移行は最後のコストである。顧客はしばしば、苦難の時に初めてポータビリティの限界を発見する。顧客は完全なディスクイメージをエクスポートできるか？ 文書化されたバックアップ形式があるか？ DNS レコードは顧客の管理下にあるか？ IP アドレスは移動できるか、それともリナンバーする必要があるか？ メールキュー、ログ、アカウントデータはエクスポート可能か？ 迅速な転送に料金がかかるか？ これらはいずれも DMAIL の公開資料に現れない。購入者は、プロバイダー紛争や停止後ではなく、データをアップロードする前に退出条件を交渉すべきだ。

これらの経済性は、正しい判断が「回避」でも「信頼」でもない理由を説明する。正しい判断は「サービスを証拠に一致させる」ことだ。DMAIL の公開ネットワークは、狭いホステッド機能をサポートできる。成熟したクラウドに通常付随する前提を公にサポートしていない。マルチサイトゾーン、公開された回復目標、ネイティブ IPv6、署名された経路起点認証、透明なステータスレポート、文書化されたエクスポート、24 時間体制のサポート。顧客が何が欠けているかを正確に知っているなら、低コストまたはプライベートなサービスは依然として合理的でありうる。

ルーティングセキュリティは未完成

ルーティング記録には注目すべき不在が 1 つある。RIPEstat のRPKI バリデーションチェックは、AS205482 と 185.11.198.0/24 に対して不明ステータスを返す。なぜなら、検証する ROA が見つからないからだ。RPKI は魔法の盾ではない。すべての経路漏洩を防ぎ、すべての AS パスを保護し、サーバーをオンラインに保つわけではない。しかし、有効な経路起点認証は、無効をフィルタリングするネットワークに、プレフィックスに対して認可されていない起点を拒否する暗号的な方法を与える。

小規模なホステッドキャパシティプロバイダーにとって、可視 ROA の不在は致命的ではないが、明確な改善項目である。ブロックは 1 つの /24 にすぎない。起点は既知である。メンテナーチェーンには Mastertel が関与する。正しい ROA を公開することで、回避可能なクラスのルーティングリスクを減らすことができる。プロバイダーがアドレス割り当てや契約の制約のためにそれを公開できない場合、その理由は、サービスがプレフィックスに依存する顧客によって理解されるべきである。

現在の経路は、可視 IPv6 を示していない。RIPEstat のルーティングステータスは、AS205482 の IPv6 プレフィックスをゼロと報告している。多くのロシアおよび国際サービスは依然として IPv4 上で動作し、狭いホステッドサービスはネイティブ IPv6 を必要としないかもしれない。しかし、「クラウド」の購入者は、特にグローバルなアプリケーションアクセス、監視、メール配信性インフラ、将来の保証のために、ますますデュアルスタック機能を期待している。DMAIL が IPv4 容量のみを販売している場合、その制限は明示的であるべきだ。

ルッキンググラスビューは、さらなるセキュリティと回復力の手がかりを提供する。いくつかの AS29226 経路は、AS205482 が数回プリペンドされていることを示している。AS パスプリペンディングは一般に、経路を好ましくなくするために使用される。DMAIL の場合、これは Nauka-Svyaz がより魅力的なインバウンド経路であり、Mastertel が観測された経路で好ましくない代替手段として機能していることと一致する。オペレーターのポリシー声明なしでは意図の証明にはならないが、非対称冗長性の読み取りを強化する。

顧客は 4 つのルーティングセキュリティ成果物を求めるべきだ。第 1 に、ライブ観測と一致する現在の上流リスト。第 2 に、経路起点認証ステータスとそれを維持する責任者。第 3 に、各上流とのプレフィックスフィルタリングと経路変更手順。第 4 に、AS8641 または AS29226 が引き出されたときに何が起こるかを示すフェイルオーバーテスト。これらは風変わりな要求ではない。単一プレフィックスのホステッドネットワークが信頼できるインフラとして扱われる前に必要な最小限の証拠である。

データ主権は国コードではなく、契約である

割り当て地域は RU であり、アドレスレコードはロシアである。これはローカリティの質問を枠付けるのに役立つが、それに答えはしない。185.11.198.0/24 の whois 記録は国を RU としている。組織記録はモスクワのアドレスを示している。企業ブランドはロシアである。directpost の企業サイトはロシア語である。これらの事実はロシアの運用コンテキストを支持する。それらはデータセンター、バックアップサイト、ストレージ下請け業者、ディザスタリカバリコピー、またはスタッフのアクセス境界を特定しない。

個人データを扱う顧客にとって、ローカリティは運用上具体的でなければならない。契約は、一次データがどこに保存されるか、バックアップがどこに保存されるか、誰が施設を運営するか、誰が顧客データにアクセスできるか、ログがどのように保持されるか、メディアがどのように破壊されるか、プロバイダー関係が終了した場合に顧客がどのようにデータを復旧できるかを述べるべきである。会社がロシアであること、または IP ブロックがロシアに登録されているという声明は、これらの事実を確立しない。

データ主権はサポートとも交差する。プロバイダーはサーバーをロシアに保持しながらも、監視、バックアップ暗号化、チケッティング、分析、または管理者アクセスのために外国のソフトウェアサービスに依存するかもしれない。逆に、国内サービスのみを使用しながらも、バックアップを一次ホストと同じ障害ドメインに保存するかもしれない。DMAIL の公開記録はどちらの設計も示していない。注意深い購入者は、広範な国籍主張ではなく、具体的な依存関係リストを求めるべきだ。

移行計画は主権の一部である。顧客がコンプライアンス、制裁エクスポージャー、サービスの劣化、サプライヤー変更のために迅速に離脱しなければならない場合、データの整合性を保持するエクスポート経路が必要である。小規模なホステッド環境では、最も簡単な安全な答えは、定期的な顧客所有のバックアップ、独立した DNS 管理、文書化された復元手順、プロプライエタリなロックインがないことかもしれない。これらの項目が欠けている場合、ローカリティは罠になりうる。データはローカルだが、必要なときに顧客はそれをきれいに移動できない。

ここで、DMAIL の弱いパブリックフットプリントは建設的なデューデリジェンスにつながるべきだ。会社は信頼をサポートするために顧客名や機密ダイアグラムを公開する必要はない。大まかな事実を開示できる。モスクワか非モスクワのホスティングエリアか、容量が所有ハードウェアかリース仮想化か、バックアップが同じ施設か別のサイトか、顧客がポータブルイメージを受け取れるか、施設インシデント中に利用可能なサポートチャネルはどれか。これらの事実がなければ、「RU」は回復の約束ではなく、管轄マーカーのままである。

最初に何が失敗するか

ラックの障害が最も単純なシナリオだ。ホストがクラッシュし、ストレージが失敗し、スイッチが電力を失い、施設スタッフが機器を再装着しなければならない。DMAIL がハードウェアを所有している場合、復旧はその監視、スペア、施設アクセスに依存する。サーバーまたは仮想環境を借りている場合、復旧はプロバイダーの修復キューに依存する。顧客は、誰が機器に触れられるか、交換部品がどこに保管されているか、プロバイダーが一度にダウンしている複数の顧客を抱えている場合に何が起こるかを尋ねるべきだ。

上流障害は可視ルーティングシナリオだ。AS8641 が 185.11.198.0/24 の搬送を停止した場合、小さな AS29226 経路が、負荷に対して設定およびプロビジョニングされていれば、到達可能性を維持するかもしれない。AS29226 に管理上または経路オブジェクトの問題がある場合、AS8641 がパケットを転送していても、逆引き DNS やアドレス管理タスクは依然として影響を受ける可能性がある。共有施設の障害が両方のセッションを削除した場合、どちらの経路も役に立たない。違いを知る唯一の方法は、各経路を引き出し、共有物理サイトを分離してテストすることだ。

ハードウェア在庫の障害は静かなシナリオだ。サービスがダウンし、診断は迅速だが、必要な部品が入手できない。予備のディスクはサイズが間違っている。電源ユニットはプロプライエタリだ。交換ルーターにはライセンスが必要だ。サーバーを十分に早く施設に配送できない。小規模なホステッドプロバイダーにとって、これはしばしば実際の復旧限界である。公開記録は DMAIL の在庫に関する情報を提供していないため、顧客は契約で期待を設定すべきだ。

サポート障害は人間のシナリオだ。オペレーターはアラートを見るが、上流アカウントチームに連絡できないか、施設が権限のない連絡先からの指示を受け付けないか、管理者アクセスを持つ人が利用できない。役割が明確であれば、単一プレフィックスネットワークは迅速に修復されうる。資格情報と権限が集中している場合、数時間ダウンしたままになる可能性がある。購入者は、指名されたエスカレーション、代替連絡先、および上流と施設のプロバイダーがこれらの連絡先を認識している証拠を求めるべきだ。

請求またはプロバイダー契約の障害は商業シナリオだ。プレフィックスとサーバーは技術的に健全でありながら、請求保留、終了通知、アンチ abuse 停止、未解決の顧客苦情によってサービスが損なわれる可能性がある。アドレスと経路記録における Mastertel の足跡は、サプライヤーの継続性を特に重要にする。顧客は、DMAIL が紛争中にサービスを維持するのに十分な契約上のコントロールを持っているか、サプライヤー関係が変わった場合にデータがエクスポート可能であり続けるかを知るべきだ。

移行障害は顧客のシナリオだ。サービスはオンラインかもしれないが、顧客は IP アドレス、メールレピュテーション、バックアップ履歴、アプリケーション状態を失うことなく離脱できない。小規模プロバイダーは、定期的なエクスポート、独立した DNS コントロール、文書化された復元手順、合意された引き継ぎ期間を顧客に与えることで、このリスクを軽減できる。DMAIL の公開資料はこれらの条件を示していない。これは、サービスをビジネスクリティカルと見なす人にとって最も明確な契約上のギャップである。

評価を上げるであろう証拠

DMAIL は、機密の顧客情報を露出することなく、公開インフラ評価を改善できるだろう。最初に、現在のサービス声明が役立つだろう。会社が VPS、ベアメタル、アプリケーションホスティング、管理メール、内部プラットフォーム容量、または自社の商取引運用のためのみのインフラを提供しているかどうかを述べるべきである。公開記録は現在、経路ネットワークの存在を支持しているが、そのネットワーク上で販売されているサービスを特定していない。

次に、場所声明が役立つだろう。ラック番号をリストする必要はない。都市、施設オペレーターの種類、DMAIL がハードウェアを所有するかリースするか、リモートハンズが社内か契約か、一次サイトとバックアップサイトが分離されているかどうかを名前で挙げることができる。これにより、抽象的な「RU」の場所が有用な運用境界に変わるだろう。

ルーティング声明は簡単だろう。現在の上流を特定し、RIPE aut-num 記録に残っている AS31261 エントリを説明し、AS8641 と AS29226 の意図された役割を記述し、両方が重要な負荷を運べるかどうかを述べるべきである。また、185.11.198.0/24 の ROA を公開するか、不在を説明するべきである。これらは、公開起点フットプリント全体が 1 つのプレフィックスであるネットワークにとって、低コストの開示である。

回復声明はマーケティング主張よりも価値があるだろう。バックアップ頻度、復旧目標、ハードウェアスペアポリシー、施設アクセスの取り決め、サポート時間、緊急連絡先、サービス クレジットの制限を示すべきである。応答と復旧を区別すべきである。チケットに応答することは、故障したサーバーを交換したり、ワークロードを別のサイトに移動したりすることと同じではない。

データポータビリティ声明が全体像を完成させるだろう。顧客に、データ、イメージ、メールキュー、ログ、DNS 設定、アカウントメタデータのエクスポート方法を伝えるべきである。終了後、データがどれくらい利用可能であり続けるか、請求紛争中に何が起こるかを述べるべきである。小規模プロバイダーにとって、透明な退出は誇張された冗長性よりも信頼できる。

これらの項目が公開されるか、購入者に非公開で提供されるまで、ネットワーク証拠の評価は広範なクラウドサービスの主張に対して弱いままである。会社は実在する。ASN はアナウンスされている。プレフィックスは可視である。上流経路には少なくとも 2 つの名前がある。しかし、中核的なクラウドの質問は未回答のままだ。ラックはどこにあるのか、マシンを誰が所有しているのか、誰が上流に支払うのか、電力はどれくらい持つのか、どんな予備部品が手元にあるのか、そして顧客はどうすれば害なく離脱できるのか？

狭いが防御可能な購入姿勢

DMAIL Direct Mail LLC を幽霊経路として退けるべきではない。法務記録、RIPE 組織記録、AS205482、185.11.198.0/24、現在のグローバルな可視性はすべて、本物の小規模ネットワークアイデンティティを指している。DMAIL がロシアのインターネットルーティングにおいて運用面を持っていると言うのに十分な証拠がある。

また、公開証拠のみで本格的なクラウドプラットフォームに格上げすべきでもない。マルチサイトプラットフォーム、所有ラック、公開 VPS プラン、データセンターリース、専任サポートデスク、予備ハードウェア在庫、復旧テスト、RPKI カバレッジ、IPv6 サービス、顧客ポータビリティ、または物理経路の多様性の公開証明はない。企業ウェブプレゼンスは通信販売商取引を指し、DMAIL 自身の /24 の外でホストされている。これは、英雄的な仮定ではなく、格下げを要求する種類の記録である。

最も強い解釈は、DMAIL のホステッドキャパシティは、顧客に提供されている場合、プロバイダ依存の小規模サービスであるということだ。その実際の回復力は、Mastertel、Nauka-Svyaz、機器が配置されている名前のない施設、行動を許可されたサポート担当者、および顧客がデータを移動できる条件に依存する。ワークロードが狭く、バックアップが独立しており、ダウンタイム耐性が正直であれば、購入者はこのようなサービスで作業できる。重要なプラットフォームを、冗長性、サポート、退出の現在の証拠なしにそこに置くべきではない。

価格は欠けている証拠を反映すべきだ。ロシアの小規模ネットワーク上のベストエフォート容量としてラベル付けされていれば、低コストプランは許容可能でありうる。より高い信頼性のプランには、指定されたサイト、経路の多様性、電力コミットメント、テストされたバックアップ、経路起点認証、サポートエスカレーション、ポータブルデータが必要だ。これらの提供の違いはマーケティングではない。今日到達可能なアドレスブロックと、ラック、トランジット、修復窓口の通常の障害を生き延びられるサービスとの違いである。