Подразумевал что java не используется для генерации html, а как бэкенд сервисы. Сервлеты в этом случае не выглядят месивом, но да есть и лучше.
JSP компилится на сервере и не один раз, тормознутость мне кажется зависит от конкретной реализации.
Про Weblogic точно не расскажу, знаю только что есть AES, где и какой ключ узнаю как забуду пароль. Аудит можно пройти с чем угодно. Аудиторы за частую не обладают достаточной компитенцией. Даже опытные сотрудники ИБ могут не знать разные «приятные» фичи.
Вариантов доступа может быть множество: операторы, бэкап, пользователи с правом только установки приложений. И даже если пользователь админ на сервере, он не должен получать пароли от базы и веб сервисов так легко. Понятно что шифрование защита «от дурака», но и она должна быть. Это ни сколько не исключает ограничение доступа на уровне файловой системы.
В тесте использовалось синхронное или асинхронное взаимодействие? Интересно посмотреть на временные характеристики не обработки сообщений, а транзакций. Обработка сообщений слишком абстрактная мера, да и время в десятки секунд не позволяют делать какой-либо вывод. Почему 50 и 70 км, это максимальное растояние? Это в пределах одного города, слишком мало для построения катострофоустойчивой системы. Будет Active-Active кластер работать на расстоянии 100-120 км? Или например 500 км(расстояние от Москвы до Нижнего Новгорода).
Дело не в атаке, а разделении прав. Если пользователь имеет readonly права на конфиг, мне не хотелось бы чтоб он получал еще доступ ко всем отстальным ресурсам. Для атаки это ерундовая защита, один лишний шаг, чтоб извлечь пароль из памяти и в любом случае мы храним ключ на этом же сервере.
Если это будет реализованно как в WebLogic вполне достаточно, потому что если пароль открытым текстом, это повод даже чисто формально WAS не использовать в некоторых областях.
Tomcat можно простить, он бесплатен и опенсорсен. У него другая ниша. Надеюсь не кто не вибирает его для платформы под банковский процессинг. А если кто-то выбирает, он готов дописать.
В документации описано, но хотелось показать подробнее что они имели в виду под xor. По ссылке описаны возможность создания и включения своего алгоритма путем реализации интерфейса com.ibm.wsspi.security.crypto.customPasswordEncryption. Полезная фича, но хотелось бы другого.
JSP компилится на сервере и не один раз, тормознутость мне кажется зависит от конкретной реализации.
кривыхумелых руках.http://www.ibm.com/developerworks/java/jdk/linux/download.html
Но на большинстве продуктов, например BPM и 7-я версия пока не работает.
Вариантов доступа может быть множество: операторы, бэкап, пользователи с правом только установки приложений. И даже если пользователь админ на сервере, он не должен получать пароли от базы и веб сервисов так легко. Понятно что шифрование защита «от дурака», но и она должна быть. Это ни сколько не исключает ограничение доступа на уровне файловой системы.
Если это будет реализованно как в WebLogic вполне достаточно, потому что если пароль открытым текстом, это повод даже чисто формально WAS не использовать в некоторых областях.