Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Select con#,obj#,rcon#,enabled,nvl(defer,0) from cdef$ where rob
|
|
j#=: 1
Plans in shared pool between Begin and End Snap Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Shows the Execution Plans found in the shared pool between the begin and end
snapshots specified. The values for Rows, Bytes and Cost shown below are those
which existed at the time the first-ever snapshot captured this plan - these
values often change over time, and so may not be indicative of current values
-> Rows indicates Cardinality, PHV is Plan Hash Value
-> ordered by Plan Hash Value
--------------------------------------------------------------------------------
| Operation | PHV/Object Name | Rows | Bytes| Cost |
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
End of Report
Для ускорения сбора подобной статистики можно воспользоваться переменными:
SQL> define begin_snap=1
SQL> define end_snap=2
SQL> define hash_value=2065408759
SQL> define report_name=batch_run
И запустить SPREPSQL.
Для оптимальной работы STATSPACK рекомендуется регулярно собирать статистику оптимизатора для схемы пользователя PERFSTAT.
Например,
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> 'PERFSTAT', CASCADE=> TRUE); EXECUTE DBMS_UTILITY.ANALYZE_SCHEMA('PERFSTAT', 'COMPUTE');
Наполнение отчета
На содержимое (качественное и количественное) отчета о производительности, полученном с помощью STATSPACK влияют дополнительные параметры, такие как уровень детализации снимка (snapshot level) и фильтры SQL-выражений (snapshot SQL thresholds).
Уровень детализации снимка определяется числом. Допустимые значения – 0, 5, 6, 10. По умолчанию – 5. Каждый последующий уровень включает в себя предыдущий. Чем больше уровень, тем объемнее отчет.
Уровень 0 – общая статистика производительности. Этот уровень включается во все остальные. Содержит статистику ожиданий, системных событий, данных отката, кэша данных, SGA, фоновых событий, событий сессий пользователей, блокировок, родительских защелок и др.
Уровень 5 – дополнительные данные по SQL-выражениям. Здесь уже используются фильтры SQL-выражений для выявления ресурсоемких SQL-выражений:
- Число выполнений (executions) SQL-выражения (по умолчанию 100);
- Число чтений с диска (disk reads) выполненных SQL-выражением (по умолчанию 1, 000);
- Число разборов (parse calls), вызванных SQL-выражением (по умолчанию 1000);
- Число попаданий в кэш данных (buffer gets), выполненных SQL-выражением (по умолчанию 10000);
- Размер разделяемой памяти, используемой SQL-выражением (по умолчанию 1 Мб).
Если стат-данные по использованию ресурсов SQL-выражения (хотя бы одного из перечисленных) превышают значения, указанные в фильтрах, оно включается в отчет. Значения для фильтров можно указывать различными для каждого снимка.
Снятие снимка уровня 5 и выше будет зависеть от размера разделяемого пула и количества содержащихся в нем SQL-выражений.
Значения фильтров SQL-выражений для каждого снимка хранятся в таблице STATS$STATSPACK_PARAMETER.
Уровень 6 – включает в себя всю статистику уровня 5, плюс дополнительные данные по планам выполнения и использования ресурсов SQL-выражениями. Например, содержит полезную во многих случаях информацию о том, изменялся ли план выполнения SQL-выражения.
Уровень 10 – включает в себя всю статистику уровня 6, плюс дополнительная информация по родительским (parent) и подчиненным (child) защелкам.
Аудит
Аудит Oracle может помочь в определении неавторизованного доступа или внутреннего злоупотребления по отношению к информации, содержащейся в базе данных.
Простой набор типовых действий аудита в работающей БД должен быть активен постоянно. Необходимый минимум включает в себя отслеживание доступа пользователей, использование системных привилегий и изменение в структуре базы данных. Этот основной набор не покажет неудавшихся попыток доступа к специфическим данным, которые не должны быть доступны; тем не менее, он даст достаточно простой обзор " некорректного" доступа или использования привилегий. Если служащий подозревается в недозволенных действиях или ожидается атака, тогда может быть применен более детализованный аудит для специфических таблиц. С точки зрения управления БД, аудит изменения данных для всех таблиц не так уж практичен и может повлиять на производительность системы в целом. Аудит доступа для изменения данных следует использовать для таблиц, имеющих особо важное значение (например, заработная плата сотрудников в базе данных HR).
Как могут быть проконтролированы пользователи Oracle
Стандартные команды аудита позволяют контролировать все системные и объектные привилегии доступа к любым таблицам или представлениям базы данных на уровне команд select, delete, insert или update.
Аудит может быть запущен как для успешных (SUCCESSFULL), так и для неуспешных (NOT SUCCESSFULL) попыток или для тех и других сразу. Как индивидуально для каждого пользователя, так и для всех пользователей сразу, он может выполняться на сессионном уровне или на уровне действия (доступа). На уровне действия одна запись создается для одного действия, а на сессионном - одна запись для всех контролируемых операций одной сессии.
Какие проблемы могут возникнуть при использовании аудита
Часто аудит воспринимается как сложный и медленный. Причина этому – обычная некомпетентность. Естественно, если большинство опций аудита будут включены, тогда получающийся в результате журнал может быть большим и трудным для интерпретации и управления. Кроме того, если аудит задействован на всех таблицах и представлениях базы, то это может повлиять и на производительность. Всякий раз, когда выполняемое действие контролируется аудитом в журнал вносится запись; очевидно, что чем интенсивнее используется аудит, тем больше записей будет записано в системное табличное пространство исключительно для аудита.
Основное правило настройки аудита – это простота и предусмотрительность. Выполняйте аудит и детальный мониторинг только тех операций и объектов, информация о которых действительно необходима. Важно то, что с помощью простых отчетов можно выявить нарушения, среди действий, зафиксированных в журнале аудита. Отметим также, что при инсталляции Oracle по умолчанию аудит выключен, и Oracle не поставляется с какими-нибудь стандартными установками аудита по умолчанию или отчетами для анализа созданного журнала аудита.
Стандартные команды аудита не разрешают контролировать операции на уровне строк. Так же невозможно отслеживать действия привилегированных пользователей, таких как SYS или " as sysdba" до версии Oracle 10gR2.
Возможности аудита Oracle
Включение аудита необходимого действия осуществляется с помощью команды SQL AUDIT. Может указываться три уровня аудита:
§ На уровне объектов схемы. Фиксируются сведения о доступе к конкретным объектам БД.
§ На уровне SQL-выражений. Фиксируются сведения о выдаче определенных SQL-выражений.
§ На уровне системных привилегий. Фиксируются сведения о общесистемные действия (из числа регулируемых системными привилегиями), выполняемые пользователями.
Для более детального аудита указываются дополнительные опции:
§ BY имя_пользователя – при аудите SQL-выражений и системных привилегий будут фиксироваться только те действия, которые осуществлял указанный пользователь.
§ WHENEVER SUCCESSFUL/WHENEVER NOT SUCCESSFUL – для любого вида аудита можно указывать, будут ли фиксироваться успешные, либо безуспешные попытки выполнить то или иное действие. Последнее обычно возникает, когда пользователь не имеет достаточно привилегий.
§ BY SESSION/BY ACCESS – для любого вида аудита можно указать, признак фиксации регистрируемых действий: либо одна запись на все время сеанса при первом выполнении действия, либо отдельная запись на каждое действие в течение сессии.
Задачу аудита базы данных Oracle не следует ограничивать только лишь использованием команд аудита; так же успешно могут быть применены и другие технологии. Приведем некоторые основные методы, которые могут быть использованы для аудита базы данных Oracle:
Все привилегии, которые могут быть предоставлены пользователю или роли БД, могут быть проконтролированы. Сюда включены доступ на чтение, запись и удаление объектов на табличном уровне. Для более детализованного аудита можно задействовать триггеры.
Системные триггеры
Эта возможность появилась в Oracle 8 и разрешает выполнение триггера, срабатывающего на некоторое системное событие. Сюда включены запуск и останов базы данных, попытки входа и выхода, создание, изменение и удаление объектов схемы. С помощью автономных транзакций, можно записывать в журнал упомянутые системные события.
Update, delete и insert триггеры
Это “вторая линия обороны”, которая позволяет понять действия пользователей на более детальном уровне. Для того, что бы отслеживать изменения в базе на уровне столбца и строки, можно написать триггеры, которые позволят полностью сохранять данные, до или после выполненного действия. Использование этого типа контроля очень ресурсоемко, так как создается и хранится много дополнительных записей. Кроме того, что существует еще один недостаток, связанный с этим методом - доступ на чтение нельзя отследить с помощью обычных триггеров базы данных.
Детализированный (fine-grained) аудит
Детализированный аудит решает проблему отслеживания доступа на чтение. Данная возможность основана на внутренних триггерах, срабатывающих, при разборе какой-нибудь части SQL-предложения. Это очень эффективно, так как SQL-предложение разбирается единожды для аудита и выполнения. Эта возможность использует предикаты, которые определены и проверяются каждый раз, когда происходит доступ к соответствующим объектам. Детализированный аудит управляется PL/SQL пакетом который называется DBMS_FGA. Созданная PL/SQL процедура выполняется каждый раз, когда выполняется, соответствующее ей, действие с предикатом. Этот метод позволяет контролировать не только DML-операции на уровне строк и столбцов, но и предложения чтения.
Аудит доступа к базе данных
Контроль доступа к БД является фундаментальной задачей для того, что бы определить кто, когда и откуда имеет доступ к информации. Неудачные попытки, так же как и попытки входа в нерабочее время в течение дня быть отслежены.
Аудит изменений в структуре базы данных
В производственной базе данных никому из пользователей никогда не следует изменять структуру схемы. АБД следует вносить изменения в специально отведенное для этого время. Какие-либо другие изменения следует рассматривать как подозрительные. Наблюдение за структурными изменениями может указать на некорректное использование БД.
Третья задача – это аудит использования любых системных привилегий.
Заключительная группа команд аудита, которая может быть задействована – это организация контроля за любыми изменениями данных при помощи самих объектов. Этот вопрос зависит от специфики инсталляции и приложения.
Основная конфигурация
Записи аудита могут помещаться либо в аудиторскую таблицу базы данных, либо в аудиторский журнал операционной системы. Запись аудита в журнал операционной системы в некоторых случаях более защищена, но эта возможность доступна не для всех платформ и ее специфика зависит от платформы. В этой статье в качестве места хранения для журнала аудита мы будем использовать базу данных.
Аудит включается для записи в базу данных добавлением следующей строки в файле init.ora. Символьная связь к нему обычно может быть найдена в $ORACLE_HOME/dbs.
audit_trail = db
После этого базу данных необходимо перезапустить. Простая проверка покажет, что аудит действительно включен.
SQL> select name, value from v$parameter 2 where name like 'audit%'; NAME VALUE------------------------------ ------------------------------audit_trail DBaudit_file_dest? /rdbms/audit
Но контролируемые действия не отслеживаются до тех пор, пока эти действия не заданы явно; это верно, кроме случаев привилегированного доступа к базе данных, запуска и останова базы данных, структурных изменений, таких как добавление файла данных. Эти действия отслеживаются в файле операционной системы в $ORACLE_HOME/rdbms/audit до тех пор пока audit_file_dest не переопределено в файле init.ora. В Windows эти события появляются в Event Viewer.
Для того, что бы проверить наличие того, что какие-нибудь привилегии или выражения уже используются для аудита, сделайте следующее:
SQL> select * from dba_stmt_audit_opts 2 union 3 select * from dba_priv_audit_opts; no rows selectedЧто бы найти какие объекты уже контролируются аудитом, запросите представление dba_obj_audit_opts.
Для начала включите аудит для попыток доступа к базе данных:
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 NOCTXSYS AUDIT SYSTEM NODBA AUDIT ANY YESDBA AUDIT SYSTEM YESIMP_FULL_DATABASE AUDIT ANY NOMDSYS AUDIT ANY YESMDSYS AUDIT SYSTEM YESWKSYS AUDIT ANY NOWKSYS AUDIT SYSTEM NO 9 rows selected.
Выше приведенные результаты принадлежат базе данных Oracle 10g. Пользователи по умолчанию MDSYS, CTXSYS и WKSYS были бы неплохой мишенью для атакующего, так как любые действия аудита могут быть выключены любым из этих пользователей, что бы скрыть любые предпринятые действия.
Как только пользователи начнут присоединяться к БД, в журнал аудита начнет поступать информация.
Теперь давайте установим аудит для контроля изменений в схеме. Можно отслеживать изменения любых объектов БД: таблиц, индексов, кластеров, представлений, последовательностей, процедур, триггеров, библиотек и т.д. В этом примере аудит будет включен для группы объектов.
set head off feed off pages 0spool aud.lisselect 'audit '||name||'; 'from system_privilege_mapwhere (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%')unionselect 'audit '||name||'; 'from system_privilege_mapwhere (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%')unionselect 'audit '||name||'; 'from system_privilege_mapwhere (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%')unionselect 'audit '||name||'; 'from system_privilege_mapwhere (name like 'EXECUTE%INDEX%'or name like 'EXECUTE%PROCEDURE%'or name like 'EXECUTE%LIBRARY%')/spool off@@aud.lis
Данный скрипт выведет набор команд аудита в спул файл, который затем запустится для выполнения команд аудита. Все, что «аудируется» можно увидеть, используя следующий запрос:
select audit_option, success, failurefrom dba_stmt_audit_optsunionselect privilege, success, failurefrom dba_priv_audit_opts/ ALTER ANY CLUSTER BY ACCESS BY ACCESSALTER ANY INDEX BY ACCESS BY ACCESSALTER ANY INDEXTYPE BY ACCESS BY ACCESS…EXECUTE ANY INDEXTYPE BY SESSION BY SESSIONEXECUTE ANY LIBRARY BY SESSION BY SESSIONEXECUTE ANY PROCEDURE BY SESSION BY SESSIONSQL>
Каждый раз, когда пользователь пытается что-нибудь затронуть в базе данных, на что включен аудит, ядро Oracle проверяет действие и создает или обновляет (в случае одной записи для сессии) запись в таблице AUD$, владельцем которой является пользователь SYS. Эта таблица по умолчанию находится в табличном пространстве SYSTEM. Кстати говоря, это само по себе может стать причиной проблемы при атаке – отказ в обслуживании. Если табличное пространство SYSTEM заполнится, то база данных зависнет.
AUD$ - особенная таблица словаря данных, так как только пользователь SYS имеет право удалять из нее записи. Если журнал аудита включен и пишется в базу данных, то число записей в этой таблице необходимо внимательно контролировать, чтобы удостовериться, что она не растет слишком быстро, и не заполнила все системное табличное пространство. Стратегия очистки нуждается в адаптации, что бы сохранять размер таблицы и если необходимо архивировать записи журнала аудита для будущего использования. Одна из тактик может состоять в том, что бы копировать записи в итоговую таблицу, созданную для выполнения спецпроверки с целью выявления злоупотреблений. Эти итоговые таблицы могут располагаться в отдельной базе данных для увеличения защищенности. После копирования таблица sys.aud$ может быть усечена.
Только пользователи, которым предоставлен специальный доступ к таблице SYS.AUD$ могут читать, изменять и удалять данные из нее. По умолчанию этими правами владеет SYS, но эти действия может выполнять любой другой пользователь, наделенный необходимыми правами. Существуют две специальные роли, которым разрешен доступ к таблице SYS.AUD$ на select и delete, это роли DELETE_CATALOG_ROLE и SELECT_CATALOG_ROLE. Эти роли не следует предоставлять обычным пользователям.
Возвращаясь к примерам, наши пользователи уже вошли в систему и проработали целый день и создали некоторые записи аудита. Эти записи могут быть просмотрены различными способами:
- Путем выборки записей из SYS.AUD$.
- Путем выборки записей из dba_audit_trail.
- Путем выборки записей из dba_audit_session – это представление показывает только лишь события начала и завершения сессии.
Простое SQL-предложение может показать попытки соединения в деталях:
col username for a15col terminal for a6col timestamp for a15col logoff_time for a15col action_name for a8col returncode for 9999select username, terminal, action_name, to_char(timestamp, 'DDMMYYYY: HHMISS') timestamp, to_char(logoff_time, 'DDMMYYYY: HHMISS') logoff_time, returncodefrom dba_audit_sessionSQL> /USERNAME TERMIN ACTION_N TIMESTAMP LOGOFF_TIME RETURNCODE--------------- ------ -------- --------------- --------------- ----------SYS pts/1 LOGOFF 09042003: 051046 09042003: 051641 0ZULIA pts/1 LOGON 09042003: 051641 1017SYS pts/1 LOGOFF 09042003: 051649 09042003: 053032 0SYS pts/2 LOGOFF 09042003: 052622 09042003: 053408 0ZULIA pts/1 LOGON 09042003: 053032 1017
Существует несколько простых злоупотреблений, которые могут быть обнаружены при исследовании пользовательского доступа в базу данных. Для примера, взглянем на этот отчет и обнаружим следующее:
Неудачные попытки входа
Они могут означать попытки атакующего получить неавторизованный доступ в базу данных. Нижеследующий SQL ярко демонстрирует это:
select count(*), username, terminal, to_char(timestamp, 'DD-MON-YYYY') from dba_audit_session where returncode< > 0 group by username, terminal, to_char(timestamp, 'DD-MON-YYYY'); COUNT(*) USERNAME TERMIN TO_CHAR(TIM---------- --------------- ------ ----------- 1 BILL pts/3 09-APR-2003 3 FRED pts/3 09-APR-2003 4 ZULIA pts/1 09-APR-2003
Здесь можно заметить два возможных злоупотребления, первое – это то, что пользователь Zulia пытается войти в систему и получает отказ четыре раза в один и тот же день. Возможно, пользователь забыл свой пароль или может быть кто-то пытается его угадать. Если изменить SQL, как показано ниже, то это даст более детальную информацию:
select count(*), username, terminal, to_char(timestamp, 'DD-MON-YYYY'), returncode from dba_audit_session group by username, terminal, to_char(timestamp, 'DD-MON-YYYY'), returncode; COUNT(*) USERNAME TERMIN TO_CHAR(TIM RETURNCODE---------- --------------- ------ ----------- ---------- 1 BILL pts/3 09-APR-2003 1017 1 EMIL pts/1 09-APR-2003 0 1 EMIL pts/2 09-APR-2003 0 1 EMIL pts/3 09-APR-2003 0 1 EMIL pts/4 09-APR-2003 0 3 FRED pts/3 09-APR-2003 1017 3 SYS pts/1 09-APR-2003 0 1 SYS pts/2 09-APR-2003 0 1 SYSTEM pts/5 09-APR-2003 0 4 ZULIA pts/1 09-APR-2003 1017 1 ZULIA pts/1 09-APR-2003 0 11 rows selected.
Отчет показывает, что пользователь успешно вошел в систему с этого же терминала, в этот же день. Проверяйте число неудачных попыток входа в систему каждый день. Те пользователи, для которых, число неудачных попыток входа превышает пороговое значение, должны быть изучены.
Попытки доступа несуществующих пользователей в базу данных
Одно интересное дополнение к приведенному выше SQL позволяет отыскать попытки входа в систему под несуществующим пользователем. В этом случае тоже будут созданы записи аудита. Следующий SQL иллюстрирует это:
select username, terminal, to_char(timestamp, 'DD-MON-YYYY HH24: MI: SS') from dba_audit_session where returncode< > 0 and not exists (select 'x' from dba_users where dba_users.username=dba_audit_session.username) USERNAME TERMIN TO_CHAR(TIMESTAMP, 'D--------------- ------ --------------------FRED pts/3 09-APR-2003 17: 31: 47FRED pts/3 09-APR-2003 17: 32: 02FRED pts/3 09-APR-2003 17: 32: 15BILL pts/3 09-APR-2003 17: 33: 01
Возможно это тоже злонамеренные действия. Все попытки войти в систему под несуществующим пользователем следует проверять и расследовать каждый день.
Попытки доступа в базу данных в нерабочее время
Следует выполнять проверки попыток доступа в базу данных во внерабочие часы. Им может оказаться обычная сверхурочная работа, но также легко - неавторизованный доступ. Его можно проверить следующим выражением:
select username, terminal, action_name, returncode, to_char(timestamp, 'DD-MON-YYYY HH24: MI: SS'), to_char(logoff_time, 'DD-MON-YYYY HH24: MI: SS') from dba_audit_session where to_date(to_char(timestamp, 'HH24: MI: SS'), 'HH24: MI: SS') < to_date('08: 00: 00', 'HH24: MI: SS') or to_date(to_char(timestamp, 'HH24: MI: SS'), 'HH24: MI: SS') > to_date('19: 30: 00', 'HH24: MI: SS'); USERNAME TERMIN ACTION_N RETURNCODE TO_CHAR(TIMESTAMP, 'D TO_CHAR(LOGOFF_TIME, ---------- ------ -------- ---------- -------------------- --------------------SYS pts/1 LOGOFF 0 09-APR-2003 20: 10: 46 09-APR-2003 20: 16: 41SYSTEM pts/5 LOGOFF 0 09-APR-2003 21: 49: 20 09-APR-2003 21: 49: 50ZULIA pts/5 LOGON 0 09-APR-2003 21: 49: 50EMIL APOLLO LOGON 0 09-APR-2003 22: 49: 12
Приведенные выше SQL показывает любые соединения до 8: 00 утра и после 7: 30 вечера. Любые соединения, особенно те, которые выполнены привилегированными пользователями, такими как SYS или SYSTEM, должны быть исследованы. Особенное внимание следует обратить на то, откуда был произведен доступ. Например, если привилегированный доступ выполнен с машины, которая не находится в отделе администратора, администратор должен выяснить зачем он производился.
Проверка пользователей, которые используют общую учетную запись в базе данных
Следующее выражение SQL ищет пользователей, которые потенциально могут использовать общую учетную запись в базе данных:
select count(distinct(terminal)), username from dba_audit_session having count(distinct(terminal))> 1 group by username; COUNT(DISTINCT(TERMINAL)) USERNAME------------------------- ---------- 4 EMIL 3 SYS 3 ZULIA
Здесь показано, что три пользователя входили в систему более чем с одного места. Дальнейшая проверка может показать время, что бы увидеть, работали ли они одновременно. Установите временной интервал для данной проверки в один день. Приведенный выше SQL показывает лишь направление исследования, без лишних сложностей. И конечно, обнаруженные учетные записи должны быть изучены дополнительно.
Множественные попытки доступа под различными учетными записями с одного и того же терминала
Заключительный пример применяется для нахождения места, откуда фиксировались попытки получения доступа под множеством учетных записей. Данное выражение SQL довольно простое и к нему может быть добавлена группировка по дню, а также выведены пользователи для каждого терминала. Рассмотрите простой пример для иллюстрации этой идеи:
select count(distinct(username)), terminal from dba_audit_session having count(distinct(username))> 1 group by terminal; COUNT(DISTINCT(USERNAME)) TERMIN------------------------- ------ 3 pts/1 2 pts/2 3 pts/3 3 pts/5
Данный отчет может показать кого-либо, пытающегося получить доступ перебором учетных записей и паролей, но сюда же могут попасть законопослушные пользователи, которые используют различные учетные записи для различных аспектов своей работы. В любом случае администратору следует выяснить это.
В следующем примере, аудит был настроен для определения изменений, выполняемых в схеме базы данных. Сюда можно отнести создание новых объектов или попытки изменения уже существующих.
Простой SQL, приведенный ниже, покажет любые сведения из журнала аудита, имеющие отношения к созданным или измененным объектам:
col username for a8col priv_used for a16col obj_name for a22col timestamp for a17col returncode for 9999select username, priv_used, obj_name, to_char(timestamp, 'DD-MON-YYYY HH24: MI') timestamp, returncodefrom dba_audit_trailwhere priv_used is not nulland priv_used< > 'CREATE SESSION'/ ZULIA CREATE TABLE STEAL_SALARY 09-APR-2003 20: 07 0PETE CREATE PROCEDURE HACK 09-APR-2003 20: 42 0
Этот пример показывает, что пользователь ZULIA создал таблицу, а пользователь PETE писал PL/SQL процедуру. Любые изменения такого рода, в производственной базе данных, должны быть исследованы. Намного более специфичные злодеяния могут быть обнаружены в отношении изменений объектов и схемы, но в целом, пользователи не должны иметь возможности менять что-либо в производственной базе данных.
Защита базы данных от рассмотренных злонамеренных действий
Рассмотренные примеры - всего лишь основа для использования возможностей аудита Oracle. Настройка аудита – это один из первых шагов для обеспечения безопасности БД. Использование аудита должно быть частью общего плана безопасности организации, в который входит и Oracle. Следует регулярно контролировать состояние конфигурации БД на наличие вновь обнаруженных уязвимостей, которые могут стать брешью в информационной безопасности системы.
Из-за своей сложной природы и большого числа различных параметров, сервер Oracle может быть по-разному настроен, однако, чтобы наилучшим образом обеспечить безопасность, необходимо всегда следовать принципу наименьших привилегий. Как только БД станет частью общего плана безопасности и будет корректно сконфигурирована и регулярно проверяема, тогда аудит следует рассматривать как важную часть этой общей стратегии.
В основном, не представляйте какие-либо привилегии обычным пользователям в производственной базе данных, удалите большинство привилегий PUBLIC, удалите, заблокируйте или измените пароли всех учетных записей по умолчанию. Убедитесь в том, что пользователи придерживаются политики безопасности при работе с паролями и включена функция управления паролями.
Важно, чтобы настройки аудита планировались с точки зрения производительности и удобства использования. Журнал аудита также требует поддержки (очистка, перенос).
Аудит Oracle очень мощное средство и существует достаточно большое количество опций его настройки в БД Oracle. Существует возможность контролировать почти все с помощью стандартных команд, но не на строковом уровне. Если вам необходим высоко-уровневый аудит используйте стандартные функции что бы посмотреть общую активность, и затем рассмотреть исследуйте нужное в более мелких деталях.
Так как возможно контролировать почти все типы действий в БД Oracle, используя стандартные функции аудита, АБД следует поэкспериментировать, чтобы выбрать наиболее полезные настройки аудита для их организации. Не старайтесь использовать все подряд. Кроме всего прочего, предопределите, какие данные будут созданы в журнале аудита и какие злонамеренные действия с их помощью можно выявить. Напишите отчеты, чтобы проверить журнал аудита и очищайте его регулярно. Анализируйте данные этих отчетов каждый день и предпринимайте соответствующие действия.
Для более детального аудита, используйте триггеры базы данных и детализированный (fine grained) аудит. Помните, что для использования и реализации этих методов необходим опыт программирования, так что они должны быть внимательно рассмотрены. Много полезной информации может быть собрано без аудита, на строковом уровне. Кроме всего прочего, внедрите принцип наименьших привилегий, что бы избегнуть изменений и чтений данных пользователями, для которых они не предназначены.
|
|