Justin Massey
Jonathan Epstein
AWS でクラウドベースのアプリケーションを構築、スケーリング、管理するエンジニアリングチームは、ある時点で、アプリケーションとインフラストラクチャーが攻撃を受けることを知っています。ただし、アプリケーションが拡張され、新しい機能が追加されると、AWS 環境の全範囲を保護することはますます複雑なタスクになります。
可視性と監査可能性を追加するために、AWS CloudTrail は、AWS 環境で発生するアクティビティの誰、何、どこ、いつを追跡し、このアクティビティを監査ログの形式で記録します。したがって、CloudTrail 監査ログには、AWS アカウント全体で実行されるアクションを監視し、悪意のある可能性がある行動を特定し、適切に構成されていない可能性のあるインフラストラクチャーの一部を明らかにするための鍵となる情報が含まれています。
このガイドでは、以下について説明します。
しかしまずは、AWS CloudTrail が AWS アカウント内のアクティビティをどのように整理、監視するかを簡単に見てみましょう。
明白な証跡
前述のように、AWS CloudTrail は、環境内で検出したアクティビティの各インスタンス (API リクエストやユーザーログインなど) をイベントとして記録します。これは、アクティビティの詳細を指定する JSON オブジェクトで、 発生した時間、アクティビティを実行した人、アクティビティによって影響を受けたリソースなどが含まれます。AWS CloudTrail コンソールのイベント履歴ページですべてのイベントを表示、フィルタリングできます。これは、発生後最大 90 日間利用できます。
AWS 大半のお客様は、すべての CloudTrail イベントに統合証跡を使用しています。ただし、イベントをフィルタリングするイベントストリームを作成することはできます。たとえば、ログの負荷を軽減するために、特定の AWS サービスまたはリソースに関連するアクティビティのみで構成されるイベントストリームを作成したい場合があります。これを行うには、証跡を作成するか、選択した AWS S3 バケットにイベントをログファイルとして送信するイベントストリームを作成します。このように、イベントは指定した保持ポリシーに従って利用することが可能で、重大な問題を見つけるためにすばやくフィルタリングでき、Amazon CloudWatch または Amazon Simple Notification Service (SNS) を使用してアラートを受け取ることができます。
CloudTrail は、監査ログを gzip アーカイブフォームで、証跡の作成時に指定した S3 バケットに保存します。ファイルの名前には、証跡作成者のアカウント番号、ログが記録されたリージョン、ファイルが作成された年月日が含まれます。CloudTrail ログファイルの検索の詳細については、AWS ドキュメントを参照してください。
デフォルトでは、証跡はリージョンに依存しません。つまり、証跡はすべてのリージョンの関連イベントをログに記録します。単一リージョンの証跡を作成して、単一リージョンのアクティビティに焦点を当てることもできますが、すべてリージョンの証跡を作成することをお勧めします。そうすることで、新しいリージョンがオンラインになったときに、より多くの可視性とデータを自動的に追跡できるようになります。
AWS Organization 内の AWS アカウントによって生成されたすべてのログを監視するように組織証跡を設定することもできます。AWS Organizations を使用すると、組織内のすべてのアカウントのユーザーのアクセス許可を一元管理でき、追加費用なしでセットアップできます。チームが絶えず変化する環境を管理することで、さまざまな AWS アカウントを管理し、プライマリアカウントとメンバーアカウントに構成を適用する必要がある場合は、組織をお勧めします。
AWS CloudTrail 監査ログの理解
AWS CloudTrail は、ユーザーが AWS マネジメントコンソール、コマンドラインインターフェイス (CLI)、SDK/API で実行するアクション、および AWS によって実行される自動アクションに基づいて、ほとんどの AWS サービスから 3 つの異なるタイプのイベントを記録します。CloudTrail によって追跡されないサービスのリストについては、AWS ドキュメントを参照してください。3 つのイベントタイプは次のとおりです。
-
管理イベント: セキュリティグループのコンフィギュレーション変更、IAM ロールのアクセス許可の調整、AWS Virtual Private Cloud (VPC) ネットワークの変更など、AWS アカウントのリソースで実行される管理およびネットワーク (コントロールプレーン) 操作のエントリ。
-
データイベント: AWS データプレーンリソースで実行されるデータリクエスト操作 (
Get、Delete、PutAPI コマンドなど) のエントリ。 -
インサイトイベント: 短期間の過剰な API 呼び出しなど、過去の API 使用状況と比較した AWS アカウントの異常なAPIアクティビティを反映するエントリ。
CloudTrail のイベントログの大部分は管理イベントとデータイベントで構成されているため、それらについて詳しく見ていきます。インサイトイベントを使用して AWS データの異常を追跡、検出する方法の詳細については、AWS ドキュメントを参照してください。
管理イベント
管理イベントには、アカウント内のリソースに対して実行されるすべての管理操作と、ほとんどの非 API アクションが含まれます。非 API アクションには、AWS コンソールへのログイン (AwsConsoleSignIn) や、暗号化キーローテーションなどの自動サービスアクション (AwsServiceEvent) が含まれます。AWS CloudTrail は、デフォルトで管理イベントをログに記録します。
以下のサンプル管理イベントは、フィールド eventType: AwsConsoleSignIn で示されるコンソールログインを記録します。これは、userName Alice を持つ誰かが多要素認証なしで AWS コンソールに正常にサインインしたことを示しています。
{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDABBBBBBBBBBBBBBBBB", "arn": "arn:aws:iam::111111111111:user/alice", "accountId": "111111111111", "userName": "alice" }, "eventTime": "2020-09-23T09:09:56Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36", "requestParameters": null, "responseElements": { "ConsoleLogin": "Success" }, "additionalEventData": { "LoginTo": "https://console.aws.amazon.com/console/home", "MobileVersion": "No", "MFAUsed": "No" }, "eventID": "6894a571-9f34-47b8-b75c-5f4ca34f281e", "eventType": "AwsConsoleSignIn", "recipientAccountId": "111111111111"}データイベント
データイベントは、AWS IAM ロール、Amazon EC2 インスタンス、Amazon S3 バケット、AWS Lambda 関数などのリソースまたはサービス上または内部で実行される操作の詳細を提供します。多くの場合、これらは大量のアクティビティであるため、データイベントは、証跡を作成するときにデフォルトで無効になっています。これを AWS CloudTrail で追跡するには、リソースまたはリソースタイプを証跡に追加する必要があります。
以下の例は、ユーザー Alice が example-bucket というバケットで PutObject Amazon S3 操作を正常に実行して、ファイル exampleFile.txt をアップロードしたことを示しています。
{ "eventVersion": "1.07", "userIdentity": { "type": "IAMUser", "principalId": "AIDAAAAAAAAAAAAAAAAAA", "arn": "arn:aws:iam::111111111111:user/Alice", "accountId": "111111111111", "accessKeyId": "AKIAAAAAAAAAAAAAAAAAA", "userName": "Alice" }, "eventTime": "2020-09-22T20:15:25Z", "eventSource": "s3.amazonaws.com", "eventName": "PutObject", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36]", "requestParameters": { "X-Amz-Date": "20200922T201524Z", "bucketName": "example-bucket", "X-Amz-Algorithm": "AWS4-HMAC-SHA256", "x-amz-acl": "private", "X-Amz-SignedHeaders": "content-md5;content-type;host;x-amz-acl;x-amz-storage-class", "Host": "example-bucket.s3.us-east-1.amazonaws.com", "X-Amz-Expires": "300", "key": "exampleFile.txt", "x-amz-storage-class": "STANDARD" }, "responseElements": null, "additionalEventData": { "SignatureVersion": "SigV4", "CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "bytesTransferredIn": 12, "AuthenticationMethod": "QueryString", "x-amz-id-2": "d2UncmUgaGlyaW5nIDopIGh0dHBzOi8vd3d3LmRhdGFkb2docS5jb20vY2FyZWVycy8K", "bytesTransferredOut": 0 }, "requestID": "EEEEEEEEEEEEEEEE", "eventID": "f378e059-d87f-44b7-aee2-7ebfa1beff93", "readOnly": false, "resources": [ { "type": "AWS::S3::Object", "ARN": "arn:aws:s3:::example-bucket/exampleFile.txt" }, { "accountId": "111111111111", "type": "AWS::S3::Bucket", "ARN": "arn:aws:s3:::example-bucket" } ], "eventType": "AwsApiCall", "managementEvent": false, "recipientAccountId": "111111111111", "eventCategory": "Data"}CloudTrail ログの解釈
AWS CloudTrail ログには、AWS 環境全体のアクティビティを監視できる貴重な情報が含まれているため、調査を行うには、それらを解釈する方法を理解することが重要です。このセクションでは、CloudTrail ログファイルのサンプル管理イベントについて詳しく説明し、どのフィールドに注目する必要があるかを示します。
CloudTrail ログファイルは JSON 形式で記述され、各イベントは単一の JSON オブジェクトとして表示されます。すべてのイベントタイプのエントリには、アクションを実行した AWS ID のアクセスキー ID (userIdentity フィールド) や実行されたアクションの詳細 (eventName と requestParameters) など、同じ重要なフィールドがいくつか含まれています。管理およびデータイベントエントリは、アクションが正常に実行されたかどうかを判断するのに役立つ responseElements フィールドも提供します。
以下のスニペットでは、Alice (userName) という名前のユーザーが Bob (requestParameters) という名前の新しいユーザーを作成する (eventName) ために呼び出しを行ったことがわかります。
{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDAAAAAAAAAAAAAAAAAA", "arn": "arn:aws:iam::111111111111:user/Alice", "accountId": "111111111111", "accessKeyId": "AKIAAAAAAAAAAAAAAAAAA", "userName": "Alice" }, "eventTime": "2020-09-21T10:31:20Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateUser", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "console.amazonaws.com", "requestParameters": { "userName": "bob", "tags": [] }, "responseElements": { "user": { "path": "/", "userName": "bob", "userId": "AIDABBBBBBBBBBBBBBBBB ", "arn": "arn:aws:iam::111111111111:user/bob", "createDate": "Sep 21, 2020 10:31:20 AM" } }, "requestID": "604e7549-4ea4-4185-83b0-acff4e462d27", "eventID": "600e50af-0a2c-4352-95a8-7b813c744072", "eventType": "AwsApiCall", "recipientAccountId": "111111111111"}エントリは新しく作成されたユーザーの識別の詳細 (responseElements) を返しているため、コマンドが正常に実行されたことがわかります。そうでない場合、AWS ドキュメントに示されているように、JSON 応答に errorCode および errorMessage 要素が含まれることになります。
監視する上で最も重要な CloudTrail ログを確認する前に、CloudTrail によって定義されたさまざまなユーザー ID タイプと、CloudTrail がアクションを実行したユーザーを識別する方法を理解することが大切です。
CloudTrail ID タイプ
すべての CloudTrail イベントログには、アクションを実行したユーザーまたはサービスを説明する userIdentity 要素が含まれています。この要素内の type フィールドは、リクエストを行ったユーザーまたはサービスの種類と、そのユーザーまたはサービスがリクエストを行うために使用した資格情報のレベルを示します。CloudTrail の userIdentity タイプには次のものがあります。
-
Root: リクエストは、プライマリ AWS アカウントの認証情報を使用して行われました。AWS アカウントのエイリアスを設定すると、代わりにそのエイリアスがここに表示されます。
-
IAMUser: リクエストは IAM ユーザーの認証情報を使用して行われました。
-
FederatedUser: リクエストは、フェデレーショントークンを通じて提供された一時的なセキュリティ認証情報を持つユーザーによって行われました。
-
AWSAccount: リクエストはサードパーティの AWS アカウントによって行われました。
-
AWSService: リクエストは AWS サービスアカウントによって行われました。多くの AWS サービスは、サービスアカウントを使用して、お客様に代わって自動アクションを実行します。
-
AssumedRole: リクエストは、AWS Security Token Service (STS) AssumeRole 操作を使用して取得した一時的な認証情報を使用して行われました。
これらの ID タイプのほとんどはかなり単純ですが、AssumedRoles はアクションを実行したユーザーの名前を難読化します。次のセクションでは、AssumeRole 呼び出しが実際にどのように機能するか、AssumedRole ID の背後にいるユーザーを特定する方法、および巧妙な攻撃者が AssumedRole セッションを使用して真の ID を隠す方法について説明します。
'AssumedRole' CloudTrail ログの初期 ID の解釈
AWS のマルチアカウント設定で一般的なのは、単一の AWS アカウントですべてのユーザーを管理することです。これをアカウント A と呼びます。次に、セキュリティのベストプラクティスは、IAM ユーザーに直接関連付けられた IAM ポリシーがないことを確認することと、代わりにアクションを実行するための一時的な資格情報を提供することです。これを行うには、IAM ロールを含む独立したアカウント (アカウント B など) を作成します。各々には、IAM ポリシーで定義された一連の許可されたアクションがあります。これで、アカウント A のユーザーが、アクションを実行する必要があるときに、これらのロールを引き受けることを許可できます。
アカウント A のユーザーがアカウント B で有効になっているすべての AWS リージョンを一覧表示したいとします。最初に、ユーザーは DescribeRegions アクセス許可を持つアカウント B のロールに AssumeRole を入れ、AssumeRole コマンドによって返される一時的な認証情報を取得します。次に、それらを使用してコマンドを実行します。アカウント A (accountId: 222222222222) のユーザー (userName: Alice) がアカウント B (accountId: 11111111111) のロールを引き受ける CloudTrail ログは次のようになります。
{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDAAAAAAAAAAAAAAAAAA", "arn": "arn:aws:iam::222222222222:user/Alice", "accountId": "222222222222", "accessKeyId": "AKIAAAAAAAAAAAAAAAAAA", "userName": "Alice" }, "eventTime": "2020-09-22T16:23:50Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-go/1.16.8 (go1.12.7; linux; amd64)", "requestParameters": { "roleArn": "arn:aws:iam::111111111111:role/ExampleRole", "roleSessionName": "ExampleRoleSession", "externalId": "ffffffffffffffffffffffffffffffff", "durationSeconds": 3600 }, "responseElements": { "credentials": { "accessKeyId": "ASIADDDDDDDDDDDDDDDD", "expiration": "Sep 22, 2020 5:23:50 PM", "sessionToken": "d2UncmUgaGlyaW5nIDopIGh0dHBzOi8vd3d3LmRhdGFkb2docS5jb20vY2FyZWVycy8K" }, "assumedRoleUser": { "assumedRoleId": "AROAEEEEEEEEEEEEEEEEE:ExampleRoleSession", "arn": "arn:aws:sts::111111111111:assumed-role/ExampleRole/ExampleRoleSession" } }, "requestID": "4da64d92-6130-4355-86f2-1609a6eb53e1", "eventID": "ffef7974-b1a0-4e88-b27f-0b143965f30c", "resources": [ { "accountId": "111111111111", "type": "AWS::IAM::Role", "ARN": "arn:aws:iam::111111111111:role/ExampleRole" } ], "eventType": "AwsApiCall", "recipientAccountId": "111111111111", "sharedEventID": "4f61c867-6a49-4c41-a267-388c38e99866"}AssumeRole コマンドは、ユーザー Alice がロールの委任されたアクションを実行するために使用できる AccessKeyId (ASIADDDDDDDDDDDDDDDD) を返します。次のイベントログでは、AssumedRole ユーザーがアクセスキー ASIADDDDDDDDDDDDDDDD を使用して DescribeRegions 操作を実行していることがわかります。したがって、ユーザー Alice がアクセスキーを使用したと推測できます。
{ "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROAEEEEEEEEEEEEEEEEE:ExampleRoleSession", "arn": "arn:aws:sts::111111111111:assumed-role/ExampleRole/ExampleRoleSession", "accountId": "111111111111", "accessKeyId": "ASIADDDDDDDDDDDDDDDD", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAEEEEEEEEEEEEEEEEE", "arn": "arn:aws:iam::111111111111:role/ExampleRole", "accountId": "111111111111", "userName": "ExampleRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2020-09-22T15:58:31Z" } } }, "eventTime": "2020-09-22T16:26:02Z", "eventSource": "ec2.amazonaws.com", "eventName": "DescribeRegions", "awsRegion": "us-east-1", "sourceIPAddress": "1.2.3.4", "userAgent": "aws-sdk-go/1.16.8 (go1.12.7; linux; amd64)", "requestParameters": { "regionSet": {} }, "responseElements": null, "requestID": "0a857cb2-90c4-4f09-9624-1149fb27f8a1", "eventID": "26fe99a5-8ed5-4923-9cf7-b6cdf96fa5f3", "eventType": "AwsApiCall", "recipientAccountId": "111111111111"}AssumedRole セッション名の制御
引き受けたロールを制御し、引き受けたロールを使用してアクションを実行するユーザーをより簡単に追跡するには、ユーザーのセッション名を指定するのが良い方法です。これを行うには、引き受けるロールの信頼ポリシーで許可されるセッション名を指定します。たとえば、次の信頼ポリシーでは、ロールを引き受けるために、ユーザーは自分のユーザー名にちなんでセッションに名前を付ける必要があると指定しています。そうしないと、AssumeRole コマンドは失敗します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<AccountNumber>:root" }, "Action": "sts:AssumeRole", "Condition": { "StringLike": { "sts:RoleSessionName": "${aws:username}" } } } ] }このコンフィギュレーションを使用すると、引き受ける各ロールセッションで実行されたアクションを簡単に追跡、フィルタリングできます。または、有効なセッション名を指定できなかったユーザーをキャッチできます。セッション名を制御するその他の例については、関連する AWS ブログ投稿を参照してください。
監視する主要な CloudTrail 監査ログ
AWS の IAM ポリシーは複雑で、AWS アカウント内のすべてのリソースにアクセスするためのアクセス許可をユーザーに提供できる可能性があります。つまり、セキュリティの構成ミスにより、誰かが環境を操作し、アセットへのアクセスを強化する可能性が十分にあります。監査ログを監視することで、ユーザーアクティビティと、ユーザーによるリソース操作の全体像を把握できます。これには、ユーザーが最初にその操作を実行する権限があるかどうかも含まれます。
攻撃者は、次のようなさまざまな AWS リソースで、過度に許容的な IAM アクセス許可や構成ミスを探すことがよくあります。
- IAM ユーザー/ロール
- EC2 インスタンス
- S3 バケット
たとえば、S3 バケットには、アカウント内の認証済みユーザーだけでなく、すべての認証済みユーザーに読み取りアクセスを提供するポリシーがアタッチされている場合があります。攻撃者がこの脆弱性を発見した場合、そのバケット内に保存されているすべてのデータを読み取り、顧客またはビジネスの情報を漏洩させる可能性があります。
CloudTrail ログには、ユーザーアクティビティの信頼できる記録が含まれており、どのログに焦点を合わせるかがわかれば、環境を監視するために必要なすべての情報が提供されます。次のリソースベースのタイプのログは、脅威の大部分が発生する場所であるため、特に重要です。
これらのリソースベースの操作から生成されたサンプルログを以下で見ていきます。イベントログを読み取るときは、攻撃や構成ミスの可能性を見つけるのに役立つ JSON 属性に常に注意を払う必要があります。これには、呼び出しの応答 (つまり responseElements)、行われた API 呼び出し (つまり eventName)、コマンドを呼び出したユーザーやロールなどの識別情報 (つまり、userIdentity の下のさまざまなフィールド) などがあります。
ユーザーアカウント
攻撃者が環境に侵入する最も一般的な方法の 1 つは、公開された AWS シークレットアクセスキーを使用し、キーのアクセス許可を列挙することです。公開されたキーに広範な管理アクセス許可がある場合、攻撃者はセキュリティインフラストラクチャーを無効にしながら、自身にさらにアクセス許可を付与することができます。CloudTrail ログで次のアクティビティを監視すると、攻撃者がアクセス許可を検査し、環境内で永続性の維持を試みている攻撃者について警告を受けることができます。
不正なユーザーアクティビティのログには、responseElements に次のエラーメッセージが含まれています。
{ [...], "errorCode": "Client.UnauthorizedOperation", "errorMessage": "You are not authorized to perform this operation.", "requestParameters": { "regionSet": {} }, "responseElements": null, "requestID": "0a857cb2-90c4-4f09-9624-1149fb27f8a1", "eventID": "26fe99a5-8ed5-4923-9cf7-b6cdf96fa5f3", "eventType": "AwsApiCall", "recipientAccountId": "111111111111"}不正アクティビティログが 1 つあるだけでは、必ずしも脅威を示しているわけではありません。たとえば、ユーザーが特定の AWS コンソールリソースを表示するために必要なアクセス許可を持っていないために、不正なアクションが発生した可能性があります。または、サービスがアクセス権のないリソースを呼び出そうとした結果である可能性があります。
ただし、IAM ユーザーが認証エラーを受け取るのがこれが初めての場合は、エラーの原因を調査する価値があるかもしれません。これは、攻撃者がアカウントまたはサービスを使用してリソースにさらにアクセスしようとした結果である可能性があります。たとえば、環境へのバックドアとして新しいユーザーまたはロールを作成しようとしたり、アクセスを取得したユーザーまたはロールにすでに関連付けられている IAM ポリシーを拡張しようとしたりする場合があります。
不正または悪意のあるアクションを実行するときに検出されないようにするために、攻撃者は AWS アカウントで実行されている Amazon GuardDuty 脅威検出システムを無効にしようとする可能性があります。GuardDuty 検出システムの削除のインスタンスを調査することは常に大切です。
バケット
攻撃者は、環境を侵害しようとするときに S3 バケットを標的にすることがよくあります。ユーザーアカウントと同様に、攻撃者はセキュリティの構成ミスや人為的エラーによりバケットのコンテンツにアクセスする可能性があります。CloudTrail ログを監視することで、次のバケットの列挙と変更の攻撃手法を見つけることができます。
攻撃者が EC2 インスタンスにアクセスした場合、最初に行う可能性があるのは、関連するインスタンスプロファイルからアクセスできるすべての S3 バケットを列挙するか、バケットのアクセスポリシー全体を変更しようとすることです。ほとんどの自動化されたリソースは、必要なすべてのバケットにすでに直接アクセスできるため、通常、ListBuckets または PutBucketPolicy 呼び出しは調査する価値があります。
同様に、S3 バケットにアタッチされているパブリックアクセスブロックを削除しようとする試みは、調査が必要なイベントです。これは、正当なユーザーがデバッグメカニズムとしてセキュリティコントロールを削除することによってタスクを実行しようとしている可能性もありますが、攻撃者がバケットをパブリックインターネットに開こうとしている恐れもあります。DeleteAccountPublicAccessBlock イベントログはできるだけ早く調査することをお勧めします。
ネットワークコンポーネント
攻撃者は、VPC、ルートテーブル、ネットワークゲートウェイ、ネットワークアクセスコントロールリスト、セキュリティグループなど、構成ミスのあるネットワークリソースを介して環境にアクセスしようとする可能性もあります。CloudTrail ログは、次のタイプの考えられるネットワーク攻撃を特定し、違反を解決するための適切な手順を実行するのに役立ちます。
- AWS VPC の作成または変更
- AWS ルートテーブルの作成または変更
- AWS ネットワークゲートウェイの作成または変更
- AWS ネットワークアクセスコントロールリストの作成または変更
- AWS セキュリティグループの作成または変更
ネットワークリソースの体制をチェックし、それが安全に構成されていることを確認するには、Datadog の Compliance Monitoring ツールを使用することをお勧めします。このツールは、AWS 環境をスキャンして構成ミスをリアルタイムで検出します。
Datadog を使用した CloudTrail ログの収集および分析
AWS インフラストラクチャーのログモニタリングプラットフォームとして Datadog を使用する利点は次のとおりです。
- ログのエクスポートプロセスを合理化する AWS CloudTrail、Amazon S3、AWS Kinesis Firehose、Amazon Lambda との直接インテグレーション
- ログ処理パイプラインを使用して AWS 環境からストリーミングされるすべての AWS CloudTrail ログの自動フィールドパース
- Datadog の Logging without Limits™ を使用したすべての CloudTrail ログの費用効果の高い収集とアーカイブ
- セキュリティおよびコンプライアンス分析のログコンテキストのスコープの拡大
サービスの AWS インテグレーションをセットアップし、Datadog にストリーミングする CloudTrail ログを取得したら、カスタムダッシュボードを構築して、AWS 環境の健全性とセキュリティに関する高レベルの視点を得ることができます。また、Datadog の組み込みの脅威検出ルールを使用すると、重大なセキュリティおよび運用上の問題 (上記で説明したものを含む) が発生したときにそれを検出できます。
CloudTrail ログを Datadog にエクスポートする
CloudTrail ログを AWS から Datadog にエクスポートすると、環境の他の可観測性データで記録されたイベントを分析し、より深くコンテキスト化できます。これを行う簡単な方法は、Amazon Kinesis Data Firehose を使用することです。これは、外部データストレージおよび分析リポジトリへのリアルタイムの分散ストリーミングデータの配信を自動化するフルマネージド型の AWS サービスです。
AWS データ配信に Kinesis Data Firehose を使用すると、ほぼリアルタイムのアップロード、サーバーレスデータ変換オプション、AWS サービスの完全なスイートとのインテグレーションなどの多くの利点があります。Datadog で使用するために Kinesis Data Firehose を設定する手順については、ブログ投稿を参照してください。
Datadog で CloudTrail ログを調べる
監査ログが Datadog のログエクスプローラーにストリーミングされると、それを簡単にフィルタリング、検索して、特定のユースケースで最も重要なログを見つけることができます。たとえば、監視する主要な AWS 監査ログを参照して、ユーザーがセキュリティグループのアクセス許可を作成または変更しようとしたイベントを探すことができます。これを行うには、ログをフィルタリングして CreateSecurityGroup、AuthorizeSecurityGroupIngress、または AuthorizeSecurityGroupEgress イベントを探します。
監査ログをフィルタリングして潜在的な問題を見つけるだけでなく、監査ログを使えば、カスタムデータ視覚化による高レベルの Datadog ダッシュボードを構築できます。こうすれば、受信ログを際限なくフィルタリングすることなく、受信ログのトップダウンの視点をすばやく取得できます。
リアルタイムでセキュリティの脅威を検出する
Datadog Security Monitoring を使用すると、セキュリティの脅威が発生したときにそれをキャッチできるため、イベントストリームが取り込まれるときにイベントストリーム全体に厳密な検出ルールを適用できます。検出ルールはすぐに利用でき、MITRE ATT&CK® フレームワークによって列挙された攻撃手法と照合します。これは、すでに説明した重要なイベントタイプの多くをカバーしています。さらに、環境の特定のニーズに基づいてイベントを評価する場合は、独自のルールを作成できます。
着信イベントが検出ルールの 1 つと一致すると、Datadog はセキュリティシグナルエクスプローラーで検査できるセキュリティシグナルを作成します。セキュリティシグナルは、問題のアクションを開始したユーザー名と IP アドレス、イベント自体のタイムライン、脅威に対応するための標準化されたガイドラインなど、各トリガーイベントに関するコンテキストを提供します。
AWS CloudTrail 監査ログの監視を始める
この投稿では、AWS CloudTrail 監査ログの解釈方法を確認しました。各イベントタイプがどのように機能するかを確認し、複数のログでユーザーとロールをフォローするためのベストプラクティスを説明し、調査する最も重要な監査ログを強調しました。また、Amazon Kinesis Data Firehose を使用して CloudTrail ログを Datadog にインポートする方法と、Datadog を使用してログをトリアージし、発生したセキュリティの問題を検出するための最良の方法についても説明しました。AWS 監査ログの監視と Datadog を使用したアプリケーションの保護の詳細については、ドキュメントをご覧ください。また、Datadog をまだ使用していない場合は、ぜひ 14 日間の無料トライアルをご利用ください。
