Обеспечение Java Агент

Question

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

Answer 1

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

Нет. Приложение не имеет (почти) никаких знаний об агенте. Конечно, у приложения нет способа правильно проверить агента.

Я думаю, вы могли бы разработать «протокол», в котором приложение работает, только если агент вызывает конкретный метод приложения определенным образом. Однако это можно обойти путем обратного инжиниринга приложения или реального агента и использования этих знаний для написания плохого агента, который имитирует требуемое поведение.

---

Но я думаю, что вы поступаете неправильно путь. Существует много лучших (более простых, понятных, более эффективных) способов внедрения поведения в приложение Java. И я думаю, что могу определить, что ваша мотивация состоит в том, что вы хотите как можно меньше модифицировать устаревшее приложение. И это основная мотивация вашего сложного агентного подхода.

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

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

Если бы я делал это и был обеспокоен защитой от попыток (инсайдера) подорвать бизнес-правила, я бы:

1. Выберите альтернативный механизм
2. Внедрите новый код и модификации в устаревшее приложение по мере необходимости.
3. Аудит основного приложения и логи перехватчика c
4. Присоединяйтесь к двум части вместе (в зависимости от того, как работает механизм)
5. Установите комбинированную систему на защищенную машину или контейнер.

Answer 2

API присоединения Java уже защищен таким образом, что агент должен либо:

• быть указан в командной строке.
• быть присоединенным из JVM, запущенной один и тот же пользователь ОС.

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

Теоретически вы могли бы написать Java агент, который инструментирует API инструментария и убедиться, что этот агент подключен первым. Инструментарий API инструментария может затем проверить файл jar подключенного агента перед его присоединением и сравнить его, например, с некоторым известным начальным числом. Если это начальное число не совпадает, вы можете не выполнить инициализацию агента.