共用方式為

疑難排解 AWS S3 連接器問題

  • 發行項

Amazon Web Services (AWS) S3 連接器可讓您將 AWS S3 貯體中收集到的 AWS 服務記錄內嵌至 Microsoft Sentinel。 我們目前支援的記錄類型包括 AWS CloudTrail、VPC 流量記錄和 AWS GuardDuty。

本文說明如何快速找出 AWS S3 連接器發生問題的原因，以便找到解決問題所需的步驟。

了解如何將 Microsoft Sentinel 連線至 Amazon Web Services 以內嵌 AWS 服務記錄資料

Microsoft Sentinel 未從 Amazon Web Services S3 連接器或其中一個資料類型接收資料

AWS S3 連接器 (或其一種資料類型) 的記錄在連接器連線超過 30 分鐘後，即無法在 Microsoft Sentinel 工作區中顯示。

在您搜尋原因和解決方案之前，請先檢閱下列考量：

  • 從連接器連線到資料內嵌至工作區之間，可能需要 20-30 分鐘的時間。
  • 連接器的連線狀態指出收集規則存在，但未指出資料已內嵌。 如果 Amazon Web Services S3 連接器的狀態為綠色，則表示其中一個資料類型有集合規則，但仍然沒有資料。

判斷問題的原因

在本節中，我們將討論下列原因：

  1. AWS S3 連接器權限原則未正確設定。
  2. 資料不會擷取至 AWS 中的 S3 貯體。
  3. AWS 雲端中的 Amazon Simple Queue Service (SQS) 不會從 S3 貯體接收通知。
  4. 無法從 AWS 雲端中的 SQS/S3 讀取資料。 使用 GuardDuty 記錄時，問題是由錯誤的 KMS 權限所造成。

原因 1：AWS S3 連接器權限原則未正確設定

此問題是因為 AWS 環境中的權限不正確所造成。

建立權限原則

您需要許可權原則才能部署 AWS S3 資料連線器。 檢閱必要的權限並設定相關權限。

原因 2：S3 貯體中不存在相關資料

S3 貯體中不存在相關的記錄。

解決方案：視需要搜尋記錄和匯出記錄

  1. 在 AWS 中，開啟 S3 貯體，根據所需的記錄搜尋相關資料夾，並檢查資料夾內是否有任何記錄檔。
  2. 如果資料不存在，則表示 AWS 設定有問題。 在此情況下，您需要設定 AWS 服務，以將記錄匯出至 S3 貯體。

原因 3：S3 資料未到達 SQS

資料未從 S3 成功傳輸到 SQS。

解決方案：確認資料已到達並設定事件通知

  1. 在 AWS 中，開啟相關的 SQS。
  2. 在 [監視] 索引標籤下，您應該會在 [已傳送的訊息數目] 小工具中看到流量。 如果 SQS 中沒有流量，則問題出在 AWS 設定。
  3. 確保 SQS 的事件通知定義包含正確的資料篩選 (首碼和尾碼)。
    1. 若要查看事件通知，請在 S3 貯體中選取 [屬性] 索引標籤，然後找出 [事件通知] 區段。
    2. 如果您看不到本節，請加以建立。
    3. 請確定 SQS 具有從 S3 貯體取得資料的相關原則。 SQS 必須在 [存取] 原則索引標籤中包含此原則。

原因 4：SQS 未讀取資料

SQS 無法成功讀取 S3 資料。

解決方案：確認 SQS 讀取資料

  1. 在 AWS 中，開啟相關的 SQS。

  2. 在 [監視] 索引標籤中，您應該會在 [已刪除的訊息數目] 和 [已接收的訊息數目] 小工具中看到流量。

  3. 一個資料尖峰並不足夠。 等到有足夠的資料 (數個尖峰) 後，然後檢查是否有問題。

  4. 如果至少有一個小工具是空的，請執行此查詢來檢查健康情況記錄：

    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

  5. 確保已啟用健康情況功能：

    SentinelHealth 
| take 20

  6. 如果未啟用健康情況功能，請加以啟用。

AWS S3 連接器的資料 (或其中一種資料類型) 會出現在 Microsoft Sentinel 中，延遲超過 30 分鐘

此問題通常會發生在 Microsoft 無法讀取 S3 資料夾中的檔案時。 Microsoft 無法讀取檔案，因為檔案已加密或格式錯誤。 在這些情況下，多次重試最終會導致內嵌延遲。

判斷問題的原因

在本節中，我們將討論下列原因：

  • 記錄加密未正確設定
  • 事件通知未正確定義
  • 健康情況錯誤或健康情況已停用

原因 1：記錄加密未正確設定

如果金鑰管理服務 (KMS) 已加密完全或部分記錄，則 Microsoft Sentinel 可能沒有此 KMS 解密檔案的權限。

解決方案：檢查記錄加密

請確定 Microsoft Sentinel 具有此 KMS 的解密檔案權限。 檢閱 GuardDuty 和 CloudTrail 記錄 所需的 KMS 許可權。

原因 2：事件通知未正確設定

當您設定 Amazon S3 事件通知時，必須指定 Amazon S3 應該傳送通知給哪些支援的事件種類。 如果您未指定的事件種類存在於 Amazon S3 貯體中，則 Amazon S3 不會傳送通知。

解決方案：確認事件通知已正確定義

若要確認從 S3 到 SQS 的事件通知是否已正確定義，請檢查：

  • 通知是從包含記錄的特定資料夾定義，而不是從包含貯體的主資料夾定義。
  • 通知是使用 .gz 尾碼來定義。 例如：

原因 3：健康情況錯誤或健康情況已停用

健康情況記錄中可能會發生錯誤，或健康情況功能未啟用。

解決方案：確認健康情況記錄中沒有任何錯誤，並啟用健康情況

  1. 執行此查詢，確認健康情況記錄中沒有任何錯誤：

    SentinelHealth
| where TimeGenerated between (ago(startTime)..ago(endTime))
| where SentinelResourceKind  == "AmazonWebServicesS3"
| where Status != "Success"
| distinct TimeGenerated, OperationName, SentinelResourceName, Status, Description

  2. 確保已啟用健康情況功能：

    SentinelHealth 
| take 20

  3. 如果未啟用健康情況功能，請加以啟用。

下一步

在本文中，您已了解如何快速找出原因並解決 AWS S3 連接器的常見問題。

我們歡迎您提供意見反應、建議、功能要求、Bug 報表，或改善和新增項目。 請移至 Microsoft Sentinel GitHub 存放庫以建立問題或分支並上傳貢獻項目。