Назад | Перейти на главную страницу

Управление учетными данными в среде CI / CD

Настроить: У меня есть приложение, которое я сейчас развертываю вручную на сервере. Для этого требуется несколько учетных данных (клиентские секреты внешних служб, токены, ключи AES, IV и т. Д.), Которые я в настоящее время храню в файле, зашифрованном с помощью gpg. Каждый раз, когда я перезапускаю приложение, я разблокирую gpg-key в консоли, и служба затем снова расшифрует файл из сценария приложения (как gpg-agent сохраняет парольную фразу в памяти в течение ограниченного времени) и анализирует их через конвейер.

Преимущество этого метода в том, что ни учетные данные, ни gpg-парольная фраза, необходимая для доступа к ним, НИКОГДА не сохраняется на диске и хранится только в памяти. Таким образом, даже с полным доступом root невозможно восстановить учетные данные. Единственный шанс - получить доступ в течение короткого промежутка времени, в течение которого gpg-ключ остается разблокированным.

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

Здесь кредиты проект на github, который похож на то, что я делаю, но все еще имеет указанные выше недостатки. Возможно, файл удастся зашифровать несколькими gpg keys, а затем попытайтесь расшифровать его всеми ключами, пока один из них не удастся.

Вопрос: Каковы лучшие способы обработки учетных данных, которые (а) доступны нескольким пользователям без ключа или совместного использования учетной записи, (б) доступны для системы CI / CD (где у меня нет консоли каждый раз, когда происходит развертывание), и ( в) хранит только данные пароля в памяти? "Обходной путь" с несколькими gpg keys выглядит как сложный взлом и не работает с системами CI / CD.

Я буду говорить о секретах вместо учетных данных, так как может быть другая конфиденциальная информация, которую вы хотите защитить. Неважно, что ваш вопрос сформулирован специально для систем CI / CD, проблема остается неизменной, говорим ли мы об использовании сертификатов X.509 для аутентификации, сохранении учетных данных базы данных или защите токена доступа для агента сборки.

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

Некоторые приложения шифруют секреты на диске, но, как они часто иметь быть симметричным, то есть более или менее декоративным.

Так что ты можешь сделать?

  • Ваша первая линия защиты - это DAC вашей операционной системы (дискреционный контроль доступа) и MAC (обязательный контроль доступа) - если мы говорим о Linux, разрешения POSIX - это DAC, а LSM, такие как App Armor, SELinux или GRSecurity, - это MAC.

  • Проверка вашей ОС на соответствие стандартам, например СНГ или DISA STIG.

  • Используя HSM или Смарт-карта OpenPGP На ум приходит время хранения ключа PGP, который вы используете для шифрования секретов на диске. Подобные устройства гарантируют, что ключ никогда не покинет оборудование.

Имейте в виду, что никакая единственная мера не обеспечивает безопасности ключей в HSM - физический доступ может их скомпрометировать. Аппаратные устройства хранения ключей должны сочетаться с физической защитой и надлежащими операционными процедурами для обеспечения их безопасности.

Проверьте политики корневого центра сертификации основного браузера (Хром, Fire Fox, Edge / IE). Они предписывают использование аппаратных криптоустройств, а также несколько ограничений и правил, касающихся того, как с ними работать и какие проверки вы должны пройти.

  • Используя программное обеспечение, подобное Свод чтобы получить секрет по запросу, но для этого требуется поддержка приложений. В противном случае вы просто снова сохраняете его на диске. Что Vault может добавить к этому миксу, так это принудительный TTL для секретов и возможность их самостоятельно менять.