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

Другие вопросы, относящиеся к этому методу проектирования, описаны в главе 17.

Советы по аудиту

В этом разделе мы даем еще несколько советов по аудиту.

Не отключайте триггеры аудита

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

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

Поиск пользовательского илгеии

На многих узлах Oracle используются регистрационные идентификаторы общего назначения (например, PRODUCTION), и все несколько сотен пользователей такого узла могут быть подключены к Oracle под одинаковым пользовательским именем. По сути дела, это является условием эффективного использования среды менеджера обработки транзакций. В этим случае аудит на базе пользовательского имени Oracle не всегда эффективен. Рещение, как и в предыдущем подразделе, состоит в использовании пакета с глобальной переменной и обязательном представлении пользователя этому пакету до того, как триггеры аудита разрешат обновление контролируемых таблиц. Этот подход, который рассматривается ниже в разделе Безопасность , не очень приветствуется в среде пользователей Oracle, но дает высокую эффективность.

Роль анализа журналов в аудите

Если вам доступен анализатор журналов, то одно из возможных направлений проверки состоит в том, чтобы установить, сработали триггеры или нет. Так, если использовать триггер для регистрации всех изменений в таблице PAYROLL, то путем анализа журнала можно убедиться, что каждая операция над таблицей сопровождалась записью аудита.

Журналы, которые сохраняются путем архивации почти на всех узлах, выполняющих обновление важнейших данных, предоставляют аудитору массу возможностей:

Эти журналы находятся вне базы данных, поэтому никакой уровень привилегий в Oracle не даст возможности получать к ним доступ через SQL. К этим журналам можно обратиться только из операционной системы на файловом уровне.

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

Журналы содержат новые значения и старые значения, связанные с каждой DML-операцией, за исключением прямой загрузки и невосстановимых копий из одной таблицы в другую.

Они ведутся практически независимо, так как Oracle записывает их независимо от того, будут они использоваться или нет.

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

Предупреждение

Нам приходилось видеть и попытки использовать тот факт, что представление V$SQLAREA в столбце SQLTEXT содержит последний SQL-оператор. Настоятельно рекомендуем не делать так. Этот механизм позволяет увидеть только первые 1000 символов SQL-операторов. Сюда включаются все рекурсивные SQL-операторы, и их нельзя отличить от выданных пользователем. Связанные переменные не вычисляются, поэтому во многих случаях нельзя увидеть фактические значения столбцов. Кроме того, поскольку это представление содержит SQL-код, выданный всеми пользователями системы, то трудно разобраться в том, кто и что вьщавал.

Безопасность

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

Средства безопасности Oracle? можно разделить на две кагегории:

безопасность доступа определяет, кто попадает в приложение и какую его часть этот кто-то может использовать (или какая часть доступна для него);

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

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

Примечание

Если вы проектируете систему, для которой требуется более высокий уровень безопасности, то описанные в этом разделе средства могут оказаться недостаточными. В этом случае необходимо использовать продукт Trusted Oracle. Мы не описываем его в нащей книге, но вы можете воспользоваться множеством материалов, предоставляемых .Oracle по данному предмету.

Безопасность доступа

В Oracle? имеется целый ряд механизмов для идентификации и верификации пользователей. Самый простой из них - заставить каждого пользователя при первом подключении указывать свое имя и пароль. Эта верификация должна выполняться независимо от того, какое внещнее интерфейсное средство используется для доступа к базе данных. Идея состоит в том, чтобы допустить пользователя к работе со средствами базы данных только после того, как он установит санкционированное соединение с ней. Имя пользователя и пароль сверяются с указанными в таблице SYS.USER$, куда пароль заносится в зашифрованной форме. Администраторы БД видят только зашифрованный пароль в таблице (расшифрованный не видит никто). Мы не знаем ни одного человека, который ухитрился расшифровать пароль в среде Oracle.

Большинство пользователей рассчитывают на то, что им придется входить в систему только один раз (и правильно делают). Если они указали имя и пароль при входе в операционную систему - особенно если средства безопасности этой ОС работают хорошо - то почему они должны указывать другое имя и другой пароль для подключения к Oracle? Для решения этой проблемы в Oracle введен механизм, известный как ОРЗ$-регистрация: если пользователь ввел пустое имя (и не указал пароль), Oracle подключает его к базе данных как соответствующего Oracle-пользователя, принимая идентификационные данные, полученные операционной системой. Эти бюджеты называются ОР8$-бюджетами, потому что в версии 5 именем пользователя