SAP R/3 Системное администрирование
Шрифт:
Журнал аудита безопасности (Security Audit Log) позволяет регистрировать всю деятельность пользователя, которая имеет отношение к безопасности системы. Аудиторы часто требуют такие записи, особенно для пользователей с критически важными полномочиями, чтобы гарантировать контролируемость системы. Не имеет смысла и технически невозможно регистрировать деятельность всех пользователей с помощью журнала аудита безопасности. Журнал аудита чаще используется для мониторинга критически важных пользователей, которые имеют много полномочий, особенно пользователи
Рис. 8.20. Информационная система пользователей
Функцию ►Security Audit Configuration можно использовать для определения, какие типы деятельности и для каких пользователей будут записываться в журнал аудита безопасности. Эти пользователи и виды деятельности затем будет контролироваться постоянно. Можно использовать ►Security Audit Analysis для анализа записей аудита согласно различным критериям.
Сначала в ►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 в структуре предприятия:
► Число пользователей на систему
► Число логических систем
► Частота изменений пользователей и полномочий
► Продолжительность разработки (и поэтому время, в течение которого разработчики требуются как пользователи систем)