AWS S3 – Client- en serverside-encryptie

AWS S3-encryptie aan de client- en serverzijde biedt vijf verschillende manieren om gegevens in Amazon Simple Storage Service te beschermen, elk met een andere balans tussen sleutelbeheer, operationele complexiteit, auditdiepte en kosten. De juiste keuze hangt af van wie u wilt buitensluiten: alleen externe aanvallers of AWS zelf. Deze handleiding behandelt elke S3-encryptieoptie, wanneer u welke moet gebruiken, hoe u ze kunt afdwingen met bucketbeleid, wat er in CloudTrail wordt weergegeven en hoe u kunt kiezen tussen native sleutelbeheer, BYOK (Bring Your Own Key) en HYOK (Hypothetic Your Own Key).

Kort antwoord: Welke AWS S3-versleutelingsoptie moet je gebruiken?

Voor de meeste workloads: gebruik SSE-KMS met een door de klant beheerde KMS-sleutel. U krijgt AES-256-encryptie in rust, een volledig CloudTrail-auditspoor van elke encryptie- en decryptiegebeurtenis gekoppeld aan een IAM-identiteit, de mogelijkheid om de sleutel onafhankelijk uit te schakelen en automatische jaarlijkse sleutelrotatie. Voor de hoogste sleutelsoevereiniteit (waarbij AWS uw sleutel nooit mag bewaren): gebruik client-side encryptie met uw eigen hoofdsleutel. Voor de eenvoudigste configuratie zonder overhead voor sleutelbeheer en zonder auditspoorvereiste: SSE-S3 (wat sinds januari 2023 de standaard S3-methode is). Voor het leveren van uw eigen sleutel per aanvraag zonder KMS te gebruiken: SSE-C.

Key Takeaways

• S3 versleutelt standaard sinds januari 2023: Alle nieuwe objecten in een S3-bucket worden automatisch versleuteld met SSE-S3 (AES-256), zelfs zonder expliciete configuratie. Bestaande objecten worden niet met terugwerkende kracht versleuteld.
• Er bestaan ​​vijf versleutelingsopties, verdeeld over twee categorieën: Server-side (SSE-S3, SSE-KMS, SSE-C) betekent dat S3 de versleuteling uitvoert nadat de gegevens zijn ontvangen. Client-side betekent dat u de gegevens versleutelt vóór het uploaden, waardoor S3 de onversleutelde tekst nooit te zien krijgt.
• SSE-KMS is de aanbevolen standaard voor gereguleerde workloads: Het biedt een auditlogboek per bewerking in CloudTrail, ondersteunt door de klant beheerde sleutels met BYOK en stelt u in staat een sleutel uit te schakelen of te verwijderen om onmiddellijk decryptie te voorkomen zonder objecten te verwijderen.
• BYOK en HYOK dienen verschillende soevereiniteitsvereisten: BYOK (importing your own key material into AWS KMS) houdt de sleutel tijdens gebruik in AWS, maar biedt u wel de mogelijkheid tot herkomstverificatie. HYOK (client-side encryption with your own master key) betekent dat AWS de sleutel op geen enkel moment aanraakt.
• Versleuteling tijdens overdracht vereist een apart bucketbeleid: De standaardversleuteling van S3 dekt alleen data in rust. Schakel `aws:SecureTransport=false` uit in uw bucketbeleid om TLS af te dwingen voor alle verzoeken.

Wat is AWS S3-encryptie en waarom is het belangrijk?

Amazon S3 (Simple Storage Service) is de objectopslagservice van AWS. Het slaat gegevens op als objecten in containers die buckets worden genoemd. Elk object kan maximaal 5 TB groot zijn. S3 wordt veel gebruikt voor back-ups, data lakes, applicatie-assets, logarchieven en gereguleerde datasets, waaronder workloads in de gezondheidszorg (HIPAA), de financiële sector (PCI DSS) en de overheid (FedRAMP).

Versleuteling in S3 pakt twee verschillende dreigingsmodellen aan. Versleuteling in rust beschermt objecten die op schijf zijn opgeslagen tegen onbevoegd lezen als de onderliggende opslagmedia zonder toestemming worden benaderd. Versleuteling tijdens transport beschermt objecten tijdens het transport tussen clients en de S3-service. Beide vormen van versleuteling zijn vereist voor de meeste compliance-frameworks en vereisen afzonderlijke configuraties in S3.

S3 gebruikt AES-256 met Galois Counter Mode (AES-256-GCM) voor alle symmetrische versleutelingsbewerkingen. GCM biedt geauthenticeerde versleuteling: het voegt een unieke authenticatietag toe aan elk versleuteld object, waarmee wordt geverifieerd dat de gegevens niet zijn gemanipuleerd en dat de juiste sleutel is gebruikt voor decryptie. Dit beschermt zowel tegen passief afluisteren als tegen actieve wijziging van de opgeslagen versleutelde tekst.

Versleuteling tijdens transport: TLS afdwingen voor alle S3-verzoeken

S3 ondersteunt HTTPS (TLS) voor alle API-verzoeken. TLS versleutelt de verbinding tussen de client en het S3-eindpunt, waardoor objectgegevens en verzoekmetadata tijdens de overdracht worden beschermd. S3 dwingt HTTPS echter niet standaard af; een S3-bucket zonder beleid accepteert zowel HTTP- als HTTPS-verzoeken.

Om TLS af te dwingen voor alle verzoeken aan een bucket, moet u een bucketbeleid toepassen dat elk verzoek weigert waarbij de aws:SecureTransport De voorwaardesleutel is onwaar. Het onderstaande beleid weigert alle GetObject-verzoeken die geen HTTPS gebruiken:

{
  "Id": "EnforceSSLOnly",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSSLRequests",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Pas dit beleid toe op elke S3-bucket die gevoelige gegevens bevat. Houd er rekening mee dat de Resource Het blok moet zowel de bucket ARN als de object ARN omvatten (met /*) om zowel API-aanroepen op bucketniveau als op objectniveau via HTTP te weigeren.

Server-side encryptie (SSE): drie opties uitgelegd

Server-side encryptie betekent dat S3 uw gegevens via HTTPS ontvangt en deze vervolgens versleutelt voordat ze naar de schijf worden geschreven. S3 slaat de versleutelde tekst op. Wanneer u het object opvraagt, ontsleutelt S3 het (met behulp van de juiste sleutel) voordat het via HTTPS naar u wordt teruggestuurd. De versleuteling en ontsleuteling vinden plaats binnen de serviceomgeving van S3. Uw applicatie hoeft geen cryptografische bewerkingen uit te voeren.

SSE-S3: Door S3 beheerde sleutels (de standaard sinds januari 2023)

SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys) is de standaardversleutelingsmethode voor alle nieuwe S3-objecten vanaf januari 2023. AWS genereert een unieke AES-256-GCM-gegevensversleutelingssleutel voor elk object. Deze gegevenssleutel wordt vervolgens versleuteld met een regelmatig vernieuwde hoofdsleutel die volledig door AWS wordt beheerd. U hebt geen inzicht in of controle over beide sleutels.

SSE-S3 is geschikt voor workloads waarbij encryptie in rust vereist is, maar er geen behoefte is aan een auditlogboek van sleutelgebruik of onafhankelijk sleutelbeheer. Het voegt geen operationele overhead en geen kosten toe bovenop de standaard S3-opslag. De keerzijde: u kunt de toegang tot de encryptiesleutel niet uitschakelen, roteren of controleren. Er is geen CloudTrail-registratie van individuele objectontsleutelingen. U kunt de mogelijkheid om een ​​object te ontsleutelen niet intrekken zonder het object zelf te verwijderen.

SSE-KMS: KMS-beheerde sleutels met auditlogboek en klantcontrole

SSE-KMS gebruikt AWS Key Management Service (KMS) om de encryptiesleutels te beheren die uw S3-objecten beschermen. Wanneer u een object uploadt met SSE-KMS, roept S3 KMS aan om een ​​gegevensencryptiesleutel (DEK) te genereren. KMS retourneert twee versies: een DEK in platte tekst (gebruikt om het object te versleutelen) en een versleutelde DEK (opgeslagen naast het versleutelde object in S3). S3 verwijdert de DEK in platte tekst direct na het versleutelen van het object. Wanneer u het object downloadt, stuurt S3 de versleutelde DEK naar KMS, die deze ontsleutelt en de DEK in platte tekst retourneert, zodat S3 het object kan ontsleutelen en aan u kan teruggeven.

Elke GenerateDataKey- en Decrypt-aanroep naar KMS genereert een CloudTrail-logboekvermelding met de ARN van de KMS-sleutel, de aanvragende IAM-principal, de S3-bucket- en objectsleutel en een tijdstempel. Dit biedt u een volledig, aan de identiteit gekoppeld auditspoor van elke versleutelings- en ontsleutelingsgebeurtenis op elk S3-object dat door SSE-KMS wordt beschermd.

SSE-KMS ondersteunt twee sleuteltypen, die aanzienlijk verschillende beveiligings- en controle-eigenschappen hebben:

AWS-beheerde KMS-sleutel (aws/s3): AWS maakt deze sleutel automatisch aan wanneer u SSE-KMS voor het eerst inschakelt voor een bucket zonder een CMK op te geven. AWS beheert de sleutel volledig, inclusief de rotatie (elke drie jaar voor aws/s3-sleutels). U kunt de sleutel in KMS bekijken, maar u kunt het beleid ervan niet wijzigen, de sleutel niet uitschakelen of verwijderen. U krijgt CloudTrail-logboekregistratie, maar geen onafhankelijke controle over de sleutel.

Door de klant beheerde KMS-sleutel (CMK): Deze sleutel maakt u aan in KMS voordat u SSE-KMS inschakelt. U definieert het sleutelbeleid, bepaalt wie de sleutel mag gebruiken voor S3-versleuteling en -ontsleuteling, schakelt automatische jaarlijkse rotatie in en kunt de sleutel op elk moment uitschakelen of verwijderen. Het uitschakelen van de CMK voorkomt onmiddellijk dat S3 objecten ontsleutelt die met die sleutel zijn versleuteld, zonder dat die objecten worden verwijderd. Dit is de aanbevolen optie voor gereguleerde workloads.

SSE-C: Door de klant verstrekte versleutelingssleutels

SSE-C (Server-Side Encryption with Customer-Provided Keys) vereist dat u een 256-bits AES-versleutelingssleutel in de HTTP-aanvraagheader opneemt voor elke PutObject (upload) en GetObject (download). S3 gebruikt de door u verstrekte sleutel om de AES-256-versleuteling of -ontsleuteling uit te voeren en verwijdert de sleutel vervolgens direct uit het geheugen. S3 slaat alleen een willekeurig gezouten HMAC-vingerafdruk (Hash-Based Message Authentication Code) van de sleutel op om toekomstige aanvragen te valideren.

Het gevolg: als u de sleutel kwijtraakt, verliest u permanent de toegang tot alle objecten die ermee zijn versleuteld. Er is geen mechanisme voor sleutelherstel. SSE-C moet HTTPS gebruiken; S3 weigert SSE-C-verzoeken die via HTTP worden gedaan.

SSE-C is geschikt wanneer u S3 nodig hebt voor versleutelingsbewerkingen, maar u uw sleutel niet in AWS KMS kunt of wilt plaatsen. U aanvaardt de volledige verantwoordelijkheid voor het beheer, de rotatie, de opslag en de distributie van de sleutel naar elk systeem dat toegang tot de objecten nodig heeft. SSE-C genereert geen KMS CloudTrail-gebeurtenissen omdat het geen gebruikmaakt van KMS.

Client-side encryptie: Versleutelen vóór uploaden

Client-side encryptie betekent dat uw applicatie of client de gegevens versleutelt voordat ze uw omgeving verlaten. Wat S3 ontvangt en opslaat, is al versleuteld; S3 heeft nooit toegang tot de onversleutelde gegevens. Dit is het enige S3-encryptiemodel waarbij AWS onder geen enkele operationele omstandigheid toegang kan krijgen tot uw gegevens, zelfs niet in geval van juridische dwang jegens AWS.

De AWS SDK voor Java (en andere talen) biedt een S3-encryptieclient die client-side encryptie implementeert. Er zijn twee opties voor sleutelbeheer:

Clientzijde met AWS KMS CMK: Uw applicatie roept KMS aan om een ​​onversleutelde gegevenssleutel en een versleutelde gegevenssleutel te genereren. Uw applicatie versleutelt het object met de onversleutelde gegevenssleutel, verwijdert de onversleutelde sleutel en uploadt de versleutelde gegevens samen met de versleutelde gegevenssleutel als objectmetadata. Om te downloaden en te ontsleutelen, haalt uw applicatie de versleutelde gegevenssleutel op uit de objectmetadata, roept KMS aan om deze te ontsleutelen, gebruikt de geretourneerde onversleutelde gegevenssleutel om het object te ontsleutelen en verwijdert de onversleutelde sleutel. AWS KMS is betrokken bij het versleutelen van de sleutel, waardoor er een CloudTrail-registratie van de sleutelbewerkingen is, maar AWS heeft nooit toegang tot de onversleutelde objectgegevens.

Clientzijde met een zelfbeheerde hoofdsleutel: Uw applicatie gebruikt zijn eigen hoofdsleutel (opgeslagen in uw HSM, sleutelbeheersysteem of applicatiesleutelkluis) om de dataversleutelingssleutel te versleutelen en te ontsleutelen. AWS is niet betrokken bij sleutelbewerkingen. Dit is het HYOK-model (Hold Your Own Key): de versleutelingssleutel bevindt zich volledig buiten AWS. Zelfs als AWS gedwongen zou worden om toegang te verlenen tot uw S3-bucket, is de opgeslagen versleutelde tekst nutteloos zonder de hoofdsleutel die nooit bij AWS is geweest.

Native Key Control vs. BYOK vs. HYOK: Welk model past het beste bij uw behoeften?

De belangrijkste encryptiebeslissing voor elke S3-workload is niet welke AES-modus te gebruiken, maar wie de sleutels beheert. De drie beschikbare sleutelbeheermodellen voor S3 hebben zeer verschillende beveiligingseigenschappen, operationele vereisten en implicaties voor compliance.

Afmeting	Native (SSE-S3 of door AWS beheerde KMS-sleutel)	BYOK (door de klant beheerde KMS-sleutel met geïmporteerd sleutelmateriaal)	HYOK (Client-side encryption with self-managed master key)
Wie genereert de encryptiesleutel?	AWS	Klant (geïmporteerd in KMS)	Klant (komt nooit in AWS terecht)
AWS-toegang tot de sleutel in platte tekst	Ja	Ja, tijdens actieve KMS-operaties.	Nee
CloudTrail-auditlogboek per object	SSE-S3: Nee. AWS-beheerde KMS: Ja	Ja (GenerateDataKey + Decrypt-gebeurtenissen)	KMS-variant: Ja (sleutelomslag/ontsleuteling). Zelfbeheerd: Nee
Onafhankelijke sleutel uitschakelen/intrekken	SSE-S3: Nee. AWS-beheerde KMS: Nee.	Ja (CMK onmiddellijk uitschakelen of verwijderen)	Ja (intrekken via uw sleutelbeheersysteem)
Automatische sleutelrotatie	SSE-S3: Ja (door AWS beheerd). AWS-beheerde KMS: Elke 3 jaar	Ja (jaarlijks voor CMK) of handmatig voor geïmporteerd materiaal	Volledig door de klant beheerd.
Operationele complexiteit	Laag	Medium	Hoge
KMS API-kosten per S3-bewerking	SSE-S3: Geen. AWS-beheerde KMS: $0.03/10 aanroepen	$0.03/10k calls	KMS-variant: $0.03/10 gesprekken. Zelfbeheer: Geen
Best voor	Algemene werkbelasting; prioriteit voor eenvoud	Gereguleerde sectoren; HIPAA, PCI DSS, FedRAMP	Zero-trust opslag; luchtgeïsoleerd; geclassificeerde gegevens

IAM-model: Toegang met minimale privileges voor S3-encryptie

Versleuteling alleen voorkomt geen ongeautoriseerde toegang. Een juiste IAM-configuratie bepaalt wie S3-objecten kan lezen (en dus decoderen). Een goed ontworpen IAM-model voor SSE-KMS S3-workloads scheidt het beheer van versleutelingssleutels van de gegevenstoegang met behulp van drie controlelagen.

S3-bucketbeleid: Hiermee wordt bepaald welke IAM-principals S3 API-aanroepen (GetObject, PutObject, ListBucket, DeleteObject) mogen uitvoeren op de bucket en de objecten daarin. Voor SSE-KMS-handhaving voegt u een 'Weigeren'-voorwaarde toe die vereist dat... s3:x-amz-server-side-encryption koptekst te zijn aws:kms Bij alle PutObject-verzoeken wordt ervoor gezorgd dat er geen niet-versleutelde objecten kunnen worden geüpload.

KMS-kernbeleid: Hiermee wordt bepaald welke IAM-principals de CMK kunnen gebruiken. kms:GenerateDataKey (nodig om objecten te versleutelen) en kms:Decrypt (nodig om objecten te decoderen). De S3-service roept KMS aan namens de aanvragende IAM-principal; de principal moet zowel S3- als KMS-machtigingen hebben om de bewerking te laten slagen. Scheid de rol van sleutelbeheerder (die sleutelbeleid kan beheren, roteren en uitschakelen) van de rol van sleutelgebruiker (die via S3 kan versleutelen/ontsleutelen).

IAM-identiteitsbeleid: Het IAM-beleid van de aanroepende principal moet zowel de S3-actie als de KMS-actie toestaan. Voor een alleen-lezen rol die toegang moet hebben tot S3-objecten, maar nooit nieuwe objecten mag uploaden, moet de juiste machtiging worden verleend. s3:GetObject en kms:Decrypt Alleen voor een schrijfrol, voeg dit toe. s3:PutObject en kms:GenerateDataKeyNooit toestaan kms:CreateKey, kms:DeleteKeyof kms:DisableKey naar toepassingsrollen.

Service Control Policies (SCP's): Als uw AWS-accounts zich in een AWS-organisatie bevinden, bieden SCP's een extra beveiligingslaag bovenop IAM-beleid. Gebruik een SCP om elke S3 PutObject te weigeren die geen versleutelingsheader bevat. Zo voorkomt u dat gebruikers binnen de organisatie per ongeluk onversleutelde S3-objecten opslaan, ongeacht de individuele IAM-configuraties van de accounts.

Sleutelrotatie voor S3-encryptie

Sleutelrotatie voor S3 SSE-KMS werkt via KMS-sleutelrotatie, niet door elk S3-object opnieuw te versleutelen. Wanneer automatische jaarlijkse rotatie is ingeschakeld voor een door de klant beheerde CMK, genereert KMS nieuw cryptografisch materiaal en markeert dit als de actieve versie. Alle nieuwe S3 PutObject-bewerkingen gebruiken het nieuwe sleutelmateriaal. Bestaande objecten blijven versleuteld met de sleutelmateriaalversie die actief was toen ze werden geüpload; KMS bewaart alle eerdere versies en gebruikt de juiste versie bij het ontsleutelen van die oudere objecten.

Dit betekent dat u uw S3-objecten nooit opnieuw hoeft te uploaden of te versleutelen om sleutelrotatie te implementeren. De CMK ARN en sleutel-ID blijven hetzelfde; de ​​rotatie is transparant voor S3 en uw applicaties. De rotatiegebeurtenis wordt vastgelegd in CloudTrail onder de RotateKey soort evenement.

Voor BYOK-sleutels met geïmporteerd sleutelmateriaal is automatische rotatie niet beschikbaar via KMS. U moet extern nieuw sleutelmateriaal genereren, dit in dezelfde CMK importeren, instellen als primair sleutelmateriaal en zelf het overgangsschema beheren. Voor SSE-C bent u volledig verantwoordelijk voor de rotatie: u moet nieuwe sleutels in uw verzoeken aanleveren en bestaande objecten opnieuw versleutelen als u de sleutel die ze beschermt wilt wijzigen.

CloudTrail-logboekregistratie voor S3-versleutelingsgebeurtenissen

CloudTrail-logging vormt de basis voor de audit van de naleving van SSE-KMS-versleuteling. Elke KMS API-aanroep die door S3 namens een aanvragende instantie wordt gedaan, genereert een CloudTrail-record met daarin de ARN van de KMS-sleutel, de IAM-principal (gebruiker, rol of service), het bron-IP-adres, de naam van de S3-bucket en de objectsleutel, en een tijdstempel.

De twee gebeurtenissen die in de gaten gehouden moeten worden zijn: GenerateDataKey (gegenereerd wanneer een object wordt geüpload met SSE-KMS) en Decrypt (gegenereerd wanneer een object wordt gedownload en gedecodeerd). Het genereren van waarschuwingen bij deze gebeurtenissen maakt verschillende beveiligingsscenario's mogelijk: het detecteren van onverwachte gebruikers die gevoelige objecten decoderen, het identificeren van ongebruikelijk hoge decoderingsvolumes die kunnen wijzen op datalekken, het controleren van de naleving van het toegangsbeleid voor gegevens en het samenstellen van bewijsmateriaal voor wettelijke audits.

Configureer CloudTrail om naast beheergebeurtenissen ook S3-data-events te verzenden, aangezien S3-activiteit op objectniveau (GetObject, PutObject, DeleteObject) standaard niet wordt vastgelegd in beheergebeurtenislogboeken. Leid CloudTrail-logboeken door naar een aparte, tegen schrijven beveiligde S3-bucket in een speciaal beveiligingsaccount om manipulatie te voorkomen.

Kostenoverwegingen voor S3-encryptie

SSE-S3 brengt geen extra kosten met zich mee voor S3-opslag of -aanvragen. SSE-KMS brengt wel kosten met zich mee voor KMS API-aanroepen: AWS KMS rekent $ 0.03 per 10,000 API-aanroepen (GenerateDataKey voor uploads, Decrypt voor downloads). Voor een workload die 1 miljoen objecten per maand uploadt en downloadt, bedragen de KMS API-kosten ongeveer $ 6 per maand per CMK per regio. Door de klant beheerde KMS-sleutels kosten ook $ 1 per sleutel per maand.

Bij grote aantallen aanvragen (tientallen miljoenen S3-bewerkingen per maand) worden de kosten van de KMS API aanzienlijk. S3 ondervangt dit met een sleutelfunctie op bucketniveau: wanneer u de S3 Bucket Key-optie inschakelt voor een SSE-KMS-bucket, genereert S3 een kortstondige datasleutel op bucketniveau op basis van uw CMK en gebruikt deze om lokaal individuele object-DEK's te genereren, waardoor het aantal KMS API-aanroepen met wel 99% wordt verminderd. De Bucket Key-aanpak verlaagt de kosten voor S3-workloads met een hoge doorvoer aanzienlijk, terwijl dezelfde versleutelingseigenschappen behouden blijven.

SSE-C brengt geen AWS-kosten met zich mee voor sleutelbeheer, maar u draagt ​​wel de volledige operationele kosten voor het opslaan, distribueren, roteren en beveiligen van de sleutel buiten AWS. Client-side encryptie met een zelfbeheerde hoofdsleutel brengt eveneens geen AWS-kosten voor sleutelbeheer met zich mee, maar vereist wel uw eigen infrastructuur voor het beheer van de sleutellevenscyclus.

S3-versleuteling afdwingen met bucketbeleid

De versleutelingsconfiguratie van een bucket bepaalt het standaardgedrag voor nieuwe objecten, maar voorkomt niet dat een gebruiker expliciet een onversleuteld object uploadt, tenzij u een Deny-beleid toevoegt. Om te garanderen dat alle objecten versleuteld zijn en dat alleen de door u gekozen methode wordt gebruikt, combineert u twee Deny-instructies in het bucketbeleid.

Om SSE-KMS af te dwingen met een specifieke CMK:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyWrongKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/your-key-id"
        }
      }
    }
  ]
}

De eerste verklaring weigert elke upload die geen gebruikmaakt van SSE-KMS. De tweede verklaring beperkt uploads verder tot het gebruik van uw specifieke CMK ARN, waardoor wordt voorkomen dat iemand per ongeluk de standaard aws/s3-sleutel of een andere CMK gebruikt voor uw gereguleerde databucket.

Volledige vergelijking van alle S3-versleutelingsopties

De onderstaande tabel geeft een overzicht van alle S3-versleutelingsopties op basis van de aspecten die van belang zijn voor een beslissing over beveiliging en naleving van regelgeving:

Keuze	Versleuteling in rust	Versleuteling tijdens het transport	Sleutel beheerd door	CloudTrail per object	Onafhankelijke sleutelbediening	AWS ziet platte tekst
SSE-S3	Ja (AES-256-GCM)	Nee (apart beleid)	AWS	Nee	Nee	Ja
SSE-KMS (door AWS beheerde sleutel)	Ja (AES-256-GCM)	Nee (apart beleid)	AWS	Ja	Nee	Ja
SSE-KMS (door de klant beheerde CMK)	Ja (AES-256-GCM)	Nee (apart beleid)	Klant (in km)	Ja	Ja	Ja
SSE-C	Ja (AES-256-GCM)	Nee (apart beleid)	Klant (buiten AWS)	Nee	Ja	Ja (tijdens de operatie)
Clientzijde + KMS CMK	Ja (AES-256-GCM)	Nee (apart beleid)	Klant (sleutelomslag in KMS)	Ja (alleen toetsenbordomslag)	Ja	Nee
Clientzijde + zelfbeheerde sleutel	Ja (AES-256-GCM)	Nee (apart beleid)	Klant (volledig buiten AWS)	Nee	Ja	Nee
aws:SecureTransport-beleid	Nee	Ja (TLS)	AWS (TLS-certificaat)	Nee	Nee	NB

Multicloud- en hybride encryptiearchitectuur voor S3

Organisaties die S3 gebruiken in combinatie met Azure Blob Storage, Google Cloud Storage of on-premises objectopslag, worden geconfronteerd met een uitdaging op het gebied van consistentie in sleutelbeheer: elk cloudplatform heeft zijn eigen native sleutelbeheerservice en het beheren van afzonderlijke sleutelinventarissen, rotatiebeleid en auditsporen voor verschillende providers vergroot de operationele complexiteit en de inspanningen op het gebied van compliance aanzienlijk.

Drie patronen bieden een consistente oplossing voor S3-encryptie in meerdere clouds:

• Cloud-native per cloud met uniform CLM: Gebruik SSE-KMS voor S3, door Azure beheerde sleutels voor Blob Storage en Cloud KMS voor GCS, maar implementeer een platform voor certificaat- en sleutellevenscyclusbeheer dat de sleutelinventaris samenvoegt, de naleving van rotatievereisten controleert en een uniform auditspoor biedt voor alle cloudproviders. Dit behoudt de native prestaties en biedt tegelijkertijd inzicht in de governance.
• Gecentraliseerde BYOK in elke cloud: Genereer al het sleutelmateriaal vanuit één extern sleutelbeheersysteem. Importeer de afgeleide sleutels in AWS KMS (voor SSE-KMS BYOK), Azure Key Vault (voor Azure BYOK) en GCP Cloud KMS (voor GCP BYOK). Alle clouds gebruiken sleutels die terug te voeren zijn op dezelfde gezaghebbende bron. Sleutelrotatie en het levenscyclusbeleid worden centraal beheerd.
• Client-side encryptie met een gedeelde hoofdsleutel: Versleutel alle gegevens aan de clientzijde vóór het uploaden, met dezelfde hoofdsleutel, ongeacht in welke cloud de gegevens terechtkomen. De cloudprovider is volledig uitgesloten van de sleutelhiërarchie. Dit is het sterkste model voor multi-cloud soevereiniteit, maar vereist dat uw applicatie alle cryptografische bewerkingen afhandelt en dat uw externe sleutelbeheersysteem een ​​hoge beschikbaarheid heeft voor elke lees- en schrijfbewerking.

Voor organisaties die encryptiesleutels beheren in S3 en andere cloud- en on-premises omgevingen, biedt CBOM Secure van Encryption Consulting geautomatiseerde detectie en inventarisatie van cryptografische assets, waaronder KMS-sleutels, S3-bucket-encryptieconfiguraties en certificaatinventaris in CycloneDX-formaat voor compliance-rapportage. Onze adviesdiensten op het gebied van cloudgegevensbescherming ontwerpen de juiste sleutelbeheerarchitectuur voor uw specifieke multi-cloud compliance-vereisten.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is een bedrijf gespecialiseerd in toegepaste cryptografie met ISO/IEC 27001:2022- en SOC 2-certificeringen. Wij helpen organisaties bij het ontwerpen, implementeren en auditeren van S3-encryptieconfiguraties die voldoen aan HIPAA, PCI DSS, FedRAMP, NIST 800-53 en andere compliance-raamwerken.

• Advies inzake gegevensbescherming in de cloud: We beoordelen uw huidige S3-versleutelingsconfiguratie, identificeren hiaten (niet-versleutelde buckets, ontbrekende bucketbeleidsregels, SSE-S3 waar SSE-KMS vereist is, ontbrekende CloudTrail-data-events) en ontwerpen de doelarchitectuur, inclusief sleutelbeheermodel, IAM-model, handhaving van bucketbeleid en rotatieschema. Zie onze adviesdiensten.
• HSM als een service: Voor BYOK- en client-side-encryptiescenario's waarbij uw sleutelmateriaal moet worden gegenereerd in een FIPS-gevalideerde HSM buiten AWS, biedt Encryption Consulting de volgende oplossingen. HSM als een service Biedt een speciale FIPS 140-2 Level 3 HSM-infrastructuur voor sleutelgeneratie, met integratie in AWS KMS-sleutelimportworkflows.
• CBOM Secure: AWS-omgevingen met veel S3-buckets hebben vaak inconsistente encryptieconfiguraties. Encryption Consulting biedt hiervoor een oplossing. CBOM Secure Ontdekt en inventariseert alle S3-bucketversleutelingsinstellingen, KMS-sleutelconfiguraties en toegangsbeleidsregels in uw AWS-accounts en genereert een cryptografische materiaallijst in CycloneDX-formaat die hiaten identificeert en bewijsmateriaal voor audits ondersteunt.
• PKI als een service: Voor organisaties die private PKI-certificaten nodig hebben voor S3-clientauthenticatie (wederzijdse TLS naar S3-toegangspunten of S3 via VPC-eindpunten), biedt Encryption Consulting de volgende oplossingen. PKI als een service Biedt een beheerde private CA met ACME-geautomatiseerd certificaatlevenscyclusbeheer.
• PQC-gereedheid: NIST heeft in augustus 2024 de post-kwantumcryptografiestandaarden FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) afgerond. NIST IR 8547 wijst erop dat RSA en ECC rond 2030 zullen worden uitgefaseerd voor nieuwe toepassingen. Hoewel AES-256-GCM, gebruikt door S3, als kwantumresistent wordt beschouwd, zal de infrastructuur voor sleutelbeheer (KMS-sleutelversleuteling, TLS-verbindingen met S3-eindpunten) moeten overstappen op post-kwantumalgoritmen. Encryption Consulting's PQC-gereedheid Deze service brengt uw volledige S3-cryptografische status in kaart ten opzichte van de migratietijdlijn.

Neem contact op met Encryption Consulting om uw S3-encryptiearchitectuur te bespreken.

Conclusie

AWS S3 versleutelt nu standaard alle nieuwe objecten, waardoor het risico op het per ongeluk opslaan van onversleutelde gegevens wordt weggenomen. Standaardversleuteling met SSE-S3 biedt echter geen auditlogboek, geen onafhankelijk sleutelbeheer en geen mogelijkheid om de toegang tot gegevens in te trekken zonder ze te verwijderen. Voor elke gereguleerde workload is SSE-KMS met een door de klant beheerde CMK de minimaal geschikte configuratie: het voegt een auditlogboek per object toe, stelt u in staat de sleutel uit te schakelen om de S3-ontsleutelingsmogelijkheid direct in te trekken en ondersteunt BYOK als u door de klant gegenereerd sleutelmateriaal nodig hebt.

Client-side encryptie is de juiste keuze wanneer het dreigingsmodel vereist dat AWS nooit toegang heeft tot onversleutelde gegevens, ook niet onder wettelijke verplichting. Het verhoogt de complexiteit van de applicatie, maar biedt de sterkste positie op het gebied van gegevenssoevereiniteit die in elke cloudomgeving beschikbaar is.

De belangrijkste beheerbeslissing, het IAM-ontwerp, de handhaving van het bucketbeleid en de CloudTrail-configuratie zijn allemaal even belangrijk als de versleutelingsmethode zelf. Versleuteling zonder de bijbehorende beheersmaatregelen is slechts schijnvertoning: je kunt wel zeggen dat de gegevens versleuteld zijn, maar je kunt niet zeggen wie ze heeft ontsleuteld, wanneer, of of die persoon daartoe bevoegd was.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen SSE-S3, SSE-KMS en SSE-C in Amazon S3?

Bij SSE-S3 genereert, beheert en roteert AWS automatisch alle encryptiesleutels, zonder dat de klant hier inzicht in heeft of er controle over heeft. SSE-KMS maakt gebruik van AWS KMS en biedt een CloudTrail-auditlogboek van elke encryptie- en decryptiebewerking, met de keuze tussen door AWS beheerde of door de klant beheerde sleutels. Bij SSE-C moet u een 256-bits AES-sleutel in elke aanvraagheader meesturen; S3 gebruikt deze en verwijdert deze direct, waarbij alleen een HMAC-vingerafdruk wordt opgeslagen. Het belangrijkste verschil zit hem in de diepte van de audit en de controle: SSE-S3 biedt geen van beide; SSE-KMS biedt beide; SSE-C biedt controle zonder een KMS-auditlogboek.

Wat is client-side encryptie in Amazon S3 en wanneer moet ik het gebruiken?

Client-side encryptie betekent dat u gegevens versleutelt voordat u ze naar S3 uploadt, zodat S3 alleen de versleutelde tekst opslaat en AWS nooit de onversleutelde tekst verwerkt. Gebruik deze optie wanneer wettelijke vereisten encryptie vereisen voordat gegevens uw omgeving verlaten, wanneer uw dreigingsmodel AWS als potentieel toegangspunt omvat (HYOK-model), of wanneer u zero-trust opslag nodig hebt waarbij geen enkele cloudprovider toegang heeft tot uw gegevens. De keerzijde is dat de applicatie volledig verantwoordelijk is voor het beheer, de rotatie en de distributie van sleutels naar alle systemen die toegang tot objecten nodig hebben.

Versleutelt AWS S3 gegevens standaard?

Ja. Sinds januari 2023 past Amazon S3 automatisch SSE-S3 (AES-256-GCM) toe op alle nieuwe objecten in elke S3-bucket, zelfs zonder expliciete configuratie. Bestaande objecten die al in een bucket zijn opgeslagen, worden niet met terugwerkende kracht versleuteld. U kunt de standaardinstelling op bucketniveau wijzigen naar SSE-KMS om een ​​CloudTrail-auditlogboek en klantsleutelbeheer in te schakelen.

Wat is BYOK voor Amazon S3 en hoe werkt het?

BYOK (Bring Your Own Key) voor S3 betekent dat u sleutelmateriaal genereert in uw eigen HSM of sleutelbeheersysteem, dit importeert in AWS KMS als een door de klant beheerde sleutel met geïmporteerd sleutelmateriaal, en SSE-KMS op uw S3-bucket configureert om die CMK te gebruiken. AWS KMS gebruikt uw geïmporteerde materiaal om de gegevensversleutelingssleutels te genereren die uw objecten beschermen. U behoudt het bronsleutelmateriaal en kunt dit uit KMS verwijderen om verdere decryptie onmiddellijk te voorkomen zonder tussenkomst van AWS-ondersteuning.

Hoe kan ik met behulp van een bucketbeleid encryptie afdwingen voor alle S3-objecten?

Voeg een Deny-instructie toe aan uw S3-bucketbeleid die gericht is op s3:PutObject-verzoeken waarbij de s3:x-amz-server-side-encryption-header niet is ingesteld op aws:kms (voor SSE-KMS) of AES256 (voor SSE-S3). Voeg een tweede Deny-instructie toe met de voorwaarde aws:SecureTransport ingesteld op false om alle HTTP-verzoeken (niet-TLS) te blokkeren. Deze twee voorwaarden samen voorkomen zowel onversleutelde uploads als onversleutelde verbindingen met de bucket.

Hoe wordt AWS S3-versleuteling weergegeven in CloudTrail-auditlogboeken?

SSE-KMS genereert een GenerateDataKey CloudTrail-gebeurtenis bij elke PutObject en een Decrypt-gebeurtenis bij elke GetObject. Elke gebeurtenis bevat de ARN van de KMS-sleutel, de aanvragende IAM-principal, de S3-bucket- en objectsleutel, het bron-IP-adres en een tijdstempel. SSE-S3 en SSE-C genereren geen KMS-gebeurtenissen. Schakel S3-datagebeurtenissen in CloudTrail afzonderlijk van beheergebeurtenissen in, aangezien S3-API-aanroepen op objectniveau standaard niet worden vastgelegd in beheergebeurtenislogboeken.