Bygge tabeller over CloudTrail-data

Athena kan ikke spørre mot rå S3-filer før du forteller tjenesten hvordan de skal leses. En tabell kobler CloudTrail-JSON-filene i S3-bøtten til navngitte kolonner med datatyper. Når tabellen finnes, kan den rike strukturen i CloudTrail-hendelsene nås med vanlig SQL.

CloudTrail leverer hendelser som JSON, der hver post beskriver ett API-kall med nestede felt som userIdentity, eventName, sourceIPAddress og requestParameters. Tabellskjemaet må gjenspeile denne nestingen, blant annet med struct-typer for objekter, slik at spørringer kan nå felt som userIdentity.arn.

Du trenger ikke å skrive skjemaet for hånd. AWS publiserer en standard CREATE TABLE-setning for CloudTrail, og både CloudTrail-konsollen og Athena kan generere den for deg. Når du bruker den medfølgende DDL-en, sikrer du at alle felt, også de som ligger dypt nestet, blir riktig tilordnet, slik at spørringene dine ikke går glipp av data.

En SerDe (Serializer/Deserializer) forteller Athena hvordan hver fil skal tolkes. CloudTrail-tabeller bruker en SerDe som er utformet for CloudTrail-oppsettet i JSON, og som forstår både records-arrayet og nestede strukturer. Det er avgjørende å velge riktig SerDe; en feil kan føre til tolkningsfeil eller NULL-verdier i kolonnene.

Tabellens LOCATION-uttrykk peker på S3-prefikset der CloudTrail lagrer logger, vanligvis en bane som inneholder konto-ID og region. Det er viktig å angi riktig prefiks: Et for bredt prefiks gjør at du skanner irrelevante data, mens et for smalt prefiks gjør at du går glipp av hendelser du ønsket å spørre etter.

Når tabellen er opprettet, kan du spørre etter nestede felt ved hjelp av punktnotasjon, for eksempel userIdentity.arn eller requestParameters.bucketName. SQL-funksjoner hjelper deg med å pakke ut arrayer og JSON-strenger. Det er her Athena virkelig utmerker seg i undersøkelser: Du kan filtrere presist på hendelsesnavn, principal og parametere for alle API-kall.

I stedet for manuell DDL kan en AWS Glue crawler skanne S3-dataene og automatisk utlede et skjema i Data Catalog. For velkjente formater som CloudTrail er den medfølgende DDL-en vanligvis ryddigere, men crawlere er nyttige for egendefinerte eller skiftende loggformater der du helst vil slippe å skrive skjemaet manuelt.

CloudTrail-JSON inneholder felt som selv er JSON-strenger, for eksempel requestParameters når verdiene varierer mellom tjenester. Du tolker ofte disse ved spørringstidspunktet ved hjelp av JSON-funksjoner. Når du vet at enkelte kolonner er strenger som må tolkes, og ikke forhåndsstrukturerte kolonner, unngår du forvirring når et felt ikke oppfører seg som en vanlig kolonne.

For et organisasjonsspor havner logger fra alle kontoer i én bøtte, under prefikser som er spesifikke for hver konto. Du kan opprette én tabell over hele prefikset for å spørre mot alle kontoer samtidig, eller separate tabeller per konto for å holde dem atskilt. En samlet tabell er svært nyttig for trusseljakt i hele organisasjonen med én spørring.

Etter at du har opprettet tabellen, kjører du en rask SELECT med en liten LIMIT for å bekrefte at rader returneres og at kolonnene fylles ut som forventet. Hvis kolonnene er NULL, er det sannsynligvis noe galt med SerDe-en, plasseringen eller skjemaet. Denne rimelighetssjekken hindrer deg i å bygge undersøkelser på en tabell som i stillhet er ødelagt.

Når CloudTrail-tabellen er riktig, har du et søkbart revisjonsspor som dekker hele den registrerte historikken. Hver konsollpålogging, hvert API-kall og hver feil er nå en rad du kan filtrere og aggregere. Denne tabellen er grunnlaget for hendelsesspørringene du skal skrive videre.

For å spørre etter CloudTrail i Athena oppretter du en tabell som kobler JSON-filene til kolonner. Du bruker AWS sin medfølgende CREATE TABLE DDL, riktig SerDe og riktig S3-LOCATION. Spør etter nestede felt med punktnotasjon, tolk JSON-strengkolonner ved spørringstidspunktet, og bekreft resultatet med en liten SELECT. Et organisasjonsspor kan samles i én tabell for trusseljakt i hele organisasjonen.