技術部セキュリティグループの水谷です。

先日、Twitterに投稿もしたのですが、AWSのThis is My Architectureという事例紹介のシリーズでクックパッドが取り組んでいるセキュリティログ管理基盤の紹介ビデオが公開されました。この記事ではビデオの内容の補足、そして撮影の様子などを紹介したいと思います。

AWSの This is My Architecture という事例紹介シリーズで、S3を中心としたセキュリティログ管理基盤のアーキテクチャの説明をさせていただきました。

Cookpad: Security Architecture to Monitor and Analyze Secure Logs using ... https://t.co/MMEcblCBhs@YouTubeより

— Masayoshi Mizutani (@m_mizutani) 2020年10月15日

This is My Architecture とは？

AWSにおいて事例紹介となるようなアーキテクチャを構築・運用しているユーザが、自分たちのアーキテクチャを5分ほどのビデオで紹介するシリーズです。様々な分野で活躍しているユーザとAWSのアーキテクトの方と一緒にアーキテクチャを紹介する、という形式になっています。

aws.amazon.com

今回クックパッドでもオファーをいただき、社内でいくつかあった事例の中でセキュリティログ管理の話が紹介としては良さそうということで、私がAWSの桐山さんと共にビデオ撮影させていただきました。

動画の撮影

ここからは動画撮影に関するよもやま話をお伝えしようと思います。

撮影まで

この This is My Architecture の動画は毎年年末にラスベガスで開催されている¹AWSのイベント re:Inventの会場で撮影されています²。そのため、この動画も撮影したのは実は去年のre:Invent（2019年12月）でした。

しかし、諸般の事情により私が現地に行って撮影する、というのが正式に決まったのが11月5日で、そこから超特急で渡航手配³や発表準備に取り掛かりました。10月にはre:Inventの参加するとは露ほども考えていなかったので、なんとか間に合ってよかったです。

原稿の準備

撮影準備で大変だったのはまず原稿の準備です。撮影をするうえで原稿を事前に用意しないといけないというルールがあったわけではないのですが、今回は英語で話すということと発表時間の制約が厳しい（原則5分以内）ことから、発表内容は全て原稿を用意しました。

このブログの後半に補足として書いていますが、今回のアーキテクチャとして伝えたいことはいろいろありました。なので、最初はもりもりの原稿になってしまい、かなり早口で説明しても2〜3分ほどオーバーしていた記憶があります。

そのため、このアーキテクチャの本質として伝えたいことに要点をしぼり、何度も推敲を重ねて実際に撮影に使用したバージョンまでブラッシュアップしました。特に私自身は英語が全く得意ではないので、わかりやすく丁寧に発音するためにはゆっくり喋れるような余裕が必要でした。そのため、さらに尺に余裕が出せるように原稿を短くしていきました。

発表練習

原稿の準備と並行して、発表練習も11月中にかなり時間をとって取り組みました。

写真はAWSオフィスにて、実際の撮影時にある黒板をホワイトボードで想定しつつ、説明の手順を確認したり、発表原稿の読みあわせをしたときのものです。先に述べたように、私は英語がだいぶ苦手な部類だったため、流暢に話せるようにということも含めて練習していました。

発音に関しては（出来はさておき）かなり事前に確認しました。やはりどうしても日本人発音になってしまいがちなので、何度かネイティブスピーカーの人に発表を聞いてもらい、聞き取りづらいところなどをチェックして発音を修正する、というのを繰り返しました。また、自分が発音しづらかったりネイティブスピーカーの人に聞き取りづらいような単語は避け、別の単語に置き換えるような修正もしました。特に数字については結果を示すために非常に重要な要素にも関わらず、なかなか正確に聞き取ってもらうのが難しかったので、ボードに直接書く＆特にはっきり話す、という作戦でいきました。

また、原稿準備のところでも触れましたが、今回は時間の制約が厳しかったことなどから発表原稿は一言一句丸暗記しました。英語でも日本語でも完全に丸暗記して発表するというのは実は初めての体験だったため、11月は暇さえあれば原稿をブツブツつぶやいていたなと記憶しています。

撮影本番

12月5日の朝（現地時間）から撮影でした。この前日は時差ボケ⁴と緊張で見事に一睡もできなかったのですが、意外と元気に撮影できました。

撮影はre:Invent会場の一部が撮影専用のスタジオとなっており、そこで撮影してもらいました。This is My Architectureのページを見ていただくと分かる通り、かなりの数の事例紹介があるため、各チームが入れ替わり立ち替わりで撮影していました。

ボードを用意してくれるスタッフの方にアーキテクチャ図の説明をしたりしつつ、その場でブラックボードに書き込みをしてもらうなど準備をして、撮影に突入しました。

かなり入念に準備したかいあって、撮影自体は非常にスムーズに終わりました。一応、スタッフの方からは一発OKをもらったのですが、ちょっと言いよどんでしまったところもあったので英語版をもう一度だけ撮影し直して完了できました。

さらに「時間余ったからせっかくなんで日本語版も撮ろうか？」みたいな話になり急遽日本語版も撮影することになりました。過去のThis is My Architectureをざっと見た限り二ヶ国語で別々に撮影されたものはほぼ無さそうで、おそらくかなりレアケースだったようです。おかげで日本語版も撮影させてもらったのですが、それまでずっと英語で話していた内容で全く日本語版を想定していなかったので、撮影中は必死に英語から日本語に翻訳して喋っていました。

完成動画

ということで完成した動画がこちらとなります。動画の編集や公開のタイミングなどの問題で、最終的に公開されたのが少し遅くなってしまいましたが、無事公開していただきました。

英語版

www.youtube.com

日本語版

www.youtube.com

（動画の補足）S3を中心としたセキュリティログ管理基盤

今回撮影した動画は5分以内に収める＆使えるアーキテクチャ図も限られていたため、詳しい説明を大幅に削ってエッセンスだけを話させてもらいました。（原稿の推敲にはだいぶ苦労しました）なのでこのブログで少し内容を補足させてもらえればと思います。ちなみに、この話はかなり前から取り組んでおり何度か講演やブログでも紹介させて頂いたものなので、それらと重複する部分がかなり含まれる点はご容赦ください。

https://techlife.cookpad.com/entry/2018/05/31/080000

過去の記事でも紹介したとおり、クックパッドではセキュリティ監視に使うログを全てS3に保存してから利用する、というアーキテクチャを採用しています。

従来、セキュリティ関連のログ管理ではSIEM（Security Information & Event Manager）などのログ管理ソリューションが用いられて来ました。細部は製品やサービスによって違うものの、大まかな発想としてはログを直接取り込んでアラートを検出するフローとログを保管するフローを別々に扱うものが多かったと思います。このアーキテクチャの利点は、取り込んだログをなるべく早くアラート検知に利用することで発報までの遅延が短くなることです。しかし一方で以下の2つの課題を抱えています。

1. 障害対応時の対応負荷：センサーからのログ送信経路やアラート検知・ログ保管側のシステムに障害があった場合には対応・復旧作業が必要になります。再度センサーなどからの取り込みをしないとログが欠損してしまいますが、ログの取り込み元の数が多くなるほど対応の工数が大きくなります。また、各センサーで大きくバッファを持たないとログが消失する可能性もあります
2. ログスキーマ管理の難しさ：利用するログの種類が多くなるとログのフォーマット、スキーマ管理も大きな課題になってきます。アラート検知やログ保管をする際にはログのフォーマットやスキーマを解釈して処理をする必要がありますが、これを事前に設定しておかないと取り込みに失敗します。失敗後のリトライで再度ログを送信する必要がでてくると、これもトラブル対応と同様にログの欠損や消失を防ぐための負荷が大きくなってしまいます。

この問題を緩和するために、クックパッドのセキュリティログ管理基盤ではアラート検知やログ検索のフローを実行する前に「S3にログを保存する」というレイヤーを挟んでいます。S3はバケット上にオブジェクトを作成された際、即座にそのイベント情報をSNS (Simple Notification Service) などへ通知する機能があります。これを使ってS3へのログデータ到達とほぼ同時にアラート検知のためのプロセスを発火させたり、検索システムへログデータを転送させることができます。検索システムへのログデータ転送は、先日AWSのブログで紹介されていたAWS サービスのログの可視化やセキュリティ分析を実現する SIEM on Amazon Elasticsearch Serviceでも同様のアーキテクチャが採用されています。

このアーキテクチャの利点

先の述べた課題である 障害対応時の対応負荷および ログスキーマ管理の難しさが軽減されるのが、まず1つ目の利点です。利点として一見地味なのですが、継続して運用をすることを考えると、これらの負担軽減は大きな意味を持ちます。

S3は高い可用性を持っており、多くの場合自分でストレージを運用するのに比べてトラブルが少なくてすみます。そのためセンサーからS3へ「とりあえず」ログを投げ込んでおくことで欠損のリスクを大幅に小さくすることができます。また、S3に保存された後の処理が失敗しても、再度S3のオブジェクト生成イベントを流すことで容易に後続の処理を再開することができます（ただしこれは後続の処理が冪等になるよう設計されている必要はあります）。

ログスキーマ管理の観点では「センサーがログを送ってきたタイミングでスキーマが完璧に定義できている必要がない」というのが大きな利点になります。センサーのログを受け取った時点でパースするようなシステムの場合、送信の前に完璧にパースできるようスキーマの把握をしてパーサーを用意しておく必要があります。もしパースに失敗した場合はセンサー側から再送が必要になってします。しかしS3に保存する際にはスキーマは全く関係なく、もしパースに失敗してもS3から処理を再開できます。到着するまでスキーマがはっきりしないようなログでも、S3のオブジェクト生成イベントを一時的にどこかへ退避させることで、到着してからパーサーの準備をするということも可能です。

他にも、安価にログを保存できるS3でログ保管ができる、という利点があります。SIEMなどログ保管・検索を同じアーキテクチャに持つものだと、ログを保持するための料金が比較的高くなってしまいます。保管と検索を同時にしているため、保持しているログなら容易に検索できるメリットがある反面、ストレージ本体やストレージを動かすためのインスタンスないし筐体のコストが高価になりがちという問題があります。S3はデータの保存料金が非常に安価に抑えられておりコストメリットが大きいだけでなく、トータルの保存容量の制限もないためにストレージの残り容量を夜な夜な気にする必要もありません。ライフサイクルマネジメント機能を使って自動的に長期的に保存するのにも向いています。

このアーキテクチャの欠点

従来のアーキテクチャと比べたときに、S3を中心としたアーキテクチャの欠点として挙げられるのは、センサーからアラート検知やログ検索のシステムへログが到達するまでの遅延が発生することです。これはS3がオブジェクトストレージであるため、ログをなるべく細切れにせずにある程度の数を1つのオブジェクトにまとめたほうがリクエスト数が減ってコストメリットが出るためです。また、あまりにリクエスト数が多いとAPIの呼び出し制限にひっかかる恐れがあります（参考）。こうしたことから、センサー側で少しログをためた後にS3へアップロードするため、ログを貯める時間がそのまま遅延になります。この遅延がどのくらいになるかはログの流量やセンサーの能力や性質などに依存するため一概には言えませんが、筆者の経験則からするとおおよそ1〜2分、最大でも5分程度になるように各種設定するのが良いと思われます。

ここで問題になるのが、1〜2分ほどの遅延がセキュリティログの利用にどのくらいの影響を及ぼすのか？ という点です。例えばManaged SOCのようなビジネスをしていたり専属の24/365体制なSOCを持つような組織の場合は、アラートが上がった場合に即応する体制が整っており、1〜2分の遅延を削ることに意味があるかもしれません。しかしそうでない場合は必ずしもアラート検出から1〜2分で対応できるとは限らず、遅延が致命的になるとは想像しにくいです。また、Managed SOCでもアラート発生から対応するまでのSLA（Service Level Agreement）が設定されている場合がありますが、最短でも15分程度です。その中の1〜2分であれば、多くの組織の場合許容できるのではないかと考えられます。クックパッド内でもこのような基準をもとに考え、多少の遅延は許容できると判断しました。

分析パートについて

この動画を撮影したのが実に1年前なので、分析パート（ボードのANALYSISの部分）について少し補足です。

アラートの検知については引き続きLambdaを使い、ログの中からアラートとして扱うべき事象の抽出をしています。アラート発報後の対応のフェイズについては サーバーレスで作るセキュリティアラート自動対応フレームワークで紹介しております。

また、ログ検索については動画中でgraylogを使っていると話していますが、その後Athenaをベースとしたセキュリティログ向け全文検索システムminervaに移行しており、graylogは退役しています。こちらについてはAmazon Athena を使ったセキュリティログ検索基盤の構築でも紹介しておりますので、よろしければあわせて御覧ください。

まとめ

最初、この撮影の話を聞いたときは「まあ5分喋るくらい大したことないでしょ」とか軽く考えていたのですが、正直な感想として想像の100倍くらい大変でした。しかし、撮影準備の過程で自分の作ったアーキテクチャについていろいろな人と議論できたり、その本質について考えさせられるなど良い経験もさせてもらいました。なにより、動画という良い形で成果を残せたことは、とても良かったと思います。この機会を提供してくれた＆協力してくれたAWSの方々、そして桐山さんに改めて御礼を申し上げたいです。

少し話が変わりますが、クックパッドのセキュリティエンジニアはこのような自分たちが必要とする仕組みを自分たちで考え、組み立て、現場に活かしていくというのが役割の一つになっています。先日、CODE BLUE 2020でもこのような話をさせていただいたのですが、情報セキュリティの課題を知識や経験だけでなくエンジニアリングで解決していく、というのはとても刺激的で、私自身はとても楽しんで仕事をしています。しかし現状、一緒にチャレンジしてくれるメンバーが足りていないこともありセキュリティエンジニアのポジションは引き続き募集しています。もし興味のある方がいらっしゃいましたら、まずはzoomなどでカジュアル面談して実際どうよ？という話もできるかと思いますので、ぜひお気軽にお声がけください！