7.4.3. Задание файлов, запуск и остановка механизма аудитинга
Задание файлов для записи протокола
Для протоколирования действий пользователей используются файлы. Одним из обязательных шагов по запуску системы аудитинга должно быть задание расположение файлов протокола. Файлы протокола - это обычные файлы ОС, куда включенный механизм аудитинга будет помещать записи о действиях пользователя. Аналитик по безопасности должен специфицировать директорию, где эти файлы будут располагаться.
Изначально файлы протокола располагаются в директории, на которую указывает параметр ADTPATH файла $INFORMIXDIR/aaodir/adtcnf. Если сразу после инсталляции сервера посмотреть на данный параметр, то он будет установлен в /tmp. Временная директория /tmp не самое удачное место для хранения файлов протокола. Можно поменять значение данного параметра, но это должно быть сделано до инициализации экземпляра сервера (то есть до выполнения команды oninit -i). Если не менять значение данного параметра, то указываемая им директория и будет первой директорией для файлов протокола. Поменять эту директорию можно после запуска механизма аудитинга командой
onaudit -p <директория>
например
onaudit -p /usr/audit
Если менанизм аудитинга не включен или на указываемую директорию аналитик по безопасности не имеет прав записи и чтения, то будет выдано сообщение об ошибке.
В директории, указанной для хранения протоколов будут автоматически создаваться файлы с названиями вида <имя сервера БД>.<порядковый номер>. В качестве имени сервера будет выступать значение параметра INFORMIXSERVER, а порядковый номер - просто номер файла протокола. Дело в том, что система аудитинга имеет ограничение по размеру файлов протокола (параметр ADTSIZE файла $INFORMIXDIR/aaodir/adtcnf) и по достижению очередного файла протокола произойдет автоматический переход на новый файл. Можно и принудительно перейти к следующему файлу протокола, выполнив команду
onaudit -n
Данная команда может быть выполнена только при включенном механизме аудитинга. Пример содержимого директории с протоколами для сервера по имени shm_ncr1:
# echo $INFORMIXSERVER shm_ncr1 # ls -l /usr/audit total 3 -rw-rw---- 1 informix ix_aao 234 Mar 5 12:41 shm_ncr1.0 -rw-rw---- 1 informix ix_aao 78 Mar 5 13:18 shm_ncr1.1 # onaudit -n Onaudit -- Audit Subsystem Configuration Utility Copyright (C) Informix Software, Inc., 1996 # ls -l total 5 -rw-rw---- 1 informix ix_aao 234 Mar 5 12:41 shm_ncr1.0 -rw-rw---- 1 informix ix_aao 78 Mar 5 13:18 shm_ncr1.1 -rw-rw---- 1 informix ix_aao 0 Mar 5 13:24 shm_ncr1.2
Включение и выключение механизма аудитинга.
Для того, чтобы узнать включен ли или выключен механизм аудитинга в данный момент времени, управляющий безопасностью может выполнить команду
onaudit -c
Данная команда, среди нескольких параметров, выдает и параметр ADTMODE. Этот параметр указывает на текущее состояние системы аудитинга. Если он равен 0, то механизм аудитинга выключен, никакого протоколирования не ведется. Если он находится в диапазоне от 1 до 8, то это означает, что механизм аудитинга включен:
# onaudit -c Onaudit -- Audit Subsystem Configuration Utility Copyright (C) Informix Software, Inc., 1996 Current audit system configuration: ADTMODE = 3 ADTERR = 0 ADTPATH = /usr/audit ADTSIZE = 50000 Audit file = 3
Разные значения параметра ADTMODE соответствуют разным уровням и способам протоколирования. Не вдаваясь в подробности, которые всегда можно найти в документации, будем считать что нам для нормального протоколирования нужен уровень “3”. Соответственно, перевод механизма аудитинга на данный уровень с другого уровня, или просто включение механизма аудитинга происходводится командой:
onaudit -l 3
- 4.5. Упражнения 67
- Глава 6. Устройство Informix Dynamic Server 165
- Глава 7. Эксплуатация информационных систем 177
- Глава 1 Обзор основных архитектур баз данных
- 1.1. Архитектура на основе разделяемых файлов
- 1.2. Архитектура “Хост-терминал”
- 1.3. Архитектура “Клиент-Сервер”
- 1.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
- 1.5. Упражнения
- Глава 2 Модели данных
- 2.1. Уровни восприятия данных
- 2.2. Иерархическая модель данных
- 2.3. Сетевая модель данных
- 2.4. Реляционная модель данных
- 2.5. Объектно-реляционная модель данных
- Глава 3 Реализация информационных систем на основе продуктов Informix Software
- 3.1. Обзор продуктов Informix
- 3.2. Варианты построения систем
- Internet/Intranet-конфигурация
- 3.3. Выбор оптимальной конфигурации
- Глава 4 Математические основы реляционных субд
- 4.1. Основные понятия
- 4.2. Ключи
- 4.3. Основные операции над таблицами и их интерпретация
- 4.4. Нормализация
- 4.5. Упражнения
- Глава 5 Язык sql
- 5.1. Типы данных, доступные в sql
- 5.3. Основные sql-операторы для доступа и модификации данных
- 5.4. Управление транзакциями
- 5.5. Продвинутые варианты оператора поиска
- 5.5.1. Поиск по нескольким таблицам
- 5.5.2. Устранение повторения данных в операторе select
- 5.5.3. Вычисления внутри оператора select
- 5.5.4. Логические выражения в условии sql-операторов
- 5.5.5. Слияние двух выборок
- 5.5.6. Сортировка выборки
- 5.5.7. Вставка в таблицу нескольких строк одновременно
- 5.6. Использование sql в языках программирования
- 5.7. Программирование сервера базы данных
- 5.7.1. Динамический sql
- 5.7.3. Хранимые процедуры
- 5.7.4. Триггеры
- 5.8. Ограничители (задание целостности на уровне схемы)
- 5.9. Разграничение в sql прав пользователей
- 5.9.1. Права доступа
- 5.9.2. Права на уровне базы данных
- 5.9.3. Права на таблицы
- 5.9.4. Права на хранимые процедуры
- 5.9.5. Кто и как следит за соблюдением прав
- 5.9.6. Механизм ролей
- 5.9.7. Псевдотаблицы (view)
- 5.9.7. Синонимы
- 5.10. Управление одновременным доступом к данным
- 5.10.1. Что бывает, когда несколько человек одновременно пытаются обновить одни и теже данные
- 5.10.2. Открытие базы данных только для себя
- 5.10.3. Блокирование таблицы
- 5.10.4. Механизм блокирования записей и уровни изоляции
- 5.10.5. Управление ожиданием снятия блокировок
- 5.10.6. Тупиковые ситуации
- 5.11. Повышение скорости обработки запросов.
- 5.11.1. Индексы
- 5.11.2. Буферизация журнала транзакций
- 5.11.3. Блокировка на уровне записей и страниц
- 5.11.4. Эффективное построение запросов
- 5.11.5. Сортировка и поиск по коротким полям. Классификаторы
- 5.12. Объектное расширение sql в Informix ds/Universal Data Option
- 5.12.1. Зачем нужна поддержка объектов в серверах бд?
- 5.12.3. Внедрение объектно-ориентированной технологии
- 5.12.4. Реализация объектного подхода в Informix
- Informix ds/Universal Data Option - объектно-реляционная субд
- 5.12.5. Итак…
- Глава 6. Устройство Informix Dynamic Server
- 6.1. Внутренняя архитектура dsa
- 6.2. Механизм хранения данных
- 6.3. Инсталляция продукта
- 6.4. Запуск и останов сервера
- 6.5. Работа с русским языком
- Глава 7. Эксплуатация информационных систем
- Администрирование серверов баз данных
- 7.2. Обеспечение сохранности данных.
- 7.2.1. Технологии постоянного дублирования
- 7.2.2. Архивация
- 7.2.3. Так как же обеспечить сохранность данных?
- 7.3. Архивирование и восстановление данных
- 7.3.1. Что нужно архивировать
- 7.3.2. Утилиты архивации и восстановления
- 7.3.3. Создание архивов утилитой ontape
- 7.3.4. Восстановление из архивов утилитой ontape
- 7.3.5. Как узнать “когда”?
- 7.3.6. Практические советы
- 7.4. Средства контроля за доступом
- 7.4.1 Как работает аудитинг?
- 7.4.2. Конфигурирование списков протоколируемых событий
- 7.4.3. Задание файлов, запуск и остановка механизма аудитинга
- Анализ протокола
- 7.4.5. Практические советы или Что делать, если вы хотите…
- 7.5. Реагирование на чрезвычайные ситуации
- 7.6. Мониторинг текущего состояния сервера базы данных
- 7.6.1. Кто работает с сервером базы данных
- 7.6.2. Сколько памяти использует сервер бд
- 7.6.3. Сколько свободного места имеется у сервера бд
- 7.7. Достижение требуемой производительности
- 7.7.1. Как узнать, что ждет некоторый запрос
- 7.7.2. Как выяснять причины падения производительности
- 2. Общие принципы предлагаемой технологии
- 3. Как портировать приложение