Обеспечивает ли передача конфиденциальных переменных конфигурации в .properties за пределами Config.groovy преимущество безопасности в Grails?

Question

Я понимаю, что в Grails по умолчанию конфигурации хранятся в Config.groovy и после их развертывания свойства содержатся в войне.Очевидно, это может вызвать проблемы, если вам нужно изменить их без повторного развертывания приложения.Тем не менее, я только что прочитал следующее в документации по плагину Grails AWS:

"В соответствии с рекомендациями Amazon вы можете использовать файл .properties для обработки ваших секретных ключей и ключей доступа для этого плагина."

...

"Иногда у вас по-прежнему нет доступа к файловой системе, но не хочет широко хранить свои учетные данные в файле конфигурации "

(http://blanq.github.com/grails-aws/1.2.12.1/index.html)

Есть ли какое-то преимущество в безопасности хранения кредитов за пределами Config.groovy? Возможно, я что-то упускаю: /

Answer 1

Существует несколько конкретных причин, по которым вы не хотите включать информацию о безопасности непосредственно в WAR.

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

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

Answer 2

Иногда вам нужно скрыть некоторые кредиты даже от разработчиков. Например, это могут быть ключи PayPal и внешняя команда (с которой вы никогда не встречались). Таким образом, вы можете хранить эту конфигурацию где-нибудь на сервере (/etc/myapp/config.properties), не предоставляя доступ к ней другим разработчикам.

Вторая часть о ' не имеет доступа к файловой системе ', означает, что вы можете указать эти параметры при запуске, в командной строке, не сохраняя их где-либо. Таким образом, даже тот, кто имеет доступ к серверу, по-прежнему не может видеть учетные данные, по крайней мере, в обычном файле

Answer 3

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

Преимущество в том, что вам не нужно извлекать код и устанавливать Grails на рабочий сервер. Вы можете просто создать один общий военный файл, загрузить и развернуть его на рабочем сервере.