概要
- 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 のキャパシティは、同社がサイトの場所、電源設計、トランジット契約、予備ハードウェア、サポートエスカレーション、明確なデータポータビリティ条件を示すまで、リースされたラックまたはプロバイダ管理インフラに依存するものとして扱います。
1プレフィックスクラウド問題
クラウドという言葉は、しばしばインフラを軽く見せます。仮想サーバーはパネルに現れます。メールプラットフォームはキャンペーンを吸収します。ストレージバケットはファイルを保持します。ビジネスアプリケーションはあるホストから別のホストに移動します。顧客には、アドレス、ログイン、毎月の請求書、サポート連絡先が見えます。その下にあるハードな表面はそれほど優雅ではありません。ラックがあります。ルーターがあります。上流契約があります。電源、冷却、リモートアクセス、ハードウェア在庫、そして夜間に何かが故障したときに応答できる人がいます。
DMAIL Direct Mail LLC は、その物理的なレンズを通して読まれるべきです。その公開ネットワークの証拠は本物ですが、小さなものです。RIPEstat のAS205482 の AS 概要は、保有者を DMAIL Direct Mail LLC と特定し、ASN がアナウンスされていることを示しています。現在のルーティングステータスは、1つの IPv4 プレフィックス185.11.198.0/24（256アドレス）を示し、IPv6 のアナウンスはありません。アナウンスされたプレフィックスビューも同じ単一の/24を示しています。これは利用可能なインターネットリソースです。しかし、広範なクラウド資産ではありません。
狭い読み取りが重要なのは、/24が非常に異なる現実を支え得るからです。いくつかの公開ホスト、メールリレー、アプリケーションフロントエンド、管理インターフェース、顧客仮想サーバー、ネットワークアドレス変換ポイントなどを収容できます。モスクワのキャリア施設の1つのキャビネットからルーティングされることも、別のプロバイダのマネージドサービス下に設置された機器からルーティングされることもあります。冗長ホストに注意深くバックアップされて接続されることも、ディスク障害がビジネス停止になる老朽化した1台のサーバーに接続されることもあります。アドレス数だけでは、どのバージョンが存在するかを知ることはできません。
NIST のクラウドコンピューティングの古典的な定義は、ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの共有設定可能なリソースへのオンデマンドネットワークアクセスを説明しています。この定義は、顧客が消費するものと、オペレーターが維持しなければならないものを分離するのに役立ちます。最小のホスティングサービスでさえ、実際のネットワークアクセス、実際のコンピューティング、実際のストレージ、実際の運用労力を必要とします。DMAIL がホスティングキャパシティを販売する場合、販売は単に256アドレスではありません。それは、それらのアドレスの背後にある機器と契約に依存する権利です。
公開記録には、現在のセルフサービス VPS ストア、ベアメタル在庫、公開データセンターホール、サービスレベルスケジュール、バックアップポリシー、公開ステータスページ、ピアリングポリシー、顧客移行ガイド、または名前付きサポートエスカレーションは示されていません。この欠如はサービスが非アクティブであることを意味しません。スモールビジネスホスティングは関係主導でプライベートな場合があります。しかし、正しい記事は製品カタログではないことを意味します。これは、薄く見えるネットワークの修復マップです。何が失敗するか、誰が修復できるか、そして1つのプレフィックスの主張を信頼できるホスティングキャパシティコミットメントに変える証拠は何か、です。
法的アイデンティティはサービスカタログよりも明確
法的記録はロシアから始まります。公開のEGRUL 会社検索で OGRN 1157746030309を照会すると、ООО "ДИРЕКТ ПОЧТА"が INN 7714326233、登録日2015年1月16日、登録地域モスクワとして特定されます。同じ OGRN がORG-DML13-RIPE の RIPE 組織オブジェクトに現れ、Direct Mail LLC という名称、国ロシア、登録番号1157746030309、モスクワの Vyatskaya 通りの住所が記載されています。したがって、法人とインターネットリソースの記録は、名前のないルートではなく、同じ企業アイデンティティを指しています。
商業アイデンティティは、それほどインフラ重視ではありません。RIPE のアビューズメールボックスに関連付けられたドメインdirectpostcorporate.ruは、Директ Почта - товары почтой от производителяというタイトルの公開ページを表示します。これは通信販売の商品提案であり、クラウドホスティングのストアフロントではありません。このページは、DMAIL の RIPE アビューズロールが同じドメインのアドレスを使用しているため関連があります。それは、公開サイトが DMAIL 自身のネットワーク上で動作していることや、同社が小売バイヤーにデータセンタキャパシティを販売していることの証拠ではありません。
この区別は測定可能です。directpostcorporate.ruの公開 DNS は89.104.80.93に解決され、RIPEstat のそのアドレスのネットワーク情報ビューは、AS48287 (RU-CENTER) の89.104.80.0/21内に配置し、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 ネームサーバーをリストしています。アビューズコンタクトファインダーはプレフィックスの Mastertel の連絡先[email protected]を返します。これらのエントリのいずれも悪くはありません。まとめると、Mastertel がアドレス管理、逆 DNS、アビューズルーティングにおいて重要な運用当事者であることを示しています。
AS オブジェクトはさらに1つのレイヤーを追加します。RIPE のAS205482 の aut-num レコードは DMAIL を名前、組織 ORG-DML13-RIPE を関連付け、AS31261 および AS29226 のインポートおよびエクスポートポリシーをリストしています。登録されたポリシーは、AS8641 が支配的な可視上流である現在の公開ルート観測と完全には一致していません。このミスマッチは、運用上のリスクではなく、文書化リスクとして扱われるべきです。正式な記録だけではライブ設計を知るには不十分であると言っています。
ホスティングキャパシティの顧客にとって、これらの記録は正確な質問をサポートします。DMAIL の機器は Mastertel のインフラに対してどこにあるのか？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 の可視フットプリントに比べて substantial です。RIPEstat の現在のAS8641 のルーティングステータスは60の IPv4 プレフィックス、IPv6 可視性、数百の観測ネイバーを示しています。現在のAS29226 のルーティングステータスも多くの IPv4 および IPv6 プレフィックスと数百の観測ネイバーを示しています。PeeringDB はNauka-SvyazとMastertelを、複数の施設とインターネットエクスチェンジプレゼンスを持つネットワークサービスプロバイダとして提示しています。これは有用なコンテキストです。DMAIL の到達可能性は、より大きなネットワークによって運ばれています。
それは物理的な回復力の証明ではありません。2つの BGP ネイバーは1つの建物で終端し、1つのミートミールームを通り、1つのラック電力チェーンに依存し、分岐する前に1つのメトロファイバールートを共有する可能性があります。1つのプロバイダがアドレス管理者であり、別のプロバイダがほとんどの可視パスを運ぶことができます。顧客のサーバーは両方の経路の背後にありながら、その前の単一のスイッチ、ハイパーバイザー、ストレージアレイ、または配電ユニットが故障すると依然として障害が発生する可能性があります。ルーティングテーブルはグローバルな到達可能性を見ます。ラック配線、電力ランタイム、予備機器を見ません。
登録されたポリシーのミスマッチも重要です。AS205482 の RIPE レコードは AS31261 および AS29226 からのインポートをリストしていますが、公開観測は現在 AS8641 と AS29226 を示しています。RIPEstat のAS31261 の概要は PJSC MegaFon と特定していますが、AS31261 は ASN ネイバービューで現在観測されているネイバーの1つではありませんでした。これは古い関係、プライベートまたは非アクティブな取り決め、または可視インターネットに一致しなくなったルートポリシーを反映している可能性があります。公開されたポリシーが古い小規模ネットワークでも正常に動作できますが、購入者はオブジェクトテキストに頼るのではなく、現在の上流図を尋ねるべきです。
正しい冗長性テストは運用面です。Nauka-Svyaz ルートが撤回された場合、ホスティングサービスは Mastertel を通じて許容可能なレイテンシとパケットロスで到達可能ですか？Mastertel の管理チェーンが失敗した場合、ルート、逆 DNS、アビューズ処理は維持できますか？施設の障害が両方のアップリンクを除去した場合、現在のデータを持つ別のサイトはありますか？答えが「上流は多様である」場合、顧客は回線 ID、施設名、物理的入口、最近のフェイルオーバーレコードを求めるべきです。それらがなければ、AS205482 はルーティング層の代替手段を持ちますが、証明されていない物理的独立性を持ちます。
ラックが欠落している場所
IP ブロックの割り当てはサーバーを配置しません。ホスティングサービスは、ハードウェアまたは仮想化キャパシティが実行される場所、つまりリースラック、ケージ、キャビネット、パブリッククラウドテナント、マネージドベアメタルサーバー、共有ホスティングアカウント、またはプロバイダ運用の仮想化クラスターを必要とします。DMAIL は、その可視ネットワークについて、施設名、フロア、アベイラビリティゾーン、ラック数、設置電力、冷却設計、キャリアリスト、リモートハンズプロバイダ、ストレージシステム、ハイパーバイザースタックを公開していません。
この欠落した場所が記事の中心です。キャパシティがリースラックにある場合、最初の障害経路は普通です。ブレーカーが落ちる、電源が故障する、トップオブラックスイッチがラインナードを失う、ディスクプールが劣化する、またはリモートハンズリクエストが他の作業の後ろで待ちます。キャパシティがプロバイダ管理ハードウェア上にある場合、DMAIL のサポートチームはサービスをトリアージできますが、故障した部品を物理的に交換することはできません。キャパシティが別のプロバイダの仮想マシンの再販である場合、実際の修復クロックはほとんど完全にそのプロバイダに属します。
公開記録はプロバイダ依存の構造に傾いています。アドレスブロックは Mastertel の割り当て内にあります。ルートと逆委任は Mastertel を通じて維持されています。現在のほとんどの可視パスは Nauka-Svyaz を通り、少数が Mastertel を通ります。アビューズドメインに関連付けられた企業ウェブサイトは、DMAIL 自身の/24ではなく RU-CENTER を通じて解決されます。これらの事実のいずれも DMAIL がホスティングキャパシティを運用することを妨げません。しかし、同社を大規模な独立データセンタ資産の所有者として扱うことには反対します。
設置キャパシティと利用可能キャパシティは異なります。設置事実は単純です。1つの/24が可視です。利用可能キャパシティは、サーバー数、コア、メモリ、ストレージメディア、上流コミット帯域幅、オーバーサブスクリプション、バックアップ帯域幅、サポートカバレッジに依存します。/24は回復力のあるクラスターを前面に出すことができますが、1つの控えめなマシンを前面に出すこともできます。どの公開文書も、ポートサイズ、トランジットコミット、ピーク利用率、顧客数、バックアップ保持、復元時間、オンサイトスペアを示していません。したがって、購入者は月額料金だけでなく、不確実性に対して価格を付ける必要があります。
ラックの場所はデータローカリティにも影響します。DMAIL がロシアの顧客データをロシアでホストする場合、それは顧客がローカリティの期待を満たすのに役立ちます。しかし、ここでレビューされた公開証拠は物理サイトを特定していません。ロシアの個人データ規則は、場所を単なる技術的選好以上にします。Roskomnadzor の運営者登録環境と、Gorodissky による Article 18(5)のローカリティ義務の概要は、関連する個人データシステムがどこで維持されているかを知る必要性を指しています。個人データを扱う購入者は、「RU」を十分な場所の声明として受け入れることはできません。都市、施設、下請け業者、バックアップ場所、移行経路が必要です。
同じ質問がバックアップにも適用されます。サービスはモスクワで実行され、ロシアの別の都市、同じ施設、外国の場所、またはどこにもバックアップされる可能性があります。各選択は、法的および運用上のリスクを変更します。ローカルのみのバックアップは合法で高速ですが、単一の施設喪失に対して脆弱です。リモートバックアップは回復を改善できますが、ローカリティ、アクセス、またはレイテンシの問題を生み出す可能性があります。DMAIL の公開情報源はバックアップ設計を述べていないため、ホスティングキャパシティの契約には名前付きの復旧場所とテスト済みの復元経路が必要です。
ホスティングキャパシティはレイヤーで障害が発生する
最初のレイヤーは顧客向けサービスです。DMAIL がアプリケーション、メールプラットフォーム、仮想サーバー、または小規模マネージド環境をホストしている場合、顧客の障害は、到達不能なドメイン、切断されたセッション、配信失敗、遅延ジョブ、またはアクセスできない管理パネルとして現れます。ユーザーは、原因がディスク、電源、ソフトウェア、ルーティング、請求のいずれであるかをほとんど知りません。サービスプロバイダの価値は、症状を障害レイヤーに迅速にマッピングする能力です。
2番目のレイヤーはコンピューティングとストレージです。仮想マシンはホストに依存します。データベースはディスク、メモリ、コントローラの健全性、スナップショット、バックアップに依存します。メールプラットフォームはキュー、レピュテーション、ストレージ、上流接続に依存します。単一の物理ホストが複数の顧客ワークロードを運ぶ場合、1つのハードウェア障害が一度に多くの顧客に影響を与える可能性があります。プロバイダが予備ホストとワークロードを移動する自動化を持っている場合、障害は小さくなります。DMAIL の公開記録は、ホスト数、クラスタリング、ストレージレプリケーション、予備ハードウェアを示していません。
3番目のレイヤーはラックと施設です。健全なサーバーでも、電力、冷却、物理的アクセスがなければ役に立ちません。BEREC のネットワーク回復力の概要は、コアおよびアクセスネットワーク全体でのバックアップ電源と継続性の取り決めの重要性を指摘しています。ENISA の通信インシデント分析は、システム障害、電力切断、ケーブル損傷を通信インシデントの繰り返し原因として強調しています。これらは DMAIL 固有のインシデントではありませんが、ホスティングキャパシティの購入者がテストすべき通常の障害タイプです。
4番目のレイヤーは上流接続です。DMAIL の場合、これは現在の可視ルートセットの AS8641 と AS29226 に加え、観測されていないまたはレガシーの取り決めを意味します。AS8641 がほとんどすべての可視パスを運ぶ場合、Mastertel パスが存在しても、そこでの問題は可視的になり得ます。Mastertel がルートオブジェクト、逆 DNS、プレフィックス管理に中心的な場合、Mastertel 側のアカウント、ルート、アビューズ処理の問題は、AS8641 がトラフィックを転送している場合でも重要になり得ます。ホスティングサービスは、支配的な上流、管理メンテナー、バックアップパスの組み合わせと同じくらい信頼性があります。
5番目のレイヤーは請求と契約継続性です。小規模なホスティングサービスは、劇的な技術的インシデントなしに失敗する可能性があります。プロバイダ契約が期限切れになる。データセントの請求書が紛争になる。ドメインまたは証明書の更新が忘れられる。サプライヤーがアンチアビュースポリシーを変更する。ストレージ形式またはコントロールパネルがプロプライエタリであるため、顧客がデータをエクスポートできない。DMAIL の公開証拠は、標準条件、サービスクレジット、データエクスポート権、サプライヤーの背中合わせの義務を示していません。これにより、商業レイヤーが回復力の一部になります。
6番目のレイヤーは人です。薄い公開フットプリントは、しばしば小さなチーム、関係販売、手動サポートを意味します。これは既知の顧客にとっては良い場合があります。同じエンジニアがサービスを深く理解しているかもしれません。しかし、2つのインシデントが同時に発生した場合、資格情報を持つ唯一の人が不在の場合、またはサプライヤーが指名されたアカウントホルダーとのみ話す場合、ボトルネックになる可能性があります。DMAIL の公開ページは、サポート名簿、緊急電話、シフトスケジュール、エスカレーションマトリックス、リモートハンズ契約を開示していません。購入者は、サービスがパブリック IP スペースを持っているという理由だけで24時間のクラウドサポートを想定すべきではありません。
ハードウェア在庫と移行が真の経済的テスト
ホスティング経済学は小規模では厳しいです。顧客はクラウドの動作、つまり迅速なセットアップ、予測可能な価格、短い回復、低いデータ損失、容易な退出を望みます。プロバイダは物理的なもの、つまりラックスペース、ポート、電力、サーバー、ディスク、メモリ、ライセンス、監視、バックアップ、サポート時間、スペア、トランジットに対して支払います。小規模な1プレフィックスのプロバイダは、特定の顧客ニーズに近いことで競争できますが、これらのコストを消すことはできません。
ハードウェア在庫は、回復力に資金を供給するのが最も簡単な場所です。予備の電源、ディスク、スイッチ、サーバー、または光モジュールは、それを節約する時間までアイドルに見えます。スペアを保持することは現金を消費し、互換性の知識を必要とします。サプライヤーの配送に頼ることは運送コストを下げますが、復旧を長くします。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 を公開することは、1つの回避可能なクラスのルーティングリスクを低減します。プロバイダがアドレス割り当てまたは契約の制約のために ROA を公開できない場合、その理由はプレフィックスに依存するサービスを持つ顧客によって理解されるべきです。
現在のルートは可視の IPv6 も示していません。RIPEstat のルーティングステータスは AS205482 の IPv6 プレフィックスがゼロと報告しています。多くのロシアおよび国際的なサービスは依然として IPv4 で動作しており、狭いホスティングサービスはネイティブ IPv6 を必要としないかもしれません。しかし、「クラウド」の購入者は、特にグローバルなアプリケーションアクセス、監視、メール配信可能性インフラ、将来性のために、デュアルスタック機能をますます期待しています。DMAIL が IPv4 キャパシティのみを販売している場合、その制限は明示されるべきです。
ルッキンググラスビューは、さらなるセキュリティと回復力の手がかりを提供します。一部の AS29226 パスは AS205482 が数回プレペンドされていることを示しています。AS パスプレペンディングは、一般的にパスをより好ましくなくするために使用されます。DMAIL の場合、これは Nauka-Svyaz がより魅力的なインバウンドパスであり、Mastertel が観測されたパスで好ましくない代替として機能していることと一致します。オペレーターのポリシーステートメントがなければ意図の証明にはなりませんが、非対称冗長性の読み取りを強化します。
顧客は4つのルーティングセキュリティアーティファクトを求めるべきです。第一に、ライブ観測に一致する現在の上流リスト。第二に、ルートオリジン認証ステータスとそれを維持する責任者。第三に、各上流とのプレフィックスフィルタリングおよびルート変更手順。第四に、AS8641 または AS29226 が撤回されたときに何が起こるかを示すフェイルオーバーテスト。これらはエキゾチックな要求ではありません。1つのプレフィックスのホストネットワークを信頼できるインフラとして扱う前に必要な最小限の証拠です。
データ主権は契約であり、国コードではない
割り当て地域は RU であり、アドレスレコードはロシアです。これはローカリティの質問を枠組みするのに役立ちますが、答えにはなりません。185.11.198.0/24の whois レコードは国の RU を示しています。組織レコードはモスクワの住所を示しています。企業ブランドはロシア語です。直接郵便会社のサイトはロシア語です。これらの事実はロシアの運用コンテキストをサポートします。データセンター、バックアップサイト、ストレージ下請け業者、ディザスタリカバリコピー、スタッフアクセス境界を特定しません。
個人データを扱う顧客にとって、ローカリティは運用上具体的でなければなりません。契約は、一次データがどこに保存されているか、バックアップがどこに保存されているか、誰が施設を運営しているか、誰が顧客データにアクセスできるか、ログがどのように保持されるか、メディアがどのように廃棄されるか、プロバイダ関係が終了した場合に顧客がどのようにデータを回復できるかを述べるべきです。会社がロシアである、または IP ブロックがロシアに登録されているという声明は、これらの事実を確立しません。
データ主権はサポートとも交差します。プロバイダはサーバーをロシアに置きながら、監視、バックアップ暗号化、チケッティング、分析、管理者アクセスに外国のソフトウェアサービスに依存する可能性があります。逆に、国内サービスのみを使用しながら、バックアップを一次ホストと同じ障害ドメインに保存する可能性があります。公開 DMAIL 記録はどちらの設計も示していません。注意深い購入者は、広い国籍の主張ではなく、具体的な依存関係リストを求めるべきです。
移行計画は主権の一部です。顧客がコンプライアンス、制裁エクスポージャー、サービス劣化、サプライヤー変更のために迅速に離脱しなければならない場合、データ整合性を保持するエクスポートパスが必要です。小さなホスト環境では、最も簡単な安全な答えは、定期的な顧客所有のバックアップ、独立した DNS 制御、文書化された復元手順、プロプライエタリロックインなしです。これらが欠けている場合、ローカリティは罠になり得ます。データはローカルですが、顧客は必要なときにきれいにそれを移動できません。
これは、DMAIL の弱い公開フットプリントが建設的なデューデリジェンスにつながるべき点です。会社は顧客名や機密図を公開する必要はありません。大まかな事実を開示できます。モスクワまたは非モスクワのホスティングエリア、キャパシティが所有ハードウェアかリース仮想化か、バックアップが同じ施設か別のサイトか、顧客がポータブルイメージを受け取れるか、施設インシデント時にどのサポートチャネルが利用可能か。これらの事実がなければ、「RU」は回復の約束ではなく、管轄区域のマーカーに留まります。
最初に失敗するもの
ラック障害は最も単純なシナリオです。ホストがクラッシュする、ストレージが故障する、スイッチが電力を失う、または施設スタッフが機器を再設置しなければならない。DMAIL がハードウェアを所有している場合、回復は監視、スペア、施設アクセスに依存します。サーバーまたは仮想環境をレンタルしている場合、回復はプロバイダの修理キューに依存します。顧客は誰が機器に触れることができるか、交換部品がどこに保管されているか、プロバイダが同時に複数の顧客ダウンを抱えた場合に何が起こるかを尋ねるべきです。
上流障害は可視的なルーティングシナリオです。AS8641 が185.11.198.0/24の運搬を停止した場合、小さな AS29226 パスは、負荷のために構成およびプロビジョニングされていれば、到達可能性を維持するかもしれません。AS29226 に管理上またはルートオブジェクトの問題がある場合、AS8641 がパケットを転送していても、逆 DNS およびアドレス管理タスクが影響を受ける可能性があります。共有施設の障害が両方のセッションを除去した場合、どちらのルートも役に立ちません。違いを知る唯一の方法は、各パスを撤回し、共有物理サイトを分離してテストすることです。
ハードウェア在庫障害は静かなシナリオです。サービスがダウンし、診断は迅速ですが、必要な部品が利用できません。予備ディスクのサイズが合わない。電源がプロプライエタリである。交換ルーターにライセンスが必要。サーバーを施設に十分早く出荷できない。小規模ホスティングプロバイダにとって、これがしばしば実際の回復限界です。公開記録は DMAIL の在庫に関する情報を提供しないため、顧客は契約で期待値を設定すべきです。
サポート障害は人間のシナリオです。オペレーターはアラートを見ますが、上流のアカウントチームに連絡できない、または施設が許可されていない連絡先からの指示を受け付けない、または管理者アクセスを持つ人が不在です。1つのプレフィックスのネットワークは、役割が明確であれば迅速に修復できます。資格情報と権限が集中している場合、何時間もダウンしたままになる可能性があります。購入者は、指名されたエスカレーション、代替連絡先、および上流と施設のプロバイダがそれらの連絡先を認識していることの証明を求めるべきです。
請求またはプロバイダ契約の障害は商業的シナリオです。プレフィックスとサーバーは技術的に健全ですが、請求保留、終了通知、アンチアビュース停止、または未解決の顧客苦情によってサービスが損なわれる可能性があります。アドレスおよびルートレコードにおける 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、機器が置かれている名前のない施設、行動を許可されたサポート担当者、顧客がデータを移動できる条件に依存します。購入者は、ワークロードが狭く、バックアップが独立しており、ダウンタイム許容度が正直である場合、そのようなサービスで作業できます。購入者は、冗長性、サポート、退出の現在の証拠なしに、重要なプラットフォームをそこに置くべきではありません。
価格は欠落した証明を反映すべきです。低コストプランは、小規模ロシアネットワーク上のベストエフォートキャパシティとしてラベル付けされていれば許容できます。より高い信頼のプランには、名前付きサイト、ルート多様性、電力コミットメント、テスト済みバックアップ、ルートオリジン認証、サポートエスカレーション、ポータブルデータが必要です。これらのオファーの違いはマーケティングではありません。それは、今日到達可能なアドレスブロックと、ラック、トランジット、修理窓口の通常の障害に耐えられるサービスとの違いです。