いわさです。
先日のアップデートで 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 である必要があります。
ここでちょっと心が折れそうになりましたが、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 です。
hogetmp.json
{
"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' | pbcopyAWS CLI に引き渡すパラメータの本体は以下です。
ハイライト部分は先程エスケープした文字列を値として設定しています。
コマンドによるとチェックサムを使った検証も出来るのですが、オプションなので今回は割愛しました。
hoge.json
[
{
"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 のステータスを見てみるとアクティブになっています。これは良さそうですね。
クエリ
最後に、取り込まれたアクテビティログをクエリしてみます。
注意点として、データストアが CloudTrail と違うものなのでクエリエディター上で切り替えてイベントデータストア ID を取得してください。
適当に SELECT してみますが、成功しましたね。
先程エスケープした JSON データはeventDataとして取得が出来ます。
後は通常の CloudTrail Lake におけるクエリの話なので深堀りしませんが、フィルタリングしたりフィールドを指定したり、好きなように分析することが出来ます。
さいごに
本日は CloudTrail Lake で AWS 以外のアクティビティイベントをデータストアへ取り込めるようになったので試してみました。
CloudTrail のログを別の SIEM に取り込むパターンはいくつか見たことがあるのですが、CloudTrail Lake で集中管理しようという逆のパターンでしょうか。
re:Invent 2022 では Config の設定項目情報も取り込めるようになっていたので、今後どういう位置づけになるのか気になるところです。
25
