技術や仕組み

【専門家監修】AWSにおけるログ収集の重要性と具体的な設定方法

【専門家監修】AWSにおけるログ収集の重要性と具体的な設定方法
監修者情報
監修者アイコン
中村 丈洋

形式手法および高信頼ソフトウェアの研究に従事、博士号(工学博士)を取得。2013年より株式会社SHIFTにてソフトウェアテスト支援ツール開発および非機能テストに従事。SHIFT SECURITY の設立に携わる。同社では脆弱性診断手法とツール開発、およびセキュリティコンサルティング業務に従事。2018年よりSHIFT SECURITY 執行役員に就任。現在に至る。

目次
    • はじめに
    • CloudTrailからのインシデント調査の失敗例
    • CloudTrailのログを効果的に活用するための3つのポイント
    • ポイント01 CloudTrailのログを長期保存しよう
    • ポイント02 保存されるログ/されないログを管理しよう
    • ポイント03 全リージョンでログを収集しよう
    • まとめ

はじめに

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

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

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

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

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

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

ポイント01 CloudTrailのログを長期保存しよう

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

ポイント

インシデントが発生してもすぐに発覚するとは限りません。
気づいた時には欲しいログが消えているかもしれません。

法規制や認証によっては長期間のログ保存が義務付けられています。
例えば、PCIDSSでは最低1年間、監査証跡を保存する必要があります。

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

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

ポイント02 保存されるログ/されないログを管理しよう

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

管理イベントで記録されるイベント

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

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

管理イベントで保存されないログ

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

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

ポイント03 全リージョンでログを収集しよう

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を設定していない状態では十分な情報が得られない場合も多々あります。 「ちゃんとログ収集を設定してたかな?」という方はこの機会に設定を確認してはいかがでしょうか?

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

AWSの監視運用・分析のご支援はSHIFT SECURITYにお任せください

ctaバナー

AWSやAzureなどのIaaS環境上に構成されるセキュリティモジュールからログを収集・分析し、脅威の報告をします。

IaaS監視のサービス詳細はこちら
\ 記事をシェアする /

Contact

お見積り・ご相談など、お気軽にご相談ください

ご相談・ご質問はこちら

お問い合わせ

お見積り依頼はこちら

お見積り依頼

資料請求はこちら

資料請求

お電話でのご相談はこちら
(平日10:00~18:00)

TEL.050-1707-3537
サイトTOPへ