Google Cloud Service Extensions で Fastly の Next-Gen WAF をデプロイして大規模にトラフィックを保護

Alisha Stull 氏

Google Cloud パートナーエンジニア

James Nguyen

プロダクトマネージャー

Victor Carvajal

シニアソフトウェアエンジニア

2026年6月18日

エンジニアリング DevOps セキュリティ

もし Web アプリケーションが攻撃を認識する前にロードバランサーが攻撃を阻止できたら？

Google Cloud Service Extensions を利用して、ロードバランサーのパイプライン内で直接トラフィックをリアルタイムで検査することが可能になりました。さらに、Fastly の Next-Gen WAF と組み合わせることで、パフォーマンスを犠牲にすることなく、エンタープライズグレードのセキュリティを実現できます。

このブログ記事では、この強力な統合の仕組みと、それが先進的なクラウドアーキテクチャにとって重要な理由に加え、すぐに実行できる実際のデプロイ方法について詳しくご紹介します。

実環境での効果：パフォーマンスと保護の両立

現実的なシナリオを使って、実際のメリットを見てみましょう。

セットアップ：複数の地域にまたがって毎秒1万件のリクエストを処理する、Google Kubernetes Engine（GKE）上で稼働するeコマースプラットフォーム。

課題：200ミリ秒未満のレスポンス時間を維持しながら、クレデンシャルスタッフィング攻撃、SQL インジェクション、ボットトラフィックから保護する。

ソリューション：Next-Gen WAF を Service Extension のコールアウトとしてデプロイすることで、以下が可能になります。

ゼロレイテンシのセキュリティ決定をロードバランサーレベルで実行
既存の GKE インフラストラクチャで自動スケーリング
リージョン単位のデプロイにより最適なパフォーマンスを実現
フェイルオープン設定により、エージェントのメンテナンス中も可用性を維持

Fastly の Next-Gen WAF と Google Cloud Service Extensions の連携方法

Google Cloud Service Extensions では、カスタムロジックを挿入する方法として、プラグインとコールアウトの2つが提供されています。

コールアウトを利用することで、Cloud Load Balancing はデータ処理中に Envoy gRPC を使用して、Google Cloud サービスとユーザー管理サービスを呼び出すことができます。

Fastly の Next-Gen WAFは、ユーザー管理のコンピューティング VM、GKE Multi-Cloud の GKE Pod、またはオンプレミス環境で、汎用 gRPC サーバーとして実行できます。

実装の詳細：ゼロから保護へ

この統合では、gRPC を介して Envoy の外部処理プロトコル (ExtProc) を活用することで、WAF が重要な段階でトラフィックを検査して対応できるようになります。

1. REQUEST_HEADERS : 受信したリクエストヘッダーを脅威インテリジェンスと照合して分析

2. REQUEST_BODY : ペイロードデータをストリーミングし、悪意のあるコンテンツの有無を検査

3. RESPONSE_HEADERS: データ漏えいがないか送信レスポンスを監視

このようなきめ細かな検査機能により、アプリケーションのバックエンドに到達する前に脅威を特定してブロックします。

ゼロからデプロイするには、拡張機能をサポートするアプリケーションロードバランサーを作成して設定する必要があります。

Next-Gen WAF エージェントを使用してコールアウトバックエンドサービスをデプロイする場合、すぐに使える Docker イメージを利用できます。以下のターミナルスニペットによって、ロードバランサーのネットワークに Next-Gen WAF エージェントを配置、設定、デプロイするための VM インスタンスを作成できます。

詳しくは Fastly のドキュメントサイトをご覧ください。

gcloud compute instances create callouts-vm \
 --zone=$ZONE \
 --network=lb-network \
 --subnet=backend-subnet \
 --machine-type=e2-medium \
 --image-family=cos-stable \
 --image-project=cos-cloud \
 --tags=allow-ssh,load-balanced-backend \
 --metadata-from-file=startup-script=startup-script-tls.sh

#!/bin/bash

# Create certificate directory
mkdir -p /etc/ssl/certs/sigsci

# Generate self-signed certificates for the gRPC service
openssl req -x509 -newkey rsa:4096 \
 -keyout /etc/ssl/certs/sigsci/key.pem \
 -out /etc/ssl/certs/sigsci/cert.pem \
 -days 365 -nodes \
 -subj "/C=US/ST=CA/L=SF/O=Fastly/CN=ext11.com"

# Set proper permissions for the sigsci user inside the container
chmod 644 /etc/ssl/certs/sigsci/key.pem
chmod 644 /etc/ssl/certs/sigsci/cert.pem

# Start Signal Sciences agent with TLS configuration
docker run -d \
 --name sigsci-agent \
 --restart unless-stopped \
 -p 443:443 \
 -v /etc/ssl/certs/sigsci:/etc/ssl/certs/sigsci:ro \
 -e SIGSCI_ACCESSKEYID=<YOUR ACCESS KEY> \
 -e SIGSCI_SECRETACCESSKEY=<YOUR SECRET KEY> \
 -e SIGSCI_ENVOY_GRPC_ADDRESS=0.0.0.0:443 \
 -e SIGSCI_ENVOY_EXTPROC_ENABLED=true \
 -e SIGSCI_ENVOY_GRPC_CERT=/etc/ssl/certs/sigsci/cert.pem \
 -e SIGSCI_ENVOY_GRPC_KEY=/etc/ssl/certs/sigsci/key.pem \
 -e SIGSCI_DEBUG_LOG_VERBOSITY=3 \
  signalsciences/sigsci-agent:latest

# Log startup completion
echo "Signal Sciences agent with TLS started at $(date)" >> /var/log/startup.log

早速デプロイしてみませんか？

Fastly の Next-Gen WAF と Google Cloud Service Extensions の統合は、クラウドセキュリティを重視する組織にとって、非常に有力な選択肢となります。リアルタイムの脅威対策、クラウドネイティブなデプロイ、エンタープライズクラスのパフォーマンスを提供するこのアーキテクチャは、最も要求の厳しい本番環境にも適しています。

Web アプリケーションセキュリティの未来は、ご利用のクラウドインフラストラクチャと深く統合できるこのソリューションから始まります。今こそ移行のときです。

さらに詳しく知りたい方は、こちらの包括的なセットアップガイドで、詳細な実装手順とトラブルシューティングのヒントをご覧ください。

英語のみで利用可能