セキュリティ & アイデンティティ

オンプレミスとクラウドのワークロードに対応した Cloud Armor の新しい WAF 機能

2020年5月15日

Google Cloud Japan Team

※この投稿は米国時間 2020 年 5 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションがどこにデプロイされていようと、管理者にとってはセキュリティをインフラストラクチャ全体で迅速かつ簡単にスケーリングできることが重要です。Google の Cloud Armor は、Google ネットワークのエッジで、各所のウェブアプリやサービスに Google 規模のセキュリティを確保する、ウェブアプリケーションファイアウォール（WAF）と DDoS 軽減サービスを提供します。

昨年 11 月、Google は新しい WAF 機能をベータ版としてリリースし、Security Command Center でのテレメトリーを強化しました。それ以降、アプリケーションの保護と可用性の維持を求めて Google Cloud ネイティブのサービスのデプロイを検討されるお客様に、急速に採用されています。これを受けて Google では最近、次のような機能を備えた WAF をすべてのお客様に一般提供することを決めました。

位置情報に基づくアクセス制御
SQL インジェクション（SQLi）とクロスサイトスクリプティング（XSS）の防御のために事前構成された WAF ルール
カスタム L7 のフィルタリングポリシー用カスタムルール言語
Security Command Center との統合

ATB Financial の技術戦略およびアーキテクチャ部門の責任者である Innes Holman 氏は次のように述べています。「ATB Financial にとってセキュリティは最優先事項です。Google Cloud Armor の導入によって、ワークロードをクラウドに安全にデプロイできるようになりました。アプリケーションを全体で保護でき、ATB のセキュリティおよびコンプライアンス要件の遵守にも役立っています。」

Cloud Armor for Cloud CDN: オリジンサーバーの保護

ウェブアプリケーションやウェブサイトは多くの場合、静的コンテンツと動的コンテンツの両方を提供します。Cloud CDN を有効にすると、静的コンテンツの提供は最適化できますが、動的コンテンツへのクライアントリクエストは、さらにアプリケーションサーバーに接続し、処理、応答を経る必要があります。CDN は通常、攻撃を受けてもスケーリングしてキャッシュに保存されたコンテンツを提供できますが、オリジンサーバーは、限られたリソースが不適切なリクエストによって過負荷に陥るのを避けるために、上流に WAF が必要になります。また、一般的に企業は、セキュリティとコンプライアンス上の要件から、リスクを軽減し、アプリケーションサーバーの可用性を確保するために WAF ルールと L7 フィルタリングポリシーの適用を必要としています。

こうしたニーズを満たすため、Cloud CDN が有効化されたバックエンドサービスの保護に、Cloud Armor のセキュリティポリシーを設定できるようになりました。CDN が有効化されたバックエンドサービスにセキュリティポリシーを適用すると、Cloud Armor は、オリジンサーバー宛てのリクエスト（キャッシュミスやキャッシュを経由しない動的リクエストなど）のすべてにそのポリシーを適用します。

使用を開始するには、Google Cloud Load Balancing（GCLB）の構成で、バックエンドサービスの Cloud CDN を有効にしてから、[高度な構成] を展開し、Cloud Armor セキュリティポリシーを適用します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_cloud_armor_security.max-700x700.jpg

ハイブリッド環境やマルチクラウドデプロイ向けの Cloud Armor

Cloud CDN と Cloud ロードバランサに続き、Cloud Armor も、Google Cloud にデプロイされていないフロントアプリケーションに使用できるようになりました。エンタープライズのワークロードは複雑になってきており、オンプレミスとクラウドの併用や、複数のインフラストラクチャプロバイダにまたがる運用といったケースが多くなっています。こうしたハイブリッドアーキテクチャは、企業の恒久的な環境か、あるいは移行のための一時的な措置かもしれません。いずれにしてもセキュリティチームは、アプリケーションがデプロイされる場所を問わず、一貫したセキュリティ管理を行う必要があります。オンプレミスにデプロイされたインターネット接続のアプリケーションも、インターネット経由の攻撃から保護しなくてはなりません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_cloud_armor_create_backend_service.max-800x800.jpg

ユーザーは、Cloud Armor を含む Google のエッジインフラストラクチャを全面的に活用し、一般のインターネット経由でアクセスできる限り、あらゆる場所にデプロイされているワークロードを保護できるようになりました。使用を開始するにはまず、GCLB のバックエンドサービスを設定して、インターネットネットワークエンドポイントグループ（NEG）を指定します。次に、そのバックエンドサービスに Cloud Armor のセキュリティポリシーを適用して 1 つ以上のルールを構成し、保護されたアプリケーションを狙ったレイヤ 7 のトラフィックをフィルタリングします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_cloud_armor_ddos.max-1100x1100.jpg

次のステップ

新たな Google Cloud Armor のリリースによって、Google Cloud のお客様にエンタープライズクラスの WAF と DDoS 軽減サービスをネイティブにご提供できるようになりました。Google の万全なエッジネットワークによって DDoS からアプリケーションを保護し、アプリケーションを狙った攻撃によるリスクを軽減できます。ハイブリッド環境や CDN が有効化されたワークロードに対応できる GCP のエッジサービス（Cloud Armor、Cloud CDN、Cloud Load Balancing など）は、Google Cloud 上、オンプレミス、または他のクラウドプロバイダなど、どこであってもアプリケーションやウェブサイトを保護し、エッジの均一性を保ち、一貫したポリシーとアクセス制御を維持できます。

詳しくは、次のリソースをご確認ください。

-By プロダクトマネージャー Emil Kiner

投稿先