OpenEdge Auditing – забытая история
Включение OpenEdge Auditing
Включение OpenEdge Auditing выполняется с помощью утилиты PROUTIL. Перед включением необходимо создать отдельную область для хранения таблиц аудита, которые будут загружены в нее в момент включения OpenEdge Auditing. Тип этой области должен быть обязательно SAT-II. Параметры области ни чем не ограничены, но это не означает, что вы должны использовать существующие области для этих целей. Для индексов аудиторских таблиц желательно тоже создать отдельную область. Наличие отдельных областей необходимо из-за того, что таблицы аудита будут во много раз активнее обычных таблиц. Их так же рекомендуется разместить на отдельном диске, чтобы снизить влияние I/O нагрузки на диски. Помимо этого, с целью улучшения производительности, можно деактивировать не уникальные индексы аудиторских таблиц, которые впоследствии можно активировать с помощью утилиты PROUTIL IDXBUILD.
Для включения OpenEdge Auditing вам необходимо выполнить следующие шаги:
- Убедитесь, что все пользователи вашей базы данных используют версии Progress OpenEdge не ниже 10.1А.
- Создайте структурный файл, с описание областей аудита с типом SAT-II. Назовем этот файл aud.st. Пример его содержимого может выглядеть следующим образом:
d "Audit Data":18,32;512 . f 2000000 d "Audit Data":18,32;512 . # d "Audit Index":19,1;8 . f 2000000 d "Audit Index":19,1;8 .
- Убедитесь, что база данных остановлена и ни кем не используется
- Добавьте новые области к базе данных с помощью утилиты PROSTRCT с классификатором ADD.
$ prostrct add sports aud.st
- Обновите структурный файл базы данных утилитой PROSTRCT с классификатором LIST:
$ prostrct list sports
- Включите OpenEdge Auditing с помощью следующей команды:
$ proutil sports –C enableauditing area “Audit Data” indexarea “Audit Index” deactivateidx
После успешного завершения работы утилиты, на экране вы получите следующее сообщение:
Auditing has been enabled for database sports. (12479)
Та же самая информация будет отражена и в логе базы данных (.lg). Теперь, в базе данных включен механизм OpenEdge Auditing, и вы можете приступить к его настройке.
Настройка OpenEdge Auditing
Настройка привилегий аудита
Когда вы в первый раз включаете OpenEdge Auditing, то по умолчанию все права аудита принадлежат администратору базы данных. Это означает, что администратор может выполнять любые действия, связанные с администрированием OpenEdge Auditing. Права аудита разделяются на несколько частей: администрирование полисов аудита, администрирование данных аудита, доступ к данным аудита, и возможность вручную генерировать события аудита. До тех пор, пока права аудита не будут назначены кому-либо еще, администратор базы данных будет способен выполнять все эти операции.
Как только администратор базы данных предоставит права аудита другим пользователям, он больше не сможет обеспечивать поддержку данных и полисов аудита. Например, он больше не сможет отключить аудит базы данных, не сможет создавать и изменять полисы аудита или архивировать данные аудита. Но он все еще имеет право обеспечивать поддержку физической структуры базы данных. Таким образом, с этого момента, администрирование OpenEdge Auditing будет отделено от администрирования всей базы данных. В некоторых случаях, может случиться так, что администратор аудита и администратор базы данных окажется одним лицом. Однако в случае, в котором есть один администратор аудита и более одного администраторов базы данных, всегда только администратор аудита должен имеет возможность настраивать полисы аудита. Администратор аудита может также предоставлять соответствующие права другим пользователям.
По умолчанию OpenEdge применяет модель авторизации (GRANT) ко всем таблицам базы данных, связанными с аудитом. Это означает, что для человека, который должен настраивать полисы аудита и управлять данными аудита, должны быть предоставлены соответствующие права доступа. Поскольку вы наверняка не хотели бы, чтобы только один человек был ответственен за все действия по настройке и управлению аудитом, вы можете распределить между несколькими пользователями права аудита. Как только какая-либо из привилегий назначена пользователю, у него появляется возможность предоставлять эту привилегию другим пользователям, то только если выбрана функция Can Grant Permissions for.
Существует четыре привилегии безопасности аудита:
- Audit administrator– авторизованный пользователь, которому предоставлены права создавать, изменять и удалять полисы аудита, а так же, он может читать данные аудита.
- Application audit event inserter – авторизованный пользователь, которому предоставлены права генерации прикладных событий аудита. Заметьте, что в приложениях ABL, эта привилегия являются не обязательной и по умолчанию заблокирована. В приложениях SQL, эта привилегия по умолчанию включена и не может быть выключена.
- Audit data archiver – авторизованный пользователь, который имеет права только на архивацию и загрузку данных аудита. Этот пользователь не имеет прав доступа к полисам аудита.
- Audit data reporter – авторизованный пользователь, который имеет права читать данные аудита.
У администратора аудита есть неограниченный доступ для чтения всех таблиц аудита, но не у одного из пользователей нет привилегий изменения данных аудита. И только архиватор данных аудита может усечь или переместить данные аудита в другое местоположение, например в отдельную базу данных для длительного хранения и формирования отчетов. Администратор аудита, это единственный пользователь, который может настраивать полисы аудита. Настроенные полисы и данные аудита хранятся в стандартных таблицах OpenEdge Auditing.
Добавление или удаление учетной записи пользователя из списка привилегированных пользователей аудита, приводит к срабатыванию полиса аудита, который записывает некоторые или все изменения для сохранения истории.
В следующей таблице представлена информация о типах предоставляемых прав доступа пользователем, который уже имеет одну из привилегий аудита.
Таблица 1 Предоставление привилегий аудита
Имеющаяся привилегия аудита | Возможность предоставления привилегий другим пользователям |
Audit administrator | Audit administratorApplication audit event inserterAudit data reporter |
Audit data archiverApplication audit event inserterApplication audit event inserterAudit data reporterAudit data reporterAudit data archiverAudit data archiver
Администраторы SQL могут предоставлять права аудита с помощью оператора SQL GRANT. А ABL администраторы могут использовать Data Dictionary или Data Administration.
Если не назначен ни один администратор аудита, то контрольные функции аудита остаются за администратором базы данных. Если не существует конкретного администратора базы данных, то все пользователи автоматически получают права администратора аудита.
Рекомендуется создавать, по крайней мере, двух администраторов аудита, основного и резервного. Например, это обезопасит вас от ситуаций, когда основной администратор по определенным причинам потерял работоспособность, в этом случае, вам на помощь прейдет резервный администратор аудита.
Если же у вас был один администратор аудита, и доступ к его учетной записи был потерян, то администратор базы данных может восстановить контроль над аудитом, удалив привилегии последнего администратора и вернув себе полный контроль. Как только контроль над аудитом будет восстановлен администратором базы данных, он сможет назначить нового администратора аудита. Данная возможность доступна, только если в базе был только один администратор аудита.
Для предоставления права аудита, вы должны идентифицировать ID пользователя, выбрать соответствующую привилегию аудита для него, и добавить дополнительные комментарии. Вы так же можете указать, может ли этот пользователь выдавать права другим пользователям. Любой пользователь с правами администратора аудита способен выдавать все привилегий другим пользователям. Для всех привилегий кроме привилегии администратора аудита, опция Can Grant Permissions for по умолчанию не включена. При назначении привилегии администратора аудита, пользователь автоматически получает возможность предоставлений привилегий аудита другим пользователям.
Для предоставления привилегий аудита подключитесь к базе данных как администратор и с помощью Data Dictionary, и настройте следующее:
- Создайте учетные записи пользователей, которые будут выполнять соответствующие роли аудита. Допустим, это будут два пользователя:
- audadm – Audit administrator
- audarc – Audit data archiver
- Перейдите в меню Admin -> Security -> Edit Audit Permissions. Откроется диалоговое окно, которое позволяет настраивать права аудита пользователям:
┌──────────────────────Edit Audit Permissions (sports)──────────────────────┐ │ UserId Permission │ │ ──────────────────────────────────────────────────────────────────── │ │ │ │ │ │ │ │ │ │ UserId: │ │Permission: [V] │ │ Grantor: adm │ │ Comments: ┌────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────┘ │ │ [ ]Can Grant Permissions for │ │ │ │ Done Grant Save Cancel Revoke │ │ User ID: adm │ │ │ └───────────────────────────────────────────────────────────────────────────┘ Press CTRL-A to Grant new Permission or DEL to Revoke selection
- Выберите кнопку Grant или нажмите комбинацию клавиш CTRL-A чтобы преступить к предоставлению прав доступа. Станет активным поле UserId. В нем введите ID пользователя, который станет администратором аудита, в нашем случае, это audadm. Внимание, в поле UserId не проверяется корректность введенного пользовательского ID, поэтому будьте внимательны. После ввода ID нажмите клавишу Enter, вы перейдете к всплывающему списку Permission. После нажатия клавиши стрелки вниз, откроется список привилегий аудита, как показано на рисунке ниже. Выберите Audit Administrator:
┌──────────────────────Edit Audit Permissions (sports)──────────────────────┐ │ UserId Permission │ │ ──────────────────────────────────────────────────────────────────── │ │ │ │ │ │ │ │ │ │ UserId: audadm │ │Permission: [V] │ │ Grantor: ┌────────────────────────────────────────────────┐ │ │ Comments: │ │ │ │Audit Administrator │ │ │Application Audit Event Inserter │ │ │Audit Data Archiver │ │ │Audit Data Reporter │ │ └────────────────────────────────────────────────┘ │ │ │ │ Done Grant Save Cancel Revoke │ │ User ID: adm │ │ │ └───────────────────────────────────────────────────────────────────────────┘ Choose Permission then hit F1 to Save or CTRL-N to Cancel
- После нажатия клавиши Enter, в поле Permission установится название соответствующей привилегии, и у вас появится возможность ввести дополнительные комментарий в поле Comments. Здесь вы можете напечатать любые примечания, относящиеся к этому пользователю. Обратите внимание, что поле Can Grant Permissions for Audit Administrator оказалось выбранным, и изменить его нельзя. Это означает, что пользователь audadm может назначать любые права доступа другим пользователям.
- С помощью клавиши Tab перейдите на кнопку Save и нажмите клавишу Enter. Внесенные изменения будут сохранены.
┌──────────────────────Edit Audit Permissions (sports)──────────────────────┐ │ UserId Permission │ │ ──────────────────────────────────────────────────────────────────── │ │ audadm Audit Administrator │ │ │ │ │ │ │ │ UserId: audadm │ │Permission: Audit Administrator [V] │ │ Grantor: adm │ │ Comments: ┌────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────┘ │ │ [X]Can Grant Permissions for Audit Administrator │ │ │ │ Done Grant Save Cancel Revoke │ │ User ID: adm │ │ │ └───────────────────────────────────────────────────────────────────────────┘ Press CTRL-A to Grant new Permission or DEL to Revoke selection
С этого момента, все привилегии аудита у администратора базы данных будут отменены. Обратите внимание на поле Grantor, в этом поле прописывает ID пользователя, который выдал права аудита другому пользователю, в нашем случае, это dbadm.
- Перезайдите в базу данных, используя логин администратора аудита и повторите операцию выдачи привилегии аудита для пользователя audarc, выдав ему привилегию Audit Data Archiver.
После того, как вы выдали все привилегии соответствующим пользователям, создайте в базе данных контрольный ключ (passkey), который обеспечит безопасность данных аудита от фальсификации. Для этого:
- Войдите в базу данных под администратором базы.
- Войдите в Data Dictionary меню Admin -> Database Identification -> Database Identification Maintenance. Появится диалоговое окно, как показано на следующем рисунке:
┌────────────────Database Identification Maintenance (sports)─────────────────┐ │ │ │ DB Identifier: mgCnV1lYk7fiEWMi/hRsqA │ │ DB Passkey: │ │ DB Description: sports │ │ Additional Details: ┌────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ OK Cancel New DB Passkey/Identifier │ └─────────────────────────────────────────────────────────────────────────────┘
- Выберите кнопку New DB Passkey/Identifier. Откроется диалоговое окно смены ключа базы данных:
┌──────────────────New Database Passkey/Identifier (sports)───────────────────┐ │ DB Identifier: tGtKo5FFYI3iEWUi5DkR+w │ │ DB Passkey: │ │ Verify Passkey: │ │ [X]No Passkey │ │ │ │ Generating a new Database Passkey or Identifier may change how your │ │ database is identified in utilities that use these values. │ │ │ │ You should be very certain that it is your intention to perform this │ │ action before saving changes. │ │ │ │ OK Cancel │ │ │ └─────────────────────────────────────────────────────────────────────────────┘
- Нажмите кнопку Change Passkey. В поле No Passkey снимите флаг, которое указывает, что Passkey не используется. Активируются поля DB Passkey и Verify Passkey. В первом поле введите контрольный ключ базы данных, а во втором повторите его. При этом вводимые символы не будут отображаться.
- Нажмите кнопку Ok.
Настройка стандартных полисов аудита
Для загрузки стандартных полисов OpenEdge Auditing используется приложение Audit Policy Maintenance. Для работы с ним необходимо выполнить следующее:
- Запустите приложение Audit Policy Maintenance (приложение доступно в версии OpenEdge для Windows)
- В меню File выберите Import Policy.
- В появившемся диалоговом окне укажите место расположения файла policies.xml. Обычно он находится в установочном каталоге Progress: %DLC%/auditing.
- Нажмите кнопку Ок для начала загрузки полисов аудита.
Как только полисы аудита будут загружены в Audit Policy Maintenance, вам необходимо отредактировать и настроить их для своих целей. Как только редактирование будет завершено, вам необходимо сохранить все изменения, выбрав в меню File -> Commit Changes.
О том, как выполнять настройку существующих и собственных полисов аудита смотрите Audit Policy Maintenance Help Topics из меню Help.
Метка:OpenEdge