IBM Cloud Docs
隔離されたリカバリー環境ネットワークのアーキテクチャー

隔離されたリカバリー環境ネットワークのアーキテクチャー

このようなソリューション・アーキテクチャーでは、サンドボックスは、バックアップのコピーにアクセスしたり、仮想マシン (VM) の起動に使用したりできる隔離されたネットワーク環境として定義されています。 これらは実稼働環境から隔離されているため、同じ IP アドレスを持つ VM によって重複 IP アドレスの競合が発生したり、リカバリーされた VM が実稼働 VM とやり取りしたりすることはありません。

Veeam® DataLabs ではサンドボックスの概念が有効になっていますが、VMware NSX-T™ 環境ではまだ有効ではありません。これは、NSX-T セグメントから隔離セグメントにマッピングできないためです。 そのため、これらのソリューション・アーキテクチャーでは Veeam と VMware NSX-T の両方のテクノロジーを使用するサンドボックスを有効にします。

  • Veeam vPower NFS サービス - バックアップ・ファイルから VM を直接開始できます。
  • Veeam Data Integration API - ファイル・システムへのバックアップ・ファイルのマウントを可能にします。
  • NSX-T オーバーレイ・セグメント - 物理ネットワークから抽象化された仮想ネットワークに、VM を接続できるようにします。
  • NSX-T T1 - ルーティング機能とゲートウェイ・ファイアウォール機能を提供します。
  • NSX-T 分散ファイアウォール - 分散ファイアウォールにより、VM 上の East-West トラフィックでファイアウォール機能が有効になります。

また、隔離されたリカバリー環境でも、ゲートウェイクラスター上にホストされた vSRX アプライアンスと管理VMが使用され、エアギャップ環境を提供します。 通常の運用では、インバウンド・トラフィックのみが DMZ ゾーン内の VM へのアクセスするように制限されます。

孤立復旧環境ネットワーク概要*
復旧環境ネットワーク概要
孤立復旧環境ネットワーク概要

上の図は、分離されたリカバリ環境で使用される VMware Cloud Foundation for Classic - Automated インスタンスの統合クラスタに関連するネットワークを示しています。 顧客の注文は以下のようになります。

  • プライベートネットワークのみのVCF for Classic - Automatedインスタンスで、ゲートウェイクラスターとJuniper® vSRXファイアウォールを備えています。
  • ベアメタル・サーバーの Veeam サービス。
  • Ubuntu 20.04 LTS を実行するベア・メタル・サーバー。

IaaS がプロビジョンされたら、以下を行います。

  • プロビジョニング・プロセス中に作成されたサンプル・セグメントを削除します。
  • ワークロード T0 および T1 を保持します。
  • サービス T0 に変更しません。
  • DMZ セグメントを作成し、いくつかの Microsoft® Windows® Jump ホストと Linux® bastion ホストをプロビジョニングします。 このようなアクションによって、サイバー・チームは隔離を行いながら環境にアクセスできます。
  • vSRX を以下について構成します。
    • システム・サービスおよびローカル管理者のアクセス権。
    • 管理サービス (NTP、DNS、SNMP、syslog など)。
    • インターフェースとゾーン。
    • アドレス・ブック、サービス、およびセキュリティー・ポリシー。
    • NAT、ルーティング、および VPN。
  • VCF for Classic - Automated インスタンスのVLANと IBM Cloud® ゲートウェイデバイス(ゲートウェイクラスタ内のESXiホスト)を関連付け、経由させます。

vSRX セキュリティー・ポリシーにより、以下の表に示されている目標が実現されます。

vSRXセキュリティポリシーの目的
ルール名 ソース 宛先 サービス アクション
DMZ へのアクセスを許可 サイバー管理者 IP DMZ サブネット SSH、RDP 許可
インスタンス管理へのアクセスを許可 DMZ インスタンス管理 SSH、HTTPS、TCP-9392、DNS 許可
実稼働環境への Veeam アクセスを許可 Veeam バックアップ・サーバー IP 実動 vSphere 管理ネットワーク HTTPS 許可
プロキシーへの Veeam アクセスを許可 Veeam バックアップ・サーバー IP 実動プロキシー・ネットワーク SSH、TCP-6162、TCP-2500 -3300 許可
強化 Linux リポジトリーへのプロキシー・アクセスを許可 実動プロキシー・ネットワーク 強化 Linux リポジトリー IP TCP-2500 から 3300 許可
IBM Cloud サービスへの ADDNS アクセスを許可 ADDNS IP DNS および NTP IP TCP/UDP-53, UDP-123 許可
VCF for Classic - Automated サブネット間のアクセスを許可する VCF for Classic - Automated サブネット VCF for Classic - Automated サブネット 任意 許可
vCenter が KMIP を使用できるように許可 vCenter IP IBM Cloud エンドポイント・サービス・ネットワーク TCP 5696 許可
  • TCP-9392 - Veeam リモート・コンソールが Veeam サーバーにアクセスする際に使用する TCP ポート番号。
  • このソリューション・アーキテクチャーでは、Veeam のバックアップ・プロキシーは Linux になります。 したがって、以下のステップが必要です。
    • プロキシへのバックアップサーバー、例えば、SSH、 TCP-6162 (Veeam Data Moverポート)、 TCP-2500 から3300(Veeamデータ転送チャネル)。
    • プロキシーからバックアップ・サーバーへの接続 (TCP-2500 から 3300 (Veeam データ伝送チャネル) など)。
  • Veeam バックアップ・サーバー・アクセスから隔離されたリカバリー vCenter およびホストへのアクセスは、接続済みのネットワークを介して行われます。
  • Veeam バックアップ・サーバーから強化 Linux リポジトリーへのアクセスは、接続済みのネットワークを介して行われます。
  • Linux へのプロキシアクセスを許可するリポジトリのルールは、「許可」と「拒否」を切り替えることができ、エアギャップを促進します。
  • NFS を使用する場合、ストレージ VLAN は、vSRX アプライアンスをホストする IBM Cloud ゲートウェイ・デバイスに関連付けられていないため、このアクションは vSRX をバイパスします。
  • VCF for Classic - Automated サブネット間のアクセスを許可するルールをさらに厳しくロックダウンする必要がある場合は、 VMware Solutions が使用するポート の詳細をご覧ください。
  • 暗号化が使用されている場合、vCenter は KMIP サービスにアクセスする必要があります。 このサービスには、IBM Cloud エンドポイント・サービス・ネットワーク 166.8.0.0/14 を介してアクセスします。
  • 自動化された Day 2 操作が VCF for Classic - Automated インスタンスで必要な場合は、展開および Day 2 操作に使用されるポート を参照してください。

エア・ギャップを有効にする場合、お客様は以下を行います。

  • T1 という名前の Cyber-Tools-T1 を作成し、それをワークロード T0 にリンクします。 Cyber-T1 は、接続されたセグメントを広告するように設定されています。 このアクションにより、接続されたセグメントにある VM との間のトラフィックのルーティングが可能になります。
  • それらの管理 VM 用のセグメントを作成します。
  • Linux および Ansible を実行する管理 VM を作成します。 管理 VM では、必要なときに vSRX アプライアンスのセキュリティー・ポリシーを変更します。
  • 自動化サーバーでクーロン・ジョブを使用して、インバウンド・ファイアウォール・ルールを「拒否」から「許可」に変更する Ansible Playbook の実行をスケジュールします。 バックアップのタイミングの後、お客様がインバウンド・ファイアウォール・ルールを「許可」から「拒否」に変更します。

実稼働環境のサイバー・バックアップを有効にするために、お客様は以下を行います。

  • ベアメタル・サーバー上の前提条件タスクに従って、強化 Linux リポジトリーとしての役割に対応できるようにサーバーを準備します。
  • 強化 Linux リポジトリーが有効になった Veeam バックアップ・サーバーを使用します。
  • 隔離されたリカバリー環境の vCenter を Veeam バックアップ・サーバー構成から削除します。
  • 実動 vCenter を Veeam バックアップ・サーバー構成に追加します。
  • Veeam VMware プロキシー・サーバーを作成し、実稼働環境にデプロイします。
  • 必要な実動 VM のサイバー・バックアップ・ジョブを作成します。

サイバー・バックアップでサイバー関連のタスク (バックアップ・ファイルでマルウェアを探すスキャンや、隔離されたネットワーク上のバックアップからの VM のリカバリーなど) を有効にするには以下を行います。

  • マルウェア・スキャナーが組み込まれた、サイバー・ツール・セットのセグメントを作成します。
  • Isolated-NW-T1 という名前の T1 を作成し、作業負荷 T0 にリンクします。Isolated-NW-T1 は、すべてのNAT IPアドレスだけをアドバタイズするように設定されています。 このアクションにより、接続されたセグメントのアドバタイズメントが停止され、セグメントの NAT IP アドレスのみがアドバタイズされます。
  • 以下の 2 つの分散ファイアウォール・グループを作成します。
    • 名前: Cyber-Tools-Segments、カテゴリー: Segments、メンバー: Cybertools
    • 名前: Cyber-Isolated-Segments、条件: Segment Tag Equals Isolated-Segments、範囲: Cyber
  • 「Cyber-Isolated」という名前の分散ファイアウォール・ポリシーを作成します。このポリシーには、隔離要件を満たすための以下のルールが含まれています。
NSX-T分散ファイアウォールルール
ルール名 ソース 宛先 サービス アクション
隔離へのアクセスを許可 (Allow access to Isolated) Cyber-Tools-Segments Cyber-Isolated-Segments すべて 許可
隔離間のアクセスを許可 (Allow access between Isolated) Cyber-Isolated-Segments Cyber-Isolated-Segments すべて 許可
隔離へのアクセスを拒否 (Deny access to Isolated) 任意 Cyber-Isolated-Segments すべて 拒否
隔離からのアクセスを拒否 (Deny access from Isolated) 任意 Cyber-Isolated-Segments すべて 拒否

サンドボックスが必要な場合、お客様は各自で希望するスクリプト・ツールを使用して、以下を自動的に行います。

  • T1 上のネットワークのデフォルト・ゲートウェイの IP アドレスを使用して、Isolated-NW-T1 に接続される論理セグメントを作成します。 以下の図では、NW2 と NW3 に一致するサブネットを持つ 2 つのセグメント Isolated-NW2 および Isolated-NW3 が示されています。 これらのセグメントは、タグと範囲 (「範囲: Cyber」および「タグ: Isolated-Segments」など) を指定して作成されます。 これらのタグおよび範囲は、前のテーブルにリストされている分散ファイアウォール・グループおよびルールで使用されます。
  • cyber-tools セグメントの送信元アドレスを使用する IP パケットについて、宛先サブネットを変換済みサブネットにマップする宛先 NAT ルールを作成します。 例えば、Src=172.16.67.2->Dst=172.16.68.2 => Src=172.16.67.2->Dst=172.16.253.2 です。

必要なトラフィック・フローを以下の図に示します。ここで、

  • 緑色は、許可されるトラフィック・フローを示します。
  • 赤色は、拒否されるトラフィック・フローを示します。

イミュータブル・バックアップ環境サンドボックスの例*
環境サンドボックスの例
イミュータブル・バックアップ環境サンドボックスの例