2024年8月29日

【Google Cloud】Cloud NGFW Standard を試してみた


Content

はじめに

こんにちは。
Cloud Next Generation Firewall(以下、Cloud NGFW)がリリースされて以降、いくつかの機能が追加がされており、
さらに、2023/09/27 に「FQDN オブジェクト」も GA となったことで、Cloud NGFW Standard で実現できる機能が増えております。

今回は「Cloud NGFW Standard」で提供される下記の機能について検証していきたいと思います。

  • FQDN オブジェクト
  • 位置情報のフィルタリング
  • Google Cloud Threat Intelligence

Cloud NGFWとは

1.Cloud NGFW とは

Google Cloud ワークロードを広範囲かつ高度な機能で保護する完全分散型のファイアウォール サービスです。
マネージド サービスのため、インフラの管理の考慮が不要です。

Cloud NGFW には3つの料金ティアがあり、それぞれ利用できる機能に違いがあります。
(2024年6月時点の情報のため、最新情報は公式ドキュメントをご確認ください。)

特徴 Essentials Standard Enterprise
ファイアウォールポリシー
タグの統合
ステートフルインスペクション
アドレスグループ
Google Cloud Threat Intelligence
FQDN オブジェクト
位置情報のフィルタリング
侵入防止システム( IPS )
TLS 復号

※ 「侵入防止システム( IPS )」についてはこちらのブログで検証していますので、あわせてご参照ください。

2.Cloud NGFW Standard で利用できる機能について

Cloud NGFW Standard では、Essentials で提供される基本的な機能に加え、以下の機能が利用できます。

機能 概要
FQDN オブジェクト 完全修飾ドメイン名(FQDN)オブジェクトを使用して、特定のドメインとの間で送受信されるトラフィックをフィルタ
位置情報のフィルタリング 特定の地理的位置またはリージョンに基づいて外部トラフィックをフィルタ
Google Cloud Threat Intelligence 脅威インテリジェンス データに基づいてトラフィックをフィルタ

3.Cloud NGFW Standard の利用料金について

Cloud NGFW Standard の利用料金は、処理したトラフィック量に対する従量課金となります。

製品 データ処理の金額
Cloud NGFW Standard $0.018 / GB

検証準備

それでは検証環境を準備します。
今回は、位置情報による検証も行うため「東京リージョン」と「US リージョン(us-central1)」にそれぞれ1台ずつ Compute Engine を用意しました。
それぞれ、エフェメラル外部 IP アドレス を割り当てて、インターネットに直接接続できるようにします。
なお、Compute Engine 同士が内部通信経由でアクセスできないよう、別の VPC を準備しています。

構成概要図

環境準備

① 権限準備
作業アカウントに下記のロールが付与されていることを確認します。

  • Compute セキュリティ管理者 (roles/compute.securityAdmin)
  • Compute ネットワーク管理者 (roles/compute.networkAdmin)
  • Compute インスタンス管理者(v1) (roles/compute.instanceAdmin.v1)

② 検証用の Compute Engine を作成します。
東京リージョン側の Compute Engine には Web サーバ (Apache) をあらかじめインストールし、「index.html」が閲覧できる状態にします。

・ 東京リージョン (asia-northeast1)
・ US リージョン (us-central1)
③ ファイアウォール ポリシーの作成
以下の内容でファイアウォール ポリシーを作成します。

名前 ngfw-standard-filter
デプロイのスコープ リージョン
リージョン Tokyo (asia-northeast1)
関連付け VPC (ポリシーを割り当てる VPC 名)

Google Cloud コンソールの場合:
ナビゲーション メニューから 「ネットワーク セキュリティ」>「ファイアウォール ポリシー」を選択し、「ファイアウォール ポリシーの作成」を選択します。その後、ウィザードに沿って、作成した「ファイアウォール ポリシー」を VPC に割り当てます。

 

gcloud CLI の場合:


gcloud compute network-firewall-policies create \
ngfw-standard-filter \
--region=asia-northeast1

gcloud compute network-firewall-policies associations create \
--firewall-policy ngfw-standard-filter \
--network (ポリシーを割り当てる VPC 名) \
--firewall-policy-region=asia-northeast1

 

④ ファイアウォール ポリシーにルールを作成します。
現時点では「許可」にてルールを作成し、検証時に「拒否」へ変更してフィルタの効果を確認します。

ルール #1 ルール #2 ルール #3
優先度 2000 2002 2001
説明 特定サイト向けのアクセスを拒否 特定ロケーションからのアクセスを拒否 特定カテゴリからのアクセスを拒否
トラフィックの方向 下り 上り 上り
アクション 許可 許可 許可
フィルタ FQDN:
sight-r.sts-inc.co.jp
位置情報:
日本
Google Cloud Threat Intelligence:
パブリック クラウド IP

Google Cloud コンソールの場合:
作成した「ファイアウォール ポリシー」を選択し、「ルールの追加」をクリックしてそれぞれのルールを作成します。

gcloud CLI の場合:


gcloud compute network-firewall-policies rules create 2000 \
--action allow \
--firewall-policy ngfw-standard-filter \
--description "特定サイト向けのアクセスを拒否" \
--layer4-configs=all \
--direction EGRESS \
--src-ip-ranges 0.0.0.0/0 \
--dest-fqdns (アクセスを拒否するサイト) \
--enable-logging \
--firewall-policy-region=asia-northeast1

gcloud compute network-firewall-policies rules create 2002 \
--action deny \
--firewall-policy ngfw-standard-filter \
--description "特定ロケーションからのアクセスを拒否" \
--layer4-configs=all \
--direction INGRESS \
--src-ip-ranges 0.0.0.0/0 \
--src-region-codes JP \
--enable-logging \
--firewall-policy-region=asia-northeast1

gcloud compute network-firewall-policies rules create 2001 \
--action deny \
--firewall-policy ngfw-standard-filter \
--description "特定カテゴリからのアクセスを拒否" \
--layer4-configs=all \
--direction INGRESS \
--src-ip-ranges 0.0.0.0/0 \
--src-threat-intelligence iplist-public-clouds \
--enable-logging \
--firewall-policy-region=asia-northeast1

以上で 「ファイアウォール ポリシー」 の準備ができました。

それでは早速検証してみましょう。

検証

1.FQDNオブジェクトによるフィルタ

特定サイトを FQDN 指定でアクセス拒否することで、フィルタ効果の検証を行います。

1-1:該当のサイトへアクセスします。
今回は本サイト (Sight-R:サイタル) を対象に、アクセス制御を検証します。
フィルタリング ルール #1 が「許可」となっている場合は、正常にアクセスができます。

1-2:フィルタリング ルール #1 を 「許可」から「拒否」へと変更します。

Google Cloud コンソールの場合:
ナビゲーション メニュー より、[ネットワーク セキュリティ] – [ファイアウォール ポリシー] – [ネットワーク ファイアウォール ポリシー] を選択し、(ファイアウォール ポリシー名)から、該当のルール(優先度)のアクション を「許可 → 拒否」へ変更する。

gcloud CLI の場合:


gcloud compute network-firewall-policies rules update (該当のルール(優先度)) \
--firewall-policy (ファイアウォール ポリシー名) \
--firewall-policy-region=asia-northeast1 \
--action deny

1-3:再度、該当のサイトへアクセスします。
フィルタリング ルール #1 を「拒否」に変更すると、アクセスがタイムアウトになることが確認できます。
また、Cloud Logging にも 拒否ログが記録されていました。

  • Cloud Logging 該当ログ


1-4:検証結果
FQDN オブジェクトで指定した場合も、アクセス制御が機能していることが確認できました。
logging の状況から推測すると、FQDN から IP アドレスを問い合わせた後、フィルタをかけているようですね。

 

2.位置情報オブジェクトによるフィルタ

特定ロケーションからのアクセス拒否することで、フィルタ効果の検証を行います。

2-1:該当のサイトへアクセスします。
今回は日本からのアクセスを対象に、フィルタを制御します。
フィルタリング ルール #2 が「許可」となっている場合は、正常にアクセスができます。

  • 東京リージョン → 東京リージョン

  • USリージョン → 東京リージョン

2-2:フィルタリング ルール #2 を 「許可」から「拒否」へと変更します。

Google Cloud コンソールの場合:
ナビゲーション メニュー より、[ネットワーク セキュリティ] – [ファイアウォール ポリシー] – [ネットワーク ファイアウォール ポリシー] を選択し、(ファイアウォール ポリシー名)から、該当のルール(優先度)のアクション を「許可 → 拒否」へ変更する。

gcloud CLI の場合:


gcloud compute network-firewall-policies rules update (該当のルール(優先度)) \
--firewall-policy (ファイアウォール ポリシー名) \
--firewall-policy-region=asia-northeast1 \
--action deny

2-3:再度、該当のサイトへアクセスします。
フィルタリング ルール #2 を「拒否」に変更すると、日本からのアクセスがタイムアウトとなることが確認できます。
また、Cloud Logging にも 拒否ログが記録されていました。
一方、USリージョンからは、正常にアクセスができます。

  • 東京リージョン → 東京リージョン

  • USリージョン → 東京リージョン

  • Cloud Logging 該当ログ

2-4:検証結果
位置情報にて日本からのアクセスフィルタを指定した場合も、アクセス制御が機能していることが確認できました。

 

3.脅威インテリジェンスによるフィルタ

特定の脅威インテリジェンス データからのアクセス拒否することで、フィルタ効果の検証を行います。

3-1:USリージョンより、東京リージョンのサイトへアクセスします。
今回は「パブリック クラウド IP」 からの Webアクセスを拒否することで検証を行います。

3-2:フィルタリングルール #3 を 「許可」から「拒否」へと変更します。

Google Cloud コンソールの場合:
ナビゲーション メニュー より、[ネットワーク セキュリティ] – [ファイアウォール ポリシー] – [ネットワーク ファイアウォール ポリシー] を選択し、(ファイアウォール ポリシー名)から、該当のルール(優先度)のアクション を「許可 → 拒否」へ変更する。

gcloud CLI の場合:


gcloud compute network-firewall-policies rules update (該当のルール(優先度)) \
--firewall-policy (ファイアウォール ポリシー名) \
--firewall-policy-region=asia-northeast1 \
--action deny

3-3:再度、USリージョンより、東京リージョンのサイトへアクセスします。

「USリージョン」から Web サーバへアクセスができなくなりました。

3-4:検証結果
脅威インテリジェンス データにてアクセスフィルタを指定した場合も、アクセス制御が機能していることが確認できました。

検証結果とユースケース

検証の結果、全機能とも想定通りの結果となりました。
また、事前登録された項目やドメイン名を指定するだけで、簡単、かつ柔軟にフィルタリングを適用できることが確認できました。

上記の結果から、ユースケースとして下記が想定されます。

機能 概要
FQDN オブジェクト ・グローバル IP アドレスが頻繁に変わるサイトに対する通信制御
・通信制御に対する可読性の向上
位置情報のフィルタリング ・ 特定地域からのみアクセスを許可
・ 特定地域からのアクセスログを監査
・ 特定地域からDoS/DDoS 攻撃を受けた際の緊急遮断
Google Cloud Threat Intelligence ・ 悪意のある既知の IP アドレス からの通信制御
→ マネージドサービスのため、常に最新の脅威リストで制御ができる。

同様な通信制御ができるサービスとして「Google Cloud Armor」があります。
送信元の地域や、脅威インテリジェンス データのカテゴリに基づいてフィルタリングが利用できますが、「Google Cloud Armor」はロードバランサ配下に対する制御となるため、システム構成に応じて「Cloud NGFW Standard」との使い分けが可能ではないでしょうか。

まとめ

今回は「Cloud NGFW Standard」で提供されている3つの機能について検証を行いました。
人間が認識しずらい IP アドレスではなく、FQDN や定義済みのリストでアクセス制御ができるため、可読性が向上することで運用上のミス発生も抑制できるのではないかと思います。

・ Google Cloud コンソール からGUI操作で簡単にフィルタリングができる。
・ ファイアウォール ポリシーを適用する対象を制御することで対象ごとに柔軟なルール設定が可能
・ 他のファイアウォール系のサービスと上手く組み合わせて、シンプルで安全な環境へ。
内部のアクセス制御は「VPC ファイアウォール ルール」
Webサーバは「Cloud Armor」で防御
外部向けのアクセス制御は「Cloud NGFW Standard」 等

最後まで読んでいただき、ありがとうございました!

当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします!

2024年8月29日 【Google Cloud】Cloud NGFW Standard を試してみた

Category Google Cloud

ご意見・ご相談・料金のお見積もりなど、
お気軽にお問い合わせください。

お問い合わせはこちら