4. Если есть пользовательские бюджеты общего назначения, например DATA ENTRY CLERK, которыми пользуются многие в системе, то маркирование записей с помощью этого имени не очень-то поможет в выявлении реального лица, вощедщего в систему. Кроме того, если есть удаленные пользователи, которые обращаются к таблицам в нащей системе с помощью распределенных транзакций, то в качестве пользовательского бюджета, применяемого для маркирования записи, может оказаться общий бюджет, используемый удаленными пользователями. В этом случае данные аудита также скажут нам мало полезного.

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

6. Мы регистрируем только создание и вставку. Записей об операциях запроса данных у нас нет, и мы не знаем, кто и какие данные читал.

7. Журнал аудита не позволяет определить, что еще, кроме попытки соединиться с системой под данным пользовательским именем и в данное время, было сделано в рамках этой же транзакции.

Использование средств аудита Oracle?

До настоящего момента мы говорили об аудите в общем. В этом разделе мы рассмотрим некоторые стандартные средства аудита, предусмотренные в Огас1е7. Поначалу эти средства, возможно, покажутся очень мощными и гибкими. К сожалению, при близком рассмотрении оказывается, что многие из них не очень эффективны. Как правило, они регистрируют только события, не записывая значения данных, связанных с событием. В голову сразу приходят щоколадные чайники.*

Ссылки на шоколадные чайники в этой книге встречаются неоднократно, и, конечно, ничего подобного не существует. Просто есть старая английская поговорка: As much use as a cholocate teapot ( Пользы, как от шоколадного чайника , т.е. вообще никакой пользы). Много лет назад один из авторов работал в английском отделении одной североамериканской софтверной компании, отдел исследований и разработок которой английские сотрудники называли фабрикой шоколадных чайников.

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

AUDIT SESSION;

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

Допустим, что все данные нашей БД, за исключением таблицы PAYROLL, содержащей секретную информацию, довольно малоинтересны для случайного (или не совсем случайного) пользователя. Очевидно, что мы введем правила защиты, которые ограничат круг пользователей, имеющих доступ к этой таблице (подробнее мы рассмотрим этот вопрос ниже, когда перейдем к обеспечению безопасности). Однако часто люди относятся к своим паролям очень беспечно. Некоторые вообще оставляют без присмотра свой экран после входа в систему. Чтобы обеспечить безопасность этой таблицы, мы задаем для нее аудит посредством следующей команды:

AUDIT ALL ON LIVE.PAYROLL BY ACCESS;

Эта команда заставляет Oracle регистрировать детали всех операций над таблицей PAYROLL. Фраза BY ACCESS обеспечивает наличие элемента для каждого случая доступа, а не только одного элемента на тип доступа для данного сеанса. Oracle заносит все аудиторские действия в одну таблицу SYS.AUD$, и, если включено много журналов аудита, эта таблица становится очень загроможденной. К счастью, Oracle обеспечивает ряд представлений, позволяющих просмотреть содержимое AUD$ в виде структурированных наборов (см. CATAUDIT.SQL).

Аудиторские представления позволяют запрашивать доступы к таблице PAYROLL по пользователям, по типам доступа, по дате и времени доступа. Однако мы не можем установить, что было изменено в таблице: персональные сведения (например, адрес) или данные о зарплате. Жаль, что это средство аудита Oracle может сообщить нам так немного. Если существует подозрение, что кто-то подключается как пользователь с ролью, позволяющей модифицировать таблицу PAYROLL, исправляет зарплату до начисления, а затем делает ее прежней, то для определения этого нам нужно намного больше информации, чем могут дать средства аудита Oracle.

Причина, по которой средства аудита в Oracle должны включаться как на уровне экземпляров, так и операторами AUDIT, предельно проста. Если табличное пространство SYSTEM при включенном аудите заполнилось и места для записей аудита уже нет, то освободить место невозможно. Почему?

Потому что для этого пришлось бы создать запись аудита, а ее нельзя создать из-за отсутствия места.

Решение состоит в том, чтобы разрушить экземпляр (при таких обстоятельствах вряд ли можно будет выполнить SHUTDOWN NORMAL) и перезапустить его с отключенным аудитом на уровне экземпляров, чтобы вы (или администратор БД) смогли заняться проблемой освобождения места. Конечно, пока все это происходит, работать придется без аудита.

Если такое с вами хоть раз случалось, вы понимаете, почему ПО анализа журналов так привлекает компьютерных аудиторов. При наличии такого анализатора каждое внесенное в БД изменение остается в журнале, и эти журналы имеют возрастающие порядковые номера, чтобы аудитор мог увидеть, какого именно журнала нет. Кроме того, журнал содержит старые и новые значения данных для операций обновления, а также старые значения удаленных записей. Бывалый пользователь сможет с помощью анализатора журналов проверить, изменялись ли какие-либо таблицы без отражения изменений в журнале аудита!

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

Углубленный аудит с помощью триггеров

В этом разделе мы продолжим предыдущий пример, но расширим сферу аудита. На этот раз мы введем дополнительную таблицу, которая будет содержать полный хронологический журнал всех изменений, внесенных в столбец SALARY таблицы PAYROLL. Поскольку регистрация этой информации влечет за собой дополнительные расходы, в некоторых организациях эту таблицу можно включать периодически - для получения случайных выборок или только если есть подозрение, что возникла проблема. С технической точки зрения, второй метод можно назвать закрытием двери конюшни после того, как лошадь убежала. На наш взгляд, если вам нужен журнал аудита, то следует использовать его постоянно.

SQL-код для создания этой таблицы и код поддерживающего ее триггера приведены ниже. Отметим, что в первичном ключе таблицы аудита используются дата и время; предположение о том, что ничью зарплату нельзя изменить дважды за одну секунду, кажется разумным, а если все-таки это имеет место, то ваша озабоченность по поводу безопасности оправдана.

CREATE TABLE 3alary change log (emp# NUMBER(10) NOT NULL

,tran3action dt DATE NOT NULL

,user name VARCHAR2(30) NOT NULL

,old 3al value NUMBER(8,2) NOT NULL ,new sal value NUMBER(8,2) NOT NULL