高度なネットワーク脅威検出に Cloud IDS を最大限活用
Google Cloud Japan Team
※この投稿は米国時間 2021 年 7 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。
このたびプレビュー版の提供が開始された Google Cloud IDS は、クラウドネイティブかつマネージド型のネットワークベース脅威検出を提供するサービスです。Palo Alto Networks の業界をリードする脅威検知テクノロジーを用いて構築され、高水準のセキュリティ有効性を実現します。Cloud IDS を活用することで、お客様はネットワークベースの脅威に関する詳しい分析情報を取得でき、侵入検知システムの使用が求められる業界固有のコンプライアンス目標を達成できます。このブログでは、ネットワークベースの脅威を検出する Cloud IDS の仕組みと、Cloud IDS の実装を最大限に活用する方法について詳しくご紹介します。
Cloud IDS の有効な活用方法
仮想クラウド ネットワークへの Intrusion Detection System(IDS)の実装は、ネットワークを安全に保つための重要な手段として、クラウドを利用する多くのお客様にとっての要件となっています。
このようなシステムを統合するためのベスト プラクティスと設計戦略は、クラウド ネットワーキングの新しいテクノロジーとともに変化、成熟してきました。ネットワークのボトルネックや、VPC 内(east / west)のトラフィックを検査できないといった問題の克服は、これまでネットワーク チームやセキュリティ チームの悩みの種でした。Google Cloud IDS は「パスの外部」にデプロイされるため、これら両方の懸念を解消できます。Cloud IDS は Packet Mirroring を使用してネットワーク トラフィックのコピーと転送を行い、プライベート サービス アクセス(PSA)を使用して、Google マネージド プロジェクトに存在するクラウドネイティブな IDS インスタンスのセットに接続します。これにより、VPC の設計を変更することなく、Cloud IDS を既存の Google Cloud Platform(GCP)ネットワークにシームレスに統合できます。
IDS インスタンスによって検出された脅威と侵入を可視化するために、Cloud IDS は、脅威のログとセキュリティ通知を Cloud Logging とお客様のプロジェクトの Cloud IDS ユーザー インターフェースにフィードします。この処理はすべて内部で行われるため、Cloud IDS のデプロイと管理が簡単になります。ここでは、Cloud IDS をデプロイする際に知っておくべきこと、考慮すべきことを詳しくご説明します。
Cloud IDS エンドポイント(接続フローのコレクタ)を作成することから始まります。これにより、Google Cloud マネージド プロジェクトに存在する 3 つの Palo Alto VM シリーズ ファイアウォール仮想マシン(VM)がバックグラウンドでデプロイされます。
IDS エンドポイントの作成プロセス中に、分析するゾーンと VPC を指定する必要があります。特定の Cloud IDS インスタンスは、VPC のリージョン内のトラフィックを検査できます。
Palo Alto Networks からの更新は、Cloud IDS によって毎週取得され、既存のすべての IDS エンドポイントに push されます。
エンドポイントの作成時にアラートの最小重大度レベルを決定します。レベルは、「重大」(頻度が最も少ない)から「情報」(頻度が最も多い)までの間で選択できます。
IDS にトラフィックをフィードするには、Packet Mirroring ポリシーを作成してエンドポイントに接続します。
Cloud IDS に接続する Packet Mirroring ポリシーを作成する場合、サブネット、タグ、個別のインスタンスの 3 つのオプションから、ミラーリング対象のソースを選択できます。
サブネット: サブネットは、サブネット内のすべてのインスタンスを分析する必要がある場合に便利です。1 つのポリシーに、最大 5 つのサブネットを含めることができます。
タグ: タグは、1 つまたは複数のサブネットにあるインスタンスのグループを分析する必要がある場合に便利です。1 つのポリシーに、最大 5 つのタグを含めることができます。
個別のインスタンス: 特に限定されたインスタンスを分析する必要がある場合にのみ、個別のインスタンスを使用します。1 つのポリシーにつき、50 個のインスタンスを指定できます。
Cloud IDS を作成するための機能と手順についての理解が深まったところで、次に、デプロイの効果を最大限に引き出すための重要なポイントをいくつかご紹介します。
Packet Mirroring に適切なミラーリング対象ソースとフィルタを使用し、検査対象トラフィックを効果的に制御する
Packet Mirroring ポリシー内には、トラフィックをフィルタリングするオプションがあります。覚えておくべき点として、IP ベースのフィルタは指定されるアドレス範囲がリモート サブネットであることを前提としています。つまり、フィルタのアドレス範囲は、上り(内向き)トラフィックの場合はソース ネットワークになり、下り(外向き)トラフィックの場合は宛先ネットワークになります。一般的なインターネットベースのトラフィックなど、リモート ネットワークが不明な場合は、Packet Mirroring ポリシーで IP ベースのフィルタを使用しないでください。フィルタを使用するよう選択した場合、Packet Mirroring ポリシーによる IDS へのトラフィック送信が妨げられ、偽陰性の可能性が高くなります。また、フィルタを使用する場合は、Packet Mirroring のフィルタの順序に注意してください。フィルタ戦略の構成を誤ると、Cloud IDS のものではないトラフィックがミラーリングされてしまう可能性があります。最後に、[トラフィックの方向] フィルタ オプションで、常に双方向トラフィックをキャプチャします。
一方、フィルタが非常に有効なユースケースもあります。たとえば、信頼できるリモート ネットワークと信頼できないリモート ネットワークでアラートの重大度を別々に設定する場合を考えてみましょう。この場合、ミラーリングされたソースは同じでも、フィルタと「アラートの最小重大度」が異なる 2 つの IDS エンドポイントを作成できます。この構成では、信頼性の高いリモート ネットワーク トラフィックほど中程度のアラート重大度レベルで IDS エンドポイントに push されやすく、一般的なインターネット トラフィックは、より高頻度のアラートで IDS エンドポイントに push されます。
この例では、10.2.0.0/16 という信頼できるネットワークから送信されたトラフィックが ids-endpoint2 によって分析され、「中」レベル(およびそれ以上)の重大度でアラートが送信されます。一方、信頼できないインターネットから発信されたトラフィックは ids-endpoint1 にミラーリングされ、「情報」レベル(およびそれ以上)の脅威に対してアラートが送信されます。なお、以下のスクリーンショットの「インターネット IP」は、実際にはミラーリングされた VM から見た送信元アドレスを示していることに注意してください。
同一の IDS エンドポイントに複数の Packet Mirroring ポリシーを接続する
Cloud IDS の Packet Mirroring ポリシーの接続方法は柔軟で、複数の Packet Mirroring ポリシーを同一の IDS エンドポイントに接続することもできます。たとえば、「app1」というタグが付いたインスタンスのトラフィックをミラーリングする Packet Mirroring ポリシーと、「app2」というタグが付いたインスタンスのトラフィックをキャプチャする 2 つ目のポリシーの両方を「ids-endpoint-1」に接続できます。また、両方のネットワーク タグのトラフィックをキャプチャする単一のポリシーを設定することも可能です。現在、1 つのポリシーには最大 5 つのタグしか設定できないため、6 つ目のタグをポリシーに追加する必要がある場合は、IDS エンドポイントに 2 つ目のポリシーを接続する必要があります。
接続したポリシーは、他の Packet Mirroring ポリシーと同様に編集できます。エンドポイントからポリシーを削除するには、単純にそのポリシーを削除します。削除したポリシーはいつでも再作成が可能です。現状、「接続解除」オプションはありません。
複数のプロジェクトに共有 VPC と単一の Cloud IDS を使用する
ネットワーキングとセキュリティを一元的に管理するチームが組織内のさまざまなプロジェクトをサポートしていて、複数のプロジェクトに IDS の適用が必要な場合は、共有 VPC の使用を検討してください。共有 VPC を使用することにより、複数のプロジェクト間で Cloud IDS を含むネットワーク リソースを共有できるため、それらのプロジェクトを単一の Cloud IDS でサポートできるようになります。IDS エンドポイントは、共有 VPC が実際に存在するホスト プロジェクトに作成する必要があります。共有 VPC の Cloud IDS は、サービス プロジェクトに存在する個々のインスタンスを含め、従来の VPC と同じ 3 種類のミラーリング対象ソースをサポートします。
HTTPS ロードバランサを使用して SSL をオフロードする
Cloud IDS は、パケットの IP ヘッダーだけでなくペイロードも検査します。HTTPS / TLS / SSL トラフィックのようにペイロードが暗号化されている場合は、アプリケーションを L7 内部ロードバランサ(ILB)または HTTP(S) 外部ロードバランサの背後に配置することを検討してください。これらのタイプのロードバランサを使用することで、ミラーリング対象インスタンスの上位レイヤで SSL 復号を処理でき、Cloud IDS は SSL 復号済みトラフィックを認識して、侵入や脅威を検査、検出できます。Google Front End からロードバランサ バックエンドへの暗号化について詳しくは、こちらのドキュメントをご覧ください。
SIEM / SOAR ソリューションとの統合により、分析とアクションを追加で実行する
Cloud IDS からのログを、Cloud Logging からサードパーティ ツール(たとえば、Security Information and Event Management(SIEM)システムと Security Orchestration Automation and Response(SOAR)システム)に送信することで、セキュリティ運用チームの定義に準じて付加的な分析を行ったり迅速な緩和措置を講じたりすることができます。サードパーティ製の SIEM および SOAR システムは、Cloud IDS から取り込んだ情報に基づいて攻撃者の IP アドレスを自動的にブロックするハンドブックを実行するように構成できます。自動化を使用するか手動で行うかにかかわらず、プロキシベースの外部ロードバランサまたは内部ロードバランサの背後にあるターゲットに対し、記録されたソース IP をブロックする場合は、注意が必要です。プロキシベースのロードバランサは、実際の送信元アドレスをプロキシ アドレスに変換します。攻撃と認識されたアドレスを拒否すると、正当なトラフィックもブロックしてしまう可能性があります。このレベルのセキュリティには、Cloud Armor の使用を検討してください。Cloud Armor のウェブ アプリケーション ファイアウォール(WAF)とレイヤ 4 ベースのアクセス制御機能は、Cloud ロードバランサのソース NAT の前に配置されるため、セキュリティ スイートとして優れた組み合わせです。
セキュリティ ツールボックスへの Cloud IDS の追加
クラウドネイティブで、Google Cloud と統合されている Cloud IDS はデプロイが簡単で、高いパフォーマンスを発揮します。稼働させるにはわずか数回クリックするだけです。Cloud IDS は既存の VPC に簡単に追加でき、「パス外」に配置されるため、ネットワークの再設計はほぼ必要ありません。デプロイの完了から脅威検出が可能な状態になるまでが迅速です。また、侵入検知システムの使用が必須のコンプライアンス要件を満たすのにも役立ちます。
Cloud IDS の使用を開始するには、こちらの動画をご覧ください。プレビューへのアクセスは、Google のウェブページからお申し込みいただけます。
-Google Cloud PSO ネットワーク スペシャリスト Jonny Almaleh