ココナラが膨大なセキュリティログの可視化と分析を実現するまで
川崎 雄太 (株式会社ココナラ)
こんにちは、株式会社ココナラの川崎です。プロダクトインフラと社内情報システムのエンジニアマネージャーを担当しています。
ココナラでは 2021 年からセキュリティ組織を立ち上げており、現在も試行錯誤してセキュリティ強化を進めていますので、その内容をご紹介します。
昨今、DDoS 攻撃や不正アクセスなど、攻撃にさらされる機会は少なくありません。
その中でセキュリティ観点でのログ分析の重要性は高く、例えば「インシデント発生時のリアクティブな調査・分析」から「日々の傾向分析〜アクション創出といったプロアクティブな対応」を可能とします。
「ココナラで抱えていたセキュリティの課題」や「どのように SIEM on Amazon OpenSearch Service を導入し、セキュリティログ分析やモニタリングを実現していったか ?」について、具体的な取り組みをご紹介します。
ココナラで抱えていたセキュリティの課題
以下のようなセキュリティ課題を抱えており、それを解決するために 2021 年に CSIRT を立ち上げました。
- セキュリティの専門部署がなく、どのようにロードマップを描き、合意形成し、計画して登っていけばよいかが不明確。
- セキュリティの課題がリストアップされておらず、「もぐらたたき」で対応をしていた。
- セキュリティに関するログを自己流で取得していたが、正しく活用できていなかった。
今回の記事は 3 にフォーカスした内容となります。
以下の図は 2021 年時点におけるココナラにおける脅威とセキュリティ課題をリスク別に整理した資料になります。セキュリティ課題の 1 つ 1 つに重み付けをし、件数と掛け合わせて対応状況を評価しました。
2021 年当時は EDR 製品の導入やフォレンジックを行っていたので、社内情報システム関連のセキュリティ対策はコーポレートエンジニア中心にある程度出来上がっていましたが、プロダクト側は DDoS 攻撃や脆弱性攻撃への対策は一定していたものの、セキュリティの専門部署がなかったため、まだ改善の余地がある状況でした。
「いつ、どのようなことが起きているか ?」を把握して、打ち手を導出することがセキュリティログ分析に取り組んだきっかけになります。
セキュリティログ分析への取り組み
セキュリティログ分析は分析、検知、監査、監視など目的は様々ですが、「ある時点のシステムの状態 (コンディション) を把握」し、そこから「対応が必要な場合の打ち手を創出する」ことをココナラでは目指しています。
ココナラでもセキュリティログ分析に取り組もうとしていましたが、一筋縄では行きませんでした。例えば、そのままのデータ形式では可読性が低い状態ですし、ログの量が膨大です。そのため、セキュリティログ分析の仕組みが必要と考えました。
WAF ログのサンプル
{"timestamp":1660500016184,"formatVersion":1,"webaclId":"arn:aws:wafv2:xxxxxxxxxx:xxxxxxxxxxxx:regional/webacl/coconala-xxx-xxx/fa1c1322-be20-40b4-bd60-57a76114df65","terminatingRuleId":"Default_Action","terminatingRuleType":"REGULAR","action":"ALLOW","terminatingRuleMatchDetails":[],"httpSourceName":"ALB","httpSourceId":"xxxxxxxxxxxx-app/coconala-xxxxxxxxx/62e94fe4ea5bbd7d","ruleGroupList":
〜〜中略〜〜
"requestHeadersInserted":null,"responseCodeSent":null,"httpRequest":{"clientIp":"xxx.xxx.xxx.xxx","country":"JP","headers":[{"name":"host","value":"coconala.com"},{"name":"accept","value":"application/octet-stream,image/x-icon,image/jpg,image/jpeg,image/png,image/x-win-bitmap,image/ico,image/x-bmp,image/tiff,image/gif,image/bmp,image/x-xbitmap,binary/octet-stream,image/x-ms-bmp"},{"name":"user-agent","value":"Coconala/x.xx.x (com.coconala.ios.portal; build:x.xx.x; iOS xx.x.x)
〜〜後略〜〜まずは、AWS Well-Architected Tool の「セキュリテイ」の柱のレビューをココナラの AWS Japan 担当者に伴走してもらったことや、AWS Japan との月例会・個別テーマの定例を設けて、1 つ 1 つ解決していきました。
その中で「SIEM on Amazon OpenSearch Service」と出会い、人力では 1 つ 1 つ確認することが非現実的な量のログの可視化と分析に挑戦しました。
ココナラでは「アクセス状況や攻撃・インシデントの可視化・予測を行うこと」を目的に導入しています。例えば、ココナラというプロダクトは国内を中心にサービスを提供していますので、国外からのアクセスは通常利用のケースもありますが、そうでないケースもあるのでその判別やモニタリングに活用しています。
どのように解決していったか ?
前述の通り、システムの規模が多くなればなるほど、ログの量が膨大となり、分析の仕組みが不可欠となるので、SIEM on Amazon OpenSearch Service の活用に踏み出しました。
最初は試行錯誤して、導入していく方向性を AWS Japan へ相談したところ、SIEM on Amazon OpenSearch Service のハンズオン を開催していただき、環境構築から模擬運用まで実践しました。
ココナラでの環境構築はワークショップの中で完結しているので、今回は触れませんが、Github に公開されている手順 の通りで簡単に行うことができます。
AWS CloudFromation を実行し、あとは待つだけで環境が出来上がります。
具体的な利用事例を 3 つ紹介します。
まず初めに AWS WAF ログを取り込ませて、以下の可視化と分析を行いました。
- アクセス状況 (国内、国外）
- WAF のブロック状況 (IP アドレス別、国別、UA 別、URL 別、など）
そこから深堀りをしていき、WAF ルールの点検など、プロアクティブに攻撃への対策を講じることができるようになりました。
次に Elastic Load Balancing (ELB) ログを取り込ませて、以下の可視化と分析を行いました。
- HTTP レスポンスコード状況 (2xx 系、4xx 系、5xx 系、など）
- アクセス状況 (IP アドレス別、国別、UA 別、URL 別、など）
AWS WAF ログの状況と突き合わせを行い、怪しいアクセスをしている IP アドレスの拒否リスト登録など、攻撃の芽を早めに摘むことができるようになりました。
ココナラでは、4xx 系と 5xx 系のリクエストが 30 秒あたりに 100 回を超えた場合に怪しいアクセスが発生していると考え、IP アドレスの割り出しやアクセスしている URL を確認し、特に不正な URL にアクセスしていることが確認できたら、WAF の IP アドレス拒否リストに追加するという運用を行っています。
こちらのダッシュボードからは先に述べた対応の他に、単位時間あたりの IP アドレスごとのグラフから極端にアクセス数の多い IP アドレスが無いか ? を確認したり、単位時間あたりのアクセス数のグラフから極端にアクセス数が増えていないか？を確認しています。
最後に Amazon GuardDuty と連携させて取り込ませて、以下の可視化と分析を行いました。
- 脅威発生状況 (脅威の種類、IP アドレス別、国別、など）
脅威を行ってくる IP アドレスは HTTP リクエストとしても攻撃を仕掛けてくる可能性があるので、AWS WAF / ELB ログの状況と突き合わせを行い、こちらも IP アドレスの拒否リスト登録など、攻撃の芽を早めに摘むことができるようになりました。
上記の実現手法ですが、各種ログが格納されている Amazon S3 バケットからセキュリティ関連を統制する AWS アカウントへクロスレプリケーションすることで簡易に自動転送・自動取り込みを行っています。
これを行うだけで、ダッシュボードにデータが可視化され、分析を行うことが可能になります。
ココナラでは毎営業日モニタリングを行い、そこから得られた情報を元に次のアクションを創出することでモニタリングを起点とした PDCA サイクルを実現しています。
また、例えばGuardDutyによる侵入検知など緊急性の高いものについては Slack へ即時発報し、日次のモニタリングを待たずに確認・トリアージを行うことで、緊急度に応じた差別化を図っています。
少し話がそれますが、SIEM on Amazon OpenSearch Service を導入する際に AWS アカウントのベストプラクティスに従って、「セキュリティ関連を統制する AWS アカウントを別で構築する」ことで、様々なセキュリティ施策を同時並行で進めていきました。
この点については、別の記事で何をどう進めていったか ? をまとめようと思います。
効果
主に以下のメリットを享受していると考えます。
- システム全体のアクセス状況をダッシュボード化し、ドリルダウンによる分析を可能にした
- 異常値を視覚的に把握することができ、他の監視ソリューションと組み合わせて、セキュリティインシデントの予兆検知と発生後の分析高速化を実現した
- これらを日次運用を定義してPDCAサイクルを回すことで、プロアクティブ/リアクティブな対応を効率的に行えるようになった
ココナラでは AWS WAF / Elastic Load Balancing / Amazon GuardDuty / AWS CloudTrail のログを取り込んで活用しています。
例えば、リクエスト量の増加を他の監視ソリューションで検知した際に、ダッシュボードから DDoS 攻撃が起きているか ? の切り分けや深堀りを行っていたり、ログイン処理の試行数が増加している IP アドレスを特定し、遮断を行う、などのユースケースで SIEM on Amazon OpenSearch Service が活躍しています。
他にも、日次でアクセスの多い IP アドレスを抽出し、深堀りや閾値を設定して常に追いかけられるようにモニタリングする、などのプロアクティブな活用もできています。
今後の取り組み
導入して 1 年程度のため、継続したリファクタリングを行うことが重要と考えます。
他のログのダッシュボードも多数用意されていますので、そちらの活用を検討したり、ログフォーマットを自作し、セキュリティログ以外のログの取り込みにも挑戦してみたいと思います。
また、セキュリティログ分析を行うことで様々なファクトが明らかになりました。
例えば、それなりの頻度で1分間に数百回以上のアクセスを行っているお行儀の悪いスクレイピングが行われていることや、海外から DDoS 攻撃までは行かないまでも大量アクセスされていることなどです。
それらをベースに経営層に対して、セキュリティ対策の必要性と効果を定量・定性の両面から伝えていくべく、SIEM on Amazon OpenSearch Service を活用していこうと思います。
特に「IPO を目指している企業」 や 「IPO 後でより一層セキュリティ対策を強化しなければならない企業」 へ持ち帰ることができる内容があると考えますので、ご活用いただけたら幸いです。
筆者プロフィール
川崎 雄太
株式会社ココナラ システムプラットフォームグループ 兼
情報システムグループ Group Manager
法政大学卒業後、電力会社に入社し、インフラエンジニアとしてキャリアをスタート。その後、リクルートテクノロジーズ (現リクルート) でプロダクトインフラ / SRE組織やセキュリティ組織のチームリーダーを経て、アドテク企業でプロダクトインフラ組織のグループマネージャーを歴任、セキュリティ組織の立ち上げも経験。
2020 年 10 月にココナラへジョイン。入社当時はプロダクトインフラを担当していたが、2021 年から社内情報システムも担当となり、二足のわらじで組織の成果の最大化とインフラを起点としたQCD向上に取り組んでいる。
AWS を無料でお試しいただけます