GAE: лучшие практики для хранения секретных ключей?

Question

Есть ли не страшные способы хранения секретных ключей для Google App Engine? Или, по крайней мере, менее страшно, чем проверять их в системе контроля версий?

Answer 1

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

Вы можете использовать ее для шифрования своих секретов перед их сохранением в базе данных или в зашифрованном виде в системе контроля версий.Только люди с «расшифровыванием» доступа к KMS и вашим секретам смогут их использовать.

Факт остается фактом, что люди, которые могут развернуть код, всегда смогут получить ваши секреты (при условии, что ваше приложение GAE должно иметь возможность использовать секреты), но, насколько я могу, это невозможнодумать о.

Answer 2

Здесь нет простого решения. Ввод ключей в хранилище является плохим как из-за того, что он проверяет нерелевантные подробности конфигурации, так и из-за того, что он потенциально предоставляет конфиденциальные данные. Я обычно создаю для этого модель конфигурации с одним объектом и устанавливаю соответствующие параметры конфигурации и ключи для нее после первого развертывания (или всякий раз, когда они меняются).

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

Answer 3

Не совсем ответ:

• Если вы сохраняете ключи в модели, любой, кто может развернуть, может прочитать ключи из модели и выполнить развертывание снова, чтобы скрыть свои следы. Хотя Google позволяет загружать код (если вы не отключите эту функцию), я думаю, что он сохраняет только последнюю копию каждой пронумерованной версии.
• Если вы храните ключи в незарегистрированном конфигурационном файле и отключаете загрузку кода, то только люди с ключами могут успешно развертывать, но никто не может прочитать ключи, не пробираясь в бэкдор в развертывание (потенциально это не так сложно) .

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

Жизнеспособной альтернативой может быть объединение двух: хранить зашифрованные ключи API в хранилище данных и поместить главный ключ в файл конфигурации. Это имеет некоторые потенциально хорошие функции:

• Злоумышленникам необходим как доступ к копии хранилища данных, так и копия файла конфигурации (и, по-видимому, разработчики не создают резервные копии хранилища данных на ноутбуке и не теряют его в поезде).
• Указав два ключа в конфигурационном файле, вы можете выполнять смену ключей (поэтому злоумышленникам требуется хранилище данных / конфигурация того же возраста).
• Асимметричная криптография позволяет разработчикам добавлять API-ключ к хранилищу данных без необходимости читать другие.

Конечно, тогда вы загружаете криптографию на серверы Google, что может или не может считаться «экспортом» криптографии с обычными юридическими проблемами (например, что если Google настроит Азиатско-Тихоокеанский центр обработки данных?).

Answer 4

Если вы используете Laravel и хотите хранить ключи в Datastore - этот пакет может упростить управление производительностью с помощью кэширования.https://github.com/tommerrett/laravel-GAE-secret-manager

Answer 5

Три способа, которыми я могу придумать:

1. Сохраните его в хранилище данных (может быть в кодировке base64, чтобы иметь еще один уровень косвенности)
2. Передайте его как переменные среды через параметры командной строки во время развертывания.
3. Храните файл конфигурации, игнорируйте его и читайте с сервера. Здесь этот файл сам по себе может быть файлом .py, если вы используете развертывание на python, поэтому чтение и хранение файлов .json не требуется.

ПРИМЕЧАНИЕ. Если вы выбираете маршрут по conf-файлу, не храните этот JSON в статических общих папках!