Microsoft DefenderポータルでMicrosoft Sentinelを使っている管理者にとって、Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log dataの重要点は、AWSログ取り込みの中心が「S3バケットから取得する新しいAWS S3コネクタ」に整理されていることです。対象はVPC Flow Logs、GuardDuty findings、CloudTrail、CloudWatch logsで、従来のCloudTrail専用コネクタとは運用設計が変わります。(Microsoft Learn)
特に確認すべきなのは、S3バケット、SQSキュー、OIDC、IAMロール、ログ形式、Content HubのAWSソリューション、そしてMicrosoft Defenderポータルへの移行方針です。設定だけを急ぐと、ログが入らない、30分以上遅延する、SQSやKMS権限で詰まる、同じCloudTrailを二重取り込みする、といった問題が起きやすくなります。(Microsoft Learn)
Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log dataの要点
2026年5月14日に更新された公式情報では、Amazon Web ServicesのサービスログをMicrosoft Sentinelへ取り込むコネクタとして、新しいS3 connectorとCloudTrail connector legacyが分けて説明されています。新しいS3 connectorは、AWSサービスが出力したログをS3バケットに集約し、SQS通知を使ってMicrosoft Sentinelがログファイルの場所を把握して取り込む方式です。(Microsoft Learn)
対象となるAWSサービスログは、主に次の4種類です。
| AWSサービス | 取り込むログ | 主な用途 | 確認すべきポイント |
|---|---|---|---|
| Amazon VPC | VPC Flow Logs | 通信元、通信先、ポート、許可・拒否の把握 | GZIP形式のCSV、ヘッダーあり、区切り文字がスペース |
| Amazon GuardDuty | Findings | AWS上の脅威検知結果の集約 | json-lineおよびGZIP形式、KMS権限 |
| AWS CloudTrail | 管理イベント、データイベント | API操作、設定変更、権限操作の追跡 | GZIP形式のJSON、既存CloudTrailコネクタとの重複 |
| AWS CloudWatch | CloudWatch logs | アプリケーションやAWSリソースのログ分析 | GZIP形式のCSV、ヘッダーなし。必要に応じてLambdaで整形 |
Microsoft Learnでは、VPC、GuardDuty、CloudTrail、CloudWatchのログ形式が前提条件として明記されています。CloudWatch logsは、Microsoft Sentinelが受け付ける形式に変換するためのLambda関数も案内されています。(Microsoft Learn)
何が変わるのか
今回のポイントは、「AWSとMicrosoft Sentinelをつなぐ」作業が単なるCloudTrail連携ではなく、S3バケットを中心に複数のAWSサービスログを取り込む設計として扱われている点です。
従来のCloudTrail connectorは、CloudTrail管理イベントの取得に使われるレガシーな選択肢です。一方、新しいS3 connectorでは、S3に保存された複数種類のAWSサービスログをMicrosoft Sentinelへ取り込めます。AWS側では、ログをS3へ出力し、S3イベント通知をSQSへ送り、Microsoft Sentinel側ではSQSから新しいログファイルのパスを確認してS3から取得します。(Microsoft Learn)
管理者目線では、変更点を次のように整理できます。
| 観点 | 従来のCloudTrail connector | 新しいS3 connector |
|---|---|---|
| 主な対象 | CloudTrail | VPC Flow Logs、GuardDuty、CloudTrail、CloudWatch logs |
| 取り込み方式 | CloudTrail API中心 | S3バケットとSQS通知を利用 |
| AWS側の設計 | IAMロールとCloudTrail連携が中心 | S3、SQS、OIDC、IAM、ログ出力設定が必要 |
| 拡張性 | CloudTrail用途に限定されやすい | AWSサービスログを種類ごとに拡張しやすい |
| 注意点 | CloudTrail API制限による遅延 | パス、SQS、KMS、ログ形式の設計ミスに注意 |
CloudTrail legacy connectorには、AWS CloudTrailのLookupEvents API制限もあります。公式情報では、アカウントごとに1秒あたり2トランザクション、1回のクエリで最大50レコードという制限が示されており、1リージョンで大量のイベントが継続的に発生する環境では取り込み遅延の原因になります。(Microsoft Learn)
影響を受ける管理者・開発者
この更新で特に影響を受けるのは、Microsoft Defenderポータル、Microsoft Sentinel、AWS環境をまたいで運用しているチームです。
SOC・セキュリティ運用担当者
SOC担当者は、AWSのCloudTrail、GuardDuty、VPC Flow Logs、CloudWatch logsをMicrosoft Sentinelの分析ルールやハンティングで使えるようになるため、調査範囲を広げられます。一方で、どのテーブルにどのログが入るかを把握していないと、検知ルールやKQLクエリの見直しが後回しになりやすくなります。
Microsoft Sentinelのテーブル一覧では、AWS S3コネクタに関連するテーブルとして、AWSCloudTrail、AWSCloudWatch、AWSGuardDuty、AWSVPCFlowなどが示されています。既存の検知ルールやワークブックがこれらのテーブルを参照している場合は、取り込み元の切り替え後も期待どおりにデータが入るか確認してください。(Microsoft Learn)
AWS管理者・クラウド基盤担当者
AWS管理者は、S3バケット、SQSキュー、S3イベント通知、OIDC IDプロバイダー、IAMロール、KMS権限を確認する必要があります。特に、ログを同じS3バケットに保存しても、異なる種類のログを同じパスに混在させないことが重要です。(Microsoft Learn)
公式情報では、ログタイプごとにSQSキューを分けること、1つのSQSキューはS3バケット内の1つのパスに対応させることが既知の注意点として示されています。GuardDuty findingsとVPC Flow Logsを取り込む場合は、それぞれ専用のキューを用意する設計が安全です。(Microsoft Learn)
開発者・DevOps担当者
開発者やDevOps担当者は、CloudWatch logsの形式変換やIaCテンプレートの更新に注意が必要です。CloudWatch logsをそのままS3へ出力しても、Microsoft Sentinelが受け付けるCSV GZIP形式になっていない場合があります。公式手順では、必要に応じてLambda関数でCloudWatchイベントを整形してS3へ送る方法が案内されています。(Microsoft Learn)
本番環境では、サンプル手順をそのまま適用するだけでなく、対象S3バケット、対象ロググループ、対象KMSキーに絞った権限設計を検討してください。最初は接続確認を優先し、その後に最小権限へ調整する流れにすると、切り分けとセキュリティのバランスを取りやすくなります。
設定前に確認すべき前提条件
新しいAWS S3 connectorを使う前に、Microsoft Sentinel側とAWS側の両方で前提条件を確認します。
| 確認項目 | 内容 | 失敗しやすいポイント |
|---|---|---|
| Microsoft Sentinelワークスペース権限 | ワークスペースへの書き込み権限が必要 | 閲覧権限だけでは接続を追加できない |
| Content Hub | Amazon Web Servicesソリューションをインストール | コネクタが一覧に表示されない原因になる |
| PowerShell / AWS CLI | 自動セットアップで必要 | ローカル端末や実行環境に未導入 |
| S3バケット | AWSサービスログの保存先 | ログタイプを同じパスに混在させる |
| SQSキュー | S3イベント通知の受け口 | 1キューで複数ログタイプ・複数パスを受けようとする |
| IAMロール | Microsoft SentinelがAWSリソースを読むために使用 | ロール名や信頼ポリシーのプレフィックス不備 |
| ログ形式 | サービスごとの受け入れ形式に合わせる | CloudWatchやVPC Flow Logsの形式違い |
| KMS | 暗号化ログの復号権限 | GuardDutyやCloudTrailで遅延・失敗の原因になる |
Microsoft Sentinelのデータコネクタは、Microsoft SentinelのContent Hubから関連ソリューションをインストールしてから構成します。Defenderポータルでは「Microsoft Sentinel > Configurations > Data connectors」からデータコネクタを開く流れです。(Microsoft Learn)
自動セットアップで確認すること
Microsoftは、AWS S3 connectorのオンボーディングを簡素化するためにPowerShellスクリプトを用意しており、公式手順では自動セットアップが推奨されています。スクリプトは、OIDC Web IDプロバイダー、IAMロール、必要な権限、S3バケット、SQSキュー、AWSサービスのログ出力設定などを作成または構成します。(Microsoft Learn)
自動セットアップの大まかな流れは次のとおりです。
| 手順 | 作業 | 実務上の確認ポイント |
|---|---|---|
| 1 | Microsoft SentinelでAmazon Web Services S3コネクタを開く | 表示されない場合はContent HubのAWSソリューションを確認 |
| 2 | PowerShellスクリプトをダウンロード | Azure Government環境では専用スクリプトを使う |
| 3 | aws configureを実行 | 対象AWSアカウント、リージョン、権限を確認 |
| 4 | スクリプトを実行 | Workspace IDの入力ミスに注意 |
| 5 | 出力されたRole ARNとSQS URLをコピー | Sentinel側の接続追加で使う |
| 6 | Destination tableでデータタイプを選択 | CloudTrail、GuardDuty、VPC、CloudWatchなどの取り込み先を誤らない |
| 7 | Add connectionを実行 | 接続状態だけでなく実データの到着を確認 |
公式ドキュメントでは、スクリプトの完了に最大30分かかる場合があると説明されています。接続直後にデータが見えなくても、すぐに失敗と判断せず、SQS、S3、SentinelHealthを順に確認するのが現実的です。(Microsoft Learn)
手動セットアップで特に注意すべきAWS側設定
手動セットアップでは、AWS環境側でS3バケット、SQSキュー、S3イベント通知、OIDC IDプロバイダー、IAMロールを作成し、Microsoft Sentinel側にRole ARNとSQS URLを登録します。(Microsoft Learn)
重要なのは、OIDCとIAMロールの命名・信頼ポリシーです。公式情報では、Microsoft Defender for Cloud用のOIDCプロバイダーが既にある場合、新しいOIDCプロバイダーを作成するのではなく、既存プロバイダーにMicrosoft Sentinelをaudienceとして追加するよう説明されています。(Microsoft Learn)
また、AWS assumed roleの名前には正確にOIDC_プレフィックスが必要です。信頼ポリシー側のsts:RoleSessionNameにもMicrosoftSentinel_プレフィックスが必要で、これが合っていないとコネクタが正常に動作しません。(Microsoft Learn)
実務では、次の3点をチェックリスト化しておくと設定ミスを減らせます。
| チェック項目 | 正しい考え方 |
|---|---|
| OIDCプロバイダー | Defender for Cloud用が既にある場合はSentinelのaudienceを追加する |
| IAMロール名 | OIDC_で始まる名前にする |
| RoleSessionName | MicrosoftSentinel_ワークスペースIDの形式にする |
既存環境から移行する場合の進め方
既にCloudTrail legacy connectorを使っている場合は、いきなり停止せず、短期間の並行確認を行うのが安全です。CloudTrailはAWSCloudTrailテーブルに入るため、取り込み元を増やすと同じイベントが重複する可能性があります。テーブル一覧でも、AWSCloudTrailはAmazon Web Services S3とAmazon Web Servicesの両方に関連するテーブルとして示されています。(Microsoft Learn)
移行は次の順序で進めると、障害時の切り戻しがしやすくなります。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 現状確認 | 既存のCloudTrail connector、分析ルール、ワークブック、KQLを棚卸し | どのテーブルを参照しているか分かる状態にする |
| AWS側準備 | CloudTrailをS3へ出力し、専用パスとSQSを設定 | S3にログがあり、SQSに通知が届く |
| Sentinel側接続 | Amazon Web Services S3コネクタでCloudTrailを追加 | AWSCloudTrailに新規データが入る |
| 並行確認 | 旧・新の取り込み差分、遅延、重複を確認 | 重要イベントが欠落していない |
| 切り替え | legacy connectorを停止または整理 | 重複取り込みが止まり、検知が維持される |
| 最適化 | 保持期間、コスト、分析ルールを調整 | 不要なログや重複ルールを削減 |
Microsoft Sentinelは、2027年3月31日以降Azure portalではサポートされず、Microsoft Defenderポータルで利用する形に移行すると公式情報で案内されています。既存のMicrosoft Sentinel環境をAzure portal中心で運用している場合は、AWSログ取り込みの移行とあわせて、Defenderポータル側のナビゲーションや権限も確認しておくべきです。(Microsoft Learn)
取り込み後の確認に使えるKQL
接続状態が「正常」に見えても、実際にログが入っているとは限りません。公式トラブルシューティングでは、コネクタの緑色の接続状態は収集ルールの存在を示すものであり、データが取り込まれたこと自体を保証しないと説明されています。(Microsoft Learn)
取り込み確認では、まず対象テーブルに直近データがあるかを確認します。
AWSCloudTrail
| where TimeGenerated > ago(1h)
| summarize Count=count() by bin(TimeGenerated, 5m)VPC Flow Logsを取り込む場合は、次のように確認します。
AWSVPCFlow
| where TimeGenerated > ago(1h)
| summarize Count=count() by bin(TimeGenerated, 5m)GuardDuty findingsは次のように確認できます。
AWSGuardDuty
| where TimeGenerated > ago(24h)
| project TimeGenerated, Severity, Type, Title
| order by TimeGenerated descCloudWatch logsを取り込む場合は、対象テーブルにデータが入っているかを確認します。
AWSCloudWatch
| where TimeGenerated > ago(1h)
| summarize Count=count() by bin(TimeGenerated, 5m)データが入らない場合や30分以上遅延する場合は、SentinelHealthで失敗内容を確認します。
SentinelHealth
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| project TimeGenerated, SentinelResourceKind, SentinelResourceName, Status, Description, ExtendedProperties公式トラブルシューティングでは、取り込み開始まで20〜30分程度かかる場合があること、S3にログが存在しない、SQSに通知が来ない、SQS/S3を読み取れない、KMS権限が不足している、といった原因が整理されています。(Microsoft Learn)
よくある失敗と対策
AWS S3 connectorのトラブルは、Microsoft Sentinel側だけを見ても解決しにくいことが多いです。S3、SQS、IAM、KMS、ログ形式を順番に切り分ける必要があります。
| 症状 | よくある原因 | 対策 |
|---|---|---|
| コネクタが表示されない | AWSソリューションがContent Hubに未インストール | Content HubでAmazon Web Servicesソリューションをインストールまたは更新 |
| 接続後にデータが出ない | S3に対象ログがない | AWSサービス側のログ出力設定を確認 |
| S3にログはあるがSentinelに入らない | SQSにS3イベント通知が届いていない | S3イベント通知のprefix、suffix、SQSアクセスポリシーを確認 |
| 取り込みが大きく遅れる | 暗号化ログのKMS権限不足、形式違い | KMS復号権限とログ形式を確認 |
| GuardDutyだけ入らない | Findingsの出力頻度やKMS設定の問題 | GuardDutyのエクスポート設定とKMS権限を確認 |
| VPC Flow Logsの時刻がずれる | カスタム形式でstart属性がない | start属性を含め、TimeGeneratedへのマッピングを確認 |
| 複数ログが混ざる | 同一S3パスや同一SQSを使い回している | ログタイプ・パスごとにSQSを分ける |
特にSQSは「通知が届いているか」と「Microsoft Sentinelが読み取れているか」を分けて確認します。AWS側のSQS MonitoringでNumber Of Messages Sent、Number Of Messages Received、Number Of Messages Deletedを確認すると、S3通知の未達なのか、読み取り側の問題なのかを切り分けやすくなります。(Microsoft Learn)
展開時の実務チェックリスト
本番展開前には、次の項目を確認してください。
| 分類 | 確認内容 |
|---|---|
| 権限 | Sentinelワークスペースへの読み書き権限、AWS IAMロール、S3/SQS/KMS権限 |
| ポータル | DefenderポータルでMicrosoft SentinelのData connectorsへ到達できるか |
| Content Hub | Amazon Web Servicesソリューションがインストール済みか |
| AWSログ | VPC、GuardDuty、CloudTrail、CloudWatchのどれを取り込むか決めているか |
| S3設計 | ログタイプごとにパスを分けているか |
| SQS設計 | 1キュー1ログタイプ・1パスを基本にしているか |
| 形式 | Microsoft Sentinelが受け付けるGZIP、CSV、JSON形式に合っているか |
| 重複 | 旧CloudTrail connectorとの二重取り込みがないか |
| KQL | 既存の検知ルール、ハンティングクエリ、ワークブックが動くか |
| コスト | 取り込み量、保持期間、データレイク利用方針を確認したか |
| 運用 | SentinelHealthを監視し、遅延や失敗を検知できるか |
Microsoft Sentinelのデータコネクタでは、データ保持や階層化の設定も確認できます。Microsoft Sentinel data lakeを利用している場合は、分析層とデータレイク層の保持期間、レイクのみの取り込み設定なども運用設計に含める必要があります。(Microsoft Learn)
管理者が次に取るべき行動
まず、自社のAWSログ取り込みがCloudTrail legacy connector中心なのか、新しいAmazon Web Services S3 connector中心なのかを確認してください。CloudTrailだけを見ている環境でも、GuardDuty、VPC Flow Logs、CloudWatch logsをMicrosoft Sentinelに集約できれば、侵害調査や横断的な検知の精度を上げやすくなります。
次に、AWS側でS3パスとSQSキューをログタイプごとに分離し、Microsoft Sentinel側で対象テーブルにデータが入ることをKQLで確認します。最後に、Defenderポータルへの移行方針、既存検知ルールの影響、二重取り込み、KMS権限、保持期間をレビューしてください。
この更新は、単なる接続手順の追加ではなく、AWSログをMicrosoft Defenderポータル上のMicrosoft Sentinel運用へ統合するための設計見直しです。接続作業だけで完了とせず、「どのログを、どの経路で、どのテーブルに、どの検知ルールで使うか」まで決めることが、安定した運用につながります。
コメント