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

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

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

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

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

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

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

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

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

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