セキュリティログ分析にSIEM on Amazon OpenSearch Serviceを利用

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社ココナラ / Yuta Kawasaki（ゆーた）

開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2025/11/04投稿日2025/11/04

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

SIEM on Amazon OpenSearch Service

10名以下

2022年4月

B to C

C to C

利用機能	SIEM on Amazon OpenSearch Service
ツールの利用規模	10名以下
ツールの利用開始時期	2022年4月
事業形態	B to C C to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

AWSが提供しているアーキテクチャーを踏襲することで、アーキテクチャー設計・構築コストを削減
- CloudFormationを実行するだけで10分程度で環境が構築される
自前で実装したのは所定のS3バケットへのPut処理のみ
- ここはS3レプリケーションで実現している

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

ココナラは上場前後で一定のセキュリティアセスメントを行っていたが、セキュリティの専門組織は持っていなかった。具体的には以下のようなセキュリティに関する課題を抱えていた。

セキュリティの専門部署がなく、どのようにロードマップを描き、合意形成し、計画して登っていけばよいかが不明確
セキュリティの課題がリストアップされておらず、「もぐらたたき」で対応をしていた
セキュリティに関するログを自己流で取得していたが、正しく活用できていなかった

上場後にCSIRTを立ち上げており、社内情報システムのセキュリティ対策はある程度できていたが、プロダクトは改善の余地が大きい状況だった。課題を解決するために「AWS Well-Architected フレームワーク」に従って、アセスメントを実施し、3点目の対応としてSIEM on Amazon OpenSearch Serviceの導入を決定した。

どのような状態を目指していたか

セキュリティ課題に対して、適切なアセスメントがされていて、計画的に対策が進んでいる
特にプロダクトに関しては「いつ、どのようなことが起きているか ?」を把握して、打ち手を導出するPDCAサイクルが継続的に回っている
プロダクト開発者はプロダクト開発に集中し、CSIRTがセキュリティ運用をある程度は一手に担える

比較検討したサービス

Elasticsearch
Splunk

比較した軸

導入の容易性が高いこと
小さい環境から始められること
初めての取り組みなので、ベンダーの伴走が十分に得られること
近しい規模感の会社で取り組んでいるような事例であること
- Sansan社、freee社で利用事例があった

選定理由

SIEMの環境をCloudFormationで一括作成できること
AWSの中に閉じて、設定が容易なこと

導入の成果

改善したかった課題はどれくらい解決されたか

セキュリティログ分析についてはやりたいことをできたと言える。少なくとも現在地の確認とリアクティブな運用しかできていなかったところをプロアクティブに持っていけたのは成果。

どのような成果が得られたか

セキュリティログを分析できる環境が作れたことで、「いま、この瞬間に、プロダクトで何が起きているか？」が可視化できるようになった。そして、可視化された情報をもとにプロアクティブな対策を講じたり、PDCAサイクルを継続的に回せる状況を実現できた。

SIEM on Amazon OpenSearch Serviceのりようについて、社外発信しているので以下もご覧いただきたい。

導入時の苦労・悩み

環境構築や運用設計で苦労した点は特になし
実際にセキュリティログを取り込んで、「どのような状況が見えるのか？」がわからなかったので、効果が見えるまでは本当に必要と言えるのか悩んだ

導入に向けた社内への説明

上長・チームへの説明

セキュリティログ分析を行っていないことで「いま、この瞬間に、プロダクトで何が起きているか？」がわからないことのリスクを説明
前述の通り、「効果はやってみないとわからないが、現状問題が無いことがわかるだけでもメリットがある」と説明

活用方法

■通常時

CSIRTにて、毎営業日18時ごろに1日のアクセス状況、アラート状況をモニタリングし、攻撃と思われるアクセスを特定し、記録
アクションが必要なものはIssue化して、優先度と対応予定日を決めて、日々の運用作業に取り込む

■インシデント時

オンコール担当者・CSIRTにて、攻撃を受けているかどうかの調査にて活用

よく使う機能

WAFログ
- 日々のアクセス状況 / ブロック状況のモニタリングと分析
ELBログ
- 日々のアクセス状況、特に悪意のあるアクセスを中心としたモニタリングと分析
CloudTrailログ
- システム基盤の変更点に問題が無いかどうかの確認

ツールの良い点

簡単に立ち上げて試してみることができる
クエリを書く必要がなく、視覚的に絞り込み、分析を行うことが可能

ツールの課題点

SIEM上で閲覧できるログの日数を増やすためにはインスタンスのスペックアップが必要で、お金で解決する必要がある
過去のログを閲覧したい場合は別でSIEM on Amazon OpenSearch Serviceの環境を構築する必要がある
複数条件での分析が難しい

ツールを検討されている方へ

ざっくりセキュリティログの分析を行ってみたい、ライトな環境で試してみたいという方にはおすすめ
- そこまでコストがかからず、かつ、スピーディーに立ち上げが可能
- まずは可視化してPoCをしてみたいというところも自分でコントロールが可能
ログの保持期間を1週間以上にしたい場合は一定のインスタンススペックにする必要があり、その場合はコストがそれなりにかかるという認識を持つことが大事
検知やアラート発報にそこまで適していないので、別のツールを使って実現する必要がある
- たとえば、Amazon CloudWatchアラームなどで仕込む必要あり
複雑なことをやりたい場合はSplunkを利用した方が好ましい場合があるので、比較検討は必須

今後の展望

アラート発報やチャットツールとの連携強化がされるとより利用者が増える可能性がある
AI / LLMの機能が実装されれば、より運用者が楽できるので期待している
- Anomaly Detectionに特化しているため、傾向によって検知できる仕組みが必要になってくる
- このあたりはAWSに対して継続的に要望すると良い

株式会社ココナラ / Yuta Kawasaki（ゆーた）

開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

2020年にココナラへジョイン、Head of Informationとして、プロダクトインフラ・SREと社内情報システム / セキュリティを管掌している。 2024年からココナラテックの執行役員情報基盤統括本部長を兼任。 2025年からココナラのDev Enabling室室長を兼任し、技術広報を中心とした開発の進化を進めている。