#java #linux #security
#java #linux #Безопасность
Вопрос:
У нас есть веб-приложение Java, работающее на JBoss и Linux. Параметры подключения к базе данных рабочей среды поступают из файла конфигурации, который существует только на серверах приложений рабочей среды. Этот конфигурационный файл доступен для чтения только идентификатору пользователя, который также запускает приложение (назовем этого пользователя appuser), и единственными людьми, которые могут входить на серверы рабочей среды и sudo для appuser, являются члены нашей операционной группы. Сама производственная среда защищена брандмауэром от всех других сред.
Мы хотели бы сделать это более безопасным. В частности, мы хотели бы запретить операционной группе считывать пароль подключения к базе данных и другие ключи, которые в настоящее время находятся в файле конфигурации.
Другим фактором, который следует учитывать, является то, что за создание и развертывание приложения отвечает операционная группа.
Какие у нас есть варианты? Решение должно поддерживать ручной перезапуск приложения, а также автоматический запуск приложения при перезагрузке ОС.
Обновить
Решение, которое я сейчас изучаю (совет Адамски за его предложение, которое примерно соответствует шагу 1):
-
Напишите исполняемый файл-оболочку, предназначенный
setuid
для пользователя, который запускает / останавливает приложения и владеет файлами конфигурации и всем в дереве каталогов JBoss. -
Используется
jarsigner
для подписи войны после ее создания. Построение ВОЙНЫ будет осуществляться разработчиком.setuid
Оболочка проверит подпись, подтвердив, что WAR не был подделан. -
Измените процесс развертывания, чтобы развернуть только подписанный WAR.
setuid
Оболочка также может переместить WAR на место в каталоге развертывания JBoss.
Комментарии:
1. Примечание: любая подпись имеет смысл только в том случае, если вы используете реальный сертификат, а не самоподписанный. Кроме того, JVM все еще может быть подделан.
2. Правильно, установка JDK также должна быть заблокирована, особенно
cacerts
каталог.
Ответ №1:
Почему бы просто не создать второго пользователя для операционной группы для sudo, который имеет только подмножество прав доступа к файлам по сравнению с идентификатором пользователя вашего приложения?
Никаких изменений кода не требуется; красиво и просто.
Комментарии:
1. Как они запускают приложение? Сделать сценарий запуска setuid?
2. Да, вы могли бы сделать это таким образом.
3. Я не могу создать setuid самого скрипта (я забыл об этом ограничении), но я могу написать исполняемый файл-оболочку, который запускает скрипт, и создать setuid оболочки.
4. Это не совсем герметично, потому что операционные системы могут просто развернуть свой собственный файл WAR и вуаля, у них есть доступ к конфигурационному файлу.
5. Возникает вопрос: почему ваша оперативная группа имеет доступ к области развертывания?
Ответ №2:
Возможно, вам будет интересно посмотреть, как люди из Jetty подошли к этой проблеме:
http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords
Это, по крайней мере, гарантирует, что вы не можете просто прочитать пароль напрямую, но вам нужно приложить серьезные усилия, чтобы получить понятную для человека версию.
Если лицензия Jetty совместима с тем, что вы хотите сделать, вы можете просто поднять их код.
Комментарии:
1. Вам потребуется доступ к коду дешифрования Jetty и ключу шифрования, оба из которых будут находиться в системе управления версиями. Хм..
2. Дайте нам знать, что вы найдете. Помните, что если компьютер может использовать его, он может быть расшифрован.
3. Обновленный вопрос с предлагаемым подходом.
Ответ №3:
Простой способ — использовать разрешения Unix для управления тем, кто может читать эти файлы. Однако конфиденциальные данные, такие как пароли, никогда не должны храниться в обычном виде. Есть несколько альтернатив. Они требуют определенных усилий, но именно такого подхода придерживается большинство коммерческих продуктов.
Храните пароли в зашифрованном виде в файловой системе. Для этого можно использовать либо криптографию Java, либо шифрование XML.
или
Храните конфиденциальную информацию, такую как пароли, в базе данных вместе с другими деталями конфигурации и шифруйте ее с помощью инструментов базы данных. Вам все равно нужно будет хранить пароль базы данных где-нибудь в файловой системе. Oracle предоставляет кошелек для хранения пароля. Есть также некоторые сторонние кошельки, которые могут это сделать, если поставщик вашей базы данных его не предоставляет.