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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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