隔離されたリカバリー環境ネットワークのアーキテクチャー
このようなソリューション・アーキテクチャーでは、サンドボックスは、バックアップのコピーにアクセスしたり、仮想マシン (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 セキュリティー・ポリシーにより、以下の表に示されている目標が実現されます。
ルール名 | ソース | 宛先 | サービス | アクション |
---|---|---|---|---|
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」という名前の分散ファイアウォール・ポリシーを作成します。このポリシーには、隔離要件を満たすための以下のルールが含まれています。
ルール名 | ソース | 宛先 | サービス | アクション |
---|---|---|---|---|
隔離へのアクセスを許可 (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
です。
必要なトラフィック・フローを以下の図に示します。ここで、
- 緑色は、許可されるトラフィック・フローを示します。
- 赤色は、拒否されるトラフィック・フローを示します。