freee株式会社

AWSで提供している各種サービスにAWS WAFおよびWafCharmを導入しました。これらのサービスは主に中小企業・個人事業主様向けで、スモールビジネスではなかなか手が回らないバックオフィス業務の負担を軽減するため、クラウドで提供させていただいております。おかげさまで、2018年4月には導入していただいている事業所様が100万を突破しました。

当社は中小企業・個人事業主様の大事な会社情報、人事労務情報を管理しています。もっとも機密性が高い重要な情報だけに、万が一にでも漏えいは許されません。そこで当社では、お客様が事業に注力し円滑に事業継続できるように、セキュリティ対策の専門部門であるPSIRT（Product Security Incident Response Team）を設置。PSIRTは中小企業・個人事業主様の大切な情報を守るため、セキュリティ対策の企画立案・運用・監視などの事前対応から、何らかの問題が発生した場合に速やかに対処する事後対応にも携わっています。

まず、WafCharmの前提となるAWS WAFを前方に置き、後方には統合型サーバーセキュリティソリューションを置く2段構えをベースに、OS、IPアドレス、ブラウザーの種類のほか、アクセスログなどの行動パターン情報をもとに、ログイン後に不審な動きをしていないか監視するリスクベース認証（Risk Based Authentication）も稼働させています。これらにより、我々としては多層防御と言えるセキュリティ対策ができていると自負しています。

さらに我々はAWS WAFのアクセスログを含め、ネットワークおよびセキュリティのログのアクティビティを収集し、時系列で見ることができる自作のSIEM（Security Information and Event Management）を活用。これにより、不審・不正なアクセスはもちろん、どこでブロックされているかまで把握することができます。サイバーキルチェーンを推進していくためにも、SIEMによる分析が我々の大きなミッションとなります。

こうしたセキュリティ対策により、大半は何があってもカバーはできると考えていましたが、できればWAFの段階で止めるのが理想です。ただし、そのためには通過させるものとブロックするものを精査しながら、日々シグネチャをつくり込む必要があります。

しかし、事業が成長して急速にトラフィックが増えている状況において、我々の少ないリソースでは限界があります。実際、ルールの管理やログの精査もままならない状況でした。WAFとして稼働はしていますが、「昨日よりも今日が良くなっている」とは言えないのは、PSIRTとしてセキュリティ向上の観点から問題があると言わざるを得ません。そこで着目したのがWafCharmでした。

アプライアンス製品も検討しました。ただ、一度プロキシを通し、アプライアンス製品のフィルターをかけてからロードバランサーとなるとレイテンシが下がる懸念がありました。今まで50msぐらいで返していたものが250msぐらい広がってしまうのは避けたいと考えました。

それに加えて、アプライアンス製品をAWS上で冗長構成にすると、非常に管理コストがかかります。セキュリティ対策は重要ですが、コストと性能のバランスは考慮しなければなりません。当社の方針でもある「SaaSでできるものはSaaSで」「マネージドでできるものはマネージドで」に準じ、AWS WAFに落ち着きました。

AWS WAFの運用を容易にする方法として、マネージドルールを利用する手段もありました。しかし、マネージドルールの場合は中身がブラックボックスのため、どこで引っ掛かったのか詳細が分かりません。

我々はPSIRTと名乗っている以上、シグネチャの中身には責任を持ちたいと考えています。例えば、誤検知があった場合「このシグネチャのこの文字列が引っかかったのが原因で、今回はこのように調整しました」というような説明責任です。この観点を踏まえるとWafCharmは正規表現のシグネチャの中身が参照できるため、しっかり解析すれば原因まで突き止めることが可能です。そのような経緯もあり、2018年にWafCharmを導入しました。

確かに導入後の約1年弱は、カウントするだけの検知モードでWafCharmを稼働させていました。その理由はブラックリストの精査です。全ブロックの約7割はブラックリストで止めているという状況があるほど、我々は検知数を上げるためにブラックリストを頼りにしていますが、同時に誤検知も少なくありません。お客様のIPアドレスであるにも関わらず、ブロックしてしまうこともあったため、まずはブロックしない検知モードで稼働させ、不要なIPアドレスの検知はブラックリストから除外するという作業をしていました。これにより、現在の誤検知は月に数回程度。各段に精度が高まった状態でWafCharmを活用しています。

印象的なのは、ブラックリストに出入りするIPアドレス。コンシューマが使用するような回線ですと、不正なアクセスをした場合でもブラックリストに入る時間はわずかです。大抵、1時間後には復帰しているので、我々はそういったIPアドレスがWafCharmで止まるか、後方の統合型サーバーセキュリティソリューションで止まるかをモニタリングしています。もちろん、ほとんどはWafCharmが止めてくれます。

ただ、こうしたアクセスは悪意があるものではないことが多く、動きも複雑ではありません。ちなみに、こうしたアクセスがお客様の場合は「ご利用とは異なるアクセスがあるようですが、Windowsのアップデートなどはされていますか？」と伺います。

稀ですが、F5の連打でリロードを繰り返すアクセスもあります。レートリミットに引っかかるので厄介ではありますが、これも攻撃の意図はないことがほとんどですから問題視はしていません。

何といってもお任せで自動運用できるところです。我々のリソースが増えているわけではありませんから、自分たちで最近のセキュリティ対策のトレンドをかき集めてシグネチャに反映させる作業が不要なのは本当に助かっています。実際、シグネチャの部分はPHPをすべてブロックする程度のカスタマイズのみ。ほかはお任せで運用しています。我々は基本的に誤検知のみに集中している状況です。

また、我々PSIRTは週に1回集まって、AWS WAFのアクセスログを含むSIEMのログ情報をもとに検証を行っていますが、その際、分かりやすい余計なアクセスはWafCharmが止めくれていますから、考察するスタートラインがきれいに舗装されている気がします。これにより、例えば、我々のアプリケーションのミスにもいち早く気付くことができます。

現在、お客様に利用いただいているサービスの大半はAWSで、AWS WAF＋WafCharmのカバー率は9割を超えています。トラフィックでいうと95％以上に達します。しかも、WafCharmのブロックは、後方の統合型サーバーセキュリティソリューションの10倍以上。90％以上の攻撃は前方に位置するWafCharmが止めています。こういう状況ですから当社にとってWafCharmは、なくてはならないセキュリティ対策ツールのひとつと言っても過言ではありません。

AWS WAF v1からv2へ移行する際、当社のシグネチャの移行をサイバーセキュリティクラウドにお願いしましたが、v2用に更新されたシグネチャを参照したとき、当社では同じように記述することはできないと思いました。そもそもv1とv2とではルールの構造が変わっており、ポイント制の課金体系も間違えないように記述しなければなりません。当社用のカスタマイズもしていました。それをv2に合わせてルールの修正作業を3日程度で行ったわけですから、本当にプロフェッショナルだと感じました。

これから先、v3への移行もあるかもしれませんが、更新の不安がないWafCharmがあれば問題ではありません。セキュリティ対策に終わりはありませんから、ツールも長く継続して利用できるものが安心と考えた場合、WafCharmの導入がおすすめだと考えます。

Web APIのセキュリティ対策を考えています。我々がWeb APIにアクセスするクライアントアプリケーションを使ってリクエストする分には問題ありません。問題は悪意を持つ第三者がクライアントアプリケーションを使ってアクセスし、正常に認証を通過してしまったあとです。悪意がある場合、IDや数字を変えたリクエストを何度も送信して、どうにかして他人の情報を搾取しようとします。こうしたアクセスは、IDや数字を入れ替えただけですが、リクエストとしては正しいため、WAFのようなシグネチャベースのセキュリティ対策では検知が容易ではありません。

Web APIのセキュリティ対策におけるアプローチは3段階あります。1段階目はAPIのカタログ化、2段階目はファジングです。カタログ化したAPIに対し、数字や文字列の長さを変えるなどしてランダムにテストを行って機械的にセキュリティホールを探すのがファジングとなります。3段階目はセッションとしてつなげて見たときに、通常の正しいアクセスをしているふりをしながら隣の人の情報を覗き見する挙動を検知するステートフルな仕組みです。

実際、クライアントアプリケーションを通じてWeb APIにアクセスしてくるリクエストは少なからずありますので、早急な対策が必要だと考えています。市場にないのなら、内製で開発することも思案中です。