Blokkere offentlig tilgang og bucket-policyer

Lekkede data fra en feilkonfigurert S3-bøtte (Simple Storage Service) er blant de vanligste nettskybaserte datainnbruddene. Én feil innstilling kan eksponere millioner av objekter for hele internett.

S3 er privat som standard, men flere lag med tillatelser kan åpne den ved et uhell. Å forstå disse lagene er avgjørende sikkerhetskunnskap.

Tilgang til et S3-objekt kan gis gjennom flere mekanismer:

• IAM-policyer for brukere og roller.
• Bøttepolicyer knyttet til bøtten.
• ACL-er (tilgangskontrollister) for bøtter og objekter.
• Block Public Access-innstillinger som overstyrer resten.

Offentlig eksponering skyldes vanligvis en feil i en bøttepolicy eller ACL.

S3 Block Public Access (BPA) er en overordnet sikkerhetsbryter. Når den er aktivert, overstyrer den alle bøttepolicyer eller ACL-er som ville gitt offentlig tilgang, uansett hva disse sier.

AWS aktiverer nå BPA som standard for nye bøtter. La den være aktivert på kontonivå, slik at én feilkonfigurert policy aldri kan lekke data offentlig.

BPA har fire uavhengige innstillinger som blokkerer offentlige ACL-er, ignorerer eksisterende offentlige ACL-er, blokkerer offentlige bøttepolicyer og begrenser offentlig tilgang gjennom alle tilgangspunkter.

Sammen fungerer de som et absolutt tak: Selv om noen skriver en policy som gir offentlig lesetilgang, avviser BPA den. Det er Deres sterkeste sikkerhetsvern mot utilsiktet eksponering.

En bøttepolicy er en ressursbasert JSON-policy knyttet til en bøtte. Den definerer hvem (aktøren) som kan utføre hvilke handlinger på hvilke objekter, og under hvilke betingelser.

Bøttepolicyer er effektive for tilgang på tvers av kontoer og detaljert kontroll, men en uforsiktig Principal med verdien "*" gir hele verden tilgang. Gå nøye gjennom dem.

Utdraget De nettopp så, er nøyaktig slik en datalekkasje ser ut: Principal "*" sammen med s3:GetObject gir alle anonyme brukere lesetilgang til alle objekter.

Med mindre De med hensikt tilbyr offentlig innhold, er dette en feilkonfigurasjon. Block Public Access ville overstyrt den, og derfor er BPA sikkerhetsnettet Deres.

Bøttepolicyer gjør mer enn å gi tilgang; de kan kreve sikkerhetsbetingelser. Et vanlig mønster er å avvise alle opplastinger som ikke er kryptert eller ikke kommer over TLS.

Ved å bruke en Deny med en betingelse på aws:SecureTransport eller s3:x-amz-server-side-encryption håndheves sikker håndtering av data ved hver opplastingsoperasjon.

Betingelser gjør policyer mer presise ved å knytte dem til konteksten: Tillat bare tilgang fra et bestemt VPC-endepunkt, et kjent IP-område eller en organisasjon med aws:PrincipalOrgID.

Disse betingelsesnøklene lar Dem gi nøyaktig den tilgangen en arbeidsbelastning trenger, og ikke noe mer, slik at skadeomfanget blir mindre hvis en legitimasjon misbrukes.

Verktøy hjelper Dem med å finne risiko før angripere gjør det. IAM Access Analyzer markerer bucketer som er delt utenfor kontoen, og S3-konsollen viser en indikator for om hver bucket er offentlig eller ikke offentlig.

AWS Config-regler og Security Hub kan kontinuerlig kontrollere at Block Public Access fortsatt er aktivert for alle bucketer.

Bruk Block Public Access på kontonivå, ikke bare per bucket, slik at innstillingen automatisk gjelder for alle eksisterende og fremtidige bucketer.

Håndheving for hele kontoen lukker åpningen der en nyopprettet bucket kan slippe gjennom. Bruk AWS Config og SCP-er for å sikre at ingen kan slå av innstillingen, slik at offentlig eksponering blir strukturelt umulig.

Ingen enkeltkontroll er tilstrekkelig. Kombiner Block Public Access på kontonivå, bucket-policyer med minste privilegium, standardkryptering og kontinuerlig revisjon.

Hvis ett lag er feilkonfigurert, beskytter de andre fortsatt dataene Deres. Lagdeling er det som gjør S3 fra en hyppig kilde til datainnbrudd til pålitelig privat lagring.

Feilkonfigurering av S3 er en av de viktigste årsakene til datainnbrudd. Tilgang er lagdelt på tvers av IAM, bucket-policyer, ACL-er og hovedbryteren Block Public Access – som overstyrer alle offentlige tildelinger og bør være aktivert for hele kontoen. En policy med Principal "*" lekker data; bruk i stedet betingelser for å håndheve TLS, kryptering og avgrenset tilgang. Utfør kontinuerlig revisjon med Access Analyzer, Config og Security Hub, og bruk forsvar i dybden slik at ingen enkeltfeil eksponerer objektene Deres.