AWS WAFを完全に理解する ~WAFの基礎からv2の変更点まで~

AWS WAFを完全に理解したい人向けにまとめました。WAFとは、というところからまとめています。メインはv2となったことで変わったことについて書いています。目指せAWS WAFチョットデキル。

#セキュリティ

#AWS WAF

#AWS

臼田佳祐

2020.03.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さん、WAFWAFしてますか？(挨拶

今回はタイトル通りAWS WAFを完全に理解するための情報を全部詰め込んだブログです。長いです。

そもそもWAFってなんだっけ？という話から初めて「全部理解した」と言えるようになるまでをまとめています。直近AWS WAF v2がリリースされたため、この変更点を中心に機能の説明をします。

Developers.IOではWAFを扱った記事がたくさんあるので、細かいところはブログを引用します。いわゆる元気玉ブログです。

おさらい的な部分も多いので変更点が気になる方は適当に飛ばしてください。

そもそもWAFとは

AWS WAFの前にWAFの話をします。WAFはWeb Application Firewallの略でWebアプリケーションを保護するためのソリューションです。

一般的なWebアプリケーションに対する攻撃手法としてSQLインジェクションやXSS(クロスサイトスクリプティング)などがありますが、これらの脅威から保護します。(もっといろんな攻撃から保護することが多いですがここでは省略)

ソフトウェア、ハードウェア、サービスとして利用する形態などがあります。

ファイアウォールとありますが、純粋なファイアウォールと重複した役割(L3/L4の保護機能)を持っているわけではなくL7に対してのみ動作します。IDS/IPSとも役割が異なります。そのため、どれかが利用されていれば他のソリューションが必要ない、ということは全く無いです。そもそもファイアウォールやIDS/IPS、WAFがあるからセキュリティ上安全になるわけではなく、一部分を保護できるだけのため、根本的に保護対象のサーバやアプリケーションの脆弱性を管理することや、適切に運用することが必要ですので入れればOK、というものでもないことには注意が必要です。

WAFのわかりやすい概要はこの記事がいいです。なぜWebサイトのセキュリティ対策にWAFが必要なのか？理由を徹底解説 | セキュリティ対策 | CyberSecurityTIMES(上記図引用元)

正しくWAFを理解するには下記ドキュメントを参照してください。

Web Application Firewall 読本：IPA 独立行政法人情報処理推進機構

AWS WAFとは

AWS WAFは文字通り、AWSが提供するWAFです。

利用形態

WAFの種類はいくつかありますが、AWS WAFは下記にインテグレートしてサービスとして利用します。

CloudFront
ALB
API Gateway

AWS WAF以外のWAF

AWS上で利用できるWAFとしては元々、下記のようなベンダーのマーケットプレイスから購入してEC2上で動作させるものもあります。

F5
Imperva
Barracuda
等々

AWS WAFのメリット/デメリット

サービスとして利用できるAWS WAFとその他のWAFでは下記のような違いがあります。

いいこと
- 簡単なデプロイとインテグレート
- 圧倒的なスケーラビリティ
- 基盤が管理されているマネージドサービス
- 従量課金でコスパがいい
- 簡単なログ出力とAWSサービス連携によるログ調査環境
- セキュリティベンダーのマネージドルール
できないこと
- きめ細やかなルールのチューニング
- すべてのパケットログ取得
- 戻りパケットのチェックやフィルター

EC2上に構築するWAFは特性上、直接ネットワークに挟むとボトルネックになることがありますが、AWS WAFでは上記サービスにインテグレートされてスケールするため柔軟性に優れています。基盤もAWSが管理しているため、死活監視やサーバ自体のメンテナンス、ファームウェアの管理等が不要で非常に簡単に利用できます。

一方で細かいことはできません。高度なセキュリティ要件がある場合にはセキュリティベンダーの提供するWAFも利用する必要があるでしょう。このあたりは要件によって使い分けることになります。併用する選択肢もあります。

AWS WAFについてよく理解するには下記が参考になります。v1のWAFについての内容ですが概ね同じであるため問題ありません。

マネージドルールというセキュリティベンダーが提供しているルールを簡単に利用できることもメリットです。これらのルールは、従来セキュリティの知識がないと難しいAWS WAFのルールの運用をセキュリティベンダーが代わりにやってくれる大変便利な機能です。

AWS WAFの用語

WebACL
- 1つのWAFの設定の塊
- CloudFront / ALB / API Gatewayに割り当てる単位
- 1つのリソースに対して1つのWebACLのみ割り当て可能
- 複数のリソースに対して同じWebACLを割り当て可能
- 複数のルール/ルールグループを内包する
ルール
- リクエストに対する条件のまとまり
- 例えば指定したIPにマッチするか、特定のクエリストリングがあるか等
ルールグループ
- ルールをまとめたもの
- 事前に定義可能
アクション
- リクエストをルールに照らし合わせた結果をどう扱うかの設定
- ALLOW / BLOCK / COUNTがある
- ルール毎にアクションがあり、すべてのルールに当たらなければWebACLに設定されたDefault Actionに沿って処理される

AWS WAFの位置づけとAWSセキュリティ

WAFを導入するからにはセキュリティの強化が目的だと思います。その前提となるAWSセキュリティもサラッとおさらいしましょう。

AWSのセキュリティを考える上での大前提は責任共有モデル(下図引用元)です。

Shared_Responsibility_Model_V2_JP

簡単に言うとにAWSが管理する部分はAWSが責任を持って、その上のOS/アプリやAWS上の設定等はお客様が責任を持つというものです。わかりやすく明確な分解点です。サービスによってAWSがどこまで面倒を見ているかは異なります。

AWS WAFはお客様が作るアプリケーションの前に置くことによって効果を発揮しますが、当然アプリケーションの動作するEC2のセキュリティを考えたときには、Security Groupによるアクセス制御やOS/ミドル/アプリケーションの脆弱性診断/管理(パッチマネジメント)なども行う必要があります。

AWS WAFを導入するだけですべてが守れるわけではないことはもちろん、それぞれのコンポーネント・レイヤーによって利用すべきサービス、注意する設定などは変わりますので意識しましょう。

全体としてどう考えていくかは下記ブログがわかりやすいと思います。

AWS WAFを利用する前にはもちろん、CloudTrail / AWS Config / GuardDutyなどの基本的なサービスが有効化されていることも確認しましょう。AWSセキュリティベストプラクティスについて理解するには下記が参考になります。

AWS WAF v2の変更点

さて、本題です。2019年末頃に新機能AWSマネージドルールと共にAWS WAFが新しいバージョン(v2)になりました。

AWS WAF向けのAWSマネージドルールの発表| AWSニュースブログ

ここまでv2と書いていますが、現状ではAWS WAFと記述するだけで新しいAWS WAFであると表現され、書き分ける場合には New AWS WAFなどと書かれます。古い方を AWS WAF Classicと書くことが多いです。この記事ではわかりやすいように新しい方をv2と書いてます。

なぜv2と呼んでいるかですが、APIがv2となっているためです。

大きく下記のような変更点があります。

v1とは別リソース/別API/別コンソール
キャパシティユニット導入
AWS マネージドルール対応
ルールの記述方法の変更

それでは変更点を見ていきましょう。

別リソース/別API/別コンソール

先程APIがv2となったと書きましたが、古いAPIはそのまま生きています。というわけでv1とv2は共存しています。

コンソール画面を見ていきます。

新しいAWS WAFのコンソールですが、左側のメニューにSwitch to AWS WAF Classicと書かれています。これを押すと古いコンソールに変わります。

ちなみにURLもhttps://console.aws.amazon.com/wafv2となっています。

既存でWAFのリソースがある場合には切り替えて見るとわかりますが、v2になるとあるはずのリソースが表示されなくなります。これは、v1とv2でリソースが異なるためです。

v1のリソースは引き続きv1のコンソール、v1のAPIで管理し、v2とは別物の扱いになります。

ちなみに現状、v1からv2への移行方法は「手動でがんばってね☆ミ」という感じで公式ドキュメントに書かれていました。移行するメリットはなくもないですが、現状ではそこまで頑張らなくてもいいと思います。

キャパシティユニット導入

これまでv1では、ルールが10個までしか登録できませんでした。

ルールとは、WAFの動作する様々な条件の定義で、例えば下記のような条件で1つのルールとなりました。

指定したIPからのアクセスを拒否する
XSSとなるような文字列を拒否する
特定のIPのみ/adminパスへのアクセスを許可する
過剰なリクエストがあるIPを拒否する

条件を付け足していくとどうしても10個のルールではできることに限界がありました。

v2では10個という制約の代わりに、ルールの数ではなく重みを評価するようになりました。それがキャパシティユニットです。

ルールの内容によってルール毎にキャパシティが算出され、1つのWebACLに1500Web ACL Capacity Unit (WCU)までルールを組み込むことが可能になりました。下図のように1ずつ重み付けされます。

設定した内容でどの程度のキャパシティとなるかはドキュメントにありますが、殆どの場合1500WCUまで使用することは無いでしょう。

AWS マネージドルール

v1の時は各サードパーティのセキュリティベンダーがマネージドルールを提供していましたが、AWSからも純正のマネージドルールがリリースされました。

複数のマネージドルールがあります。

Baseline Rule Groups: 一般的な脅威からの一般的な保護
- Core Rule Set (CRS): 一般的なルール。OWASPやCVEに記載されているもの等が含まれている。
- Admin Protection: 公開されている管理ページの保護。
- Known Bad Inputs: 脆弱性を発見/悪用するリクエストの検知。
Use-Case Specific Rule Groups: 用途別の保護
- SQL Database: SQLインジェクション等のSQLデータベースに対する攻撃からの保護
- LINUX operating system: LFIなどLinuxOSへの攻撃の保護。POSIXOSルールと合わせて利用。
- POSIX Operating System: Linux、FreeBSD等POSIX OSの保護。
- Windows Operating System: Windows OSの保護。
- PHP Application: PHPアプリの保護。
- WordPress Application: WordPress固有の脆弱性に対する攻撃の保護。
IP Reputation Rule Groups: IP評価ルール。
- Amazon IP Reputation: AWSの持つ悪意あるボット等のIPアドレスからの保護。