может кто сталкивался.

Успешно мониторим failed logons через select * from DBA_AUDIT_TRAIL where returncode=1017

Проблема в том что количество failed logons со стороны сервисных и шаред аккаунтов достаточно велико и это связано с кривыми руками application support. Вести воспитательную работу со всеми кастомерами слишком утомительно (их слишком много). Аккаунты в воспитательных целях не перекроешь. В целом борьба с этим напоминает борьбу со змей горынычем. Одну голову отрубишь, еще две вырастит.

Короче вопрос такой. Есть ли способ как то определить насколько этот failed logon опасен с точки зрения секьюрити? Криво настроеные коннекшны всегда ломятся с одним паролем, а если это был бы допустим подбор пароля, то пароль каждый раз был бы разный. Не уверен, но в оракле вряд ли где то отражается что то типа хэш пароля под которым ломились.

Короче я бы хотел как то отсортировать реально опасные failed logons на которые стоит обратить внимание от просто криво настроенных приложений. Есть идеи?

Vadim LejninveepПроблема в том что количество failed logons со стороны сервисных и шаред аккаунтов достаточно велико и это связано с кривыми руками application support
Сколько у тебя приложений? Конечное число?
1) Создай справочник, и warning выдавай для тех, кто не соблюдает
стандартный набор полей DBA_AUDIT_TRAIL

Сделай distinct from DBA_AUDIT_TRAIL, ненужное выбрить


2) Для новых приложений, пусть оформляют допуск (стндартная форма)

И вообще, такие вопросы решаются регламентом.
Безопасник есть? вот ему и пишешь докладную с предложениями.

Пойми, если что случится, вазелин придется запасать тебе.


Я бы подготовил profiles с failed login (с разным количеством)
Заблокировался account, разблокировка через безопасника.

Риски, в общем случае не твоя забота, это забота бизнеса, а вот разъяснить эти риски бизнесу, желательно бумажкой с их подписью что все поняли - твоя.

В крайнем случае, от тебя должен быть документ на имя начальника что ты предупреждал.
Чем больше бумаги - тем чище жопа.

Спасибо за идеи. Обсудим с коллегами.

Еще собираемся EUS попробовать (OID или OUD). Как там обстоят дела со всякими секьюрити чеками и политиками? В самой DB я так понял с этим относительно все примитивно.