You want to archive data in Cloud Storage. Because some data is very sensitive, you want to use the `Trust No One` (TNO) approach to encrypt your data to prevent the cloud provider staff from decrypting your data. What should you do?
You want to archive data in Cloud Storage. Because some data is very sensitive, you want to use the `Trust No One` (TNO) approach to encrypt your data to prevent the cloud provider staff from decrypting your data. What should you do?
To follow the 'Trust No One' (TNO) approach and ensure that the cloud provider staff cannot decrypt your data, you should use a customer-supplied encryption key (CSEK). By specifying the CSEK in the .boto configuration file and storing the encryption key in a different project that only the security team can access, you maintain full control over the encryption keys, preventing the cloud provider from accessing them. This isolation and control align with the TNO approach.
The correct answer must be D A and B can be eliminated immediately since kms generated keys are considered potentially accessible by CSP. C is incorrect because memory store is essentially a cache service. Additional authenticated data (AAD) acts as a "salt", it is not a cipher.
AAD is bound to the encrypted data, because you cannot decrypt the ciphertext unless you know the AAD, but it is not stored as part of the ciphertext. AAD also does not increase the cryptographic strength of the ciphertext. Instead it is an additional check by Cloud KMS to authenticate a decryption request.
The trust no one design philosophy requires that the keys for encryption should always be, and stay, in the hands of the user that applies them. This implies that no external party can access the encrypted data (assumed that the encryption is strong enough). https://en.wikipedia.org/wiki/Trust_no_one_(Internet_security)
Answer: A Description: AAD is used to decrypt the data so better to keep it outside GCP for safety
A is the answer. https://cloud.google.com/kms/docs/additional-authenticated-data Additional authenticated data (AAD) is any string that you pass to Cloud Key Management Service as part of an encrypt or decrypt request. AAD is used as an integrity check and can help protect your data from a confused deputy attack. The AAD string must be no larger than 64 KiB. Cloud KMS will not decrypt ciphertext unless the same AAD value is used for both encryption and decryption. AAD is bound to the encrypted data, because you cannot decrypt the ciphertext unless you know the AAD, but it is not stored as part of the ciphertext. AAD also does not increase the cryptographic strength of the ciphertext. Instead it is an additional check by Cloud KMS to authenticate a decryption request.
Agree with A
CSEK with only security team having access seems to be right approach. Not sure how A can be better.
D may work, but 'Trust No One' = do not trust GCP too. So D cannot be the answer.
CSEKs are used when an organization needs complete control over key management.
The answer is A The question tells us that "prevent the cloud provider staff from decrypting", so we cannot keep anything that helps decrypt on GCP, not even in a different project. so the answer cannot be D.
C can not be the answer since memorystore cant be used to save CSEK key. https://cloud.google.com/memorystore/docs/redis/cmek#when_does_memorystore_interact_with_cmek_keys A is the Answer.
It’s A, because you cannot decrypt the ciphertext unless you know the AAD (https://cloud.google.com/kms/docs/additional-authenticated-data)
answer A: KMS + AAD is more secure than CSEK
Option A is not the best choice for the "Trust No One" (TNO) approach because it involves using Google Cloud's Key Management Service (KMS) to create and manage encryption keys. This means that the cloud provider will have access to the keys, which could potentially enable their staff to decrypt the data.
IMO must be (D) : to reach TNO goal keys must be customer supplied.
D it is
Answer: A
Customer-Supplied Encryption Key (CSEK): CSEK allows you to provide your encryption keys, ensuring that the cloud provider staff does not have access to the keys and cannot decrypt your data. Separate Project for Key Management: Saving the CSEK in a different project that only the security team can access adds an additional layer of security. It isolates the encryption keys from the project where the data is stored, ensuring that even within the same cloud provider, only authorized personnel can access the keys. Use of .boto Configuration: Specifying the CSEK in the .boto configuration file ensures that it is applied consistently when interacting with Cloud Storage through tools like gsutil. This way, every archival file is encrypted using your keys. Options A and B involve using Google Cloud Key Management Service (KMS) to manage keys, which does not align with the TNO approach because cloud provider staff could potentially access the keys stored in Google Cloud KMS.
I just cannot understand this question. If you can't trust the provider, in this case Google, then how can you use the KMS approach. In my mind you have to generate the key locally and upload but I'm clearly wrong and don't get why.
Keep AAD Outside of Google Cloud: Keeping the AAD outside of Google Cloud ensures that Google cannot access the additional context required to decrypt the files, thus implementing the TNO approach. Option C: Customer-Supplied Encryption Key (CSEK) in .boto File: Storing the CSEK in Cloud Memorystore or any cloud service introduces a risk where the key could be potentially accessed by cloud provider staff. Option D: Customer-Supplied Encryption Key (CSEK) in a Different Project: While storing the CSEK in a different project adds some security, it still leaves the keys within the Google Cloud environment, which does not fully meet the TNO approach.