AWS S3 – Klient- och serversideskryptering

AWS S3-kryptering på klient- och serversidan ger dig fem olika sätt att skydda data i Amazon Simple Storage Service, vart och ett med en annan balans mellan nyckelägande, driftskomplexitet, granskningsdjup och kostnad. Rätt val beror på vem du behöver låsa ute: bara externa angripare eller AWS självt. Den här guiden täcker alla S3-krypteringsalternativ, när du ska använda vart och ett, hur du tillämpar dem med bucket-policyer, vad som visas i CloudTrail och hur du väljer mellan nativ nyckelhantering, BYOK och HYOK.

Snabbt svar: Vilket AWS S3-krypteringsalternativ bör du använda?

För de flesta arbetsbelastningar: använd SSE-KMS med en kundhanterad KMS-nyckel. Du får AES-256-kryptering i vila, en komplett CloudTrail-revisionslogg för varje krypterings- och dekrypteringshändelse kopplad till en IAM-identitet, möjlighet att inaktivera oberoende nyckel och automatisk årlig nyckelrotation. För högsta nyckelsuveränitet (där AWS aldrig får inneha din nyckel): använd klientsideskryptering med din egen huvudnyckel. För enklaste installationen utan nyckelhanteringsoverhead och inget krav på revisionslogg: SSE-S3 (som nu är S3-standard sedan januari 2023). För att tillhandahålla din egen nyckel per begäran utan att använda KMS: SSE-C.

Key Takeaways

• S3 krypterar som standard sedan januari 2023: Alla nya objekt i valfri S3-bucket krypteras automatiskt med SSE-S3 (AES-256) även utan explicit konfiguration. Befintliga objekt krypteras inte retroaktivt.
• Det finns fem krypteringsalternativ, uppdelade i två kategorier: Serversidan (SSE-S3, SSE-KMS, SSE-C) innebär att S3 hanterar krypteringsoperationen efter att ha mottagit data. Klientsidan innebär att du krypterar innan uppladdning, så S3 ser aldrig klartext.
• SSE-KMS är den rekommenderade standarden för reglerade arbetsbelastningar: Den tillhandahåller en revisionslogg per operation i CloudTrail, stöder kundhanterade nycklar med BYOK och låter dig inaktivera eller ta bort en nyckel för att omedelbart förhindra dekryptering utan att ta bort objekt.
• BYOK och HYOK uppfyller olika suveränitetskrav: BYOK (import av eget nyckelmaterial till AWS KMS) behåller nyckeln i AWS under användning men ger dig proveniens. HYOK (klientsideskryptering med din egen huvudnyckel) innebär att AWS aldrig vidrör nyckeln.
• Kryptering under överföring kräver en separat bucketpolicy: Standardkrypteringen för S3 täcker endast data i vila. Neka aws:SecureTransport=false i din bucketpolicy för att tillämpa TLS för alla förfrågningar.

Vad är AWS S3-kryptering och varför är det viktigt?

Amazon S3 (Simple Storage Service) är AWS objektlagringstjänst. Den lagrar data som objekt i containrar som kallas buckets. Varje objekt kan vara upp till 5 TB stort. S3 används ofta för säkerhetskopior, datasjöar, applikationstillgångar, loggarkiv och reglerade datamängder, inklusive arbetsbelastningar inom hälso- och sjukvård (HIPAA), ekonomi (PCI DSS) och myndigheter (FedRAMP).

Kryptering i S3 adresserar två separata hotmodeller. Kryptering i vila skyddar objekt som lagras på disk från att läsas om det underliggande lagringsmediet används utan auktorisering. Kryptering under överföring skyddar objekt medan de transporteras mellan klienter och S3-tjänsten. Båda krävs för de flesta efterlevnadsramverk, och båda kräver separata konfigurationer i S3.

S3 använder AES-256 med Galois Counter Mode (AES-256-GCM) för alla symmetriska krypteringsoperationer. GCM tillhandahåller autentiserad kryptering: den lägger till en unik autentiseringstagg till varje krypterat objekt, vilket verifierar både att informationen inte har manipulerats och att rätt nyckel användes för dekryptering. Detta skyddar mot både passiv avlyssning och aktiv modifiering av lagrad chiffertext.

Kryptering under överföring: Tillämpa TLS för alla S3-förfrågningar

S3 stöder HTTPS (TLS) för alla API-förfrågningar. TLS krypterar anslutningen mellan klienten och S3-slutpunkten, vilket skyddar objektdata och begärandemetadata under överföring. S3 tillämpar dock inte HTTPS som standard; en S3-bucket utan en policy accepterar både HTTP- och HTTPS-förfrågningar.

För att tillämpa TLS för alla förfrågningar till en bucket, tillämpa en bucketpolicy som nekar alla förfrågningar där aws:SecureTransport Villkorsnyckeln är falsk. Principen nedan nekar alla GetObject-förfrågningar som inte använder HTTPS:

{
  "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": "*"
    }
  ]
}

Tillämpa denna policy på varje S3-bucket som innehåller känsliga data. Observera att Resource blocket måste täcka både hinken ARN och objektet ARN (med /*) för att neka API-anrop på både bucket-nivå och objektnivå som görs via HTTP.

Server-Side Encryption (SSE): Tre alternativ förklarade

Serversideskryptering innebär att S3 tar emot dina data via HTTPS och sedan krypterar dem innan de skrivs till disk. S3 lagrar chiffertexten. När du begär objektet dekrypterar S3 det (med lämplig nyckel) innan det skickas tillbaka till dig via HTTPS. Krypteringen och dekrypteringen sker inom S3-tjänstens gränser. Din applikation behöver inte hantera kryptografiska operationer.

SSE-S3: S3-hanterade nycklar (standard sedan januari 2023)

SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys) är standardkrypteringsmetoden för alla nya S3-objekt från och med januari 2023. AWS genererar en unik AES-256-GCM-datakrypteringsnyckel för varje objekt. Den datanyckeln krypteras sedan med en regelbundet roterande huvudnyckel som AWS hanterar helt och hållet. Du har ingen insyn i eller kontroll över någon av nycklarna.

SSE-S3 är lämpligt för arbetsbelastningar där kryptering i vila krävs, men det inte finns något krav på en kundgranskningslogg för nyckelanvändning eller oberoende nyckelkontroll. Det lägger inte till några driftskostnader och inga kostnader utöver standard S3-lagring. Nackdelen: du kan inte inaktivera, rotera eller granska åtkomst till krypteringsnyckeln. Det finns ingen CloudTrail-post för enskilda objektdekrypteringar. Du kan inte återkalla möjligheten att dekryptera ett objekt utan att ta bort själva objektet.

SSE-KMS: KMS-hanterade nycklar med revisionslogg och kundkontroll

SSE-KMS använder AWS Key Management Service (KMS) för att hantera krypteringsnycklarna som skyddar dina S3-objekt. När du laddar upp ett objekt med SSE-KMS anropar S3 KMS för att generera en datakrypteringsnyckel (DEK). KMS returnerar två versioner: en klartext-DEK (används för att kryptera objektet) och en krypterad DEK (lagras bredvid det krypterade objektet i S3). S3 kasserar klartext-DEK:n omedelbart efter att objektet har krypterats. När du laddar ner objektet skickar S3 den krypterade DEK:n till KMS, som dekrypterar den och returnerar klartext-DEK:n så att S3 kan dekryptera objektet och returnera det till dig.

Varje GenerateDataKey- och Decrypt-anrop till KMS genererar en CloudTrail-loggpost som inkluderar KMS-nyckelns ARN, den begärande IAM-principalen, S3-bucket- och objektnyckeln samt en tidsstämpel. Detta ger dig en komplett, identitetslänkad revisionslogg för varje krypterings- och dekrypteringshändelse på varje S3-objekt som skyddas av SSE-KMS.

SSE-KMS stöder två nyckeltyper, som har avsevärt olika säkerhets- och kontrollegenskaper:

AWS-hanterad KMS-nyckel (aws/s3): AWS skapar den här nyckeln automatiskt första gången du aktiverar SSE-KMS på en bucket utan att ange en CMK. AWS hanterar nyckeln helt och hållet, inklusive rotation (vart tredje år för aws/s3-nycklar). Du kan visa nyckeln i KMS men kan inte ändra dess policy, inaktivera den eller ta bort den. Du får CloudTrail-loggning men ingen oberoende kontroll över nyckeln.

Kundhanterad KMS-nyckel (CMK): Du skapar den här nyckeln i KMS innan du aktiverar SSE-KMS. Du definierar nyckelpolicyn, kontrollerar vem som kan använda nyckeln för S3-kryptering och -dekryptering, aktiverar automatisk årlig rotation och kan inaktivera eller ta bort nyckeln när som helst. Att inaktivera CMK:n förhindrar omedelbart att S3 dekrypterar objekt som är krypterade med den nyckeln, utan att ta bort dessa objekt. Detta är det rekommenderade alternativet för reglerade arbetsbelastningar.

SSE-C: Kundlevererade krypteringsnycklar

SSE-C (Server-Side Encryption with Customer-Provided Keys) kräver att du inkluderar en 256-bitars AES-krypteringsnyckel i HTTP-förfrågningshuvudet för varje PutObject (uppladdning) och GetObject (nedladdning). S3 använder din angivna nyckel för att utföra AES-256-krypterings- eller dekrypteringsoperationen och tar sedan omedelbart bort nyckeln från minnet. S3 lagrar endast ett slumpmässigt saltat HMAC (Hash-Based Message Authentication Code) fingeravtryck av nyckeln för att validera framtida förfrågningar.

Konsekvensen: om du förlorar nyckeln förlorar du permanent åtkomst till alla objekt som krypterats med den. Det finns ingen mekanism för nyckelåterställning. SSE-C måste använda HTTPS; S3 avvisar SSE-C-förfrågningar som görs via HTTP.

SSE-C är lämpligt när du behöver S3 för att utföra krypteringsoperationer men du inte kan eller vill lägga in din nyckel i AWS KMS. Du tar fullt ansvar för nyckelhantering, rotation, lagring och distribution till varje system som behöver åtkomst till objekten. SSE-C genererar inga KMS CloudTrail-händelser eftersom den inte använder KMS.

Klientsidans kryptering: Kryptering före uppladdning

Klientsideskryptering innebär att din applikation eller klient krypterar data innan den lämnar din miljö. Det S3 tar emot och lagrar är redan chiffertext; S3 har aldrig tillgång till klartexten. Detta är den enda S3-krypteringsmodellen där AWS inte kan komma åt dina data under några operativa omständigheter, inklusive rättsligt tvång riktat mot AWS.

AWS SDK för Java (och andra språk) tillhandahåller en S3-krypteringsklient som implementerar kryptering på klientsidan. Det finns två alternativ för nyckelhantering:

Klientsidan med AWS KMS CMK: Din applikation anropar KMS för att generera en klartextdatanyckel och en krypterad datanyckel. Din applikation krypterar objektet med klartextdatanyckeln, kasserar klartextnyckeln och laddar upp chiffertexten tillsammans med den krypterade datanyckeln som objektmetadata. För att ladda ner och dekryptera hämtar din applikation den krypterade datanyckeln från objektmetadata, anropar KMS för att dekryptera den, använder den returnerade klartextdatanyckeln för att dekryptera objektet och kasserar klartextnyckeln. AWS KMS är involverat i nyckelomslagning, så det finns en CloudTrail-post över nyckeloperationer, men AWS har aldrig åtkomst till klartextobjektdata.

Klientsidan med en självhanterad huvudnyckel: Din applikation använder sin egen huvudnyckel (lagrad i din HSM, nyckelhanteringssystem eller applikationsnyckellager) för att omsluta och packa upp datakrypteringsnyckeln. AWS är inte involverad i någon nyckeloperation. Detta är HYOK-modellen (Hold Your Own Key): krypteringsnyckeln ligger helt utanför AWS. Även om AWS skulle vara tvunget att ge åtkomst till din S3-bucket, är den lagrade chiffertexten värdelös utan huvudnyckeln som aldrig kom in i AWS.

Native Key Control kontra BYOK kontra HYOK: Vilken modell passar dina krav?

Det viktigaste krypteringsbeslutet för alla S3-arbetsbelastningar är inte vilket AES-läge som ska användas – det är vem som kontrollerar nycklarna. De tre nyckelkontrollmodellerna som finns tillgängliga för S3 har mycket olika säkerhetsegenskaper, driftskrav och efterlevnadskonsekvenser.

Dimensionera	Native (SSE-S3 eller AWS-hanterad KMS-nyckel)	BYOK (kundhanterad KMS-nyckel med importerat nyckelmaterial)	HYOK (Klientsideskryptering med självhanterad huvudnyckel)
Vem genererar krypteringsnyckeln	AWS	Kund (importerad till KMS)	Kund (kommer aldrig in i AWS)
AWS-åtkomst till klartextnyckel	Ja	Ja, under aktiv KMS-operation	Nej
CloudTrail-granskningslogg per objekt	SSE-S3: Nej. AWS-hanterad KMS: Ja	Ja (GenereateDataKey + Decrypt-händelser)	KMS-variant: Ja (nyckelomslag/avbrytning). Självhantering: Nej
Inaktivera/återkalla oberoende nyckel	SSE-S3: Nej. AWS-hanterad KMS: Nej	Ja (inaktivera eller ta bort CMK omedelbart)	Ja (återkalla i ditt nyckelhanteringssystem)
Automatisk nyckelrotation	SSE-S3: Ja (AWS-hanterad). AWS-hanterad KMS: Vart tredje år	Ja (årligt för CMK) eller manuellt för importerat material	Helt kundstyrd
Operationell komplexitet	Låg	Medium	Hög
KMS API-kostnad per S3-operation	SSE-S3: Ingen. AWS-hanterad KMS: 0.03 USD/10 000 samtal	0.03 USD/10 000 samtal	KMS-variant: 0.03 USD/10 000 samtal. Självhanterad: Ingen
Bäst för	Allmänna arbetsbelastningar; prioritet för enkelhet	Reglerade sektorer; HIPAA, PCI DSS, FedRAMP	Nollförtroendelagring; airgappad lagring; sekretessbelagda data

IAM-modell: Åtkomst med lägsta behörighet för S3-kryptering

Kryptering i sig förhindrar inte obehörig åtkomst. Korrekt IAM-konfiguration avgör vem som kan läsa (och därmed dekryptera) S3-objekt. En väl utformad IAM-modell för SSE-KMS S3-arbetsbelastningar separerar hantering av krypteringsnycklar från dataåtkomst med hjälp av tre kontrolllager.

S3-bucketpolicy: Styr vilka IAM-principaler som kan utföra S3 API-anrop (GetObject, PutObject, ListBucket, DeleteObject) på hinken och dess objekt. För SSE-KMS-tillämpning, lägg till ett neka-villkor som kräver att s3:x-amz-server-side-encryption rubriken ska vara aws:kms på alla PutObject-förfrågningar, vilket säkerställer att inga okrypterade objekt kan laddas upp.

KMS-nyckelpolicy: Kontrollerar vilka IAM-principer som kan använda CMK:n för kms:GenerateDataKey (behövs för att kryptera objekt) och kms:Decrypt (behövs för att dekryptera objekt). S3-tjänsten anropar KMS åt den begärande IAM-principalen; principalen måste ha både S3- och KMS-behörigheter för att åtgärden ska lyckas. Separera rollen som nyckeladministratör (som kan hantera nyckelpolicy, rotera, inaktivera) från rollen som nyckelanvändare (som kan kryptera/dekryptera via S3).

IAM-identitetspolicy: Den anropande principalens IAM-policy måste tillåta både S3-åtgärden och KMS-åtgärden. För en skrivskyddad roll som ska komma åt S3-objekt men aldrig ladda upp nya, bevilja s3:GetObject och kms:Decrypt endast. För en skrivroll, lägg till s3:PutObject och kms:GenerateDataKeyBevilja aldrig kms:CreateKey, kms:DeleteKey, eller kms:DisableKey till applikationsroller.

Service Control Policies (SCP:er): Om dina AWS-konton finns i en AWS-organisation, tillhandahåller SCP:er ett skyddslager ovanför IAM-policyer. Använd en SCP för att neka alla S3 PutObject som inte inkluderar en krypteringsrubrik, vilket förhindrar att någon principal i organisationen av misstag lagrar okrypterade S3-objekt oavsett individuella kontons IAM-konfigurationer.

Nyckelrotation för S3-kryptering

Nyckelrotation för S3 SSE-KMS fungerar genom KMS-nyckelrotation, inte genom att omkryptera varje S3-objekt. När automatisk årlig rotation är aktiverad på en kundhanterad CMK genererar KMS nytt kryptografiskt material och markerar det som aktiv version. Alla nya S3 PutObject-åtgärder använder det nya nyckelmaterialet. Befintliga objekt förblir krypterade med den nyckelmaterialversion som var aktiv när de laddades upp; KMS behåller alla tidigare versioner och använder den korrekta vid dekryptering av dessa äldre objekt.

Det här innebär att du aldrig behöver ladda upp eller kryptera dina S3-objekt igen för att implementera nyckelrotation. CMK ARN och nyckel-ID förblir desamma; rotationen är transparent för S3 och dina applikationer. Rotationshändelsen loggas i CloudTrail under RotateKey händelsetyp.

För BYOK-nycklar med importerat nyckelmaterial är automatisk rotation inte tillgänglig via KMS. Du måste generera nytt nyckelmaterial externt, importera det till samma CMK, ställa in det som primärt nyckelmaterial och hantera övergångstidslinjen själv. För SSE-C är du helt ansvarig för rotationen: du måste ange nya nycklar i dina förfrågningar och kryptera om befintliga objekt om du vill ändra nyckeln som skyddar dem.

CloudTrail-loggning för S3-krypteringshändelser

CloudTrail-loggning är granskningsryggraden för SSE-KMS-krypteringsefterlevnad. Varje KMS API-anrop som görs av S3 för en begärande principal genererar en CloudTrail-post som innehåller KMS-nyckelns ARN, IAM-principalen (användare, roll eller tjänst), käll-IP-adressen, S3-bucketnamnet och objektnyckeln samt en tidsstämpel.

De två händelserna att övervaka är GenerateDataKey (genereras när ett objekt laddas upp med SSE-KMS) och Decrypt (genereras när ett objekt laddas ner och dekrypteras). Aviseringar om dessa händelser möjliggör flera säkerhetsanvändningsfall: upptäcka oväntade principer som dekrypterar känsliga objekt, identifiera ovanligt höga dekrypteringsvolymer som kan indikera dataexfiltrering, granska efterlevnad av dataåtkomstpolicyer och bygga bevispaket för myndighetsrevisioner.

Konfigurera CloudTrail för att leverera S3-datahändelser utöver hanteringshändelser, eftersom aktivitet på S3-objektnivå (GetObject, PutObject, DeleteObject) inte registreras i hanteringshändelseloggar som standard. Dirigera CloudTrail-loggar till en separat, skrivskyddad S3-bucket i ett dedikerat säkerhetskonto för att förhindra manipulering.

Kostnadsöverväganden för S3-kryptering

SSE-S3 lägger inte till några kostnader för S3-lagring eller förfrågningar. SSE-KMS lägger till kostnader för KMS API-anrop: AWS KMS debiterar 0.03 USD per 10 000 API-anrop (GenereateDataKey för uppladdningar, Decrypt för nedladdningar). För en arbetsbelastning som upp- och nedladdningar av 1 miljon objekt per månad är KMS API-kostnaden cirka 6 USD per månad per CMK per region. Kundhanterade KMS-nycklar kostar också 1 USD per nyckel per månad.

Vid höga volymer av begäranden (tiotals miljoner S3-operationer per månad) blir kostnaderna för KMS API betydande. S3 mildrar detta genom en nyckelfunktion på bucket-nivå: när du aktiverar alternativet S3 Bucket Key på en SSE-KMS-bucket genererar S3 en kortlivad datanyckel på bucket-nivå från din CMK och använder den för att generera enskilda objekt-DEK:er lokalt, vilket minskar KMS API-anrop med upp till 99 %. Bucket Key-metoden minskar dramatiskt kostnaderna för S3-arbetsbelastningar med hög genomströmning samtidigt som samma krypteringsegenskaper bevaras.

SSE-C har ingen AWS-kostnad för nyckelhantering, men du bär den fulla driftskostnaden för att lagra, distribuera, rotera och skydda nyckeln utanför AWS. Klientsideskryptering med en självhanterad huvudnyckel har på liknande sätt ingen AWS-nyckelhanteringskostnad men kräver din egen infrastruktur för nyckellivscykelhantering.

Tillämpa S3-kryptering med Bucket Policies

Krypteringskonfigurationen för en bucket anger standardbeteendet för nya objekt, men det hindrar inte en anropare från att explicit ladda upp ett okrypterat objekt om du inte lägger till en Deny-policy. För att garantera att alla objekt krypteras och att endast din valda metod används, kombinera två Deny-satser i bucket-policyn.

För att tillämpa SSE-KMS med en specifik 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"
        }
      }
    }
  ]
}

Det första kommandot nekar alla uppladdningar som inte använder SSE-KMS. Det andra kommandot begränsar ytterligare uppladdningar till att endast använda ditt specifika CMK ARN, vilket förhindrar att någon av misstag använder standardnyckeln för aws/s3 eller en annan CMK på din reglerade databucket.

Komplett jämförelse av alla S3-krypteringsalternativ

Tabellen nedan sammanfattar alla S3-krypteringsalternativ för de dimensioner som är viktiga för ett säkerhets- och efterlevnadsbeslut:

Alternativet	Kryptering vid vila	Kryptering i transit	Nyckel hanterad av	CloudTrail per objekt	Oberoende nyckelkontroll	AWS ser klartext
SSE-S3	Ja (AES-256-GCM)	Nej (separat policy)	AWS	Nej	Nej	Ja
SSE-KMS (AWS-hanterad nyckel)	Ja (AES-256-GCM)	Nej (separat policy)	AWS	Ja	Nej	Ja
SSE-KMS (kundhanterad CMK)	Ja (AES-256-GCM)	Nej (separat policy)	Kund (i KMS)	Ja	Ja	Ja
SSE-C	Ja (AES-256-GCM)	Nej (separat policy)	Kund (utanför AWS)	Nej	Ja	Ja (under drift)
Klientsidan + KMS CMK	Ja (AES-256-GCM)	Nej (separat policy)	Kund (nyckelomslag i KMS)	Ja (endast nyckelomslag)	Ja	Nej
Klientsidan + självhanterad nyckel	Ja (AES-256-GCM)	Nej (separat policy)	Kund (helt utanför AWS)	Nej	Ja	Nej
aws:SecureTransport-policy	Nej	Ja (TLS)	AWS (TLS-certifikat)	Nej	Nej	-

Multimoln- och hybridkrypteringsarkitektur för S3

Organisationer som använder S3 tillsammans med Azure Blob Storage, Google Cloud Storage eller lokal objektlagring står inför en utmaning med konsekvent nyckelhantering: varje molnplattform har sin egen inbyggda nyckelhanteringstjänst, och att hantera separata nyckelinventeringar, rotationspolicyer och granskningsspår mellan leverantörer multiplicerar den operativa komplexiteten och efterlevnadsarbetet.

Tre mönster hanterar S3-kryptering i flera moln konsekvent:

• Molnbaserad per-moln med enhetlig CLM: Använd SSE-KMS för S3, Azure-hanterade nycklar för Blob och Cloud KMS för GCS, men distribuera en plattform för hantering av certifikat och nyckellivscykel som aggregerar nyckelinventeringen, övervakar rotationsefterlevnad och tillhandahåller en enhetlig granskningslogg för alla molnleverantörer. Detta bevarar den inbyggda prestandan samtidigt som det ger styrningsinsyn.
• Centraliserad BYOK i varje moln: Generera allt nyckelmaterial från ett enda externt nyckelhanteringssystem. Importera härledda nycklar till AWS KMS (för SSE-KMS BYOK), Azure Key Vault (för Azure BYOK) och GCP Cloud KMS (för GCP BYOK). Alla moln använder nycklar som kan spåras tillbaka till samma auktoritativa källa. Nyckelrotation och livscykelpolicy hanteras centralt.
• Klientsidans kryptering med en delad huvudnyckel: Kryptera all data på klientsidan före uppladdning, med samma huvudnyckel oavsett vilket moln datan hamnar i. Molnleverantören är helt exkluderad från nyckelhierarkin. Detta är den starkaste suveränitetsmodellen för flera moln, men kräver att din applikation hanterar alla kryptografiska operationer och att ditt externa nyckelhanteringssystem har hög tillgänglighet för varje läs- och skrivoperation.

För organisationer som hanterar krypteringsnycklar över S3 och andra moln- och lokala källor, tillhandahåller Encryption Consultings CBOM Secure automatiserad identifiering och inventering av kryptografiska tillgångar, inklusive KMS-nycklar, S3-bucketkrypteringskonfigurationer och certifikatinventering i CycloneDX-format för efterlevnadsrapportering. Våra rådgivningstjänster för molndataskydd utformar rätt nyckelkontrollarkitektur för era specifika krav på efterlevnad i flera moln.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att designa, implementera och granska S3-krypteringskonfigurationer som uppfyller HIPAA, PCI DSS, FedRAMP, NIST 800-53 och andra efterlevnadsramverk.

• Råd om molndataskydd: Vi utvärderar er nuvarande S3-krypteringskonfiguration, identifierar luckor (okrypterade buckets, saknade bucketpolicyer, SSE-S3 där SSE-KMS krävs, saknade CloudTrail-datahändelser) och utformar målarkitekturen inklusive nyckelkontrollmodell, IAM-modell, tillämpning av bucketpolicyer och rotationsschema. Se vår rådgivningstjänster.
• HSM som en tjänst: För BYOK- och klientsideskrypteringsscenarier där ditt nyckelmaterial måste genereras i en FIPS-validerad HSM utanför AWS, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad FIPS 140-2 Level 3 HSM-infrastruktur för nyckelgenerering, med integration i AWS KMS-nyckelimportflöden.
• CBOM-säker: AWS-miljöer med många S3-buckets har ofta inkonsekventa krypteringskonfigurationer. Encryption Consultings CBOM-säkerhet upptäcker och inventerar alla S3-bucketkrypteringsinställningar, KMS-nyckelkonfigurationer och åtkomstpolicyer för dina AWS-konton, och genererar en kryptografisk materiallista i CycloneDX-format som identifierar luckor och stöder revisionsbevispaket.
• PKI som en tjänst: För organisationer som behöver privata PKI-certifikat för S3-klientautentisering (ömsesidig TLS till S3-åtkomstpunkter eller S3 via VPC-slutpunkter), Encryption Consultings PKI som en tjänst tillhandahåller hanterad privat CA med ACME-automatiserad hantering av certifikatlivscykeln.
• PQC-beredskap: NIST slutförde postkvantkryptografistandarderna FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. NIST IR 8547 pekar mot att RSA och ECC avskrivs för nya användningsområden runt 2030. Medan AES-256-GCM som används av S3 anses vara kvantresistent, kommer nyckelhanteringsinfrastrukturen (KMS-nyckelomslag, TLS-anslutningar till S3-slutpunkter) att behöva övergå till postkvantalgoritmer. Encryption Consultings PQC-beredskap Tjänsten mappar din fullständiga S3-kryptografiska position mot migreringstidslinjen.

För att diskutera er S3-krypteringsarkitektur, kontakta Encryption Consulting.

Slutsats

AWS S3 krypterar nu alla nya objekt som standard, vilket eliminerar risken för att oavsiktligt lagra okrypterad data. Men standardkryptering med SSE-S3 ger ingen revisionslogg, ingen oberoende nyckelkontroll och ingen möjlighet att återkalla åtkomst till data utan att radera den. För alla reglerade arbetsbelastningar är SSE-KMS med en kundhanterad CMK den lägsta lämpliga konfigurationen: den lägger till en revisionslogg per objekt, låter dig inaktivera nyckeln för att omedelbart återkalla S3-dekrypteringsfunktion och stöder BYOK om du behöver kundgenererat nyckelmaterial.

Klientsideskryptering är rätt val när hotmodellen kräver att AWS aldrig har tillgång till klartext, inte ens under juridisk tvång. Det ökar applikationskomplexiteten men ger den starkaste datasuveräniteten som finns tillgänglig i alla molnmiljöer.

Beslutet om nyckelkontroll, IAM-designen, tillämpningen av bucketpolicyn och CloudTrail-konfigurationen är alla lika viktiga som själva krypteringsmetoden. Kryptering utan omgivande kontroller är en efterlevnadsteater: man kan säga att informationen är krypterad, men man kan inte säga vem som dekrypterade den, när eller om de var behöriga att göra det.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan SSE-S3, SSE-KMS och SSE-C i Amazon S3?

SSE-S3 låter AWS generera, hantera och rotera alla krypteringsnycklar automatiskt utan kundinsyn eller kontroll. SSE-KMS använder AWS KMS och tillhandahåller en CloudTrail-revisionslogg för varje krypterings- och dekrypteringsoperation, med ett val mellan AWS-hanterade eller kundhanterade nycklar. SSE-C kräver att du anger en 256-bitars AES-nyckel i varje förfrågningshuvud; S3 använder den och kasserar den omedelbart, och lagrar endast ett HMAC-fingeravtryck. Den viktigaste skillnaden är revisionsdjup och kontroll: SSE-S3 tillhandahåller ingendera; SSE-KMS tillhandahåller båda; SSE-C tillhandahåller kontroll utan en KMS-revisionslogg.

Vad är klientsideskryptering i Amazon S3 och när ska jag använda det?

Klientsideskryptering innebär att du krypterar data innan du laddar upp till S3, så S3 lagrar endast chiffertext och AWS hanterar aldrig klartext. Använd det när myndighetskrav kräver kryptering innan data lämnar din miljö, när din hotmodell inkluderar AWS som en potentiell åtkomstpunkt (HYOK-modell), eller när du behöver nollförtroendelagring där ingen molnleverantör kan komma åt dina data. Avvägningen är fullt applikationsansvar för nyckelhantering, rotation och distribution till alla system som behöver objektåtkomst.

Krypterar AWS S3 data som standard?

Ja. Från och med januari 2023 tillämpar Amazon S3 automatiskt SSE-S3 (AES-256-GCM) på alla nya objekt i alla S3-buckets, även utan explicit konfiguration. Befintliga objekt som redan lagras i en bucket krypteras inte retroaktivt. Du kan ändra standardinställningen till SSE-KMS på bucketnivå för att aktivera en CloudTrail-revisionslogg och kundnyckelkontroll.

Vad är BYOK för Amazon S3 och hur fungerar det?

BYOK (Bring Your Own Key) för S3 innebär att du genererar nyckelmaterial i ditt eget HSM eller nyckelhanteringssystem, importerar det till AWS KMS som en kundhanterad nyckel med importerat nyckelmaterial och konfigurerar SSE-KMS på din S3-bucket för att använda den CMK:n. AWS KMS använder ditt importerade material för att generera datakrypteringsnycklarna som skyddar dina objekt. Du behåller källnyckelmaterialet och kan ta bort det från KMS för att omedelbart förhindra ytterligare dekryptering utan inblandning från AWS-support.

Hur framtvingar jag kryptering på alla S3-objekt med hjälp av en bucket-policy?

Lägg till en Deny-sats i din S3-bucketpolicy som riktar sig mot s3:PutObject-förfrågningar där s3:x-amz-server-side-encryption-headern inte är inställd på aws:kms (för SSE-KMS) eller AES256 (för SSE-S3). Lägg till en andra Deny-sats med hjälp av villkoret aws:SecureTransport inställt på false för att blockera alla HTTP-förfrågningar (icke-TLS). Dessa två villkor tillsammans förhindrar både okrypterade uppladdningar och okrypterade anslutningar till bucketen.

Hur visas AWS S3-kryptering i CloudTrail-granskningsloggar?

SSE-KMS genererar en GenerateDataKey CloudTrail-händelse för varje PutObject och en Decrypt-händelse för varje GetObject. Varje händelse inkluderar KMS-nyckelns ARN, den begärande IAM-principalen, S3-bucket- och objektnyckeln, käll-IP och en tidsstämpel. SSE-S3 och SSE-C genererar inte KMS-händelser. Aktivera S3-datahändelser i CloudTrail separat från hanteringshändelser, eftersom S3-API-anrop på objektnivå inte registreras i hanteringshändelseloggar som standard.