Sdílet prostřednictvím

Řešení potíží s konektorem AWS S3

  • Článek

Konektor Amazon Web Services (AWS) S3 umožňuje ingestovat protokoly služby AWS shromážděné v kontejnerech AWS S3 do Microsoft Sentinelu. Typy protokolů, které aktuálně podporujeme, jsou AWS CloudTrail, protokoly toku VPC a AWS GuardDuty.

Tento článek popisuje, jak rychle identifikovat příčinu problémů, ke kterým dochází u konektoru AWS S3, abyste našli kroky potřebné k vyřešení problémů.

Zjistěte, jak připojit Microsoft Sentinel k Amazon Web Services k ingestování dat protokolů služby AWS.

Microsoft Sentinel nepřijímá data z konektoru Amazon Web Services S3 ani z jednoho z jeho datových typů

Protokoly konektoru AWS S3 (nebo některého z jeho datových typů) se v pracovním prostoru Microsoft Sentinelu nezobrazují déle než 30 minut po připojení konektoru.

Než začnete hledat příčinu a řešení, projděte si tyto aspekty:

  • Příjem dat do pracovního prostoru může od okamžiku připojení konektoru trvat 20 až 30 minut.
  • Stav připojení konektoru signalizuje přítomnost pravidla shromažďování dat, ale neznamená jejich načtení. Pokud je stav konektoru Amazon Web Services S3 zelený, existuje pravidlo kolekce pro jeden z datových typů, ale stále žádná data.

Určení příčiny vašeho problému

V této části se věnujeme těmto příčinám:

  1. Zásady oprávnění konektoru AWS S3 nejsou správně nastavené.
  2. Data se neingestují do kontejneru S3 v AWS.
  3. Amazon Simple Queue Service (SQS) v cloudu AWS nepřijímá oznámení z kbelíku S3.
  4. Nejde načíst data z SQS nebo S3 v cloudu AWS. V protokolech GuardDuty je problém způsobený nesprávnými oprávněními Služby správy klíčů.

Příčina 1: Zásady oprávnění konektoru AWS S3 nejsou správně nastavené

Příčinou tohoto problému jsou nesprávná oprávnění v prostředí AWS.

Vytvoření zásad oprávnění

K nasazení datového konektoru AWS S3 potřebujete zásady oprávnění. Zkontrolujte požadovaná oprávnění a nastavte příslušná oprávnění.

Příčina 2: Relevantní data v kontejneru S3 neexistují

Příslušné protokoly v kontejneru S3 neexistují.

Řešení: V případě potřeby vyhledejte protokoly a vyexportujte protokoly.

  1. V AWS otevřete kontejner S3, vyhledejte příslušnou složku podle požadovaných protokolů a zkontrolujte, jestli ve složce nejsou nějaké soubory protokolu.
  2. Pokud data neexistují, je problém s konfigurací AWS. V takovém případě je potřeba nakonfigurovat službu AWS tak, aby export protokolů do kontejneru S3.

Příčina 3: Data S3 nepřišla na SQS

Data se z S3 do SQS úspěšně nepřenesla.

Řešení: Ověřte, že data přišla a nakonfigurovala oznámení událostí.

  1. V AWS otevřete příslušnou službu SQS.
  2. Na kartě Monitorování by se měl zobrazit provoz ve widgetu Počet odeslaných zpráv. Pokud se ve službě SQS žádný provoz nezobrazuje, je problém v konfiguraci AWS.
  3. Ujistěte se, že definice oznamování událostí služby SQS obsahuje správné filtry dat (předponu a příponu).
    1. Pokud chcete zobrazit oznámení událostí, v kbelíku S3 vyberte kartu Vlastnosti a vyhledejte část Oznámení událostí.
    2. Pokud se tato část nezobrazí, vytvořte ji.
    3. Ověřte, že služba SQS má příslušné zásady získávání dat z kbelíku S3. Ve službě SQS musí být tyto zásady na kartě Zásady přístupu.

Příčina 4: SQS nečte data

SQS nečte data S3 úspěšně.

Řešení: Ověřte, že SQS čte data.

  1. V AWS otevřete příslušnou službu SQS.

  2. Na kartě Monitorování by se měl zobrazit provoz ve widgetech Počet odstraněných zpráv a Počet přijatých zpráv.

  3. Jedna špička dat nestačí. Počkejte, až bude k dispozici dostatek dat (několik špiček) a pak zkontrolujte problémy.

  4. Pokud je některý z widgetů prázdný, spuštěním následujícího dotazu zkontrolujte protokoly stavu:

    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. Ujistěte se, že je povolená funkce sledování stavu:

    SentinelHealth 
| take 20

  6. Pokud funkce sledování stavu není povolená, povolte ji.

Data z konektoru AWS S3 (nebo jednoho z jeho datových typů) se v Microsoft Sentinelu zobrazují se zpožděním delším než 30 minut.

K tomuto problému obvykle dochází, když Microsoft nemůže číst soubory ve složce S3. Microsoft nemůže číst soubory, protože jsou buď zašifrované, nebo ve špatném formátu. V těchto případech mnoho opakování nakonec způsobí zpoždění příjmu dat.

Určení příčiny vašeho problému

V této části se věnujeme těmto příčinám:

  • Šifrování protokolu není správně nastavené
  • Oznámení událostí nejsou definována správně.
  • Chyby stavu nebo zakázání stavu

Příčina 1: Šifrování protokolu není správně nastavené

Pokud jsou protokoly plně nebo částečně zašifrované službou Služba správy klíčů (KMS), služba Microsoft Sentinel nemusí mít pro tuto službu KmS oprávnění k dešifrování souborů.

Řešení: Kontrola šifrování protokolu

Ujistěte se, že služba Microsoft Sentinel má pro tuto službu KmS oprávnění k dešifrování souborů. Projděte si požadovaná oprávnění KMS pro protokoly GuardDuty a CloudTrail.

Příčina 2: Oznámení událostí nejsou správně nakonfigurovaná

Když nakonfigurujete oznámení události Amazon S3, musíte určit, které podporované typy událostí Amazon S3 by měly oznámení odeslat. Pokud typ události, kterou jste nezadali, existuje v kontejneru Amazon S3, Amazon S3 oznámení neodesílá.

Řešení: Ověřte, že jsou správně definovaná oznámení událostí.

Pokud chcete ověřit, že jsou správně definována oznámení událostí z S3 na SQS, zkontrolujte, že:

  • Oznámení je definované z konkrétní složky, která obsahuje protokoly, a ne z hlavní složky, která obsahuje kbelík.
  • Oznámení je definováno s příponou .gz . Příklad:

Příčina 3: Chyby stavu nebo zakázání stavu

V protokolech stavu můžou docházet k chybám nebo je možné, že funkce stavu není povolená.

Řešení: Ověřte, že v protokolech stavu nedošlo k žádným chybám, a povolte stav.

  1. Spuštěním následujícího příkazu ověřte, že protokoly stavu neobsahují žádné chyby:

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

  2. Ujistěte se, že je povolená funkce sledování stavu:

    SentinelHealth 
| take 20

  3. Pokud funkce sledování stavu není povolená, povolte ji.

    Další informace o následujících položkách použitých v předchozím příkladu najdete v dokumentaci Kusto:

    Další informace o KQL najdete v přehledu dotazovací jazyk Kusto (KQL).

    Další zdroje informací:

Další kroky

V tomto článku jste zjistili, jak rychle identifikovat příčiny a řešit běžné problémy s konektorem AWS S3.

Vítáme zpětnou vazbu, návrhy, žádosti o funkce, zprávy o chybách nebo vylepšení a doplňky. Přejděte do úložiště GitHub pro Microsoft Sentinel a vytvořte problém nebo fork a nahrajte příspěvek.