GCPにおけるDDoS防御と緩和のベストプラクティスについて

Best Practices for DDoS Protection and Mitigation on Google Cloud PlatformをDeepL翻訳して、GCPのDDoS対策について追記しつつまとめました。違和感のある翻訳部位については、個人的な主観で表現を変えています。読んでいる限りでは、GCPの超基本的なセキュリティ設定に通じていると感じます。

最初に、ネットワーク用語について補足しておきます。

GCPのPoP （Point Of Presence）は、各リージョンのデータセンターの入口を指す。GFE（Google Front End）は、PoPの中で外部インターネットから着信する HTTP(S)、TCP、TLS プロキシのトラフィックをロードバランサで終端し、DDoS 攻撃対策を提供して、Google Cloud サービス自体へのトラフィックをルーティングおよび負荷分散します。HTTP(S)/TCPプロキシ/SSLプロキシのCloud Load Balancingの場合、Google Front End（GFE）と Google Cloud VPC ネットワーク内バックエンドの間のトラフィックは自動的にTLS暗号化され、GFEのロードバランサでWAF等セキュリティを担うCloudArmorの利用も設定できる。しかし、ファイヤーウォール設定で行う様な外部インターネットからGFE(CloudLoadBalancing)を介さずVPC（FireWall）というIngress（インバウンド通信）経路もあり、その経路はデフォルトでTLS暗号化されない。

脅威を減らすためのGCP設定

■「GCP」→「(企業)組織:Organization」→「部門:Folders」→「プロジェクト」→「(Shared)VPCやGCEなどのGCPリソース」という順でGCPのリソース階層を組織トップで以下の図のように定義する。リソース階層の設定を行うことで、ユーザー権限設定などを適切に出来るようになります。組織は、「Google Workspaceでプライマリドメイン名の購入」 または、GCPのIAMの「IDと組織」の「Cloud Identity」でお名前ドットコムなどの独自ドメインにTXTレコード設定にてドメイン所有権の証明を行います。組織や部門はGoogle Adminにて設定できます。

なお、「admin.google.com(Google Admin) は 無料は14日だけなGoogle Workspace（旧G suite） アカウントでのみ使用できます。通常の Gmail アカウントでは admin.google.com にログインできません。」となっており、Webアプリ向けではなく、GCPのユーザー管理向けの独自ドメインメールアドレスが必要なため、お名前ドットコムなどの独自ドメインのレジストラの料金は、組織管理の場合、ほぼ必須となります。

Google Workspace(旧G Suite)はGドライブやGメールなど、グーグルのWEBサービスです。GCPは、クラウドインフラサービスとなっています。GCPのユーザーはGoogle WorkspaceのGoogleAdminで組織:Organization（株式会社ABC）や組織部門:Folders（クラウド開発部のステージング環境）のように管理するよう設計されています。さらにGoogle AdminのGoogleグループでは、メーリングリスト、会議、ドキュメント向けのユーザーをグルーピングします。Google Workspaceは14日間しか無料がありません。実質的に、GCPユーザーのアクセス権をセキュアに管理するためには、GCP利用人数分のGoogle Workspace課金（月額で1ユーザーにつき680円～2040円）とGoogle Adminで利用する独自ドメインのお金が必須となります。なお、AWSであればIAMやAWS Organizationsで無料で管理できます。組織導入向けのGCP学習を個人で行う場合のコストハードルはやや高め、無料のGCPだけでは出来ない。

■GCP内の実装について、サブネット、ネットワーク、ファイヤーウォール、(ネットワーク)タグ、などを使い、疎結合でセキュアに構成する。

■ファイヤーウォールのルールを使い、必要なポートやプロトコルへのアクセスのみを開放する。また、プロトコルフォワーディングを行う。

■GCPは、Spoofing(なりすまし)対策の防御としてデフォルトでプライベートネットワーク（IPアドレス）を備えています。

■GCPは自動的に仮想ネットワーク間の分離を提供します。

外部インターネットから内部トラフィックを隔離

■不必要なパブリックIPを使用しない様にインスタンスをデプロイする。

■NATゲートウェイやSSH踏み台を設定し、インターネットに公開されるインスタンス数を制限する。

■外部への露出を回避するため、Internal Load Balancing を導入する。

ロードバランサーは、負荷分散の役割もありますが、外部インターネットからのリクエストを受けて、プライベートネットワーク内のGCPリソースにトラフィックを送るというセキュリティ面の役割を強く認識しておく必要があります。

SSH踏み台の代わりにGCPへのログイン自体のセキュリティ設定（多要素認証やユーザー権限設定）をしっかり行い、Cloud Shellを使うことも推奨されます。

プロキシベースLoadBalancingでDDoS保護

■L7のHTTP(S)LoadBalancingまたは、L4のSSLプロキシLoadBalancingを利用して、Synフラッド,IPフラグメントフラッド, ポート枯渇など、多くのL4以下の攻撃を緩和し、吸収出来ます。
つまり、L7はLoadBalancingだけでは対応できないのでCloudArmorやサードパーティが必要です。

■マルチリージョンのインスタンスでHTTP(S)LoadBalancingを使っている場合、世界中のインスタンスに攻撃を分散できます。

スケールアップして攻撃を吸収する

■GoogleFrontEnd（LoadBalancing）による保護の活用。
Google Cloud Global Load Balancing を使用すると、ユーザートラフィック終端としてのフロントエンドインフラストラクチャが自動的にスケーリングされ、特定の攻撃 (SYNフラッドなど) がコンピュートインスタンスに到達する前に吸収されます。

■Anycastベースのロードバランシングの活用。HTTP(S)ロードバランシングとSSLプロキシロードバランシングは、すべてのリージョンで展開されたバックエンドインスタンスのフロントエンドに単一のAnycast IPを有効にします。通常、ユーザーのトラフィックはキャパシティのある最も近いバックエンドに誘導されますが、DDoS攻撃が発生した場合、このアプローチのさらなる利点は、バックエンドが配置されているすべてのリージョンのキャパシティのあるインスタンスにトラフィックを分散させることで、攻撃を吸収するためのリソースを増加させることができます。

■オートスケーリングの活用。HTTP(S)またはSSLプロキシのロードバランシングを設定する場合。
ユーザーのトラフィックを終端させるGoogleFrontEndは、バックエンドを保護します。また、トラフィックの急増に対応するために、十分な数のインスタンスをプロビジョニングしたり、オートスケーリングを設定したりする必要があります。突然トラフィックが急増した場合、ロードバランシングプロキシレイヤーは、キャパシティに余裕があるすべてのバックエンドにトラフィックを分散します。同時に、オートスケーラーはトラフィックに合わせてバックエンドを強化します。

CDNによる保護

■Google Cloud CDN は、クライアントとオリジンサーバー間のプロキシとして機能します。
キャッシュ可能なコンテンツについて、Cloud CDN は、バックエンド サーバー（インスタンス）にコンテンツを送信するのではなく、ユーザーに近いPOP(points of presence:リージョンの入口)からコンテンツをキャッシュし、サービスを提供します。
キャッシュ可能なコンテンツに対するDDoS攻撃が発生した場合、リクエストはオリジンサーバーではなく世界中のPOPに送信されるため、攻撃を吸収できる場所が広がります。

■CDN Interconnect（AkamaiなどのサードパーティCDN）を使用している場合は、CDN Interconnectパートナーが提供する追加のDDoSプロテクションを活用することができます。Google Cloud から CDN プロバイダに送信されるトラフィックには特別料金が自動的に適用されます。パートナーの DDoS 保護機能の詳細については、パートナーのページを参照してください。

サードパーティ製DDoSソリューション導入

■DDoS 攻撃の防止/軽減のための具体的な保護ニーズを満たすため、専用のサードパーティ製 DDoS保護ソリューション購入を検討してください。

■GOOGLE CLOUD MARKETPLACEを通じて利用可能な DDoS ソリューションを導入することもできます。

GAE(Google App Engine)を使う

■App Engine は完全なマルチテナント システムとして設計されており、単一の不正なアプリケーションがプラットフォーム上の他のアプリケーションのパフォーマンスや可用性に影響を与えないようにするための多くのセーフガードを実装しています。

■App Engineは、SYNフラッド、IPフラグメントフラッド、ポート枯渇など、多くのレイヤ4以下の攻撃を緩和し、吸収するGoogleFrontEndの背後にあります。つまり、L7は対応できないのでLoadBalancing+CloudArmorやサードパーティが必要です。

■dos.yamlファイルを介してIP/IPネットワークのセットを指定して、それらがアプリケーションにアクセスできないようにすることもできます。

GCS(Google Cloud Strage)

■Google Cloud Storageリソースにアクセスするため、ユーザーにGoogleアカウントを要求したくない場合、署名付きURLを使用してアクセスを制御することができます。

APIレート制限

■APIレートの制限は、Google Compute Engine APIへのリクエスト数を定義します。
APIレートの制限はプロジェクトごとに適用されます。

■プロジェクトで、API レート制限は 20 リクエスト/秒に制限されています。

リソースクォータ制限

■Compute Engineは、様々な理由でリソース使用量のクォータを強制します。
例えば、クォータは予期せぬ使用量の急増を防ぐことで、Google Cloud Platformユーザーのコミュニティを保護します。
Google Cloud Platformの無料試用プロジェクトには、アクセスを制限するクォータがあります。