| Создание журнала аудита в XML-формате
Один
из краеугольных камней инфраструктуры системы безопасности в сервере
Oracle Database – контролируемость (accountability): возможность
регистрации действий пользователей в системе базы данных. Когда
действия происходят (например, пользователь обновляет определенную
таблицу), сервер базы данных регистрирует эти события в журнале аудита
(audit trails), который может находиться либо в базе данных в
специальной таблице AUD$ схемы SYS, либо в специальных файлах
операционной системы (ОС). Когда эти данные хранятся в базе данных, они
защищаются резервным копированием этой базы, и администратору базы
данных легко запрашивать их, используя обычные операторы языка SQL.
Однако в этом случае после совершения злонамеренного обновления любой,
кто имеет доступ к схеме SYS, потенциально может стереть из журнала
аудита соответствующие данные.
Журнал аудита в среде ОС
принадлежит владельцу программного обеспечения сервера Oracle, поэтому
его хранение в специальных файлах ОС – один из способов защиты от
доступа пользователей с привилегиями SYS. Вы можете иметь отдельные
учетные записи ОС для администраторов базы данных, которые позволяют им
администрировать базу данных и даже они могут иметь привилегии SYSDBA,
но эти привилегии не разрешают администраторам удалять или изменять
файлы журнала аудита. Использование файлов журнала аудита в файловой
системе (с аккуратным разграничением доступа на уровне ОС и базы
данных) может удовлетворить требования по безопасности многих
организаций.
Другое преимущество журнала аудита в среде ОС
заключатся в его доступности, даже если экземпляр сервера базы данных
не работает. Неудобство такого журнала состоит в том, что для его
интерпретации необходимо анализировать файлы журнала аудита, используя
инструменты, подходящие для этой ОС и формата файлов.
В сервере
Oracle Database 10g Release 2 функциональные возможности аудита на
уровне ОС были расширены – теперь в среде ОС можно создавать файлы
журнала аудита в стандартном XML-формате. XML-документы легко
распознаваемы, существует много инструментов (работающих во многих ОС)
для чтения и форматирования этих документов, поэтому такие журналы
аудита легко анализировать. Для облегчения запросов к содержимому этих
журналов аудита есть также соответствующий SQL-интерфейс. В этой
статье, я покажу, как настраивать журнал аудита в XML-формате и
эффективно использовать его.
Начальная настройка
По умолчанию
аудит в сервере Oracle Database 10g Release 2 не включен. Для его
включения и записи данных аудита в XML-формате нужно только вставить в
файл параметров инициализации следующую строку:
AUDIT_TRAIL = XML
Это – статический параметр, поэтому, чтобы он начал действовать, необходимо перезапустить экземпляр сервера базы данных.
Подготовим для этой статьи демонстрационные данные, выполнив с привилегиями SYSDBA следующие операторы:
SQL> CREATE USER bank IDENTIFIED BY bank;
SQL> GRANT CONNECT, RESOURCE TO bank;
SQL> CONNECT bank/bank
SQL> CREATE TABLE accounts (accno NUMBER);
SQL> GRANT SELECT ON accounts TO SCOTT;
SQL> INSERT INTO accounts VALUES (104);
Затем включим аудит созданной таблицы.
Здесь мы хотим выполнять аудит всех, кто выбирает данные из таблицы
ACCOUNTS (банковские счета), находящейся в схеме BANK (банк). Для этого
выполним:
AUDIT SELECT ON bank.accounts;
Этот оператор может выполнить (и
включить аудит этой таблицы) пользователь BANK (владелец таблицы) или
любой другой пользователь с системной привилегией AUDIT ANY. После
этого шага, когда любой пользователь, имеющий объектную привилегию
SELECT на эту таблицу, выбирает из нее что-нибудь, этот факт
регистрируется в журнале аудита. Например, если пользователь SCOTT
подключается к системе базы данных и выбирает что-то из этой таблицы,
выполняя:
CONNECT scott/tiger
...
SELECT * FROM bank.accounts WHERE accno = 104;
Этот оператор SELECT генерирует запись
аудита. Параметр AUDIT_TRAIL имеет значение "XML", поэтому запись
генерируется в XML-формате.
Файлы журнала аудита записываются в
каталог, указанный в параметре инициализации AUDIT_FILE_DEST, значение
по умолчанию которого –$ORACLE_BASE/admin/$ORACLE_SID/adump. Вы можете
динамически изменить это местоположение, не перезапуская экземпляр
сервера базы данных. Если вы хотите создавать эти файлы в другом
каталоге, таком, например, как /audit_trail, выполните следующий
оператор (как SYSDBA):
ALTER SYSTEM SET AUDIT_FILE_DEST = '/audit_trail' DEFERRED;
После выполнения этого оператора записи аудита для вновь создаваемых сеансов будут поступать в указанный каталог.
Проверка журнала аудита
Теперь,
когда вы знаете, где генерируются записи аудита, вы можете проверить
журнал аудита. Это будет XML-файл в каталоге, который указан в
параметре инициализации AUDIT_FILE_DEST. Файл, сгенерированный
выполненным действием (оператор SELECT), показан на листинге 1. Давайте
рассмотрим, как интерпретировать его.
xml version="1.0" encoding="UTF-8" ?>
<Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd" xmlns:
xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/
oracleas/schema/dbserver_audittrail-10_2.xsd">
<Version>10.2</Version>
<AuditRecord>
<Audit_Type>1</Audit_Type>
<Session_Id>108802</Session_Id>
<StatementId>9</StatementId>
<EntryId>1</EntryId>
<Extended_Timestamp>2005-10-09T00:20:02.284327</Extended_Timestamp>
<DB_User>SCOTT</DB_User>
<OS_User>oracle</OS_User>
<Userhost>prolin1</Userhost>
<OS_Process>22158</OS_Process>
<Terminal>pts/3</Terminal>
<Instance_Number>0</Instance_Number>
<Object_Schema>BANK</Object_Schema>
<Object_Name>ACCOUNTS</Object_Name>
<Action>103</Action>
<Returncode>0</Returncode>
<Scn>6447392335</Scn>
<SesActions>---------S------</SesActions>
</AuditRecord>
</Audit>
Листинг 1. Журнал аудита в XML-формате.
Запись в журнал аудита осуществляется в обычном XML-стиле:
<Audit>
<Audit_Record>
<Audit_Type>...
<Session_Id>...
<StatementId>...
<EntryId>...
<Extended_Timestamp>...
<DB_User>...
<OS_User>...
<Userhost>...
<OS_Process>...
<Terminal>...
<Instance_Number>...
<Object_Schema>...
<Object_Name>...
<Action>...
<Returncode>...
<Scn>...
<SesActions>...
</Audit_Record>
</Audit>
Запись аудита содержится внутри тегов
<Audit_Record> и </Audit_Record> вместе со специальными
тегами, показывающим детальную информацию, которая находится в записи.
Например, тег <DB_User> показывает пользователя базы данных,
который инициировал действие, сгенерировавшее эту запись. Если сеанс
инициировал более одного действия, то в файле аудита будут показаны
наборы деталей каждого действия, заключенные в теги
<Audit_Record>.
Первый тег каждого набора –
<Audit_Type>, который указывает тип записи аудита. На листинге 1
значение <Audit_Type> – 1, которое указывает на обычный аудит в
XML-формате. Вы можете также использовать XML-формат для детального
аудита, в этом случае тег покажет значение 2. Если вы включите аудит
SYS-операций (по умолчанию аудит этих операций не выполняется),
установив в параметре инициализации AUDIT_SYS_OPERATIONS значение TRUE,
то этот тег покажет значение 4. Наконец, обязательные (mandatory)
записи аудита в XML-формате показываются значением 8. Примеры
обязательных записей аудита: записи о запуске и остановке экземпляра
сервера базы данных, генерируемые независимо от значения параметра
инициализации AUDIT_TRAIL. Все записи журнала аудита в XML-формате
содержат этот тег; он помогает дифференцировать типы этих записей.
Следующий
тег, <Session_Id>, показывает идентификатор сеанса (не системный
идентификатор экземпляра сервера базы данных SID), который сгенерировал
эту запись аудита. Обратите внимание, вы можете увидеть этот
идентификатор в столбце AUDSID представления V$SESSION:
SELECT AUDSID
FROM V$SESSION
WHERE SID = <SID>;
В одном и том же сеансе пользователь мог
выполнять множественные операторы, идентификатор каждого из которых
показывается отдельным тегом <StatementId>. Время регистрации
записи аудита показывается в теге <Extended_Timestamp>. Обратите
внимание, на листинге 1 время регистрации: 2005-10-09T00:20:02.284327.
Время показывается не в часовом поясе местного времени, а в поясе UTC
(Universal Time Coordinated, универсальное синхронизированное время,
также называемое среднем временем по Гринвичу (GMT)); поэтому формат
отметки времени кажется странным.
Остальная часть тегов
показывает пользователя, который выполнял действия, и другие
существенные детали этих действий. Теги <DB_User>,
<OS_User>, <Userhost>, <OS_Process>,
<Terminal>, <Instance_Number>, <Object_Schema>,
<Object_Name> и <Action> показывают соответственно имя
пользователя базы данных, имя пользователя ОС, имя хост-машины, к
которой подключен пользователь, идентификатор процесса ОС,
идентификатор терминала пользователя, номер экземпляра, к которому
подключен пользователь (в среде Oracle Real Application Clusters),
владелец таблицы, с которой работает пользователь, имя этой таблицы и
числовой код типа действия.
Действие, аудит которого показан на
листинге 1, выполнилось успешно, поэтому тег кода возврата
<Returncode> показывает значение 0. Обратите внимание, если бы
это действие выполнилось неудачно, был бы показан номер ошибки сервера
Oracle. Например, если бы вы попытались удалить несуществующую таблицу,
вы получили бы ошибку ORA-00955 и тег <Returncode> показывал бы
число 955.
Это успешное действие было выполнено, когда системный
номер изменения SCN (system change number) был равен 6447392335, как
показывает тег <Scn>. Это очень полезно в ретроспективных
запросах для выяснения значений столбцов в определенный момент времени.
Например, предположим, значение столбца BALANCE (остаток на счете) за
прошедший период времени значительно изменилась. Как вы можете узнать
точное значение, которое видел пользователь? Вы могли бы использовать
ретроспективный запрос и увидеть значение столбца BALANCE , каким оно
было во время этого SCN:
SELECT balance
FROM accounts
AS OF SCN 6447392335
WHERE accno = 104;
Тег <SesActions> показывает
действия, выполненные в сеансе. В теге содержится строка длиной 16
символов, из которых важными являются первые 12. Он показывает
результат действий, выполненных пользователем; в каждой позиции
показывается результат выполнения определенного действия: Alter
(изменение), Audit (аудит), Comment (примечание), Delete (удаление),
Grant (предоставление), Index (индексирование), Insert (вставка), Lock
(блокирование), Rename (переименование), Select (выборка), Update
(обновление) и Flashback (ретроспективная операция).
Например,
на листинге 1 значение тега <SesActions> – "----------S------",
где S (Success) в 10-й позиции указывает на успешное выполнение
действия SELECT. Это означает, что пользователь SCOTT выполнил в сеансе
одно или более успешных действий SELECT и больше никаких других
действий, подлежащих аудиту.
Если пользователь SCOTT также
выполнил бы в этом сеансе успешное действие ALTER, в первой позиции
вместо "-" появилась бы буква S. Если бы при выполнении показанного
выше оператора SELECT произошел сбой, то в 10-й позиции вместо буквы S
появилась бы буква F (Failure). Если бы пользователь SCOTT выполнил
более одного оператора SELECT, и при выполнении некоторых из них
происходили сбои, тогда как другие были выполнены успешно, то 10-й
позиции появилась бы буква B (Both), указывая как на успешное, так и на
неуспешное выполнение действий.
Расширенный аудит
Запись аудита
на листинге 1 показывает действие (оператор SELECT) и объект, над
которым было выполнено это действие (таблица ACCOUNTS). Однако она не
показывает сам SQL-оператор, который выполнил пользователь SCOTT. В
механизме аудита есть также средства расширения его функциональных
возможностей, позволяющие записывать текст этих SQL-операторов. Для их
включения установите в файле параметров инициализации следующий
параметр и перезапустите экземпляр сервера базы данных.
AUDIT_TRAIL = XML, EXTENDED
После включения расширенного аудита пользователь SCOTT выполнил другой оператор SELECT:
SELECT * FROM accounts WHERE accno = :i;
Сгенерированный XML-файл показан на
листинге 2. Он содержит два дополнительных элемента, которые не входили
в файл обычного аудита, показанный на листинге 1:
* <Sql_Bind>#1(3):107</Sql_Bind>
и
* <Sql_Text>select * from bank.accounts where accno = :i</Sql_Text>.
xml version="1.0" encoding="UTF-8" ?>
<Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd" xmlns:
xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/
oracleas/schema/dbserver_audittrail-10_2.xsd">
<Version>10.2</Version>
<AuditRecord>
<Audit_Type>1</Audit_Type>
<Session_Id>108844</Session_Id>
<StatementId>10</StatementId>
<EntryId>1</EntryId>
<Extended_Timestamp>2005-10-10T18:26:18.720548</Extended_Timestamp>
<DB_User>SCOTT</DB_User>
<OS_User>oracle</OS_User>
<Userhost>prolin1</Userhost>
<OS_Process>22584</OS_Process>
<Terminal>pts/3</Terminal>
<Instance_Number>0</Instance_Number>
<Object_Schema>BANK</Object_Schema>
<Object_Name>ACCOUNTS</Object_Name>
<Action>103</Action>
<Returncode>0</Returncode>
<Scn>6447496045</Scn>
<SesActions>---------S------</SesActions>
<Sql_Bind>#1(3):107</Sql_Bind>
<Sql_Text>select * from bank.accounts where accno = :i</Sql_Text>
</AuditRecord>
</Audit>
<Sql_Bind>#1(3):107</Sql_Bind>
<Sql_Text>select * from bank.accounts where accno = :i</Sql_Text>
Листинг 2. Расширенный XML-формат.
Тег
<Sql_Text> показывает текст фактического SQL-оператора,
выполненного пользователем SCOTT. В этом конкретном SQL-операторе есть
переменная связывания (:i). Значение этой переменной показывается в
теге <Sql_Bind> в формате
#ПозицияПеременной(ДлинаЗначенияПеременной):
ЗначениеПеременнойСвязывания. Листинг 2 показывает, что есть только
одна переменная связывания (#1), длина ее значения равна трем символам
(3), а значение – 107. Использование расширенного XML-аудита позволяет
регистрировать SQL-операторы и использованные значения переменных
связывания.
Обратите внимание, расширенный XML-аудит
зафиксировал только тот SQL-оператор, который пользователь SCOTT
выполнил после установки параметра AUDIT_TRAIL=XML, EXTENDED и
перезапуска экземпляра сервера базы данных. Результаты XML-аудита,
показанные на листингах 1 и 2, получены в разных сеансах.
Просмотр файлов аудита в реляционном представлении
XML-файлы,
записанные средствами аудита, – обычные файлы ОС, которые можно
рассматривать любой программой просмотра XML-документов, но вы можете
пожалеть о старом знакомом журнале аудита в таблице базы данных, с
которым можно было работать, используя SQL-операторы. Не беспокойтесь,
вы по-прежнему можете использовать обычный SQL для выполнения запросов
к данным, записанным в XML-файлы журнала аудита. Содержимое этих файлов
показывает новое представление словаря данных V$XML_AUDIT_TRAIL. Для
того чтобы увидеть информацию аудита, вы можете выбрать все столбцы
этого представления:
SELECT * FROM
V$XML_AUDIT_TRAIL;
Результат этого запроса для облегчения
просмотра показан на листинге 3 в вертикальном формате. Обратите
внимание, если бы были множественные записи XML-аудита, вы видели бы в
этом представлении одну запись для каждой записи XML-аудита. Имена всех
столбцов представления совпадают с именами тегов в XML-файле журнала
аудита; например, тег <DB_User> в файле показывается в
представлении как столбец DB_USER. Отметка времени показывается в
столбце EXTENDED_TIMESTAMP, но время показывается в часовом поясе
местного времени, а не в поясе UTC, как в файле XML-аудита. Столбцы,
которые не заполнены в XML-файле, имеют в представлении значение NULL.
SELECT * FROM
V$XML_AUDIT_TRAIL;
AUDIT_TYPE : 1
SESSION_ID : 108844
PROXY_SESSIONID : 0
STATEMENTID : 10
ENTRYID : 1
EXTENDED_TIMESTAMP : 10-OCT-05 06.26.18.720548 PM -04:00
GLOBAL_UID :
DB_USER : SCOTT
CLIENTIDENTIFIER :
EXT_NAME :
OS_USER : oracle
OS_HOST : prolin1
OS_PROCESS : 22584
TERMINAL : pts/3
INSTANCE_NUMBER : 0
OBJECT_SCHEMA : BANK
OBJECT_NAME : ACCOUNTS
POLICY_NAME :
NEW_OWNER :
NEW_NAME :
ACTION : 103
STATEMENT_TYPE : 0
TRANSACTIONID :
RETURNCODE : 0
SCN : 6447496045
COMMENT_TEXT :
AUTH_PRIVILEGES :
GRANTEE :
PRIV_USED : 0
SES_ACTIONS : ---------S------
OS_PRIVILEGE :
ECONTEXT_ID :
SQL_BIND : #1(3):107
SQL_TEXT : select * from bank.accounts where accno = :i
Листинг 3. Содержимое V$XML_AUDIT_TRAIL
Дополнительная защита
Естественно,
для повышения контролируемости, вы хотите "уплотнить" защиту
инфраструктуры аудита. Вышеизложенная процедура начальной установки
имеет одну потенциальную проблему – любой, имеющий системную привилегию
выполнения поставляемого пакета UTL_FILE, может удалить файл журнала
аудита из файловой системы ОС, используя процедуру FREMOVE. Чтобы
снизить этот риск, вы можете ограничить эти возможности:
* аннулировав эту привилегию у группы пользователей PUBLIC;
* аннулировав системную привилегию CREATE DIRECTORY у группы пользователей PUBLIC.
Первый
вариант – несколько радикальный, но он представляет собой надежный
способ снижения риска. Второй вариант является, вероятно, более
практичным. Для удаления этого файла пользователи должны иметь доступ к
данному каталогу ОС или возможность создания объектов базы данных типа
DIRECTORY (каталог). Если вы у группы пользователей PUBLIC отзовете
системную привилегию CREATE DIRECTORY, то только пользователи с ролью
DBA смогут создавать каталоги в том каталоге ОС, в котором находится
журнал аудита, но не обычные пользователи. Если они не могут создать
каталог, они не смогут и удалить файл, используя пакет UTL_FILE. В
любом случае, в методах передовой практики считается, что системную
привилегию CREATE DIRECTORY следует отозвать у группы пользователей
PUBLIC.
Пользователь ОС, который владеет программным
обеспечением Oracle, владеет и файлами XML-аудита, поэтому любой, кто
имеет права доступа к серверу и к этой учетной записи пользователя ОС,
может удалить эти файлы. Тем не менее, ограничивая привилегии, вы
можете добиться приемлемого уровня безопасности.
В сервере
Oracle предлагается и другой тип аудита. При этом аудите журнал аудита
пишется в системные журналы ОС (system logs, syslogs), которые
принадлежат привилегированному пользователю (такому, как "root" в ОС
UNIX) и не могут удаляться другими пользователями, включая владельца
программного обеспечения Oracle.
Системные журналы
Вышеприведенные
варианты не будут работать, если владелец программного обеспечения
сервера базы данных, обычно пользователь "oracle", решит удалить все
записи в этих файлах XML-аудита. Чтобы дополнительно защитить их, вы
можете использовать утилиту (систему) syslog. Эта система записывает
сообщения в специальный файл, принадлежащий привилегированному
пользователю ОС (пользователь "root"), поэтому никакой другой
пользователь не сможет удалить его. Вы можете установить параметры
инициализации так, чтобы журнал аудита записывался системой syslog:
AUDIT_TRAIL=OS
AUDIT_SYSLOG_LEVEL=USER.ALERT
Теперь после перезапуска экземпляра
сервера базы данных все записи аудита будут записываться системой
syslog в соответствии с установленным средством (источником сообщений)
– facility – (kernel (ядро ОС), user (пользовательские процессы) и так
далее) и определенным уровнем серьезности сообщений – level – (таким,
как notice (необычные состояния), warning (предупреждения), err
(состояния ошибок) и так далее). Вторая строка показанного выше кода
указывает, что записи аудита записываются с установленными средством
user и уровнем alert (срочные ситуации). Если вы не укажете ничего
больше, то эти записи аудита будут поступать в файл сообщений сервера
по умолчанию – обычно в сервере Linux это файл /var/log/messages.
Однако в этот файл поступают все сообщения, включая и сообщения самой
ОС, поэтому вы можете создать другой файл только для целей аудита,
скажем, audit.log. Укажите местоположение этого файла для данного
средства в конфигурационном файле системы syslog, обычно находящимся
в/etc/syslog.conf:
user.alert /var/log/audit.log
Эта строка указывает, что сообщения
средства user на уровне alert должны поступать в файл
/var/log/audit.log. Теперь перезапустите процесс системы syslog.
Фактическая команда зависит от системы, ваш системный администратор
должен применять правильную команду. В ОС UNIX как пользователь "root"
выполните команду:
/etc/init.d/syslog restart
Она перезапустит процесс системы syslog,
который будет писать сообщения средства user на уровне alert в файл
/var/log/audit.log file. После этого, когда пользователь выполнит
запрос к таблице ACCOUNTS, в этом файле появится следующая строка:
Oct 13 01:26:55 oradba Oracle Audit[28955]: SESSIONID: "25386"
ENTRYID: "1" STATEMENT: "8" USERID: "SCOTT" USERHOST: "prolin1"
TERMINAL: "pts/2" ACTION: "103" RETURNCODE: "0" OBJ$CREATOR: "ARUP" OBJ$NAME:
"ACCOUNTS" SES$ACTIONS: "---------S------"
SES$TID: "76564" OS$USERID: "oracle"
К сожалению, она не в XML-формате, но
действия вполне понятны. Этот файл принадлежит пользователю root,
поэтому пользователь oracle не сможет удалить или изменить его, что
обеспечивает очень хорошую защиту.
Заключение
Журнал
аудита в XML-формате в сервере Oracle Database 10g Release 2 позволяет
вам без необходимости выбора иметь и то и другое – журнал аудита,
отделенный от базы данных для усиления защиты от несанкционированного
доступа, и тот же самый знакомый SQL-интерфейс для выполнения запросов
к данным, который повышает продуктивность работы. Это очень полезно для
обеспечения соблюдения многих законов и требований по безопасности. Вы
можете использовать общедоступные программы просмотра XML-документов,
разработанные сторонними производителями, и вы (или, возможно,
специалисты отдела, который обязан контролировать вашу команду, но не
имеющий возможности использовать SQL) можете использовать
XML-анализаторы с таблицами стилей, позволяющие создавать заказные
отчеты по файлам журнала аудита.
Дополнительно ИЗУЧАЙТЕ средства аудита:
Oracle Database Security Guide
Oracle Database Concepts (глава 20)
Oracle Database Reference
Oracle Database SQL Reference
oracle.com/technology/documentation
|
Копирование материалов разрешено,