2019年03月20日(水) 株式会社リクルートテクノロジーズ 日比野 恒 ETL処理をServerlessにしてみた件 【JAWS-UGコンテナ支部#14】

2 名前: 日比野 恒 (ひびの ひさし) 所属: 株式会社リクルートテクノロジーズ ITソリューション本部 サイバーセキュリティ部 (CISSP、CISA、情報処理安全確保支援士) 志向: オープンSIEM構想を推進 オープンな技術 オープンな環境 × 「オープンな技術」や「オープンな環境」でSIEMを作りたい！！ 「個人の知見やスキルは、社会の利益のために使われるべき」というマインド 自己紹介 後日スライド公開予定

3 本日のテーマ

4 これじゃないよ！

Queuing 5 大規模なセキュリティログ分析プラットフォーム Data Enrichment Data Collector Data Store Data Analyze Container Task (ETL) オンプレ ログ処理サーバ (Shipper) SFPログ 各種 ログ Security Analysts ログ処理サーバ (Shipper) SFPログ イベント ログ AWS Region Data Lake Log A Log Z ・ ・ ・ ・ ・ ・ Container Task (ETL) Container Task (Collector) ・ ・ ・ Container Task (Collector) AWS Cloud Data Archive Instances (Data Store) Instances (BI/Search) CI/CD Stream A Stream Z ・ ・ ・

動的なエンリッチ 6 ログと一言で言っても色々あるよね 定型 非定型 長期 短期 監視業務 (SIEM) 監査業務 (Reporting) フォレンジック調査業務 ハンティング 業務 柔軟なサブクエリ リアルタイム性 多様な検知ロジック 高速な集計処理 迅速なリストア

7 ETL処理とは... DWH ETL Collector Log Log Log Data Lake Log UseCase1 UseCase2 UseCase3 Extract Transform Load

8 ElasticStack on AWSで組んでみた Elastic search Logstash Logstash Log Log Log S3 Log UseCase1 UseCase2 UseCase3 Extract Transform Load

9 ボトルネックになるのは Elastic search Logstash Logstash Log Log Log S3 Log UseCase1 UseCase2 UseCase3 Extract Transform Load 複雑な処理になるほどCPUがきつい

10 やっぱし、スケールさせないとね！ ん！？

11 ということで、そろそろ本題！

12 ×

Lostash(ノード) 13 まずはシンプルに... input Firewall IDS/IPS WAF if 分岐 if 分岐 filter output filter処理1 filter処理2 filter処理3 filter処理1 filter処理2 filter処理3 Firewall ID/IPS filter処理1 filter処理2 WAF Elasticsearch filter { if "firewall" in [tags] { grok { match => { "message" => ... } date { match => ... } } if "ids" in [tags] { grok { match => { "message" => ... } date { match => ... } } ・ ・ ・ logstash.confの例

Lostash(ノード) 14 Multi pipeline機能を使ってみる input Firewall IDS/IPS WAF filter output filter処理1 filter処理2 filter処理3 filter処理1 filter処理2 Elasticsearch input input output output filter filter filter処理1 filter処理2 filter処理3 - pipeline.id: firewall pipeline.batch.size: 125 path.config: "/etc/logstash/conf.d/firewall.conf" pipeline.workers: 1 - pipeline.id: ids pipeline.batch.size: 125 path.config: "/etc/logstash/conf.d/ids.conf" pipeline.workers: 1 - pipeline.id: waf pipeline.batch.size: 125 path.config: "/etc/logstash/conf.d/waf.conf" pipeline.workers: 1 pipeline.ymlの例 id: firewall id: ids id: waf

15 Fargateにすることでスケールを手に入れる Images タスク(Logstash) input filter1 filter2 filter3 output サービス: Firewall タスク(Logstash) input filter1 filter2 filter3 output サービス2: IDS タスク(Logstash) input filter1 filter2 filter3 output サービス3: WAF タスク 定義 タスク 定義 タスク 定義 Fargate 設定 ファイル 設定 ファイル 設定 ファイル ①ぷっしゅ ②さくせい ③きどう ④よみこみ ⑤とりこみ Elasticsearch Firewall IDS/IPS WAF

Logstash 16 世の中そう簡単にはいかないらしい(;´Д｀) ログ保存先 (S3) Backup先 (S3) input s3 メモリキュー EVENT EVENT filter ファイル処理 オブジェクトリスト (key名で昇順ソート) ログ処理 オブジェクト ファイル /tmp/logstash オブジェクトコピー処理 オブジェクト削除処理 ローカルファイル削除処理 ①オブジェクトリスト生成 ②オブジェクトリスト 単位でダウンロード ③イベント格納 ④s3.copy_object ⑤オブジェクト削除 AWS API (COPY) オブジェクトリスト毎に ログ処理実行 ⑥ローカルファイル削除 ※②失敗時も実行 Fargateのタスク並列処理で一番最初に 処理が完了したLogstash以外は ローカルが削除されずに蓄積されてしまう (並列処理を前提にした作りではない...)

17 並列分散しても同じ処理の重複がはげしかった Logstashタスク1 filter1 Elasticsearch filter2 filter3 filter4 output Logstashタスク2 filter1 filter2 filter3 filter4 output Logstashタスクxxx filter1 filter2 filter3 filter4 output ・ ・ ・ CPU使用率 取り込むファイルサイズを小さくしても、Logstashのポーリング間隔次第で 多くのログデータにおいて重複処理してしまい、無駄なログのDDoS攻撃状態... ログDDoS攻撃(笑) 重複処理 ログ (10MB)

Logstash タスクストレージ (10GB) 18 さらにストレージにWriteしてしまっているのも良くない ログ保存先 (S3) input s3 メモリキュー EVENT EVENT filter オブジェクト ファイル /tmp/logstash Elasticsearch output elasticsearch Dead Letter Que ファイル /var/lib/logstash/dlq Write/Read Write

19 【参考】Fargateのタスク制約 No CPU メモリ ストレージ 1 0.25 vCPU 0.5GB、1GB、および2GB 10GBのDockerレイヤーストレージ ボリュームマウント用にさらに4GB 2 0.5 vCPU 1GB～4GB(1GB単位) 3 1 vCPU 2GB～8GB(1GB単位) 4 2 vCPU 4GB～16GB(1GB単位) 5 4 vCPU 8GB～30GB(1GB単位) 参考1: AWS Fargateの料金 https://aws.amazon.com/jp/fargate/pricing/ 参考2: Fargateタスクストレージ https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/fargate-task-storage.html

20 ElasticStack on AWSだとこうなるのか... Kinesis Elasticsearch (3ヶ月) Fargate (Back) Fargate (Front) 生ログ NLB S3 Bucket (Data Lake) リスナ Filebeat Logstash Logstash Index オンプレ環境 AWS環境 加工処理 Index’ ③ S3 Bucket (12ヶ月) Snapshot Security Analysts Kibana 生ログ Filebeat 加工処理 エンリッチ 処理 生ログ Filebeat Dead Letter Que Logstash (EC2) ② ① エンリッチ処理 Prefix 【凡例】 Curator Elasticsearch (フォレンジック用) Index’ Curator Kibana Daily Daily インシデント対応時 Logstash (EC2) Lookup DB Stream Kinesis Data Streamsを利用して ETL処理を行うFargate(Logstash)の リソースを無駄なくスケールさせる。

21 まとめ ✓ EC2の管理不要で嬉しい！でも、4vCPUだとつらたん(*´ω｀) ✓ S3-input-pluginとFargateとの相性があまり良くなかった... ✓ 次回はAmazon EKSを評価してみるべし！

ご清聴ありがとうございました