Каковы лучшие практики для хранения сертификатов при весенней загрузке? - PullRequest
1 голос
/ 09 января 2020

Каждый учебник, который я вижу в Интернете, показывает, как настроить HTTPS при весенней загрузке, просто указав путь к хранилищу ключей и пароль в файле application.conf, например, 1.4 в по этой ссылке . Я могу сделать это и настроить HTTPS нормально.

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

1 Ответ

0 голосов
/ 09 января 2020

Так что мне удалось найти хороший ресурс, объясняющий, что должно быть сделано

Как и в любом другом руководстве, они говорят что-то вроде "не хранить хранилища ключей в исходном коде" без предоставления каких-либо рекомендаций о том, как это сделать. Я знаю, что не должен хранить хранилища ключей в git, docker, банках ... но КАК мне их отделить? какие инструменты я должен использовать?

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


Защитите свой Keystore и пароли ключей (я сделано это)

Очень часто пароли хранилища ключей хранятся в открытом тексте в различных конфигурационных файлах.

Например, вот типичная конфигурация коннектора Tomcat:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
    keystoreFile="${catalina.home}/conf/keystore.p12"
    keystorePass="mypass" keyPass="mypass"
    keyAlias="main-key"
    maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS"
    />

Это очевидно совершенно неприемлемо с точки зрения безопасности.

Сохраняйте секретные секреты в другом месте, в идеале используйте менеджер секретов, такой как хранилище Hashicorp. По крайней мере, мастер-пароль может быть сохранен в переменной среды для должным образом защищенной учетной записи. Храните личные ключи отдельно

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

Установка ограничительных прав доступа к файлам для хранилищ ключей (я это сделал)

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

chown account_id keystore_file_name
chmod 400 keystore_file_name

Хранить только активные ключи / сертификаты (я это сделал)

Убедитесь, что хранилища ключей содержат только активные ключи, сертификаты и CA-цепочки. Сертификаты с истекшим сроком действия, неиспользуемые CAS должны быть удалены.

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

Не упаковывать хранилища ключей внутри Jar Файлы / Архивные файлы приложения

Очень часто разработчики связывают файлы хранилища ключей со всеми другими ресурсами приложения, чтобы они попадали в путь к классу приложения, а затем автоматически выбирали мои инструменты сборки Maven / Gradle и добавлялись в файлы Jar.

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

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

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

Не упаковывать хранилища ключей внутри Docker Контейнеры

Файлы хранилищ ключей и файлы PEM следует размещать в внешний том docker, чтобы их можно было обновлять без изменения образа docker. Это позволяет обновлять хранилища ключей независимо от docker образов в случае нарушения безопасности или для регулярного вращения ключа / сертификата / refre sh.

Файлы на внешнем томе можно просто заменить на хосте и затем контейнер docker (или несколько контейнеров) можно перезапустить.

Если на одном хосте работает несколько контейнеров docker, все они могут совместно использовать один и тот же том с хранилищами ключей.

Не хранить хранилища ключей в приложении Git Репо

Все ключи и секреты должны быть отделены от исходного кода и храниться отдельно. Отдельные хранилища ключей для разных сред

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

PKCS12 совместим с другими инструментами, такими как openSSL. Это значение по умолчанию для Java 9 и выше, но оно должно быть явно задано для предыдущих Java версий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...