Читать онлайн «SAP R/3 Системное администрирование». Страница 46

Подготовка обычного диалогового пользователя для доступа через Интернет не отличается от обслуживания пользователей, описанного выше (см. раздел 8.2.1). Кроме описанных там параметров, можно также присвоить пользователю одного или несколько ссылочных пользователей. Ссылочные пользователи позволяют расширить полномочия пользователя и обеспечить всем пользователям Интернета идентичные полномочия.

Если требуется отдельный пользователь Интернета для IAC, то его можно сконфигурировать следующим образом:

1. Выберите Internet user (см. рис. 8.19).

Рис. 8.19. Обслуживание пользователей Интернета

2. Введите идентификатор пользователя (ID).

3. Задайте тип пользователя. Тип часто соответствует прикладной области и ограничивает права пользователя. Например, «KNA1» означает, что данную транзакцию Интернета может выполнять только сам пользователь.

4. Инициализируйте пользователя с помощью Initialize.

5. Теперь пользователь активен. Система автоматически генерирует для него пароль. Чтобы сменить пароль, выберите Change Password.

Пользователя Интернета можно блокировать и разблокировать.

Чем больше пользователей работает в системе R/3, тем более сложным и трудным будет управление пользователями и мониторинг критических для безопасности пользователей. Система SAP обладает дополнительными инструментами для выполнения этих задач.

Чтобы предоставить системному администратору обзор всех пользователей и полномочий, система R/3 предлагает специальную ►Information system. Она позволяет анализировать и сравнивать пользователей и полномочия, предоставленные в системе для большого набора критериев. На рис. 8.20 показан начальный экран этого инструмента.

Информационная система пользователей делает возможным, например, выбрать всех пользователей, которые были назначены определенной роли, или определить все роли, содержащие определенные полномочия.

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

Журнал аудита безопасности (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 в структуре предприятия: