Låse ned lagringsbuckets for logger

CloudTrail, Config og Flow Logs lagrer til syvende og sist data i S3-bøtter. Denne bøtten er kronjuvelen i revisjonssporet, og fortjener derfor den sterkeste beskyttelsen. Hvis bøtten er sikker, kan en angriper som kompromitterer en arbeidsbelastning, fortsatt ikke nå bevisene på det som ble gjort.

Den første kontrollen er S3 Block Public Access, som sikrer at loggbøtten aldri eksponeres mot internett. En offentlig lesbar loggbøtte lekker sensitive driftsdetaljer til hvem som helst. Ved å aktivere Block Public Access på konto- og bøttenivå lukkes denne risikoen effektivt.

En streng bøttepolicy bør bare tillate loggtjenesten å skrive og bare bestemte sikkerhetsroller å lese, mens alle andre nektes tilgang. De kan også nekte s3:DeleteObject for alle prinsipal-er, slik at logger ikke kan fjernes gjennom vanlige API-kall. Dette gir et sterkt grunnvern mot tilfeldig manipulering.

S3 Object Lock håndhever write-once-read-many (WORM)-lagring og gjør objekter virkelig uforanderlige i en bestemt periode. Selv en kontoadministrator kan ikke slette eller overskrive et låst objekt før oppbevaringsperioden utløper. Dette er det sterkeste forsvaret mot at en angriper eller en intern bruker sletter logger.

Object Lock har to moduser. I Governance mode kan brukere med særskilte tillatelser overstyre låsen. I Compliance mode kan ingen, heller ikke rotbrukeren, slette objekter eller forkorte oppbevaringsperioden før den utløper. For regulerte revisjonslogger gir Compliance mode den sterkeste garantien.

Object Lock krever versjonering, som beholder hver versjon av et objekt. Versjonering alene er også nyttig: Hvis en angriper overskriver et objekt, blir den forrige versjonen værende. Kombinert med en nektelse av DeleteObjectVersion gjør versjonering det langt vanskeligere å ødelegge historikken enn å slette ett enkelt gjeldende objekt.

MFA Delete krever flerfaktorautentisering for å slette objektversjoner permanent eller endre versjoneringstilstanden. Det legger inn en menneskestyrt, maskinvarebasert kontroll foran destruktive handlinger i loggbøtten, slik at selv en kompromittert påloggingsinformasjon ikke kan tømme versjoner i det stille uten MFA-enheten.

Krypter loggdata i hvile med KMS, helst med en kundeadministrert nøkkel der policyen begrenser hvem som kan dekryptere. Dette beskytter konfidensialiteten, siden logger ofte inneholder sensitive detaljer som brukernavn og IP-adresser. KMS oppretter også en revisjonspost for hver dekryptering, noe som gir bedre oversikt over hvem som leser loggene.

Aktiver S3-servertilgangslogging, eller bruk CloudTrail-datahendelser på loggbøtten, slik at De kan se hvem som har fått tilgang til den. Sett opp alarmer for uventede lesinger eller alle forsøk på sletting. Ved å overvåke selve loggbøtten sørger De for at et angrep på bevisene Deres, ironisk nok, også blir registrert.

Ingen enkeltinnstilling er tilstrekkelig. Block Public Access, en bøttepolicy som nekter sletting, Object Lock i Compliance-modus, versjonering, MFA Delete og KMS-kryptering gjør til sammen bøtten motstandsdyktig mot sletting, endring og eksponering. Målet er forsvar i dybden: Hvert lag dekker svakhetene i de andre.

En riktig nedlåst loggbøtte er uforanderlig, privat, kryptert og overvåket. Kombinert med validering av CloudTrail-loggfiler for å oppdage manipulering sikrer den at bevisene både overlever og forblir beviselig intakte. Denne herdingen på bøttenivå er nøyaktig det eksamensscenarier om beskyttelse av logger forventer.

Sikre loggbucket-er med lagdelte kontroller: Block Public Access, en bucket policy som nekter sletting, S3 Object Lock (Compliance-modus kan ikke brytes, mens Governance kan overstyres), versjonering, MFA Delete og KMS-kryptering for konfidensialitet. Overvåk tilgangen med S3 access logging eller CloudTrail-datahendelser. Til sammen gjør dette loggene uforanderlige, private og overvåkede.