0 google-cloud-storage google-cloud-kms
我在一个 Google 云项目中有两个存储桶，例如storage-project。一个使用默认加密的存储桶，另一个使用在另一个名为security-project. 我已授予的角色Cloud KMS CryptoKey Encrypter/Decrypter在云存储服务帐户（service-xxxxxxxx@gs-project-accounts.iam.gserviceaccount.com） storage-project。我可以使用拥有这两个项目的 Google 帐户成功将文件上传到此存储桶。这是预期的行为。
现在我有其他用户帐户，谁拥有的角色Viewer，并Storage Object Creator在storage-project，并没有任何权限的security-project。我担心的是，上述用户能够从第二个存储桶上传和下载文件，即使用户没有被授予对上述密钥的加密/解密权限。
根据链接https://cloud.google.com/storage/docs/encryption/customer-managed-keys#service-accounts，使用客户管理的加密密钥进行加密和解密是使用服务帐户完成的。这隐含地意味着Storage Object Creator在 上有角色的任何人都storage-project可以使用该密钥进行加密/解密。
有什么方法可以限制用户的加密/解密权限？更具体地说，该用户应该能够将文件上传到第一个存储桶，而不是第二个存储桶，就像我们使用 AWS KMS + S3 所做的那样。
一些背景背景对于这有意义很重要。在 Google Cloud 上，许多服务都以服务帐号的形式运行。例如，Google Cloud Storage 的每个 Google Cloud 项目都有一个唯一的服务帐号。您可以通过 Cloud Console、API 甚至 curl获取 Cloud Storage 服务帐户（如下所示）：
$ curl https://storage.googleapis.com/storage/v1/projects/${PROJECT_ID}/serviceAccount \
--header "Authorization: Bearer $(gcloud auth print-access-token)"
服务帐户通常表示为电子邮件，例如：
service-1234567890@gs-project-accounts.iam.gserviceaccount.com
当 Cloud Storage 服务与其他 GCP 服务交互时，它会使用此服务帐号来授权这些操作。
默认情况下，所有数据都在 Google Cloud 上进行静态加密。通常，此数据使用 Google 管理的密钥进行加密。当您为 Cloud Storage启用Customer Managed Encryption Keys (CMEK) 时，您将Cloud Storage 存储分区配置为使用提供的Cloud KMS密钥自动加密/解密上传/下载的数据。作为客户，您可以通过 Cloud KMS 控制该密钥。
注意：我将解释这是如何上传文件的，但同样的原则也适用于下载文件。
没有 CMEK
如果没有 CMEK，开发者会将对象上传到 Cloud Storage。Cloud Storage 使用 Google 管理的加密密钥加密对象并将加密的对象保存到磁盘：
+-----------+ +---------------+ +-------+
| 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 来加密对象并将加密的对象持久化到磁盘：
+-----------+ +---------------+ +-----------+ +-------+
| Developer | | Cloud Storage | | Cloud KMS | | Disk |
+-----------+ +---------------+ +-----------+ +-------+
| | | |
| Upload object | | |
|---------------------->| | |
| | | |
| | Encrypt this object | |
| |---------------------------------->| |
| | | |
| | Here's the encrypted object | |
| |<----------------------------------| |
| | | |
| | Write encrypted object | |
| |---------------------------------------------->|
| | | |
这里最重要的一点是 Cloud KMS API 是使用 Cloud Storage 服务帐户的身份调用的，而不是调用开发者的身份。
这是设计使然，因为大多数客户希望 CMEK 对开发人员透明。当您在 Cloud Storage 存储分区上启用 CMEK 时，开发人员无需了解 CMEK 配置。他们照常使用 Cloud Storage API，而 Cloud Storage 会使用您指定的密钥来处理加密/解密操作。开发人员不需要 Cloud KMS 密钥的权限，因为如上图所示，开发人员从不直接与 Cloud KMS 交互。
所以，重新审视你原来的问题：
有什么方法可以限制用户的加密/解密权限？更具体地说，该用户应该能够将文件上传到第一个存储桶，而不是第二个存储桶，就像我们使用 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 权限，而不是限制对key 的IAM 权限。
| 归档时间： |
|
| 查看次数： |
457 次 |
| 最近记录： |