使用CMEK和Cloud Storage限制Cloud KMS密钥的加密/解密权限 [英] Restricting encrypt/decrypt permissions for a Cloud KMS key with CMEK and Cloud Storage
问题描述
我在一个Google云项目中有两个存储桶，例如storage-project.一个存储桶使用默认加密，另一个存储桶使用在另一个名为security-project的项目中创建的客户管理密钥(CMEK)进行加密.我已将角色Cloud KMS CryptoKey Encrypter/Decrypter授予storage-project中的Cloud Storage服务帐户(service-xxxxxxxx@gs-project-accounts.iam.gserviceaccount.com).我可以使用两个项目的所有者Google帐户将文件成功上传到此存储桶.这是预期的行为.
I have two storage buckets in one Google cloud project, say storage-project. One bucket with default encryption, and another bucket encrypted with a Customer Managed Key (CMEK) created in another project called security-project. I have granted the role Cloud KMS CryptoKey Encrypter/Decrypter to the Cloud Storage service account (service-xxxxxxxx@gs-project-accounts.iam.gserviceaccount.com) in the storage-project. I could successfully upload files to this storage bucket using a Google account who is owner to both the projects. This is an expected behaviour.
现在我有另一个用户帐户，该用户帐户在storage-project上具有角色Viewer和Storage Object Creator，在security-project上具有 无权限 .我担心的是，即使未向用户授予上述密钥的加密/解密权限，上述用户也可以从第二个存储桶上传和下载文件.
Now I have another user account, who has the roles Viewer and Storage Object Creator on the storage-project, and no permissions on the security-project. My concern is that, the above user is able to upload and download files from the second storage bucket, even though the user is not granted encrypt/decrypt permission on the above mentioned key.
根据链接 https://cloud .google.com/storage/docs/encryption/customer-managed-keys#service-accounts ，使用客户管理的加密密钥进行加密和解密都是通过服务帐户完成的.这隐含地意味着，在storage-project上具有Storage Object Creator角色的任何人都可以使用该密钥进行加密/解密.
As per the link https://cloud.google.com/storage/docs/encryption/customer-managed-keys#service-accounts, encryption and decryption with customer-managed encryption keys is accomplished using service accounts. This implicitly means that anyone who has Storage Object Creator role on the storage-project, has the ability to encrypt/decrypt with that key.
有什么办法可以限制用户的加密/解密权限?更具体地说，该用户应该能够将文件上载到第一个存储桶，而不是上载到第二个存储桶，就像我们使用AWS KMS + S3一样.
Is there any way that I could restrict encrypt/decrypt permission for a user? More specifically, this user should be able to upload files to the first storage bucket, and not to the second bucket, like we could do with AWS KMS + S3.
推荐答案
背景
要理解这一点，一些背景上下文很重要.在Google Cloud上，许多服务都作为服务帐户运行.例如，对于每个Google Cloud项目，Google Cloud Storage都有一个唯一的服务帐户.您可以通过Cloud Console，API，甚至卷曲(如下所示):
Background
Some background context is important for this to make sense. On Google Cloud, many services operate as a Service Account. For example, Google Cloud Storage has a unique service account per Google Cloud project. You can get the Cloud Storage service account via the Cloud Console, API, or even curl (as shown below):
$ curl https://storage.googleapis.com/storage/v1/projects/${PROJECT_ID}/serviceAccount \
--header "Authorization: Bearer $(gcloud auth print-access-token)"
服务帐户通常表示为电子邮件，例如:
The service account is usually expressed as an email like:
service-1234567890@gs-project-accounts.iam.gserviceaccount.com
当Cloud Storage服务与其他Google Cloud服务进行交互时，它将使用该服务帐户来授权这些操作.
When the Cloud Storage service interacts with other Google Cloud services, it uses this service account to authorize those actions.
默认情况下，所有数据都会在静态状态下在Google Cloud上进行加密.通常，此数据是使用Google管理的密钥加密的.启用云存储的客户托管加密密钥(CMEK) ，您将Cloud Storage存储桶配置为使用提供的 Cloud KMS 自动加密/解密上传/下载的数据.钥匙.您(客户)可以通过Cloud KMS对该密钥进行控制.
By default, all data is encrypted at rest on Google Cloud. Normally this data is encrypted with Google-managed keys. When you enable Customer Managed Encryption Keys (CMEK) for Cloud Storage, you configure a Cloud Storage bucket to automatically encrypt/decrypt data that is uploaded/downloaded using a provided Cloud KMS key. You, the customer, have control over that key through Cloud KMS.
注意:我将解释上传文件的工作原理，但相反的原理适用于下载文件.
Note: I'm going to explain how this works for uploading files, but the same principles apply in reverse for downloading them.
没有CMEK
没有CMEK，开发人员会将对象上传到Cloud Storage. Cloud Storage使用Google管理的加密密钥对对象进行加密，并将加密后的对象持久保存到磁盘:
Without CMEK, a developer uploads an object to Cloud Storage. Cloud Storage encrypts the object with a Google-managed encryption key and persists the encrypted object to disk:
+-----------+ +---------------+ +-------+
| Developer | | Cloud Storage | | Disk |
+-----------+ +---------------+ +-------+
| | |
| Upload object | |
|---------------------->| |
| | ----------------------------------\ |
| |-| Encrypt with Google-managed key | |
| | |---------------------------------| |
| | |
| | Write encrypted object |
| |-------------------------------------->|
| | |
使用CMEK
使用CMEK，开发人员可以将对象上传到Cloud Storage. Cloud Storage使用Cloud Storage服务帐户调用Cloud KMS API来加密对象，并将加密后的对象持久保存到磁盘:
With CMEK, a developer uploads an object to Cloud Storage. Cloud Storage invokes the Cloud KMS API using the Cloud Storage service account to encrypt the object and persists the encrypted object to disk:
+-----------+ +---------------+ +-----------+ +-------+
| Developer | | Cloud Storage | | Cloud KMS | | Disk |
+-----------+ +---------------+ +-----------+ +-------+
| | | |
| Upload object | | |
|---------------------->| | |
| | | |
| | Encrypt this object | |
| |---------------------------------->| |
| | | |
| | Here's the encrypted object | |
| |<----------------------------------| |
| | | |
| | Write encrypted object | |
| |---------------------------------------------->|
| | | |
这里最重要的一点是，Cloud KMS API是使用Cloud Storage服务帐户的身份(而不是调用开发人员的身份)来调用的.
The most important point here is that the Cloud KMS API is invoked using the Cloud Storage service account's identity, not the calling developer's identity.
这是设计使然，因为大多数客户希望CMEK对开发人员透明.在Cloud Storage存储桶上启用CMEK时，开发人员无需了解CMEK配置.他们照常使用Cloud Storage API，并且Cloud Storage使用您指定的密钥来执行加密/解密操作.开发人员不需要Cloud KMS密钥的权限，因为如上图所示，开发人员从不直接与Cloud KMS进行交互.
This is by design, because most customers want CMEK to be transparent to the developer. When you enable CMEK on a Cloud Storage bucket, developers do not need to be aware of CMEK configuration. They use the Cloud Storage API as normal, and Cloud Storage takes care of the encryption/decryption operations using the key you specified. The developer does not need permissions on the Cloud KMS keys because, as shown in the diagram above, the developer never interacts with Cloud KMS directly.
因此，请重新讨论您的原始问题:
So, revisiting your original question:
有什么办法可以限制用户的加密/解密权限?更具体地说，该用户应该能够将文件上载到第一个存储桶，而不是上载到第二个存储桶，就像我们使用AWS KMS + S3一样.
Is there any way that I could restrict encrypt/decrypt permission for a user? More specifically, this user should be able to upload files to the first storage bucket, and not to the second bucket, like we could do with AWS KMS + S3.
您在这里有几个选择:
-
您可以使用应用程序层加密(ALE)代替CMEK.您仍然可以使用Cloud KMS，但是开发人员会在保存到Cloud Storage之前使用Cloud KMS 加密数据:
+-----------+ +-----------+ +---------------+ +-------+
| Developer | | Cloud KMS | | Cloud Storage | | Disk |
+-----------+ +-----------+ +---------------+ +-------+
| | | |
| Encrypt this object | | |
|---------------------------------->| | |
| | | |
| Here's the encrypted object | | |
|<----------------------------------| | |
| | | |
| Upload KMS-encrypted object | | |
|-------------------------------------------------->| |
| | | ----------------------------------\ |
| | |-| Encrypt with Google-managed key | |
| | | |---------------------------------| |
| | | |
| | | Write KMS-encrypted, Google-encrypted object |
| | |------------------------------------------------->|
| | | |
不授予用户对存储桶的权限.除了限制键上的IAM权限之外，您还需要限制存储桶上的IAM权限.
Do not grant the user permissions on the bucket. Instead of restricting IAM permissions on the key, you need to restrict IAM permissions on the bucket.
这篇关于使用CMEK和Cloud Storage限制Cloud KMS密钥的加密/解密权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
