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

ルールの効果を高める Cloud Armor 機能のご紹介: 高度なルール調整と自動デプロイ

2022年12月5日

Google Cloud Japan Team

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

10 月に開催された Google Cloud Next において、Google は Cloud Armor の高度なルール調整のプレビューリリースを発表しました。この機能は、事前構成されたウェブアプリケーションファイアウォール（WAF）ルールの適用方法をお客様側できめ細かく制御できるようにするものです。また、機械学習ベースの攻撃検出および対応機能である Cloud Armor Adaptive Protection で生成される緩和ルールの自動デプロイオプション（プレビュー版）も発表しました。

事前構成された WAF ルールの高度な調整

高度なルール調整機能により、次のことができるようになりました。

事前構成された WAF ルールを感度レベルで調整する
シグネチャのオプトインまたはオプトアウトモードを使用して、事前構成された WAF ルールをデプロイする
リクエストフィールドを WAF ルールの検査対象から除外する

高度なルール調整によって、ルールの効果を高め、基になるシグネチャと一致するトラフィックを受信しうる保護対象アプリケーションからのノイズを削減できます。詳細ログを有効にして、あるデプロイから除外するシグネチャとフィールドを迅速に特定できるようにすることをおすすめします。

感度レベルによる構成

保護対象リソースへの通常のトラフィックにおいて、リクエストが安全で正しい形式であるにもかかわらず事前構成された WAF ルールがトリガーされることがあり、その結果、偽陽性が発生します。これは頻繁に起きる現象ではありませんが、発生すると煩わしいものです。Cloud Armor の最新リリースでは、ルール調整の構成オプションとプロセスが拡張され、そのような場合の対処方法が大幅に簡素化されました。感度レベルを指定できるようになり、この感度レベルによって、事前構成された WAF ルール内でどのシグネチャグループを使用して受信リクエストを検査するかが決定されるようになったため、特定のシグネチャを個別にリストする必要性が減りました。

OWASP ModSecurity Core Rule Set（CRS）は、特定の脅威シグネチャの値をパラノイアレベル（1～4）という論理グループにグループ化します。パラノイアレベルは、Cloud Armor によってルール言語の感度レベルフィールドとして実装されます。Google がレベル 0 を追加したため、感度レベルは 5 種類あります。

感度レベル 0: ルールの適用なし - シグネチャのオプトインモード
感度レベル 1～4: 状況に合わせたシグネチャ感度。レベル 1 は忠実度が最も高いシグネチャ（偽陽性が生じる可能性が最も低い）に相当し、レベル 4 は感度が最も高いシグネチャ（偽陰性が生じる可能性が最も低い）に相当します。

Cloud Armor のドキュメントでは、シグネチャと感度レベルの関連付けについて詳細に説明しています。

一般に、感度レベルが高いほど、不正なリクエストの通過を許可するリスク（偽陰性）が低くなります。ただし、感度が高いと、ルールをさらに調整しなければ、ノイズとなるアラートが発生しやすくなります。防御戦略に応じて、特に機密性の高いアプリケーションではレベル 4 などの制限が厳しい体制で始め、保護対象アプリケーションで確認されたノイズに基づいてルールを緩和するとよいでしょう。ただし、ほとんどのお客様は、レベル 1 などの制限が緩いデプロイから始めて、必要に応じてレベルを上げる傾向にあります。

感度レベル 1 の例:

読み込んでいます...

シグネチャのオプトアウトモードとオプトインモード

ルールをさらに調整するために、ルールセット内の特定シグネチャのオプトインとオプトアウトが可能になりました。

オプトアウト: 現在のルールの呼び出しで使用しないシグネチャを無効化できます。
オプトイン: オプトアウトの逆の機能で、Cloud Armor に評価させるシグネチャのみを選択します。

オプトアウトの例:

読み込んでいます...

このルールでは、PHP の CRS ルールに感度レベル 3 が適用されますが、通常はレベル 3 グループに含まれるシグネチャである owasp-crs-v030301-id933111-php が除外されます。

「opt_in_rule_ids」オペレーションを適用するには、感度レベルを明示的に 0（ルール適用なし）に設定する必要があります。

オプトインの例:

読み込んでいます...

上記のオプトインの例では、現在 4 つのシグネチャを含む標準の Cloud Armor の「cve-canary」ルールセットを適用せずに、指定した 2 つの共通脆弱性識別子（CVE）のシグネチャのみを Cloud Armor に処理させます。

オプトインのアプローチは、2 つのケースで役立ちます。1 つ目は、ほとんどのシグネチャルールが処理されないことが予想される場合。除外する多数のシグネチャセットをリストするのではなく、評価する少数のシグネチャのみをリストします。2 つ目は、新しくリリースされたシグネチャを常に検証してからデプロイする場合。このようなケースは、新しい重大なゼロデイ脆弱性によって新たなシグネチャが増えるなど、既存のルールに新しいシグネチャが追加された場合などに当てはまります（Log4j への対応で追加された例）。オプトイン ID を使用すると、新しいシグネチャは自動的に評価されません。まず特定の環境でそのシグネチャをテストして検証し、準備ができたらデプロイできます。

Common Expression Language（CEL）と事前構成された WAF ルールを組み合わせることで、特定の URL に特殊な処理が求められる場合にサポートする必要があるオプトイン / オプトアウトのユースケースをカスタマイズできます。また、事前構成された WAF シグネチャの検査を別の場所で維持できます。

CEL ルールとオプトアウトルールの組み合わせ:

読み込んでいます...

この CEL ルールの例では、リモートコード実行 CRS ルールが感度レベル 3 で評価されますが、指定した正規表現の一致に基づきログイン URL に到達しようとするリクエストの場合のみ、1 つのシグネチャ値が除外されます。

必要に応じてリクエストフィールドを検査から除外する

事前構成された WAF ルールにおいて、シグネチャをトリガーする可能性のある値（特殊文字など）が受信リクエストに含まれていることが想定される場合があります。こういった状況においても、脆弱性がないか Cloud Armor でリクエストを評価する必要があります。そのような場合のために、Cloud Armor ポリシー内で事前構成 WAF ルールにフィールドレベルの除外を構成できるようになりました。

フィールド名の文字列パターンの一致に基づいて、特定のフィールド（リクエストヘッダー、Cookie、クエリパラメータ、URL パス）を評価から除外するように Cloud Armor ルールを構成できるようになりました。

次のいずれかの演算子を使用して、フィールド名で照合する文字列シーケンスを明確に示すことができます。

EQUALS
STARTS_WITH
ENDS_WITH
CONTAINS
EQUALS_ANY

特定の WAF ルールと不適切なシグネチャを識別したら、gcloud コマンドを使用して、不要なフィールドを評価から除外し残りのリクエストに対してルールを処理するように Cloud Armor に指示できます。

フィールド除外の例:

読み込んでいます...

上記の例では、「owasp-crs-v030301-id941140-xss」と「owasp-crs-v030301-id941270-xss」という 2 つのシグネチャに対する検査において、Cloud Armor が「abc」で始まるヘッダーを省略して受信リクエストを評価するように除外が構成されています。「xss-v33-stable」ルールセット内にある他のすべてのシグネチャは、優先度 = 1400 でルールに含まれている場合、引き続き評価に含まれます。

Adaptive Protection が提示するルールを自動でデプロイする

Cloud Armor の Adaptive Protection（動画）は、しかけられた攻撃を自動的に検出し、攻撃のトラフィックを分析して、ほぼリアルタイムで緩和策を提示できます。Cloud Armor は、この機能を使用して記録されている最大規模の DDoS 攻撃のひとつを軽減しました。Adaptive Protection は Google の機械学習機能を活用することで、保護されたアプリケーションのトラフィックフローを分析して、良好なトラフィックのベースラインを確立し、ベースラインから逸脱する潜在的な攻撃を検出できます。アラートには動的に計算された攻撃のシグネチャが含まれ、Adaptive Protection はそれを軽減するための WAF ルールを提示します。

Adaptive Protection を信頼し活用を始めたお客様からよくあるご要望に、人手を介さずに緩和ルールを生成したいというものがあります。これまで 1 年半の間、こうした要望をいただいてきました。Adaptive Protection の新しい自動デプロイ機能（プレビュー版）を使用することで、お客様は Cloud Armor により、Adaptive Protection で生成されたルールを次の基準に基づいて自動的にデプロイできるようになりました。

負荷しきい値: 攻撃されたアプリケーションやバックエンドサービスの負荷の急増
信頼度しきい値: 攻撃の可能性を示す信頼スコア
影響を受けるベースラインのしきい値: ルールの影響を受ける可能性のあるベースライントラフィックの割合
有効期限: ルールを適用する期間

以前は、アラートと提示ルールを手動で確認してからルールをデプロイする必要がありました。お客様が Adaptive Protection の精度に納得し、このデプロイ手順を自動化するように依頼されるまで、さほど時間はかかりませんでした。新しい自動デプロイ機能により、Cloud Armor のお客様は、構成した基準のしきい値が満たされると、ブロックやレート制限といった目的のアクションを含むルールを自動的にデプロイできます。