CloudTrailのセキュリティ監視をちょー簡単にやってみた【Sumo Logic】
こんにちは、臼田です。
皆さん、セキュリティ対策で疲弊してないですか？
今回は面倒なCloudTrailのセキュリティ監視をちょー簡単にやってみたいと思います。使うのはSumo Logicです。
これからなんで大変なのか、なんでSumo Logicを使うといいのかというゴタクをつらつら並べますので、知ってるよって方は後半の「やってみた」部分まで飛ばしてください。
CloudTrailの必要性
AWSインフラの管理において、CloudTrailの有効化はすべてのユーザにおいて必須と言っても過言ではありません。
CloudTrailはAWSサービスのすべてのAPIコールを保存するサービスです。どのユーザがいつ・何をしたかを把握できるので、セキュリティ分析・トラブルシューティングを始めユーザとリソースのアクティビティの可視化、コンプライアンスの簡素化等に利用できます。
その中でもセキュリティ分析は重要な要素の一つです。IAMユーザやアクセスキーが不正に利用されていないか、EC2やセキュリティグループの操作が正常か、S3で不用意に公開されているファイルがないか、CloudTrailを監視することにより確認できる項目はたくさんあります。
AWSから提供されているAWS_Security_ChecklistでもCloudTrailの利用が求められています。
CloudTrailを監視する大変さ
しかしながら、CloudTrailの監視は簡単ではありません。記録されるログの量は膨大で、フォーマットはjsonであるため、生のログを追うことは愚の骨頂です。
マネジメントコンソールからフィルターをかけることはできますが、一つのkeyとvalueに基づくものでかなり簡易的です。暫定的な確認用で、よりしっかりした監視や分析には別のソリューションと組み合わせる必要があります。アカウントやリージョンを跨ぐ場合もマネジメントコンソールからの確認は向きません。管理しているAWSアカウントが多くなるほど、CloudTrailを監視するための仕組みが必要になるでしょう。
また、様々な種類のAPIコールのログが混ざっています。どのAPIのどの値が必要な情報なのか、どの値とどの値を並べてみればいいのか等、ログの分類や集計方法についても熟知する必要があり、手軽に監視を始めることはできません。
Sumo Logicのメリット
Sumo Logicはクラウドネイティブなログ分析のSaaSで、AWS関連のログもすぐに取り込んで分析を始めることができます。
今回取り上げるCloudTrail以外にも、ALBやCloudFront等様々なログを取り込んですぐに可視化・分析を始めることができます。一番いいところは各サービスで必要な分析手法がすでにプリセットとしてダッシュボードに用意されていることです。そのおかげで、どのログから見たらいいかわからない、どういう集計をとったらいいかわからない等の問題はなく、簡単に始めることができます。
やってみた
アカウントの作成からログの取り込みを行ってダッシュボードを作成します。他のブログで知ってるよって方はダッシュボードの説明まで飛ばしてください。
アカウント作成
まずはSumo Logicのアカウント作成からです。フリートライアルで30日間使えるのと、その後もフリープランで継続して利用することが可能です。
Sumo Logicのホームページの右上「Sign Up Free」を押すとフォームが出るので、メールアドレスを入力して、ロケーションはJapanはないので何でもいいですが今回はデフォルトのNorth Americaとし、プランはどれを選んでも30日無料であることは変わりませんが「Sumo Logic Free」を選択しておきます。
メールが届くのでActivateします。
CloudTrail取り込み
ログインしたらセットアップウィザードが上がるので「Set Up Streaming Data」を選択します。
データタイプの選択画面になるのでCloudTrailを選択します。
CloudTrailのログを取り込むための設定画面になります。1つ目の「Source Category」はSumo Logic上の分類なのでデフォルトのままで大丈夫です。2つ目のIAMユーザーのアクセスキーやS3の情報を入力する画面では、まずCloudTrailのログが保存されているS3のバケット名とパスを設定します。リージョンはTokyoがないのでOthersで大丈夫です。
入力したバケットとパスの内容に基づいたS3のバケットポリシーがその下に表示されますが、これはIAMポリシーとしても使い回すことができるので、これをコピーしてIAMポリシーと、それを適用したIAMユーザーを作成します。
AWSマネジメントコンソールからIAMポリシーの画面に移動し、「ポリシーの作成」を押し、作成画面で「JSON」タブからコピーした内容を貼り付け作成します。ポリシー名は適当に「sumologic_s3_policy」等で作成します。
続いてIAMユーザーを作成します。適当なユーザー名を入れ「プログラムによるアクセス」を選択して次に進みます。
ポリシーは作成済みなので既存のポリシーからポリシー名で検索して、先ほど作成したポリシーにチェックを入れて次へ進みます。確認が出るので作成します。
作成したらアクセスキーとシークレットアクセスキーを控えます。Sumo Logicの画面に戻って入力し、「Continue」を押します。データの取り込みが始まるのでしばらくそのまま待ちます。
ログの取り込みが完了するとダッシュボードを表示することができます。ちなみに、複数のリージョンやアカウントのログもセットアップウィザードを使って取り込めば同じ画面で見ることもできます。
ダッシュボード一覧
Sumo LogicのCloudTrailApp(プリセットのCloudTrail用ダッシュボード)として6種類のダッシュボードが利用できます。
このダッシュボードを最初から利用できるところがSumo Logicの魅力の一つなので、それぞれの使い方を掘り下げて解説したいと思います。
ダッシュボードの種類は下記のとおりです。
- AWS CloudTrail - Overview
- CloudTrailの中で特に重要なログイン周りやリソースの削除等を表示します。
- AWS CloudTrail - Console Logins
- ログインしているユーザのロケーションやMFAの利用状況、ログイン失敗等を表示します。
- AWS CloudTrail - User Monitoring
- ユーザのアクティビティやAdminユーザのアクティビティが確認できます。
- AWS CloudTrail - Network and Security
- リソースへのアクセス失敗やNetworkALC・SecurityGroupの変更などの変更が確認できます。
- AWS CloudTrail - Operations
- どのAWSサービスやリージョンからAPIが呼ばれているかや、リソースの追加削除が確認できます。
- AWS CloudTrail - S3 Public Objects and Buckets
- 公開されたバケットやオブジェクトが確認できます。
各ダッシュボードを見ていきましょう。
Overview
Overviewは特に重要な項目が集まっていますが、まずはダッシュボード自体についても解説していきます。左のカラムに追加されたダッシュボードが表示されています。ダッシュボードを選択すると画面上部のタブに追加され、タブを切り替えることによりダッシュボードの表示が切り替わります。タブにはダッシュボード以外にもログ検索などもあり、個別に追加したり、お気に入り登録したりできます。
各パネルの表示を順に見ていきましょう。まずはGeo Location of All Usersです。
これはTrailに保存されているAPIがどこから呼ばれているかをGeo情報を元にマップに当てたパネルです。通常とは違う場所からAPIが呼ばれていたら一発でわかります。(私の場合は各リージョンのAWS Configからのアクセスがあるためいろいろなところから来ているように見えます。)
MAPは拡大することもできるので、日本国内のどこから来ているかもわかりやすいです。
お次はTop 10 Usersです。ほとんど塗りつぶしてしまいましたが各IAMユーザー名が書かれています。ユーザーあたりのAPIコール数のランキングで、今回はSumo Logicの検証をしすぎてsumologicのユーザがダントツになっています。通常ではどのユーザーが一番アクティブに動いているかわかるので、例えばアクセスキーの漏洩があったときには手当たり次第いろんなAPIが呼ばれていることをここで検知することもあるでしょう。
次にFailed Loginsです。単純にログインに失敗した数です。あんまりログインに失敗することは無いと思うので、カウントが上がるだけで要注意です。ここで各パネルの使い方も掘り下げておきます。右上に「Last 24 Hours」とありますが、これはクリックすると対象の時間軸を変更することができます。7日分見たり、逆に直近15分だけ見ることも可能です。
その隣のドキュメントマークを押すと、別のタブでこのログの検索結果が表示されます。
この画面はFailed Loginsのログ検索結果です。上部にあるのがクエリで、下部に結果が表示されています。クエリでcountしているので、「Aggregates」では3.00のみ表示されていますが、「Messages」を選択するとcountする前の該当ログが一覧で見れるので、実際にいつどのユーザーでLoginの失敗があったか確認できます。
ログ検索画面も、必要ないフィールドを非表示にしたりjsonも折りたたんでキレイに見ることができます。また、パラメータを選択してクエリに加えることも簡単なので、ダッシュボードから気になったものをこの画面で開いて、有用な情報を絞り込んでいくことも可能です。
ここのクエリは下記のような形です。ConsoleLoginイベントでFailureになっているという比較的わかりやすい内容ですが、こういうどのパラメータがどの値だと問題があるのかということを覚えるのに通常は時間がかかります。Sumo Logicではこのように事前に用意されているので、そのまま利用でき、学習コストも大幅に削減できます。
_sourceCategory=aws/cloudtrail ConsoleLogin Failure
| parse "\"eventName\":\"*\"" as eventName nodrop
| parse "\"responseElements\":{\"ConsoleLogin\":\"*\"}" as loginResult nodrop
| where eventName="ConsoleLogin" and loginresult="Failure"
| count by loginResult
残りのこれらの画面は各AWSリソースとSecurity Group / Network ACLの作成・削除です。いろいろ表示されていますが、本番環境だとあまりここは変わらないと思うので、何かが表示されたら要確認です。
Console Logins
AWSマネジメントコンソールへのログインに特化した画面です。人が意図的に操作しているので、管理外の場所からアクセスされることはあまりないのが通常です。Geo Locationの使い勝手はOverviewと一緒でLogin Events By UserやLogins Over Timeは時間あたりのログイン系のグラフです。重要になるのは左下のLogins from Multiple IPで、複数経路から同じユーザーがログインしているので、アクセスキーの漏洩が発生している可能性もあります。(ただ単に短時間で別ネットワークから利用している場合もありますが)
更に下にも項目があり、Logins Without MFAはMFAを利用しないでログインしているユーザーが確認できるので、これはすぐに是正する(MFAを必須にする)必要があるユーザーです。
User Monitoring
ユーザーのアクティビティが確認できます。左上はGeo、左下はTop10でこのあたりはOverviewにもあったものです。下の真ん中はユーザーごとのインスタンス作成、削除です。
右側の3つは通常のユーザーではなくAdminユーザーの動きになります。APIを利用している時間や、どのAPIを多く利用しているか確認できます。
こちらは個別にAdminユーザーをこちらの手順に従って登録する必要はありますが、強い権限を持ったユーザーの動きが問題ないか確認できます。
Network and Security
その名の通りネットワークとセキュリティのダッシュボードです。左側はAuthorization Failuresとなっていて、APIコールが権限がなく失敗しているものをGeoや時間軸で表示しています。たまに権限がなく失敗することはありますが、真ん中の時間軸のグラフで突出して多かったり、明らかにおかしいGeoから来ていたら確認したほうがいいです。
右側はNetwork・Securityと付くAPIを表示します。中央はNetwork ACL、中央右はSecurity Groupについてのイベントを表示しています。これらは日常的に変更されることは少ないので要注意です。
右下はShort Lived Critical Operationsで、短時間だけ存在していたユーザーやポリシーなどを表示します。検証用の一時的なものであればいいですが、攻撃者が気付かれないようにさっと作ってさっと消している可能性もあります。
こちらのクエリを見てみましょう。eventとしてIAM周りのイベントを取り、短時間のみで絞っています。こういった複雑なクエリも用意してあって頼もしいですね。
_sourceCategory=aws/cloudtrail (putuserpolicy or deleteuserpolicy or createuser or deleteuser or creategroup or deletegroup)
| parse "\"userName\":\"*\"" as user_name nodrop
| json field=_raw "userIdentity.principalId" as principal_id nodrop
| parse regex field = principal_id ":(?<user_principal>.+)" nodrop
| if (user_name="", user_principal, user_name) as src_user
| parse "\"eventName\":\"*\"" as event_name
| parse "awsRegion\":\"*\"" as aws_Region
| where event_Name in ("PutUserPolicy","DeleteUserPolicy","CreateUser","DeleteUser","CreateGroup","DeleteGroup")
| parse regex field=event_name "^(?<event_type>[A-Z][a-z]+?)(?<resource_type>[A-Z][A-Za-z]+)"
| if(event_Name in ("PutUserPolicy","DeleteUserPolicy"),"Short-lived User Policy Assignment","Other") as event_description
| if(event_Name in ("CreateUser","DeleteUser"),"Short-lived User Creation and Deletion",event_description) as event_description
| if(event_Name in ("CreateGroup","DeleteGroup"),"Short-lived Group Creation and Deletion",event_description) as event_description
| parse regex "\"requestParameters\":[\s\S]+?\"userName\":\"(?<dest_user>[^\"]+?)\"" nodrop
| parse "\"policyName\":\"*\"" as resource_name nodrop
| parse "\"groupName\":\"*\"" as resource_name nodrop
| if(event_type in ("Create","Put"),_messageTime,0) as start_messagetime
| if(event_type in ("Delete"),_messageTime,0) as end_messagetime
| sum(start_messagetime) as start_messagetime,sum(end_messagetime) as end_messagetime by src_user,dest_user,aws_region,event_description,resource_name
| where start_messagetime !=0 AND end_messagetime !=0 AND ((end_messagetime-start_messagetime)< 600000)
| fields -start_messagetime,end_messagetime
Operations
オペレーションではクリティカルな項目はそんなにありませんが、時間軸でどのような操作がされているかが主に確認できます。右側では時間軸ごとで上から、どのAWSサービスへのAPIコールが多いか、どのリージョンで呼ばれているか、作成と削除されたリソースについて確認できます。左側はどのイベントが多いか、左下にはどのEIPに関連したイベントが多いかが表示されます。EIPのイベントはあまり頻繁にはないので気にしたほうがいいかもしれません。
S3 Public Objects and Buckets
公開されているS3バケットやオブジェクトの情報がまとまっています。が、残念ながら私の環境では公開しているものがないので味気ないですが、バケットごとのオブジェクト操作数や、権限が変更されたオブジェクトが確認できます。このダッシュボードは通常S3バケットを公開していアカウントでは、誤って公開されていないかをすぐ確認でき、常時公開しているアカウントでは公開バケットの状態が確認できるため、どちらでも役に立つでしょう。
まとめ
Sumo LogicのCloudTrailダッシュボードについてがっつり説明しました。使い始めるのはちょー簡単でログを取り込む設定だけで終わり、その後多機能なダッシュボードで様々なセキュリティ監視を行うことができることが伝わったかと思います。
もちろんCloudTrailのログを手で頑張って分析してもいいですが、これだけ充実したダッシュボードがあるSumo Logicを利用しない手はないと思います。このダッシュボードで見る場所は沢山ありますが、逆にCloudTrailを分析するための手法が一通り揃っているので、Sumo Logicに任せてしまえば構築・検証などを通り越してすぐに1つのシステムで監視を始めることができるのはかなりのメリットだと思います。
ぜひこれを利用してAWS環境のセキュリティ監視を始めてみてはいかがでしょうか？
Sumo Logicのインフラ活用法セミナーやります！
ちなみに、2018年10月4日（木）にクラスメソッドの共催でSumo Logicジャパン社設立記念セミナーが行われます。Sumo Logicの特徴やAWSなどインフラへの活用方法をレクチャーする内容です。セキュリティ監視に興味がある方は、こちらのイベントもチェックしてみてください。
