Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon Athena を使った セキュリティログ検索基盤の構築 /seclog-athena
Search
Masayoshi Mizutani
January 31, 2020
Technology
5
3k
Amazon Athena を使った セキュリティログ検索基盤の構築 /seclog-athena
ログ分析勉強会 vol.2
https://loganalytics.connpass.com/event/157354/
の資料です
Masayoshi Mizutani
January 31, 2020
Tweet
Share
More Decks by Masayoshi Mizutani
See All by Masayoshi Mizutani
MCPの基礎とUbieにおける活用事例 /ubie-mcp
mizutani
3
1.8k
クラウドセキュリティのベストプラクティスと実装例 /cloudsec-bestpractice-example
mizutani
9
3k
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
2
790
Ubieにおけるセキュリティ課題管理の自動化 / ubie-sec-issue-automation
mizutani
0
900
Trivy + Regoを用いたパッケージ脆弱性管理 /trivy-rego
mizutani
7
4.6k
リモートワークを支える 社内セキュリティ基盤の構築と運用 /secueiry-for-wfh
mizutani
0
740
SOARによるセキュリティ監視業務の効率化とSecOps /soar-and-secops
mizutani
1
1.1k
Webサービス事業会社におけるEDRの検討と導入の事例 /falcon2019
mizutani
1
790
AWS re:Inforce recap 2019
mizutani
1
4.3k
Other Decks in Technology
See All in Technology
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.2k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
160
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
120
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
160
解析の定理証明実践@Lean 4
dec9ue
1
210
mrubyと micro-ROSが繋ぐロボットの世界
kishima
3
390
Geminiとv0による高速プロトタイピング
shinya337
0
210
怖くない!はじめてのClaude Code
shinya337
0
320
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
240
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
400
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
220
Featured
See All Featured
Being A Developer After 40
akosma
90
590k
Code Reviewing Like a Champion
maltzj
524
40k
Automating Front-end Workflow
addyosmani
1370
200k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Done Done
chrislema
184
16k
Agile that works and the tools we love
rasmusluckow
329
21k
How to Ace a Technical Interview
jacobian
277
23k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Transcript
Amazon Athena を使った セキュリティログ検索基盤の構築 クックパッド株式会社 技術部セキュリティグループ 水谷正慶
本日のトピック •以前のセキュリティログ検索基盤の課題 •セキュリティログ検索の要件 •検索基盤の設計と実装 ΫοΫύουͷηΩϡϦςΟϩάݕࡧج൫Λ "NB[PO"UIFOBΛϕʔεʹ࠶ߏஙͨ͠Λ͠·͢
講演者自己紹介 •水谷 正慶 (@m_mizutani) •クックパッド株式会社 (2017.11〜) ‣ 技術部セキュリティグループ グループ長 ‣
セキュリティ監視基盤の設計・構築・運用を主に担当 •前職ではSOCアナリストやSIEMに関する研究開発など
None
5
社内情報セキュリティの指針 •制限や禁止事項を厳しくしすぎない ‣ 社内でスムーズに情報共有ができるようにする ‣ オフィスから外部へのアクセスを不必要に制限しない ‣ リモートでもオフィスと変わらずに仕事ができる環境づくり • その代わりガッチリ監視をする
• 問題を検出する • 問題発生後に追跡できるようにする セキュリティ監視の仕組みは重要な位置づけ 6
https://techlife.cookpad.com/entry/2019/11/21/073000 7
これまでのセキュリティログ検索基盤 •Graylogを利用 ‣ Elasticsearchをベースにした OSSのログ検索エンジン ‣ インタラクティブな検索UI ‣ 様々なログを取り込んで横断 検索可能に
8
Graylogの利用における課題 •弾力性があまり高くない ‣ スケールイン・アウトがスムーズにできない •使用頻度に対してコストが高い ‣ Use caseが基本的にはアラート発生時の調査なので検索の頻度は限られる ‣ およそ月額40万円強、年間500万円
•Elasticsearchの運用が辛い ‣ 流量から単純に負荷を見積もれないため新しい種類のログ投入時には緊張感が必要
クックパッドでのセキュリティログ検索の要件 (1/2) 1. 複数種類のログスキーマに依存しない検索ができる • 現状で20種類くらいのログを収集 • 全種類のログスキーマをメンテし続けるのは激しく消耗 2. ニアリアルタイムで検索ができる
• ログ発生から5〜10分ぐらいで検索ができるようになる状態にする • 数秒以内を目指しても専属のアナリストがいないので無意味 • Managed SOCなどではSLAを15分程度に定めておりその範囲なら問題ないとする
クックパッドでのセキュリティログ検索の要件 (2/2) 3. 単語境界を識別した検索ができる • “10.0.0.1” を検索したいときに “110.0.0.119” とかがヒットしないでほしい 4.
ログの投入時に容易にかつ迅速にスケールアウト・スケールインが可能である • ログ流量の変化に対して弾力性があってほしい • 新しい種類のログを投入するときに他のログが影響を受けないように 5. 全体的な費用負担を減らす • 余計なコストを削減することで別のことにお金を使える
今回利用した主なAWSサービスの(雑な)紹介 • AWS Lambda: サーバレスのコード実行サービス。 容易にスケールイン・アウトさせられる •Amazon S3: オブジェクトストレージサービス。 格安でデータを投入・保存できてしかも高可用
•Amazon Athena: S3上のデータをSQLで抽出・分析 ができるサービス。
ログ検索のためのアプローチ (1/2) •オンラインストレージ(EBS等)と比べてS3は爆安 •検索は低頻度なのでスキャン量課金が有利 •grepよりはもう少し複雑なクエリを書くためにS3 selectよりAthenaを採用 ϩά"844ʹอଘͯ͠ݕࡧ"UIFOBΛར༻͢Δ
ログ検索のためのアプローチ (2/2) •単語境界識別のために前処理をしておく必要がある • Lambdaを使うことでシームレスにスケールする • S3バケットに一次集約されたログをLambdaで処理し て別S3バケットにparquet形式で保存 ϩάͷೖ࣌ʹ-BNCEBΛར༻ͯ͠ΠϯσοΫεΛ࡞͢Δ
テーブル設計 ϩάͷɾจষΛղ ͯ͠୯ޠ୯ҐͰJOEFY ςʔϒϧʹอଘ Ͳͷ4ΦϒδΣΫτ͔ ʢPCKFDU*%ʣͱͦͷΦϒδΣ ΫτͰԿ൪ʹͰ͖ͯͨϩ ά͔ʢߦ൪߸ʣه ରʹͳΔϩάͷຊจΛ4Φϒ δΣΫτͱߦ൪߸͝ͱʹNFTTBHF
ςʔϒϧʹอଘͯ͠ɺJOEFYςʔϒ ϧͷݕࡧ݁ՌͱKPJO͢Δ
実装 •Minerva (Backend) https://github.com/m-mizutani/minerva ‣ Lambda (Go) + Athena +
DynamoDB + API gateway ‣ Serverless構成をCloudFormationでdeploy •Strix (Frontend) https://github.com/m-mizutani/strix ‣ Go with gin-gonic + Vue ‣ Docker imageにしてECS上にdeploy
検索時の全体構成イメージ Strix Minerva エンジニア ECS API gateway Athena S3
Minerva (Backend)
Minerva (Backend)
Minervaの役割 (1/2) 1. ログの投入 • 一次集約されたログをダウンロードし、Indexテーブル、messageテーブル用に parquetファイルを生成 • ElasticsearchにおけるStandard Tokenizerのような実装を自作して単語を分割
2. パーティションの作成 • パーティション例: s3://***-bucket/some-prefix/indices/dt=2019-11-01-05/ some-bucket/some-key.parquet • 新しいパーティションにログが保存されたらAthenaにALTER TABLE命令を発行
Minervaの役割 (2/2) 3. ログのマージ • ログ投入時には元のファイルと1対1でparquetファイルを生成していたが Athenaの検索では細切れのファイルではパフォーマンスがでない • 一定時間ごとに複数のファイルをマージしている 4.
ログの検索 • API gatewayでリクエストを受け取りAthenaへクエリ発行 • クエリの組み立てはLambda内で実施する
Strix (Frontend) •検索の対象範囲を時間で絞り込む ことで10秒〜数十秒で検索可能 •検索結果に対してjqでフィルタを 書いてインタラクティブな分析を サポート •検索結果を半永久的に保存して分 析時の記録として残せるように
Demo
成果 •過去1時間程度のログなら10秒程度で検索可能 •まだ完全に移行はできていないが対象ログを1ヶ月間分 (非圧縮 約7.5TB)保持してもコストは1/10以下であ る3万円に収まる見込み
FAQ •Glue使わないの? ‣ 起動間隔がそこそこ長い(最短5分+起動から処理開始までにもラグ) •Firehoseでparquet変換しないの? ‣ 到着時間ベースでの時間分割になってしまう(生成時間ベースにできない) •CloudWatch Logsに投入しないの? ‣
お値段が厳しい(投入だけでS3で1ヶ月保存する30倍) ‣ 流量が増えると検索が厳しくなる
None