大規模な攻撃と脆弱性対策のために　ココナラとBookLiveのWafCharm導入事例

EVENT

Cloud Security Day 2023 先駆者に学ぶ AWSセキュリティベストプラクティス

2023年11月22日に開催

株式会社ココナラ・川崎氏、ENECHANGE株式会社・岩本氏、株式会社BookLive・日向野氏は、それぞれの企業におけるセキュリティ対策の見直しについて話しました。全3回。前回はこちらから。

スピーカー

AWSを巻き込んで具体的な対策を立てていった

渡辺洋司氏（以下、渡辺）：とりあえず先を見ていきますね。「こんな感じの体制でしたよ」というところと、続いて、社内のセキュリティ対策体制が実際にどんな感じで変わってきたのかの話を聞きたいと思います。では川崎さん。またお願いします。

川崎雄太氏（以下、川崎）：はい。先ほど体制の話をした中で、どんなふうに上っていったかを簡単に説明しました。一言で言ってしまうと、セキュリティの専門の人がいない中で上場に向けて何をやるかとか。あとは、先ほどのCSIRTのセキュリティエンジニアが入ったのが2022年8月とかなので、上場してからもまだセキュリティのエンジニアがいない状況でした。

そういう時に我々の取れるアクションの1個で一番大事なのは、AWSのセキュリティを強化するにはやはりAWSに頼りましょうというところかなと思っています。平たく言うとですね、AWSをかなり巻き込んでセキュリティに関しての対策をどうやってやっていくかとか、具体的なHOWの部分の手段についてもやっていくというところをやっていました。

もちろん、セキュリティ以外もインフラのリアーキとか、アプリケーションレイヤーにも踏み込んで、定例のミーティングをいろいろしました。

セキュリティに関しても月次でミーティングしていって、「世の中のトレンド的にこういうのをやっているよね」とか、「ココナラぐらいの規模の会社さん、他社でいうとこういうところに苦しんでいて、こういうふうにやらなきゃいけないよね」と、そういう具体的な話をAWSさんからいろいろとインプットをしてもらって、取捨選択して経営層にぶつけていって、「さぁ、どの順番で何をやろうか」という道筋を立てていくことをやっていました。

一応の一例としては「Well-Architected Tool」。これはデファクトかもしれませんが、AWSを使っていく上では、まずここでアセスメントをしてみて、どこにどんな課題があるのかを浮き彫りにしていく。

その中から「優先度の高いものってどれなんだっけ？」ということをココナラ担当のSAの方と一緒に、二人三脚で「ここは今は一定できているから、いったん塩漬けにしておくか」とか、「ここは本当になにもできていなからまずやらなきゃダメだよね」みたいなところを話し合ってやっていく。

具体的にそのようなアプローチを取っていたというのが、ココナラの環境になっています。以上です。

渡辺：ありがとうございます。

WafCharm＋αで月20万ぐらいの攻撃は防げている

渡辺：続いてもう1枚スライドがあります。実際にWafCharmを導入してもらっているので、そのあたりの話も聞けたらなと思います

（スライドを示して）実際にいろいろと効果を書いてもらっているんですが（笑）。使ってみてどんな感じですか？

川崎：はい。ここはもうWafCharmの宣伝をしたいなと思います（笑）。

先ほどもお話ししたとおり、インフラ・SREが片手間でセキュリティをやっていたので、運用に時間をかけていなかった時には、WAFの運用は特にメチャクチャ大事なところかなと。ココナラもEOLしているミドルウェアを使っている部分も一定あったりするので、まずはWAFでしっかりと防御しなければいけない。

そういう時に、WafCharmでWAFのルールを運用してもらうというところがファーストアクションかなと思って、まずここに取り組みました。ここも概算ですが、WAFのルールとかでチューニングしていくことは、いろいろとモニタリングをしてチューニングしていくことを考えると、月30時間くらいかかるんじゃないの？　と私のほうで試算していました。

良い意味でこれをまったくやらなくてよくなったので、ここの削減はメチャクチャ助かったなと思っているというのがまず1点です。

とは言っても、自分たちでも一定のルールはやらなきゃいけないなという部分はあったので、定期的なブラックリストの更新とか、あとはWAFの細かいところでいうのであれば、レートベースルールをしっかりいろいろな場所に使い込んでいく。

ユーザーさんの導線とかを考えて、「ここはこういう頻度で来るから、このぐらいのレートベースを仕掛けましょう」ということで、DDoS攻撃を対策していくようなところもやっていました。

なので、「WafCharm＋自分たちでマネージドルールをチューニングしていく」という二段構えで攻撃対策していくというところで、結果として、だいたい月20万件ぐらいの攻撃を防げているかなという印象があります。

ここは今まではモニタリングもできていなかったし、「ここまで防げていなかったことに対して、WafCharm＋αでがんばってみたらこれぐらい効果が出ました」ということは、1個紹介として挙げさせてもらいました。以上です。

渡辺：ありがとうございます。

SIEM on Amazon OpenSearch Serviceを利用して感じたこと

渡辺：続いてもう1枚（スライドが）あるんですけど。ここ最近「SIEM on AWSといえば川崎」という感じになっているので（笑）。このあたりの説明も紹介してもらえればと思います。

川崎：はい。超具体的なところを1個ぐらい話したいなと思ったので、SIEMの話を持ってきました。これは「SIEM on Amazon OpenSearch Service」という、AWSがパッケージとして提供しているSIEMのソリューションです。

これをココナラで導入した背景の「セキュリティログの監査とかをしっかりしましょう」ということは、Well-Architected Toolの項目にも1個ありました。

これがまったくできていなかった時に、そもそも悪意のあるアクセスがどのくらい来ているのかとか、アクセスがどのくらい大量に来ているのかがまったくわかっていなかったので、「まずは可視化しないとなにも始まらないね」ということで2021年に導入し始めました。これを利用するにあたっても、SAの方に伴走してもらいました。

あとは、ココナラのSA生産＋αで、2.5時間ぐらいのハンズオンをしてもらいました。そもそも「CloudFormation」でデプロイからなにから全部できるので、その場でやってしまいましょうとか。

どんな感じで何を見るとどういうふうなモニタリングができたり、どこをどうやったらアラートがしかけられたりとか、いろいろなところを全部ハンズオンでやってもらったので、このあたりの学習コストがぜんぜんなくできたのも、1個の特徴かなと思っています。

正直に言ってしまえば、ログの分析は「S3」＋「Athena」でできます。ですが、やはりクエリを使わなければいけないとか、そもそもアラートとかモニタリングは自分たちから情報を取りにいかないとS3＋Athenaだと厳しいと思うので、ダッシュボード化していくとか、それによってアラートを仕込む。メトリクスを見ていくようなところを使う時には、このソリューションはメチャクチャ活かせているかなと思います。

なのでぜひ。お金もそれなりにはかかりますが、費用対効果の高いソリューションだと思うので、もし検討している方がいたらぜひよろしくお願いしますという宣伝でした。以上です。

渡辺：ありがとうございます。前回もお話を聞いて、「費用が……」というところは……。S3とAthenaでできるけれど、実際はリアルタイムのモニタリング（が必要というところ）と、あとは費用がちょっとかかるというのがあると思うんですが、実際に今データを保存している期間は、OpenSearchだとどのくらい入れているんですか？

川崎：今はだいたい7日間入れています。7日前の攻撃を調べることはないだろうということで、そこは割り切りとしてチューニングしているというのが1つあります。あとは、過去データを見たければS3にちゃんとあるので。それを再インデックスすれば情報を見ることができるというのもあるので、いったんリアルタイムは前7日分にしています。

渡辺：なるほど。ありがとうございます。じゃあ導入の相談は川崎さんに（笑）。

川崎：はい（笑）。

大規模な攻撃・脆弱性対策のためにWafCharmを導入

渡辺：お待たせしました。ここからはBookLiveの日向野さんにお話を聞きたいと思います。先ほど冒頭でも話しましたが、BookLiveさんは本当にWafCharmの初期から利用いただいていて、そのあたりの導入の流れ・背景とかを聞けたらと思っています。

日向野達郎氏（以下、日向野）：はい。弊社がセキュリティ対策を強化するきっかけになったのが2018年頃です。2018年当時、弊社として初めての規模となるマス広告の展開を予定していました。マス広告によって知名度が向上すると、そのデメリットとしてはセキュリティ攻撃を受けやすくなるというところがあるかなと考えていました。

弊社としては、もともとセキュリティ対策に関して必要十分なものは行っていました。アプリケーションレイヤーでの脆弱性対策ですね。不審な動きをしているIPのブロックや入力値のサニタイズ。基本的なところも含めて十分対策はできていたかなと思っています。あとは外部の診断会社による脆弱性診断も定期的に行っていました。

今も継続して行っていますが、指摘事項があれば優先度や重要度に合わせて随時対応を行っているというところで、その当時でも対策はできていたのかなと思っていました。ですが、知名度の向上によって大規模な攻撃、特にはDDoS攻撃などに対しては十分な対策はできていなかったのかなと。

あと、脆弱性診断を受けるのも頻繫にやっていたわけではないので、新たに発見されたような脆弱性とか、恒常的に機能開発する上でどうしても発生しかねないセキュリティホールに関しては、素早く対策ができていたわけではない。主にこの2点が当時の課題としてあったかなと考えています。

そちらに向けて「じゃあセキュリティ対策を強化しよう」と考えていったところで、もともと弊社のストアサービスがその時点でもうAWS上で稼働していたところもあったので、脆弱性対策としてはAWSに関連するサービスを使っていこうというのは早い段階で決まったことになります。

AWSでいうとWAFと「Shield Advanced」を使っていこうというところは決まっていました。（スライドを示して）それを最適化していく上でのいろいろな紆余曲折があったというところは、ここにも映しているんですが、WAFのルールを自前でカスタムしていくのは非常に難易度が高いなと感じていたところがあります。

その当時、専任のセキュリティの担当とかチームがあったというわけではないので、自前でカスタムしていくのはやはり非常に難易度が高いなと考えていました。その時点で、解決策の候補としては2つあったかなと思います。

日向野：1つは、当時はまだAWSが提供しているマネージドルールがリリースされていなかったので、パートナーのマネージドルールを利用するパターン。2つ目が、WAFのルール運用をお任せできるサービスを利用するというパターンでした。

先ほど話があったとおり、（WAFのルール運用をお任せできるサービスは）当時はまだできたばかりだったと記憶していますが、WafCharmが国内（のサービス）では唯一の良い選択肢だったかなと記憶しています。

この2つの選択肢に対して、PoCというかたちで検証を行っていき、パートナーマネージドルールに関しては、弊社のストアシステムの利用用途というところでは、誤検知が多かったというのがファクトとしてありました。

弊社は電子書籍のストアを担っているので、技術書を探す際に「SQL」とか「スクリプト」という文字列も入力するケースもあるんですが、パートナーマネージドルールを適用した状態だとそれがインジェクション的なものと判定されて、ブロックされてしまうところがありました。

パートナーマネージドルールは実はカスタマイズがなかなか難しかったのと、当時は提供ベンダーが海外企業だったので、日本語でのサポートも期待できなかったというところで、回避する方法がなかなか（なくて）難しかったというのが結果としてありました。

その点、WafCharmを利用していた際には、WafCharmさんに「こういった文字列に関しては除外判定してほしいです」と連絡することで、すぐに対応してもらえたので、検知精度を素早く上げることができました。日本企業で日本語でサポートの方と連絡できる体制が整っていたというところも安心材料になったので、結果としてWafCharmを導入してWAFを運用していこうと決めた次第です。

渡辺：誤検知の話は私も一緒にサポートをしていて。書籍のタイトルとかなので、例えばUNIXのコマンドのcatとか、そういうものは攻撃としては止めなきゃいけない。（でも書籍のタイトルに）猫のcatが出てくるみたいなことがあって（笑）。

「確かにね」みたいなところを、一緒にやらせてもらうことで我々としても勉強になったという（笑）。非常にありがたい事例です。

サーバーレスな環境を目指して構成を設計した

渡辺：（スライドを示して）こちらはこんなシステム構成ですよというものが、ありますけれど。

日向野：はい。今見せているのが、セキュリティ対策を強化したあとの概略図になっています。弊社のインターネットベーシングのALBのWAFとShield Advancedを適用して、Shield AdvancedでDDoS攻撃を防御。脆弱性を突いてくるような攻撃に関しては、WAFで防御をするようなかたちになっています。

こちらの構成で意識していたこととしては、サーバーレスな環境を目指したというところがあります。やはりセキュリティ対策は重要課題ということはもちろん認識のとおりだと思いますが、じゃあそこに無尽蔵にコストを使っていいのかというと、もちろんそういうことではなくて、会社の人員とかお財布事情とかも含めて、やはり限られたリソースで運用していかなければならない。

というところを考えると、その運用コストをいかに小さくするか、限られたリソースでどれだけの最大の効果を発揮するかを考えなきゃいけないところは、セキュリティ対策においても同義かなと考えています。

そういった点で、なるべく「EC2」のような常時稼働させるようなものを排除して、AWSのマネージドサービスを活用していって、運用コストの最適化と料金面。必要な時だけ稼働するというようなところでのサーバーレスな環境を目指すことで、料金コストの最適化を目指して実現できたようなかたちになっています。

渡辺：では、実際のところですね。

日向野：そうですね。細かいところの話をしていくんですが、WAFに関しては、WAFが検知するサンプルリクエストを弊社のSlackチャンネルに通知するようにしています。AWSのWAFで防御しているブロックしたものとか、カウントモードを適用したものをSlackのチャンネルに通知するようにしています。

こちらを確認することで、新規に適用したルールが適切に働いているか、もしくは意図せず正常なリクエストをブロックしていないか、カウントしていないかを簡単に確認できるようにしています。

もう1つが、ダッシュボードツールである「Kibana」との連携も行っています。こちらはブロックしたリクエストを、すべてALBのログから取得してKibanaに取り込んでいます。ブロックされた件数とか、アクセスしてきた件数の全体的な傾向を確認する目的で、Kibanaのダッシュボードを利用しています。

WafCharmの連携に関しても、サーバーレスな構成でというところですが。WAFのログを「Firehose」と「Lambda」を経由してS3に入れることで、WafCharmからS3に入っているログを取得して、それをもとにWafCharm側からルールのカスタムを行っている流れになっています。

WafCharmでは、IPレピュテーション情報を元にしたブロックリストのルールの更新とか、新たに発見されたセキュリティリスクへの対策ルールの追加というところで、WAFのルールのカスタムを随時行っている状態になります。

Shield Advancedについて、DDoS検知の動きもSlackに通知するようにしています。DDoS攻撃を検知したらSlackの「緊急度が高い」と設定したチャンネルに通知するようにしています。こちらのイベントを「CloudWatch Alarm」で検知して、SNSを経由してSlackに通知するようにしています。そうすることで、社内の温度感がにわかに高まることを目指してやっています。

それに並行して、DDoS攻撃を検知した場合には、AWS側のShieldレスポンスチームに自動でエスカレーションするような仕組みも設定しています。こちらも同様に、Shield AdvancedからCloudWatch Alarm、SNSを経由して、Lambdaでサポートのケースの文章を作って、サポートからSRチームにリクエストを投げるというところを自動化しています。

そうすることで、SRチームでDDoSかどうかというのを自動的に検証してもらうような動きを行っています。なので、ここは弊社側の人員の手を介さず、自動的に連携できるようにしています。

渡辺：ありがとうございます。

SRTを利用して感じたこと

渡辺：ここで気になるところはSRT（Secure Reliable Transport）ですね。実際にSRTを利用してもらっていて、実際の効果とか、そういう助かっているみたいなところはなにかありましたか？

日向野：はい。DDoS検知に関しては、幸いにして、実際にこれを導入してからDDoSなどをされる攻撃は発生していません。キャンペーンなどで一時的に負荷が増えた、アクセスが増えたということでDDoS疑いを検知したことはありましたが、実際のDDoSの攻撃としてこちらの連携が動くようなことはなかったです。

Shield Advancedを利用しているというところで、もちろんL3とかL7に関しては自動的に防御されている状態だと思うので、実際に体感できるところではないかもしれませんが、もちろんDDoS攻撃に関しては防御されていて、それにより被害は受けないということができていますね。