ГЛАВА 8

ПОЛЬЗОВАТЕЛИ И ИХ ПОЛНОМОЧИЯ В СИСТЕМЕ R/3

Концепция пользователя — одно из основных понятий в системе защиты R/3. Для достижения необходимого уровня защиты администратор системы R/3 должен быть знаком с возможностями, которые предлагает концепция пользователей и подготовленным к реализации этой концепции.

Пользователь

С точки зрения системы SAP пользователь является техническим идентификатором, с помощью которого выполняется некоторое действие. Идентификатору пользователя присваиваются свойства, которые сохраняются в главной записи пользователя (user master record). Пользователь может быть реальным физическим пользователем или техническим пользователем, который используется только для фоновой обработки.

Имя пользователя

Пользователь идентифицируется уникальным образом с помощью имени пользователя (user name), одновременно являющегося строкой символов, которую реальный пользователь использует для регистрации в системе и идентификатором, используемым внутри системы.

Наиболее важные свойства пользователя включают полномочия этого пользователя, которые присваиваются как профили (profiles). Администрирование и присвоение этих профилей является еще одной темой, рассматриваемой в данной главе.

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

Использование главных записей

После инсталляции в системе R/3 доступен ряд стандартных клиентов и пользователей (см. главу 7). Пользователи всегда являются зависимыми от клиента, т. е. действительными только для клиента, где они были определены. Другим важным свойством пользователя является пароль, который должен вводиться при входе в систему (регистрации), и который можно изменить в любое время, включая регистрацию в системе. Кроме того, при входе в систему можно выбрать предпочитаемый для работы язык. Имя пользователя и присвоенные ему свойства составляют главную запись пользователя (user master record). Она включает в себя следующие группы элементов, которые также появляются на вкладках (см. таблицу 8.1) для управления адресами:

Таблица 8.1. Вкладки управления адресами

Ведение пользователей, которое описывается в следующем разделе, включает создание, изменение и удаление пользователей, кроме поддержания их свойств в главной записи пользователя. Не обязательно выбирать значения для всех этих свойств, например, можно не задавать дату окончания действия (ограничивающую срок действия полномочий пользователя конкретным периодом времени). Сложность возможных настроек пользователя позволяет адаптировать систему R/3 к индивидуальным требованиям, а также ограничить полномочия заданными прикладными областями.

Администрирование пользователей начинается с ►User Maintenance (см. рис. 8.1). Это меню содержит все функции для создания, изменения и удаления пользователей, а также для управления их свойствами.

Рис. 8.1. User Maintenance: начальный экран

Для определения пользователя надо ввести уникальное имя пользователя в поле User. В Basic Release 4.6C и более поздних версиях можно использовать поле Alias (псевдоним) для выбора пользователей с помощью дополнительного идентификатора, которые пользователи создают, например, из транзакций Интернет в области самообслуживания. В этом месте нельзя создать псевдоним. В следующем примере предполагается, что пользователь MUSTERMANN создан с помощью User names • Create или с помощью соответствующей пиктограммы.

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

Адрес пользователя

При создании пользователя MUSTERMANN выводится экран, аналогичный показанному на рис. 8.2, на котором можно ввести данные адреса пользователя. Технически на странице закладки Logon data необходимо поддерживать хотя бы фамилию пользователя и пароль. Необходимо ввести все известные адресные данные на тот случай, если возникнет необходимость контакта с пользователем.

Рис. 8.2. Определения адреса пользователя

Не требуется вводить один и тот же адрес для каждого пользователя. Можно определить ►Company Addresses и присваивать их пользователям.

Данные регистрации в системе

На вкладке Logon Data нужно определить пароль и тип каждого пользователя. В Basic Release 4.6C и более новых версиях необходимо также определять группу пользователя для новых пользователей. На рис. 8.3 показаны настройки для создания пользователя MUSTERMANN.

Пароль при вводе отображается в замаскированной звездочками форме. Тип пользователя определяет, в каком из следующих режимов он работает в системе R/3:

Рис. 8.3. Данные регистрации пользователя

► Dialog (диалоговый)

Диалоговый пользователь может работать в системе R/3 произвольным образом, включая фоновую и пакетную обработку, услуги CPI-С и режим диалога (если это не запрещается явно его полномочиями). Условия лицензирования SAP запрещают использование одновременно нескольких одинаковых идентификаторов пользователя в рабочих системах.

► Communication (коммуникация)

Пользователь с типом Communication может использоваться для бездиалоговой коммуникации между системами, такой как вызов удаленной функции (RFC, см. главу 13). Такому пользователю не разрешается регистрироваться в системе R/3 или начинать диалоговую обработку.

► System (система)

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

► Service (служба)

Пользователь с типом Service является диалоговым пользователем, который доступен для большой анонимной группы пользователей, например для доступа через Интернет Transaction Server (ITS). Для этого типа пользователей не выполняется никакой проверки окончания срока действия или начальных паролей, и явно разрешена множественная регистрация. Однако по соображениям безопасности необходимо только назначать таких пользователей с большой осторожностью и с ограниченными полномочиями.

► Reference (ссылочный)

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

Пользователь MUSTERMANN определен как диалоговый пользователь. Соответственно не существует никаких ограничений на использование системы R/3, которые связаны с типом пользователя.

Группа пользователей

Группа пользователей служит для документирования и получения технической информации, помогает координировать назначение полномочий и обслуживать данные пользователей. Пользователь в одной группе может обслуживать данные пользователя в другой группе, только если имеет на это явные права. Необходимо ввести группу пользователей на вкладке Logon data (Данные регистрации); пользователь может добавить дополнительные группы пользователей на вкладке Groups. Кроме того, организация пользователей в группы облегчает массовые изменения пользователей (►Mass Change).

Группа пользователей SUPER вначале является единственной группой, уже определенной в системе R/3. Эту группа необходимо использовать для всех пользователей, которые имеют сходные полные полномочия в системе. Логическое назначение пользователя группе позволяет судить о его полномочиях и прикладных областях. Для создания и обслуживания групп пользователей с помощью инструментальных средств выберите команду Environment • User Group или используя ►User Group. Например, создайте группу MM, в которую можно будет позднее включить пользователей прикладной области Materials Management. Это позволяет определить администратора пользователей, который может управлять пользователями только в этой группе.

Другие данные (номер счета, место возникновения затрат) можно анализировать для целей статистики с помощью отчетов. Эти данные не оказывают влияния на деятельность пользователя.

Вкладка Defaults

Вкладку Defaults можно использовать для определения используемых по умолчанию настроек устройств вывода, часовых поясов, формата данных и десятичной нотации. Можно также задать значение по умолчанию для языка регистрации пользователя. В этом случае пользователю больше не требуется вводить язык регистрации во время регистрации. Пользователи могут принимать значения по умолчанию пользователя, чтобы удовлетворить свои специфические требования с помощью меню ►Own Data (см. раздел 8.4).

Вкладка Parameters

Вкладку Parameters можно использовать для определения зависящих от пользователя значений по умолчанию для часто используемых полей ввода. Пользователи могут настроить эти данные самостоятельно с помощью пункта меню ►Own Data (см. раздел 8.4).

SNC

Если используется защищенная сетевая коммуникация SNC (в противном случае вкладка не выводится), то можно использовать вкладку SNC для определения имени, которое используется для аутентификации пользователя во внешнем продукте системы безопасности.

Personalization

Пользователи могут вводить индивидуальные настройки для объектов персонализации на вкладке Personalization. Объекты персонализации должны быть предопределены и реализованы в прикладном компоненте, чтобы их можно было здесь выбрать. Вкладка и все интерфейсы доступны уже в Basic Release 4.6C, в то время как стандартные объекты персонализации, которые можно настраивать таким образом, включены в версию Release 6.10 и более новые.

Вкладки Roles (до Basic Release 4.6B: Activity groups) и Profiles используются для присвоения пользователю требуемых полномочий. Этот процесс более подробно описан ниже.

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

Реальное измерение выполняется с помощью ►System Measurement или ►License Administration Workbench для более сложных системных инфраструктур (т.е. Service Data Control Center (SDCC) в SAP Web AS и более поздних версиях).

Правила классификации и измерения зависят от конкретной версии и контракта и описаны подробно во «Введении в измерение системы».

Все описанные в предыдущих разделах данные можно снова изменить позже в таких же транзакциях. Одновременное изменение нескольких пользователей может быть крайне трудоемким. К счастью, для этого существует специальная функция ►Mass Change, которая позволяет создавать и выполнять большинство изменений при администрировании пользователей для выбранного множества пользователей.

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

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

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

При создании нового пользователя администратор присваивает начальный пароль, который пользователь должен изменить во время первой регистрации в системе. Этот пароль вместе с именем пользователя требуется для регистрации в системе 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

Классы объектов

Число объектов авторизации в системе R/3 весьма значительно, что связано с диапазоном функций R/3. Чтобы лучше различать их, объекты разделяются на классы объектов. Чтобы просмотреть все доступные в системе SAP объекты полномочий можно использовать ►Object Classes. Например, MM_E — класс объектов Materials Management-Purchasing (управление материалами-закупками). Выбрав эту область, можно получить все доступные для нее объекты полномочий. Небольшой текст дает описание объекта полномочий. Например, выберите M_BEST_EKG для заказа детали. Такой объект полномочий включает в себя поле полномочий ACTVT, содержащееся в каждом объекте полномочий по умолчанию, и специальное поле EKGRP (см. рис. 8.5). Назначение данных полей и значений, которые они могут содержать, описываются в документации по R/3.

Рис. 8.5. Объект полномочий M_BEST_EKG

В данном примере в поле EKGRP можно задать имя или диапазон имен определенных групп закупки. Щелкните на кнопке Permitted activities, чтобы определить все возможные значения для деятельности.

Таблица 8.3. Возможные значения в поле ACTVT и их описания

Большинство полномочий уже определены с помощью значения «*», поэтому нужно ввести для компании только необходимые специфические значения. Можно использовать ►Role Maintenance • Environment • Auth.Objects для вывода всех существующих полномочий для объекта полномочий, изменения существующих полномочий или добавления новых.

Если принять во внимание сложность системы R/3, станет очевидно, что, хотя можно определить и присвоить все необходимые полномочия каждому отдельному пользователю, требуемые громадные усилия не оправдывают такой подход. Это является причиной того, почему полномочия могут группироваться вместе. Для поддержания всех наборов полномочий одновременно можно использовать роли. Более ранние версии Basis используют для этой цели профили полномочий; система R/3 продолжает использовать эти профили полномочий в качестве технического инструмента.

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

Эти профили затем автоматически генерируются во время обслуживания роли, как описано ниже. Это одновременно простейшая и наиболее рекомендуемая процедура. Однако в исключительных случаях, таких как пользовательские разработки, может понадобиться изменить существующие профили вручную или создать новые. Обслуживание профилей вручную возможно в ►User Maintenance с помощью Environment • Profiles • Maintain profiles (в Basis Release 6.10 и более поздних выводится предупреждающее сообщение, указывающее, что для обслуживания полномочий необходимо использовать роли).

Профили в R/3 могут иметь разные состояния:

► Активный/неактивный

► Обслуженный (т. е. адаптированный к текущим условиям) или оставленный без изменений (стандартный)

Если система стандартная (немодифицированная), то все ее профили еще не обслужены. Создаваемые новые профили должны активизироваться (т. е. о них должна знать вся система — лишь после этого они будут ей доступны в системе).

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

Составные профили

Можно также создать новые профили путем слияния определенных заказчиком или стандартных полномочий или профилей полномочий. Эти профили называют составными профилями. Чтобы вручную присвоить полученные профили пользователю, используйте при создании пользователя вкладку Profiles. На рис. 8.6 показаны профили, присвоенные пользователю SAP*. Ему присвоен профиль SAP_ALL, охватывающий все возможные операции в системе R/3.

Рис. 8.6. Профиль полномочий пользователя SAP*

Рис. 8.7. Иерархическая организация полномочий и профилей

Поля полномочий

Объекты полномочий (которые логически делятся на классы объектов) состоят из стандартного поля Activity и дополнительных полей полномочий. Полномочие определяется на основе значений для полей объекта полномочий, которые представляют разрешение для действия. Определяя различные значения можно создать разные полномочия для объекта полномочий.

Чтобы упростить администрирование, полномочия объединяются вместе как профили или генерируются автоматически во время обслуживания роли. Эти профили записываются в главной записи пользователя - либо автоматически, если используются роли, либо вручную.

Полномочия системного администрирования также должны разделяться в соответствии с областями ответственности и распределяться с помощью ролей (см. раздел 8.3.8). Система SAP имеет несколько профилей, которые особенно важны для администрирования и которые иногда должны назначаться явно (см. таблицу 8.4).

Таблица 8.4. Наиболее важные для администрирования профили полномочий

Роли

Роль (до Basis Release 4.6B: группа деятельности) является описанием рабочей среды, которое можно присвоить пользователю. Определение ролей существенно облегчает администрирование пользователей. Если нужно изменить полномочия, то необходимо только изменить роли. После генерации измененных ролей можно выполнить сравнение пользователей, чтобы изменения автоматически вступили в силу для всех соответствующих пользователей. Роль содержит следующую информацию:

► Имя роли

► Текстовое описание роли

► Рабочие операции роли

► Профили полномочий

► Пользователи, которым присвоена роль

► Данные индивидуализации

► MiniApps (в Basis Release 6.10 и более поздних версиях)

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

Подготовка к обслуживанию роли

Чтобы активировать обслуживание роли с помощью Profile Generator, необходимо сначала включить деактивацию проверки полномочий, для чего нужно задать следующий параметр в профиле инстанции:

□ auth/no_check_in_some_cases = Y

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

SAP values

Следующий шаг в подготовке к использованию Profile Generator состоит в копировании индикаторной проверки для объектов полномочий транзакции и значений полей полномочий для Profile Generator, предоставленных SAP (значений SAP) в таблицы заказчика. Чтобы скопировать индикаторы проверки, используйте утилиты из ►SAP values (см. рис. 8.8).

Рис. 8.8. Интеграция значений SAP

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

Затем можно вручную изменить объекты полномочий или составных профилей для отдельных транзакций. Для этого используется ►Check Indicators в Customizing (см. рис. 8.9).

Рис. 8.9. Работа с присвоением транзакциям объектов полномочий

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

Чтобы сделать эти изменения переносимыми, необходимо присвоить их классу разработки заказчика (в Basis Rerlease 6.10 и позже — пакету). Поэтому сначала необходимо определить как минимум один класс разработки заказчика.

На рис. 8.10, например, показаны индикаторы проверки для всех объектов полномочий, используемых для транзакции AL09 (Download Monitoring Data). Индикатор проверки может иметь одно из следующих значений статуса:

► U — Индикатор проверки не определен, аналогично проверке для N

► N — Объект полномочий не проверяется для транзакции

► С — Объект полномочий проверяется для транзакции

► CM — Объект полномочий проверяется для транзакции и в Profile Generator предлагаются значения указанных полей

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

Рис. 8.10. Объекты полномочий и индикаторы проверки для транзакции AL09

Стандартные роли

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

Можно вызвать обзор предоставленных ролей в информационной системе (см. раздел 8.6) или с помощью отчета RSUSR070. Если эти роли удовлетворяют требованиям, то можно присвоить их пользователям непосредственно (см. раздел 8.3.8); не требуется создавать роли самостоятельно.

Обслуживание ролей

Транзакция ►Role Maintenance (обслуживание ролей) позволяет копировать, создавать, изменять, присваивать, сравнивать и переносить роли. Обслуживание роли заказчика сострит в основном из двух шагов:

1. Присвоение меню пользователя

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

Для иллюстрации этой процедуры используется относительно простой пример: требуется создать и отредактировать роль для системных администраторов R/3.

На первом шаге требуется создать роль или скопировать ее с существующей роли.

1. Выберите ►Role maintenance для создания ролей и обслуживания существующих. На рис. 8.11 показан начальный экран; в данном примере создается роль с именем zadmin.

2. Введите затребованное имя роли, такое как zadmin. Имена ролей, которые начинаются с «SAP_*», зарезервированы для стандартных ролей.

3. Выберите представление Basic maintenance.

Рис. 8.11. Создание ролей

Базовое обслуживание и полное представление

Для обработки ролей доступны три режима. При простом обслуживании обрабатывается только меню пользователя (например, для рабочего места). Базовое обслуживание включает меню, профили и персонализированные объекты. Описанная роль присваивается реальным пользователям R/3 позже. Полное представление, однако, значительно сложнее и непосредственно связано с HR Organizational Management. Вместо присваивания существующих пользователей R/3 по имени можно присваивать должности, рабочие места или организационные единицы, которые предоставляют большую гибкость. Этот подход имеет смысл только в том случае, если в R/3 используется HR Organizational Management. Соответственно следующий пример ограничен базовым обслуживанием.

4. Выберите Create.

5. Каждая вкладка при обслуживании роли (см. рис. 8.12) имеет цвет, который указывает на статус соответствующей части обслуживания роли:

- Еще не обслужено (красный)

- Устаревший (желтый)

- Обслужен и является текущим (зеленый)

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

6. Теперь можно создать меню пользователя на вкладке Menu. Можно использовать меню из меню SAP, из других ролей, из меню области приложений и импортировать из файла. Можно также добавлять отдельные транзакции, запросы и другие объекты, такие как адреса Web. Выберите из этих вариантов подходящие виды деятельности для роли.

Рис. 8.12. Базовое обслуживание ролей

7. Для данного примера выберите раздел Tools CCMS из меню SAP и добавьте транзакцию SM21 (оперативный анализ системного журнала) и адрес Web SAP Service Marketplace (см. рис. 8.13).

8. Сохраните результаты работы.

9. Вернитесь к базовому обслуживанию. После завершения деятельности по обслуживанию статус пункта Menu изменится на зеленый.

Рис. 8.13. Выбор видов деятельности

Меню пользователя

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

10. Далее для выбранных операций генерируется профиль полномочий. При обслуживании роли выберите вкладку Authorizations (см. рис. 8.14) и введите имя нового профиля полномочий. Все имена с «_» в качестве второго символа зарезервированы для стандартных профилей SAP. Можно позволить системе предложить значение, но оно состоит из трудно запоминаемой строки символов (см. рис. 8.17). Для упрощения последующего анализа рекомендуется использовать свое собственное имя или описательный короткий текст.

Рис. 8.14. Обслуживание полномочий

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

► Зеленый — все полномочия имеют значения, но нужно их проверить.

► Желтый — по крайней мере, одно поле требует ввода значения (например, имя пользователя или устройства), которое необходимо задать вручную.

► Красный — существует поле, для которого не заданы организационные уровни.

Состояние группы операций, класса объектов, объекта, полномочий или поля может также быть следующим (выводится в обзоре как текст):

► Standard(стандартное) — во всех подчиненных узлах стандарты SAP не изменялись.

► Changed (измененное) — по крайней мере, в одном подчиненном узле стандарты SAP изменены.

► Maintained (обслуживаемое) — по крайней мере, в одно подчиненное поле, не заполненное SAP, были введены пользовательские значения.

► Manually (добавлено вручную) — по крайней мере, одно полномочие было вручную добавлено к подчиненным узлам.

► Old (старое) — после обновления R/3 сравниваются значения существовавших ранее и новых объектов и значений. Если все подчиненные значения идентичны, то узлу (хотя он все еще является текущим) присваивается состояние «старый».

► New (новое) — при сравнении обнаружилось, что были добавлены новые значения.

Теперь можно вручную внести изменения в выбранные полномочия и при необходимости присвоить значения. Можно также добавить или удалить полный набор полномочий. На рис. 8.14 показаны полномочия, выбранные для данного примера. Для этого нужно выполнить следующие шаги:

1. Выбрать узел и открыть его.

2. Теперь можно:

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

- Создать новые полные или отдельные полномочия с помощью команды Edit • Insert • Authorizations.

- Создать или изменить значения объекта полномочий, выбрав соответствующий символ в строке. Например, если обратиться к рис. 8.14, то рекомендуется создать значения полномочий на устройства в системе спула R/3. Эти значения описывают имена устройств, на которые распространяются полномочия. Например, D* означает все имена устройств, начинающиеся с D.

- Вручную удалить или добавить отдельные коды транзакций, соответствующие операциям.

3. После внесения изменений на всех светофорах должен быть зеленый свет. Сохраните изменения.

4. Выберите значок Generate Authorizations.

5. Создается профиль с присвоенными полномочиями и сохраняется с определенным на предыдущем экране именем.

6. Вернитесь к базовому обслуживанию. После завершения обработки статус обслуживания полномочий изменяется на зеленый.

Составные роли

Чтобы еще больше упростить администрирование, можно сгруппировать роли в виде составных ролей. Создание и обслуживание составных ролей в основном совпадает с обслуживанием отдельных ролей.

На начальном экране ►Role maintenance введите имя и щелкните на кнопке Create collective role, чтобы создать составную роль. Используйте вкладку Roles для определения ролей, которые желательно объединить вместе. Можно импортировать и обрабатывать меню отдельных ролей на вкладке Menu. Полномочия в этом месте редактировать нельзя.

В больших проектах R/3 обязанности системного администратора обычно распределяются по нескольким областям и присваиваются различным людям или группам. Пользователь SAP* имеет профиль SAP_ALL, который включает все виды деятельности, включая специфические для приложений. Поэтому этот пользователь не подходит для обычной деятельности и должен быть защищен от неавторизованного использования. Вместо этого необходимо определить специальных пользователей с ролями, созданными для специальных целей.

Таблица 8.5. Наиболее важные роли для администрирования

Есть два основных способа назначения ролей:

1. Роли назначаются пользователям в ►User Maintenance

2. Пользователи назначаются ролям в ►Role Maintenance

Чтобы назначить роли в ►User Maintenance (см. раздел 8.2.1), выберите вкладку Roles. Затем можно ввести требуемые роли непосредственно для этого пользователя. При этом для данной роли сгенерированные профили автоматически добавляются на вкладку Profiles.

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

Пользователей можно назначать роли на вкладке User при обслуживании роли.

1. Выберите вкладку User.

2. Введите нового пользователя в поле User ID (см. рис. 8.15 для пользователя MUSTERMANN). Пользователь уже должен быть определен.

Рис. 8.15. Назначение пользователя

Период действия

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

3. Щелкните на кнопке User compare, чтобы назначить созданные для роли профили полномочий выбранным пользователям (см. рис. 8.16). Этот процесс называется сравнением основных записей пользователей.

4. Выйдите из обслуживания ролей.

Это завершает пример. Транзакцию обслуживания пользователей можно использовать для подтверждения того, что сделанные изменения были сохранены. Все назначенные пользователи получили выбранную роль и сгенерированный профиль. На рис. 8.17 это показано для пользователя MUSTERMANN.

Рис. 8.16. Сравнение основных записей пользователей

Рис. 8.17. После сравнения основных записей пользователей

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

► Сравнение пользователей во время назначения пользователей с помощью кнопки User compare (см. пример выше). В этом случае вывод статуса кнопки указывает, требуется ли другое сравнение. Этот метод хорошо подходит для обслуживания роли в системе разработки.

► Выбор пункта Automatic User Master Adjustment when Saving Role в ►Role Maintenance в меню SAP в разделе Utilities • Settings. Затем сравнение выполняется автоматически каждый раз при сохранении роли.

► Сравнение пользователей с помощью отчета PFCG_TIME_ DEPENDENCY. Необходимо планировать это задание периодически (ежедневно, если возможно) в качестве фонового задания. Это единственный способ гарантировать, что пользователи поддерживаются актуальными особенно в системах консолидации и производства, где изменения профилей импортируются как переносы. Этот отчет выполняет полное сравнение пользователей, удаляя все назначения, которые становятся недействительными.

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

При использовании Central User Administration (CUA, см. раздел 8.7.4), пользователей можно назначать только в центральной системе.

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

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

Преобразование в Profile Generator

Обновление версии системы R/3, которая не использует Profile Generator, в версию, использующую эту утилиту, крайне трудоемко. В этом случае SAP рекомендует заново создать систему управления полномочиями.

Альтернативно можно использовать ►SAP values (см. рис. 8.8) на шаге 6 для преобразования существующих профилей в роли. Преимущество этого подхода заключается в том, что можно продолжать использовать существующие проверенные профили. Однако обратите внимание: здесь нельзя применять значения, используемые SAP по умолчанию, меню могут создаваться только тогда, когда профили содержат соответствующие полномочия для кода транзакции.

Если исходная версия использует Profile Generator, то можно использовать ►SAP values (с шагами от 2А до 2С) для сравнения существующих данных полномочий с новыми данными.

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

Достаточно часто встречаются ситуации, когда пользователи не имеют всех требуемых полномочий особенно во время начальных фаз реализации R/3. В этом случае после прекращения транзакции в связи с отсутствием полномочий затронутый пользователь или системный администратор может выбрать ►Authorization Data для вывода списка отсутствующих полномочий. Транзакция показывает, какое требуется полномочие для выполнения выбранного действия.

Кроме всего прочего, можно использовать ►SAP System Trace (см. главу 15) для записи всех проверок полномочий. В этом случае записываются все проверенные проекты полномочий, включая проверенные значения. Можно использовать меню Edit filters для ограничения трассировки отдельных пользователей, процессов или транзакций. Администраторы могут затем еще больше ограничить выбор, например пользователем, во время анализа трассировки. Система SAP System Trace удобна для определения всех необходимых полномочий для действия на основе выполненной проверки полномочий.

Управляющий пользователями администратор несет ответственность за обслуживание данных в главной записи пользователя. Пользователи разных прикладных областей обычно не имеют полномочий на самостоятельное обслуживание этих данных за исключением адреса компании. В то же время все пользователи могут определять в главной записи специальные настройки, помогающие им работать с системой R/3. Например, эти настройки задают начальное меню, язык входа в систему, назначенный по умолчанию принтер и формат данных для ввода стандартных значений в отдельные поля. Для ввода таких данных нужно выбрать команду ►Own Data. Система выведет окно Maintenance, где можно задать почтовый адрес компании, фиксированные значения и параметры. Эти вкладки соответствуют аналогичным вкладкам при обслуживании пользователей (см. раздел 8.2.1).

На рис. 8.18 показан экран обслуживания задаваемых по умолчанию значений пользователя. Этот экран открывается в отдельном сеансе, поэтому не требуется прерывать выполняемую операцию, чтобы обслужить задаваемые по умолчанию значения пользователя. Исходный сеанс остается неизменным.

Рис. 8.18. Обслуживание задаваемых по умолчанию значений пользователя

Обслуживание задаваемых по умолчанию пользовательских параметров позволяет назначать индивидуальные значения для полей ввода. Это означает, что не придется вводить значение в поле явным образом. Поля сами заполняются определяемыми значениями. Например, можно вывести на экран техническую информацию по коду компании или месту возникновения затрат. Чтобы вывести на экране техническую информацию для поля ввода, выделите это поле и активируйте кнопку технической информации в контекстной справочной системе F1. Поле Parameter ID содержит имя параметра, которое требуется для его определения. Например, BUK означает код компании. Это сокращение можно использовать в своих персональных значениях.

Во многих случаях, когда информация просто выводится (но не изменяется), пользователи могут работать анонимно в Интернете. Однако в среде системы SAP даже при работе в Интернете доступ обычно требует индивидуального имени пользователя и соответствующего пароля. Это требуется, когда через Интернет должны выполняться такие транзакции, как размещение заказа. В зависимости от Internet Application Component (IAC, см. главу 1) может быть достаточно сконфигурировать обычный диалог пользователя для активации в Интернете, но может понадобиться создать и поддерживать дополнительную учетную запись пользователя Интернета. Обратитесь к описанию конкретного IAC, чтобы выяснить, какой вариант применим.

Подготовка обычного диалогового пользователя для доступа через Интернет не отличается от обслуживания пользователей, описанного выше (см. раздел 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 в структуре предприятия:

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

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

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

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

► Конфигурирование административного пользователя в центральной системе

► Конфигурирование сценария ALE:

- Именование логических систем

- Присвоение логических систем клиентам

- Создание пользователей коммуникации (которые используются в интерфейсах RFC) во всех вовлеченных клиентах

- Создание интерфейсов RFC

- Создание новых представлений модели распределения ALE

- Поддержание и генерация профилей Partner между всеми клиентами, участвующими в CUA

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

► Активация CUA

► Конфигурирование параметров распределения для полей

► Распространение адреса компании

► Синхронизация пользователей

Более подробно эти шаги описаны в следующих разделах.

Свойства и управление интегрированной системой ALE описаны в главе 13. Поэтому здесь описаны только настройки специфические для Центрального управления пользователей (CUA).

Сначала нужно сконфигурировать логические системы (см. главу 13), для всех клиентов, работающих с CUA. Затем используется ►Client Administration для присвоения логических систем клиентам. Одно соединение RFC должно быть задано для пересылки данных из центральной системы в каждую дочернюю систему и в противоположном направлении — необходимо иметь отдельные соединения RFC для каждого направления. Между дочерними системами не требуется никаких соединений. Клиент в месте расположения CUA также должен быть интегрирован как дочерняя система в центральное управление. Определяется новое представление модели для модели распространения ALE, чтобы указать, какие данные будут обмениваться между логическими системами. Для CUE это будут предопределенные бизнес-объекты USER и UserCompany с методом распространения Clone.

Затем генерируется партнерское соглашение и распространяется на все логические системы, что завершает конфигурирование ALE для центрального управления пользователями.

Чтобы активировать CUA, необходимо только присвоить CUA представление модели ALE. Для этого нужно ввести имя представления модели в ►Central Role Administration и нажать Create. На следующем экране следует ввести все дочерние системы для центрального управления и сохранить их. Теперь можно распространить модель с помощью меню с путем доступа Distribution Model • Distribute Distribution Model для распространения модели на дочерние системы. Центральное управление пользователями активно.

Основной аспект конфигурирования CUA включает определение места обслуживания атрибутов пользователей в различных системах, т.е. в центральной или в дочерней системе. Для определения, как будет обслуживаться каждый атрибут пользователя (см. рис. 8.22), можно использовать ►Distribution Parameters в Customizing.

Рис. 8.22. Определение параметров распространения

Администраторы могут использовать следующие параметры:

Таблица 8.6. Параметры для выбора полей

Чтобы удалить отдельные дочерние системы из центрального управления пользователями (CUA), нужно выполнить отчет RSDELCUA на соответствующих дочерних системах. Чтобы полностью прекратить деятельность всего CUA, следует выполнить отчет RSDELCUA на центральных системах. Это отменяет назначение модели распространения в CUA и деактивирует CUA.

Когда CUA полностью удалено, необходимо также выполнить следующие задачи по очистке:

► Удалить партнерское соглашение.

► Удалить модель распространения ALE.

► Удалить соединения RFC.

► Заблокировать пользователя коммуникации.

Если удаляется только одна дочерняя система, то нужно соответственно ограничить партнерское соглашение, модель ALE и интерфейсы RFC.

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

► New users

Эти пользователи существуют только в дочерней системе, но еще не в CUA. Во время переноса все параметры интегрируются в CUA.

► Identical users

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

► Different users

Одно и то же имя пользователя содержится как в CUA, так и в дочерней системе, но с другими реальными именами (реальное имя является комбинацией имени и фамилии). Необходимо решить, какой пользователь будет обслуживаться в дальнейшем. Может быть, желательно создать нового пользователя в CUA.

► Central users

Эти пользователи уже зарегистрированы в CUA идентичным образом и управляются централизованно.

Затем можно интегрировать пользователей в CUA по отдельности или всех сразу. В ходе этого процесса данные для всех пользователей за исключением New users всегда берутся и распространяются из центральной системы. Если два различных пользователя используются в действительности для Different users, то необходимо определить их снова в центральной системе и удалить идентично именованных пользователей в дочерней системе.

Для обслуживания пользователей продолжают использовать ►User maintenance (см. раздел 8.2.1), далее когда CUA активно. Однако пользователей нельзя больше создавать в дочерних системах, и готовы для ввода только те поля, которые могут обслуживаться локально согласно определению параметров распространения (см. раздел 8.7.2). В центральной системе появляется новая вкладка Systems в транзакции ►User maintenance. Эта вкладка используется для ввода систем, в которые вы хотите распространить пользователей. Данные пользователя можно определить только один раз, и они будут затем идентичны во всех дочерних системах. Каждой дочерней системе можно присвоить различные роли и профили.

Чем больше систем SAP интегрируется в неоднородную системную инфраструктуру, тем в большей степени возрастает потребность в управлении пользователями. Большая часть данных пользователей требуется как в системах SAP, так и в других системах, и поэтому хранятся с избыточностью. Обслуживание этих избыточных данных требует много времени и не всегда синхронизировано.

LDAP

Службы каталогов делают возможным для различных приложений в структуре ИТ обращение к общим данным, которые управляются централизованно. Считайте службу каталогов «адресной книгой ИТ». Если служба каталогов поддерживает Стандартный легковесный протокол доступа к каталогам (LDAP), то можно использовать LDAP Connector для обмена данными со службой каталогов в Basis Release 6.10 и более поздних версиях. Следовательно, центральные данные пользователя должны сохраняться только один раз в центральной службе каталогов и могут синхронизироваться прямо с системой SAP или Центральным управлением пользователями с помощью функций синхронизации LDAP. Затем данные можно распределить на дочерние системы в CUA (включая данные более ранней версии Basis).

► Обслуживание данных коммуникации

При обслуживании в ►User maintenance данных коммуникации — особенно номеров факсов — необходимо проверить, чтобы эти данные соответствовали соглашениям SAP. Необходимо вводить значения без каких-либо ведущих пробелов или специальных символов, с разделителем между номером компании и расширением и без кода страны (это можно выбрать в Other Communication), в противном случае SAPConnect не сможет проверить данные (см. главу 13).

► Высокие требования к памяти в связи с большими меню пользователей

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

► Клиент для Центрального управления пользователями

Концепция полномочий для CUA упрощается, когда CUA задается на отдельном клиенте или даже на отдельной системе (например, отдельная система мониторинга).

ALE Customizing: SAP Implementation Guide (SPRO) • R/3 Basis Customizing • Application Link Enabling (SALE)

Authorization data: SAP Menu • System • Utilities • Disp.Authorization Check (SU53)

Central Role Administration: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Select Model Views for Central Administration (SCUA)

Check indicators: SAP Implementation Guide (SPRO) • Basis • System Administration • Users and Authorizations • Maintain Authorizations and Profiles with the Profile Generator • Edit SAP Check Indicators and Field Values • Change Check Indicators (SU24)

Client administration: SAP Menu • Tools • Administration • System Administration • Administration • Client Administration • Client Maintenance (SCC4)

Company address: SAP Menu • Tools • Administration • User Maintenance • Users • Environment • Maintain Company Address (SUCOMP)

Distribution Model: ALE Customizing (SALE) • Model Business Processes • Maintain Distribution Model and Distribute Views (BD64)

Distribution Parameters: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Configure Distribution Parameters for Fields (SCUM)

Information system: SAP Menu • Tools • Administration • User Maintenance • Information System (SU01 • Info • Info System)

Internet users: SAP Menu • Tools • Administration • User Maintenance • Internet Users (SU05)

License Administration Workbench (LAW): He доступно в стандартном меню SAP (LICENSE_ADMIN)

Mass changes: SAP Menu • Tools • Administration • User Maintenance • Users • Environment • Mass Change (SU10)

Object classes: SAP Menu • Tools • ABAP/4 Workbench • Development • Other Tools • Authorization Objects • Objects (SU21)

Own data: SAP Menu • System • User Profile • Own Data (SU3)

Partner agreements: ALE Customizing (SALE) • Model Business Processes • Maintain Distribution Model and Distribute Views (BD64) • Generate Partner Agreement (BD82)

Role maintenance: SAP Menu • Tools • Administration • User Maintenance • Roles (PFGC)

SAP Implementation Guide: SAP Menu • Tools • AcceleratedSAP • Customizing • Edit Project (SPRO)

SAP Proposals: SAP Implementation Guide (SPRO) • System Administration • Users and Authorizations • Maintain Authorizations and Profiles with the Profile Generator • Copy SAP Check Indicators and Field Values (SU25)

SAP System Trace: SAP Menu • Tools • Administration • Monitor • Traces • SAP System Trace (ST01)

Security Audit Analysis: SAP Menu • Tools • Administration • Monitor • Security Audit Log • Analysis (SM20)

Security Audit Configuration: SAP Menu • Tools • Administration • Monitor • Security Audit Log • Configuration (SM19)

System Measurement: SAP Menu • Tools • Administration • Administration • System Measurement (USMM)

User group: SAP Menu • Tools • Administration • User Maintenance • Maintain User Groups (SUGR)

User maintenance: SAP Menu • Tools • Administration • User Maintenance • Users (SU01)

User transfer: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Transfer Users from New Systems (SCUG)

Быстрые ссылки

► SAP Service Marketplace, псевдоним licenseauditing

Документ: "Introduction to System Measurement"

► SAP Service Marketplace, псевдоним security

► SAP Service Marketplace, псевдоним securityguide

Документ: "SAP Security Guidelines"

► SAP Service Marketplace, псевдоним sso

Указания SAP Service Marketplace

Таблица 8.7. Указания SAP Notes для администрирования пользователей

1. Какое утверждение правильно?

Пользователь с типом «System»:

a. может регистрироваться в системе без пароля через интерфейс RFC

b. имеет пароль, но настройки для периода действия не применимы

c. не может регистрироваться в системе в диалоговом режиме

2. Какое утверждение правильно?

a. Пользователю может быть присвоена только одна роль.

b. Пользователю может быть присвоено несколько ролей.

3. Какая информация переносится при переносе ролей?

a. Профили полномочий для роли

b. Определение пользователей

c. Назначение ролей пользователям

4. Полномочия роли расширены. С какого момента пользователь, которому была назначена эта роль и который уже зарегистрировался в системе, сможет начать использовать измененные полномочия?

a. Пользователь может начать использовать измененные полномочия немедленно.

b. Пользователь может использовать измененные полномочия после сравнения пользователей.

c. Пользователь должен снова зарегистрироваться в системе и может затем начать использовать измененные полномочия.

d. Сначала должно быть выполнено сравнение пользователей. Затем пользователь должен снова зарегистрироваться в системе, после чего может начать использовать измененные полномочия.