AWS CloudTrailのログをSQS方式でSIEMに取り込む
はじめに
こんにちは。
昨今は企業のクラウド利用が進んでおり、ハイブリッドクラウドはもちろんクラウドオンリーの構成も見かけるようになってきましたね。オンプレミスの時代からサーバやサービス、ネットワーク機器のログを集約して分析したり、監視したりすることが行われており、ログの転送方式としてはSYSLOGが一般的ではありますが、クラウドサービスのログを取得する場合は、そのクラウド独自のサービスや機能を使う場合が多いのが現状です。
今回はAWSの監査ログであるCloudTrailイベントをSIEM(Security Information and Event Management)製品に取り込んでみたいとおもいます。
構成
今回の構成は以下の図の通りです。SIEM製品にはRapid7社のInsight IDRを使用します。AWSのCloudTrailイベントを取り込むことを目的とし、方式としてはSQS(Simple Queue Service)を利用したものを採用します。なお、この方式はほかの製品（例えばSplunkやQRaderなど）でも利用できるものになります。(*1)
*1 細かい設定は製品によって異なる部分もあるかと思いますので、各種リファレンスガイドなどをご確認ください
大まかな流れとしては以下の通りです。
CloudTrailでイベントが発生するとS3バケットにイベント（ログ）が保存される
ログが保存されるとSNSトピックにその旨が通知される
SNSトピックに更新があるとSQSのキューがたまる
SIEMがSQSのキューをポーリング（定期的に確認）する
キューがたまっているとそれに対応するログをS3バケットに取りに行く
設定手順
以下の流れで設定していきます。
CloudTrailでイベントを記録するように設定
CloudTrailイベントの保存先のS3バケットを指定
CloudTrailでSNSトピックを有効化
SQSでキューを作成
SQSキューの設定でCloudTrailのSNSと関連付ける
SIEMがログを取得するためのIAMポリシーを作成
S3バケットポリシーを設定
SIEM側でログの取り込み設定
CloudTrailの設定
すでにCloudTrailを有効にされている場合はこの手順はスキップしてください。
まず、CloudTrailのサービスにアクセスし、証跡の作成に進みます。 証跡ログはS3に保存されるのですが、ここでは新規バケットを作成するか既存のバケットを使用するか選択できます。今回は新規バケットを作成することにします。
今回の設定のポイントとして、SNSトピックの有効化があります。その他設定で「SNS通知の配信」を有効にします。新規SNSトピックを作成を選択します。そうすると、SNSトピックのコードが自動的に生成されます。
SQSキューの作成
SQSサービスにアクセスします。トップページに「キューを作成」というボタンがあるので押下します。
キューの種類として「標準」と「FIFO」が選べますが今回は「標準」を選択します。名前は任意です。その他設定値はお好みで変更してください。デフォルト値でも問題ありません。
キューの作成が完了すると、一覧から作成したキューが確認できます。
SQSキューとSNSトピックの関連付け
次に、作成したキューにSNSトピックを関連付けします。この操作をAWSでは「Amazon SNSトピックにサブスクライブ」すると言います。
Amazon SOS＞キュー＞先ほど作成したキュー と進み、画面下部にいくと以下のようにSNSサブスクリプションの設定画面が見えますので、「Amazon SNSトピックにサブスクライブ」のボタンを押下します。
ここでCloudTrailの設定で有効にしたSNSトピックが出てくるので選択し保存します。
先ほどは空だったSNSサブスクリプション一覧に追加したSNSトピックが表示されます。リージョンごとに表示フィルタがかかっているので、もし表示されていない場合は「サブスクリプションリージョン」を適切なリージョンに変更してみてください。
IAMポリシーの作成
SIEMがログを取得するために必要な権限をIAMポリシーで設定します。IAM ＞ ポリシー と進んで新規に「ポリシー」を作成します。以下のようなJson形式でポリシーを記述します。自身の環境に応じて設定するべき場所は3か所(３行)になります。
XXXX：CloudTrailのARNを設定する
YYYY：SQSキューのARNを設定する
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXXXXXXXXXXXXXXX",
"arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXXXXXXXXXXXXXXX"/*"
]
},
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage"
],
"Resource": [
"arn:aws:sqs:ap-northeast-Y:YYYYYYYYYYYY:YYYYYYYYYYYYYYYYYY
]
}
]
}
Json形式のルールを投入できたら、任意の名前を決めてポリシーの作成をします。
IAMユーザーの作成
次に作成したポリシーを割り当てたIAMユーザを作成します。これはSIEMがログを取得するために使用するアクセスキーになります。
IAM ＞ ユーザー と進んで新規に「ユーザー」を作成します。名前は任意に入力し「アクセスキー・プログラムによるアクセス」を選択します。
先ほど作成したIAMロールをアタッチし、ユーザーの作成を完了させます。 最後に作成したユーザのアクセスキーとシークレットキーが記載されたCSVファイルをダウンロードできるので、安全な場所に保管しておいてください。後ほどSIEMの設定で使用します。
S3バケットのポリシー設定
次に、CloudTrailログが保存されているバケットのアクセス許可ポリシーを設定します。
該当のバケット>アクセス許可 と進み、バケットポリシーを編集します。既存のポリシーが存在しているので、以下のポリシーを追記します。既存のポリシーは消さないように注意してください。自身の環境によって書き換える場所は以下の通りです。
arn:aws:iam::[UserID]:user/[User Name] →先ほど作成したIAMユーザのARNを記述します
arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXXXX →CloudTrailが保存されているS3バケットのARNを記述します
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[UserID]:user/[User Name]"
},
"Action": "s3:List*",
"Resource": [
"arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXXXX",
"arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXXXX/*"
]
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[UserID]:user/[User Name]"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::aws-cloudtrail-logs-XXXXXXXXX/*"
}
以上でAWS側の準備は完了です。
SIEM側のログ取り込み設定
SIEM側のログ取り込み設定を行っていきます。今回はRapid7のInsight IDRを使用しますので、管理コンソールにログインします。 (SIEM側の環境構築、初期設定は完了している前提です)
Data Collection＞Add Event Source と進みます。ログを収集するコレクターを選択し、Select Event Source Typeで「AWS CloudTrail」を選択します。Collection Methodは「SQS Message」を選択します。その他項目は任意で設定します。
下にスクロールしていくと、以下のような設定項目があります。AWS AuthenticationはIAM User Credentialを選択します。Credentialで先ほど作成したIAMユーザーのアクセスキーを入れていきます。SQS Queue URLは作成したキューのURLを入力します。Bucket Region Nameはログが保存されているS3バケットのリージョンを選択します。これは製品の仕様なのですが、執筆時点(2022.07)において日本国内では大阪リージョンに対応していないのでご注意ください。最後に「Save」を押下します。
ログの受信確認
Data Collection Management＞Event Source で先ほど追加したログの取り込み設定が確認できます。ステータスが「Running」でEPMに何かしら正の数字が表示されていれば正常にログが受信できています。エラーが発生している場合はこの画面にエラーメッセージが出てきます。よくあるエラーの原因としてはIAMロールの設定不備、S3バケットのアクセス権限設定不備が考えられますのでエラーメッセージを参考に適宜見直してみてください。
次にLog Searchから実際のログを確認してみます。CloudTrailログはCloud Service Activityカテゴリに分類されていますので、左側の項目にチェックを入れます。そうするとCloudTrailログが出てくるはずです。以上で設定は完了です。お疲れ様でした！
おわりに
今回はAWSの監査ログであるCloudTrailイベントをSIEM製品に取り込んでみました。CloudTrailにかかわらず、S3に保存されるログについてはSNSトピックとSQSキューを使うことで外部のシステムに取り込み可能なものが多いので、まずは受け側のシステムの機能・仕様を確認してみましょう。
また弊社セキュリティサービス部ではセキュリティコンサルティングの一環としてお客様のニーズに合わせた各種SIEM製品の導入支援も行っておりますので、お気軽にお問合せいただいたければと思います。
執筆者プロフィール: Yutaka Takahashi
ネットワーク、インフラ、SOC運用等を経験し現在は情報セキュリティの案件を中心に担当。 最近はクラウドサービスについて勉強中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/