1

For some time now, we have been assessing the risks from a GDPR perspective when data (data-at-rest) in the Google Cloud is fully encrypted using native means. This means that we create both the KEK and the DEK completely with Google Cloud KMS and encrypt the storage buckets with it.

Also, we are not currently subject to any regulatory requirements that enforce separation based on CSEK or CMEK.

It would help me a lot if people could share their experience in this area.

schroeder
  • 123,438
  • 55
  • 284
  • 319
rsfeed
  • 9
  • 1
  • 3
    Encrypted PII is still PII, since it can be decrypted. A legal advice forum would probably be a better fit, but AFAIK (I'm not a lawyer) the GDPR cares about whether stored data can be attributed to a person by any means, including decryption or practical de-anonymization. – SAI Peregrinus Sep 02 '22 at 16:32
  • What's your question? – schroeder Sep 04 '22 at 13:59
  • 1
    I agree with SAI, the fact that it is encrypted falls under the "reasonable protections" section of the GDPR ("good, you protected it") but apart from that, how it is encrypted doesn't change anything. It's still PII. From a GDPR perspective, what are you doing with it? How long do you keep it? Do you have permission to process and store it? – schroeder Sep 04 '22 at 14:07

1 Answers1

-1

The point is, during my CCSP certification, almost everywhere in the documentation and any other material there was the recommendation never to store keys in a public cloud KMS. There are few blogs that analyze the technologies used, BYOK or CMEK/CSEK could never provide privacy. In fact, no documentation from the CSP specifies exactly what the process looks like. No CSP is completely transparent, and in the end there is no certainty as to how many keys are used to protect the DEK. At Google, there is no way to create a "security world" with the help of HSM or to use dedicated HSM. Nor is it clear how to check the DEK, the BYOK and CMEK are primarily for the KEK. If this is the case, there is no way to store personal data in a public cloud and meet the GDPR

rsfeed
  • 9
  • 1
  • That's a complete oversimplification of a conclusion and lacks the required context. You simply cannot make that conclusion about GDPR. The only point to make is "is it best practice?" That's it. – schroeder Sep 05 '22 at 08:27
  • This also doesn't "answer the question". This looks like you've set this up as a discussion, but this is a Q&A site. We need a question, which you didn't provide. And this is not an answer to "risk scenarios"; this is instead an opinion on compliance. – schroeder Sep 05 '22 at 08:32
  • This is indeed true. I'm referring to „Schrems II“ (Schrems ./. Facebook Ireland, Az.: C-311/18) and thus that the EU-US Privacy Shield is invalid. The point is, if there is no assurance the resting data is entirely encrypted and all keys are entirely under the control of the customer granting privacy, how can the PII privacy can ever be granted the the consumers of a private company in the EU using public cloud services? – rsfeed Sep 05 '22 at 08:41
  • And that's all fine and good. However, this is irrelevant to your post. As I said, you've answered a compliance question, not what you asked. – schroeder Sep 05 '22 at 08:44
  • True, I'm asking for other users experience. Maybe someone had already the same topic and some material or links where to go further – rsfeed Sep 05 '22 at 08:44
  • Asking for "people's experiences" is not a good fit on a Q&A site. We are unique in that we have a format of a clear question with direct answers. So, we aren't a discussion site like Reddit. And even as a discussion point, you've strayed from the topic you raised. – schroeder Sep 05 '22 at 08:46
  • You also cannot make the claim that "there is no way to store personal data in a public cloud and meet the GDPR". Only, from your assertions, that the GCP service you investigated has issues with GDPR compliance. There are certainly GDPR-compliant cloud hosting services and cloud hosted KMS. – schroeder Sep 05 '22 at 08:48
  • I do not, I put on the thesis that CMEK, CSEK, BYOK are no guarantee to secure PII in public clouds, and from the EU view, in the sense of a GDPR, really guarantee to customers that third parties cannot see this data. At least one has to assume that the CSP can have access to this data at any time if the DEK is not really exclusively controlled by the CSC – rsfeed Sep 05 '22 at 09:57
  • It is about privacy and the promise of the CSP that with CMEK/BYOK the data encrypted with it is exclusively accessible to the CSC - this concept is not transparent – rsfeed Sep 05 '22 at 10:04