Microsoft Sentinel を用いて、Amazon SQS サービス経由で AWS CloudTrail ログを収集、分析してみよう

# 1. はじめに
Microsoft Sentinel では、コネクターを用いて様々なログを収集することが出来るのですが、AWS Cloud 向けに S3 Bucket の Amazon SQS 経由によるデータコネクターがリリースされていました。Microsoft の [Document](https://learn.microsoft.com/ja-jp/azure/sentinel/connect-aws?tabs=s3) では分かり難いところもあるので、手順について整理も含めて記事にしてみました。

# 2. 環境について
Microsoft Sentinel と AWS Cloud のデータ収集の接続構成図は次のようなイメージです。
- AWS 側で対象のデータソースを Amazon S3 Bucket に保管収集する（本記事では CloudTrailを対象にしています）
- S3 Bucket の通知設定を用いて、新規分のデータを Amazon SQS のキューに転送する
- Azure 側では、AWS 側の IAM ロールを用いて、Amazon SQS のキューをポーリング収集する
- Log Analytics ワークスペースに ``AWSCloudtrail`` テーブルが作成される
- Microsoft Sentinel 側で、分析ルール / 可視化ブックを用いて分析を行う

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/acff259a-cd02-64f9-993f-21279ac0249a.png)

# 3. やってみる
以下、設定手順の流れです。
AWS 環境の構成用に自動化ツールとして専用の PowerShell スクリプトも配布されていますが、AWS 側の既存の CloudTrail 設定を用いず新たに新規作成してしまうため、今回は手動による設定手順をまとめています。

## 3.1 Azure 側 - Microsoft Sentinel に「Amazon Web Services」をインストールする
 - コンテンツハブから、AWS 用のパッケージである「Amazon Web Services」をインストールします
 - コンテンツハブの導入を行うことで、AWS 接続用のデータコネクターや、可視化ブック、分析ルールのパッケージが使えるようになります
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/c76f513d-aa38-b13f-83ac-6833038a1783.png)

## 3.2 Azure 側 - データコネクターの設定から、Sentinel ワークスペース ID を記録する
 - コンテンツハブでインストールした後、データコネクター設定から「Amazon Web Service S3」を開きます
 - 設定情報に「External ID (Workspace ID)」をコピーして控えておきます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/12cbc031-3292-0f81-13d9-c7fc14fa8482.png)

## 3.3 AWS 側 - Amazon SQS キューの作成
 - AWS CloudTrail ログ更新をキューイングさせるため、Amazon SQS キューを作成します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/932f140f-255e-4628-34e1-16bb60f7fe30.png)
 - SQS キュー側のポリシー設定で、CloudTrail (Amazon S3) からのデータアップロードを許可するポリシーを設定します
     - この部分が Microsoft 側ドキュメントに記載されておらず、分かり難いです
     - AWS 側の設定になりますが、S3 Bucket からの ``SendMessage`` アクションを許可する必要があります

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:ap-northeast-1:(AWSアカウントID):(SQSリソース名)",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::aws-cloudtrail-logs-xxxxxxxxxxx-xxxxxx"
        }
      }
    }
  ]
}

```

## 3.4 AWS 側 CloudTrail ログ保管 S3 Bucket の通知設定
 - CloudTrail のログ保管先 S3 Bucket のイベント通知設定より、SQS キュー通知を設定します
 - 前 Step の許可ポリシーが投入されていれば、設定の保存が出来るはずです

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/04cea8eb-63e5-e91c-89db-0e8cfb092a1b.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/716049a7-7026-c762-3f2b-776d6b11977e.png)

## 3.5 AWS 側 IAM 設定
　- [MS Learn の手順](https://learn.microsoft.com/ja-jp/azure/sentinel/connect-aws?tabs=s3#create-an-open-id-connect-oidc-web-identity-provider-and-an-aws-assumed-role)に従い、OIDC プロパイダーと IAM ロールの設定を行います
  - Microsoft Defender for Cloud の設定を行っている場合は、既に OIDC プロパイダーが設定されています（同じ OIDC プロパイダーを使います）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/12a11153-ca10-26d4-b3e6-388f9784a5de.png)

 - [MS Learn の手順](https://learn.microsoft.com/ja-jp/azure/sentinel/connect-aws?tabs=s3#create-an-open-id-connect-oidc-web-identity-provider-and-an-aws-assumed-role)に従い、対象者として API を追加します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/f4defb6f-4c0d-42ad-9750-e51e0916ea54.png)

 - Microsoft Sentinel が用いる IAM ロールを作成します
     - IAM ロール名は指定があり **OIDC_** で始まる命名規則にする必要があります
     - 本記事では ``OIDC_MicrosoftSentinelRole`` で作成しました
     - 「信頼されたエンティティ」の欄に、``"sts:RoleSessionName": "MicrosoftSentinel_{WORKSPACE_ID)"`` のフォーマットで、3.2 項で控えたワークスペース ID の情報を追加します
     - 許可ポリシーとして 4 つを追加します
         - ``AmazonSQSReadOnlyAccess``
         - ``AWSLambdaSQSQueueExecutionRole``
         - ``AmazonS3ReadOnlyAccess``
         - ``ROSAKMSProviderPolicy``

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/c4a84a41-a139-cb1e-712e-b2f3723e396f.png)

## 3.5 Azure 側 Sentinel データコネクターの設定
 - AWS 側の設定が完了しましたら、Sentinel データコネクターのパラメータを投入して保存します
 - パラメータとして以下の情報が必要です
     - AWS 側 IAM ロールの ARN 名
     - Amazon S3 から通知させた Amazon SQS の URL 情報
     - 宛先テーブル（CloudTrail / VPC FlowLog / Amazon GuardDutyが選択可能）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/5bf486d8-9e5a-1546-c616-f56ca96d130a.png)

 - 設定が無事に投入できると、「ロールARN / キュー URL / 宛先」に反映されます（認証エラーなどで接続が出来ないと、設定情報が反映されずにエラーが出力されます）
 - 複数のデータソース (CloudTrail / Amazon GuardDuty / VPC Flow Log / CloudWatch Log など）を設定する場合は、3.3 ～ 3.4 の設定を繰り返してください
 - 

## 4. 動作確認
データコネクターの設定が反映されると、数分後に Amazon SQS キュー経由で Sentinel / Log Analytics ワークスペースに反映されます。
直近のデータの送受信の確認については、Amazon SQS のメトリクス画面を見ると、送信/受信のメッセージ数が双方カウントされることで、キューの受け渡しが出来ていることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/dcbda95c-056f-c1f4-cc3b-a19be33b322d.png)

データコネクターのページだと、暫く時間が経過した後に受信データが上がり、Log Analytics ワークスペースに取り込まれたことが分かります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/bfe36561-d0bb-0a66-37f5-d82c520a660a.png)

# 5. Sentinel での分析
## 5.1 可視化ブックの確認
Microsoft Sentinel では、AWS CloudTrail 用の専用可視化ブックが提供されています。
AWS User Activities を開くと、CloudTrail ログからユーザーのアクティビィティ状況が確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/cf47ac73-7f63-8864-1e71-c42724639cd0.png)

## 5.2 Sentinel 分析ルールの有効化
「Amazon Web Services」コンテンツハブをインストールすると、AWS CloudTrail 用の異常検知ルールが提供されています。VPC や CloudTrail そのものの変更、FullAdmin ポリシーのロールアタッチなど、脅威と判定したいものを有効化してみてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/f9f30988-0ef4-7839-d36c-51dc1e85dc15.png)

ルールの詳細は GitHub レポジトリにも公開されています。

https://github.com/Azure/Azure-Sentinel/tree/master/Detections/AWSCloudTrail

## 6. チューニング - 不要なログをそぎ落とす
AWS CloudTrail のログを取り込んで気付いたのですが、別途設定していた Microsoft Defender for Cloud の CSPM 監査ポーリングが大量に記録されていることに気付きました。このような別途監視しているサービスのデータは記録上不要なので、取り込まないフィルターをかけたいと思います。

以下は Microsoft Defender for Cloud が利用する ``CspmMonitorAws`` ロールが CloudTrail に記録されたログです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/c6aba034-13ef-d5df-7dcf-cf4f6b76eb94.png)

Log Analytics ワークスペースの[テーブルの変換](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/data-collection-transformations)を用いて、不要なデータを削除します。
Log Analytics ワークスペースから対象のテーブルを選択し、「変換の編集」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/b5801917-5019-1ee3-8eda-3d6883a7c363.png)

対象のテーブルに対して、KQL を用いて変換を行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/653790/b6a3e5d7-7353-87ec-6f9b-356dbbacb201.png)

今回の Log Analytics ワークスペースでは、以下のように Microsoft Defender for Cloud が用いる IAM ロール名を除外するように設定しました。

```sql
source
| where SessionIssuerUserName !in~ ("CspmMonitorAws", "DefenderForCloud-OidcCiem", "DefenderForCloud-AgentlessScanner", "DefenderForCloud-DataSecurityPostureDB")
```

# 7. まとめ
Microsoft Sentinel を用いて、AWS 各種ログを取得する方法、解析・分析する方法をご紹介しました。データコネクターが提供されていると、設定が容易になり、Microsoft Sentinel 側からの監視も容易になりそうです。
本記事がどなたかの参考になれば幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。