Базы данных Oracle - статьи

         

Рабочие примеры


Давайте сейчас проработаем два примера и посмотрим, что можно изучить. Для начала включите аудит для попыток доступа к базе данных: SQL> audit create session; Audit succeeded. SQL>

Приведенная команда будет отслеживать доступ всех пользователей, независимо от того успешен он или нет. [by access] это действительное умолчание для данной команды.

Заметка: Формат всех команд аудита по документации Oracle выглядит следующим образом:

audit {statement_option|privilege_option}
[by user] [by {session|access}] [ whenever
{successful|unsuccessful}]

Обязательными являются только лишь statement_option и privilege_option части выражения. Другие части являются опционными и их использование позволяет сделать аудит более специфичным.

Что бы пользователь мог задать команду аудита, необходимым условием для него является наличие привилегии "AUDIT SYSTEM". Найти пользователей, которые имеют эту привилегию, можно выполнив следующее: SQL> select * 2 from dba_sys_privs 3 where privilege like '%AUDIT%';

GRANTEE PRIVILEGE ADM ------------------------- ----------------------- CTXSYS AUDIT ANY NO CTXSYS AUDIT SYSTEM NO DBA AUDIT ANY YES DB AUDIT SYSTEM YES IMP_FULL_DATABASE AUDIT ANY NO MDSYS AUDIT ANY YES MDSYS AUDIT SYSTEM YES WKSYS AUDIT ANY NO WKSYS AUDIT SYSTEM NO

9 rows selected.

SQL>

Выше приведенные результаты принадлежат базе данных Oracle 9i. Пользователи по умолчанию MDSYS, CTXSYS и WKSYS были бы неплохой мишенью для атакующего, так как любые действия аудита могут быть выключены любым из этих пользователей, что бы скрыть любые предпринятые действия.

Теперь аудит будет отслеживать все попытки доступа, и нам необходимо подождать, когда какие-нибудь пользователи войдут в систему что бы выполнить свою работу. И пока они будут делать это, давайте установим аудит, для контроля изменений в схеме. Для краткости, не все изменения объектов схемы будем отслеживать, в этом примере. Хотя в принципе, можно отслеживать изменения любых объектов БД: таблиц, индексов, кластеров, представлений, последовательностей, процедур, триггеров, библиотек и т.д. В этом примере аудит будет включен на выборочной группе объектов. Настройка аудита может быть выполнена за два этапа, создание команд аудита и запуск на исполнение, как показано ниже: set head off set feed off set pages 0 spool aud.lis select 'audit 'name';' from system_privilege_map where (name like 'CREATE%TABLE%' or name like 'CREATE%INDEX%' or name like 'CREATE%CLUSTER%' or name like 'CREATE%SEQUENCE%' or name like 'CREATE%PROCEDURE%' or name like 'CREATE%TRIGGER%' or name like 'CREATE%LIBRARY%') union select 'audit 'name';' from system_privilege_map where (name like 'ALTER%TABLE%' or name like 'ALTER%INDEX%' or name like 'ALTER%CLUSTER%' or name like 'ALTER%SEQUENCE%' or name like 'ALTER%PROCEDURE%' or name like 'ALTER%TRIGGER%' or name like 'ALTER%LIBRARY%') union select 'audit 'name';' from system_privilege_map where (name like 'DROP%TABLE%' or name like 'DROP%INDEX%' or name like 'DROP%CLUSTER%' or name like 'DROP%SEQUENCE%' or name like 'DROP%PROCEDURE%' or name like 'DROP%TRIGGER%' or name like 'DROP%LIBRARY%') union select 'audit 'name';' from system_privilege_map where (name like 'EXECUTE%INDEX%' or name like 'EXECUTE%PROCEDURE%' or name like 'EXECUTE%LIBRARY%') / spool off @@aud.lis


Данный скрипт выведет набор команд аудита в спул файл, который затем запустится для выполнения команд аудита.

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

Сейчас, когда все примеры аудита только что включены, установки могут быть просмотрены при помощи этого SQL: 1 select audit_option,success,failure 2 from dba_stmt_audit_opts 3 union 4 select privilege,success,failure 5* from dba_priv_audit_opts SQL> /

AUDIT_OPTION SUCCESS FAILURE --------------------------- ---------- ---------- ALTER ANY CLUSTER BY ACCESS BY ACCESS ALTER ANY INDEX BY ACCESS BY ACCESS ALTER ANY INDEXTYPE BY ACCESS BY ACCESS ALTER ANY LIBRARY BY ACCESS BY ACCESS ? EXECUTE ANY LIBRARY BY SESSION BY SESSION EXECUTE ANY PROCEDURE BY SESSION BY SESSION

38 rows selected.

SQL>

Каждый раз, когда пользователь пытается что-нибудь затронуть в базе данных, на что включен аудит, ядро Oracle проверяет действие и создает или обновляет (в случае одной записи для сессии) запись в таблице AUD$, владельцем которой является пользователь SYS. Эта таблица по умолчанию находится в табличном пространстве SYSTEM. Кстати говоря, это само по себе может стать причиной проблемы при атаке – отказ в обслуживании. Если табличное пространство SYSTEM заполнится, то база данных зависнет.

AUD$ - особенная таблица [словаря данных], так как только из нее пользователь SYS имеет право удалять из нее записи. Если журнал аудита включен и пишется в базу данных, то число записей в этой таблице необходимо внимательно контролировать что бы удостовериться что она не растет слишком быстро, и не заполнила все системное табличное пространство. Стратегия очистки нуждается в адаптации, что бы сохранять размер таблицы и если необходимо архивировать записи журнала аудита для будущего использования. Одна из тактик может состоять в том, что бы копировать записи в итоговую таблицу, созданную для выполнения спецпроверки с целью выявления злоупотреблений. Эти итоговые таблицы могут располагаться в отдельной базе данных для увеличения защищенности. После копирования таблица sys.aud$ может быть усечена.

Таблицу SYS.AUD$ можно передвинуть в табличное пространство, отличное от SYSTEM, но сначала, уточните это в технической поддержке Oracle, так как это действие может более не поддерживаться.

Только пользователи, которым предоставлен специальный доступ к таблице SYS.AUD$ могут читать, изменять и удалять данные из нее. По умолчанию этими правами владеет SYS, но эти действия может выполнять любой другой пользователь, наделенный необходимыми правами. Существуют две специальные роли, которым разрешен доступ к таблице SYS.AUD$ на select и delete, это роли DELETE_CATALOG_ROLE и SELECT_CATALOG_ROLE. Эти роли не следует предоставлять обычным пользователям.

Возвращаясь к примерам, наши пользователи уже вошли в систему и проработали целый день и создали некоторые записи аудита. Эти записи могут быть просмотрены различными способами:



  • Путем выборки записей из SYS.AUD$ - Это исходный журнал аудита
  • Путем выборки записей из dba_audit_trail – Это представление DBA показывающее исходный журнал аудита.
  • Путем выборки записей из dba_audit_session – Это представление показывает только лишь события входа и выхода.


  • Простое SQL-предложение может показать попытки соединения в деталях: SQL> get check_create_session 1 -- 2 -- check_create_session.sql 3 -- 4 col username for a15 5 col terminal for a6 6 col timestamp for a15 7 col logoff_time for a15 8 col action_name for a8 9 col returncode for 9999 10 select username, 11 terminal, 12 action_name, 13 to_char(timestamp,'DDMMYYYY:HHMISS') timestamp, 14 to_char(logoff_time,'DDMMYYYY:HHMISS') logoff_time, 15 returncode 16* from dba_audit_session SQL> / USERNAME TERMIN ACTION_N TIMESTAMP LOGOFF_TIME RETURNCODE ----------- ------ -------- --------------- --------------- -------- SYS pts/1 LOGOFF 09042003:051046 09042003:051641 0 ZULIA pts/1 LOGON 09042003:051641 1017 SYS pts/1 LOGOFF 09042003:051649 09042003:053032 0 SYS pts/2 LOGOFF 09042003:052622 09042003:053408 0 ZULIA pts/1 LOGON 09042003:053032 1017

    Существует несколько простых злоупотреблений, которые могут быть обнаружены при исследовании пользовательского доступа в базу данных. Для примера, взглянем на этот отчет и обнаружим следующее:




      Содержание раздела