Sikring af buckets til loglagring

CloudTrail, Config og Flow Logs opbevarer i sidste ende data i S3-bucketer. Denne bucket er kronjuvelen i dit revisionsspor og fortjener derfor den stærkeste beskyttelse. Hvis bucketen er sikker, kan en angriber, der kompromitterer en arbejdsbelastning, stadig ikke få adgang til beviserne på, hvad vedkommende gjorde.

Den første kontrol er S3 Block Public Access, som sikrer, at logbucketen aldrig eksponeres mod internettet. En offentligt læsbar logbucket lækker følsomme driftsoplysninger til alle. Ved at aktivere Block Public Access på konto- og bucket-niveau lukker du denne risiko effektivt.

En stram bucket-politik bør kun tillade logningstjenesten at skrive og kun bestemte sikkerhedsroller at læse, mens alle andre afvises. Du kan også afvise s3:DeleteObject for alle principaler, så logge ikke kan fjernes gennem normale API-kald. Det er et stærkt grundlag mod tilfældig manipulation.

S3 Object Lock håndhæver write-once-read-many (WORM)-opbevaring og gør objekter reelt uforanderlige i en bestemt periode. Selv en kontoadministrator kan ikke slette eller overskrive et låst objekt, før opbevaringsperioden udløber. Det er det stærkeste forsvar mod en angriber eller insider, der forsøger at slette logge.

Object Lock har to tilstande. I Governance mode kan brugere med særlige tilladelser tilsidesætte låsen. I Compliance mode kan ingen, heller ikke root-brugeren, slette data eller forkorte opbevaringsperioden, før den udløber. For regulerede revisionslogge giver Compliance mode den stærkeste garanti.

Object Lock kræver versionering, som bevarer hver version af et objekt. Versionering alene hjælper også: Hvis en angriber overskriver et objekt, forbliver den tidligere version. Kombineret med et afslag på DeleteObjectVersion gør versionering det langt sværere at ødelægge historikken end blot at slette ét aktuelt objekt.

MFA Delete kræver multifaktorgodkendelse for permanent at slette objektversioner eller ændre versioneringstilstanden. Det tilføjer en menneskestyret, hardwarebaseret kontrol foran destruktive handlinger i logbucketen, så selv en kompromitteret legitimationsoplysning ikke lydløst kan rydde versioner uden MFA-enheden.

Kryptér logdata under opbevaring med KMS, helst med en kundeadministreret nøgle, hvis politik begrænser, hvem der kan dekryptere. Det beskytter fortroligheden, fordi logge ofte indeholder følsomme oplysninger som brugernavne og IP-adresser. KMS opretter også en revisionsregistrering af hver dekryptering, hvilket giver indsigt i, hvem der læser loggene.

Aktivér S3-serveradgangslogning, eller brug CloudTrail-datahændelser på logbucketen, så du kan se, hvem der har tilgået den. Opret alarmer for uventede læsninger eller ethvert sletteforsøg. Overvågning af selve logbucketen sikrer, at et angreb på dine beviser ironisk nok også bliver registreret.

Ingen enkelt indstilling er tilstrækkelig. Block Public Access, en bucket-politik med afvisning af sletning, Object Lock i Compliance mode, versionering, MFA Delete og KMS-kryptering gør tilsammen bucketen modstandsdygtig over for sletning, ændring og eksponering. Målet er forsvar i dybden: Hvert lag dækker de andres huller.

En korrekt låst logbucket er uforanderlig, privat, krypteret og overvåget. Kombineret med CloudTrail-logfilvalidering til registrering af manipulation sikrer den, at dine beviser både overlever og forbliver beviseligt intakte. Denne hærdning på bucket-niveau er præcis det, eksamensscenarier om beskyttelse af logge forventer.

Sikr logbuckets med lagdelte kontroller: Block Public Access, en bucket-politik, der afviser sletning, S3 Object Lock (Compliance-tilstand kan ikke omgås, mens Governance kan tilsidesættes), versionering, MFA Delete og KMS-kryptering for fortrolighed. Overvåg adgang med S3-adgangslogning eller CloudTrail-datahændelser. Tilsammen gør de loggene uforanderlige, private og overvågede.