Сначала в ►Security Audit Configuration (см. рис. 8.21) необходимо создать профиль. Затем имя этого профиля используется для сохранения настроек.

Фильтры

Можно использовать фильтры для определения, какие события в каких классах аудита (диалоговая регистрация, начало транзакции, RFC и т.д.) будут записываться для каких пользователей в каких клиентах. Можно использовать символы-местозаполнители (*) для пользователя и клиента, но нельзя использовать записи с групповыми символами, такие как «MULLER*». В результате число пользователей, которые могут записываться в журнал с помощью профиля, ограничивается числом фильтров. Необходимо явно выбрать каждый фильтр с помощью Filter active.

Рис. 8.21. Конфигурация журнала аудита безопасности

Профиль

После конфигурирования критерия фильтра нужно сохранить профиль. Дополнительные значки для управления профилем появятся в панели инструментов. Чтобы начать запись в журнал в соответствии с созданными фильтрами, необходимо активировать выбранный профиль через меню или пиктограмму. Активированный профиль будет использоваться при следующем запуске системы.

Динамическая конфигурация

В качестве альтернативы статической конфигурации можно также изменять эти настройки динамически во время работы с помощью вкладки Dyn.Configuration. Параметризация использования фильтров для динамической конфигурации идентична статической конфигурации

Записанные в журнал данные сохраняются в файлах на уровне операционной системы. Функция ►Security Audit Analysis позволяет выбирать с помощью известных параметров фильтра, а также по дате/времени и терминалу пользователя. Выбранные данные форматируются в соответствии с настройками системного журнала (см. главу 15)

Параметры профиля

Для использования журнала аудита безопасности необходимо активировать его через параметры профиля и определить, сколько фильтров можно использовать. Наиболее важными параметрами профиля являются:

► rsau/enable– Активирует журнал аудита безопасности

► rsau/max_diskplace/local– Максимальный объем пространства, который может быть выделен файлам аудита

► rsau/selection_slots– Число фильтров, допустимых для журнала аудита безопасности (максимум 5)

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

Файлы анализа могут очень быстро увеличиваться в размере в зависимости от сконфигурированных критериев фильтра. Поэтом? необходимо регулярно делать резервные копии этих файлов, чтобы удалить их на уровне операционной системы.

В больших системных средах с множеством пользователей описанное выше локальное управление пользователями может требовать много времени Обслуживание одинаковых пользователей в различных системах и синхронизация изменении между системами, что означает, что администраторам необходимо регистрироваться на каждой локальной системе, может сделать обслуживание пользователей утомительным и подверженным ошибкам. К счастью здесь может помочь Центральное управление пользователями (CUA- Central User Administration). В Basis Release 4.6 и более поздних версиях можно выполнить все действия по обслуживанию пользователей на одном определенном клиенте одной системы, а затем распространить данные на других клиентов той же или других систем. Специальный клиент является отправителем (центральной системой), в то время как все остальные клиенты (дочерние системы) - получателями данных. Application Link Enabling (ALE, см. главу 13) является технологией, которая используется для обмена данными. Клиенты, которые обмениваются данными, конфигурируются и управляются как логические системы.

Преимущества

После конфигурирования CUA пользователи могут создаваться или удаляться только в центральной системе. Для каждого атрибута пользователя можно определить (в управлении CUA), будет ли этот атрибут обслуживаться только центрально, только локально или центрально и локально. Поэтому требуемые роли и полномочия должны существовать в активной форме во всех дочерних системах. В результате каждый пользователь должен обрабатываться только один раз, централизованно, что дает администраторам существенно более четкое представление обо всех пользователях и полномочиях.

Значение этих преимуществ CUA слегка снижается из-за возросших усилий, требуемых для конфигурирования сценария ALE и синхронизации существующих пользователей, а также дополнительными навыками, требуемыми от администратора. Следующие критерии помогут определить, имеет ли смысл конфигурировать CUA в структуре предприятия:

► Число пользователей на систему

► Число логических систем

► Частота изменений пользователей и полномочий

► Продолжительность разработки (и поэтому время, в течение которого разработчики требуются как пользователи систем)