CloudTrailデータをセキュリティ運用と脅威ハンティングに活用する方法

クラウドにワークロードを移行する組織が増える中、どの組織のセキュリティチームも同じ疑問を抱えています。

• セキュリティに関連するデータはどれか？
• そのデータはどこに保存され、どのように収集すべきか？
• そして最も重要な疑問——そのデータをどのように活用すれば悪質なアクティビティを検出できるのか？

このブログ記事では、AWSセキュリティテレメトリの最も価値あるソースの1つである CloudTrail を重点的に取り上げます。CloudTrailログは、AWS環境全域でのアクティビティの痕跡を記録する、デジタルの「パンくず」のような役割を果たします。これらのログは、インシデント発生時の状況を理解するために不可欠なものですが、脅威の早期発見に向けた検出機能を構築するうえでも欠かせません。

(この記事は「Splunkで脅威ハンティング」シリーズの一部です。お客様に最大限の価値を提供できるよう、その内容を最近更新しました。)

AWS CloudTrailとは？

アマゾン ウェブ サービス (AWS)では、CloudTrailを「AWSアカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービス」と定義しています。ユーザー、ロール、サービスがAWS内で何らかのサービスの実行を試みた場合、それが成功したか失敗したかを問わず、そのイベントに関する情報を含むログが生成されます。CloudTrailはセキュリティ運用において非常に価値あるデータソースであるため、AWSではお客様のアカウントでデフォルトで有効になっています。

AWSサービスは、Amazonが提供するサービスです。例として、EC2によるコンピューティング、RDSのリレーショナルデータベース、さらにはCloudTrailのロギング機能などが挙げられます。CloudTrailを有効にすることで、ユーザーは次の詳細情報を取得できます。

• 現在提供されているすべてのサービス
• AWSが今後リリースする新サービス(ユーザーが何らかの形で必ず使用することになるもの)

CloudTrailログをSplunkに取り込む

AWS CloudTrailログをSplunkに取り込むには、いくつかの方法があります。導入環境(Splunk CloudまたはSplunk Enterprise)、許容できるレイテンシー、導入規模などによっても異なりますが、主な方法は以下のとおりです。

CloudTrailイベントの形式

ここでは、Githubから入手できるBOTSデータセットを使用して説明します。IAMサービスに対するCreateKeyPairアクションを示しているイベントを見てみましょう。生のJSON形式のCloudTrailイベントは以下のようになります。

{"requestParameters": {"keyName": "BOTS"}, "userAgent": "signin.amazonaws.com",
"eventVersion": "1.05", "eventName": "CreateKeyPair", "userIdentity": {"accountId": 
"622676721278", "arn": "arn:aws:iam::622676721278:user/frothly_admin", "sessionContext": 
{"attributes": {"mfaAuthenticated": "false", "creationDate": "2018-07-26T20:56:40Z"}},
"accessKeyId": "ASIAZB6TMXZ7GUK5FY3H", "principalId": "AIDAIUCPPDM575G2FVOTI",
"userName": "frothly_admin", "type": "IAMUser", "invokedBy": "signin.amazonaws.com"},
"responseElements": {"keyFingerprint":
"02:36:de:d2:6a:97:c5:a7:f2:e7:b2:d8:ce:95:a7:bd:85:a6:af:39", "requestId": "477c8411-ae6b-4be6-9756-6cd1a29f503b", "keyName": "BOTS", "keyMaterial": ""}, 
"recipientAccountId": "622676721278", "eventSource": "ec2.amazonaws.com", "eventTime":
"2018-07-26T21:08:28Z", "requestID": "477c8411-ae6b-4be6-9756-6cd1a29f503b", 
"awsRegion": "us-west-1", "sourceIPAddress": "12.196.122.120", "eventType": "AwsApiCall", 
"eventID": "597b5cd4-9f1d-4087-a9e0-7a9e73d9aa3a"}

Splunkはこの生データを解析してCloudTrailフィールドを抽出し、生のJSONイベントから、構文が強調表示された次のような構造化ビューを生成します。

このイベントを見ると、次のことがすぐにわかります。

• 実行者：「frothly_admin」というIAMユーザーがイベントを実行した
• 内容：「BOTS」というキーを作成しようと試みている
• 場所：「us-west-1」AWSリージョンでキーペアを作成するアクションが発生した
• 日時：「2018年07月26日」の「21時08分28秒」(UTC)に発生した

アクションに関する詳細は、以下に挙げるその他のフィールドで確認できます。

• キー作成の試みが成功している(errorCodeフィールドが存在していない)
• コンソールにログインしたユーザーによってキーの作成が行われている
  - invokedBy：signin.amazonaws.com
• ユーザーが多要素認証(MFA)を使用せずにコンソールにログインしている
  - mfaAuthenticated: false
• キーのフィンガープリントが「02:36d2:6a:97a7e7d895bd:85af:39」である
  - keyFingerprint: 02:36d2:6a:97a7e7d895bd:85af:39
• AWSにより秘密鍵が削除され、CloudTrailイベントに秘密鍵の情報が含まれていない
  - keyMaterial: <sensitiveDataRemoved>

主要なCloudTrailフィールド

eventName

「eventName」は特に注目すべきフィールドです。このフィールドには、リクエストされたアクション(そのサービスのAPIのアクションの1つ)が含まれます。このフィールドをcountで並べ替え、正規表現を使ってサブフィールドをフィルタリングすると、個々のアクションと対応するサービスをさらに詳しく特定できます。

ここでは、AWS Configサービスが大量のDescribeEvaluationStatusリクエストを生成していることが確認できます。このブログ記事では、Configとそのデータの全容まではお伝えできませんが、CloudTrailが記録するイベントタイプは、Get、Describe、Runなどのアクションから、Config、EC2インスタンス、S3バケットなどのサービスに至るまで、多岐にわたることを認識しておくことが重要です。

CloudTrailデータを活用したサイバーセキュリティのユースケース

では、CloudTrailがセキュリティ運用をどのようにサポートするかを見ていきましょう。

ユースケース1：認証情報の侵害の検出

認証情報の侵害の兆候を検出することは、あらゆる環境に共通したセキュリティ運用のゴールです。CloudTrailは、特にこの点において効果を発揮します。

「予防は治療に勝る」という言葉もあります。そこで、まずはリスク増加の指標をどのように特定するかを見てみましょう。AWSのセキュリティポリシーを確立するうえで、広く認知されているリソースにCIS AWS Foundations Benchmarkがあります。2025年時点の最新バージョン(v5.0.0)では、AWS環境のセキュリティを保護するための最新のベストプラクティスが提供されています。AWS Security Hubが現在サポートしているバージョンは v3.0.0 ですが、どちらのバージョンを使用しても、構成リスクを評価し、ベースラインコントロールを定義し、侵害の可能性を事前に低減できます。

CISは、以下のそれぞれで多要素認証(MFA)を使用することを常に強く推奨しています。

• コンソールアクセス権を持つIAMユーザー。このコントロール(IAM.5)により、コンソール経由でログインできるすべてのユーザーがMFAを使用するよう徹底できます。
• rootアカウント。特に最高レベルのセキュリティが求められる環境では、ハードウェアベースのMFA(IAM.6)の使用が推奨されます。

これらのコントロールはCIS AWS Foundations Benchmark v3.0.0に含まれており、v5.0.0にも引き継がれています。つまり、これらのアカウントでMFAが有効になっていないと、環境を不要なリスクにさらすことになります。

コンソールログインは、CloudTrailのeventNameに「ConsoleLogin」として表示されます。コンソールログインでのMFAの使用は、additionalEventDataセクションに表示されます。これらの2つの属性をSplunkサーチに組み合わせることで、MFAを使用せずにコンソールにログインしているユーザーを特定できます。

 |sourcetype=aws:cloudtrail eventName=ConsoleLogin
 | stats count by username, additionalEventData.MFAUsed

ユーザー「bstoll」がMFAを使用せずにコンソールに4回ログインしたことが確認できます。組織内でのこうしたポリシー違反については、bstoll本人またはその管理者に連絡し、コンソールアカウントでMFAを有効にするようフォローアップする必要があります。幸いなことに、MFAを使用せずにroot権限でログインした形跡はありませんでした。

このサーチは、必要に応じてSOCが対応すべきアラートとして簡単に保存できます。

ユースケース2：セキュリティハンティング

CloudTrailを、プロアクティブなアラートではなくセキュリティハンティングに活用する方法を見てみましょう。サービスアクションに関連するエラーをいくつか確認します。簡単なサーチでさまざまなエラーメッセージを表示できます。

sourcetype=aws:cloudtrail
 | stats count by errorCode
 | sort - count

ほとんどのAPIのアクションが成功しています。侵害されたアカウントによるアクションであってもコマンドの実行が成功する場合もありますが、ここではより取り組みやすい問題から見ていきましょう。errorCodeが「AccessDenied」のイベントが7件あります。さらに詳しく調べてみる必要がありそうです。

これらのイベントをフィルタリングし、表形式で出力すると、興味深い結果が得られます。

sourcetype=aws:cloudtrail errorCode=AccessDenied
| table awsregion, eventName, userName, src_ip, userAgent, errorMessage

このビューを見ると、ユーザーweb_adminが何度もアクションを試み、最終的に拒否されていることがわかります。errorMessageに、いくつかの疑わしいアクティビティが示されています。

• これらのweb_adminによるアクティビティの失敗は何を意味しているのでしょうか？
• web_adminユーザーのアカウントが侵害されている可能性はあるのでしょうか？
• これらの送信元IPからのアクティビティを確認すべきでしょうか？

状況を把握するために、SOCチームに追跡調査を依頼しましょう。

まとめ

CloudTrailは、AWSセキュリティ運用において最も価値あるデータソースの1つです。CloudTrailによって、環境全域にわたるユーザーアクティビティとサービスアクティビティの詳細な記録がもたらされ、検出と調査に不可欠な環境の可視化が実現します。

CloudTrailログをSplunkに取り込むことで、セキュリティチームはシンプルかつ強力なクエリを使用して、設定ミスを発見し、認証情報の侵害の兆候を検出し、不審な行動を調査できます。CIS AWS Foundations Benchmarkにまとめられているベストプラクティスなどと組み合わせれば、CloudTrailを強力なクラウドセキュリティ態勢の基盤コンポーネントとすることができます。

ポリシー違反を監視する場合でも、侵害の些細な兆候を追跡する場合でも、CloudTrailなら情報に基づいた迅速な対応に求められるコンテキストを提供できます。

Splunkはセキュリティチームをいつでもサポートします。