さまざまな VPC 設計で IDS に Packet Mirroring を使用する方法
Google Cloud Japan Team
※この投稿は米国時間 2021 年 3 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud のお客様の多くが、オンプレミスからクラウドに移行する際、ネットワークの可視性をオンプレミスと同レベルに維持しつつ、上位層のネットワークの異常を検出して警告するスケーラブルなソリューションを求めています。この要求を満たすには、Packet Mirroring をオープンソースの Suricata などの侵入検知システム（IDS）や、その他の推奨される脅威検出システムと組み合わせます。このタイプのソリューションは、クラウドで必要となる可視性をもたらします。つまり、悪意のあるアクティビティを検出、警告し、場合によってはそれ以降の侵入を防ぐためのセキュリティ対策を実装します。
ただし、利用可能な VPC 設計オプションの数を考えると、Packet Mirroring と IDS の設計戦略は混乱をきたす恐れがあります。設計オプションの例としては、Google のグローバル VPC、共有 VPC、VPC ピアリングなどがあります。このブログでは、Google Cloud でサポートされている VPC オプションを使用しながらネットワーク トラフィックを検査できるよう、さまざまな VPC 設計で Packet Mirroring と仮想 IDS インスタンスを使用する方法をご紹介します。
Packet Mirroring の基本
まずは Packet Mirroring についてもう少し詳しく説明いたします。Packet Mirroring は、Google Cloud ネットワーク環境で使用されるセキュリティとネットワーク分析の主要なツールの一つです。Packet Mirroring は、従来のネットワークのネットワーク タップやスパン セッションと機能が似ています。具体的には、選択された「ミラーリング対象のソース」からネットワーク トラフィック（上りと下り（内向きと外向き））をキャプチャし、トラフィックをコピーして、そのコピーを「コレクタ」に転送します。また、ヘッダーだけでなく、各パケットの全ペイロードをキャプチャします。さらに、Packet Mirroring はサンプリング期間に基づいていないため、パケットレベルの詳細なトラブルシューティング、セキュリティ ソリューション、アプリケーション レイヤ ネットワーク分析に使用することもできます。
Packet Mirroring は、次の 5 つの属性に関する「Packet Mirroring ポリシー」に依存しています。
リージョン
VPC ネットワーク
ミラーリング対象のソース
コレクタ（宛先）
ミラーリング対象のトラフィック（フィルタ）
Packet Mirroring ポリシーの例は次のとおりです。
Packet Mirroring ポリシーを作成するときには、以下の重要なポイントを考慮してください。
ミラーリング対象のソースとコレクタは同じリージョンに存在する必要がありますが、ゾーン、VPC、プロジェクトが異なっていても構いません。
コレクタは、内部ロードバランサ（ILB）の背後に配置する必要があります。
ミラーリング対象のトラフィックは、ミラーリング対象のソースで追加の帯域幅を消費します。それに応じてインスタンスのサイズを設定してください。
コレクタは、ミラーリング対象の VM がトラフィックを識別するのと同じ方法で、レイヤ 3 以上のネットワーク トラフィックを識別します。これには、Google Cloud 内の上位レイヤで発生する可能性のある NAT や SSL 復号が含まれます。
Packet Mirroring の作成と管理に特に関連するユーザーロールは 2 つあります。
「compute.packetMirroringUser」 - このロールを持つユーザーは、Packet Mirroring ポリシーを作成、更新、削除できます。このロールは、Packet Mirroring ポリシーが適用されるプロジェクトでは必須です。
「compute.packetMirroringAdmin」 - このロールを持つユーザーは、目的のターゲットをミラーリングしてトラフィックを収集できます。
Packet Mirroring を使用して IDS を強化
IDS は、トラフィックの検査ができるように、トラフィックを識別する必要があります。Packet Mirroring を使用すると、トラフィックを IDS のグループにフィードできます。トラフィックを IDS インスタンスに誘導するほかの方法と比べて、このアプローチにはいくつかの重要なメリットがあります。たとえば、一部のクラウドベースの IDS ソリューションには、各ソース VM で実行する特別なソフトウェア（つまりエージェント）が必要で、そのエージェントはトラフィックを複製して IDS に転送します。Packet Mirroring を使用すると、VM にエージェントをデプロイする必要がなく、トラフィックはクラウドネイティブな方法で IDS にミラーリングされます。また、エージェント ベースのソリューションは完全に分散されていて、ネットワークのボトルネックを防ぎますが、ゲスト オペレーティング システムがソフトウェアをサポートしている必要があります。さらに、エージェント ベースのソリューションでは、ゲスト VM とそのリソースがトラフィックの複製タスクを実行するため、VM の CPU 使用率とネットワーク トラフィックが確実に増加します。ネットワーク スループットに関連して CPU 使用率が高まることは、VM のパフォーマンスが低下する主な原因となります。
もう一つの一般的なアプローチは、仮想アプライアンスをネットワークの送信元と宛先の間に「インライン」で配置することです。この設計のメリットは、セキュリティ アプライアンスが侵入防止システム（IPS）として機能し、ネットワーク間の悪意のあるトラフィックを実際にブロックまたは拒否できることです。ただし、トラフィックがセキュリティ アプライアンスを介してルーティングされるインライン ソリューションは、同じ VPC の VM 内の East-West トラフィックをキャプチャしません。VPC ではサブネット ルートが優先されるため、静的ルートを介してトラフィックが供給されるインライン ソリューションは、VPC 内トラフィックについてアラートを出すことができません。そのため、ネットワーク トラフィックの大部分は分析されず、従来のインライン IDS / IPS ソリューションは、VPC またはネットワーク境界でのみトラフィックを検査します。
これらの問題はいずれも、Packet Mirroring で解決できます。Packet Mirroring を使用すれば、VM にソフトウェアを追加する必要がなく、ミラーリング対象の各 VM に完全に分散され、トラフィックの複製が SDN レイヤで透過的に行われます。コレクタ IDS は、ロードバランサの背後のパス外に配置され、North-South のトラフィックと East-West のトラフィックの両方を受信します。
各種 VPC 構成での Packet Mirroring の使用
Packet Mirroring は、次のような多くの VPC 設計で機能します。
単一のリージョンを持つ単一の VPC
複数のリージョンを持つ単一の VPC
共有 VPC
ピアリングされた VPC
これらの各シナリオに適用される推奨事項を以下に示します。
ミラーリング対象のインスタンスとコレクタには一意のサブネットを使用します。つまり、ミラーリング対象のソースとコレクタが同じ VPC にある場合は、各リージョン内に複数のサブネットを作成します。ミラーリングする必要のあるリソースを一方のサブネットに配置し、コレクタをもう一方のサブネットに配置します。コレクタ サブネットのデフォルトの推奨サイズはありませんが、そのリージョンに含まれている可能性のあるすべてのコレクタに十分なスペースを割り振るだけでなく、少しだけ追加のスペースを割り振ります。Google Cloud のリージョンにはいつでもサブネットを追加できます。
仮想 IDS インスタンスにパブリック IP を割り当てるのではなく、CloudNAT を使用して下り（外向き）インターネット アクセスを提供します。インスタンスにパブリック IP を割り当てないようにすることで、インスタンスがインターネットからのトラフィックに外部でさらされるのを防ぐことができます。
可能であれば、ILB の背後にある冗長コレクタ（IDS インスタンス）を使用して、高可用性を実現してください。
それでは、これらの設計を 1 つずつ見ていきましょう。
単一のリージョンを持つ単一の VPC
これは、サポートされているすべての設計の中で最も単純です。この設計では、ミラーリング対象のすべてのソースが標準 VPC の 1 つのリージョンに存在します。これは、ネットワーク管理がネットワーク チーム専用ではない、小規模なテスト環境や VPC に最適です。ミラーリング対象のソース、Packet Mirroring ポリシー、コレクタ ILB、IDS インスタンスはすべて、同じリージョンおよび同じ VPC に含まれています。さらに、CloudNAT は、IDS インスタンスにインターネット アクセスを許可するように構成されています。すべてが単一のリージョン、単一の VPC、単一のプロジェクトに含まれています。
複数のリージョンを持つ単一の VPC
ミラーリング対象のインスタンスとコレクタは同じリージョンに存在する必要があるため、サブネットが複数のリージョンに含まれている VPC については、複数のコレクタ、複数の ILB、複数の Packet Mirroring ポリシーが必要です。複数のリージョンを形成するには、前述のデプロイメントと同様のデプロイメントを複数回スタンプします。この場合も CloudNAT を使用することをおすすめします。
次の例は、2 つの異なるリージョンにまたがる単一の VPC を示していますが、同様のアーキテクチャを、任意の数のリージョンを持つ VPC に使用できます。
共有 VPC
Packet Mirroring は共有 VPC にも対応します。この例では、コレクタ（IDS）、ILB、Packet Mirroring ポリシーはすべて、ホスト プロジェクト内に存在します。コレクタは独自の非共有サブネットを使用します。ただし、ミラーリング対象のソース（WebServer）は、共有 VPC の共有サブネットを使用してサービス プロジェクト内に存在します。そのため、IDS ソリューションのデプロイメントを組織のクラウド ネットワーク運用グループに担当させることができ、アプリケーション開発者はアプリケーション開発に集中できます。CloudNAT は、IDS インスタンスにインターネット アクセスを許可するように構成されています。
ピアリングされた VPC
Packet Mirroring は、ハブアンドスポーク設計など、コレクタとミラーリング対象のソースが、ピアリングされた別々の VPC にある場合にもサポートされます。VPC 間でトラフィックをミラーリングするのと同じ要件が適用されます。たとえば、コレクタとミラーリング対象のソースは同じリージョンにある必要があります。以下の例では、ミラーリング対象のソース（WebServer）と Packet Mirroring ポリシーが DM_20 プロジェクトの VPC_DM_20 に存在しています。一方、ILB とコレクタ（IDS）は、DM_IDS プロジェクトの VPC_SECURITY という、ピアリングされた VPC に存在しています。これにより、ソース VPC のユーザーは、VPC ピアリングを介してコレクタに転送されるトラフィックを選択できます。CloudNAT は、IDS インスタンスにインターネット アクセスを許可するように構成されています。異なるプロジェクト間の Packet Mirroring のロールの要件に注意してください。適切な IAM 権限を設定する必要があります。
ネットワークの可視性を犠牲にしない
Packet Mirroring を使用してクラウド IDS ソリューションを強化することは、オープンソースであるか独自仕様であるかにかかわらず、多くの Google Cloud ユーザーが使用している優れたオプションです。重要なのは、コレクタ、ILB、Packet Mirroring ポリシー自体を配置する場所です。より高度な VPC 設計を使用する場合は、これはより一層重要です。複数の VPC と GCP プロジェクトをデプロイメントに導入すると、実装は複雑化するばかりです。このブログ投稿によって、より一般的な VPC 設計において IDS に Packet Mirroring を使用する方法がおわかりいただければ幸いです。実践的なチュートリアルについては、QwikLabs の Google Cloud Packet Mirroring with OpenSource IDS をご覧ください。このチュートリアルでは、VPC の作成、IDS インスタンスの構築、Suricata のインストール、Packet Mirroring のデプロイについて説明しています。
-PSO ネットワーク スペシャリスト Jonny Almaleh
