|
|
Защита данных - Auditing
Auditing
Основы баз данных OpenEdge
Защита данных
Стратегия резервного копирования (backup)
Востановление базы данных
After-imaging
Обеспечение безопасности
Auditing
События, подлежащие аудиту
Состояния, подлежащие аудиту
Активация и деактивация Auditing
Таблицы, подлежащие аудиту
Архивация аудиторских данных
Влияние аудита на ресурсы базы данных
Влияние аудита на утилиты базы данных
Репликация данных
Failover Clusters
Поддержка и мониторинг базы данных
Команды запуска и останова
Параметры запуска баз данных
Утилиты OpenEdge RDBMS
Виртуальные системные таблиц (VST)
Auditing это эффективный, масштабируемый механизм, призванный обеспечить поддержку аудиторского следа при работе вашей системы с базой данных.
События, подлежащие аудиту
Auditing в OpenEdge гибко настраивается. Вы можете проследить события вашего приложения на самом высоком уровне или более подробно проследить изменения по конкретному полю на самом низком. Определенный набор отслеживаемых событий называется полис (policy). Полисы настраиваются с помощью Audit Policy Maintenance. Более подробно о создании и поддержке полисов смотрите Audit Policy Maintenance online Help.
События аудита записывают изменения в процессах аудита, определениях полисов и обработке данных журнала аудита. Эти события включают:
- Активацию и деактивацию auditing для базы данных
- Создание, изменение и удаление записей полисов аудита
- Время изменения полисов
- Выгрузку и загрузку данных аудита
- Выгрузку и загрузку полисов аудита
- Архивацию данных аудита
- Удаление прав администратора аудита у последнего авторизованного администратора
События безопасности записывают изменения пользователей, ролей, системы аутентификации и доменов. Также записываются изменения в SQL привилегиях. Они включают контроль создания, изменения и удаления по следующим объектам:
- Данные пользователя
- SQL DBA
- Система аутентификации
- Домен аутентификации
- Определения ролей
- Назначения ролей
- Привилегий таблиц SQL
- Привилегий столбцов SQL
- Привилегий секвенций SQL
События схемы записывают изменения в схеме вашей базы данных. Они включают контроль создания, изменения и удаления следующего:
- Таблиц
- Триггеров таблиц
- Поле в таблице
- Триггеров полей
- Индексов в таблице
- Полей в индексах
- Секвенций
- Свойств базы данных (только создание и удаление)
События данных записывают изменения в данных вашей базы. Существует три специфических события, это создание, изменение и удаление записи. Вы можете отслеживать изменения, как для таблиц, так и для полей. При использовании событий аудита на уровне поля, уровень аудита таблицы также должен быть определен. События поля имеют приоритет над событиями таблицы.
Административные события записывают запуски и остановы базы данных.
События утилит регистрируются, когда по отношению к базе данных запускались следующие утилиты:
- Двоичная выгрузка и загрузка данных
- Перемещение таблиц (Table move)
- Перемещение индексов (Index move)
- Проверка индексов (Index check)
- Переиндексация (Index rebuild)
- Усечение областей (Truncate area)
- Исправление индексов (Index fix)
- SQL выгрузка и загрузка данных
- Текстовая выгрузка и загрузка данных
Пользовательские события записывают действия пользователей, такие как вход и подключения к базе данных. Специфические события включают:
- Установка личности пользователя базой данных
- Ошибки установки личности пользователя
- Успешный вход ABL пользователя
- Ошибка входа ABL пользователя
- Выход ABL пользователя
- Подключение к базе ABL пользователя
- Отключение от базы ABL пользователя
- Успешный вход SQL пользователя
- Ошибка входа SQL пользователя
- Выход SQL пользователя
- Подключение к базе SQL пользователя
- Отключение от базы SQL пользователя
Предварительно определенные события приложений используются в конкретном контексте приложений и регистрируют группу различных событий. Такие события определяются пользователями и добавляются программно в исходный код приложения в критических местах, где невозможно отследить события базы данных. Такие группы программируются, чтобы присоединять их к серии событий на логическом уровне.
Состояния, подлежащие аудиту
Существует три возможных состояния базы данных подлежащих аудиту:
- Enabled – в этом состоянии доступ к базе данных ограничен и контролируется аудитом: Клиенты и сервера боле ранних версий не могут запускаться и подключаться к базе данных
Привилегии аудита для текущих пользователей проверяются до получения доступа к данным аудита, тем самым, защищая данные от не санкционированного доступа.
База данных и приложения проверяются согласно активным полисам аудита.
- Disabled – в этом состоянии доступ к базе данных не ограничен аудитом:
Клиенты и сервера более старых версий могут запускаться и подключаться к базе данных
Доступ к данным аудита существующим клиентам будет отвергнут.
Привилегии аудита не проверяются
База данных не проверяется
- Deactivated – доступ к базе данных ограничен аудитом:
Клиенты и сервера боле ранних версий не могут запускаться и подключаться к базе данных
Доступ к данным аудита существующим клиентам будет отвергнут.
Привилегии аудита не проверяются
База данных не проверяется
Активация и деактивация Auditing
Активация Auditing происходит командой PROUTIL. Перед активацией необходимо определить область хранения для данных аудита. Не используйте стандартные области хранения вашей базы для хранения этих данных. Для хранения индексов, так же желательно определить отдельную область. Т.к. при больших объемах данных, таким разделением областей можно добиться улучшения производительности. Так же, для улучшения производительности, можно деактивировать все не уникальные индексы, которые в последствии можно активировать с помощью команды PROUTIL IDXBUILD.
Включение Auditing
Далее будет описан детальный процесс для активации Auditing. В момент активации база данных может находиться в одном из двух состояний: auditing disabled (аудит отключен, или ранее не активировался) и auditing deactivated (аудит деактивирован).
И так, для активации последуйте следующим шагам:
1. Создайте st – файл, содержащий описания области хранения данных аудита и описание области хранения индексов аудита.
2. Добавьте области с помощью команды PROSTRCT ADD.
3. Активируйте auditing командой PROUTIL ENABLEAUDITING. В следующем примере используется имя базы данных sample-db, используемая область данных для таблиц аудита – “Audit Area”, область для индексов – “Audit Indexes”, а также деактивируются все не уникальные индексы.
proutil sample-db -C enableauditing area “Audit Area” - indexarea “Audit Indexes” deactivateidx
По окончанию активации будет выдано сообщение:
Auditing has been enabled for database sample-db. (12479)
Для восстановления auditing после деактивации необходимо сделать следующее:
1. Проверьте, что таблицы аудита пусты. Т.к. активация подразумевает также и необходимость, чтобы таблицы аудита были пусты.
2. Активируйте auditing командой PROUTIL ENABLEAUDITING.
proutil sample-db -C enableauditing
После чего появится сообщение:
Auditing has been activated
Как только auditing активирован для базы данных, необходимо определить и активировать полисы аудита для начала сбора данных. Более подробную информацию о полисах аудита можно получить из Audit Policy Maintenance online Help.
Отключение Auditing
Для отключения auditing, используется команда PROUTIL DISABLEAUDITING. Если к этому моменту база данных будет содержать информацию в таблицах _aud-audit-data и _aud-audit-data-value, команда деактивирует, а не отключит его. Синтаксис отключения следующий:
proutil db-name -C disableauditing
Если auditing будет только деактивирован, будет выдано следующее сообщение:
Auditing was not fully disabled because auditing data tables are not empty. (13647)
Auditing has been deactivated, no additional auditing records will be recorded. (13649)
Для того чтобы полностью отключить auditing, необходимо почистить таблицы _aud-audit-data и _aud-audit-data-value, и выполнить следующие действия для его полного отключения:
1. Активируйте auditing с помощью PROUTIL ENABLEAUDITING. Поскольку база данных просто деактивирована, эффект от этой команды будет как и при первоначальной активации.
2. Очистите таблицы аудита. Для этого используйте средство архивации PROUTIL AUDITARCHIVE, для удаления данных из таблиц _aud-audit-data и _aud-audit-data-value. Но имейте в виду, что не все данные могут быть удалены этой командой, например, если существуют активные полисы аудита для отслеживания архивации данных, вам придется найти иной способ для очистки таблиц.
3. Отключите auditing с помощью команды PROUTIL DISABLEAUDITING.
Поскольку аудиторские таблицы были пусты - auditing будет полностью отключен. О чем будет свидетельствовать сообщение:
Auditing has been disabled for database db-name. (12490)
Таблицы, подлежащие аудиту
Включение auditing для базы данных, добавляет в ее мета схему следующие дополнительные семь таблиц:
Имя таблицы
|
Описание
|
Архивация
|
| _aud-audit-data |
Содержит записи аудита. Т.е. все события хранятся здесь |
Да |
| _aud-audit-data-value |
Является дочерней таблицей _aud-audit-data и содержит значения изменений полей событий |
Да |
| _aud-audit-policy |
Содержит имена полисов аудита. Если имеются многочисленные активные
полисы, конфликтующие между собой, для работы будет выбран полис с
наивысшим уровнем проверки. |
Нет |
| _aud-event |
Таблица содержит все поддерживаемые OpenEdge и определенные
пользователями события и их ID. ID событий до 32 000 зарезервированы.
Пользовательские события могут использовать ID свыше 32 000. |
Да |
| _aud-event-policy |
Содержит события связанные с полисами |
Нет |
| _aud-field-policy |
Содержит поля настроенные для аудита связанные с именами полисов |
Нет |
| _aud-field-policy |
Содержит таблицы настроенные для аудита связанные с именами полисов |
Нет |
Для получения более детальной информации по таблицам, обратитесь к документации OpenEdge Getting Started: Core Business Services.
Индексы таблиц аудита
Большинство таблиц, поддерживаемых auditing, используют многочисленные индексы. При включении auditing вы можете активировать как все индексы, так и только primary индексы. Обычно, активируются только primary индексы на промышленных базах данных. Все остальные индексы используются только для формирования отчетов и, как правило, активированы только на архивных базах данных. В следующей таблице указаны индексы для каждой таблицы аудита:
Таблица
|
Имя индекса
|
Тип индекса
|
| _aud-audit-data |
_AppContext-Id
_Audit-time
_Connection-id
_Data-guid
_Event-context
_Event-group
_EventId
_Userid
|
-
-
-
Primary
Unique
-
-
-
-
|
| _aud-audit-data-value |
_Field-name
_Continuation-seq
|
-
-
|
| _aud-audit-policy |
_Policy-active
_Policy-desc
_Policy-guid
_Policy-name
|
-
-
Primary
Unique
Unique
|
| _aud-event |
_Event-desc
_Event-id
_Event-name
|
-
Primary
Unique
-
|
| _aud-event-policy |
_Event-guid
_Event-id
|
Primary
Unique
-
|
| _aud-field-policy |
_Field-name
_File-field-owner
|
Primary
Unique
-
|
| _aud-file-policy |
_Create-event-id
_Delete-event-id
_File-owner
_Guid-file-owner
_Read-event-id
_Update-event-id
|
-
-
-
Primary
Unique
-
-
|
| _Client-session |
_Auth-time
_Db-guid
_Session-uuid
_Userid
|
-
-
Primary
Unique
-
|
| _Db-detail |
_Db-guid |
Primary
Unique |
Архивация аудиторских данных
Аудит базы данных подразумевает генерацию большого количества данных за очень короткие периоды, что естественно, вызовет рост размеров вашей промышленной базы. Поэтому, имеет смысл периодически производить архивацию данных аудита. При этом созданные архивы можно всегда загрузить в копию промышленной базы данных, и активировать все имеющиеся индексы, чтобы иметь возможность получать более быстрый доступ к данным, чем на промышленной базе.
Процесс архивации
Архивация производится командой PROUTIL AUDITARCHIVE, а загрузка данных из архива, с помощью PROUTIL AUDITLOAD.
Пользователь, выполняющий архивацию аудиторских данных должен иметь привилегии Audit Archive, а пользователь, выполняющий загрузку, должен иметь привилегии Audit Data Archiver на целевой базе.
Основной процесс архивации
Основной процесс, это архивация и удаление данных из промышленной базы, плюс загрузка их в базу архивную. В следующем примере описаны действия по архивации промышленной базы prod-db, и их загрузке в архивную базу arch-db:
1. Архивация данных:
proutil prod-db -C auditarchive
Команда архивирует аудиторские данные базы prod-db в текущую директорию и очищает таблицы аудита. Имя файла архива будет иметь следующий вид: prod-db.abd.
2. Загрузка данных:
proutil arch-db -C auditload /usr1/prod-db-dir/prod-db.abd
Команда загружает аудиторские данные в базу arch-db из файла архива /usr1/prod-db-dir/prod-db.abd.
Процесс архивации со штампом проверки
Более осторожный способ архивации данных, это архивация с проверкой штампа данных, для того чтобы быть уверенными, что архивация и загрузка данных пройдут успешно, перед тем как удалять аудиторские данные из промышленной базы. Если в процессе архивации база данных находится в online, необходимо определить дату или диапазон дат которые нужно архивировать. Определение дат гарантирует, что вы в последствии удалите именно те записи, которые архивировали. Если будет определена только одна дата, то архивации подвергнутся все данные до указанной даты, если две, то архивироваться будут данные, находящиеся в промежутке указанных дат. В приведенном ниже примере архивируются данные промышленной базе prod-db до полуночи 31 августа:
1. Архивирование с проверкой штампа архивируемых аудиторских данных:
proutil prod-db -C auditarchive “08-31-2005 23:59:59.999-04:00” -checkseal
-nodelete -directory /usr1/audit_archives
Эта команда архивирует все текущие данные из промышленной базы в файл /usr1/audit_archives/prod-db.abd, но не удаляет их по завершении архивации, т.к. был установлен параметр –nodelete. Параметр же –checkseal, указывает процессу проверить штамп каждой записи аудиторских данных перед архивацией.
2. Загрузка данных:
proutil arch-db -C auditload /usr1/audit_archives/prod-db.abd -checkseal
Эта команда загружает архивные данные из файла prod-db.abd в базу данных arch-db, и проверяет штамп каждой записи аудиторской базы, перед тем как загрузить ее.
3. Удаление данных:
proutil prod-db -C auditarchive “08-31-2005 23:59:59.999-04:00”
-directory /dev/null
Эта команда удаляет данные, архивированные в шаге 1 из базы данных, и при этом не создает нового архивного файла.
Влияние аудита на ресурсы базы данных
Auditing это чрезвычайно ресурсоемкий механизм. Новая запись создается в таблице _aud-data каждый раз, когда происходит какое-либо событие. К тому же, запись или записи пишутся в таблицу _aud-data-value всегда, когда происходит изменение контролируемых полей таблиц. В зависимости от установленного уровня аудита, вы можете хранить как оригинальное значение контролируемых полей, так и любые изменения этих значений.
Влияние аудита на утилиты базы данных
Необходимо гарантировать целостность журнала аудита, для чего надо обеспечить, чтобы только авторизованные пользователи имели доступ к данным и полисам аудита. Для этого использование определенных утилит базы данных становится ограниченным для некоторых пользователей.
Auditing включает уровень безопасности для использования утилит базы данных. Это дополнение обеспечивает три первичных аспекта безопасности: аутентификация, авторизация и аудит. Необходимо определить, кто может использовать утилиты, для выполнения определенных действий, и описать детально эти действия.
Не всем утилитам требуется уровень пользовательской безопасности.
Он требуется утилитам, которые отвечают следующим критериям:
- Утилита изменяет статус аудита базы данных
- Утилита изменяет данные аудита или полисы
- Утилита изменяет описание областей базы данных принадлежащих аудиту.
Доступ к таким утилитам пользователь получает, когда ему устанавливают привилегированные права роли аудитора. Пользователь может быть определен как в таблице _user, так и просто в операционной системе, главное, чтобы для использования определенных утилит, ему были выданы роли либо Audit Administrator, либо Audit Data Archiver. Боле подробную информацию по этим процессам можно получить в OpenEdge Getting Started: Core Business Services или в Data Administration online Help.
Установление привилегированного пользователя
Существует два способа идентификации пользователя: по таблице _User и по логину операционной системы (User ID). В зависимости от способа идентификации, способ определение информации о пользователе утилитами может отличаться.
Таблица _User
Если таблица _User заполнена, необходимо обязательно указать параметр –userid username для аутентификации привилегий пользователя. Этому пользователю, к тому же, должна быть определена соответствующая роль. Пароль passwd должен соответствовать указанному пользователю. Пароль указывается параметром –password passwd, если же он не указан, утилита сама запросит его ввод. Пароль может указываться как в чистом виде, так и зашифрованном.
Допустим, вы определяете пользователя «Mike» в таблице _User, и установили ему пароль “guru”. А также установили роль Audit Data Archiver. В этом случае выполнение PROUTIL AUDTARCHIVE будет защищенным по отношению к базе данных, и выполняется следующей командой:
С паролем в чистом виде:
$ proutil auditexampledb -C auditarchive -userid Mike -password guru
С запросом пароля:
$ proutil auditexampledb -C auditarchive -userid Mike
OpenEdge Release 10.1B as of Sat Dec 17 09:56:25 EST 2005
password: ****
Запрос пароля будет осуществлен до выполнения команды.
С зашифрованным паролем:
$ genpassword -password guru
37273d32
.
.
.
$ proutil auditexampledb -C auditarchive -userid Mike
-password oech1::37273d32
Предварительно, необходимо зашифровать пароль, используя утилиту genpassword. Затем перед запуском AUDITARCHIVE указать его в командной строке.
Использование логина операционной системы
Если таблица _User не используется в базе данных, привилегированный пользователь идентифицируется по логину в операционной системе. Такой пользователь должен иметь, по крайней мере, роль Audit Administrator. Как только пользователю будут определены соответствующие роли, ненужно больше что-либо делать еще. Утилиты доверяют проверке пользователя операционной системой, и ни каких дополнительных параметров в командной строке указывать не нужно.
Дополнительно, логин операционной системы (user-id) нужно указать в классификаторе –userid username. Последствие этого добавления, это необходимость определения пароля, который определяется классификатором –password. Внимание: для пользователя операционной системы, в этом случае не используется пароль входа в операционную систему. Утилитам требуется зашифрованный MAC key (DB Pass key) в качестве пароля. MAC key хранится в таблице базы данных _db-detail, в поле _db-mac-key, который может быть установлен в Data Administration. Как устанавливать DB Pass Key смотрите в OpenEdge Getting Started: Core Business Services или в Data Administration online Help
Например, используется логин операционной системы “sysdba”, таблица _User не заполнена, в базе данных “sysdba” установлена роль Audit Data Archiver – защищенный запуск команды PROUTIL AUDITARCHIVE будет выглядеть следующим образом:
При доверии операционной системе:
$ proutil auditexampledb -C auditarchive
С использованием DB Pass Key:
$ genpassword -password ultra_secret_password
253e3b35331a203633202a330d3532202325203536
.
.
.
proutil auditexampledb -C auditarchive -userid sysdba
-password oech1::253e3b35331a203633202a330d3532202325203536
Предположим, что DB Pass Key равен “ultra_secret_password”. Предварительно, необходимо зашифровать DB Pass Key, используя genpassword. После чего использовать результат в командной строке утилиты AUDITARCHIVE.
С запросом DB Pass Key:
$ proutil auditexampledb -C auditarchive -userid sysdba
OpenEdge Release 10.1A as of Sat Dec 17 09:56:25 EST 2005
password: *********************
Запрос пароля будет осуществлен до выполнения команды. Пароль может быть введен как в чистом виде, так и в зашифрованном при наличии надлежащего префикса шифрования.
Определение зашифрованных паролей
Шифрование паролей призвано повысить безопасность, особенно при их использовании в программных сценариях при вызове утилит.
Формат зашифрованных паролей для баз данных следующий oech1::password. Он состоит из пяти символьных префиксов, отделенных от зашифрованного пароля разделителем. Следующая таблица детально описывает их:
| Компонент |
Описание |
| oec |
Сокращение, идентифицирующее алгоритм шифрования OpenEdge crypto |
| h1 |
Шестнадцатирично - двоичное закодированное значение, идентифицирующее алгоритм шифрования с размером ключа 1 |
| :: |
Разделитель |
| Password |
Зашифрованный пароль. Шифрование которого выполнено, указанным в префиксе, алгоритмом. |
Более детальное описание работы утилиты genpassword смотрите в OpenEdge Getting Started: Installation and Configuration.
Модификации утилит
Утилиты с расширенной пользовательской безопасностью имеют доступ к данным аудита и могут изменять статус auditing`а. В этой части описаны защищенной данные и перечисляются закрепленные за ними утилиты.
- Защищенные таблицы
- Защищенные области
- Расширенные утилиты
- Расширение синтаксиса PROUTIL
Защищенные таблицы
Защищенными являются таблицы, используемые для аудита и участвующие в установлении привилегий пользователям. Существует два типа защищенных таблиц: таблицы данных аудита и таблицы полисов аудита.
Имя таблицы
|
Тип таблицы
|
| _aud-audit-data |
Данные |
| _aud-audit-data-value |
Данные |
| _client-session |
Данные |
| _aud-event |
Полисы |
| _aud-event-policy |
Полисы |
| _aud-audit-policy |
Полисы |
| _aud-file-policy |
Полисы |
| _aud-field-policy |
Полисы |
Защищенные области
Защищенными считаются области с данными и индексами аудита. Они определяются при включении Auditing.
Расширенные утилиты
Расширенные утилиты работают с защищенными таблицами, областями и статусами Auditing. Для некоторых утилит, подобные операции будут безоговорочно отклонены. Для других, доступ будет предоставлен в соответствии с установленными привилегиями.
Операция
|
Классификатор
PROUTIL
|
Закрепленный
защищенный
объект
|
Необходимые
привилегии |
Ограничения
|
| Bulk load |
Bulkload |
Таблицы |
- |
Запрещен всем пользователям |
| Binary load |
load |
Таблицы |
- |
Запрещен всем пользователям |
| Binary dump |
dump
dumpspecified
|
Таблицы |
- |
Запрещен всем пользователям |
Index fix
(delete record) |
idxfix |
Таблицы |
Audit Archiver |
Запрещен всем кроме имеющих привилегию |
| Truncate area |
truncate area |
Области |
Audit Archiver |
|
| Archive audit data |
auditarchive |
Таблицы |
Audit Archiver |
Запрещен всем кроме имеющих привилегию |
| Load audit data |
auditload |
Таблицы |
Audit Archiver |
Запрещен всем кроме имеющих привилегию |
| Disable auditing |
disableauditing |
- |
Audit Administrator |
Запрещен всем кроме имеющих привилегию |
Расширение синтаксиса PROUTIL
Для расширенных утилит, для обеспечения возможности идентификации привилегированных пользователей, синтаксис PROUTIL расширен дополнительными идентификаторами, включающими логин и пароль пользователя, как показано далее:
PROUTIL dbname -C qualifier [ qualifier-parameters ]
[ -userid username [-password passwd ]]
|
|
|
|
Главная
