Как приложение может хранить секреты в Google Cloud Datastore безопасно?

Я создаю приложение, которое будет запускаться в Google App Engine (GAE). Ему потребуется доступ к данным, хранящимся пользователем в других системах (например, пользовательский термостат Nest, почта Yahoo). Приложение, работающее в GAE, позволит пользователю предоставлять учетные данные для другой системы. Приложение будет хранить эти учетные данные в облаке Google (хранилище данных) для последующего использования приложением, запущенным в Google Compute Engine от имени пользователя. Приложение также позволит OAuth разрешить пользователю разрешить приложению обращаться к внешней системе от имени пользователя. Приложение должно будет хранить учетные данные пользователя (имя пользователя и пароль) или токены доступа OAuth в облаке Google.

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

Как приложение может хранить эти секреты в хранилище данных Google Хранилище данных (Datastore) безопасно? Я думаю, что я ищу что-то вроде AWS CloudHSM для Google. То есть, я хотел бы хранить каждый секрет с идентификатором семени и ключа и использовать идентификатор ключа, чтобы получить ключ от системы управления ключами. Эта реализация также обеспечит ключевое вращение и другие стандартные методы обеспечения безопасности.

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

Есть ли служба в Google Cloud или API Google, которая будет управлять секретами? Есть ли другая архитектура, которую я должен рассмотреть?

Кстати, приложение использует Google Identity Toolkit (GitKit) для аутентификации и авторизации пользователей для использования размещенного приложения GAE. Приложение позволяет пользователям создавать учетные записи, используя либо идентификаторы федерации, либо имя пользователя и пароли через GitKit.

Спасибо, Крис

Ответ 1

Тем временем Google также добавил службу управления ключами: https://cloud.google.com/kms/

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

Ответ 2

App Identity Service может быть тем, что вы ищете https://cloud.google.com/appengine/docs/java/appidentity/#Java_Asserting_identity_to_other_systems

Он позволяет вам подписывать контент с помощью частного ключа для конкретного приложения и предоставляет вращающиеся сертификаты для проверки подписанного содержимого.

Ответ 3

Итак, насколько я могу судить, ответ заключается в том, что вы не можете. То, что вы ищете, эквивалентно KMS. Эта служба позволяет создавать и управлять ключами и создавать кучу ваших собственных криптографических материалов. Это действительно здорово, и это позволит вам быстро сделать невероятно сильную криптографию с помощью нескольких простых строк кода. Azure имеет аналогичную службу под названием KeyVault. Насколько мне известно, у него нет автоматических ключей и ротации, но кроме этого это хорошо. Во время этого ответа не было эквивалентной услуги для Google. У них есть внутренний KMS, который они использовали для криптографических операций, и вы можете предоставить свои собственные ключи, но это в значительной степени. Не совсем то же самое, что вы получаете на KeyVault, и ничего подобного KMS.

Это говорит, что есть надежда. Вы можете сделать одну из двух вещей:

  • Создайте VPC и используйте HSM из другого места. Вы можете использовать RackSpace или просто использовать AWS KMS. Это звучит безумно, но на самом деле это хорошая идея, и дополнительное управление стоит того. В общем, наиболее безопасное решение отделяет ключи от зашифрованных данных, особенно в состоянии покоя. Это означает, что ключи в одном центре обработки данных и зашифрованные данные, хранящиеся в другом центре обработки данных, являются наиболее безопасным решением. Это звучит как тяжелый материал, но, к счастью, я создал проект с открытым исходным кодом, который очень легко для вас называется KeyStor. С помощью KeyStor вы можете получить центр обработки данных, который работает с службами шифрования, установленными за один день, без проблем, и вы можете использовать AWS очень экономически эффективно.
  • Настройте свой собственный сервис cypto, пропустите интеграцию HSM и просто будьте осторожны, кто имеет доступ к машинам, которые поддерживают ваши ключи. Вы можете сделать это с помощью KeyStor, и если KeyStor не совсем сделает то, что вы хотите, то почему он с открытым исходным кодом. Возьмите код и создайте то, что вам нужно построить.

Ответ 4

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

Здесь какая-то документация от Google о секретном управлении и здесь в кодексе для специфического шифрования данных в облачном хранилище Google на уровне приложения с использованием Cloud KMS.