Как хранить учетные данные, которые требуются приложению?

13

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

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

Как управлять учетными данными приложения?

Евгений
источник
4
Кроме того, это, вероятно, слишком широко для одного ответа, который не размером с книгу.
Coderanger
1
@coderanger Наблюдая за вашей презентацией, вы классифицируете различные типы секретов. И я могу видеть, как вы думаете, что это книга ... но вопрос выше не требует классификации, а только решение конкретной проблемы.
Евгений
2
Если у вас есть конкретная ситуация, отредактируйте вопрос, включив в него более подробную информацию, например, тип используемого секрета (пароль базы данных, ключи TLS и т. Д.).
Coderanger
1
Это слишком широко. Для этого доступно как минимум 14 инструментов, не включая пользовательские сценарии или шаблоны: gist.github.com/maxvt/bb49a6c7243163b8120625fc8ae3f3cd Требуются дополнительные сведения (например, требуется ли CLI для облачного решения или для больших монолитные приложения и т. д.)
Александр
1
@Alexandre Хах, я открыл это и подумал: «Да, хороший список компиляции», а затем вижу себя цитируемым внизу :)
coderanger

Ответы:

5

Правильное управление секретами приложения всегда было проблемой. Новые проблемы пришли с принятием облака. Есть отличная презентация OWASP о реальности и проблемах хранения секретов в облаке.

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

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

  • Контроль доступа: можете ли вы предоставить доступ на запись администраторам и доступ на чтение приложений? Можете ли вы ограничить, какие приложения могут читать (приложение А имеет доступ только к этим секретам)?
  • Журналы аудита: требуется для многих отчетов о соответствии и хороший способ выяснить, если что-то не так
  • Безопасное хранение секретов: как решение хранит секреты? Зашифрованная БД? Зашифрованная ФС? Кто / что держит ключ шифрования, если таковой имеется? Как используется этот ключ - один раз при запуске, а затем безопасно сбрасывается?
  • Ротация или обновление ключей / паролей: если секретный код скомпрометирован, можете ли вы отозвать его и отправить обновленный секрет в приложения? Могут ли / должны ли приложения объединить службу секретного управления?
  • Совместимость: некоторые из этих решений предлагают тесную интеграцию с определенными языками или инфраструктурой. Некоторые предлагают REST API. Вы заинтересованы в этом?

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

Александр
источник
3

Для среды, основанной исключительно на EC2, самым простым решением является использование ролей AWS IAM и политик S3 Bucket. Некоторые формулировки этого шаблона также включают в себя KMS для шифрования и DynamoDB вместо S3 для хранения, но я не нашел убедительной причины для их использования. Посетите https://github.com/poise/citadel , он специально предназначен для пользователей Chef, но базовый шаблон работает на все, вам может понадобиться собственный помощник для фактической загрузки с S3.

coderanger
источник
1
В будущем это ответит на более раннюю и более конкретную версию вопроса.
Coderanger
2
Теперь AWS предоставляет специальный сервис для хранения значений ключей, включая шифрование через KMS: aws.amazon.com/ec2/systems-manager/parameter-store .
bnzmnzhnz