[アップデート] CloudTrail Lake のイベントデータストアがリソースベースポリシーをサポートし、クロスアカウントアクセスが可能になりました

あしざわです。

去年2024年11月のアップデートなのですが、CloudTrail Lake に以下2つの新機能が追加されていました。

• 包括的なダッシュボード機能の追加
• イベントデータストアのクロスアカウント共有機能の追加

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/aws-cloudtrail-lake-analytics-cross-account-data-access/

担当している案件で「イベントデータストアのクロスアカウント共有機能」を試す機会がありました。

このブログで本機能の仕様の紹介や使用感をお伝えしたいと思います。

機能の概要

CloudTrail Lake とは、CloudTrail のクエリ実行環境が簡単にデプロイできるサービスです。

https://dev.classmethod.jp/articles/aws-cloudtrail-lake-audit-security/

CloudTrail Lakeは、AWSが管理する形で作成するイベントデータストアというストレージにCloudTrailログを保管します。

利用開始のためには、まずイベントデータストアの作成から始めることになります。

CloudTrail Lakeのイベントデータストアを作成すると、このようなクエリエディタがマネジメントコンソール上から利用でき、Athenaなどのサービスの利用なしで直接クエリを実行できます。

ただし、従来のCloudTrail Lake のクエリエディタは、イベントデータストアを管理しているアカウントでないと利用できませんでした。つまり、他のAWSアカウントからのクエリ実行がサポートされていませんでした。

今回のアップデートでCloudTrail イベントデータストアにリソースベースポリシーを追加することで、イベントデータストアへのクロスアカウントアクセスを提供できるようになりました。

何が嬉しいのか

これまでのAWSマルチアカウント環境におけるCloudTrailログ管理の観点で、以下の4つの要素をうまく満たす良いソリューションがなく、課題となっていました。

• シンプルなアーキテクチャ
• 安価なコスト
• ログの一元管理、集約
• ログへのセキュアなアクセス

例えば以下記事では、以前から保存しているCloudTrail ログへのクロスアカウントアクセスに苦労した様子が紹介されています。

• クロスアカウントでCloudTrailの証跡ログを参照する際にハマったこと #AWS - Qiita

以下記事では、アカウント毎の2個目以降のCloudTrail 証跡による追加課金を回避するために、ログアーカイブアカウントにレプリケーションしてログを一元管理する構成をとっています。

• CloudTrail証跡をS3レプリケーションで集約管理してみた | DevelopersIO

上記以外にも、CloudTrailログの一元管理にControl Tower 管理のCloudTrail 組織証跡を使っている場合、ログ保存用のS3バケットポリシーがSCPの影響で更新ができないという障壁もありました。

以前のCloudTrail Lakeだと、追加コストは多少発生しますが、クロスアカウントのアクセスがサポートしておらず、「ログへのセキュアなアクセス」の実装が難しい状態にありました。

• シンプルなアーキテクチャ
• 安価なコスト (CloudTrail Lakeの維持コストは発生)
• ログの一元管理、集約
• ログへのセキュアなアクセス

今回のアップデートによって、CloudTrail Lake へのクロスアカウントアクセスをサポートしたことで、以下の4つの要素をほぼ満たすアーキテクチャとなりました。

• シンプルなアーキテクチャ
• 安価なコスト (CloudTrail Lakeの維持コストは発生)
• ログの一元管理、集約
• ログへのセキュアなアクセス

やってみた

ここからは、CloudTrail Lake イベントデータストアへのクロスアカウントアクセスを検証してみます。

検証には、事前にCloudTrail Lake イベントデータストアを有効化しているOrganizations組織を利用します。

ここで表記している「管理アカウント」とは、CloudTrail Lake のイベントデータストアを管理しているAWSアカウントのことです。

クロスアカウントアクセスを試す上では基本的にどのアカウントでも問題なく、Organizationsの管理アカウントと必ずしも一致する必要はありません。

ただし、この構成のよくあるユースケースは、「Organizations組織単位で取得しているイベントデータストアをメンバーアカウントからクエリアクセスさせたい」というものかと思います。

その場合、組織のイベントデータストアを作成する必要があります。組織のイベントデータストアの作成は、Organization管理アカウントもしくはOrganizationsによりCloudTrailの管理者権限を委任されたAWSアカウントのいずれかである必要があるので注意しましょう。

• 組織のイベントデータストアについて - AWS CloudTrail

環境準備

始めに、イベントデータストアのリソースベースポリシーを設定し、アカウントA、アカウントBからのイベントデータストアへのアクセスを許可します。

CloudTrailのマネジメントコンソールから、Lake > イベントデータストアにアクセスし、ポリシーを設定したいイベントデータストアの詳細画面に移動します。

画面を下の方にスクロールすると、リソースベースポリシーの項目があります。今は関連付けされていないことがわかります。

編集をクリックすると、リソースベースポリシーの入力欄が現れます。

入力欄に以下のポリシーを入力し、設定を保存します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "policy1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
            "arn:aws:iam::<アカウントAのAWSアカウントID>:root",
            "arn:aws:iam::<アカウントBのAWSアカウントID>:root"
        ]
      },
      "Action": [
        "cloudtrail:StartQuery",
        "cloudtrail:DescribeQuery",
        "cloudtrail:GetEventDataStore",
        "cloudtrail:GetQueryResults"
      ],
      "Resource": "arn:aws:cloudtrail:<リージョン名>:<管理アカウントのAWSアカウントID>:eventdatastore/<ランダム文字列>"

    }
  ]
}

ポリシーは、以下公式ドキュメントのサンプルを参考に作成しました。

• AWS CloudTrail リソースベースのポリシーの例 - AWS CloudTrail

サンプル通りのポリシーにすると権限不足でクロスアカウントアクセスできなかったため、検証の結果必要だとわかったcloudtrail:DescribeQueryを追加しています。

なお現在のPrincipalでは、そのアカウントの全てのIAMリソースからのアクセスを許可しているため、本番環境で利用する時は要件に応じて範囲を狭めるように設定することをお勧めします。

設定保存後、イベントデータストアの詳細ページに遷移しました。

以上で準備は完了です。

クエリ実行

はじめに、管理アカウントでイベントデータストアのクエリ実行ができるか試してみます。

クエリエディタの画面がこちらです。イベントデータストア名が自動補完され、イベントデータストア名に紐ついたIDも同時に表示されていますね。

以下のクエリを実行します。

SELECT element_at(requestParameters, 'roleArn') as roleArn,
    count(*) as timesAssumed
FROM <イベントデータストアID>
WHERE eventSource = 'sts.amazonaws.com'
    AND eventName = 'AssumeRole'
    AND eventTime > DATE_ADD('week', -1, CURRENT_TIMESTAMP)
GROUP BY element_at(requestParameters, 'roleArn')
ORDER BY timesAssumed DESC

このクエリは、サンプルクエリの「Get the most frequently assumed IAM roles」をサンプルのまま貼り付けたものです。

サンプルクエリから利用したいユースケースを検索しリンクをクリックすると、クエリエディタで指定しているイベントデータストアを入力した状態のクエリを展開してくれます。

そのまま実行します。

クエリ結果欄に結果が表示されましたね。表示されるかを見たいだけなので詳細についてはあまり見ていません。

続いて、マネジメントコンソールでログインしているAWSアカウントを変更し、リソースベースポリシーで許可したアカウントAもしくはアカウントBでログインし直します。

CloudTrail Lakeのクエリエディタ画面に遷移し、イベントデータストア欄にクロスアカウントアクセス先のイベントデータストアのARNを手動で入力し、クエリを実行します。後述しますが、ARNの自動入力補完は利用できないようです。

リソースベースポリシーで指定したアカウントA、Bどちらでクエリを実行しても、問題なく結果が取得できました。

参考情報：イベントデータストアのARN入力欄について

クエスアカウントアクセスする際、イベントデータストアのARNを手動入力します。

入力するとイベントデータストアIDが下に表示されますが、これはARNからイベントデータストアIDのみを抜粋しているだけのようです。

末尾を1文字変えて存在しないIDにしてみても、エラーにはならず同じように表示が変わりました。ARNが有効であるか静的にチェックしているわけではなさそうですね。

また、クロスアカウントアクセス可能なイベントデータストアは自動補完されません。自動で表示されるARNはログイン中のAWSアカウントにあるイベントデータストアだけなので注意です。

毎回手動で入力しなければならないので、クロスアカウントアクセス可能なイベントデータストアも入力補完の対象になると便利だと思いました。

さいごに

このブログでは2024年11月に追加されたCloudTrail Lake の新機能である「イベントデータストアのクロスアカウント共有機能」のサービスの紹介と検証を行いました。

イベントデータストアにクロスアカウントアクセスできるようになったおかげで、CloudTrail Lake を利用している場合でも、メンバーアカウントから過去のCloudTrailイベントへのアクセス経路が確保できるようになります。

CloudTrail の運用管理を非常に楽にしてくれる良い機能だと思いますが、まだリリースされたばかりの機能のため、まだまだ必要な機能や不十分な点が目立ちます。

例えば以下のような点です（いくつかは本文の中でも紹介しています）

• イベントデータストアを選択する際、アクセス可能なイベントデータストアARNを自動入力補完してほしい
• イベントデータストアの内部までより細かいアクセス制限したい (特定のAWSアカウントIDの情報だけ閲覧可能にする、など)

特に後者のより細かいアクセス制限は、組織全体にCloudTrail Lake のアクセス権限を配布していく場合、必須になると思っています。

CloudTrail Lake は、安価な料金プランが登場したり、ここ2年くらいでますます使いやすくなっているサービスです。

https://dev.classmethod.jp/articles/aws-cloudtrail-lake-update-new-pricing-option-for-1year-data-minimum-retention-period/

ガンガン使って積極的にAWSにフィードバックして、良い機能にしていければいいなと思っています。

以上です。ご拝読ありがとうございました。