Базы данных Oracle - статьи
Множественные попытки доступа под различными учетными записями с одного и того же терминала
Заключительный пример применяется для нахождения места, откуда фиксировались попытки получения доступа под множеством учетных записей. Данное выражение SQL довольно таки простое и к нему может быть добавлена группировка по дню, а также выведены пользователи для каждого терминала. Рассмотрите простой пример для иллюстрации этой идеи:
SQL> select count(distinct(username)),terminal 2 from dba_audit_session 3 having count(distinct(username))>1 4 group by terminal SQL> /
COUNT(DISTINCT(USERNAME)) TERMIN ------------------------- ------ 3 pts/1 2 pts/2 3 pts/3 3 pts/5
SQL>
Данный отчет показывает кого-либо пытающегося получить доступ перебором учетных записей и паролей, но сюда же могут попасть законопослушные пользователи, которые используют различные учетные записи для различных аспектов своей работы. В любом случае администратору следует выяснить это в дальнейшем.
Безусловно, существует множество других сценариев, которые могут отобразить возможные злонамеренные действия. Их проверка несложна, как и тех, что приведены выше. Оставим их читателю для самостоятельных экспериментов. Сообщите мне, если что-то найдете полезными.
В следующем примере, настройки аудита были установлены для определения изменений, выполняемых в схеме базы данных. Сюда можно отнести создание новых объектов или попытки изменения уже существующих.
Простой SQL, приведенный ниже, покажет любые сведения из журнала аудита, имеющие отношения к созданным или измененным объектам: col username for a8 col priv_used for a16 col obj_name for a22 col timestamp for a17 col returncode for 9999 select username, priv_used, obj_name, to_char(timestamp,'DD-MON-YYYY HH24:MI')
timestamp, returncode from dba_audit_trail where priv_used is not null and priv_used<>'CREATE SESSION' / SQL> @check_obj.sql
ZULIA CREATE TABLE STEAL_SALARY 09-APR-2003 20:07 0 PETE CREATE PROCEDURE HACK 09-APR-2003 20:42 0
Этот пример показывает, что пользователь ZULIA создал таблицу, а пользователь PETE писал PL/SQL процедуру. Любые изменения такого рода, в производственной базе данных, должны быть исследованы. Намного более специфичные злодеяния могут быть обнаружены в отношении изменений объектов и схемы, но в целом, пользователи не должны иметь возможности менять что-либо в производственной базе данных. И как результат, проверка может остаться чисто символической.
