概要

複数のチームが独自の Web アプリケーションまたは API を開発して運用している大規模な組織では、セキュリティ制御が弱い、またはまったく保護されていないエンドポイントが危険にさらされないように、チーム全体でセキュリティ制御の一貫性を保つためのツールとプロセスを採用しています。AWS ファイアウォールマネージャーは、組織が AWS WAF および Shield アドバンスドデプロイメントを大規模に管理するために使用できるツールです。

AWS ファイアウォールマネージャー

ファイアウォールマネージャーを使用すると、CloudFront ディストリビューション、ALB、API ゲートウェイなど、公開されているリソース全体に自動的にデプロイされる AWS WAF または Shield Advanced ポリシーを定義できます。ポリシーは次のもので構成されます。

  • 適用範囲を定義するスコープ:どのような種類のリソース (CloudFront、ALB など)?特定のタグが付いたリソースを含めるか除外するか?どのアカウントまたは組織部門を含めたり除外したりするか?
  • どの WAF ルールグループを適用するかを定義するルール?ロギングを一元的に有効にするかどうか、Shield アドバンスド保護を追加するかどうか。
  • ポリシーの範囲内でリソースが見つかったときに何をするかを定義するアクション。たとえば、ポリシールールを自動的に適用したり、単に報告したりすることができます。Firewall Manager の初期導入では、既存のアプリケーションへの影響を最小限に抑えながら手動で処理する必要があるリソースを特定するために、自動修復なしで開始することをお勧めします。信頼性が向上したら、Firewall Manager を自動修復に切り替えることができます。

ファイアウォールマネージャーを使用するには、まずその前提条件を検討してください。AWS 設定はファイアウォールマネージャーの前提条件の 1 つであることに注意してください。AWS Config のコストを最適化するには、Firewall Manager の使用のみが有効になっている場合は、レコードするリソースタイプの設定をシナリオに関連するリソース (WAF、CloudFront ディストリビューション、ロードバランサーなど) に制限してください。また、ポリシーは地域構造であることにも注意してください (たとえば、CloudFront にはグローバルポリシーが必要で、ALB や API Gateway などの地域リソースがある各地域には地域ポリシーが必要です)。この AWS ソリューションを検討して、AWS 組織全体で Firewall Manager ポリシーを簡単に導入できるようにしてください

AWS WAF の大規模なデプロイ

WAF ポリシーを作成すると、ファイアウォールマネージャーは、ポリシースコープ内の AWS アカウントのポリシー WAF ルールを含む WAF WebACL をデプロイします。WAF ポリシーでは、ファイアウォールマネージャーによってデプロイされた WebACL に追加される 2 種類のルールグループを定義できます。

  • 最初のルールグループ。他のルールよりも先に評価されます。
  • 最後に評価される最後のルールグループ。

これにより、中央のセキュリティチームが組織全体の共通ルールグループを管理できるようになり、アプリケーションチームは最初と最後の共通ルールグループの間にアプリケーションに関連するカスタムルールを追加できるようになります。AWS WAF のルールは順番に評価されるため、最初の共通ルールグループは他のルールよりも先に評価され、その後にアプリケーションチームが作成したルール、最後に最後の共通ルールグループが評価されます。

CI/CD パイプラインを構築して、管理用 AWS アカウントの AWS WAF ポリシー内の一般的な WAF ルールグループを更新できます。このルールは、Firewall Manager によって数分以内に組織全体にデプロイされます。このブログでは、OLX が中央ロギングシステムを備えた CI/CD パイプラインを使用して中央 WAF ポリシーを導入した方法をご覧ください。

一般的な WAF ガバナンスモデル

Firewall Manager は、組織の要件に応じてさまざまなセキュリティガバナンス戦略を確立できる柔軟なツールです。どの一元的なセキュリティガバナンスでも、保護レベルを高めるためにルールを一元的に適用する量と、一元的に展開された共通ルールによって生じる誤検知をどれだけ処理するかをトレードオフする必要があります。

重大な脅威を軽減するための単一ポリシー

高度に自律的なアプリケーションチームがあり、誤検出の管理を避けたい場合は、重大な脅威に対処する単一の中央 WAF ポリシーを作成してください。たとえば、高いしきい値のレート制限に基づいて WAF ルールを作成したり、信頼性の高い悪意のある IP レピュテーションリストや禁輸対象国向けのジオブロッキングルールと組み合わせたりできます。また、Shield アドバンスドを有効にして、自動アプリケーションレイヤー DDoS 緩和を有効にすることもできます。これらのルールは誤検出率が非常に低い傾向がありますが、HTTP フラッドからの保護には効果的です。さらに、重大で影響の大きいゼロデイ脆弱性が明らかになったら、デプロイされた WAF 共通ルールグループを使用して緩和策を一元的に適用できます。

アプリケーションチーム用の内部 Wiki を作成し、アプリケーションに関連するカスタム WAF ルールを WebACL に追加するためのベストプラクティスに関するガイダンスを提供することをお勧めします。たとえば、アプリケーションが SQLi や XSS 攻撃に対して脆弱な場合は、そのような攻撃に対する保護を追加するように指導してください。

1 つのポリシーでさまざまな脅威を軽減

一元的なセキュリティの対象範囲を幅広い脅威に拡大したい場合は、中央の共通ルールグループを強化しつつ、アプリケーションチームが自主的に誤検知を管理できるようにしてください。この WAF ガバナンスモデルを実装するには、カウントモードの WAF ポリシーの最初のルールグループに共通ルールを入れてください。これらのルールはラベルのみを発行します。WAF ポリシーの最後のルールグループで使用すると、これらのラベルに一致するリクエストをブロックできます。

アプリケーションチームが誤検知に遭遇した場合、ルールによって発行されるラベルを使用して除外ルールを作成できます。これを例を挙げて説明するために、SQLi から保護するための Amazon Managed Rules (AMR) がカウントモードで最初のルールグループに追加されるシナリオを考えてみましょう。最後のルールグループでは、前述の AMR によって発行された label_matched= "SQLI_Body" というラベルの付いたリクエストがルールによってブロックされます。AMR が特定の URL (url="/form1") 上のアプリケーションに誤検知を導入した場合、アプリケーションチームはこの誤検知を軽減する除外ルールを WebACL 内に作成できます (例: url="/form1"と label_matched=」SQLI_Body」の場合は許可)。許可ルールアクションは終了します。つまり、AWS WAF は以降のブロックルールの評価を停止します。

既存のアプリケーションに影響を与えずにこのポリシーの変更をロールアウトするには、このポリシーのレプリカを作成し、アプリケーションチームがステージング環境で使用することを検討してください。どちらのポリシーにも、相互に排他的なスコープが必要です。たとえば、プロダクションポリシーは、ステージングタグのあるディストリビューションを除くすべての CloudFront ディストリビューションに適用され、ステージングポリシーは、ステージングタグのあるすべての CloudFront ディストリビューションに適用されます。ほとんどの更新では、最初にステージングポリシーにロールアウトし、SNS トピックを使用してすべてのアプリケーションチームに通知できます。変更が通知されると、アプリケーションチームはステージング環境で新しいポリシーバージョンをテストします。ステージング環境は自動化でき、必要に応じて誤検知を管理します。その後、合意された遅延の後、中央チームはその変更を生産ポリシーに反映します。Log4j CVE に対する保護など、1 週間では対応できない重要な更新は、アプリケーションチームが例外を処理するまで、いくつかの一時的な誤検出を許容できるのであれば、すぐに適用できます。

アカウント管理者によるある程度のカスタマイズを許可しながら、一貫したセキュリティベースラインの適用を強制したい場合。この記事では、一元管理されるセキュリティベースラインポリシーを設計および実装するステップの概要が記載されています。また、ポリシーのテストとデプロイに関するベストプラクティスについても詳しく説明されています。

さまざまなアプリケーションタイプに対応する複数のポリシー

要件は以前と同じだが、アプリケーションセキュリティを強化することによるアプリケーションチームの認知的負担を軽減したい場合は、組織に存在するさまざまなアプリケーションタイプに対応するポリシーのカタログを作成することを検討してください。たとえば、次の 2 つのポリシーを含むカタログを作成できます。

  • 第一の方針：Wordpress ベースのアプリケーションを保護するために推奨
  • 第二の方針: PHP アプリケーションを SQL データベースで保護することを推奨します。このポリシーには、ブロック感度レベルが異なる 2 つのバージョンを作成できます。これにより、アプリケーションチームは、セキュリティ要件 (パラノイアレベル) と誤検知への対応意欲を満たすものを選択できます。

各ポリシーの範囲は特定のタグ (たとえば、最初のポリシーの場合はワードプレス、 2番目のポリシーの場合は LAMP_HIGH/LAMP_LOW) によって定義されます。アプリケーションチームは利用可能なポリシーのカタログを調べ、必要なポリシーのタグをリソースに適用します。ファイアウォールマネージャーは WAF Web ACL をリソースに自動的に関連付けます。

このアプローチでは、前のセクションで説明したのと同じ方法で、誤検知やステージ変更を管理できることに注意してください。

アプリケーションレベルの動作検知

アプリケーションレベルでは、カスタムシグナルを使用して、アプリケーションで予想される動作に基づいて異常な動作を識別できます。たとえば、ユーザーが特定の順序でアプリケーションをナビゲートすることを期待したり、ユーザーが登録住所に基づいて特定の国から特定の商品を注文したりすることを期待しない場合があります。このようなシグナルを使用すると、AWS WAF を使用して応答を自動化できます。たとえば、アプリケーションレベルの動作が疑わしい IP からの CAPTCHA リクエストをブロックしたり、拒否したりできます。アプリケーションシグナルに基づく WAF 自動化の概念を始めるには、この AWS ソリューションの例を検討してください。

高度な自動化には以下が含まれます。

各アプリケーションチームのフルマネージドポリシー

WAF 管理をアプリケーションチームから中央セキュリティチームに完全にオフロードしたい場合は、アプリケーションチームごとに、AWS アカウントのみを適用する範囲で専用のポリシーを作成してください。このシナリオでは、初期設定のプロセスを作成し、誤検出の管理などの操作のためにアプリケーションチームと中央セキュリティチーム間の通信チャネルを作成する必要があります。

リソース

このページはお役に立ちましたか?

 フィードバック