AWSに集まったログをどう分析するか　NTTドコモのエンジニアが教えるサーバーレスなログ分析基盤

AWSのサーバーレスサービスでセキュリティのログ分析

千田拓矢氏：それでは始めたいと思います。AWSのサーバーレスサービスでセキュリティのログ分析をしようという話です。

簡単に自己紹介します。千田と申します。NTTドコモのサービスイノベーション部というR&Dの部署に所属していて、5年目社員です。

基本的に普段の業務では、クラウド、AWS、GCP、Azureのセキュリティに関わる仕事をしています。機械学習もちょっとわかるくらいに勉強していて、その関連でFPGAとかGPUみたいなハードウェアの知識もちょっとあります。趣味はビールとサウナとペンギン。

ということでよろしくお願いします。

本日話すことは、大きくこの3つです。まず最初にAWSのセキュリティのログ分析の課題について話をしたいと思います。次にサーバーレスのログ分析って一体どういうものなのかといういうことを簡単に説明します。

最後にちょっとダッシュボードのデモをします。実際の生ログを出すのはセキュリティ的に厳しいので、代わりにいくつかダッシュボードを紹介して、雰囲気だけ味わってもらおうかなと思っています。

ログ分析の構成

それでは始めていきたいと思います。突然ですが、このスライドを見たことありますかね？　AWSのTwitterとかブログとかでよく紹介されているんですけど、AWSのセキュリティで重要なポイントを10個集めたものです。

よくある話なんですけど、CloudTrailのログは1つのアカウントに集約すべしというノウハウがあります。この6番目です。これを見て、なるほどそうなのかと思ってログをどんどん集約していくと、いつの日か、集めるのはいいんですけど誰がどうやって分析するのだろうかっていうことを……。そこらへんの情報があまりないということに気づくと思います。

複数のAWSのアカウントがあってログを集約する場合は、だいたいこのようなLoggingアカウントを作ってログを集める用のS3のバケットがあるという、こういう図になると思います。

こうした組織レベルのログ分析では、集約したログに対して本格的な基盤プロダクトを用意して、セキュリティの知識の豊富な専門家たちが分析するというケースが想定されると思います。

ログを見る上での課題

その場合、いくつか課題が出てきます。ログの量が大量になるので、分析すべきログの量も膨大で、セキュリティの分析する人たちにものすごく負担がかかります。図ではアカウントは3つですが、本来なら何十個も増えるというケースが考えられます。

にもかかわらず、この人たちは各アカウントの事前知識というか、このアカウントにはどんなチームメンバーがいてどんな環境を作っているのかということを、いちいち把握するのってけっこう難しいと思うんですよね。

そういったドメイン知識がない。AWS、ほぼいろんなサービスの全般の深い知識が必要とされる。ということで負担が大きい。

それからアプリレベルとかOSレベル。とくにCloudWatch Logsは、集約しようとすると、かなり複雑になるし手間もかかるし、サービスが新しく出るたびにいろいろ設定が必要だったりして、ちょっと管理が複雑化してしまうという問題もあります。

そういうふうに考えていくと、もう少し開発現場に寄り添ったような近いところで分析できるような環境のほうが実践的じゃないのかなという気がしてきます。

というわけで、より現実的なログ分析は、こういう構成になるのかなというふうに考えられます。さっきと違うのは、組織レベルの分析をAWSのサービスでやっていることです。今AWSのサービスは、けっこうセキュリティのサービスがバンバンリリースされているので、自動化がうまいことできるようになってます。

これを使えば、先ほどのセキュリティの専門家のチームがやってる業務をなんとかできるだろう、代わりになるだろうということで。ログではなくてGuardDutyとかconfigの検知結果、findingsを集約して、それを見るようにすればいいんじゃないかなということで、それを代わりにします。

残りの細かいログの分析は、各アカウントで開発現場に近いところで行うことでアプリのログとかOSログとか、とくにCloudWatchのログを合わせた詳細な分析が可能になる。そういうのが現実的かなと思います。もちろんケースバイケースです。

このようにアカウントレベルでログ分析が必要だということには、大きくポイントが3つあります。組織レベルの分析はサービスに任せればよい。実際の開発現場に近いところではドメイン知識に基づいた分析をしたほうがセキュリティ的にはよい。ログの管理をシンプルにする。こういうわけです。

サーバーレスを使ったログ分析の考え方

ちょっとここでひと段落というか、ざっくりとわかりやすくまとめます。組織レベルのログ分析は、専門アカウントで専門のチームが特定のログを本格的に分析する。それに対してアカウントレベルのログ分析では、どこでも、誰でも、あらゆるログを気軽に分析する。

ラーメンで言うと、お店で出るような本格的なラーメンと、カップラーメンのようなインスタントラーメンのような、こういうスタイルが適しているのかなというふうに考えられます。DevOpsの時代なので、セキュリティのログ分析環境もちょっと手軽に、開発のサイクルが早くなるようなものが必要なのかなというふうに考えられます。

では改めてインスタントラーメンのような分析スタイルには何が必要なのかということなんですけれども、大事なのはこの3つ。第一にサーバーレスであること。ここは重要ですね。アカウントごとに分析するので、安くてメンテナンスが楽。とはいえそこそこ性能がほしいというと、サーバーレスしか選択肢はないんじゃないのかなと思います。

次にできればAWSだけで構築できること。AWS純正なら、アカウントを作成したその日すぐに環境構築に着手できて導入もスムーズにできる。CloudFormationでテンプレート化しておけばそのまますぐに自動的にデプロイもできる。そして請求がまとまるのも地味に嬉しいところかなと思います。

最後に可能であればなんですが、機械学習があると、より今どきというか、ベターかなと思います。クラウドでは毎年新しいサービスがポンポン出てきて、ログの質も量もどんどん複雑化、肥大化していきます。アカウントレベルで分析するとなると、人手をあまりかけたくないので、できるだけ自動化していきたいというのが狙いです。

サーバーレスで実現する基本アーキテクチャ

そういうサーバーレスのAWSだけのログ分析基盤をどう作るのかというのを説明していきたいと思います。ログ分析の勉強会なので知ってる人が多いと思うんですけど、基本的にサーバーレスでログ分析、AWSで言うとS3→Glue→Athena→QuickSightの構成がわりとメジャーかなと思います。ほぼ鉄板だという感じですね。ここでは前処理用にLambda、機械学習用にSageMakerを利用します。

対象ログはGuardDutyとそれに付随するような感じでCloudTrailとVPCフローログ、あとはWAFとかCloudFrontとかELBとか。実際これ以外でもCoast and Usage Report（コストと使用状況レポート）とか、S3に入るものだったらわりとなんでも分析可能です。

環境構築に関しては＜CloudFormationでテンプレート化して、各アカウントに配布してすぐにログ分析環境をデプロイするようなかたちです。

全体のアーキテクチャはシンプルですけどこんなかたちで、いろんなログをS3に集約して、前処理用のLambdaが動いていて、Athena、QuickSightでテーブル化、可視化して。ここらへん機械学習をちょっと活かしながら異常検知みたいなことをするという感じですね。

ログ集約のパターン

順番に見ていきたいと思います。AWSのログの基本というか、おさらいになるかもしれないんですけれども、だいたいS3に集約するパターンと、CloudWatch Logsに集約するパターンの2通り考えられます。

S3に集約するログは、基本的にはAWSの、どちらかと言うとインフラに近いものが多いです。保存重視しているということで静的なログが多いですね。こういうのはAthenaとQuickSight、さきほどの鉄板の構成で分析できます。

CloudWatchのほうは、どちらかと言うとユーザーのアプリケーション層に近いような、EC2のCloudWatch Agentのログとか、あとはコンテナから出てくるログとか、そういうものが多いです。ここらへんはリアルタイムな監視を重視しているものが多くて、セキュリティというよりはパフォーマンスの監視がメインかもしれないです。

究極CloudWatchのログってS3にエクスポートできるんですけど、EC2の表示の出力とかS3にどんどんどんどん吐き出しても逆に面倒なことになりそうなので、ここらへんはもう割り切って、コンソールの画面とかInsights、あとはいろいろツールがあるのでそこらへんでがんばるという作戦でいきたいと思います。

S3に保存するときのprefixを適用にしない

S3のログをどうやって分析するのかを、このあと中心に話題にします。

S3にログを集約しようという話ですが、ちょっと注意点があります。S3にログを出力するときに、だいたいprefixを入力できると思うんですけれども、ここをちょっと考えてもらうと、みなさん適当に作ったりしていませんかね？

最初よくわかんなくて適当に好きな日付とか……。あんまり日付入力する人はいないと思うんですけども（笑）、適当にバラバラに入力していくと、きちんとフォルダの階層が分かれないという結果になります。

prefixをうまく設定すると、ちゃんとAWSLogsのあとにAccountIDがあって、Service名、region、そのあとyyyy、mmddみたいな感じでフォルダがきれいに分かれてきます。

個人的にはprefixは、あんまり付けないほうがいいんじゃないかなと思います。prefix付けるくらいだったらバケットを分けたほうがうまく管理できるような気がします。まあここは個人的な話なのでケースバイケースです。

参考にちょっといろんなログの格納パスを載せておきます。見てわかるとおり、グローバルのサービスってけっこう適当にS3にボンって格納されちゃうので、ここはprefixに工夫が必要です。

パーティショニングして分析時間を短縮する

次にLambdaによる前処理の話です。だいたいパーティショニング処理と機械学習向けの前処理とその他メタ情報付与みたいな3つあるんですけれども、本発表時間的には全部紹介できないので、パーティショニングだけ説明します。

パーティショニングって初めて聞く人もいるかもしれないですけど、大きなテーブルを小さく分割して分散処理の効率を向上させるような処理で、Athenaではよく、というか、必ず出てくる処理です。

クラウドのログはデータ量が膨大になりがちなので、Athenaでテーブル化したときにすごく巨大なテーブルができてしまうことが多いです。なのでパーティショニングが、かなり重要になってきます。

パーティショニングするとスキャン範囲を絞り込むことで時間の短縮になるし、Athenaってスキャンのデータ量に対して課金されるので、利用料の節約にもなります。このURLがけっこうわかりやすく図解されているのでおすすめです。

実際に具体例を見るとわかりやすいと思うんですけど、パーティショニングなしでCloudTrail1日分のログデータをスキャンする場合は6分21秒かかって、データが100ギガ。もしかしたらこれ頭打ちというか、制限があるのかもしれないですけど。100ギガかかりました。

パーティショニングありの場合は26秒で、データスキャンは146メガバイトということで、ほぼ1000倍くらい違う。僕の手元ですけど、こういう結果ができました。コストにかなり響いてくるので、パーティショニングは必ず行う必要があります。

これパーティショニング……だんだんマニアックになってきますが、こういうクエリ文を毎回Athenaで実行しなきゃいけないんですけど、面倒くさいので、LambdaでCloudWatch Eventで毎日1回自動的に実行するようにします。

4月1日のログに対してパーティショニング処理したい場合は、4月2日。4月1日が終わってからクエリ文を実行すると。このロケーションというかS3のこれ以降にあるファイルに対して全部パーティショニングが入るようなかたちです。

これを全部Lambdaで自動化して各ログに対して処理をしていくというふうになります。ここでS3のprefixが汚いと、Lambdaのコードももれなく汚くなってしまうので苦労すると思います。

分析の可視化

ちょっといろいろすっ飛ばしてるんですけど、これが実際のダッシュボードの画面です。左がGuardDutyのfindingsを可視化したもので、これをもとにCloudTrailのログを詳しく見ていくようなフローです。実際GuardDutyは、けっこう誤検知も多いので、ドリルダウンして、この人はここでログインしてるけど大丈夫かなみたいな。こういう感じで使います。

機械学習系の機能も充実してきたんですけど、いまいちコスパ的にいいのか悪いのかちょっとわからないので、ログがそんなに溜まってない人だったらあんまりよくないかもしれないです。