Lås ned buckets för logglagring

CloudTrail, Config och Flow Logs lagrar i slutänden data i S3-buckets. Den bucketen är granskningsspårets mest värdefulla tillgång och förtjänar därför det starkaste skyddet. Om bucketen är säker kan en angripare som komprometterar en arbetslast fortfarande inte komma åt bevisen för vad angriparen gjorde.

Den första kontrollen är S3 Block Public Access, som säkerställer att loggbucketen aldrig exponeras mot internet. En offentligt läsbar loggbucket läcker känslig information om verksamheten till vem som helst. Genom att aktivera Block Public Access på konto- och bucketnivå elimineras denna risk effektivt.

En strikt bucketpolicy bör endast tillåta loggningstjänsten att skriva och endast specifika säkerhetsroller att läsa, medan alla andra nekas åtkomst. Du kan även neka s3:DeleteObject för alla principaler så att loggar inte kan tas bort via normala API-anrop, vilket ger ett starkt grundskydd mot enkel manipulering.

S3 Object Lock tillämpar write-once-read-many (WORM)-lagring och gör objekt verkligen oföränderliga under en viss period. Inte ens en konto administratör kan ta bort eller skriva över ett låst objekt innan lagringsperioden löper ut. Detta är det starkaste skyddet mot att en angripare eller en intern användare tar bort loggar.

Object Lock har två lägen. I Governance mode kan användare med särskilda behörigheter kringgå låset. I Compliance mode kan ingen, inte ens root-användaren, ta bort objekt eller förkorta lagringsperioden innan den löper ut. För reglerade granskningsloggar ger Compliance mode den starkaste garantin.

Object Lock kräver versionshantering, som bevarar varje version av ett objekt. Även versionshantering utan Object Lock är till hjälp: om en angripare skriver över ett objekt finns den tidigare versionen kvar. I kombination med ett nekande av DeleteObjectVersion blir det mycket svårare att förstöra historiken än genom att ta bort ett enda aktuellt objekt.

MFA Delete kräver flerfaktorsautentisering för att permanent ta bort objektversioner eller ändra versionshanteringens status. Det lägger till en mänsklig, hårdvarubaserad spärr framför destruktiva åtgärder i loggbucketen, så att inte ens komprometterade autentiseringsuppgifter i hemlighet kan rensa versioner utan MFA-enheten.

Kryptera loggdata i vila med KMS, helst med en kundhanterad nyckel vars policy begränsar vilka som får dekryptera. Detta skyddar konfidentialiteten, eftersom loggar ofta innehåller känsliga uppgifter som användarnamn och IP-adresser. KMS skapar även en granskningspost för varje dekryptering, vilket ger insyn i vem som läser loggarna.

Aktivera S3-serveråtkomstloggning eller använd CloudTrail-datahändelser för loggbucketen, så att du kan se vem som har åtkomst till den. Skapa alarm för oväntad läsning eller alla försök att ta bort data. Genom att övervaka själva loggbucketen säkerställer du att ett angrepp mot dina bevis ironiskt nog också registreras.

Ingen enskild inställning räcker. Block Public Access, en bucketpolicy som nekar radering, Object Lock i Compliance mode, versionshantering, MFA Delete och KMS-kryptering gör tillsammans bucketen motståndskraftig mot radering, ändring och exponering. Målet är försvar i flera lager: varje lager täcker de brister som finns i de andra.

En korrekt låst loggbucket är oföränderlig, privat, krypterad och övervakad. Tillsammans med CloudTrail-validering av loggfiler för att upptäcka manipulering säkerställer den att dina bevis både överlever och förblir bevisligen intakta. Denna förstärkning på bucketnivå är precis vad provscenarier om loggskydd förväntar sig.

Härda loggbucketar med lager på lager av kontroller: Block Public Access, en bucket policy som nekar borttagning, S3 Object Lock (Compliance-läget kan inte kringgås, medan Governance-läget kan åsidosättas), versionering, MFA Delete och KMS-kryptering för konfidentialitet. Övervaka åtkomst med S3 access logging eller CloudTrail-datahändelser. Tillsammans gör de loggarna oföränderliga, privata och övervakade.