TL;DR
Какой метод является приемлемым, зависит от вашего профиля безопасности / риска.
Чем дольше читается
Ваш вопрос: какой из них был бы наиболее безопасным?
Простой ответ на этот вопрос - нигде не хранить пароль, а позволить оператору ввести его. Очевидно, вы ищете не тот ответ, который требуется для серверов в центрах обработки данных или даже для виртуальных машин в облаке.t осуществимо.
Чтобы понять, какой метод является достаточно безопасным, а какой приемлемым, важно понимать контекст вашей организации, ее готовность принять риск и вытекающие из этого последствия, которые необходимы для обработки секретов.Эта оценка может привести к тому, что для одной организации может быть удобно хранить учетные данные в виде простого текста (поскольку среда защищена или существует небольшая угроза, связанная с раскрытыми секретами), другим требуется шифрование с надлежащим управлением ключами и аудитом.
Вы уже описали, что хранение учетных данных в Git - неправильный вариант.Поэтому я предполагаю, что вы ищете метод, который каким-то образом защищает действительный секрет.Защита может происходить на разных уровнях:
- Хранение секретов в защищенном месте с применением контроля доступа
- Переменная среды на хосте, защищенном доступом
- Доступ-контролируемый файл с защищенными правами доступа
- Хранение секретов в зашифрованном виде
- Шифрование значения и сохранение его в файле.Здесь вы должны рассмотреть, у кого есть доступ к этому файлу и как насчет управления ключами.Вводит проблему курицы и яйца
- Шифрование значения и сохранение его в памяти.Тем не менее, вам необходимо решить проблему управления ключами.
- Извлечение секрета из надежного источника
- Учетные данные набираются сотрудником (не реально выполнимым)
- Обращаясь в службу, чтобы предоставить вам учетные данные.Удаленный сервис защищает секрет и позволяет вам / вашему приложению запрашивать секрет.
Потенциально существует больше возможностей, но давайте пока воспользуемся ими.Одним аспектом, который связан с вышеупомянутыми возможностями, является перенос учетных данных из источника в целевой пункт назначения.Транспортировка обычно охватывает одну или несколько сторон, и каждой из этих сторон необходимо каким-то образом доверять (т.е. вы должны убедиться, что определенная сторона не разглашает ваши учетные данные).Эта модель также известна как цепочка доверия.Если известно, что каждый прыжок в цепочке доверия не раскрывает ваши учетные данные, вы можете реагировать определенным шаблоном защиты на этот контекст.Если вы обнаружите слабую ссылку, которая повышает риск заражения (например, общедоступная папка, поиск оператора), вам снова нужно повысить уровень защиты в соответствии с вашими потребностями.
Имея все это,Давайте рассмотрим, какие возможности у вас есть в Spring Boot для применения защиты секретов:
Переменные среды
Вы можете сохранить конфигурацию, используя переменные среды или системные свойства.Аспект изменчивости отличается от постоянного (например, файлового) хранилища.Переменные могут быть установлены до / после запуска приложения.
Пример для переменных среды:
export SPRING_DATA_MONGODB_USERNAME=…
export SPRING_DATA_MONGODB_PASSWORD=…
java -jar my-app.jar
Примеры для системных свойств:
java -jar my-app.jar -Dspring.data.mongodb.username=… -Dspring.data.mongodb.password=…
java -jar my-app.jar --spring.data.mongodb.username=… --spring.data.mongodb.password=…
Обратите внимание, что переменные среды /командные строки могут быть проанализированы файловой системой /proc и такими инструментами, как ps
Более подробную информацию см. в справочной документации по Внешняя конфигурация .
Свойства зашифрованной конфигурации
Spring Cloud поставляется с криптографической поддержкой отдельных свойств.Вы можете зашифровать выбранные свойства различными ключами и типами ключей (симметричный, асимметричный).Этот подход позволяет выбрать свойства, которые должны быть зашифрованы, без необходимости шифровать весь файл.
Пример для переменных среды:
application.properties
spring.data.mongodb.password={cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ
Обратите внимание, что в этом подходе вводится требование управления ключами свойств.
Для получения дополнительной информации см. Справочную документацию по Шифрование и дешифрование Spring Cloud Config .
Управляемые приложением секреты
Свойства конфигурации в Spring Boot получены из Environment ипредоставлено PropertySource с.Вы можете добавить либо свойства, либо целые PropertySource до запуска Spring Boot.
Пример добавления PropertySource:
SpringApplication app = new SpringApplication(DemoApplication.class);
app.addInitializers(new ApplicationContextInitializer<ConfigurableApplicationContext>() {
@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
applicationContext.getEnvironment().getPropertySources().addFirst(…);
}
});
app.run(args);
Пример добавления свойства:
SpringApplication app = new SpringApplication(DemoApplication.class);
app.setDefaultProperties(Collections.singletonMap("spring.data.mongodb.password", "…"));
app.run(args);
Свойства удаленной конфигурации
Spring Cloud Config позволяет централизовать конфигурацию, обслуживаемую Spring Cloud Config Server.Свойства больше не хранятся локально, а обслуживаются из службы конфигурации, которая может быть защищена не так, как уровень защиты вашего приложения.Для настройки Spring Cloud Config Server вам понадобится дополнительная служба и интеграция клиентской зависимости в ваше приложение.
Обратите внимание, что этот подход не решает общую проблему, а просто переносит ее на чужую ответственность.
Подробнее см. Справочную документацию по Spring Cloud Config Server подробности.
Использование управления секретами
Если вы можете позволить себе управление секретами, такое как HashiCorp Vault, CredHub, Azure KeyVault, Kubernetes Secrets, то вы можете использовать функции своей платформы / Управление секретамисистема для защиты ваших учетных данных.
Секретные системы управления обычно обрабатывают шифрование, аудит и контроль доступа для вас.Эти системы хранят зашифрованную копию учетных данных.Как только вы запрашиваете учетные данные (обычно через защищенные соединения TLS), система проверяет, разрешено ли вам / вашему приложению доступ к этому секрету или нет.
Некоторые из этих систем также предоставляют динамические секреты.Динамические секреты генерируются для конкретного экземпляра приложения по требованию.Если ваше приложение хочет подключиться к MongoDB, система управления секретами создаст пару учетных данных и отправит их в ваше приложение.Когда ваше приложение останавливается, система управления секретами собирается отозвать учетные данные.
Дополнительные сведения см. В справочной документации по Spring Cloud Vault .