Google Cloud Security – Gegevensversleuteling

Google Cloud- gegevensversleuteling is de reeks opties die GCP biedt om data in rust te beschermen in Cloud Storage, BigQuery, Compute Engine en meer dan 100 andere services. Dit is belangrijk omdat de standaard, door Google beheerde versleuteling geen onafhankelijke controle over sleutels biedt, geen auditlogboek per bewerking en geen mogelijkheid om de toegang van GCP tot uw gegevens in te trekken. Voor gereguleerde workloads wordt aanbevolen om Customer-Managed Encryption Keys (CMEK) te gebruiken via Cloud KMS, auditlogboeken voor gegevenstoegang in te schakelen en automatische sleutelrotatie te configureren volgens een schema dat is afgestemd op de compliance-eisen.

Kort antwoord: Welke Google Cloud-versleutelingsoptie moet je gebruiken?

Voor gereguleerde workloads (HIPAA, PCI DSS, FedRAMP, GDPR): gebruik CMEK (Customer-Managed Encryption Keys) via Cloud KMS. CMEK biedt u een sleutelbeleid dat u zelf beheert, Cloud Audit Logs per bewerking, de mogelijkheid om de sleutel onafhankelijk van Google uit te schakelen of te verwijderen, automatische sleutelrotatie en optionele FIPS 140-2 Level 3 hardwarebeveiliging via Cloud HSM. Voor niet-gereguleerde workloads waar eenvoud de prioriteit heeft: GMEK (Google-managed encryption) is voldoende en brengt geen extra kosten met zich mee. Voor workloads waarbij de sleutel nooit in de GCP-infrastructuur mag komen: gebruik client-side encryptie (HYOK) of Cloud External Key Manager (Cloud EKM). CSEK (Customer-Supplied Encryption Keys) is een verouderde optie die per API-aanroep werkt, maar operationeel complex is; CMEK is de betere keuze voor de meeste gebruikssituaties waarin u controle over de klantsleutel wilt hebben.

Key Takeaways

• Google Cloud versleutelt standaard alle data die niet in gebruik is: Elk object dat naar Cloud Storage wordt geüpload, wordt vóór het opslaan op de schijf versleuteld met AES-256, zonder extra kosten. Standaardversleuteling maakt gebruik van door Google beheerde sleutels (GMEK).
• Envelope-encryptie is het onderliggende mechanisme voor alle GCP-encryptieopties: De gegevens worden opgesplitst in stukken, die elk worden versleuteld met een unieke Data Encryption Key (DEK). De DEK wordt vervolgens versleuteld met een Key Encryption Key (KEK), die wordt beheerd door Google, door de klant wordt aangeleverd of wordt beheerd in Cloud KMS. De DEK's in onversleutelde vorm worden nooit opgeslagen.
• CMEK is de optie die aan de regelgeving voldoet: Door de klant beheerde encryptiesleutels in Cloud KMS bieden per bewerking cloudauditlogboeken, de mogelijkheid om sleutels onafhankelijk uit te schakelen en te verwijderen, automatische rotatie en BYOK via importtaken. GMEK biedt geen van deze functies.
• CSEK legt de verantwoordelijkheid voor het beheer van de belangrijkste zaken volledig bij de beller: U moet uw AES-256-sleutel bij elk API-verzoek meesturen. Google bewaart deze nooit permanent. Als u uw CSEK kwijtraakt, verliest u de toegang tot alle gegevens die ermee zijn versleuteld, en Google biedt geen mogelijkheid tot herstel.
• Client-side encryption (HYOK) is de enige optie die Google volledig uitsluit: Wanneer u gegevens versleutelt voordat u ze uploadt, slaat Google alleen de versleutelde tekst op en kan uw gegevens onder geen enkele omstandigheid worden ontsleuteld, zelfs niet in geval van een juridisch verzoek aan Google.

Hoe werkt Google Cloud Envelope Encryption?

Alle opties voor gegevensversleuteling in Google Cloud zijn gebaseerd op hetzelfde onderliggende mechanisme: envelopversleuteling. Inzicht in envelopversleuteling is essentieel om te begrijpen waarom de vier GCP-versleutelingsopties verschillen in hun beveiligings- en compliance-eigenschappen.

Wanneer gegevens naar Cloud Storage worden geüpload, verdeelt GCP deze in brokken (tot wel enkele GB per stuk). Voor elk brok genereert de interne cryptografische bibliotheek van Google (CrunchyCrypt) een unieke, eenmalige Data Encryption Key (DEK). De DEK versleutelt het brok met behulp van AES-256-GCM (Authenticated Encryption with Associated Data). De DEK wordt vervolgens versleuteld met een Key Encryption Key (KEK), wat resulteert in een versleutelde DEK. De versleutelde DEK wordt samen met het versleutelde brok opgeslagen in de gedistribueerde opslagsystemen van Google. De onversleutelde DEK wordt direct na de versleuteling uit het geheugen verwijderd; deze wordt nooit ergens permanent opgeslagen.

Om te decoderen: de KEK decodeert de versleutelde DEK om de onversleutelde DEK te herstellen. De onversleutelde DEK decodeert vervolgens het gegevensblok. De onversleutelde DEK wordt direct weer uit het geheugen verwijderd. De belangrijkste vraag bij alle vier de GCP-versleutelingsopties is: wie beheert de KEK? Die controle bepaalt uw controlemogelijkheden, uw mogelijkheden tot intrekking en uw soevereiniteit over de gegevens.

De vier opties voor gegevensversleuteling in de Google Cloud

Optie 1: Door Google beheerde versleutelingssleutels (GMEK)

GMEK is de standaardversleuteling. Wanneer u gegevens uploadt naar Cloud Storage zonder een andere versleutelingsoptie op te geven, genereert, beheert en roteert Google de KEK automatisch. De versleuteling vindt plaats op de opslaglaag voordat de gegevens naar de schijf worden geschreven. GMEK is gratis, vereist geen configuratie en er zijn geen wijzigingen in de applicatie nodig.

Wat GMEK u niet biedt: een onafhankelijk auditspoor voor individuele decryptiebewerkingen, de mogelijkheid om Googles toegang tot de KEK uit te schakelen, controle over de levenscyclus van de sleutel door de klant, of bewijs dat het sleutelmateriaal is gegenereerd op FIPS-gecertificeerde hardware. GMEK beschermt tegen diefstal van fysieke opslagmedia en Googles interne toegangscontroles bepalen wie de KEK mag gebruiken. GMEK is geschikt voor niet-gereguleerde, interne gegevens waarbij Googles eigen beveiligingsbeleid binnen uw vertrouwensgrens valt.

Optie 2: Door de klant aangeleverde encryptiesleutels (CSEK)

Met CSEK genereert u uw eigen symmetrische AES-256-sleutel en voegt u deze toe als header in elk Cloud Storage API-verzoek. Google gebruikt uw sleutel als KEK om de DEK voor die bewerking te versleutelen. Nadat de bewerking is voltooid, hasht Google uw sleutel (de hash wordt gebruikt om toekomstige verzoeken met dezelfde sleutel te valideren) en verwijdert de onversleutelde sleutel uit zijn systemen. Google bewaart uw CSEK nooit permanent.

De CSEK-versleutelingsworkflow voor een schrijfbewerking is als volgt:

1. Uw CSEK-nummer wordt samen met de gegevensupload in de API-aanvraagheader aan Cloud Storage doorgegeven.
2. Cloudopslag splitst de gegevens op in kleinere bestanden.
3. CrunchyCrypt genereert voor elk chunk een unieke, eenmalige DEK.
4. Elk deel wordt versleuteld met behulp van de DEK (AES-256-GCM).
5. Cloud Storage gebruikt uw CSEK als KEK en versleutelt elke DEK ermee.
6. De versleutelde DEK wordt samen met het bijbehorende versleutelde deel opgeslagen in cloudopslag.
7. De platte tekst DEK wordt uit het geheugen verwijderd.
8. Uw CSEK wordt gehasht en de onversleutelde CSEK wordt verwijderd uit de systemen van Google. De hash valideert toekomstige verzoeken, maar kan geen gegevens decoderen of de sleutel reconstrueren.

De CSEK-ontsleutelingsworkflow voor een leesbewerking is als volgt:

1. De client of applicatie vraagt ​​gegevens op bij Cloud Storage en voegt de CSEK toe in de aanvraagheader.
2. Cloudopslag identificeert de datablokken en haalt ze op.
3. Voor elk datablok haalt Cloud Storage de versleutelde DEK op en decodeert deze met behulp van de meegeleverde CSEK.
4. De DEK-code in platte tekst decodeert het gegevensblok.
5. De onversleutelde DEK wordt verwijderd en de onversleutelde gegevens worden teruggestuurd naar de client.

CSEK is van toepassing op: de objectgegevens, de checksum van het object en de hash van het object. Cloud Storage gebruikt standaard server-side sleutels om de resterende objectmetadata, inclusief de objectnaam, te versleutelen.

Operationele risico's van CSEK: U bent volledig verantwoordelijk voor het genereren, opslaan en aanleveren van uw CSEK voor elk lees- en schrijfverzoek. Als u uw CSEK kwijtraakt, kan Google deze niet herstellen en zijn alle gegevens die ermee zijn versleuteld permanent ontoegankelijk. CSEK wordt niet opgeslagen in Cloud KMS en genereert geen auditlogboekvermeldingen in Cloud KMS. U moet uw eigen infrastructuur voor sleutelbeheer en back-up van CSEK's opzetten.

Optie 3: Klantbeheerde encryptiesleutels (CMEK) via Cloud KMS

CMEK is de versleutelingsoptie van compliance-kwaliteit voor GCP. U maakt en beheert een versleutelingssleutel in Cloud KMS (Key Management Service) en configureert de GCP-service (een Cloud Storage-bucket, een BigQuery-dataset, een Compute Engine-schijf, een Cloud Pub/Sub-topic) om die Cloud KMS-sleutel als KEK te gebruiken. Wanneer er gegevens naar de service worden geschreven, roept deze Cloud KMS aan om de DEK te versleutelen. Wanneer er gegevens worden gelezen, roept deze Cloud KMS aan om de DEK te ontsleutelen.

De CMEK-versleutelingsworkflow voor een schrijfbewerking is als volgt:

1. De gegevens worden geüpload naar de GCP-service (Cloud Storage-bucket, BigQuery-tabel, enz.).
2. De dienst splitst de gegevens op in kleinere bestanden.
3. CrunchyCrypt genereert voor elk chunk een unieke, eenmalige DEK.
4. Elk deel wordt versleuteld met behulp van de bijbehorende DEK.
5. De service stuurt elke DEK naar Cloud KMS en specificeert de CMEK-sleutelresource die als KEK moet worden gebruikt.
6. Cloud KMS versleutelt de DEK met behulp van de opgegeven CMEK-sleutel en retourneert de versleutelde DEK.
7. De versleutelde DEK wordt samen met het bijbehorende versleutelde deel opgeslagen.
8. De platte tekst DEK wordt uit het geheugen verwijderd.

De CMEK-ontsleutelingsworkflow voor een leesbewerking is als volgt:

1. Er komt een leesverzoek binnen voor de versleutelde gegevens.
2. De service haalt de versleutelde brokken en hun versleutelde DEK's op.
3. De service stuurt elke versleutelde DEK naar Cloud KMS voor decryptie, waarbij de CMEK-sleutel wordt opgegeven.
4. Cloud KMS decodeert elke DEK met behulp van de CMEK-sleutel en retourneert de DEK in platte tekst.
5. De dienst gebruikt elke platte tekst DEK om het bijbehorende deel te decoderen.
6. De onversleutelde DEK wordt verwijderd en de onversleutelde gegevens worden teruggestuurd naar de client.

Wat CMEK biedt en GMEK en CSEK niet: Elke Cloud KMS-versleutelings- en ontsleutelingsaanroep genereert een Cloud Audit Log-item (wanneer gegevenstoegangslogboekregistratie is ingeschakeld) met daarin de aanvragende service, de gebruikte sleutelversie, het tijdstempel en de oorspronkelijke identiteit. U kunt de CMEK-sleutel in Cloud KMS uitschakelen om onmiddellijk te voorkomen dat er nog verdere versleutelings- of ontsleutelingsbewerkingen worden uitgevoerd op alle gegevens die door die sleutel worden beschermd, in alle GCP-services die deze gebruiken. U kunt automatische sleutelrotatie configureren volgens een schema (minimaal 24 uur; jaarlijks is de gebruikelijke compliance-basislijn). U kunt Cloud HSM-ondersteunde sleutels gebruiken voor FIPS 140-2 Level 3 hardwarebeveiliging van de KEK. U kunt uw eigen sleutelmateriaal (BYOK) importeren via Cloud KMS-importtaken. Al deze mogelijkheden ontbreken in GMEK en CSEK.

CMEK-prijzen: Cloud KMS-sleutels kosten $ 0.06 per actieve sleutelversie per maand voor softwarebeveiligde sleutels en $ 2.50 per actieve sleutelversie per maand voor HSM-beveiligde sleutels. Cryptografische bewerkingen (versleutelings- en ontsleutelingsaanroepen van GCP-services) kosten $ 0.03 per 10,000 bewerkingen. Werkbelastingen met een hoog volume en frequente lees- en schrijfbewerkingen van objecten kunnen aanzienlijke kosten met zich meebrengen voor KMS API-aanroepen; zie het gedeelte over kostenoptimalisatie hieronder.

Optie 4: Client-side encryptie (HYOK)

Client-side encryptie, ook wel HYOK (Hold Your Own Key) genoemd, houdt in dat uw applicatie of datapipeline gegevens versleutelt voordat deze naar een GCP-service worden verzonden. Wat bij Cloud Storage of een andere GCP-service aankomt, is al versleuteld. Google slaat alleen versleutelde gegevens op en heeft onder geen enkele omstandigheid toegang tot de onversleutelde gegevens of de encryptiesleutel, zelfs niet in geval van een juridisch verzoek aan Google.

Wanneer cloudopslag client-side versleutelde gegevens ontvangt, wordt de server-side versleutelingslaag (Google's GMEK-laag) er nog steeds bovenop toegepast. Bij het ophalen van gegevens verwijdert cloudopslag de server-side laag, maar de client-side laag blijft behouden. Uw applicatie moet de client-side laag ontsleutelen met behulp van de sleutel die extern wordt beheerd.

Client-side encryptie is geschikt voor geclassificeerde gegevens, gegevens die onder de vereisten van gegevenssoevereiniteit vallen waarbij de GCP-infrastructuur zich buiten uw vertrouwensgebied bevindt, of workloads waarbij uw dreigingsmodel Google als potentieel toegangspunt omvat. De operationele kosten: elke lees- en schrijfbewerking vereist een aanroep naar uw externe sleutelbeheersysteem, dat een hoge beschikbaarheid moet hebben. HSM as a Service van Encryption Consulting biedt de externe FIPS 140-2 Level 3-sleutelbeheerinfrastructuur die nodig is voor client-side encryptie-implementaties op GCP.

GCP ondersteunt ook Cloud External Key Manager (Cloud EKM) als een HYOK-optie voor CMEK-geïntegreerde services. Met Cloud EKM wordt de CMEK-sleutel bewaard in uw externe sleutelbeheersysteem. Wanneer GCP een DEK moet versleutelen of ontsleutelen, roept het uw externe KMS aan via een TLS-verifieerde verbinding in plaats van een sleutel te gebruiken die is opgeslagen in Cloud KMS. Dit maakt HYOK-soevereiniteit mogelijk, terwijl de CMEK-integratiepunten van GCP-services zoals BigQuery en Cloud Spanner behouden blijven.

Een vergelijking van de vier GCP-versleutelingsopties

Afmeting	GMEK (beheerd door Google)	CSEK (door de klant geleverd)	CMEK (klantbeheer via Cloud KMS)	Clientzijde / HYOK
Wie heeft de controle over de KEK?	Google	Klant (op verzoek)	Klant (via Cloud KMS)	Klant (buiten GCP)
Sleutel opgeslagen in GCP	Ja (beheerd door Google)	Nee (alleen hash, geen platte tekst)	Ja (in Cloud KMS)	Nee
Google heeft tijdens het gebruik toegang tot KEK.	Ja	Ja (alleen tijdens gebruik)	Ja (binnen de HSM-grens)	Nee
Auditlogboeken van de cloud per bewerking	Nee	Nee	Ja (wanneer gegevensregistratie is ingeschakeld)	Alleen van externe KMS
Onafhankelijke sleutel uitschakelen/intrekken	Nee	Nee (verwijder je eigen kopie)	Ja (uitschakelen in Cloud KMS)	Ja (intrekken bij extern KMS)
Automatische sleutelrotatie	Ja (Google-schema)	Nee (volledig handmatig)	Ja (instelbaar schema)	Door de klant beheerd
BYOK-ondersteuning	Nee	Ja (u levert de sleutel aan)	Ja (via Cloud KMS-importtaken)	Ja (je eigen sleutel blijft de hele tijd van kracht)
FIPS 140-2 Level 3 hardware	Nee	Nee	Ja (met Cloud HSM-beveiligingsniveau)	Afhankelijk van externe KMS
Bijkomende kosten	Geen	Geen (het sleutelbeheer is van jou)	$0.06 tot $2.50 per sleutelversie per maand + $0.03 per 10 transacties	Externe KMS-kosten
Best voor	Niet-gereguleerde, interne gegevens	Verouderde sleutelbesturing per object	Gereguleerde werkzaamheden: HIPAA, PCI DSS, FedRAMP, GDPR	Geheim, soevereiniteitsbevel, nultrust

BYOK in Google Cloud: Cloud KMS-importtaken

BYOK (Bring Your Own Key) in Google Cloud betekent dat je AES-256-sleutelmateriaal buiten GCP genereert en dit importeert in Cloud KMS als een door de klant beheerde sleutel. Eenmaal geïmporteerd, functioneert de sleutel identiek aan een door Cloud KMS gegenereerde CMEK: GCP-services kunnen deze gebruiken als de KEK, er worden Cloud Audit Log-vermeldingen gegenereerd, automatische rotatieplanning wordt ondersteund en de sleutel kan onafhankelijk worden uitgeschakeld of verwijderd.

Het Cloud KMS-importproces werkt als volgt: Maak een Cloud KMS-importtaak aan voor de betreffende sleutelring en specificeer het versleutelingsalgoritme (RSA_OAEP_3072_SHA256 of AES_256_KWP). Download de versleutelingssleutel van de importtaak. Genereer uw 256-bits AES-sleutelmateriaal in uw eigen HSM of sleutelbeheersysteem. Versleutel uw sleutelmateriaal met behulp van de gedownloade versleutelingssleutel. Upload het versleutelde sleutelmateriaal naar de importtaak via de Cloud KMS API. Cloud KMS ontsleutelt uw sleutelmateriaal in het HSM-cluster (indien het beoogde beveiligingsniveau HSM is) en slaat het op als een Cloud KMS-sleutelversie.

Belangrijke beperkingen voor BYOK-sleutels in Cloud KMS: automatische rotatie is niet beschikbaar voor sleutels met geïmporteerd materiaal (Cloud KMS kan geen nieuwe versies genereren van extern gegenereerd sleutelmateriaal). U moet de rotatie handmatig beheren door extern nieuw sleutelmateriaal te genereren, een nieuwe importtaak aan te maken, het nieuwe materiaal als een nieuwe sleutelversie te importeren en deze als de primaire versie aan te wijzen. U kunt een vervaldatum instellen voor geïmporteerd sleutelmateriaal, waarna Cloud KMS het automatisch verwijdert en de sleutel onbruikbaar wordt voor nieuwe bewerkingen.

IAM-model voor toegangscontrole tot Google Cloud-versleuteling

Toegangsbeheer voor GCP-versleutelingsbewerkingen werkt via Google Cloud IAM, toegepast op zowel het GCP-serviceniveau (wie objecten in Cloud Storage kan lezen of schrijven) als het Cloud KMS-sleutelniveau (wie de CMEK-sleutel kan gebruiken om te versleutelen of te ontsleutelen). Dit zijn afzonderlijke toegangsgrenzen die beide correct geconfigureerd moeten zijn.

Cloud Storage IAM (serviceniveau): Hiermee bepaalt u wie objecten in een Cloud Storage-bucket kan lezen, schrijven, weergeven en verwijderen. De standaardrollen zijn Storage Admin (volledige controle), Storage Object Admin (CRUD-bewerkingen op objecten), Storage Object Creator (alleen schrijven) en Storage Object Viewer (alleen lezen). Pas het principe van minimale bevoegdheden toe: accounts voor analyseservices hebben Storage Object Viewer nodig, niet Storage Object Admin. Ingestiepipelines hebben Storage Object Creator nodig, niet Storage Admin.

Cloud KMS IAM (sleutelniveau): Bepaalt wie de CMEK-sleutel mag beheren en gebruiken. Drie verschillende rollen: Cloud KMS-beheerder (roles/cloudkms.admin) kan sleutelbeleid aanmaken, verwijderen en beheren, maar kan geen sleutels gebruiken voor cryptografische bewerkingen. Cloud KMS Crypto Key Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) kan versleutelen en ontsleutelen met behulp van de sleutel, maar kan deze niet beheren. Cloud KMS Viewer (roles/cloudkms.viewer) kunnen belangrijke metadata bekijken. Het serviceaccount dat door Cloud Storage wordt gebruikt om KMS aan te roepen, moet de rol Versleutelaar/Ontsleutelaar hebben voor de specifieke CMEK-sleutel; dit staat los van elke menselijke of applicatie-identiteit die gegevens leest.

Kernprincipe: het serviceaccount dat gegevens uit Cloud Storage leest, mag geen Cloud KMS-beheerdersrechten hebben. Een serviceaccount voor analisten met rechten om objecten uit Storage te bekijken, kan objecten lezen uit een met CMEK versleutelde bucket, maar heeft geen (en mag geen) Cloud KMS-cryptografische sleutelbeheerrechten. De Cloud KMS-versleutelaar/ontsleutelaar wordt automatisch door de Cloud Storage-service namens de leesbewerking aangeroepen met behulp van een door Google beheerde serviceagent, en niet door de identiteit van de gebruiker.

Beperkingen vanuit het organisatiebeleid: Gebruik constraints/gcp.restrictCloudKmsKeyLocations om ervoor te zorgen dat CMEK-sleutels alleen in goedgekeurde GCP-regio's kunnen worden aangemaakt (vanwege de vereisten voor gegevensopslag). Gebruik constraints/gcp.restrictNonCmekServices Om te vereisen dat specifieke GCP-services altijd CMEK gebruiken en niet kunnen terugvallen op GMEK. Deze beperkingen op organisatieniveau bieden een beleidsrichtlijn die van toepassing is op alle projecten binnen het toepassingsgebied en vormen een aanvulling op de IAM-configuraties per project.

Sleutelrotatie voor GCP CMEK-sleutels

Automatische sleutelrotatie voor CMEK-sleutels in Cloud KMS genereert een nieuwe sleutelversie volgens het geconfigureerde schema, zonder dat er wijzigingen nodig zijn in de GCP-services die de sleutel gebruiken. De nieuwe versie wordt de primaire versie voor alle nieuwe versleutelingsbewerkingen. Eerdere versies blijven ingeschakeld en kunnen nog steeds gegevens ontsleutelen die met die versies zijn versleuteld. De naam van de sleutelresource (sleutelringpad, sleutelnaam) blijft hetzelfde; de ​​rotatie is transparant voor applicaties en datapijplijnen.

De rotatieperioden kunnen worden geconfigureerd met een minimum van 24 uur. Voor de meeste compliance-frameworks is de aanbevolen rotatieperiode 90 dagen (in lijn met de PCI DSS-vereiste 3.7.4-richtlijnen voor symmetrische sleutelcryptografieperioden voor waardevolle sleutels) of jaarlijks voor standaard gereguleerde workloads. Elke rotatie genereert een gebeurtenis voor het aanmaken van een sleutelversie in de cloudauditlogboeken.

Het vernietigen van sleutelversies in Cloud KMS heeft een verplichte minimale geplande verwijderingsperiode van 24 uur (configureerbaar tot 120 dagen). Gedurende deze periode kan de vernietiging worden geannuleerd. Zodra de geplande tijd is verstreken, worden de sleutelversie en het bijbehorende materiaal permanent vernietigd. Het plannen van de vernietiging van een CMEK-sleutelversie genereert direct een Cloud Audit Log Admin Activity-gebeurtenis, waardoor beveiligingsteams de mogelijkheid hebben om onbedoelde of ongeautoriseerde vernietiging te detecteren en te annuleren voordat deze onomkeerbaar is.

Cloudauditlogboeken voor GCP-gegevensversleuteling

Google Cloud Audit Logs registreert de beveiligingsrelevante gebeurtenissen voor zowel Cloud Storage als Cloud KMS. Het inschakelen en correct routeren van deze logboeken is een compliancevereiste volgens PCI DSS-vereiste 10, de HIPAA-auditcontrolestandaard (45 CFR 164.312(b)) en FedRAMP AU-controles.

Auditlogboeken voor cloudopslag: Logboeken voor gegevenstoegang in cloudopslag leggen lees- (storage.objects.get) en schrijfbewerkingen (storage.objects.create, storage.objects.update, storage.objects.delete) van objecten vast. Deze logboeken moeten expliciet worden ingeschakeld op project- of organisatieniveau; ze zijn niet standaard ingeschakeld. Eenmaal ingeschakeld, registreert elke bewerking op objectniveau de aanvragende identiteit, de bucket- en objectnaam, het tijdstempel en het bron-IP-adres.

Auditlogboeken van Cloud KMS: Logboeken van beheerdersactiviteiten (altijd actief, kunnen niet worden uitgeschakeld) registreren het aanmaken van sleutels, het plannen van het aanmaken en verwijderen van sleutelversies, updates van sleutelbeleid en gebeurtenissen met betrekking tot importtaken. Logboeken voor gegevenstoegang voor Cloud KMS (moeten expliciet worden ingeschakeld) registreren elke versleutelings- en ontsleutelingsoproep die door GCP-services wordt gedaan met behulp van uw CMEK-sleutel, inclusief het aanvragende serviceaccount, de ARN van de sleutelversie en het tijdstempel. Deze KMS-logboeken per bewerking vormen het auditspoor dat aantoont wie op welk tijdstip toegang had tot welke gegevens, wat het bewijsmateriaal is dat vereist is door HIPAA-, PCI DSS- en FedRAMP-auditors.

Routeer cloudauditlogboeken naar cloudlogging (standaard) en exporteer ze bovendien naar een cloudopslagbucket in een apart, tegen schrijven beveiligd project voor langdurige bewaring. PCI DSS vereist een bewaartermijn van 12 maanden voor logboeken, waarvan 3 maanden direct beschikbaar zijn. Configureer op logboeken gebaseerde waarschuwingen in Cloud Monitoring voor: elke geplande vernietiging van een CMEK-sleutelversie op een productiesleutel; elke wijziging van de IAM-binding op een CMEK-sleutelring of -sleutel; elke decryptiebewerking vanuit een serviceaccount dat niet in de lijst met goedgekeurde rollen voor die sleutel staat; en elke toegang tot cloudopslaggegevens vanuit een onverwachte principal of geografische locatie.

Kostenoptimalisatie voor GCP-gegevensversleuteling

GMEK brengt geen extra kosten met zich mee. CSEK heeft geen kosten voor Cloud KMS (het beheer van de sleutels ligt bij u). CMEK heeft twee kostencomponenten: opslag van sleutelversies en aanroepen van cryptografische bewerkingen.

Softwarematig beveiligde CMEK-sleutelversies kosten $ 0.06 per actieve versie per maand. HSM-beveiligde sleutelversies kosten $ 2.50 per actieve versie per maand. Cryptografische bewerkingen (versleutelings- en ontsleutelingsaanroepen van GCP-services naar Cloud KMS) kosten $ 0.03 per 10,000 bewerkingen voor symmetrische sleutels. Bij een hoog aanvraagvolume lopen de kosten per bewerking snel op. Een Cloud Storage-bucket die 10 miljoen objectschrijf- en leesbewerkingen per maand ontvangt, genereert 20 miljoen Cloud KMS API-aanroepen, wat neerkomt op ongeveer $ 60 per maand aan KMS API-kosten voor die bucket alleen.

Cloud KMS heeft geen equivalent van de S3 Bucket Key-functie van AWS KMS. Voor GCP-workloads met een hoog volume, waarbij KMS-aanroepen per object kostbaar zijn, kunt u DEK-caching op applicatieniveau overwegen: haal de DEK in platte tekst eenmaal per sessie of tijdsvenster op uit Cloud KMS en gebruik deze lokaal voor meerdere versleutelings- en ontsleutelingsbewerkingen. Het nadeel is dat de DEK in platte tekst gedurende de cacheduur in het applicatiegeheugen wordt bewaard. Voor workloads die gebruikmaken van BigQuery, Cloud Storage met Autoclass of Cloud Spanner, is het aantal KMS-aanroepen per bewerking afhankelijk van het toegangspatroon en kan dit vóór de implementatie worden gemodelleerd om de maandelijkse kosten te schatten.

GCP-encryptie in multi-cloud- en hybride architecturen

Cloud KMS is een GCP-native service. CMEK-sleutels die in Cloud KMS worden aangemaakt, kunnen niet rechtstreeks worden gebruikt om gegevens te beschermen die zijn opgeslagen in AWS S3 of Azure Blob Storage. Organisaties die werken met multi-cloudarchitecturen hebben een expliciete strategie nodig voor consistent sleutelbeheer tussen providers. Drie patronen komen vaak voor:

• Per-cloud native KMS met gecentraliseerd beheer: Gebruik Cloud KMS CMEK voor GCP-workloads, AWS KMS voor AWS-workloads en Azure Key Vault voor Azure-workloads. Implementeer een gecentraliseerd platform voor sleutellevenscyclusbeheer dat de sleutelinventaris, rotatiestatus en auditlogboeken van alle drie de providers samenvoegt. De gegevens van elke cloud worden beschermd door het native KMS van die cloud; de governance-laag biedt inzicht in alle clouds en verzamelt bewijsmateriaal voor naleving zonder vertraging te veroorzaken bij cryptografische bewerkingen.
• Gecentraliseerde BYOK vanuit een externe HSM: Genereer al het sleutelmateriaal vanuit één externe HSM of een HSM-as-a-Service van een derde partij die onafhankelijk is van alle cloudproviders. Importeer de afgeleide sleutels in Cloud KMS als BYOK-sleutels voor GCP-workloads, in AWS KMS voor AWS-workloads en in Azure Key Vault voor Azure-workloads. Alle encryptie is terug te voeren op één gezaghebbende sleutelbron. Encryption Consulting's HSM als een service Biedt de externe FIPS 140-2 Level 3 HSM-infrastructuur voor dit model, die gelijktijdig toegankelijk is vanuit GCP, AWS en Azure.
• Client-side encryptie met een gedeelde sleutel (HYOK in alle clouds): Versleutel gegevens op applicatie- of pipelineniveau voordat ze een cloudprovider bereiken. Dezelfde client-side versleutelingsbibliotheek en hoofdsleutel worden gebruikt, ongeacht de bestemmingscloud. GCP, AWS en Azure slaan elk alleen versleutelde gegevens op. Dit biedt de sterkste intercloudsoevereiniteit, maar vereist dat applicaties alle cryptografische bewerkingen afhandelen en dat uw externe sleutelbeheersysteem een ​​hoge beschikbaarheid heeft voor alle cloudworkloads. Zie onze handleiding over Cloud Data Lake-beveiliging voor hoe dit patroon van toepassing is op multi-cloud data lake-architecturen.

Compliance: PCI DSS, HIPAA, FedRAMP en GDPR

PCI DSS v4.0.1 (verplicht sinds 31 maart 2025): CMEK met Cloud KMS voldoet aan vereiste 3.5.1 (bescherming van opgeslagen kaartgegevens met behulp van sterke cryptografie) voor GCP-services die PAN's opslaan. Wanneer het Cloud HSM-beveiligingsniveau wordt gebruikt voor de CMEK-sleutel, wordt ook voldaan aan vereiste 3.7.1 (sleutelgeneratie met behulp van een HSM of een algemeen aanvaarde technologie). Gegevenstoegangsgebeurtenissen in de Cloud Audit Logs voor Cloud KMS voldoen aan vereiste 10 (registratie en monitoring van toegang tot kaartgegevens). GMEK alleen voldoet niet aan PCI DSS omdat het geen auditlogboek per bewerking en geen controle over de klantsleutel biedt.

HIPAA: CMEK met Cloud KMS voldoet aan de HIPAA-technische beveiliging voor encryptie en decryptie (45 CFR 164.312(a)(2)(iv)) voor ePHI in rust in GCP-services. De Business Associate Agreement (BAA) van Google dekt Cloud KMS en Cloud Storage, waardoor deze geschikt zijn voor ePHI-workloads. Gegevenstoegangsgebeurtenissen in de Cloud Audit Logs voor Cloud KMS en Cloud Storage voldoen aan de HIPAA-auditcontrolenorm (45 CFR 164.312(b)).

FedRAMP: Google Cloud-services, waaronder Cloud KMS en Cloud Storage, zijn geautoriseerd onder FedRAMP High. Cloud KMS met Cloud HSM-beveiligingsniveau (FIPS 140-2 Niveau 3) voldoet aan de FedRAMP High-vereiste voor gevalideerde cryptografische modules volgens NIST SP 800-53 Rev. 5 SC-12 (Cryptographic Key Establishment and Management) en SC-28 (Protection of Information at Rest). GMEK (zonder HSM-ondersteunde CMEK) voldoet niet aan de FedRAMP High-vereiste voor FIPS 140-2 Niveau 3. Raadpleeg onze speciale handleiding over Google Cloud HSM voor de volledige FIPS 140-2 Niveau 3-architectuur.

GDPR: CMEK ondersteunt de naleving van de rechten van betrokkenen in het kader van de GDPR door het intrekken van toegang tot gegevens op basis van sleutels mogelijk te maken. Door een CMEK-sleutel uit te schakelen, worden alle met die sleutel versleutelde gegevens ontoegankelijk voor iedereen, inclusief Google. Dit kan dienen als een technische implementatie van het recht op verwijdering voor gegevens die anders niet selectief kunnen worden verwijderd (bijvoorbeeld in onveranderlijke logbestanden). CMEK voldoet aan de GDPR-vereiste voor passende technische en organisatorische maatregelen (artikel 32) met toegangscontrole, auditregistratie en rotatie. CSEK kan ook voldoen aan de GDPR-vereiste voor technische maatregelen, maar mist de audit trail- en governance-eigenschappen van CMEK.

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 selecteren, ontwerpen en implementeren van de juiste Google Cloud-encryptiearchitectuur die voldoet aan hun compliance-eisen, van de eerste optieselectie tot het genereren van auditbewijs.

• Ontwerp van de GCP-encryptiearchitectuur: We koppelen uw GCP-workloads aan de juiste versleutelingsoptie (GMEK, CMEK, CSEK of client-side), ontwerpen de CMEK-sleutelhiërarchie per service en dataclassificatiezone, configureren IAM met scheiding van sleutelbeheerder en sleutelgebruiker, dwingen CMEK af via beperkingen in organisatiebeleid en ontwerpen de routering van cloudauditlogboeken voor bewijs van naleving. Zie onze cloudgegevensbeschermingsdiensten.
• HSM als service voor BYOK en HYOK: Voor BYOK-implementaties die FIPS 140-2 Level 3-sleutelgeneratie buiten GCP vereisen, of voor client-side encryptiearchitecturen die een extern sleutelbeheersysteem vereisen, biedt Encryption Consulting de volgende oplossingen: HSM als een service Biedt een speciale HSM-infrastructuur die toegankelijk is vanuit GCP-workloads. BYOK-sleutels die in de HSM as a Service worden gegenereerd, kunnen via importtaken in Cloud KMS worden geïmporteerd; HYOK-sleutels blijven in de HSM as a Service en worden door uw applicatie of door Cloud EKM voor elke bewerking aangeroepen.
• CBOM Secure voor GCP-versleuteling: GCP-omgevingen met veel projecten hebben vaak inconsistente encryptieconfiguraties: sommige Cloud Storage-buckets gebruiken GMEK, andere CMEK, en bij weer andere is data-toegangslogging niet ingeschakeld. Encryption Consulting biedt een oplossing voor dit probleem. CBOM Secure Ontdekt en inventariseert alle Cloud KMS-sleutelconfiguraties, Cloud Storage-versleutelingsinstellingen en IAM-beleidsbindingen in GCP-projecten en genereert een cryptografische materiaallijst (CBOM) in CycloneDX-formaat die buckets identificeert die geen CMEK gebruiken, sleutels zonder rotatieschema's en te ruime IAM-bindingen op sleutelringen.
• Advies over naleving van PCI DSS en HIPAA: We brengen uw GCP-encryptieconfiguratie in kaart en stemmen deze af op de specifieke vereisten van PCI DSS v4.0.1, HIPAA Technical Safeguards, FedRAMP en GDPR. We identificeren hiaten in de controle, stellen het compliance-bewijspakket samen en ondersteunen u bij vragen van QSA's en auditors. Bekijk onze Nalevingsadviesdiensten.
• PQC-gereedheid voor GCP-werkbelastingen: 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. De post-kwantumroadmap van Google Cloud voor asymmetrische sleuteltypen in Cloud KMS is in ontwikkeling. Encryption Consulting's PQC-gereedheid Deze service brengt uw GCP-encryptiesleutelportfolio in kaart ten opzichte van de migratietijdlijn na de quantumovergang en ontwerpt de overgangssequentie voor asymmetrische sleutels die worden gebruikt voor ondertekening en sleuteluitwisseling in GCP-workloads.

Neem contact op met Encryption Consulting om uw GCP-encryptiearchitectuur of compliancevereisten te bespreken.

Conclusie

Google Cloud versleutelt standaard alle data in rust, maar de standaard GMEK-versleuteling is niet hetzelfde als conforme versleuteling. De conforme optie is CMEK via Cloud KMS, die een auditlogboek, onafhankelijk sleutelbeheer, een rotatieschema en een FIPS 140-2 Level 3-hardwareoptie toevoegt, zoals vereist voor gereguleerde workloads. CSEK is een optie op aanvraag waarbij de sleutel volledig buiten GCP blijft, maar de volledige verantwoordelijkheid voor het sleutelbeheer bij de gebruiker ligt. Client-side versleuteling en Cloud EKM zijn de opties voor workloads waarbij Google absoluut geen toegang mag hebben tot de versleutelingssleutel.

De meest voorkomende foutieve configuratie van GCP-encryptie is het gebruik van GMEK voor gegevens die volgens wettelijke voorschriften onder klantsleutelbeheer moeten vallen, zonder te beseffen dat GMEK geen auditlogboek per bewerking en geen onafhankelijke mogelijkheid tot sleutelintrekking biedt. Het correct selecteren van de encryptieoptie tijdens de serviceconfiguratie is aanzienlijk eenvoudiger dan het achteraf implementeren van CMEK in een reeds geïmplementeerde omgeving waar honderden buckets, datasets en schijven al GMEK gebruiken.

Veelgestelde Vragen / FAQ

Welke opties voor gegevensversleuteling zijn er in Google Cloud?

Google Cloud biedt vier opties: door Google beheerde encryptiesleutels (GMEK, de standaardoptie zonder extra kosten), door de klant aangeleverde encryptiesleutels (CSEK, waarbij u uw AES-256-sleutel per API-aanvraag aanlevert en Google deze nooit permanent opslaat), door de klant beheerde encryptiesleutels (CMEK via Cloud KMS, waarbij u de sleutel beheert in Cloud KMS en GCP-services configureert om deze te gebruiken) en client-side encryptie (HYOK, waarbij u gegevens versleutelt voordat u ze uploadt, zodat Google alleen de versleutelde tekst opslaat). CMEK is de juiste keuze voor gereguleerde workloads die een audit trail en onafhankelijke sleutelcontrole vereisen.

Wat is envelopversleuteling in Google Cloud?

Envelope-encryptie is de belangrijkste hiërarchie die GCP gebruikt voor alle encryptieopties. Gegevens worden opgesplitst in brokken; elk brok wordt versleuteld met een unieke Data Encryption Key (DEK) die wordt gegenereerd door Google's CrunchyCrypt-bibliotheek. De DEK wordt vervolgens versleuteld met een Key Encryption Key (KEK), die ofwel door Google wordt beheerd (GMEK), door de klant wordt aangeleverd (CSEK), of door de klant wordt beheerd in Cloud KMS (CMEK). De versleutelde DEK wordt samen met het versleutelde brok opgeslagen. De onversleutelde DEK wordt direct na gebruik uit het geheugen verwijderd en nooit permanent bewaard.

Wat is het verschil tussen CSEK en CMEK in Google Cloud?

CSEK vereist dat u uw AES-256-sleutel bij elk API-verzoek meestuurt; Google gebruikt deze alleen voor die specifieke bewerking, hasht deze en verwijdert deze. CMEK houdt in dat u een sleutel aanmaakt en beheert in Cloud KMS en GCP-services configureert om deze als KEK te gebruiken. CMEK biedt automatische rotatie, Cloud Audit Logs per bewerking (wanneer Data Access logging is ingeschakeld), de mogelijkheid om de sleutel direct uit te schakelen en Cloud HSM-integratie voor FIPS 140-2 Level 3 hardwarebeveiliging. CSEK biedt geen van deze mogelijkheden en legt de volledige verantwoordelijkheid voor het sleutelbeheer bij uw infrastructuur.

Hoe implementeer ik BYOK in Google Cloud?

BYOK in Google Cloud maakt gebruik van Cloud KMS-importtaken. Maak een importtaak aan voor uw doelsleutelring en download de versleutelde sleutel. Genereer uw AES-256-sleutelmateriaal in uw eigen HSM. Versleutel uw sleutelmateriaal met de gedownloade versleutelde sleutel. Upload het versleutelde materiaal naar Cloud KMS via de importtaak. De geïmporteerde sleutel wordt een CMEK-sleutel die door GCP-services wordt gebruikt. U behoudt het originele sleutelmateriaal in uw HSM en kunt de geïmporteerde kopie uit Cloud KMS verwijderen om GCP onmiddellijk de mogelijkheid te ontnemen deze te gebruiken.

Voldoet de encryptie van Google Cloud aan de HIPAA- en PCI DSS-vereisten?

CMEK via Cloud KMS voldoet aan beide vereisten wanneer correct geconfigureerd. Voor HIPAA voldoet CMEK aan de vereiste voor encryptie in rust (45 CFR 164.312(a)(2)(iv)) en voldoen Cloud Audit Logs aan de Audit Control-standaard (164.312(b)). De BAA van Google moet van kracht zijn. Voor PCI DSS v4.0.1 voldoet CMEK met Cloud HSM-bescherming aan vereiste 3.5.1 (sterke cryptografie voor opgeslagen PAN's) en vereiste 3.7.1 (HSM-sleutelgeneratie). Cloud Audit Logs voldoen aan vereiste 10. GMEK alleen voldoet aan geen van beide compliance-vereisten van de frameworks.

Hoe werkt sleutelrotatie in Google Cloud KMS voor versleutelde gegevens?

Automatische rotatie van een Cloud KMS CMEK-sleutel genereert een nieuwe sleutelversie volgens het geconfigureerde schema (minimaal 24 uur; jaarlijks is de gebruikelijke nalevingsnorm). De nieuwe versie wordt de primaire versie voor nieuwe versleutelingsbewerkingen. Eerdere versies blijven ingeschakeld voor het ontsleutelen van oudere gegevens. U hoeft bestaande Cloud Storage-objecten of BigQuery-gegevens niet opnieuw te versleutelen om de rotatie te voltooien. Voor BYOK-sleutels met geïmporteerd materiaal is automatische rotatie niet beschikbaar; u moet handmatig nieuw sleutelmateriaal genereren, dit importeren als een nieuwe sleutelversie en dit aanwijzen als de primaire versie.