Blokering af offentlig adgang og bucket-politikker

Lækkede data fra en forkert konfigureret S3-bucket (Simple Storage Service) er et af de mest almindelige cloud-brud. Én forkert indstilling kan eksponere millioner af objekter for hele internettet.

S3 er privat som standard, men flere lag af tilladelser kan utilsigtet åbne den. Det er vigtig sikkerhedsviden at forstå disse lag.

Adgang til et S3-objekt kan gives gennem flere mekanismer:

• IAM-politikker for brugere og roller.
• Bucket-politikker, der er knyttet til bucketen.
• ACL'er (adgangskontrollister) for buckets og objekter.
• Indstillinger for Block Public Access, der tilsidesætter resten.

Offentlig eksponering skyldes som regel en bucket-politik eller ACL, der er konfigureret forkert.

S3 Block Public Access (BPA) er en overordnet sikkerhedskontakt. Når den er aktiveret, tilsidesætter den enhver bucket-politik eller ACL, der ville give offentlig adgang, uanset hvad disse angiver.

AWS aktiverer nu BPA som standard for nye buckets. Lad den være aktiveret på kontoniveau, så én forkert konfigureret politik aldrig kan lække data offentligt.

BPA har fire uafhængige indstillinger, der blokerer offentlige ACL'er, ignorerer eksisterende offentlige ACL'er, blokerer offentlige bucket-politikker og begrænser offentlig adgang gennem ethvert adgangspunkt.

Tilsammen fungerer de som en fast øvre grænse: Selv hvis nogen skriver en politik, der giver offentlig læseadgang, afviser BPA den. Det er din stærkeste beskyttelse mod utilsigtet eksponering.

En bucket-politik er en JSON-politik baseret på ressourcer, som er knyttet til en bucket. Den definerer, hvem (den pågældende) der kan udføre hvilke handlinger på hvilke objekter og under hvilke betingelser.

Bucket-politikker er effektive til adgang på tværs af konti og detaljeret kontrol, men en ubetænksom Principal på "*" giver hele verden adgang. Gennemgå dem omhyggeligt.

Uddraget, du netop så, er præcis sådan et datalæk ser ud: Principal "*" sammen med s3:GetObject giver alle anonyme brugere læseadgang til alle objekter.

Medmindre du med vilje hoster offentligt indhold, er dette en forkert konfiguration. Block Public Access ville tilsidesætte den, og derfor er BPA dit sikkerhedsnet.

Bucket-politikker gør mere end at give adgang; de kan kræve sikkerhedsbetingelser. Et almindeligt mønster afviser enhver upload, der ikke er krypteret eller ikke ankommer via TLS.

Ved at bruge en Deny med en betingelse på aws:SecureTransport eller s3:x-amz-server-side-encryption håndhæver du sikker datahåndtering ved hver skrivning.

Betingelser strammer politikker ved at knytte dem til konteksten: Tillad kun adgang fra et bestemt VPC-endepunkt, et kendt IP-område eller en organisation med aws:PrincipalOrgID.

Med disse betingelsesnøgler kan du give præcis den adgang, en arbejdsbelastning har brug for, og intet mere, så konsekvenserne begrænses, hvis en legitimationsoplysning nogensinde misbruges.

Værktøjer hjælper dig med at finde risici, før angribere gør det. IAM Access Analyzer markerer buckets, der deles uden for din konto, og S3-konsollen viser en indikator for, om hver bucket er offentlig eller ikke offentlig.

AWS Config-regler og Security Hub kan løbende kontrollere, at Block Public Access forbliver aktiveret for alle buckets.

Anvend Block Public Access på kontoniveau og ikke kun pr. bucket, så indstillingen automatisk gælder for alle eksisterende og fremtidige buckets.

Håndhævelse på tværs af kontoen lukker hullet, hvor en nyoprettet bucket ellers kunne slippe igennem. Brug AWS Config og SCP'er til at sikre, at ingen kan slå indstillingen fra, så offentlig eksponering bliver strukturelt umulig.

Ingen enkelt kontrol er tilstrækkelig. Kombiner Block Public Access på kontoniveau, bucket-politikker med mindst mulige rettigheder, standardkryptering og løbende revision.

Hvis ét lag er konfigureret forkert, beskytter de andre stadig dine data. Lagdeling er det, der gør S3 til pålidelig privat lagring i stedet for en hyppig kilde til databrud.

Forkert konfiguration af S3 er en af de hyppigste årsager til databrud. Adgang er opdelt i lag på tværs af IAM, bucket-politikker, ACL'er og hovedkontakten Block Public Access — som tilsidesætter enhver offentlig tildeling og bør være aktiveret for hele kontoen. En politik med Principal "*" lækker data; brug betingelser til at håndhæve TLS, kryptering og afgrænset adgang i stedet. Foretag løbende revision med Access Analyzer, Config og Security Hub, og basér dig på forsvar i dybden, så én enkelt fejl ikke eksponerer dine objekter.