S3-tilgangskontroll: Bucket-policyer og ACL-er
Skriv bucket-policyer, sammenlign dem med ACL-er og konfigurer innstillinger for blokkering av offentlig tilgang for sikker hosting.
S3-tilgangskontroll: Bucket-policyer og ACL-er er en gratis leksjon i Cloud & IT Cert Prep på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cloud & IT Cert Prep, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.
Oversikt over tilgangskontroll i S3
S3 tilbyr flere overlappende mekanismer for tilgangskontroll: IAM-policyer (identitetsbaserte, styrer hva principaler kan gjøre), bøttepolicyer (ressursbaserte JSON-policyer for bøtten), Access Control Lists (ACLs) (eldre mekanisme for tillatelser per objekt eller bøtte) og S3 Block Public Access (en overstyring på konto- eller bøttenivå som blokkerer all offentlig tilgang, uavhengig av andre policyer). For de fleste bruksområder i dag anbefales bøttepolicyer sammen med Block Public Access – ACL-er regnes som en eldre løsning.
Bucket-policyer: ressursbasert JSON
En bucket-policy er et JSON-dokument som er direkte knyttet til S3-bucketen. Den angir hvilke principal-er (IAM-brukere, roller, AWS-kontoer, tjenester eller offentligheten) som kan utføre hvilke handlinger på hvilke ressurser (bucket-en og/eller bestemte nøkkelprefikser). Bucket-policyer støtter tilgang på tvers av kontoer uten at IAM-roller er nødvendige: De kan gi en IAM-rolle i en annen AWS-konto lesetilgang til bestemte objekter direkte gjennom bucket-policyen. Hver bucket kan ha én policy, og den maksimale størrelsen er 20 KB.
# Allow a specific IAM role from another account to read objects
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': {
'AWS': 'arn:aws:iam::999999999999:role/PartnerReadRole'
},
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/partner-data/*'
}]
}Gjøre objekter offentlig lesbare
For å levere offentlig innhold (for eksempel ressurser til et statisk nettsted eller offentlige datasett) kan De gjøre objekter offentlig lesbare gjennom en bucket-policy. Først må De deaktivere Block Public Access på bucket-nivå og deretter legge til en bucket-policy-setning med Principal: '*' og Action: s3:GetObject. Det kreves både at innstillingen Block Public Access deaktiveres, og at bucket-policyen har Allow—det fungerer ikke å aktivere bare den ene. Begrens alltid Resource til et bestemt prefiks i stedet for hele bucket-en, med mindre De med hensikt vil gjøre alle objekter offentlige.
# Public read policy for static website assets
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': '*',
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-website-bucket/public/*'
}]
}Innstillinger for S3 Block Public Access
S3 Block Public Access er et sikkerhetsnett med fire innstillinger som overstyrer bucket-policyer og ACL-er: BlockPublicAcls (avviser forespørsler om å angi offentlige ACL-er), IgnorePublicAcls (ignorerer eksisterende offentlige ACL-er), BlockPublicPolicy (avviser bucket-policyer som gir offentlig tilgang) og RestrictPublicBuckets (begrenser tilgang basert på offentlig policy). Alle fire innstillingene er aktivert som standard. De kan også aktivere Block Public Access på kontonivå, slik at det blokkeres for alle bucketer uavhengig av innstillingene for den enkelte bucket-en—ideelt for å forhindre utilsiktet offentlig eksponering.
# Enable all Block Public Access settings on a bucket
aws s3api put-public-access-block \
--bucket my-private-bucket \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=trueAccess Control Lists (ACL-er): eldre mekanisme
S3 ACL-er er den opprinnelige mekanismen for tilgangskontroll og kom før IAM. En ACL tildeler forhåndsdefinerte tillatelser (READ, WRITE, FULL_CONTROL) til AWS-kontoer eller forhåndsdefinerte grupper (alle brukere, autentiserte AWS-brukere og logglevering). ACL-er kan brukes på bucket-nivå eller på individuelt objektnivå. AWS anbefaler nå å deaktivere ACL-er (innstillingen «Bucket Owner Enforced» i S3 gjør at bucket-eieren eier alle objekter og deaktiverer ACL-er) og heller bruke bucket-policyer og IAM. ACL-er testes fortsatt i SAA-C03-eksamen som et eldre konsept.
# Disable ACLs by setting ownership to BucketOwnerEnforced
aws s3api put-bucket-ownership-controls \
--bucket my-bucket \
--ownership-controls '{"Rules":[{"ObjectOwnership":"BucketOwnerEnforced"}]}'Origin Access Control for CloudFront
Når De leverer S3-innhold gjennom CloudFront, bør bucket-en være privat, samtidig som CloudFront kan hente objekter. Bruk Origin Access Control (OAC)—den moderne erstatningen for Origin Access Identity (OAI). OAC oppretter en CloudFront-identitet som De gir tillatelsen s3:GetObject gjennom bucket-policyen, mens Block Public Access fortsatt er aktivert. På denne måten må brukerne gå gjennom CloudFront (for hurtigbufring, WAF og HTTPS) og kan ikke få direkte tilgang til bucket-en—et vanlig sikkert arkitekturmønster på SAA-C03-eksamen.
# Bucket policy granting CloudFront OAC access
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': {
'Service': 'cloudfront.amazonaws.com'
},
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/*',
'Condition': {
'StringEquals': {
'AWS:SourceArn': 'arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE'
}
}
}]
}S3-tilgang på tvers av kontoer
Det finnes to måter å gi en annen AWS-konto tilgang til S3-bucket-en Deres på. Alternativ 1 — bucket-policy: Legg til en setning med ARN-en til den eksterne kontoen som Principal og de ønskede S3-handlingene. IAM-brukerne og -rollene i den eksterne kontoen trenger fortsatt IAM-tillatelser til å kalle S3, og bucket-policyen må i tillegg gi dem Allow. Alternativ 2 — IAM-rolle med trust policy: Opprett en rolle i kontoen Deres som den eksterne kontoen stoler på. Identitetene i den eksterne kontoen antar rollen og får tillatelsene til bucket-en Deres. Bucket-policy er enklere i skrivebeskyttede scenarier, mens roller er bedre for operasjonell tilgang.
CORS-konfigurasjon for webapplikasjoner
Cross-Origin Resource Sharing (CORS) gjør det mulig for en webapplikasjon som ligger på ett domene, å gjøre JavaScript-forespørsler med fetch til en S3-bucket på et annet domene. Uten en CORS-konfigurasjon blokkerer nettlesere disse forespørslene av sikkerhetshensyn. De legger til en CORS-konfigurasjon i bucket-en som angir tillatte origins, HTTP-metoder og headere. CORS er vanligvis nødvendig når en React SPA på example.com henter bilder eller filer direkte fra en S3-bucket-URL.
# Apply a CORS configuration
aws s3api put-bucket-cors \
--bucket my-website-bucket \
--cors-configuration '{"CORSRules":[{"AllowedOrigins":["https://example.com"],"AllowedMethods":["GET"],"AllowedHeaders":["*"],"MaxAgeSeconds":3600}]}'Forhåndssignerte URL-er for midlertidig tilgang
En forhåndssignert URL gir tidsbegrenset tilgang til et privat S3-objekt (for GET eller PUT) uten å endre tillatelsene for bucket-en eller objektet. URL-en inneholder legitimasjonen Deres og et utløpstidspunkt—alle som har URL-en, kan få tilgang til objektet frem til den utløper. Bruk forhåndssignerte URL-er til å la autentiserte brukere i applikasjonen laste ned private filer, la klienter laste opp direkte til S3 uten å gå gjennom backend-en, eller dele rapporter midlertidig. Utløpstiden kan være fra 1 sekund til 7 dager (ved bruk av midlertidig legitimasjon fra STS er maksimum 12 timer).
# Generate a pre-signed GET URL valid for 24 hours
aws s3 presign s3://my-private-bucket/reports/invoice.pdf \
--expires-in 86400
# Generate a pre-signed PUT URL (for client uploads)
aws s3 presign s3://my-private-bucket/uploads/new-file.pdf \
--expires-in 3600 \
--method PUTBetingelser i bucket-policyer for sikkerhet
Bruk betingelser i bucket-policyer for å legge til kontekstbasert sikkerhet. Vanlige mønstre er: aws:SourceIp begrenser tilgang til bestemte IP-områder (for eksempel VPC-endepunkter eller bedriftsnettverk); aws:SecureTransport: true tvinger frem HTTPS ved å avvise forespørsler over HTTP (en anbefalt praksis for alle bucketer som lagrer sensitive data); s3:x-amz-server-side-encryption sikrer at objekter må lastes opp med server-side-kryptering; og aws:PrincipalOrgID begrenser tilgangen til principal-er i AWS-organisasjonen Deres og forhindrer dataeksfiltrering til eksterne kontoer.
# Deny non-HTTPS access to the bucket
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:*',
'Resource': [
'arn:aws:s3:::my-secure-bucket',
'arn:aws:s3:::my-secure-bucket/*'
],
'Condition': {
'Bool': {'aws:SecureTransport': 'false'}
}
}S3 VPC-endepunkter for privat tilgang
Som standard får EC2-instanser i et privat subnett tilgang til S3 over internett (via en NAT-gateway), noe som medfører NAT-kostnader og eksponerer trafikken mot det offentlige internett. S3 Gateway Endpoints gir privat tilkobling til S3 fra en VPC uten en NAT-gateway og uten ekstra kostnad. De legger Gateway Endpoint til i rutetabellen, og trafikk til S3 rutes automatisk gjennom AWS sitt private nettverk. De kan også legge til betingelser i bucket-policyen ved hjelp av aws:SourceVpce for å begrense tilgangen til forespørsler som kun kommer gjennom endepunktet.
# Create an S3 gateway endpoint and associate with route tables
aws ec2 create-vpc-endpoint \
--vpc-id vpc-12345678 \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-12345678Kort kunnskapssjekk
Test forståelsen Deres av AWS Solutions Architect-konsepter (SAA-C03) fra denne leksjonen.
Oppsummering av leksjonen
I denne leksjonen har De lært at bucket-policyer er ressursbaserte JSON-dokumenter som styrer tilgang på tvers av kontoer og tjenestetilgang til S3, at S3 Block Public Access er en sikkerhetsoverstyring som forhindrer utilsiktet offentlig eksponering, og at forhåndssignerte URL-er, VPC-endepunkter og CORS-konfigurasjoner håndterer bestemte tilgangsmønstre på en sikker måte. Deretter ser vi på S3-versjonering, MFA Delete og replikering.
Lær deg Cloud & IT Cert Prep med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 150
- Leksjoner
- 600
Ofte stilte spørsmål
Er leksjonen «S3-tilgangskontroll: Bucket-policyer og ACL-er» gratis?
Ja – hele teksten i «S3-tilgangskontroll: Bucket-policyer og ACL-er» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Cloud & IT Cert Prep-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.
Hva lærer jeg i «S3-tilgangskontroll: Bucket-policyer og ACL-er»?
Skriv bucket-policyer, sammenlign dem med ACL-er og konfigurer innstillinger for blokkering av offentlig tilgang for sikker hosting. Du øver på Cloud & IT Cert Prep med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Cloud & IT Cert Prep?
Ingen tidligere erfaring er nødvendig. Cloud & IT Cert Prep på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.
Hvor lang tid tar leksjonen «S3-tilgangskontroll: Bucket-policyer og ACL-er»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Cloud & IT Cert Prep-leksjonen?
Ja. Alle Cloud & IT Cert Prep-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Bucket-er, objekter og regioner
- S3-tilgangskontroll: Bucket-policyer og ACL-er
- Versjonering, MFA Delete og replikering
- Lagringsklasser og livssykluspolicyer