Безопасно ли отслеживать SSL ключи и сертификаты с помощью систем контроля версий в режимах локальной разработки и продакшена?
Как известно, файлы с переменными окружения (обычно имеют расширение .env с именем файла или без) часто не отслеживаются системами контроля версий, чтобы предотвратить утечку таких данных, как пароли к базам данных. А что насчёт файлов с ключами SLL и сертификатами?
Прошу Вас отдельно рассмотреть случаи локальной разработки, стэйджинга и продакшена.
Ход мыслей по данной теме
Режим локальной разработки
Если в режиме локальной разработки используется самовыпущенные (например, с помощью mkcert) SSL ключ и сертификат , то в целом не вижу причин исключать их из отслеживания системами контроля версий. Вроде там так не содержится никаких чувствительных данных.
Единственная вероятная причина заставить каждого участника команды выпустить сертификат самостоятельно - возможное отсутствие в mkcert команды заставить браузеры верить уже выпущенному сертификату. Если такой команды действительно нет, тогда каждому участнику придётся самостоятельно запустить команду mkcert, в результате чего будет не только выпущен ключ и сертификат, но браузеры будут им доверять. Сделать это без mkcert на Windows непросто (у меня на момент задавания вопроса не получалось).
Обновление на основе комментариев
Как прокомментировал @andreymal,
Если вы добавляете самовыпущенный сертификат в доверенные браузера, то утечка его закрытого ключа позволит злоумышленнику организовать mitm-атаку и потому очень опасна
Надеюсь, это не будет причиной использовать в режиме локальной разработке только протокол HTTP (а не HTTPS).
Продакшен
Я точно не уверен, но думаю, что SSL ключ и сертификат для режима продакшен являются секретной информацией, утечки которой допускать не следует. С какой-то вероятностью они могут быть так же доступны для общего просмотра с помощью режима разработчика браузера как CSS или JS файлы, но это опять же предположение.
В отличие от самовыпущенных SSL ключей и сертификатов для режима локальной разработки, которые у каждого члена команды могут быть свои, для режима продакшен будет один ключ и один сертификат на всех (скорее всего, выданные уполномоченными организациями на возмездной основе). Если так, то их придётся исключить из системы контроля версий и передавать между членами команды другим способом.
Обновление на основе комментариев
Был задан вопрос: зачем членам команды знать SSL продакшена, если его по идее должно быть достаточно знать одному-двум админам продакшен-серверов? Отвечу так: в зависимости от того, как организована автоматизация сборки проекта и его деплой, иногда SLL-ключ и сертификат может быть удобно иметь среди файлов исходного кода.
Первое, что настораживает - это то, SSL-ключ должны знать только админы продакшен-сервера. Не говорю, что это неправильно, но при таком раскладе, когда SSL-ключ и сертификат только у одного-двух членов комманды, могут возникнуть проблемы. Например, админ не вышел на работу, а надо опубликовать хотфикс приложения. Или же файлы, необходимые для работы приложения, разбросаны по членам команды, а не организоываны воедино.
Опять же, не говорю, что все должны делать именно так, но я собираю проект в папку, куда помещается абсолютно всё, что нужно для работы приложения на сервере, в частности с ssl-ключ, сертификат и файл переменных окружения:
Таким образом, после сборки проекта файлы остаётся только отправить на VPS тем или иным способом и перезапустить docker compose build на VPS.
Я знаю, что есть всякие продвинутые способы деплоя, в частности CI/CD как на GitHub или всевозможные инструменты AWS. Можно, например, организовать инъекцию перменных среды средствами AWS без использования .env-файлов - наверняка что-то похожее и для SSL есть. Но всё это привязывает разработчиков к конкретному поставщику устуг. Иногда это оправдано, но всё же должен быть какой-то способ грамотно организовать деплой, когда имеется один лишь только VPS изначально с голой Ubuntu.
Ответы (2 шт):
Я думаю каноническим ответом может быть такой: если к системе контроля версий допущены только те люди, которым разрешено смотреть секретные части ключей/сертификаты, и вы можете относительно надежно гарантировать (на протяжении всего времени действия ключа), что в систему контроля версий не проникнет неавторизованный и/или злоумышленник, то хранить можно. Разумеется систему аудита нужно сделать, возможно какие-то тесты на проникновение сделать. Так же действует правило: чем меньше людей знает секрет, тем он (в общем случае) надежнее хранится.
Я думаю @Pak Uula всё правильно ответил.
Закрытый ключ SSL на продакшене это очень сильно конфиденциальная штука, сохранность которой гарантирует невозможность атаки man in the middle как уже писали в комментариях. Система контроля версий это не то место, где надо подобные такие вещи.
По хорошему контур приложения и контур веб-сервера должны быть разные и разнесены друг от друга. Например приложение лежит у вас в /var/www а все что касается ssl в /etc/ssl куда вообще нет прямого доступа по http и берет его оттуда nginx, apache или любой другой веб-север. Т.е. всё это дело должно храниться отдельно от проекта приложения (сайта/сервиса).
Управлять такой конфигурацией продвинутыми способами можно, например через docker и kubernetes или puppet либо вручную или ci/cd скриптами силами специально уполномоченного девопса с доступом. А у разработчиков может даже не быть sudo прав на стенды, только запись в папку проекта.
Вы так же можете использовать LetsEncrypt через certbot как на деве, так и на проде (если нет необходимости в более надёжном УЦ, минцифрах и пр.). тогда вам вообще не надо будет думать про ssl.
Но в любом случае шифрование трафика это задача веб-сервера, а не приложений, которые на нём крутятся.
К слову, мы для dev стендов используем сертификаты, выданные локально-развернутым ЦС, корневой сертификат которого добавляется в доверенные доменной политикой на все рабочие ПК. Это избавляет от необходимости чего-то вручную к себе добавлять для упрощения разработки.