Microsoft Sentinel と Amazon Web Services（AWS）を連携する場合、2026年4月時点で最初に押さえるべき答えは「AWS S3コネクタを軸に、S3・SQS・OIDC・IAMロールを正しく設計し、VPC Flow Logs、GuardDuty、CloudTrail、CloudWatch Logsを用途別に取り込む」ことです。
Microsoft公式ドキュメント「Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log data」は2026年4月22日に更新され、AWSサービスログコネクタには、CloudTrail向けのレガシーコネクタと、S3バケットから複数種類のAWSログを取り込む新しいコネクタがあることが整理されています。対象となる主な読者は、security admins、identity teams、compliance teamsです。監視範囲、ID連携、監査証跡を分けて考えると、導入時の判断ミスを減らせます。(Microsoft Learn)
Microsoft Sentinelの最新動向：Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log dataで押さえる更新ポイント
今回の更新で重要なのは、単に「AWSログをMicrosoft Sentinelに入れる」ことではありません。AWS側のログ収集設計を、Microsoft Sentinelのデータコネクタ運用に合わせて見直す必要がある点です。
公式ドキュメントでは、AWSサービスログコネクタが次の2系統で説明されています。
| コネクタ | 主な役割 | 実務での位置付け |
|---|---|---|
| AWS S3コネクタ（新しい版） | S3バケットからAWSサービスログを取り込む | 新規導入や複数AWSログの統合監視では基本候補 |
| CloudTrailコネクタ（レガシー版） | CloudTrailの管理イベント・データイベントを扱う | 既存構成の維持やCloudTrail中心の連携で検討 |
新しいAWS S3コネクタでは、S3バケットからログを取得する形で、Amazon VPCのVPC Flow Logs、Amazon GuardDutyのFindings、AWS CloudTrailのManagement eventsとData events、AWS CloudWatch Logsを取り込めると説明されています。(Microsoft Learn)
このため、2026年4月更新の実務上の読みどころは「対応ログ種別が何か」だけではありません。むしろ、S3バケット、SQSキュー、OIDC、IAMロール、ログ形式、パス設計をどう分けるかが重要です。
2026年4月更新で実務担当者が確認すべきポイント
更新内容を現場向けに整理すると、見るべきポイントは次の通りです。
| 確認ポイント | 実務上の意味 | まず確認すること |
|---|---|---|
| S3経由の取り込みが中心 | AWSログをS3に集約し、SQS通知を使ってMicrosoft Sentinelが取得する構成になる | S3バケット、SQSキュー、イベント通知の設計 |
| 対応ログが複数サービスにまたがる | CloudTrailだけでなく、ネットワーク、脅威検知、アプリログまで扱える | どのログをSOC監視・監査対象にするか |
| 自動セットアップが推奨 | PowerShellスクリプトでAWS側リソースや権限を作成できる | PowerShell、AWS CLI、実行権限の準備 |
| ログ形式の要件が明確 | 形式が合わないと取り込み遅延や失敗につながる | GZIP、CSV、JSON、ヘッダー有無の確認 |
| S3パスとSQSの分離が重要 | ログ種別を混在させると運用・障害切り分けが難しくなる | ログ種別ごとにパスとキューを分ける |
| レガシーCloudTrailには制約がある | 高頻度イベントではバックログや遅延に注意が必要 | S3コネクタへの移行余地を確認 |
Microsoftの説明では、AWS S3コネクタの自動セットアップスクリプトは、OIDC Web IDプロバイダー、最小限の権限を持つIAMロール、S3バケット、SQSキュー、IAMポリシーなどの作成・設定を支援します。スクリプトの実行にはPowerShellとAWS CLIが必要で、完了まで最大30分かかる場合があるとされています。(Microsoft Learn)
どのAWSログをMicrosoft Sentinelに取り込むべきか
AWSログをすべて取り込めば安全になるわけではありません。ログ量、検知ルール、調査用途、監査要件を考えずに取り込むと、コストが増える一方で、重要なアラートを見落としやすくなります。
まずは、目的別にログを選ぶのが現実的です。
| ログ種別 | 主な用途 | 向いているチーム | 導入時の注意点 |
|---|---|---|---|
| VPC Flow Logs | 通信元・通信先、許可・拒否、ネットワーク経路の可視化 | security admins、ネットワーク担当 | 高トラフィック環境ではログ量が増えやすい |
| GuardDuty Findings | AWS環境内の潜在的な脅威検知結果の集約 | security admins、SOC | Findingsの重要度と対応フローを事前に決める |
| CloudTrail Management events | IAM変更、ConsoleLogin、リソース作成・削除などの追跡 | identity teams、compliance teams | 管理操作の監査証跡として優先度が高い |
| CloudTrail Data events | S3オブジェクト操作など、リソース内操作の追跡 | compliance teams、security admins | 高頻度・高コストになりやすいため範囲を絞る |
| CloudWatch Logs | アプリケーション、EC2、AWSサービス由来ログの集約 | security admins、アプリ運用 | Microsoft Sentinelが受け入れる形式への変換が必要な場合がある |
VPC Flow Logsは、VPC内のネットワークインターフェイスに出入りするIPトラフィック情報を取得でき、セキュリティグループの過剰な制限、インスタンスへの到達通信、通信方向の確認に役立ちます。GuardDuty Findingsは、AWSアカウント、ワークロード、データ内で検出された潜在的なセキュリティ問題を表します。(AWS ドキュメント)
CloudTrail Management eventsは、IAMポリシー変更、EC2作成、CloudTrail設定変更、ConsoleLoginなど、AWSアカウント内の管理操作を可視化します。一方、CloudTrail Data eventsは、S3オブジェクト操作などリソース内で発生するデータプレーン操作を扱い、AWS公式ドキュメントでは高ボリュームになりやすく、デフォルトでは記録されないイベントとして説明されています。(AWS ドキュメント)
CloudWatch Logsは、EC2、CloudTrail、Route 53など複数のソースからログを監視・保存・参照できるサービスです。Microsoft Sentinelへ取り込む場合は、CloudWatch側のログをそのまま入れるのではなく、受け入れ可能な形式に整えることが重要です。(AWS ドキュメント)
新しいAWS S3コネクタで必要になる構成要素
Microsoft SentinelのAWS S3コネクタは、AWS側に保存されたログをS3から直接読むだけの単純な構成ではありません。S3、SQS、OIDC、IAMロールが連携して動きます。
基本的な流れは次の通りです。
| 手順 | AWS側・Microsoft Sentinel側の動き |
|---|---|
| S3バケットを用意する | AWSサービスログの保存先にする |
| SQSキューを用意する | S3に新しいログファイルが作成されたことを通知する |
| S3イベント通知を設定する | 対象パスに新しいログが入ったらSQSへ通知する |
| OIDC Web IDプロバイダーを構成する | Microsoft Entra IDを使ってAWSへ認証できるようにする |
| IAMロールを作成する | Microsoft SentinelがS3とSQSへアクセスできる権限を付与する |
| Microsoft Sentinel側で接続を追加する | Role ARN、SQS URL、Destination tableを指定する |
Microsoftの環境設定ドキュメントでは、Microsoft SentinelコネクタはSQSキューをポーリングし、SQSメッセージに含まれる新しいログファイルのパスをもとにS3バケットからファイルを取得すると説明されています。また、Microsoft SentinelはMicrosoft Entra IDを使い、OIDC経由でAWS IAMロールを引き受けます。(Microsoft Learn)
この設計の利点は、静的な長期アクセスキーに依存せず、IAMロールとOIDCを使って権限を管理できる点です。identity teamsは、ここを単なる接続設定ではなく、クラウド間ID連携の統制ポイントとして扱うべきです。
自動セットアップと手動セットアップの使い分け
Microsoft公式ドキュメントでは、AWS S3コネクタの構成方法として、自動セットアップと手動セットアップが示されています。通常は自動セットアップを優先し、組織のクラウド基盤ルールや権限分離の都合がある場合に手動セットアップを検討するのが現実的です。(Microsoft Learn)
| 方法 | 向いているケース | 注意点 |
|---|---|---|
| 自動セットアップ | 初回導入、検証環境、標準構成で素早く展開したい場合 | スクリプト実行権限、AWS CLI設定、作成されるリソースの事前確認が必要 |
| 手動セットアップ | Landing Zone、Control Tower、厳格なIAM管理、既存S3/SQSを使う場合 | S3通知、SQSポリシー、IAMロール、OIDC設定を個別に検証する必要がある |
自動セットアップでは、AWS側のリソース、資格情報、権限設定をスクリプトで構成できます。ただし、本番環境でそのまま実行する前に、作成されるIAMポリシー、S3バケット名、SQSキュー、ログパスを確認してください。
特にグローバル環境では、AWSアカウント、リージョン、ログ種別、保持期間のルールが地域ごとに異なることがあります。APAC、EU、USなどで監査要件が異なる場合は、単一のS3バケットに集約するか、地域別に分けるかを事前に決めておく必要があります。
ログ形式の要件は必ず事前に確認する
AWSログ連携で失敗しやすいのが、ログ形式の不一致です。Microsoft Sentinel側の接続設定が正しくても、S3に置かれたファイル形式が要件と合わなければ、取り込み失敗や遅延の原因になります。
公式ドキュメントでは、対象ログごとに受け入れ可能な形式が示されています。(Microsoft Learn)
| AWSサービス | Microsoft Sentinelで受け入れる形式 |
|---|---|
| Amazon VPC | ヘッダー付きCSV、GZIP形式、区切り文字はスペース |
| Amazon GuardDuty | json-line形式、GZIP形式 |
| AWS CloudTrail | JSONファイル、GZIP形式 |
| CloudWatch | ヘッダーなしCSV、GZIP形式 |
CloudWatch Logsについては、Microsoft Sentinelが受け入れる形式でない場合、AWS Lambda関数を使ってCloudWatchイベントをS3へ送る方法が紹介されています。公式ドキュメントでは、このLambda関数についてPython 3.12ランタイムとx86_64アーキテクチャを使う説明があります。(Microsoft Learn)
ここでの実務上の判断基準は明確です。CloudWatch Logsを入れる前に、「どのロググループを対象にするのか」「CSV化する項目は何か」「検知ルールで使うフィールドは何か」を決めてください。目的が決まっていないCloudWatch Logsを大量に投入しても、分析しづらいデータが増えるだけです。
S3パスとSQSキュー設計で失敗しないための考え方
AWS S3コネクタの安定運用では、S3バケット名よりも「パス設計」と「SQSキュー設計」が重要です。
Microsoft公式ドキュメントでは、異なる種類のログを同じS3バケットに保存することは可能でも、同じパスに保存すべきではないとされています。また、各SQSキューは1種類のメッセージを指すべきで、GuardDuty FindingsとVPC Flow Logsを取り込む場合は、それぞれ別のキューを用意する必要があります。さらに、1つのSQSキューはS3バケット内の1つのパスだけを扱うため、複数パスを使う場合はパスごとに専用キューが必要です。(Microsoft Learn)
設計例としては、次のようにログ種別ごとに分けると管理しやすくなります。
s3://security-log-bucket/sentinel/vpc-flow-logs/
s3://security-log-bucket/sentinel/guardduty/
s3://security-log-bucket/sentinel/cloudtrail-management/
s3://security-log-bucket/sentinel/cloudtrail-data/
s3://security-log-bucket/sentinel/cloudwatch/app-a/この例では、それぞれのパスに対応するSQSキューを分けます。障害時に「S3にはログがあるのか」「SQSへ通知されているのか」「Microsoft Sentinelが読めているのか」を切り分けやすくなるためです。
避けるべき設計は、次のような構成です。
| 避けたい構成 | 起きやすい問題 |
|---|---|
| 1つのパスに複数ログ種別を混在させる | Destination tableや形式の切り分けが難しくなる |
| 1つのSQSキューに複数種別の通知を集める | 取り込み失敗時に原因を特定しにくい |
| CloudTrail data eventsを広範囲に有効化する | ログ量が急増し、コストと調査ノイズが増える |
| KMS暗号化ログの復号権限を確認しない | S3にはログがあるのにMicrosoft Sentinelが読めない |
| コネクタの緑表示だけで正常と判断する | データが実際に入っていない状態を見逃す |
レガシーCloudTrailコネクタを使い続ける場合の注意点
CloudTrailコネクタのレガシー版を使っている環境では、すぐに止める必要があるとは限りません。ただし、新規構築や大規模なAWSアカウントでは、S3コネクタを前提に見直す価値があります。
理由は、レガシーCloudTrailコネクタにはAPI制約があるためです。Microsoft公式ドキュメントでは、AWS CloudTrailのLookupEvents APIに、1アカウントあたり1秒2トランザクション、1クエリ最大50レコードという制約があり、単一テナントで1リージョンあたり毎秒100件を超えるレコードが継続的に生成されると、バックログや取り込み遅延が発生すると説明されています。(Microsoft Learn)
AWS側のCloudTrailクォータでも、LookupEvents APIのTPSクォータは2と説明されています。高頻度の操作ログを扱う環境では、レガシー連携だけに依存せず、S3経由の取り込みへ設計を寄せるほうが安定しやすくなります。(AWS ドキュメント)
また、レガシーCloudTrailコネクタはAWS Commercial CloudTrailのみ接続可能で、AWS GovCloud CloudTrailには接続できないとMicrosoft公式ドキュメントに記載されています。Azure GovernmentクラウドでAWSログを取り込む場合は、AWS S3コネクタの専用セットアップスクリプトも確認してください。(Microsoft Learn)
security adminsが見るべきポイント
security adminsは、まず検知と調査に直結するログから優先順位を付けるべきです。
最初に検討しやすいのは、GuardDuty Findings、CloudTrail Management events、重要VPCのVPC Flow Logsです。GuardDutyで脅威の初期シグナルを拾い、CloudTrailで誰が何を変更したかを追い、VPC Flow Logsで通信の実態を確認する流れを作れます。
おすすめの初期構成は次の通りです。
| 優先度 | ログ | 目的 |
|---|---|---|
| 高 | GuardDuty Findings | 既知の脅威検知結果をMicrosoft Sentinelへ集約する |
| 高 | CloudTrail Management events | IAM変更、ログ設定変更、ConsoleLoginを監査する |
| 中 | VPC Flow Logs | 重要システムの通信経路、不審なアウトバウンド通信を確認する |
| 中 | CloudWatch Logs | 検知ルールが明確なアプリ・サービスログから取り込む |
| 慎重に判断 | CloudTrail Data events | S3など重要データ操作に絞って有効化する |
ポイントは、最初から全アカウント・全リージョン・全ログを対象にしないことです。まずは重要アカウント、重要VPC、重要データストアを決め、検知ルールとインシデント対応手順があるログから取り込みます。
identity teamsが見るべきポイント
identity teamsにとって重要なのは、Microsoft SentinelとAWSの接続が、どのIDと権限で成立しているかです。
AWS S3コネクタでは、Microsoft SentinelがMicrosoft Entra IDを使ってOIDC経由でAWSへ認証し、AWS IAMロールを引き受ける構成になります。すでにMicrosoft Defender for Cloud向けのOIDCプロバイダーがある場合は、新しくOIDCプロバイダーを作るのではなく、既存プロバイダーにMicrosoft Sentinelをaudienceとして追加するようMicrosoftドキュメントで注意されています。(Microsoft Learn)
identity teamsは、次の点を確認してください。
| 確認項目 | 見るべき内容 |
|---|---|
| OIDCプロバイダー | 既存のDefender for Cloud用設定と重複していないか |
| IAMロール | Microsoft Sentinel用であることが分かる命名になっているか |
| IAMポリシー | S3とSQSに必要最小限の権限だけが付与されているか |
| KMS権限 | 暗号化されたCloudTrailやGuardDutyログを復号できるか |
| 監査対象操作 | IAM変更、ロール引き受け、ポリシー変更がCloudTrailで追跡できるか |
Microsoft Sentinelにログを入れるための権限設定そのものが、監査対象になります。接続作業を一度きりの構築タスクにせず、IAMレビューやアクセス棚卸しの対象に含めることが大切です。
compliance teamsが見るべきポイント
compliance teamsは、「ログが入っているか」だけでなく、「監査で説明できるか」を確認する必要があります。
たとえば、CloudTrail Management eventsを取り込んでいても、対象アカウントやリージョンが限定されている場合、監査証跡としては不十分な可能性があります。CloudTrail Data eventsも、すべてを有効化するとログ量が増えますが、重要なS3バケットや機密データに関わる操作だけを対象にする設計なら、監査要件とコストのバランスを取りやすくなります。
CloudTrail Data eventsは、リソース上またはリソース内で実行された操作を記録するもので、多くの場合は高ボリュームになりやすいイベントです。AWS公式ドキュメントでは、Advanced event selectorsを使って関心のあるイベントだけを記録し、コストを制御できると説明されています。(AWS ドキュメント)
compliance teams向けの確認観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
| 対象範囲 | どのAWSアカウント、リージョン、サービスを対象にしているか |
| 証跡の完全性 | 管理操作、データ操作、脅威検知結果のどれを記録しているか |
| 保持期間 | AWS側とMicrosoft Sentinel側で保持方針が整合しているか |
| 暗号化 | S3、KMS、復号権限が監査要件を満たしているか |
| 例外管理 | 対象外アカウントや対象外ログの理由を文書化しているか |
グローバル組織では、国や地域ごとにログ保持、個人情報、越境移転の考え方が異なる場合があります。Microsoft Sentinelへの集約設計は、セキュリティ部門だけで決めず、法務・コンプライアンス部門と一緒に整理してください。
取り込み後の確認方法
AWS S3コネクタを追加した後は、Microsoft Sentinel側の接続状態だけで正常と判断しないでください。Microsoftのトラブルシュート資料では、接続後にデータがワークスペースへ取り込まれるまで20〜30分程度かかる場合があり、コネクタの接続状態が緑でも、それは収集ルールが存在することを示すだけで、実データの取り込みを保証するものではないと説明されています。(Microsoft Learn)
確認は、次の順番で行うと切り分けやすくなります。
| 確認箇所 | 確認内容 |
|---|---|
| AWSサービス | 対象ログが生成されているか |
| S3バケット | 想定パスにGZIPファイルが出力されているか |
| S3イベント通知 | 対象プレフィックスとサフィックスが正しいか |
| SQSキュー | メッセージが送信・受信・削除されているか |
| Microsoft Sentinel | 対象テーブルにデータが入っているか |
| SentinelHealth | 取得失敗や権限エラーが出ていないか |
Microsoftのトラブルシュート資料では、S3にログが存在しない、SQSに通知が届いていない、SQS/S3からデータを読めない、KMS権限が不足しているといった原因が示されています。遅延が30分を超える場合は、暗号化、イベント通知、Healthログを確認する流れが有効です。(Microsoft Learn)
Microsoft Sentinel側では、まず対象テーブルにデータが入っているかを確認します。Destination tableで選んだテーブル名を使い、次のように直近の件数を確認します。
<対象テーブル名>
| where TimeGenerated > ago(24h)
| summarize Count = count() by bin(TimeGenerated, 1h)
| order by TimeGenerated desc取得失敗を確認する場合は、SentinelHealthを使います。
SentinelHealth
| where TimeGenerated > ago(1d)
| where SentinelResourceKind in ('AmazonWebServicesCloudTrail', 'AmazonWebServicesS3')
| where OperationName == 'Data fetch failure summary'
| mv-expand TypeOfFailureDuringHour = ExtendedProperties["FailureSummary"]
| extend StatusCode = TypeOfFailureDuringHour["StatusCode"]
| extend StatusMessage = TypeOfFailureDuringHour["StatusMessage"]
| project SentinelResourceKind, SentinelResourceName, StatusCode, StatusMessage, SentinelResourceId, TypeOfFailureDuringHour, ExtendedPropertiesこのクエリでエラーが見える場合は、Microsoft Sentinel側だけでなく、AWS側のS3ポリシー、SQSアクセスポリシー、IAMロール、KMSキー権限を順番に確認してください。
導入時の実践チェックリスト
実際にMicrosoft SentinelとAWSを接続する前に、次のチェックリストを使うと抜け漏れを減らせます。
| フェーズ | チェック項目 |
|---|---|
| 対象決定 | 対象AWSアカウント、リージョン、ログ種別を決めたか |
| ログ設計 | S3パスをログ種別ごとに分けたか |
| 通知設計 | SQSキューをパス・ログ種別ごとに分けたか |
| 権限設計 | OIDC、IAMロール、S3/SQS/KMS権限を最小権限で設計したか |
| 形式確認 | VPC、GuardDuty、CloudTrail、CloudWatchの形式要件を確認したか |
| コスト確認 | CloudTrail Data eventsやVPC Flow Logsのログ量を見積もったか |
| 検証 | S3、SQS、Microsoft Sentinel、SentinelHealthの確認手順を用意したか |
| 運用 | 障害時の切り分け担当をsecurity、identity、complianceで分けたか |
特に重要なのは、CloudTrail Data eventsとCloudWatch Logsです。どちらも便利ですが、対象範囲を広げすぎるとログ量が増えやすく、分析効率も下がります。まずは検知・監査に必要な対象を絞り、段階的に広げるのが安全です。
まとめ：2026年4月更新後はS3コネクタ前提でAWSログ設計を見直す
2026年4月22日更新の「Connect Microsoft Sentinel to Amazon Web Services to ingest AWS service log data」で実務担当者が押さえるべきポイントは、AWS S3コネクタを中心に、複数のAWSサービスログをMicrosoft Sentinelへ取り込む設計が明確になっていることです。
新しいAWS S3コネクタでは、VPC Flow Logs、GuardDuty Findings、CloudTrail Management/Data events、CloudWatch LogsをS3経由で取り込めます。一方で、ログ形式、S3パス、SQSキュー、OIDC、IAMロール、KMS権限を正しく設計しないと、接続できているように見えてもデータが入らない、遅延する、監査で説明できないといった問題が起きます。
次に取るべき行動は明確です。まず、現在AWSからMicrosoft Sentinelへ取り込んでいるログ種別を棚卸ししてください。そのうえで、CloudTrailだけに依存している環境はAWS S3コネクタへの移行・併用を検討し、S3パスとSQSキューをログ種別ごとに分離します。最後に、SentinelHealthと対象テーブルのKQL確認を標準手順に入れ、security admins、identity teams、compliance teamsが同じ証跡を見て判断できる運用に整えましょう。
コメント