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
20分で完全に理解するGrafanaダッシュボード
hamadakoji
3
620
Python と Snowflake はズッ友だょ!~ Snowflake の Python 関連機能をふりかえる ~
__allllllllez__
1
120
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
0
140
JSON攻略法.pdf
miyakemito
8
5k
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
620
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
670
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
570
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
160
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
130
LLM開発・活用の舞台裏@2024.04.25
yushin_n
1
150
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
190
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
221
21k
How to Ace a Technical Interview
jacobian
272
22k
The Art of Programming - Codeland 2020
erikaheidi
42
12k
Raft: Consensus for Rubyists
vanstee
132
6.3k
Web development in the modern age
philhawksworth
202
10k
What the flash - Photography Introduction
edds
64
11k
For a Future-Friendly Web
brad_frost
172
9k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
352
28k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Into the Great Unknown - MozCon
thekraken
10
990
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