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
システム・サービス運用におけるセキュリティ監視の近代的アプローチ /advnet2025-modern-secmon
mizutani
0
63
Deep Security Conference 2025:生成AI時代のセキュリティ監視 /dsc2025-genai-secmon
mizutani
9
5.3k
MCPの基礎とUbieにおける活用事例 /ubie-mcp
mizutani
3
2.5k
クラウドセキュリティのベストプラクティスと実装例 /cloudsec-bestpractice-example
mizutani
9
3.1k
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
2
890
Ubieにおけるセキュリティ課題管理の自動化 / ubie-sec-issue-automation
mizutani
0
950
Trivy + Regoを用いたパッケージ脆弱性管理 /trivy-rego
mizutani
7
4.7k
リモートワークを支える 社内セキュリティ基盤の構築と運用 /secueiry-for-wfh
mizutani
0
770
SOARによるセキュリティ監視業務の効率化とSecOps /soar-and-secops
mizutani
1
1.2k
Other Decks in Technology
See All in Technology
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
4
660
Adminaで実現するISMS/SOC2運用の効率化 〜 アカウント管理編 〜
shonansurvivors
3
360
KMP の Swift export
kokihirokawa
0
340
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
220
『OCI で学ぶクラウドネイティブ 実践 × 理論ガイド』 書籍概要
oracle4engineer
PRO
2
130
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
AWS Top Engineer、浮いてませんか? / As an AWS Top Engineer, Are You Out of Place?
yuj1osm
2
140
about #74462 go/token#FileSet
tomtwinkle
1
440
AI駆動開発を推進するためにサービス開発チームで 取り組んでいること
noayaoshiro
0
220
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
7
2.9k
Large Vision Language Modelを用いた 文書画像データ化作業自動化の検証、運用 / shibuya_AI
sansan_randd
0
110
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
10
4.5k
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
890
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
The Invisible Side of Design
smashingmag
301
51k
Designing for humans not robots
tammielis
254
26k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
The Cult of Friendly URLs
andyhume
79
6.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
How to Think Like a Performance Engineer
csswizardry
27
2k
KATA
mclloyd
32
15k
Producing Creativity
orderedlist
PRO
347
40k
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