Настроить: У меня есть приложение, которое я сейчас развертываю вручную на сервере. Для этого требуется несколько учетных данных (клиентские секреты внешних служб, токены, ключи 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). Они предписывают использование аппаратных криптоустройств, а также несколько ограничений и правил, касающихся того, как с ними работать и какие проверки вы должны пройти.