[アップデート] CloudTrail Lake で AWS 以外のアクティビティイベントをデータストアへ取り込めるようになりました

#AWS CloudTrail Lake

#AWS

いわさ

2023.02.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

先日のアップデートで AWS CloudTrail Lake が AWS 外からのアクティビティイベントの取り込みをサポートしました。

CloudTrail Lake は別途 Athena を用意せずに簡単に CloudTrail イベントが分析出来るサービスとして登場しました。

今回のアップデートによって CloudTrail だけでなく AWS 以外のアクティティログも取り込んで分析出来るようになります。

いくつか対象サービスがあるのですが、今回は GitHub からの取り込みを試してみたので検証内容などを紹介します。

取り込み設定

CloudTrail Lake で外部からの取り込みを行うためには、まずは CloudTrail Lake の Integrations から新しい Integration の作成を行います。

Integration では取り込み元のソースと、送信先のデータストアを指定します。

取り込み元ソースは本日時点で以下の 15 のパートナー製品がサポートされています。

Cloud Storage Security
Clumio
CrowdStrike
CyberArk
GitHub
Kong Inc
LaunchDarkly
Netskope
Nordcloud
MontyCloud
Okta
One Identity
Shoreline.io
Snyk
Wiz

その他、独自カスタム統合を作成することでサポート外のソースを取り込むことも可能です。

データストアは CloudTrail 用のものとは別で用意する必要があります。
Integration 用に作成するデータストアはイベントタイプが CloudTrail のものとは異なっています。

後述しますが、Integration は外部に取り込み用のエンドポイントを公開するための設定のようなもので、CloudTrail Lake 側で取り込みを主体的に行うものではありません。
そのため、どの頻度で取り込みを行うとかといった設定もしません。

Integration の作成が完了しました。
表示されている Channel ARN を使って外部からアクティビティログを送信します。

Status が Incomplete になっているのはまだ取り込みが成功していないからです。
後ほど取り込みをした際にステータスを再確認してみましょう。

GitHub から取り込む仕組み

AWS 側の設定は Integration を作成するところまで基本設定は終わりです。
他にはメッセージ送信の際に IAM ユーザーに紐づくアクセスキー、あるいは OIDC で取得した一時認証情報が必要になりますが、そのあたりは割愛します。

仕組みですが、まず GitHub は監査ログを Amazon S3 や Azure Blob Storage、 Google Cloud Storage へ連携する機能を備えています。
こちらは GitHub Enterprise の機能です。

今回は以下の仕組みを使って S3 へ出力された GitHub 監査ログを Lambda や SQS を使って CloudTrail Lake へ送信する仕組みとなっています。
つまり前提として GitHub は Enterprise である必要があります。

aws-cloudtrail-lake-github-audit-log/ at main · aws-samples/aws-cloudtrail-lake-github-audit-log · GitHub より引用

ここでちょっと心が折れそうになりましたが、CloutTrail Lake へ送信しているスクリプトと同じやり方で独自で送れるのでは、と思ったので送信部分をローカルで実行して GitHub 用に構築した CloudTrail Lake の Integration にログっぽいものを送信してみることにしました。

参考にしたコードは以下です。

GitHub からの取り込みを想定して手動取り込みしてみる

AWS CLI もアップデートされていて、新たにcloudtrail-dataというサブコマンドが提供されています。
この中のput-audit-events相当の API が上記コードでは実行されていました。

コマンドを実行するにあたって必要なログフォーマットですが、それは以下に統合用のイベントスキーマ情報が公開されていますのでそちらを使って頑張ってみます。

取り込み

今回取り込みにあたり、先程のイベントスキーマ情報を参考に以下のデータを用意しました。
それぞれのフィールドに制約があるので詳しくはドキュメントを確認いただく必要がありますが、userIdentity.detailsについてはイベントソースごとのフリーフォーマットが設定されるようです。

また、eventSourceについてはイベントソースごとに固有のようなので、こちらも気をつける必要があります。github.audit.streamingについては参考コードで設定している箇所があったので使ってみました。

recipientAccountIdは送信先の CloudTrail Lake を構成している AWS アカウント ID です。

{
    "version": "1.0",
    "userIdentity": {
      "type": "hogetype",
      "principalId": "hogeprincipal",
      "details": {
         "GitHubOrganization": "hogeOrg",
         "Repository": "hogeRepo",
         "Location": "hogeLocation"
      }
    }, 
    "userAgent": "hogeagent",
    "eventSource": "github.audit.streaming",
    "eventName": "hogename",
    "eventTime": "2023-02-02T07:10:00Z",
    "UID": "hogeuid2",
    "requestParameters": {
       "hogeparam": "val2"
    },
    "responseElements": {
       "hogeelements": "val3"
    },
    "errorCode": "hogeerror",
    "errorMessage": "hogeerrormsg",
    "sourceIPAddress": "203.0.113.1",
    "recipientAccountId": "123456789012",
    "additionalEventData": {
       "hogeadd": "val4"
    }
}

上記をインプットパラメータとして文字列で設定する必要があるので、以下を参考にエスケープ処理しました。

% cat hogetmp.json | jq '@json' | pbcopy

AWS CLI に引き渡すパラメータの本体は以下です。
ハイライト部分は先程エスケープした文字列を値として設定しています。
コマンドによるとチェックサムを使った検証も出来るのですが、オプションなので今回は割愛しました。

[
    {
        "eventData": "{\"version\":\"1.0\", ... \"additionalEventData\":{\"hogeadd\":\"val4\"}}",
        "id": "hoge001"
    }
]

先程マネジメントコンソールで作成した Integration の Channel ARN を使ってパラメータを送信します。
フォーマットに不正があればこの時点で検証エラーが発生します。

% aws-v1 cloudtrail-data put-audit-events \
   --audit-events file://hoge.json \
   --channel-arn "arn:aws:cloudtrail:ap-northeast-1:123456789012:channel/843962a8-c621-491a-a9ac-f202b689c2e9" --profile hogeadmin
{
    "failed": [],
    "successful": [
        {
            "eventID": "ff1f06e0-cac2-42a4-86d0-6ebe50df45ed",
            "id": "hoge001"
        }
    ]
}

メッセージの取り込みに成功したようです。
先程の Integration のステータスを見てみるとアクティブになっています。これは良さそうですね。