4.3.1. Организационно-технические решения по настройке и сбору данных журнала аудита ос hp-ux

Получение данных журнала аудита ОС HP-UX может осуществляться двумя способами:

01) на сервер, с консоли «root» инсталлируется агент, который в режиме «on-line» передаёт свой аудит. На серверной части обработки аудита, на основе двоичных событий аудита в формате ОС HP–UX формируются события для записи в базу данных сервера аудита службы безопасности. Достоинство данного режима заключается в следующем:

– агент осуществляет полностью автоматический режим управления подсистемой аудита (устанавливает для подсистемы аудита вспомогательный файл аудита, размер вспомогательного файла аудита, осуществляет сбор информации из файлов wtmp, btmp, sulog для генерации более качественных записей в БД, осуществляет контроль за размером файлов wtmp, btmp, sulog);

– ручная работа администраторов (пользователей «root» и «auditor») минимальна, и сводится только к инсталляции агента и добавлению событий, подлежащих аудиту;

2) вторая схема предполагает накопление аудита на подконтрольных объектах и дальнейшее использование службы удаленного доступа к их файловым системам (например, по протоколу FTP) для переноса данных аудита на сервер аудита службы безопасности. После разбора, преобразования, аудит записывается в базу данных сервера аудита службы безопасности. Недостатки такого подхода заключаются в следующем:

– наличие ручной работы администраторов по управлению подсистемой аудита (установка вспомогательного файла аудита, размера файла);

– политика безопасности на серверах под управлением ОС HP-UX разрешает читать и записывать файлы аудита только пользователю «root», это обеспечивается установкой прав доступа на файлы аудита (0600). Следовательно, для чтения данных аудита необходимо использовать учетную запись «root»;

– администратор должен как минимум раз в сутки переписывать заполненные файлы аудита с подконтрольных серверов на сервер аудита службы безопасности. Очевидно, что при большом потоке данных аудита съем аудита должен осуществляться чаще. Соотношение размера файлов аудита и периодичности их съема должны быть установлены в ходе опытной эксплуатации.

4.3.2. Организационно-технические решения по настройке и сбору данных журнала аудита субд Oracle

Требования к настройкам журнала штатной подсистемы регистрации событий.

Штатная процедура регистрации событий (ШПРС) СУБД Oracle опциональна. Опции аудита устанавливаются при помощи SQL-команды AUDIT. При эксплуатации с включенным аудитом требуется определенный расход вычислительных ресурсов СУБД, необходимый для генерации записей аудита. В случае неграмотной настройки аудита (например, включения аудита на применение всех привилегий ко всем объектам) может привести к полной неработоспособности СУБД из-за недостатка вычислительных ресурсов. Кроме того, при переполнении таблицы аудита, SQL-операции с БД, которые вызывают появление новых записей в таблице аудита, перестают выполняться. Поэтому необходимо точное определение перечня необходимых событий аудита и перечня объектов БД, для которых необходимо включить аудит.

В подсистеме аудита СУБД Oracle можно настроить аудит по следующим критериям:

– можно выполнять аудит конкретных SQL-операторов безотносительно к конкретным объектам. Например, можно генерировать запись аудита каждый раз, когда какой-либо пользователь выполняет оператор DROP TABLE, и не учитывать, к какой таблице относится этот оператор;

– можно выполнять аудит использования мощных системных привилегий. Например, генерировать запись аудита каждый раз, когда какой-либо пользователь применяет системную привилегию SELECT ANY TABLE для запроса к таблице БД;

– можно выполнять аудит определенных SQL-операторов для конкретных объектов БД. Например, генерировать запись аудита каждый раз, когда какой-либо пользователь удаляет запись из таблицы MODES;

– можно выполнять формирование одной аудиторской записи на применение каждого тип SQL-оператора в течение сеанса работы пользователя.

Наименее ресурсоемким и минимально необходимым является аудит привилегии CREATE SESSION, включение которого позволяет фиксировать факты регистрации и завершения работы пользователей. При наличии указанных фактов подсистема анализа способна выявить нетипичную активность пользователей:

– регистрация пользователя в СУБД в нерабочее время;

– регистрация с нетипичного для данного пользователя компьютера (терминала);

– регистрация пользователя в СУБД с именем, несоответствующим его имени в ОС.

С целью улучшения качества контроля, аудит для контролируемых объектов БД необходимо установить для всех пользователей СУБД. Для минимизации ресурсов, потребляемых аудитом, необходимо воспользоваться возможностью формирования одной аудиторской записи на каждый тип SQL-выражения.

СУБД Oracle генерирует записи аудита только после того, как аудит разрешен и для него установлены соответствующие опции. Например, можно установить опции аудита для конкретных субъектов. В Oracle разрешается сохранять генерируемые записи аудита либо в журнале аудита базы данных (фактически таблица записей аудита входит в состав контролируемой БД), либо в таком же журнале операционной системы, в которой работает СУБД Oracle Server. При использовании журнала аудита базы данных можно легко просматривать и находить записи аудита с помощью SQL-запросов и предвари­тельно созданных для этого журнала представлений словаря данных.