Amazon Athena を使った セキュリティログ検索基盤の構築 クックパッド株式会社 技術部セキュリティグループ 水谷正慶

本日のトピック •以前のセキュリティログ検索基盤の課題 •セキュリティログ検索の要件 •検索基盤の設計と実装 ΫοΫύου಺ͷηΩϡϦςΟϩάݕࡧج൫Λ "NB[PO"UIFOBΛϕʔεʹ࠶ߏஙͨ͠࿩Λ͠·͢

講演者自己紹介 •水谷 正慶 (@m_mizutani) •クックパッド株式会社 (2017.11〜) ‣ 技術部セキュリティグループ グループ長 ‣ セキュリティ監視基盤の設計・構築・運用を主に担当 •前職ではSOCアナリストやSIEMに関する研究開発など

No content

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倍） ‣ 流量が増えると検索が厳しくなる

No content