【クラウドのセキュリティ対策】AWSにおけるログ収集の重要性と具体的な設定方法

近年、クラウド基盤の普及と共に、クラウド基盤への不正ログインやAPIキー漏洩による不正操作などの被害が多発しています。しかし、実際にインシデントが発生し、調査を開始してみると、必要なログが収集されていなかったり、ログの保存期間が短すぎて詳細な分析ができないといったケースは少なくありません。

本記事では、このような状況を回避し、インシデント発生時にスムーズな調査が行えるよう、AWSにおけるログ収集の重要性と具体的な設定方法について解説します。

CloudTrailからのインシデント調査の失敗例

CloudTrailは、AWSアカウント内のAPI呼び出しを記録するサービスです。ユーザーによる操作、自動化されたプロセス、またはAWSサービス自体によるアクションなど、アカウント内で発生したAWSリソースへの操作がログとして記録されます。一方で、実際にインシデント分析を行う際、以下のような問題が生じる事が多々あります。本記事ではこのような失敗をしないためのポイントを解説します。

90日以上前の調査をしたいが、ログが残っていない
S3バケット中の重要データが盗まれたか判別できない
S3バケットが削除されているが、東京リージョンから取得したCloudTrailに記録が無い

CloudTrailのログを効果的に活用するための3つのポイント

１．CloudTrailのログを長期保存しよう

CloudTrail のログ保存期間は90日間です。それ以上前のログを調査するには別途、設定が必要です。
90日間というログ保存期間は以下のように十分とは言えません。

インシデントが発生してもすぐに発覚するとは限りません。気づいた時には欲しいログが消えているかもしれません。
法規制や認証によっては長期間のログ保存が義務付けられています。例えば、PCIDSSでは最低1年間、監査証跡を保存する必要があります。

最も簡単な保存期間の延長方法は CloudTrail証跡の作成です。CloudTrail証跡ではイベントをS3バケットに保存します。ログの保存期間はS3バケットのライフサイクルを設定することで制御します。保存期間は保管コスト（ログ量）と相談の上で、1年以上保存することを検討しましょう。

また、インシデント発生時に証跡S3バケットが攻撃者に削除されないように保護することも重要です。IAMで権限を発行する際には必要最小限のS3バケット操作のみ許可するよう制限しましょう。可能であれば3rdパーティ製のデータレイクとの連携なども有効です。

２．保存されるログ/されないログを管理しよう

CloudTrailは、デフォルトでは「管理イベント」と呼ばれるイベントのみを保存します。管理イベントで記録されるイベントには以下のようなものがあります。

IAMユーザのコンソールログイン
AWSリソースの操作（作成、変更、削除）
ーEC2インスタンスの起動/停止
ーS3バケットの作成・削除

一方、管理イベントでは以下のようなログは保存されません。

S3バケット内のオブジェクトへのアクセス・削除
DynamoDBのアイテムの更新・削除
Lambda関数の実行

このようなログはデータイベントと呼ばれ、別途設定することによって保存することができます。ただし、データイベントは膨大なサイズになる場合があるため、保存コストや解析コストに合わせた制御が必要です。ログサイズや保持するデータの性質等に応じて保存を検討してください。

３．全リージョンでログを収集しよう

CloudTrail はリージョン毎にイベントを記録します。例えば、東京リージョンのEC2インスタンスへの操作は東京リージョンのCloudTrailに保存されます。このため、自身のAWSアカウント上で生じたイベントを把握するには全リージョンのCloudTrailでログを収集する必要があります。

特に誤解を生じやすいのがAWSコンソールやS3バケットなどの「グローバルからアクセスできるリソース」の扱いです。例えば、東京リージョンを主に利用するユーザでも、AWSコンソールログインが東京リージョンのCloudTrailに記録されるとは限りません。ログイン履歴はログイン画面のURLのリージョン(ap-southeast-2など)に依存します。

同様に、東京リージョンで作成したS3バケットをCLIから削除した場合、東京リージョンではなく、CLIで指定したリージョンのCloudTrailに削除イベントが記録されます。

全リージョンのCloudTrailからログを収集する方法としては「CloudTrail証跡をマルチリージョン証跡として作成する」事が挙げられます。 CloudTrail証跡をAWSコンソールから作成するとデフォルトでマルチリージョン証跡が有効になります。これにより全リージョンのイベントが指定されたS3バケットに保存されます。

ただし、CloudTrail証跡を設定していなかったり、設定していても、攻撃者にバケットごと証跡を削除されている場合にはマルチリージョン証跡を利用できません。このような場合にはCLI等を駆使して全リージョンのCloudTrailからログを収集する必要があります。

この記事ではAWS基盤でのログ収集について、CloudTrailにフォーカスして解説しました。 CloudTrailはインシデント調査で非常に重要ですが、ここで紹介したように、CloudTrailを設定していない状態では十分な情報が得られない場合も多々あります。「ちゃんとログ収集を設定してたかな？」という方はこの機会に設定を確認してはいかがでしょうか？

また、ここで紹介した「ログ収集」は「監視」と組み合わせる事が非常に重要です。適切にログを収集・監視し、インシデントに備えましょう。