ごあいさつ

　AWS管理者の皆さま、こんにちは。

　前回、CloudTrailログをGlueでフラットな形にして、Athenaで読み取れるようにするところまでを実装しました。

CloudTrailLogをGlue経由してQuickSightで分析するやり方その１（Trail証跡作成→Glueジョブ作成まで）

　今回は、自社所有AWSアカウントの全てのCloudTrail証跡ログをQuickSightで分析してしまう最後の工程です。
　画面操作が中心ですので、どちらかというと前回よりも画像多めになります。

　ついでにQuickSightの使い方やコツなどについても書きますので少々長くなりますが、お付き合いください。

　最終的にこんなのが作れることが目標です。

　しょぼいように見えますが、使い勝手はなかなかのものですよ。

#●初回設定

　実は、この初回設定ですが、アカウント一つに対して一回限りの設定になります。
　ということでスクリーンショットを取り忘れてましたので、下記の記事を参考にしてください。
　初っ端から手抜きですいません。

Amazon QuickSight: ユーザー管理やパーミッション設定について

　なお、上記記事の後に、今回利用するS3とAthenaにアクセスできるような権限設定をする必要があります。
　まずはバージニア北部に移動して、右上のユーザーボタンをクリックし、QuickSightの管理に遷移します。

　「セキュリティとアクセス権限」に移動して、「接続された製品とサービス」の「追加または削除する」をクリックします。

　サービスの選択画面に行きますので、今回は「Athena」と「S3」にチェックが入れてください。

　また、S3の説明にある「詳細」をクリックすると、詳細画面がスライドします。

　ここで、Athenaでクエリを投げる先のS3バケットを選択してください。

　具体的にはglueジョブを作成する際に「--s3_converted_target」で設定したバケットです。
　　※./scripts/sample_cloudtrail_job.pyのS3_CONVERTED_TARGETで指定したバケット。

#●無事、初回設定が終わったら

　次はデータを取り込むことになりますが、ここで一つ注意点を。

　QuickSightでは、ログインしたユーザーが作成したデータセット（分析の元になるデータ）や分析、ダッシュボードなどはログインユーザーのみにしか見えません。
　他のユーザーが編集、閲覧できるようにするためにはそれぞれのリソースに対して「共有」作業を行う必要があります。

　例えばデータセットの場合、データセットのサブメニューから「共有」を選択します。
　そして、共有したいユーザーのメールアドレスで検索すると、対象のユーザーが表示されるため、該当ユーザーを選択し「共有」ボタンを押します。

　分析の共有については、該当の分析を開いて右上に「共有ボタン」があります。

　あとは出てくるサブ画面は同じですので、必要な相手を共有しましょう。

　ということを前提にデータの取り込みに進みます。

#●データセットの作成

　画面右上から「データの管理」に進むと、最初は何も表示されていません。
　「新しいデータセット」から新規作成しましょう。

　データソースは「Athena」を選んでください。

　「データソース名」には、データカタログのrawデータじゃない方を使いましょう。
　※前回のglueジョブ作成時にデフォルトであれば「aws_service_logs」になります。
　「接続を検証」すれば、有効性が確認できます。

　「データソースを作成」すると、テーブルの選択画面に遷移します。
　データベース名を選択し、取り込みたいデータソースを選びます。残念ながら一つのデータソースしか選べません。

　また、ここでカスタムSQLを使用すると、JSON部分を開けたりするのですが、非常に面倒なので今回はそのままです。

　まずはいったん「SPICEへインポート」しましょう。

　「visualize」をクリックすると自動的に分析が開きます。
　初回もしくは一つのアカウントであればこのままこの分析を使ってください。
　しかし、複数のアカウントのTrailログを分析する予定であれば、一つの分析に複数のデータセットを取り込むことが可能になっていますので、「データの編集/プレビュー」にしておきましょう。

#●データセットの修正

　今回の目的は「AWS上で不要な変更や作成が行われていないか」を監視することです。
　ですが、全てのTrailログを取得すると、一番出力されるのは「List」や「Get」系のログになります。
　これらはほぼ安全ですし、いちいち気にしてられないので、データセットからこれらをフィルタリングしましょう。

　まず、データセットを編集します。
　「データの管理」から該当のデータセットを開くと「データの編集」があります。

　データセットを開いた後、左側のペインからフィルタを選択しましょう。
　「フィルタの追加」で「eventname」を選び、「カスタムフィルタ」で「次を含まない」にしてからテキストボックスに「List」および「Get」を入力します。それぞれフィルタを作成するため、二つのフィルタが出来上がりますが、これらは or で結ばれます。

注１！　カスタムフィルタリストだとまとめて記入できますが、and条件のため上手くフィルタできません。
注２！　フィルタは分析にも存在しますが、そこでは「次を含まない」という条件が選択できません。

　最後に、画面上部にある「保存」を忘れないようにしてください。
　「保存して視覚化」だと、不要な分析が出来上がりますので使わないようにしましょう。

　これらの作業を作成されたデータカタログ全てに行います。

#●分析でIAM行動を分析する

　自動的に出来上がった分析には、一つのデータセットが取り込まれています。
　まずは一つのデータセットを分析してみましょう。

##・IAM操作イベントをチェックするために全イベントを集計

　ではまず、IAMでどんな操作が行われたかを分析してみます。
　左側の「視覚化」をクリックし、フィールドリストを開きます。

　画面下部の「ビジュアルタイプ」はピボットテーブルを選択しておきます。
　ビジュアルの左側の＋に合わせて「eventname」をドラッグしましょう。すると、eventnameを軸としたテーブルができあがります。
※上手くいかない場合は画面上部のフィールドウェル部分をクリックして、行のところにeventnameをドラッグしましょう。

　その次にフィールド上部の＋に合わせて「eventsource」をドラッグします。上手くいかない場合はフィールドウェルを開いて、列のところにドラッグしましょう。
　これで、全てのAPIイベント（List、Get除く）がイベントソース（API発行先）ごとにまとまります。

##・IAMのみを抽出する

　この中で調べたいのはIAMに関するもののみです。
　ですので、ここでフィルタを作成します。
　
　フィルタを新規作成し、

　上部：すべてのビジュアル　→　全てのフィールドで同じフィルタを適用します。ここであれば「このビジュアルのみ」で。
　フィルタタイプ：フィルタリスト
　値を検索：iam

　にすると、iam.amazonaws.comが表示されますので、チェックしましょう。

　適用後に閉じると、フィールドにはiamのイベントのみが表示されます。

##・日時指定コントロールを作成する

　先ほどIAMにイベントソースを絞ってしまいましたが、これだと、閲覧ユーザーは自由に他のイベントソースを調べることはできません。
　日時やイベント内容についても、取り込んでいる全ての日時や内容が表示されてしまいます。
　では、利用者に自由にフィルタリングさせるためにはどうしたらよいでしょう？
　その答えが、フィルタリングです。

　※逆に選択肢が多いと作業が煩雑になるので、固定化するのも一つのやり方です。
　　それぞれの業務に合った方法を選びましょう。

　パラメータを選択し、上部の＋から新規作成します。

　名前は適当に決めてください。後ほど述べる理由から、データセットが想定できる名称が良いかもしれません。
　ここでは、日時を選択させるという前提で「date」にします。
　デフォルト値も自分の目的にあった適当な値にしてください。

　ユーザーに自由に選択させる場合は「動的デフォルト値を設定」を選択します。
　※動的でなくても選択肢が少なければ単一もしくは複数の固定値を選択させることもできます。

　データセットを選択します。

　ここで、その分析フィールドが使用しているデータセットを選ばないと、そのデータセットに含まれていない値は出てきません。
　例えば、CreateUserで検索しようとしても、そのAPIが発行されていないデータセットを選択していると、そもそも表示されません。
　ユーザー名列は参照したいフィールドを選択してください。
　この場合は「day」になります。
　デフォルト値の列も同様です。ここではなぜかdayが選べなかったので「eventtime」にしてあります。

　作成後にサブウインドウを閉じ、出来上がったdateパラメータの∨をクリックすると「コントロールを追加」とあります。
　これで、分析フィールドの画面上部にコントロールができあがりました。
　

##・コントロールとフィルタを結びつける

　コントロールを作っただけでは、機能しません。
　指定された日付を利用してフィルタリングすることが必要になります。

　ここで、再びフィルタに戻ります。

　上部：全てのビジュアル
　フィルタタイプ：期間、以降（特定の日付のみを検索したい場合は「次の間」にして、二つのパラメータにdateを選択）
　パラメータを使用：チェック
　開始日のパラメータ：作成したパラメータ（上記と同じだとdate）
　この日付を含める：チェック

　適用して閉じると、コントロールで選択した日付以降のイベントのみが表示されます。

##・APIを発行したユーザーを特定する

　さて、これで日付を絞って、いつ、どんなAPIが発行されたかが分かりました。
　ですが、肝心なのは「誰が」このAPIを発行したか、です。

　そこで、もう一つ別のパラメータを作りましょう。
　イベント名に関するパラメータです。

　名前：eventname
　データタイプ：文字列
　値：単一の値
　動的デフォルト値を設定

　データセット：適したものを選択
　ユーザー名列：eventname
　デフォルト値列：eventname

　さらにこれを使ってフィルタを作ります。

　フィルタ：eventname
　上部：すべてのビジュアル
　フィルタタイプ：カスタムフィルタ、次と等しい
　パラメータを使用：チェック
　パラメータ：eventname

　こうすることで、分析フィールドにイベント名コントロールが作成され、フィルタ条件と紐づきました。

　最後に、該当APIを発行したユーザーを特定する分析項目を作成しましょう。

##・IAM操作ユーザー分析項目

　視覚化の項目に戻ります。
　eventnameを表示しているのと同じデータセットを選択するのを忘れないでください。

　画面左上に「＋追加」とあるので、そこで「ビジュアルを追加」します。
　すると、新しいビジュアルが追加されます。
　ここに新しいフィールドを追加していきます。

　画面下部のビジュアルタイプはピボットテーブルを選択します。
　まず、「json_useridentity」をビジュアル左側の＋にドラッグします。

　次に「eventname」をビジュアルの上側の＋にドラッグします。

　最後に「eventsource」をビジュアルの左側の＋にドラッグします。

#●完成、検索

　これでIAMに関するイベントを日付単位で検索し、特定のAPIを発行したユーザーを知ることができるようになりました。

　・コントロールの日付に捜索したい日付を入力
　・イベント検索用のビジュアルから、API発行者を特定したいイベント名をコピー
　・コントロールのイベント名にコピーしたイベント名をペースト
　・連動してIAMユーザー検索用のビジュアルにAPIを発行したIAMユーザーが表示される

json_useridentity

{"type": "AssumedRole", "principalId": "AxxxxxxxxxxxxxxxY:ixx-axxxxixx", "arn": "arn:aws:sts::7xxxxxxxxxx7:assumed-role/axxxxx_xxxxon-vpc-axxx-ixx/ixx-xxxxxmxx", "accountId": "7xxxxxxxxx7", "accessKeyId": "xxxxxxxxxxxxxxxxx", "sessionContext": {"attributes": {"mfaAuthenticated": "true", "creationDate": "2019-07-19T11:49:52Z"}, "sessionIssuer": {"type": "Role", "principalId": "AxxxxxxxxxxxY", "arn": "arn:aws:iam::7xxxxxxxxx7:role/axxxxx_xxxxxn-vpc-axxxx-ixx", "accountId": "7xxxxxxxxxx7", "userName": "axxxx_xxxxxn-vpc-axxxx-ixx"}}}

　IAMユーザー部分はJSONになっているため見難いですが、json_useridentity部分をトリプルクリックすると全選択になり、エディタにコピペすればユーザー特定はできます。
　queryでJSONをいちいち開いている時間があれば、こちらの方が断然早いです。

#●複数データセットの取り込み

　複数のアカウントを分析する場合は、一つの分析フィールドでは分析しにくいです。
　そのため、分析フィールドをタブで分けて、それぞれのアカウントを分析するようにした方が良いと思われます（まだ試行錯誤中）。
　まずは複数のデータセットを取り込んでみましょう。

　分析画面の左上にウィザード（鉛筆？）ボタンがあります。

　クリックすると、データセットの追加が可能になります。（同時に、削除、置き換え、編集も可能です）

　その後、コンポボックスでデータセットを切替、ビジュアルフィールドの画面上部にある＋からタブを追加すれば、複数のアカウントのデータ分析が分かりやすくビジュアル化できます。

#●データセットを取り扱うことに対する注意点

　データセットを取り込んでいくと、画面右上にあるSPICEが足りなくなってきます。
　これは、オレゴンリージョンに遷移して管理画面を開けば、新たに購入することができます。
　GBあたり$0.38/月ですので、必要な容量を購入してください。

　データセットはそのままだと更新されません。
　データセットのアイコンをクリックすると、「更新スケジュール」を決めることができます。

　Glueジョブの更新頻度とは別に、QuickSightに取り込むための頻度になりますので、ジョブの頻度と合わせて考慮してください。
　当然、取り込んでいけばいくほど費用がかかります。

#●ダッシュボードの共有

　最後に、作成した分析は閲覧のみユーザーと共有することができます。
　分析の上部にある「共有」から「ダッシュボードの共有」をクリックすると、ユーザーを招待し、そのダッシュボードに限った閲覧を許可することも可能です。

#●QuickSightは慣れないと大変、でも慣れると……

　最初は大変だなぁと思っていたQuickSightですが、使い始めてしばらく経つと「あ、こっちの方が見やすいな」「こうやった方が分析がしやすいな」など、様々なアイデアが思い浮かんできます。
　先ほどのコントロールも、eventsourceで検索できるようにすれば、IAMだけでなく全てのイベントを検索することが可能になります。
　また、他の項目を組み合わせることで、より管理が簡便になることでしょう。
　皆さんもぜひ、自分なりのTrail管理法を見つけてみましょう。