O2Cloud O2 Cloud, LLC は依然としてラック、トランジット、保守窓口に依存するホステッドキャパシティを販売

概況

• O2 Cloud LLC には、割り当て仮説が示唆するよりも強力な現在の運営証拠がある。RBC Companies は、このロシア企業を2026年7月12日時点で活動中としてリストしており、登録番号 1187746216437、税番号 9710050732、2018年登録、平均従業員数22名、2025年の収益14億1800万ルーブル、2025年の利益3億7290万ルーブルとしている。RIPE も O2 Cloud LLC をロシアの LIR として記録しており、AS208349 は現在アナウンスされている。
• 公開されているサービス範囲は広範だ。OXYGEN は VMware パブリッククラウド、プライベートクラウド、レンタルサーバー機器、バックアップ、災害復旧、S3 スタイルのストレージ、マネージドデータベース、セキュリティ製品、スマートリモートハンドサポートを販売している。これらのページは有用なコンポーネントを説明しているが、予備容量、テスト済みフェイルオーバー、顧客固有の復旧時間、あるいは O2 Cloud LLC、OXYGEN ブランド、Business System Telehouse のデータセンター施設間の正確な法的境界をそれ自体で証明するものではない。
• ルーティング層におけるネットワーク証拠は強固だ。RIPE と Hurricane Electric は AS208349、AS-O2CLOUD、発信された IPv4 および IPv6 プレフィックス、MSK-IX の存在、RETN、Rascom、Rostelecom、MegaFon、StormWall を含む名前付きアップストリームを示している。これは単なるマーケティングではなく、実際の接続性の証拠だが、ラック、施設、サポートアカウント、支払いチャネル、制裁関連のサプライヤーパスが失敗した場合にアプリケーションの継続性が証明されていることとは依然として同じではない。
• したがって、本記事の運用上の格下げの理由は「脆弱な企業」ではなく、「検証されていない復旧境界」である。購入者は、施設の所有権、MSK East と MSK West の配置、ラックと電力経路、トランジットの独立性、バックアップ場所、復元テスト、ハードウェア在庫、データ可搬性、制裁への露出、そして顧客が通常のチケット対応を待てない場合に誰が対応できるかについて、書面による回答を要求すべきである。

公開記録は活動中の企業を証明するが、完全な復旧態勢を証明するものではない

小規模または地域固有のクラウドプロバイダーに関する最初の疑問は、そもそも運営の足跡が存在するかどうかだ。O2Cloud O2 Cloud, LLC にとって、その答えは、ごくわずかなウェブ上の足跡から発せられる警告が示唆するよりも強力だ。RBC Companies上のロシア企業プロフィールは、有限責任会社 O2 Cloud を活動中とし、2018年2月28日に登録、登録番号 1187746216437、税番号 9710050732、モスクワの法定住所、平均従業員数22名、コンピューターおよび情報技術作業を主たる活動コードとしてリストしている。RBC はまた、2025年の収益を14億1800万ルーブル、2025年の利益を3億7290万ルーブルと会計報告に基づき報告し、その企業プロフィールは公開データから得た参考情報であると述べている。

RIPE は第二のアイデンティティ層を提供する。ORG-OCL29-RIPE の RIPE 組織オブジェクトは、O2 Cloud LLC、国コード RU、登録番号 1187746216437、LIR ステータスを指定している。その住所はモスクワのトヴェルスカヤ通りであり、RIPE NOC ロールは O2 Cloud NOC、ヴォルゴグラツキー・プロスペクトの住所、電話番号、[email protected]のメールボックスを記載している。これらは顧客の声ではないが、ネットワークオペレーターがルーティング、不正利用、管理責任を調整するために使用するレジストリシステム内の運用記録である。

電気通信規制の記録も同じ方向を指している。Roskomnadzor の通信ライセンス登録簿は、O2 Cloud をテレマティクス通信サービスライセンスの下にリストしている。RBC と Roskomnadzor は同じロシアの法人格と税番号を使用しており、OXYGEN のウェブサイトは顧客向けのインフラブランドを提示している。総合すると、当該企業は法人格、認可された通信プロバイダー、インターネット番号保有者として認識できる。

しかし、それはより重要な顧客の問いに答えを与えるものではない。顧客は単に企業番号だけを必要としているのではない。自分のワークロードがどこで実行されるか、誰がラックを所有または管理しているか、誰がホールに入ることができるか、どのアップストリームがトラフィックを運ぶか、プライマリクラウドなしでどのバックアップコピーを復元できるか、サプライヤー、制裁当局、請求紛争がサポートへの通常のルートを遮断した場合に何が起こるかを知る必要がある。企業は活動中で、収益性があり、ルート可視性があっても、復旧に関する証拠が弱いことがある。

調達と切り離せない法的リスク層も存在する。OFAC のO2 KLAUD の制裁リスト検索詳細は、RBC および RIPE のアイデンティティと一致する登録番号 1187746216437 および税番号 9710050732 を持つ SDN エンティティをリストしている。2024年2月23日の財務省プレスリリースは、O2 Klaud がデータセンターを運営し、インフラセキュリティとネットワーク製品を提供しており、ロシアプログラムの下で指定されたと述べている。これはサービス停止の証拠ではない。これは、一部の顧客、ベンダー、決済代行業者、保険会社、ハードウェアサプライヤー、ソフトウェアライセンサーが、その関係を通常のクラウド契約として扱う前に、制裁遵守の問題として扱わなければならないという証拠である。

結果として、判断は分かれる。O2Cloud を実証されていない事業者として退けるべきではない。目に見える証拠は、実在するロシアのクラウドおよびネットワーク事業を裏付けている。しかし、本記事は企業の存在とマーケティングページを、顧客の復旧可能性の保証に変えるべきではない。正しい基準はより狭い。すなわち、顧客は自らの仮想マシン、データ、アドレス、ライセンス、サポート権限について、正確な障害経路を証明できるか？

OXYGEN が販売していると称するものは、たとえクラウドとして販売されていても、インフラである

OXYGEN サイトは広範なビジネスインフラカタログを提示している。ホームページは、クラウドインフラが機器レンタルや仮想マシンからデータベース管理、バックアップ、セキュリティ製品に至るサービスを提供すると述べている。パブリック VMware クラウドのページでは、VMware 上のパブリッククラウド、仮想データセンター、仮想マシン、設定可能な CPU、メモリ、ストレージ、ソフトウェア定義ネットワーキング、バックアップアドオン、サポートについて説明している。プライベートクラウドのページでは、専用環境とセキュリティおよびパフォーマンスに対するより強力な制御を必要とする顧客向けのプライベートクラウドについて説明している。サーバーレンタルのページでは、仮想容量だけでなく専用機器を提供している。バックアップのページはクラウドバックアップを販売し、災害復旧のページは障害が発生したサイト向けの復旧容量を販売している。

これらのページが重要なのは、サービスのカテゴリを特定しているからだ。O2Cloud は単にソフトウェアダッシュボードやコンテンツサイトを販売しているのではない。ホステッドコンピュート、ストレージ、ネットワーキング、バックアップ、リカバリー、サポートを販売しているのだ。これらのサービスは物理システムの上に成り立つ抽象化であり、サーバー、ストレージシェルフ、スイッチ、ルーター、ファイアウォール、クロスコネクト、配電、冷却、運用スタッフ、アップストリームキャリアや施設運営者との契約に依存している。

サービスカタログを読む上で最も有用な方法は、可視的な製品を見えない依存関係から分離することだ。パブリッククラウドの仮想マシンはアカウント設定のように感じられる。プロバイダーの内部では、それは有限の CPU コア、RAM、ストレージ I/O、バックアップ帯域幅、ネットワーク容量を持つクラスターへの配置決定である。レンタルサーバーは専用に聞こえるが、その専用性は正確なハードウェア在庫と保守プロセスへの依存を高める。バックアップ製品は保険のように聞こえるが、それはバックアップが一貫性があり、保持され、本番環境と同じ認証情報から保護され、独立した場所で復元可能である場合に限る。災害復旧製品は継続性のように聞こえるが、それは復旧サイトに予約済みの余裕、ルート容量、ライセンス、テスト済みのランブックがある場合に限る。

OXYGEN のページは有用なサービス内容を謳っている。しかし、リスクを評価するために必要なアーキテクチャのすべてを開示しているわけではない。顧客ごとのオーバーサブスクリプションポリシー、配置マップ、フェイルオーバーテスト履歴、ストレージレプリケーション設計、正確なハイパーバイザークラスター境界、スペアパーツ在庫、あるいはプロバイダーの通常のポータルを通さずに顧客がデータを取得できる状況を公開していない。これは商用クラウド販売では普通のことだが、購入者が「クラウド」という言葉に頼るのではなく、証拠を求めなければならないことを意味する。

ここでは所有権の境界が特に重要だ。RIPE は O2 Cloud LLC を AS208349 の背後にあるネットワーク保有者として識別している。Uptime Institute は、Business System Telehouseを、モスクワの Oxygen Data Processing Center、データホール 2 および 3 のクライアントとして識別している。OXYGEN と O2DC ブランドは公開資料でともに提示されており、O2 Cloud の RIPE ルーティングポリシーには、顧客または隣接するルーティングコンテキストに Business System Telehouse AS47440 が含まれている。これは公開記録における運営上の関連性を裏付けているが、電力、スペース、リモートハンド、ホステッドクラウド、セキュリティ、バックアップ、データ返却についてどの法人が責任を負うかを明記した顧客契約と同一ではない。購入者はブランドの連続性を契約の明確さの代わりにしてはならない。

モスクワの施設の話にはサイトレベルの証明が必要だ

OXYGEN のクラウドページはモスクワの施設所在地を示し、データセンター用語を使用している。公開ページは MSK East と MSK West の配置に言及し、O2DC の資料はモスクワのデータセンターネットワークを説明し、Tier III 特性を謳っている。Uptime Institute のアワードリストは、モスクワの Business System Telehouse において、Oxygen Data Processing Center のデータホール 2 および 3 が設計文書の Tier III 認証を取得していることを示している。これは実際の第三者による設計検証だが、その範囲が重要だ。これは特定のデータホールに対する設計文書の認証であり、OXYGEN ブランドの下で販売されるすべてのサービス、すべてのラック、すべてのクラウドクラスター、すべての継続性プロセスに対する普遍的な認証ではない。

この区別は細かいことではない。データセンターの信頼性は独立した障害ドメインから構築される。ホールが適切に設計された電源トポロジーを持っていても、顧客のデプロイメントには依然として単一のストレージシステム、単一のファイアウォールクラスター、単一の管理プレーン、1つのバックアップアカウント、1つの契約チェーンが存在する可能性がある。モスクワの2つの拠点は一部のリスクを低減できるが、同じ都市圏、同じプロバイダー管理、同じ制裁制約、同じソフトウェアスタック、同じサポートチーム、同じ請求システム、そして時には同じ長距離回線や交換ポイントへの依存といった他のリスクは共通のままとなる。

購入者が固めるべき物理的なリストは配置から始まる。どのホールがプライマリか？セカンダリホールはあるか？両方が使用中か、それとも一方は復旧指示後にのみ利用可能か？顧客はクラスター、ラック、電源供給、ストレージアレイ全体での反親和性を持っているか、それとも仮想マシン名全体でのみか？バックアップコピーはもう一方のモスクワサイトにあるのか、同じ施設内にあるのか、オブジェクトストレージにあるのか、それとも復元にプロバイダーのアクションが必要なメディアにあるのか？顧客はデータとログの所在地を選択または検証できるか？

電力と冷却に関する主張も、顧客レベルの解釈が必要だ。Tier III 設計は同時保守可能なインフラを目指しているが、両方の電源コードが同じラック配電ユニットに接続されている場合、ストレージコントローラーが依存関係を共有している場合、冷却インシデントが高密度ノードの制御されたシャットダウンを必要とする場合、あるいは計画メンテナンスが予備容量を持つ唯一のクラスターを使い果たしてしまう場合など、顧客環境は依然として障害を起こしうる。「Tier III」という表現は施設の疑問を狭めるが、クラウドプラットフォームの疑問に答えるものではない。

設置容量も、サービスページと復旧力が乖離する点だ。OXYGEN は vCPU、RAM、ストレージ、ネットワークオプションを宣伝する一方で、有限のクラスター内にワークロードを配置する権利を留保している。通常運用に十分な容量を購入した顧客は、ホスト、ストレージシェルフ、ラック、ホール、プロバイダーアカウントの障害時に稼働するのに十分な容量を必ずしも購入したとは限らない。復旧可能な容量には、復旧場所における予備の余裕、ワークロードをそこで起動させるライセンス、そしてユーザートラフィックのテスト済み経路が必要だ。

したがって、最も安全な読み方は肯定的だが条件的である。モスクワの施設記録は、漠然とした「どこかでホストされている」という主張よりは強い。それには名前の付いた場所、公開データセンターブランド、Uptime Institute による Business System Telehouse Oxygen ホールの設計文書証拠が含まれている。未解決の問題は、O2 Cloud の顧客ワークロードがこれらのホールにどのようにマッピングされるか、実際にいくつの独立した障害ドメインが購入されるか、そして誰がそれらを有効化するコストと権限を負うかだ。

ネットワークの可視性は実在するが、経路の多様性はアプリケーションの復旧ではない

O2 Cloud のネットワーク証拠は、記録の中で最も明確な部分の一つだ。AS208349 の RIPE aut-num オブジェクトは、AS208349 を O2CLOUDRU と命名し、ORG-OCL29-RIPE に関連付けている。同じオブジェクトは、RETN、Rascom、MSK-IX、Rostelecom、MegaFon、StormWall に対する IPv4 および IPv6 アップリンクポリシーをリストしている。また、AS-O2CLOUD 内の顧客またはダウンストリームの関係として、AS211933、AS47429、AS41667、AS47440、AS206904、AS206301、AS47763 を記録している。

RIPEstat の2026年7月12日時点のアナウンスされたプレフィックスのビューは、アクティブな AS208349 のアナウンスとして 45.134.124.0/22、5.35.120.0/23、いくつかの /24 経路、185.31.133.0/24、IPv6 ブロック 2a0e:7e40::/29 を示した。ルーティングステータスのビューは、AS208349 がアナウンスされており、クエリ時点で 325 の RIS ピア中 325 で完全な IPv4 可視性、322 の RIS ピア中 321 で IPv6 可視性を持つことを示した。Hurricane Electric のBGP Toolkit ページも同様に、ロシアの原産国、発信された IPv4 および IPv6 プレフィックス、1つのインターネットエクスチェンジ、発信された RPKI 無効なし、観測された BGP ピア、MSK-IX モスクワアドレスを示している。

これは有意義な運用証拠だ。O2 Cloud が可視的な番号資源を持たない単なるリセラー名ではないことを示している。アドレス空間を発信し、ルートオブジェクトを維持し、グローバルな BGP 測定に登場している。また、複数の名前付きアップストリームおよび交換経路を持つネットワーク設計も示している。顧客にとって、これは一つのリスクカテゴリを低減する。単一のキャリア障害が自動的に全設備を孤立させると想定すべきではない。

しかし、ルーティングの多様性には限界がある。2つのアップストリーム名は、同一ラックからの物理的に多様な2本のファイバーを証明するものではない。MSK-IX でのピアリングセッションは、プロバイダーのエッジ、ファイアウォール、ルートリフレクター、または DDoS クリーニングパスでの停止を顧客トラフィックが迂回できることを証明しない。StormWall のデフォルトルートは緩和オプションを改善できる一方で、フィルタリングポリシー、リダイレクション、インシデント調整への依存も追加する。可視的な IPv6 プレフィックスはアドレスファミリーのサポートを証明するが、顧客のアプリケーション、ファイアウォール、モニタリング、DNS、サポートプロセスが IPv6 フェイルオーバーに同等に準備できていることを証明するものではない。

顧客はまた、本番の到達性と制御プレーンの到達性を区別すべきだ。ポータル、請求アカウント、DNS、証明書アカウント、サポートチケットシステムが利用できない間も、仮想マシンは稼働し続けることができる。逆に、顧客のストレージネットワーク、ファイアウォールポリシー、ルーティング広告が誤っている間も、ポータルは到達可能でありうる。公開 BGP 記録はこれらの内部依存関係を解決できない。

テストすべき具体的な障害経路は「AS208349 にルートがあるか？」ではない。ある。テストは、1つのアップストリーム、1つのエクスチェンジ、1つのエッジデバイス、1つの DDoS パス、1つの DNS プロバイダー、1つのポータルアカウント、1つのモスクワ施設依存が利用できない場合に、顧客のアプリケーションが到達可能なままでいるかどうかだ。その答えが手動のプロバイダーアクションに依存する場合、顧客はエスカレーション連絡先、契約上の応答時間、そしてプロバイダーがその操作を最近実行したという証拠を必要とする。

修復窓口は人、部品、権限によって決まる

クラウド容量は、故障したディスク、ラインカード、電源ユニット、ファン、サーバーマザーボード、ストレージコントローラーが抽象化を再び修復イベントに引き戻すまで、弾力的に感じられる。OXYGEN のスマートリモートハンドのページは、したがって証拠の重要な部分である。セルフサービスの仮想容量だけでなく、顧客機器とデータセンター作業のためのエンジニアリングサポートを説明している。これはインフラにとって正しい運用用語だ。誰かが機器を受け取り、資産にラベルを付け、ポートを接続し、コンポーネントを交換し、ケーブリングをチェックし、物理アクセスを調整しなければならない。

リモートハンドは価値があるが、完全な修復保証ではない。施設のエンジニアはケーブルを交換できるかもしれないが、ハイパーバイザーにログインする権限はないかもしれない。クラウドエンジニアは仮想マシンを再起動できるかもしれないが、顧客の専用アプライアンスに触れる権限はないかもしれない。スペアディスクは利用可能かもしれないが、正確な RAID コントローラー、HBA、NIC、光モジュール、マザーボードはそうではない。時間外のエンジニアはチケットを迅速に認識するかもしれないが、ベンダーの部品、ソフトウェアライセンス、セキュリティ承認が後から到着する。

ここで、ホステッドキャパシティの取引が経済的になる。スペアハードウェアにはコストがかかる。予約されたコンピュート余裕にはコストがかかる。デュアルキャリアパスにはコストがかかる。ウォームリカバリーサイトにはコストがかかる。シニアエンジニアをオンコールで待機させるにはコストがかかる。魅力的な価格を提供するクラウドプロバイダーは、障害に備えてどれだけの未使用容量と人的可用性を保持するかを決定しなければならない。顧客は VM の価格表からその予備を見ることはできない。

O2 Cloud の制裁ステータスは、一部の取引相手にとって修復の問題を単なる通常のロジスティクス演習以上のものにする。OFAC のリスト掲載はサーバーが故障するとは言っていない。しかし、一部の米国関連サプライヤー、決済チャネル、ソフトウェアベンダー、リモートサービスプロバイダー、保険会社が制限されるか、直接取引をサポートしたがらない可能性があることを意味する。ロシア国外の購入者にとって、これは調達、契約の執行可能性、支払い、ハードウェア交換、ソフトウェアアップデート、緊急支援に影響を与えうる。ロシア国内の購入者にとっても、輸入部品、サードパーティのソフトウェア保守、国境を越えたサポートに影響を及ぼす可能性がある。

正しい証拠は実践的なものだ。顧客は、サポート重要度マトリックス、オンサイトの人員配置モデル、リモートハンドの範囲、スペアパーツのアプローチ、保守窓口、最近のインシデント例、ベンダー保守状況、通常のチケットキューが遅すぎる場合に行動する権限を持つ人物または役割を尋ねるべきである。専用機器については、誰がハードウェアを所有しているか、シリアル番号の追跡場所、互換性のある交換部品が在庫されているか、データを含むメディアがどのように取り扱われるかを尋ねるべきである。仮想クラウドについては、ホスト障害が自動的か、ストレージ障害が保護されているか、保守中またはホールレベルのインシデント中に十分な予備容量が存在するかを尋ねるべきである。

重要な点は、O2 Cloud に修復能力がないことではない。公開証拠はそれを証明していない。重要な点は、サービスがクラウドと呼ばれているからといって修復が含まれているわけではないということだ。修復は部品、アクセス、契約、人々の連鎖である。その連鎖を見ることができない顧客は、マーケティングページが暗示するよりも長い復旧時間を見込むべきだ。

影響を受ける当事者はアカウント所有者よりも広い

ホステッドキャパシティの障害は、請求書を支払う人で止まることはほとんどない。O2 Cloud がリテールのフロントエンドをホストしている場合、影響を受けるグループには、買い物客、決済代行業者、配送パートナー、在庫システム、サービス復旧後に取引を調整しなければならないスタッフが含まれる。ロシアの企業向けにデータベースやプライベートアプリケーションをホストしている場合、影響を受けるグループには従業員、請負業者、顧客、監査人、規制当局が含まれる可能性がある。AS208349 の背後または AS-O2CLOUD のダウンストリームメンバーとして顧客ネットワークを収容している場合、ルートまたはフィルタリングのエラーは、ユーザーが O2 Cloud の名前をまったく知らないかもしれない組織に影響を与えうる。

これが所有権の境界が重要な理由だ。ビジネスユーザーは「クラウド」や「バックアップ」を契約したかもしれないが、実際の復旧タスクは施設運営者、クラウドチーム、ネットワーク運用チーム、DDoS 緩和パス、ストレージベンダー、ソフトウェアライセンサー、請求アカウント、そしておそらく顧客インテグレーターにまたがる。平穏な月には、これらの層は1つのサービスのように見える。障害時には、それらは異なる権限を持つ別々のキューになる。顧客の契約がフロントラインの販売者のみを指名している場合、顧客は施設に電話をかけたり、リモートハンドを依頼したり、アップストリームに支払いをしたり、ライセンスを更新したり、ディスクを回収したりする立場にないかもしれない。

ダウンストリームのルーティング証拠は、これをより具体的にする。AS208349 ポリシーは O2 Cloud 自身のプレフィックスをアナウンスするだけでなく、AS-O2CLOUD を通じて他の AS 番号の経路も記述している。本記事はそれらの名前を検証済みの顧客リストとして扱わないが、ルーティング構造は依然としてネットワークが他の組織の前に位置しうることを示している。インフラプロバイダーが他の事業者のトランジットまたはホスティングの依存先になった場合、その自身の修復窓口はその事業者の公共の信頼性の一部となる。したがって、ルーターの再起動やフィルタリングの変更が、他の場所で顧客サービスの問題を引き起こす可能性がある。

請求もまた、影響を受ける当事者の経路だ。クラウドプラットフォームは技術的には健全でも、アカウントの停止、支払いブロック、制裁スクリーニング保留、管理上のエラーによってアクセスが失われることがある。これは O2 Cloud に対する特別な非難ではない。これは、プロバイダーが制裁下にあり、銀行、ベンダー、保険会社が義務を異なって解釈する可能性のある顧客と協働する場合に、より重要となる一般的なクラウド障害モードだ。顧客は、通常の支払いチャネルが失敗した場合に誰がアクセスを維持できるか、コンプライアンス審査が解決される間にサービスを維持するためにどのような文書が必要かを知るべきだ。

同じ論理がデータの返却にも当てはまる。ホストされたワークロードに個人データ、財務記録、医療情報、物流記録、訴訟に必要な証拠が含まれている場合、プロバイダーの停止はアクセス権の問題になりうる。ユーザーは、障害がラックの PDU、経路漏洩、ストレージスナップショットの問題、支払いブロックのいずれかを気にしないかもしれない。彼らが気にするのは、サービス所有者が記録を提示できるかどうかだ。そのサービス所有者は、同じ障害のあるポータルに依存しないデータへの経路を必要とする。

購入者にとって、これはサービスレベルに関する議論を変える。稼働率は有用だが不完全だ。購入者は、継続しなければならないビジネス機能のリスト（注文受付、支払い捕捉、内部認証、報告、メール、バックアップ取得、インシデント通知、規制証拠、顧客サポート）を必要とする。各機能は、依存する O2 Cloud コンポーネントと、そのコンポーネントが利用できない場合に機能する代替パスにマッピングされるべきだ。そのマップこそが、プロバイダーが1つの依存先なのか、1つのブランドを共有する複数の依存先なのかを見る唯一の方法である。

最も露出している顧客は、本番と復旧の両方にプラットフォームを使用している顧客だ。プライマリ仮想マシン、バックアップ、監視、DNS、セキュリティフィルタリング、緊急サポートがすべて1つのプロバイダー関係の中に存在する場合、顧客は利便性を購入したが、独立性を購入していない可能性がある。OXYGEN のカタログには復旧力のある設計に組み合わせることができる製品が含まれているが、組み合わせが重要だ。OXYGEN オブジェクトストレージ内のバックアップ、別の OXYGEN ホール内の復旧クラスター、同じ OXYGEN チームが管理するファイアウォールは、一部のロシアのワークロードにとって依然として強力な設計かもしれない。しかし、それはプロバイダーに依存しない脱出経路と同じではない。

したがって、本記事の警告は実践的である。O2 Cloud を使用するすべての組織は、どの当事者が最初に害を被るか、どの当事者に法的通知要件があるか、どのシステムを最初に再開しなければならないか、復旧を証明するためにどの証拠が必要かを決定すべきだ。その上で、その影響に合致する制御を O2 Cloud に求めるべきである。小さなテスト環境は手動復旧とベストエフォートの回答を許容できるかもしれないが、規制対象の本番システムはそうあるべきではない。

バックアップと災害復旧は、障害経路外での復元があって初めて意味を持つ

OXYGEN のバックアップアズアサービスのページはクラウドバックアップを宣伝し、災害復旧のページは緊急復旧を宣伝している。これらはホステッドキャパシティの体制において探すべき正しいサービスだ。同時に、デューデリジェンスにおける有用な罠も生み出す。バックアップ製品の存在は、特定の顧客が復元可能で、独立し、契約上ポータブルなコピーを持っていることを証明しない。

最初の問題はコピーの独立性だ。同じストレージアレイ上のスナップショットは、ストレージシステム障害に対する保護よりも、誤ったファイル削除に対する保護の方が優れている。同じホール内のバックアップは、電力、冷却、火災アクセス、プロバイダーアカウント、制裁関連のサプライヤー障害の喪失に対する保護よりも、アプリケーション破損に対する保護の方が優れている。別の OXYGEN サイトのレプリカは施設リスクを低減できるが、同じプロバイダーのコントロールプレーン、管理者資格情報、請求関係、法的管轄に依存する可能性がある。

第二に、一貫性の問題だ。仮想マシンのスナップショットは自動的にクリーンなビジネスシステムの復元にはならない。データベース、メッセージキュー、ファイル共有、ID システム、証明書、スケジュールされたタスク、暗号化キー、アプリケーションシークレット、統合が揃わなければならない。ERP、物流、小売、銀行インターフェース、規制対象の個人データにホスト型インフラを使用する顧客にとって、起動した VM は復旧した業務と同じではない。

第三に、時間の問題だ。NIST の事業継続計画ガイドは、事業影響分析、復旧戦略、テスト、計画保守を中心的な管理策として扱っている。NIST のストレージセキュリティガイダンスは、バックアップ、レプリケーション、スナップショット、復元保証を区別している。パブリッククラウドのガイダンスも同じことを運用言語で述べている。AWS の災害復旧オプションは、バックアップと復元からウォームスタンバイ、アクティブ-アクティブ設計まで様々であり、Google Cloud の災害復旧計画ガイドは、コピーの存在だけでなく、帯域幅、施設、サポート、電力、ネットワークインフラ、テスト済みの復旧を確認するようチームに求めている。

O2 Cloud の顧客にとって、実践的な証拠は復元レポートだ。それには、本番システム、バックアップソース、復旧場所、データ損失時点、経過した復旧時間、関与した人物、必要なネットワーク変更、テストされたアプリケーション、結果を受け入れたビジネスオーナーを明記すべきだ。バックアップがマネージドサービスの場合、プロバイダーとの関係が遮断された場合に、暗号化キーやドキュメントを含め、顧客が独立してコピーを取得できるかどうかもレポートに示されるべきだ。

災害復旧は停止後に購入するアクセサリーではない。それは容量の予約であり、手順である。購入者が MSK East の喪失を MSK West での起動によって生き延びさせたいなら、MSK West にはインシデント前に十分なコンピュート、ストレージ、ライセンス、ルーティング、ファイアウォールポリシー、サポート権限がなければならない。購入者が OXYGEN から完全に離脱したいなら、バックアップはプロバイダー非依存のフォーマットにエクスポート可能であり、顧客が管理するインフラ上でテストされなければならない。

データ所在地は境界が明示的な場合にのみ利益となる

この割り当てカテゴリにはデータ主権と所在地が含まれ、O2 Cloud は有用な事例だ。なぜなら、その価値提案は、国内ホスティング、ロシアのサポート、ローカル接続、152-FZ 個人データ整合を求めるロシアまたはロシア周辺の顧客にとって最も強力である可能性が高いからだ。OXYGEN はロシアの情報セキュリティと個人データのニーズに関連するサービスを販売している。Roskomnadzor の登録簿と RBC のプロフィールも、当該企業とその法人格をロシアに位置付けている。

ロシアの顧客にとって、所在地は真の運用上の利益となりうる。トラフィック経路は短縮できる。ロシアの個人データの配置は文書化が容易になり得る。サポートはローカルで行える。支払いと契約は国内調達と整合できる。一部のワークロードは、特にデータ輸出、規制当局のアクセス、言語、ローカルソフトウェアサポートが問題となる場合、外国のハイパースケールリージョンよりもロシアのプロバイダーの方が快適かもしれない。

しかし、所在地は完全な復旧力の制御ではない。すべてのプライマリおよび復旧コピーが1つの都市圏にある場合、地域的な施設や接続性の問題は依然として重要でありうる。同じプロバイダーがポータル、バックアップ、DNS、証明書、復旧環境を管理している場合、顧客には依然としてプロバイダー集中リスクがある。制裁が外国のソフトウェア、ハードウェア、支払いフローを複雑にする場合、ローカルホスティングは一部の法的問題を軽減する一方で、国際的な顧客にとって別の問題を生み出す可能性がある。

Microsoft の信頼性と主権に関するガイダンスは、トレードオフをうまく枠組み化している。リージョン間の冗長性は継続性を向上させるが、管轄、キー配置、オペレーターアクセスの問題を変える可能性がある。同じ論理が Azure の外でも当てはまる。第二の場所は、顧客のデータ所在地ルールの下で許容される場合にのみ価値があり、国内のみの展開は、顧客のダウンタイムとデータ損失の許容範囲を満たすのに十分な分離がある場合にのみ許容される。

したがって、O2 Cloud の顧客は1つではなく4つの場所を文書化すべきだ。本番データの所在地、レプリカの所在地、バックアップ、ログ、監視データの所在地、そしてサポートアクセスの発信元である。また、通常運用、緊急サポート、法的要請のシナリオにおいて、誰がデータにアクセスできるかを記録すべきだ。これが、「RU」が単なるリージョンラベル以上のものになるレベルだ。

制裁層は購入者層を変化させる。ロシアの顧客は主に現地の規制、稼働時間、価格、サポートを評価するかもしれない。多国籍企業、米国人、米国エクスポージャーのある銀行、米国技術を使用するベンダー、国境を越えた保険を必要とする企業は、技術的メリットに到達する前に OFAC リスクを評価しなければならない。これはインフラに対する道徳的な注釈ではない。支払い、サポート、契約執行、緊急調達に関する実際的な事実だ。

移行は冗長性の最後の砦だ

すべてのクラウド購入者はフェイルオーバーを望む。多くの実際の停止では、唯一の永続的なフェイルオーバーは離脱する能力だ。O2 Cloud 自身のカタログには移行と管理インフラに関するサービスが含まれており、これは移行が製品表面の一部であることを思い出させる。顧客は、退出権を法的な付属物ではなく、復旧機能として扱うべきだ。

移行の問題はインベントリから始まる。VMware 仮想マシンはライセンスされたオペレーティングシステム、データベース、ミドルウェア、独自のバックグラウンドサービス、ID 統合、バックアップクライアント、ファイアウォールルール、監視フックを含むことができる。専用サーバーにはファームウェア、RAID レイアウト、ローカルディスク、ベンダー保証が含まれうる。マネージドデータベースはレプリケーション設定、拡張バージョン、バックアップフォーマットを隠蔽しうる。セキュリティ製品は本番トラフィックの経路に存在しうる。これらのコンポーネントはいずれも、顧客がビジネスデータを所有しているからといって自動的に移行するわけではない。

顧客はインシデント前にポータブルな証拠を必要とする。それは、現在の構成エクスポート、VM イメージまたは再構築スクリプト、データベースバックアップ、暗号化キー、ライセンス記録、DNS と証明書の管理、ネットワーク図、ファイアウォールポリシー、サポート連絡先、およびサードパーティ統合のリストを意味する。また、移動先でのテスト容量も意味する。データベース抽出物は、保守窓口内に復元できなければポータブルではない。VM イメージは、移動先のハイパーバイザー、ストレージコントローラー、ネットワークモード、またはライセンスポリシーが拒否する場合、ポータブルではない。

NIST のクラウド概要と推奨事項は、サービス契約、データ転送、パフォーマンス、信頼性、セキュリティ、ポータビリティを相互に関連する購入質問として扱っている。これが O2 Cloud にとっても正しいフレームワークだ。購入者は単に「データを取得できるか？」と尋ねるべきではなく、どのフォーマットで、どのキーを使って、何時間以内に、どの帯域幅で、どの契約状態の下で、どのプロバイダースタッフが利用可能な状態で取得できるかを尋ねるべきだ。

O2 Cloud の公開ルーティングとサービス証拠は、多くの顧客が通常の本番ワークロードをそこで運用できることをもっともらしくしている。しかし、もっともらしさはクリティカルなシステムには不十分だ。退出テストは関係が健全な間に行われるべきだ。つまり、代表的なバックアップをプロバイダーの外に復元し、アプリケーションのコピーを立ち上げ、テストグループを代替パスに誘導し、データを調整し、プロバイダーが顧客の法的義務に従って古いコピーを削除または保持できることを確認する。

ワークロードが規制されるほど、移行には記録と証拠を含める必要がある。個人データシステムには場所とアクセスログが必要だ。金融システムには調整と監査証跡が必要だ。小売および物流システムにはインターフェースの継続性が必要だ。セキュリティシステムにはポリシーとログが存続する証拠が必要だ。請求、制裁、施設、サポートの紛争が始まるまで待つ顧客は、技術的な移行が問題の半分に過ぎなかったことを発見するかもしれない。

評決: 強力なネットワーク証拠、条件的な運用上の信頼

O2Cloud O2 Cloud, LLC は、強力なルーティング証拠と実質的なサービスブランドを持つ、活動中のロシアのインフラプロバイダーとして扱われるべきだ。同社は企業記録、通信ライセンス、RIPE に LIR として、AS208349 ルーティング、OXYGEN サービスページ、Business System Telehouse の Oxygen ホールに関連する第三者データセンター認証記録で視認できる。それは休眠状態のディレクトリエントリをはるかに超えている。

格下げの理由は存在ではなく、復旧の証明に関するものだ。公開ページはクラウド、バックアップ、復旧、セキュリティ、ハードウェアレンタル、サポートサービスを説明しているが、それらのサービスを復旧力に変える顧客固有の事実、すなわち正確な施設配置、電力とラックの分離、クラスター境界、予備容量、ストレージレプリケーション、経路の独立性、エスカレーション権限、バックアップの独立性、復元テスト、エクスポート権、制裁安全なサプライヤーパスを公表していない。

ローカルクラウド容量を必要とし、プロバイダーの法的環境を受け入れる通常のロシアのワークロードにとって、O2 Cloud は、契約とテストがワークロードに一致する場合、合理的な候補となりうる。国際的な取引相手、規制対象の個人データ、厳格な復旧目標、輸入ハードウェア依存、米国制裁規則へのエクスポージャーを伴うワークロードにとっては、デューデリジェンスのハードルはより高い。プロバイダーは実在しても、特定の顧客にとって誤った復旧境界でありうる。

実践的な答えは、修飾語句ではなく証拠を購入することだ。サイトマップ、AS パス、バックアップアーキテクチャ、直近の復元、スペア在庫ポリシー、サポートマトリックス、データ所在地スケジュール、制裁遵守の回答、そして退出パッケージを要求せよ。その上で、プライマリ施設、プライマリ経路、通常のサポートパス、プロバイダーのセルフサービスポータルを取り除く障害をテストせよ。ワークロードが事業の許容範囲内でその演習を生き延びるなら、O2 Cloud のホステッドキャパシティはクラウド購入者が支払う対価に見合う働きをしていると言える。そうでなければ、顧客の真の冗長性は依然としてプロバイダーの外にある。