OpenEdge Auditing – забытая история

События, подлежащие аудиту

С помощью OpenEdge Auditing вы можете отследить практически любые события, которые генерировало ваше приложение, вплоть до изменения содержимого полей таблицы. Правила, которые отслеживают возникающие события, называются полисы аудита, которые настраиваются с помощью Audit Policy Maintenance, к сожалению, эта функция доступна в качестве отдельного приложения в составе Progress OpenEdge под Windows. Поэтому, если вы хотите полноценно использовать механизм, у вас должна быть, хотя бы одна лицензия на Progress OpenEdge под Windows. О том, как использовать Audit Policy Maintenance, можно найти информацию в Audit Policy Maintenance Online Help. В данной монографии эта тема затрагиваться не будет.

Существует множество различных событий, которые могут быть подвергнуты аудиту. Их всех можно разделить на несколько отдельных групп, таких как:

• События аудита
• События безопасности
• События схемы
• События данных
• Административные события
• События утилит
• Пользовательские события
• События приложения

Попробуем кратко охарактеризовать каждую из этих групп.

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

• Включение и отключение OpenEdge Auditing
• Создание, обновление и удаление полисов аудита
• Изменение полисов
• Выгрузка и загрузка данных аудита
• Выгрузка и загрузка полисов аудита
• Архивация данных аудита
• Удаление прав администратора-аудитора

События безопасности. Под этими событиями подразумеваются действия по изменению списка пользователей, по настройке прав доступа, по настройке системы аутентификации и т.п. Механизм OpenEdge Auditing так же отслеживает изменения в настройках SQL прав доступа. Специфическими действиями подобного характера могут быть создание, обновление и удаление:

• Учетных записей пользователей
• SQL администратора
• Системы аутентификации
• Описания ролей
• Присваивание ролей
• Привилегий SQL таблиц
• Привилегий SQL полей
• Привилегий SQL секвенций

События схемы. Это любые действия, приводящие к изменению схемы вашей базы данных. Это могут быть создание, обновление и удаление таких объектов базы данных как:

• Таблицы
• Триггеры таблиц
• Поля таблиц
• Триггеры полей
• Индексы таблиц
• Поля индексов
• Секвенции
• Свойства базы данных

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

Административные события. Под административными событиями подразумевается запуск и остановка базы данных.

События утилит. Это любые действия, которые выполняют различные утилиты, под такими действиями могут подразумеваться:

• Выполнение бинарной выгрузки и загрузки данных
• Перемещение таблиц
• Перемещение индексов
• Проверка индексов
• Перестройка индексов
• Усечение областей хранения
• Исправление индексов
• Выполнение SQL выгрузки и загрузки данных
• Выполнение текстовой выгрузки и загрузки данных

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

• Идентификация пользователя базой данных
• Ошибка идентификации пользователя
• Успешный вход в базу ABL/SQL пользователя
• Ошибка входа ABL/SQL пользователя
• Выход из базы ABL/SQL пользователя
• Подключение ABL/SQL пользователя к базе данных
• Отключение ABL/SQL пользователя от базы данных

События приложения. Это такие события, которые были предварительно закодированы для выполнения специфических задач. Они определяются разработчиком и программно добавляются в исходный код, в тех местах, где стандартными средствами OpenEdge Auditing их нельзя отследить.

Возможные состояния OpenEdge Auditing в базе данных

В базе данных, OpenEdge Auditing может иметь три состояния:

Состояние Enabled – в этом состоянии, доступ к базе данных ограничен и контролируется полисами аудита. Это означает следующее:

• Клиенты более ранних версий Progress OpenEdge (10.0B и более ранние) не могут подключаться к базе данных
• Привилегии аудита для пользователей текущей и более поздних версий, начиная с 10.1А, проверяются до получения доступа к данным аудита, тем самым защищая эти данные от несанкционированного доступа.
• База данных и приложения контролируются согласно активным полисам аудита.

Состояние Disable – в этом состоянии доступ к базе данных не ограничивается механизмом OpenEdge Auditing. Это означает, что:

• Клиенты ранних версий Progress OpenEdge имеют возможность подключения к базе данных
• Обращения к данным аудита будут отвергнуты
• Привилегии аудита не будут проверяться
• Любые действия в базе данных не будут отслеживаться

Состояние Deactivated – в этом состоянии, доступ к базе данных ограничен механизмом OpenEdge Auditing. Это означает, что:

• Клиенты более ранних версий не могут подключаться к базе данных
• Обращения к данным аудита пользователей текущих версий Progress OpenEdge будут отвергаться
• Привилегии аудита, для пользователей текущей версии не будут проверяться
• Любые действия в базе данных не будут отслеживаться

 

---