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

Можно выбрать пользователей по адресам или полномочиям. Выбор особенно прост, когда пользователи разделены на подходящие группы (см. раздел 8.2.1).

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

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

8.2.4. Защита имени входа и пароля

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

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

► Пароль не может совпадать с PASS или SAP*.

► Пользователи могут изменять свои пароли только один раз в день.

Обзор возможных параметров профилей и рекомендуемых настроек представлен в «Руководстве по защите данных для SAP R/3» и «Руководстве по безопасности SAP». Некоторые из наиболее важных параметров профиля для защиты пароля описаны ниже:

► login/min_password_lng

Определяет минимальную длину пароля (минимум 3; максимум 8 символов)

► login/password_expiration_time

Определяет допустимый период действия паролей в днях

► login/disable_multi_gui_login

Управляет возможностью многократной регистрации одного и того пользователя

В качестве альтернативы регистрации с помощью пароля можно реализовать также регистрацию с помощью Single-Sign-On (SSO). С помощью этого метода пользователь регистрируется в системе безопасности, используя имя пользователя и пароль только один раз. Оттуда данные регистрации пересылаются как маркер регистрации или сертификат в другие системы, где регистрируется пользователь; дополнительная аутентификация больше не требуется. При использовании SSO требуется использование защищенной сетевой коммуникации (SNC).

8.2.5. Стандартные пользователи

Среди идентификаторов пользователей стандартные пользователи SAP* и DDIC (называемые также суперполъзователями) играют специальную роль. SAP* и DDIC создаются автоматически в каждом клиенте системы R/3 (см. таблицу 8.2). SAP* обладает всеми полномочиями в системе R/3. Пользователь DDIC обладает всеми полномочиями для управления репозиторием R/3 (см. главу 7). Для суперпользователей некоторые компоненты системы изменений и переноса (CTS) будут вызываться только в режиме вывода, чтобы избежать пользовательских разработок с этим идентификатором.

Таблица 8.2. Стандартные пользователи и их предопределённые пароли

Клиент Пользователь Стандартный пароль 000 SAP* 06071992 000 DDIC 19920706 001 SAP* 06071992 001 DDIC 19920706 066 EARLYWATCH support

Одним из первых действий после инсталляции является защита этих пользователей и предотвращение неавторизованного доступа к системе с помощью изменения используемых по умолчанию паролей. Рекомендуется также изменить стандартный пароль «SUPPORT» пользователя EARLYWATCH клиента 066. Однако пользователь EARLYWATCH имеет полномочия вывода только для функций мониторинга производительности, поэтому он создает только небольшой риск для безопасности. В отличие от EARLYWATCH пароли пользователей SAP* и DDIC должны храниться с большими предостережениями; однако необходимо гарантировать, что они будут немедленно доступны в случае срочной необходимости.

8.3. Назначение полномочий

Распределение ответственности

Создание пользователя — это одна из задач системного администратора R/3 или администратора пользователей. Полномочия определяются, исходя из того, какие действия должен выполнять пользователь конкретного типа или группы. Иногда задачи назначения полномочий возлагают на другое лицо — администратора полномочий. Рекомендуется распределить эти обязанности хотя бы между двумя лицами, что позволит свести к минимуму риск защиты. Если пользователь имеет права на создание новых пользователей и полномочий, то он может предоставить себе все полномочия на системе R/3 и получить неограниченный доступ к данным. Этого можно избежать, если разделить эти обязанности между несколькими лицами. Обслуживание полномочий может быть обязанностью исключительно отделов пользователей или осуществляться в тесном сотрудничестве с ними. Относительно назначения полномочий существует две различные точки зрения. Для пользовательских отделов основным приоритетом является деловая активность — действия, разрешаемые или запрещаемые пользователю. Для администратора R/3 основной приоритет заключается в технических аспектах назначения полномочий и управления ими. Системный администратор не может решить, в каких полномочиях (в плане бизнеса) нуждается пользователь. Поэтому в следующих разделах рассказывается о технических аспектах назначения полномочий.

Полномочия пользователя — один из наиболее важных атрибутов, контролируемых администратором. Как и в любом другом ПО, назначение полномочий в R/3 имеет две стороны. Область деятельности пользователя следует максимально ограничить — она должна определяться исключительно выполняемыми им задачами. С другой стороны, пользователь должен обладать всеми правами, необходимыми ему для выполнения своих задач. Администратору нужно выбрать компромисс между тем и другим. Полномочия в R/3 — это сложная система индивидуальных прав и полномочий групп пользователей. Она допускает разные уровни настройки.

8.3.1. Обзор проверки полномочий

Проверка полномочий происходит всякий раз, когда в системе SAP вызывается транзакция. Проверка является двухшаговым процессом: сначала проверяются полномочия для транзакции (когда вызывается транзакция), а затем, когда запускается действие, в объекте полномочий проверяются полномочия для действия.

Концепция роли

Полномочия присваиваются пользователям как роли (до Basic Release 4.6B называвшиеся группами деятельности). Полномочия объединяются в группы как роли и вводятся в главные записи пользователей. В этом контексте роль является описанием задания, которое может быть присвоено различным пользователям. Кроме полномочий, роли содержат также определение меню пользователя (что описано подробнее в контексте обслуживания роли) и рабочие потоки.

По историческим причинам и для улучшения технического обслуживания полномочия роли объединяются в группы в профилях, которые создаются автоматически во время обслуживания роли. В более ранних версиях эти профили необходимо было обслуживать вручную. Хотя ручная обработка по-прежнему возможна, она теперь требуется в редких случаях.

Рис. 8.4. Двухэтапная проверка полномочий

В идеале администратор должен только выбрать одну из предопределенных ролей и присвоить ее пользователю. Затем во время сравнения пользователей (см. раздел 8.3.8) полномочия будут записаны в соответствующие контексты пользователя как профили.

8.3.2. Полномочия и объекты полномочий

Каждое полномочие в системе R/3 основано на так называемом объекте полномочий. С технической точки зрения этот объект представляет собой модуль, содержащий имя, поля полномочий и, возможно, значения, которые представляют операции (действия). Присваивание объекта полномочий процессу (например, отчету, транзакции или обновлению) определяется SAP. Технически полномочие является набором значений для определенного объекта полномочий, который предоставляет пользователю разрешение выполнять действие в системе SAP. Система полномочий SAP работает только с полномочиями; не существует определенных запрещений деятельности. Конечно, это означает также, что все действия, которые явно' не разрешены полномочиями, будут запрещены.