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
2.7k
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
Ubieにおけるセキュリティ課題管理の自動化 / ubie-sec-issue-automation
mizutani
0
650
Trivy + Regoを用いたパッケージ脆弱性管理 /trivy-rego
mizutani
7
4k
リモートワークを支える 社内セキュリティ基盤の構築と運用 /secueiry-for-wfh
mizutani
0
630
SOARによるセキュリティ監視業務の効率化とSecOps /soar-and-secops
mizutani
1
970
Webサービス事業会社におけるEDRの検討と導入の事例 /falcon2019
mizutani
1
660
AWS re:Inforce recap 2019
mizutani
1
4.2k
スケーラブルなセキュリティ監視基盤の作り方 /techconf2019-mizutani
mizutani
3
2.9k
Webサービス事業会社におけるEDRの検討と導入の事例 /falconday201812
mizutani
3
2.2k
クックパッドのセキュリティログ 検索基盤の紹介 /security-log-search
mizutani
3
3.5k
Other Decks in Technology
See All in Technology
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.2k
.NET Profiler in 2024.
kkamegawa
2
1.7k
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
280
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
260
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
150
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
8
900
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
8
630
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
4
620
How to do well in consulting–Balkan Ruby 2024
irinanazarova
0
150
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
340
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
2
400
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
710
Featured
See All Featured
Unsuck your backbone
ammeep
663
57k
Clear Off the Table
cherdarchuk
85
310k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Build your cross-platform service in a week with App Engine
jlugia
226
17k
Designing the Hi-DPI Web
ddemaree
276
33k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Designing for humans not robots
tammielis
247
25k
Visualization
eitanlees
137
14k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
Ruby is Unlike a Banana
tanoku
96
10k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
22
1.6k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
11
1k
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