Ограничение разрешений на шифрование / дешифрование для ключа Cloud KMS с помощью CMEK и Cloud Storage - PullRequest
0 голосов
/ 19 марта 2020

У меня есть два хранилища в одном облачном проекте Google, скажем storage-project. Один сегмент с шифрованием по умолчанию, а другой - с ключом, управляемым клиентом (CMEK), созданным в другом проекте под названием 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 -счета , шифрование и дешифрование с помощью управляемых клиентом ключей шифрования осуществляется с использованием служебных учетных записей . Это косвенно означает, что любой, кто имеет роль Storage Object Creator в storage-project, имеет возможность шифровать / дешифровать с помощью этого ключа.

Можно ли как-то ограничить разрешение на шифрование / дешифрование для пользователя? Более конкретно, этот пользователь должен иметь возможность загружать файлы в первое хранилище, а не во второе хранилище, как мы могли бы сделать с AWS KMS + S3.

Ответы [ 2 ]

6 голосов
/ 20 марта 2020

Фон

Некоторый фоновый контекст важен для того, чтобы это имело смысл. В Google Cloud многие службы работают как Сервисная учетная запись . Например, Google Cloud Storage имеет уникальную учетную запись службы для проекта Google Cloud. Вы можете получить учетную запись службы Cloud Storage через Cloud Console, API или даже curl (как показано ниже):

$ 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

Когда служба облачного хранилища взаимодействует с другими службами Google Cloud, она использует эту учетную запись службы для авторизации этих действий.

Ключи шифрования, управляемые клиентом

По умолчанию все данные в зашифрованном виде хранятся в Google Cloud. Обычно эти данные шифруются ключами, управляемыми Google. Когда вы включаете Клиентские управляемые ключи шифрования (CMEK) для облачного хранилища , вы настраиваете хранилище облачного хранилища для автоматического шифрования / дешифрования данных, которые загружаются / загружаются с использованием предоставленного ключа Cloud KMS . Вы, клиент, можете контролировать этот ключ через Cloud KMS.

Примечание. Я собираюсь объяснить, как это работает при загрузке файлов, но для загрузки их применяются те же принципы, что и в обратном порядке.

Без CMEK

Без CMEK разработчик загружает объект в облачное хранилище. Облачное хранилище шифрует объект с помощью ключа шифрования, управляемого Google, и сохраняет зашифрованный объект на диске:

+-----------+         +---------------+                           +-------+
| Developer |         | Cloud Storage |                           | Disk  |
+-----------+         +---------------+                           +-------+
      |                       |                                       |
      | Upload object         |                                       |
      |---------------------->|                                       |
      |                       | ----------------------------------\   |
      |                       |-| Encrypt with Google-managed key |   |
      |                       | |---------------------------------|   |
      |                       |                                       |
      |                       | Write encrypted object                |
      |                       |-------------------------------------->|
      |                       |                                       |

С CMEK

С CMEK разработчик загружает Объект для облачного хранилища. Cloud Storage вызывает API-интерфейс Cloud KMS, используя учетную запись службы Cloud Storage для шифрования объекта, и сохраняет зашифрованный объект на диске:

+-----------+         +---------------+                     +-----------+ +-------+
| Developer |         | Cloud Storage |                     | Cloud KMS | | Disk  |
+-----------+         +---------------+                     +-----------+ +-------+
      |                       |                                   |           |
      | Upload object         |                                   |           |
      |---------------------->|                                   |           |
      |                       |                                   |           |
      |                       | Encrypt this object               |           |
      |                       |---------------------------------->|           |
      |                       |                                   |           |
      |                       |       Here's the encrypted object |           |
      |                       |<----------------------------------|           |
      |                       |                                   |           |
      |                       | Write encrypted object            |           |
      |                       |---------------------------------------------->|
      |                       |                                   |           |

Наиболее важным моментом здесь является то, что API-интерфейс Cloud KMS вызывается с использованием Cloud Идентификатор учетной записи службы хранения, , а не идентификатор вызывающего разработчика.

Это сделано специально, поскольку большинство клиентов хотят, чтобы CMEK был прозрачен для разработчика. Когда вы включаете CMEK в хранилище Cloud Storage, разработчикам не нужно знать о конфигурации CMEK. Они используют API Cloud Storage как обычно, а Cloud Storage выполняет операции шифрования / дешифрования с использованием указанного вами ключа. Разработчику не нужны разрешения для ключей Cloud KMS, поскольку, как показано на диаграмме выше, разработчик никогда не взаимодействует с Cloud KMS напрямую.

Ограничение доступа

Итак, вернемся к исходному вопросу:

Можно ли как-то ограничить разрешение на шифрование / дешифрование для пользователя? Более конкретно, этот пользователь должен иметь возможность загружать файлы в первое хранилище, а не во второе хранилище, как мы могли бы сделать с AWS KMS + S3.

У вас есть несколько вариантов здесь:

  1. Вы можете использовать шифрование уровня приложения (ALE) вместо CMEK. Вы все еще можете использовать Cloud KMS, но Разработчик шифрует данные с помощью 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     |
          |                                   |               |------------------------------------------------->|
          |                                   |               |                                                  |
    
  2. Не предоставляйте пользователю разрешения на ведро. Вместо ограничения разрешений IAM для ключа необходимо ограничить разрешения IAM для корзины.

0 голосов
/ 20 марта 2020

Для каждого типа объекта Cloud KMS, для которого вы можете установить гранулярные разрешения Cloud IAM, этот объект имеет метод testIamPermissions. Метод testIamPermissions возвращает набор разрешений, предоставленных вызывающей стороной для этого объекта. Вы можете ограничить разрешение на шифрование / дешифрование для пользователя, используя эту Документацию

...