60 % av alle sikkerhetsbrudd i skyen starter med en feilkonfigurasjon, ifølge en 2026-rapport fra DeepStrike. Nesten halvparten av alle AWS S3-bøtter som analyseres av sikkerhetsforskere er potensielt feilkonfigurert, og over halvparten av dem inneholder sensitive eller personidentifiserbare data. En offentlig S3-bøtte kan bli funnet og lastet ned av automatiserte skannere i løpet av minutter. Denne guiden viser deg, steg for steg, hvordan du setter opp en Amazon S3-bøtte som faktisk er sikker fra dag én, med de nyeste standardendringene AWS rullet ut i 2026.

Vi bruker AWS CLI, IAM-policyer og Terraform for å bygge et komplett, fungerende oppsett. Du får kode du kan kopiere direkte inn i egne prosjekter, en oversikt over de vanligste feilene norske og nordiske team gjør, og en feilsøkingsseksjon for når ting ikke går som planlagt.

Hvorfor S3-sikkerhet er viktigere enn noen gang i 2026

Amazon S3 (Simple Storage Service) er ryggraden i svært mange nordiske skyarkitekturer, fra logglagring og backup til datainnsjøer for AI-trening. Nettopp fordi tjenesten er så fleksibel og billig å bruke, ender den også opp med å lagre alt fra kundedata til API-nøkler, ofte uten at noen har tenkt nøye gjennom tilgangsstyringen.

Ifølge tall sitert av SentinelOne kjører en gjennomsnittlig virksomhet over 3 000 feilkonfigurerte skyressurser til enhver tid, og de vanligste feilene er offentlig tilgjengelige lagringsbøtter, overdrevent åpne IAM-roller med wildcard-tillatelser, og deaktivert logging. Det er nettopp disse tre problemene denne guiden løser, i tillegg til kryptering og kontinuerlig overvåking.

For norske og nordiske virksomheter kommer et ekstra lag på toppen: personopplysningsloven og GDPR stiller krav til hvor data lagres og hvem som kan lese den, uavhengig av hvilken sky dere velger. En feilkonfigurert S3-bøtte med kundedata er derfor ikke bare et sikkerhetsproblem, men også en potensiell melding til Datatilsynet. Mange team velger av den grunn å legge produksjonsdata i AWS-regionen eu-north-1 (Stockholm), både for lavere nettverkslatens mot Norden og for å holde data innenfor EU/EØS. Det løser derimot ikke tilgangsstyringen for deg. Stegene under gjør det.

AWS selv har også strammet inn standardinnstillingene betydelig i 2026. I april rullet Amazon S3 ut en global endring som deaktiverer server-side-kryptering med kundeleverte nøkler (SSE-C) som standard for alle nye bøtter, nettopp fordi denne krypteringsmetoden ofte ble misforstått og feilkonfigurert. Vi går gjennom nøyaktig hva det betyr for deg lenger ned.

Dette trenger du før du starter

Du trenger ikke mye for å følge denne guiden, men noen forutsetninger må være på plass før du begynner på steg 1.

  • En aktiv AWS-konto med administratortilgang eller en IAM-bruker med rettigheter til S3, IAM, CloudTrail og KMS
  • AWS CLI versjon 2.27 eller nyere installert lokalt (kjør aws --version for å sjekke)
  • Terraform versjon 1.9 eller nyere, hvis du vil følge automatiseringsdelen mot slutten
  • Grunnleggende kjennskap til JSON, siden IAM-policyer og bucket-policyer skrives i dette formatet
  • En terminal med bash eller zsh (Linux, macOS eller WSL på Windows fungerer likt)
  • Valgfritt: Python 3.12 med boto3 installert, hvis du foretrekker å skripte oppsettet fremfor å bruke CLI direkte

De fleste av disse forutsetningene handler om å redusere friksjon underveis. En utdatert AWS CLI-versjon mangler ofte nyere API-parametre som --object-lock-enabled-for-bucket, og en IAM-bruker uten KMS-rettigheter vil feile stille når du senere prøver å sette opp kundestyrt kryptering. Sjekk derfor at kontoen din faktisk har tilgangene den trenger før du går videre.

Sett også AWS-regionen du vil jobbe i som miljøvariabel, slik at du slipper å gjenta den i hver kommando:

export AWS_DEFAULT_REGION=eu-north-1
export AWS_PROFILE=mitt-s3-prosjekt
aws sts get-caller-identity

Kommandoen get-caller-identity bekrefter hvilken AWS-konto og IAM-identitet du er logget inn som, før du gjør noe som helst annet. Dette er et lite steg som sparer deg for mye frustrasjon senere, spesielt hvis du jobber mot flere AWS-kontoer parallelt.

Steg 1-3: Opprett en S3-bøtte i riktig navnerom

Det første valget du tar, nemlig bøttens navn og navnerom, påvirker sikkerheten din for resten av bøttens levetid. Amazon S3 oppretter tradisjonelt bøtter i et globalt delt navnerom, der navnet blir stående ledig for andre AWS-kontoer å gjenbruke hvis du sletter bøtten. Fra 2026 anbefaler AWS i stedet at nye bøtter opprettes i kontoens regionale navnerom, en reservert underinndeling der kun din konto kan opprette bøtter med akkurat det navnet.

Steg 1: Velg et bøttenavn som følger navnekonvensjonene deres (kun små bokstaver, tall og bindestrek), og opprett bøtten med Block Public Access aktivert fra start:

aws s3api create-bucket \
  --bucket mittfirma-produksjonsdata-2026 \
  --region eu-north-1 \
  --create-bucket-configuration LocationConstraint=eu-north-1

aws s3api put-public-access-block \
  --bucket mittfirma-produksjonsdata-2026 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Steg 2: Bekreft at innstillingen faktisk er aktiv, siden en feiltrykk i JSON-strukturen lett kan gjøre at kommandoen feiler stille:

aws s3api get-public-access-block --bucket mittfirma-produksjonsdata-2026

Forventet output ser slik ut når alt er riktig satt opp:

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

Steg 3: Legg til tagger for kostnadssporing og revisjon med det samme, siden dette er langt enklere å gjøre nå enn å rydde opp i etterkant på tvers av hundrevis av bøtter:

aws s3api put-bucket-tagging \
  --bucket mittfirma-produksjonsdata-2026 \
  --tagging 'TagSet=[{Key=miljo,Value=produksjon},{Key=eier,Value=plattformteam},{Key=sikkerhetsklasse,Value=konfidensielt}]'

Hvis organisasjonen din administrerer mange AWS-kontoer, kan Block Public Access nå settes én gang på organisasjonsnivå gjennom AWS Organizations, slik at innstillingen automatisk arves av alle nye kontoer i organisasjonsenheten. Det fjerner behovet for å gjenta steg 1-2 manuelt for hver eneste konto.

Steg 4: Deaktiver ACL-er og ta eierskap med Object Ownership

Tilgangskontrollister (ACL-er) er en eldre mekanisme for å styre hvem som eier og kan lese objekter i en bøtte, og de fleste moderne S3-arkitekturer trenger dem ikke lenger. Fra 2023 er ACL-er faktisk deaktivert som standard for nye bøtter gjennom innstillingen “bucket owner enforced”, men det er verdt å verifisere eksplisitt, spesielt hvis bøtten er opprettet fra en eldre mal eller et Terraform-modul-bibliotek du har arvet fra et annet team.

aws s3api put-bucket-ownership-controls \
  --bucket mittfirma-produksjonsdata-2026 \
  --ownership-controls Rules=[{ObjectOwnership=BucketOwnerEnforced}]

Med denne innstillingen aktiv eier bøtteeieren automatisk alle objekter som lastes opp, uansett hvilken AWS-konto som lastet dem opp. Tilgang styres utelukkende gjennom IAM-policyer, bucket-policyer og eventuelt VPC-endepunktpolicyer, noe som gjør revisjon langt enklere fordi du kun trenger å sjekke ett sted for å forstå hvem som har tilgang til hva.

Har du en eksisterende bøtte som fortsatt bruker ACL-er, bør du gå gjennom hver enkelt tilgangsbevilgning før du slår om til BucketOwnerEnforced. List ut gjeldende ACL med aws s3api get-bucket-acl, noter hvilke kontoer som har eksplisitt tilgang, og bygg dette inn i en bucket-policy før du deaktiverer ACL-støtten. Gjør du det i feil rekkefølge, mister eksterne samarbeidspartnere tilgangen brått, uten forvarsel.

Steg 5-6: Kryptering i ro, og SSE-C-endringen fra april 2026

Alle S3-bøtter krypterer i dag data automatisk med serverside-kryptering (SSE-S3) som standardinnstilling. Det betyr at du teknisk sett er dekket uten å gjøre noe, men for de fleste produksjonsmiljøer bør du gå videre til SSE-KMS, siden det gir deg kontroll over nøkkelrotasjon, tilgangslogging på nøkkelnivå og muligheten til å tilbakekalle tilgang umiddelbart ved å deaktivere KMS-nøkkelen.

Steg 5: Sett standardkryptering til SSE-KMS med en kundestyrt nøkkel (CMK):

aws s3api put-bucket-encryption \
  --bucket mittfirma-produksjonsdata-2026 \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "alias/mittfirma-s3-nokkel"
      },
      "BucketKeyEnabled": true
    }]
  }'

BucketKeyEnabled reduserer antall kall til KMS betraktelig ved høyt volum, noe som direkte påvirker kostnadene dine på store datamengder.

Steg 6: Vær oppmerksom på endringen AWS rullet ut i april 2026: alle nye generelle S3-bøtter, samt eksisterende bøtter uten SSE-C-krypterte objekter fra før, får nå SSE-C (kryptering med kundeleverte nøkler) deaktivert som standard for nye skriveforespørsler. AWS anbefaler eksplisitt å la SSE-C forbli deaktivert med mindre arbeidslasten din faktisk krever det, fordi denne krypteringsmetoden krever at nøkkelen sendes med i hver forespørsel og gjør det upraktisk å dele tilgang med andre AWS-tjenester. Trenger du likevel SSE-C, må det aktiveres eksplisitt via PutBucketEncryption-API-kallet etter at bøtten er opprettet.

Hvis du har eldre systemer som fortsatt sender SSE-C-forespørsler og du ikke aktivt bruker dem, vil de nå feile med en HTTP 403 Access Denied-feil etter denne endringen. Det er verdt å sjekke CloudTrail-loggene dine for slike kall før du migrerer eldre arbeidslaster.

Steg 7: Tving frem kryptert trafikk med en bucket-policy

Kryptering i ro hjelper lite hvis data sendes ukryptert over nettverket til og fra bøtten. AWS anbefaler å bruke betingelsen aws:SecureTransport i en bucket-policy for å avvise all trafikk som ikke går over HTTPS/TLS.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TvingKryptertTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mittfirma-produksjonsdata-2026",
        "arn:aws:s3:::mittfirma-produksjonsdata-2026/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Lagre policyen som en fil og last den opp med:

aws s3api put-bucket-policy \
  --bucket mittfirma-produksjonsdata-2026 \
  --policy file://tving-tls-policy.json

Et lite, men viktig poeng: AWS fraråder å feste (pinne) S3-sertifikater i applikasjonskoden din, siden AWS fornyer sertifikater automatisk og en fastlåst offentlig nøkkel kan gjøre at applikasjonen din plutselig mister tilkobling etter en sertifikatfornyelse.

Steg 8: Aktiver versjonering og Object Lock

Versjonering lar deg beholde flere versjoner av samme objekt i bøtten, slik at et uheldig slett-kall eller en feil i en applikasjon ikke fører til permanent datatap. Kombinert med S3 Object Lock, som håndhever en “write once, read many”-modell (WORM), kan du forhindre at selv en kompromittert administratorkonto sletter kritiske data eller CloudTrail-logger før en gitt oppbevaringsperiode er ute.

# Object Lock må aktiveres ved opprettelse av bøtten
aws s3api create-bucket \
  --bucket mittfirma-logger-2026 \
  --region eu-north-1 \
  --create-bucket-configuration LocationConstraint=eu-north-1 \
  --object-lock-enabled-for-bucket

aws s3api put-bucket-versioning \
  --bucket mittfirma-logger-2026 \
  --versioning-configuration Status=Enabled

aws s3api put-object-lock-configuration \
  --bucket mittfirma-logger-2026 \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": { "DefaultRetention": { "Mode": "GOVERNANCE", "Days": 90 } }
  }'

Merk at Object Lock kun kan aktiveres når bøtten opprettes, ikke i etterkant på en eksisterende bøtte. Dette er en av de vanligste fallgruvene team støter på, og vi kommer tilbake til den i fallgruve-seksjonen under.

Steg 9: Minste privilegium med en IAM-policy som faktisk begrenser

Den klart vanligste feilkonfigurasjonen i IAM er å gi bred tilgang med "Action": "s3:*" og "Resource": "*", fordi det er raskest å få applikasjonen til å fungere. Problemet er at denne ene policyen ofte lever videre i produksjon i årevis. Bygg i stedet en policy som eksplisitt lister opp handlingene applikasjonen faktisk trenger, avgrenset til én bestemt bøtte:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MinstePrivilegiumApp",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mittfirma-produksjonsdata-2026",
        "arn:aws:s3:::mittfirma-produksjonsdata-2026/app/*"
      ],
      "Condition": {
        "StringEquals": { "aws:SourceVpce": "vpce-0123456789abcdef0" }
      }
    }
  ]
}

Legg merke til Condition-blokken, som begrenser tilgangen til et bestemt VPC-endepunkt. Dette er langt tryggere enn å stole på IP-baserte betingelser alene, siden en kompromittert AWS-nøkkel da fortsatt ikke kan brukes fra utsiden av nettverket deres. Bruk alltid IAM-roller, ikke langvarige tilgangsnøkler, for applikasjoner som kjører på EC2, Lambda eller ECS, siden roller gir midlertidige legitimasjoner som roteres automatisk.

Har appen din behov for tilgang på tvers av flere AWS-kontoer, for eksempel et sentralt loggingsprosjekt som samler data fra ti ulike produktteam, bør du bygge dette med en tillitspolicy (trust policy) på rollen i stedet for å dele ut langvarige nøkler til hvert team. Rollen kan da kun overtas (assumes) av spesifikke kontoer eller tjenester du eksplisitt navngir, og hvert overtak logges automatisk i CloudTrail med hvilken identitet som ba om det.

Steg 10: Logging og sporing med CloudTrail og server-tilgangslogger

Uten logging vet du ikke hvem som har gjort hva i bøtten din, og du oppdager ikke et brudd før det er for sent. AWS CloudTrail er aktivert som standard for administrasjonshendelser, men objektnivå-hendelser (som GetObject og PutObject) må aktiveres eksplisitt gjennom en dedikert “trail”:

aws cloudtrail create-trail \
  --name s3-dataevents-trail \
  --s3-bucket-name mittfirma-cloudtrail-logger-2026

aws cloudtrail put-event-selectors \
  --trail-name s3-dataevents-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::mittfirma-produksjonsdata-2026/"]
    }]
  }]'

aws cloudtrail start-logging --name s3-dataevents-trail

Aktiver også serveraksesslogging på selve bøtten, som gir deg en enkel loggfil per forespørsel og fungerer som et nyttig supplement til CloudTrail, spesielt for å forstå trafikkmønstre og feilsøke 4xx-feil:

aws s3api put-bucket-logging \
  --bucket mittfirma-produksjonsdata-2026 \
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "mittfirma-tilgangslogger-2026",
      "TargetPrefix": "s3-access-logs/"
    }
  }'

For organisasjoner med hundrevis av bøtter er S3 Storage Lens svært nyttig, siden det gir organisasjonsomfattende innsikt i lagringsbruk og automatisk fremhever bøtter som mangler versjonering, replikering eller livssyklusregler for opprydding av ufullstendige opplastinger.

Steg 11: Kontinuerlig overvåking med GuardDuty, Macie og Access Analyzer

Oppsettet så langt hindrer de fleste feilkonfigurasjoner, men du trenger også løpende overvåking for å fange opp mistenkelig aktivitet og feil som snek seg gjennom.

  • Amazon GuardDuty med S3 Protection analyserer CloudTrail-hendelser for bøttene dine med maskinlæring og trusselintelligens, og varsler deg om mistenkelige mønstre som uvanlige API-kall fra ukjente IP-adresser
  • IAM Access Analyzer for S3 varsler deg spesifikt når en bøtte er konfigurert med tilgang for eksterne kontoer, inkludert kontoer utenfor egen organisasjon, og forteller deg nøyaktig hvilken policy, ACL eller tilgangspunkt-policy som er årsaken
  • Amazon Macie skanner objektene dine for sensitive data som personopplysninger, finansdata og legitimasjon, ved hjelp av maskinlæring og mønstergjenkjenning, og genererer et funn dersom noe blir funnet på steder det ikke burde ligge
  • AWS Security Hub CSPM samler funn fra GuardDuty, Macie og Access Analyzer i ett dashbord og kjører egne kontinuerlige sikkerhetssjekker mot beste praksis

Aktiver GuardDuty med S3 Protection slik:

aws guardduty create-detector --enable
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty update-detector \
  --detector-id $DETECTOR_ID \
  --features '[{"Name":"S3_DATA_EVENTS","Status":"ENABLED"}]'

Kombinasjonen av disse fire tjenestene dekker både forebygging (Access Analyzer finner feilkonfigurasjoner før de utnyttes) og deteksjon (GuardDuty og Macie fanger opp aktivitet og data som allerede er et problem).

Et praktisk tips er å rute alle funn fra disse tjenestene til ett sted, enten Security Hub CSPM eller et eksternt SIEM-verktøy dere allerede bruker. Uten sentralisering ender team ofte opp med å sjekke fire ulike konsoller manuelt, noe som i praksis betyr at ingen sjekker noen av dem regelmessig. Sett også en enkel varslingsregel som sender kritiske funn til Slack eller Microsoft Teams, slik at plattformteamet reagerer innen timer, ikke uker.

Steg 12: Automatiser hele oppsettet med Terraform

Manuelle CLI-kommandoer er greit for læring, men i produksjon bør hele oppsettet kodifiseres slik at det er versjonskontrollert, gjenbrukbart og kan gjennomgås i en pull request før det rulles ut. Her er et komplett, fungerende Terraform-prosjekt som samler alle stegene over i én konfigurasjon:

terraform {
  required_version = ">= 1.9"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-north-1"
}

resource "aws_kms_key" "s3_nokkel" {
  description             = "KMS-nokkel for sikker S3-lagring"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

resource "aws_s3_bucket" "sikker_bucket" {
  bucket = "mittfirma-produksjonsdata-2026"
}

resource "aws_s3_bucket_public_access_block" "blokker_offentlig" {
  bucket                  = aws_s3_bucket.sikker_bucket.id
  block_public_acls       = true
  ignore_public_acls      = true
  block_public_policy     = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_ownership_controls" "eierskap" {
  bucket = aws_s3_bucket.sikker_bucket.id
  rule {
    object_ownership = "BucketOwnerEnforced"
  }
}

resource "aws_s3_bucket_versioning" "versjonering" {
  bucket = aws_s3_bucket.sikker_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "kryptering" {
  bucket = aws_s3_bucket.sikker_bucket.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3_nokkel.arn
    }
    bucket_key_enabled = true
  }
}

resource "aws_s3_bucket_policy" "tving_tls" {
  bucket = aws_s3_bucket.sikker_bucket.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "TvingKryptertTransport"
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource = [
        aws_s3_bucket.sikker_bucket.arn,
        "${aws_s3_bucket.sikker_bucket.arn}/*"
      ]
      Condition = {
        Bool = { "aws:SecureTransport" = "false" }
      }
    }]
  })
}

Kjør oppsettet med:

terraform init
terraform plan -out=s3-sikkerhet.plan
terraform apply s3-sikkerhet.plan

Denne konfigurasjonen kan legges rett inn i et eget Git-repository og kobles til en CI/CD-pipeline, slik at hver endring i S3-sikkerheten går gjennom kodegjennomgang før den treffer produksjon. Det er nøyaktig denne tilnærmingen AWS peker på når de anbefaler å kodifisere sikkerhet direkte i IaC-maler som Terraform og CloudFormation, og evaluere policyer før utrulling fremfor etterpå.

Multi-konto-strategi: skaler S3-sikkerhet med AWS Organizations

De tolv stegene over dekker én bøtte i én konto. De fleste nordiske virksomheter av en viss størrelse kjører derimot titalls eller hundretalls AWS-kontoer, én per team eller produkt, organisert under AWS Organizations. Å gjenta stegene manuelt for hver konto skalerer ikke, og det er nettopp her mange sikkerhetshull oppstår: en ny konto opprettes raskt for et prosjekt, og noen glemmer å sette opp Block Public Access eller kryptering før første bøtte allerede er i bruk.

Løsningen er å håndheve reglene på organisasjonsnivå i stedet for kontonivå. AWS Organizations støtter to typer policyer som er relevante her: service control policies (SCP-er), som setter et tak på hva noen i det hele tatt kan gjøre uansett hvilken IAM-tillatelse de har lokalt, og resource control policies (RCP-er), som håndhever restriksjoner direkte på ressursnivå på tvers av kontoer. Sammen med organisasjonsnivå-håndhevelse av S3 Block Public Access kan dere sette opp følgende én gang:

  • En SCP som nekter s3:PutBucketPublicAccessBlock med verdien false, slik at ingen konto kan deaktivere beskyttelsen igjen
  • En RCP som krever kryptert transport for alle S3-kall i hele organisasjonen, uavhengig av hva den enkelte bucket-policyen sier
  • En obligatorisk tagging-policy som krever eier- og miljøtagger på alle nye bøtter, slik at Storage Lens og kostnadsrapportering fungerer fra dag én

Nye medlemskontoer arver disse innstillingene automatisk når policyen er festet på rot- eller organisasjonsenhet-nivå, uten at noen i det enkelte team trenger å konfigurere noe manuelt. Det reduserer også revisjonsjobben betraktelig, siden dere kun trenger å bekrefte at organisasjonspolicyen er korrekt ett sted, fremfor å sjekke alle kontoene hver for seg.

S3-lagringsklasser: hvordan valget påvirker sikkerhet og kostnad

Sikkerhetsoppsettet du nettopp bygde gjelder uansett hvilken lagringsklasse objektene dine ligger i, men valget av klasse påvirker likevel hvor raskt du kan hente ut data ved en hendelse, og hvor lenge logger og backup faktisk bør leve. S3 Standard passer for data som leses ofte, mens Glacier-klassene er billigere men krever timer å hente ut igjen, noe som er verdt å vite før du legger CloudTrail-logger eller Object Lock-beskyttede sikkerhetskopier i feil klasse.

LagringsklasseTypisk brukMinimum lagringstidHentetid ved behov
S3 StandardAktive applikasjonsdata, hyppig lestIngenUmiddelbar
S3 Intelligent-TieringData med uforutsigbart tilgangsmønsterIngenUmiddelbar
S3 Standard-IASjeldnere lest, men krever rask tilgang30 dagerUmiddelbar
S3 Glacier Instant RetrievalArkiv som likevel må hentes raskt90 dagerMillisekunder
S3 Glacier Flexible RetrievalCompliance-arkiv, sjelden aksess90 dagerMinutter til timer
S3 Glacier Deep ArchiveLangtidsarkiv, lovpålagt oppbevaring180 dagerTimer

En vanlig arkitektur er å bruke en livssyklusregel som automatisk flytter objekter fra S3 Standard til Glacier-klasser etter et gitt antall dager, kombinert med Object Lock for å hindre sletting før oppbevaringstiden er ute. For CloudTrail-logger og andre revisjonsdata er dette ofte det beste kompromisset mellom kostnad og krav til at bevis skal være tilgjengelig når Datatilsynet eller en revisor ber om innsyn.

5 vanlige fallgruver ved S3-sikkerhet

De fleste av disse fallgruvene har én ting til felles: de virker ufarlige der og da, gjerne fordi de løser et akutt problem under en deploy sent på en fredag, men blir stående som permanente hull fordi ingen setter av tid til å rydde opp etterpå. Kjenn igjen disse fem mønstrene før de rekker å bli et innslag i neste sikkerhetsrevisjon.

  1. Å tro at Object Lock kan skrus på senere. Object Lock må aktiveres når bøtten opprettes. Oppdager du behovet etter at bøtten allerede er i bruk, må du opprette en ny bøtte og migrere dataene, noe som kan ta betydelig tid for store datamengder.
  2. Wildcard-tillatelser “for å få det til å virke”. "Action": "s3:*" kombinert med "Resource": "*" er den nummer én årsaken til at kompromitterte legitimasjoner får tilgang til langt mer enn nødvendig. Det som skulle vært en midlertidig løsning under utvikling, blir ofte stående i produksjon i årevis.
  3. Å stole på ACL-er i stedet for policyer. Team som fortsatt administrerer tilgang via ACL-er mister oversikten raskt, siden ACL-er er vanskeligere å revidere enn en samlet bucket-policy. Deaktiver ACL-er med Object Ownership med mindre du har et konkret behov for objektnivå-eierskap på tvers av kontoer.
  4. Å glemme kryptert transport. Kryptering i ro beskytter ikke data som sendes over HTTP i stedet for HTTPS. Uten en eksplisitt aws:SecureTransport-betingelse i policyen din er denne døren åpen, selv om SSE-KMS er korrekt konfigurert.
  5. Ingen logging fordi “vi ser det jo i konsollen”. Uten CloudTrail-datahendelser og S3-tilgangslogger har du ingen forensisk sti å følge etter et mistenkt brudd. Aktiver logging før du trenger den, ikke etter.

Feilsøking: 8 vanlige feil og løsninger

Selv med et gjennomtenkt oppsett vil du før eller siden treffe en feilmelding du ikke umiddelbart forstår. De fleste feil ved S3-sikkerhet kommer av at flere lag med beskyttelse (Block Public Access, IAM, bucket-policy og eventuelt en SCP) overlapper, og det er ikke alltid opplagt hvilket lag som faktisk stoppet forespørselen. Tabellen under dekker de vanligste symptomene team støter på etter at de har fulgt stegene i denne guiden.

Feilmelding eller symptomSannsynlig årsakLøsning
AccessDenied ved PutObject med SSE-CBøtten har fått SSE-C deaktivert av 2026-standardendringenAktiver SSE-C eksplisitt via PutBucketEncryption, eller bytt til SSE-KMS
BucketAlreadyExists ved create-bucketBøttenavn er allerede tatt i det globale navnerommetBruk kontoens regionale navnerom eller velg et mer unikt navn med firmaprefiks
AccessControlListNotSupported ved PUT med ACLObject Ownership er satt til BucketOwnerEnforced, som blokkerer ACL-erFjern ACL-parameteren fra opplastingskallet og bruk bucket-policy i stedet
403 Forbidden selv med korrekt IAM-policyPublic Access Block eller Service Control Policy overstyrer IAM-tillatelsenSjekk get-public-access-block og eventuelle SCP-er på organisasjonsnivå
Object Lock-konfigurasjon feilerBøtten ble ikke opprettet med –object-lock-enabled-for-bucketOpprett en ny bøtte med flagget satt fra start, og migrer data
CloudTrail viser ingen objektnivå-hendelserData events er ikke aktivert i event-selectorsKjør put-event-selectors med DataResources for S3::Object
Applikasjonen mister tilkobling etter sertifikatfornyelseApplikasjonen pinner S3s TLS-sertifikatFjern sertifikatpinning og stol på AWS sin sertifikatkjede
GuardDuty genererer ingen S3-funnS3_DATA_EVENTS-funksjonen er ikke aktivert på detektorenKjør update-detector med S3_DATA_EVENTS satt til ENABLED

Avanserte tips for produksjonsmiljøer

Når grunnoppsettet er på plass, er det noen flere lag du bør vurdere for kritiske arbeidslaster. VPC-endepunkter for S3 lar deg holde all trafikk mellom applikasjonen din og bøtten inne i AWS-nettverket, uten å gå via det åpne internett, og du kan bruke bucket-policyer til å kreve at all trafikk kommer nøyaktig fra dette endepunktet. Det gjør datauthenting fra en kompromittert instans betydelig vanskeligere.

S3 Cross-Region Replication (CRR) bør vurderes hvis compliance-krav tilsier at data må lagres i geografisk atskilte regioner utover det S3 allerede gjør på tvers av tilgjengelighetssoner. CRR krever at versjonering er aktivert på både kilde- og målbøtte, noe som er en av grunnene til at vi aktiverte versjonering allerede i steg 8.

Vurder også S3 Access Points hvis mange ulike applikasjoner eller team deler samme bøtte. Hvert tilgangspunkt får sin egen policy og sitt eget DNS-navn, slik at du kan gi granulær tilgang uten å måtte vedlikeholde én stadig voksende bucket-policy som blir vanskelig å revidere. For arbeidslaster med spesielt strenge revisjonskrav, bruk S3 Inventory til å generere periodiske rapporter over krypterings- og replikeringsstatus for hvert objekt, i stedet for å stole på stikkprøver.

Til slutt: sett opp CloudWatch-alarmer på nøkkelmetrikker som 4xxErrors og på CloudTrail-hendelser som endrer bucket-policy, ACL-er eller replikeringskonfigurasjon. En alarm som varsler når noen kjører PutBucketPolicy eller PutBucketAcl mot en produksjonsbøtte gir deg et tidlig varsel lenge før Macie eller GuardDuty ville plukket opp konsekvensene.

Planlegg også for regelmessig testing av selve tilgangsstyringen, ikke bare oppsettet. Sett opp en kvartalsvis rutine der en person utenfor plattformteamet forsøker å liste, laste ned eller endre en produksjonsbøtte med en vanlig utviklerrolle. Klarer personen det, er policyen for vid. Dette er en enkel, billig kontroll som fanger opp konfigurasjonsdrift, altså at et oppsett som var korrekt for seks måneder siden har blitt utvidet med unntak og hurtigløsninger underveis, uten at noen har ryddet opp etterpå.

AWS S3 vs Google Cloud Storage vs Azure Blob Storage: sikkerhetsfunksjoner

Mange nordiske team jobber i flere skyer samtidig. Tabellen under sammenligner de sentrale sikkerhetsmekanismene på tvers av de tre store objektlagringstjenestene, basert på offentlig dokumentasjon fra hver leverandør.

FunksjonAWS S3Google Cloud StorageAzure Blob Storage
Standardkryptering i roJa, SSE-S3 som standardJa, Google-administrerte nøklerJa, Microsoft-administrerte nøkler
Kundestyrte krypteringsnøklerSSE-KMS via AWS KMSCMEK via Cloud KMSCustomer-managed keys via Azure Key Vault
Blokkering av offentlig tilgangS3 Block Public Access, kontonivå og organisasjonsnivåOffentlig tilgang forhindret via IAM og org-policyerTillat offentlig tilgang kan deaktiveres per konto
Uforanderlig lagring (WORM)S3 Object LockBucket LockImmutable blob storage-policyer
Automatisert trusseldeteksjonGuardDuty S3 ProtectionSecurity Command CenterMicrosoft Defender for Storage
Sensitiv datagjenkjenningAmazon MacieSensitive Data Protection (DLP API)Microsoft Purview

Alle tre leverandørene tilbyr i praksis likeverdig grunnfunksjonalitet i 2026. Forskjellen ligger mest i navnene på tjenestene og hvor godt de integreres med resten av økosystemet dere allerede bruker. Har dere allerede tunge investeringer i Microsoft 365 og Entra ID, er Defender for Storage ofte et naturlig valg. Kjører dere allerede mye i AWS, gir kombinasjonen av GuardDuty, Macie og Access Analyzer en sammenhengende opplevelse uten å måtte administrere en tredjeparts sikkerhetsplattform på toppen.

For team som drifter i flere skyer samtidig, gir denne tabellen også et hint om hvor mye ekstra læringskurve dere tar på dere. Konseptene er stort sett de samme (kryptering, tilgangskontroll, uforanderlig lagring, overvåking), men API-ene, konsollene og terminologien er ulike nok til at et team som kun kjenner AWS vil bruke tid på å finne de tilsvarende knappene i Google Cloud Console eller Azure Portal. Vurder derfor om det er verdt å sentralisere sikkerhetsstyringen i et multiskyverktøy, i stedet for å administrere tre separate sikkerhetsmodeller parallelt.

Slik ser en fullført sikkerhetssjekk ut

Etter å ha fulgt alle 12 stegene, bør en fullstendig statussjekk av bøtten din gi et resultat som ligner dette:

$ aws s3api get-bucket-policy-status --bucket mittfirma-produksjonsdata-2026
{
    "PolicyStatus": {
        "IsPublic": false
    }
}

$ aws s3api get-bucket-versioning --bucket mittfirma-produksjonsdata-2026
{
    "Status": "Enabled"
}

$ aws s3api get-bucket-encryption --bucket mittfirma-produksjonsdata-2026
{
    "ServerSideEncryptionConfiguration": {
        "Rules": [{
            "ApplyServerSideEncryptionByDefault": {
                "SSEAlgorithm": "aws:kms",
                "KMSMasterKeyID": "arn:aws:kms:eu-north-1:123456789012:key/..."
            },
            "BucketKeyEnabled": true
        }]
    }
}

Ser output slik ut hos deg, har du på plass blokkert offentlig tilgang, versjonering og kryptering med kundestyrt nøkkel, altså de tre grunnpilarene i et sikkert S3-oppsett.

Ofte stilte spørsmål

Er S3-bøtter kryptert som standard?
Ja. Alle nye objekter som lastes opp til S3 krypteres automatisk med SSE-S3 som standardinnstilling. For produksjonsdata bør du likevel vurdere å oppgradere til SSE-KMS for bedre kontroll over nøkler og tilgangslogging.

Hva er forskjellen på Block Public Access og en bucket-policy?
Block Public Access er en overordnet bryter som forhindrer offentlig tilgang uansett hva bucket-policyen eller ACL-ene sier. En bucket-policy styrer derimot detaljert hvem som får gjøre hva, forutsatt at Block Public Access ikke stopper det først.

Kan jeg aktivere Object Lock på en eksisterende bøtte?
Nei. Object Lock må aktiveres når bøtten opprettes, ikke i etterkant. Trenger du dette på en eksisterende bøtte, må du opprette en ny bøtte med funksjonen aktivert og migrere dataene over.

Hva betyr SSE-C-endringen fra april 2026 i praksis for meg?
Nye generelle S3-bøtter, og eksisterende bøtter uten SSE-C-krypterte objekter, får nå SSE-C deaktivert som standard for skriveforespørsler. Trenger du fortsatt SSE-C, må det aktiveres eksplisitt via PutBucketEncryption. De fleste arbeidslaster bør uansett bruke SSE-S3 eller SSE-KMS i stedet.

Er GuardDuty og Macie inkludert gratis i AWS-kontoen?
Nei, begge tjenestene har egen prisstruktur basert på volumet av data og hendelser som analyseres. Begge tilbyr imidlertid en gratis prøveperiode slik at du kan estimere kostnaden mot ditt eget datavolum før du forplikter deg.

Hvordan finner jeg ut om en eksisterende bøtte er offentlig tilgjengelig?
Kjør aws s3api get-bucket-policy-status og aws s3api get-public-access-block mot bøtten. AWS Trusted Advisor og IAM Access Analyzer for S3 kan i tillegg skanne samtlige bøtter i kontoen din automatisk og varsle om alle som er delt eksternt.

Bør jeg bruke Terraform eller AWS CLI for S3-sikkerhet i produksjon?
Terraform (eller CloudFormation) er å foretrekke i produksjon, siden konfigurasjonen da er versjonskontrollert, kan gjennomgås i en pull request og gjenskapes identisk i flere miljøer. CLI er godt egnet til læring, feilsøking og engangsoperasjoner.

Hvor mange S3-bøtter kan jeg opprette per AWS-konto?
Alle AWS-kontoer har i dag en standard kvote på 10 000 bøtter, en betydelig økning fra det tidligere lavere taket. Det reduserer behovet for å slette tomme bøtter kun for å frigjøre plass til nye, men du kan fortsatt be AWS om en høyere kvote dersom virksomheten din har et reelt behov for flere.

Må jeg bruke samme sikkerhetsoppsett for testmiljøer som for produksjon?
Grunnprinsippene, altså Block Public Access, deaktiverte ACL-er og kryptert transport, bør gjelde i alle miljøer, siden testdata ofte inneholder anonymiserte kopier av ekte kundedata. Du kan derimot være mer avslappet på KMS-nøkkelrotasjon og Object Lock-oppbevaringstid i test, så lenge miljøet er tydelig adskilt fra produksjonskontoen.