🙆‍♀️

AWS CloudTrail 証跡を取得してみた

2023/12/26に公開

はじめに

こんにちはみゃっちーです!🦔

AWS SCS試験を受けようと考えてるんですが、ただ暗記してももったいないので、練習問題の中で面白そうなものを実際に作っていこうと思ってます。CloudTrail 証跡です!

そもそもAWS CloudTrailとは?

公式の説明は下記の通りです。

AWS およびハイブリッドおよびマルチクラウド環境でのユーザーアクティビティと API の使用状況を追跡します

https://aws.amazon.com/jp/cloudtrail/
このようにAWSユーザの操作履歴(API)を記録するサービスで、CloudTrailログをきちんと収集し活用することはAWS環境上でユーザ操作が起因する問題が発生したときに大いに役に立つと思います。

今回想定する構成

全体像は下記の通りで、赤枠で囲った部分のCloudTrail証跡の取得をやってみます。その他のところは次回作成を行います。

AWS CloudTrailでユーザのAPI履歴をS3、CloudWatchLogsに送信し、特定のアラートでSNSでメールを送信する。

取得する証跡のサンプル

今回はEC2の作成削除を行いその証跡を確認してみます。ログのサンプルはこちらです。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-log-file-examples.html

やってみた

1. マネジメントコンソール検索欄から「CloudTrail」を検索して、証跡をクリック。

2.「証跡の作成」をクリック

3. 証跡属性の選択

今回はこのようにパラメータの設定を行いました。

  • 証跡名: Write_Resource
  • 組織内のすべてのアカウントについて有効化: オフ
    • AWS Organizationsを利用して組織内の全てのAWSアカウントに対して証跡の作成を自動的に有効にする設定
  • ストレージの場所: 新規作成
  • ログファイルの SSE-KMS 暗号化: オフ
  • CloudWatch Logs: オン、新規
  • ロググループ名: デフォルト使用
  • IAM: 新規
  • IAM名: CloudTrailToCloudWatchLogsRole

4. ログイベントの選択

記録するイベントには下記の3つが用意されていますが、今回はEC2関連を検知するため、管理イベントのみチェックを入れます。

  • 管理イベント
    EC2 インスタンスの起動 (RunInstances)、S3 バケットの作成 (CreateBucket) など
  • データイベント
    S3 バケット内のオブジェクトへのアクセス (GetObject)、DynamoDB テーブルの読み取り (GetItem) など
  • Insights イベント
    不正なAPIコール、アクセス拒否エラー、ユーザーによる誤った設定変更など

5. 管理イベントの選択

CloudTrailのログには頻繁に書き込まれるものや使用用途が低いログについて除外することが可能です。また、読み取り、書き込みなどの設定項目の詳細は下記の通りです。

読み取りと書き込みの違い

読み取り

  • リソースの読み取りのみを行い、変更を行わない API オペレーションが含まれる
  • 例: EC2 の DescribeSubnetsDescribeSecurityGroups など
  • マネジメントコンソールでEC2を開いてインスタンスの一覧を見ているときなど

書き込み

  • リソースを変更する (またはその可能性のある) API オペレーションが含まれる
  • 例: EC2 の RunInstancesTerminateInstances など
  • インスタンス自体を変更するときなど

今回はEC2の作成削除関連のイベントが欲しいので書き込みを選択します。

AWS KMS イベントの除外

普段マネジメントコンソールを使用しているときは意識していませんが、例えばEC2の一覧を見るだけでもそのIAMユーザに紐づいたKMSを使用して大量のAPIコールを行っています。(このKMS関係でログの99%を占めるそうです。)

これらの情報は今回は必要ないのでチェックを入れて除外します。

Amazon RDS データ API

このイベントにおいてもKMS同様理由でチェックを外します。

ほとんどの Data API ユーザーは、AWS CloudTrail トレイル内のイベントを使用して Data API オペレーションを記録します。 これにより、トレイルは SQL ステートメントなどの重要なイベントを監査するための貴重なデータ ソースとなります。 テーブル内の行の削除や、場合によっては CloudTrail ログエントリ内のメタデータがエラーの解決に役立つことがあります。
ただし、Data API は大量のイベントを生成できるため、 CloudTrail トレイルから Data API イベントを除外することが推奨されます。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/logging-using-cloudtrail-data-api.html?icmpid=docs_console_unmapped

ログの確認

試しにEC2インスタンスを立ち上げて削除してみました。
下からサンプル通りのEC2インスタンスの作成、セキュリティグループの作成、インスタンスの削除イベントのログが取得できました。

ログの保存期間設定

現在ログはS3とcloudwatch logsに保存されていますが、このログはデフォルトでそれぞれ削除されない設定になっています。

こちらに実際に起きた証跡のデータ量に気が付かず分析サービスを使って高額請求が発生した事例をわかりやすく解説してくださってる記事があります。

cloudwatch logsの保存期間設定

該当ロググループの保存設定を編集から設定します。

S3の保存期間設定

該当バケットのライフサイクルルールを設定します。

さいごに

ここまで読んでいただきありがとうございました!

簡単に取得できてよかったです!ただログは活用しないといけないので様々な活用方法を学んでいかないとなと思っています。

次回はCloudWatch logsに保存された証跡にメトリクスフィルターを設定して、EC2の作成イベントのみを取り出し、数がわかるようにしたいと思います!

デベキャン

Discussion