Уязвимость в SAP AS Java: ошибка RECON

Сегодняшний пост будет про безопасность, а именно про уязвимость RECON.

Если вы внимательно следите за медиа-ресурсами, то про новую "страшную" дыру в безопасности SAP под названием RECON, наверняка, слышали. Но проблема в том, что часть журналистов, как обычно, "слышала звон и спала в одном ботинке...".

Давайте разбираться вместе.

1. Дыра есть - это факт. Ошибка RECON является серьёзной. Это одна из тех редких уязвимостей, которые получили максимум 10 из 10 оценок по шкале серьезности уязвимостей CVSSv3.
2. Уязвимость проста в использовании и находится в компоненте, которая по умолчанию включена в каждую SAP систему, в которой работает Java стек SAP NetWeaver. А именно, в компоненте мастера настройки LM (LM Configuration Wizard) сервера приложений SAP NetWeaver.
3. Подвержены "дыре" AS Java системы с версии 7.3 до самых новых. Про более древние ничего не говорят (они уже давно EOL), но возможно и с ними есть проблемы. Для тех, кто не помнит, SAP системы в основном представлены 3 основными типами платформ: AS ABAP (ECC/BW), AS Java и HANA. Есть ещё экзотика, типа BusinesObjects или Hybris, но их удельный вес настолько мал, что про них можно забыть. Таким образом, уязвимость охватывает системы SAP S/4HANA, SAP SCM, SAP CRM, SAP Enterprise Portal и SAP Solution Manager. Во всех них встречается AS Java часть.
4. Используя ошибку, можно получить доступ к системе, просто создав учетную запись пользователя SAP с максимальными привилегиями для приложений SAP, представленных в Интернете. 

Поэтому, на наш взгляд, стоит обратить внимание на данную проблему. Если AS Java у вас в ландшафтах отсутствует, то тогда можно расслабиться. А если же, ваша AS Java часть системы смотрит в сеть Интернет (и доступна из него!), то сразу стоит остановить службу LM (SAP note 2939665). А после этого стоит остановить Java системы и пропатчить их (SAP note 2934135).

Описание проблемы в SAP note 2947895 - RECON - SAP Vulnerability.

Закрытие дыры и патчи описаны в SAP note 2939665 - Disable/Enable LM Configuration Wizard | Critical API's in LM Configuration Wizard и SAP note 2934135 - [CVE-2020-6287] Multiple Vulnerabilities in SAP NetWeaver AS JAVA (LM Configuration Wizard).

После этого уже никакой RECON вам будет не страшен!


Авторы: Бондарев Дмитрий, Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - II

В первой части статьи я описал как в SAP системе рабочий процесс, используя двух этапный механизм, определяет пароль владельца ABAP схемы (SAP<SCHEMA-ID>) и подключается с помощью этого пользователя к базе данных Oracle.

Такой механизм использовался до версии Oracle 11g. Но с выходом базы данных Oracle 11g оказалось, что это последняя версия СУБД от Oracle, которая поддерживает OPS$-механизм для удалённого соединения с ней. В связи с этим компания SAP также внесла поправки в работу своих приложений. И начиная с SAP kernel Release 7.20 (примерно с 100 пакета поддержки) представила новый метод для хранения пароля владельца базы данных и соединения с ней. В SAP kernel Release 7.20 зашифрованный пароль для пользователя базы данных может хранится не в базе данных, а на уровне файловой системы. Такой способ называется Secure Storage in File System (SSFS). 

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

Рис. 1. Пример сообщений из журнала рабочего процесса при коннекте с базой данных новым способом.

Для того, чтобы рабочие процессы и внешние утилиты SAP (R3load, R3trans) использовали новый метод, необходимо в DEFAULT профиль SAP инстанции добавить ряд параметров (рис. 2). Про профили и параметры SAP системы я уже рассказывал в своё время в статьях (1, 2).

Одновременно должны быть установлены переменные окружения пользователя операционной системы <sid>adm (рис. 3).

Рис. 2. Параметры SAP инстанции, связанные с SSFS способом коннекта. 

Рис. 3. Переменные окружения пользователя ОС для SAP системы, связанные с SSFS способом коннекта. 

На уровне операционной системы в директории /usr/sap/<SID>/SYS/global/security созданы специальные директории и файлы со строгими правами на доступ (рис. 4). В файле SSFS_<SID>.DAT хранится как раз информация необходимая для соединения с базой данных, включая зашифрованный пароль владельца схемы.

Рис. 4. Список директорий и файлов, хранящих информацию для соединения с базой данных.

Для просмотра содержимого хранилища в SAP Kernel есть утилита rsecssfx. Набрав одноимённую команду, можно получить список всех записей (опция list) или содержимое отдельной записи (опция get). Содержимое записи с паролем зашифровано и не будет показано в целях безопасности (рис. 5).

Рис. 5. Пример использования команды rsecssfx.

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

Для обратной совместимости, вплоть до версий SAP Kernel 7.38 и базы данных Oracle 11.2, поддерживается одновременно и старый, двух этапный, метод. Хотя SAP уже в этих версиях рекомендует переходить на новый метод хранения пароля на уровне файловой системы. Ведь сделать это можно даже в системах на базе SAP NetWeaver 7.0, так как эти программные продукты поддерживают SAP Kernel 7.20. Переход на это ядро я описывал в одноимённом посте.  

И стоит иметь в виду, что если в Oracle 11g установить параметры профиля REMOTE_OS_AUTHENT=TRUE, то при старте инстанции в терминале или в системном журнале можно увидеть сообщения об ошибке вида:

• ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance,
• ORA-32006: REMOTE_OS_AUTHENT initialization parameter has been deprecated.

Эти сообщения можно проигнорировать, так как не смотря на них старый механизм всё ещё будет работать. Необходим он, если в UNIX системах утилиты SAP BR*Tools и рабочие процессы SAP всё ещё используют OPS$-механизм, который и требует установки параметра REMOTE_OS_AUTHENT=TRUE. 

Ну а начиная с SAP Kernel 7.40 поддерживается только SSFS механизм хранения пароля пользователя SAP<SCHEMA-ID>.

Для смены пароля владельца схемы необходимо пользоваться SAP утилитами BR*Tools (версия не ниже 7.20 пакет поддержки 28). Команда вида:

> brconnect -u / -f chpass 

изменит пароль и в системных таблицах Oracle, и в защищенном SSFS хранилище.

Есть правда небольшой нюанс на переходных системах, там где возможна работа обоих методов. Такая команда при выполнении проверит есть ли таблица OPS$<USER>.SAPUSER. И если она ещё существует в базе данных, то пароль пользователя изменится в ней, а новое хранилище SSFS будет проигнорировано. Поэтому при переходе на новый метод необходимо эту таблицу удалить.

Либо в команде BRCONNECT можно использовать дополнительную опцию "-s|-secstore", где можно указать поменять пароль для коннекта рабочими процессами ABAP инстанции. Например, командой вида:

> brconnect -u / -c -f chpass -o SAPSR3 -p <new_password> -s abap 

При использовании этой опции пароль будет изменён именно в SSFS хранилище, а наличие таблицы OPS$<USER>.SAPUSER будет проигнорировано.


OPS$-механизм, который я описывал в прошлой части может быть использован не только для удалённого соединения, но и для локального. И даже в версиях Oracle 12c и выше локальное соединение с использованием OPS$-механизма всё еще поддерживается. Его могут использовать, например, утилиты BR*Tools или администратор при выполнении операций с базой данных (в утилите SQLPlus). 

Но если вы хотите от него отказаться окончательно, то можно его заменить на специального пользователя BRT$ADM, с помощью которого утилиты из набора BR*Tools и будут открывать соединение и  выполнять задачи по администрированию базы данных. После создания такого пользователя OPS$-пользователей из базы данных можно окончательно удалить. Подробности про этот переход и про работу BR*Tools, включая вопросы смены пароля владельца схемы в SSFS, можно найти в SAP note # 1764043 - Support for secure storage in BR*Tools.

Также на данную тему советую изучить SAP notes:

• 1611877 - Support for ABAP SSFS during database connect,
• 1622837 - Secure connection of AS ABAP to Oracle via SSFS,
• 1639578 - SSFS as password store for primary database connect.

В них детально описано как перевести систему на новый метод хранения пароля и соединения с базой данных. 

Стоит ещё отметить, что SSFS механизм хранения пароля владельца схемы используется не только при разворачивании системы на Oracle, но и при работе с Sybase ASE, SAP HANA и SAP MaxDB (см. SAP note 1639578).

А если хотите погрузиться в администрирование базы данных Oracle на практике, то добро пожаловать в мой авторский курс по SAP Basis. 

Автор: Шиболов Вячеслав Анатольевич

Как рабочие процессы SAP соединяются с базой данных Oracle - I

Как вы знаете, основными "рабочими лошадками" SAP инстанции являются рабочие процессы (SAP Work Processes или WP), которыми управляет диспетчер. В случае с AS ABAP это ABAP диспетчер. При использовании с SAP системой СУБД Oracle рабочие процессы SAP инстанции для корректной работы должны соединиться с базой данных. После открытия соединения каждому рабочему процессу SAP будет соответствовать один процесс на уровне СУБД, так называемый shadow-процесс.
При этом на сервере приложений SAP на уровне операционной системы рабочие процессы запускаются и работают под пользователем <sid>adm (в UNIX) или SAPService<SID> (в случае Windows). В свою очередь все таблицы и индексы в базе данных, которые используются текущей SAP системой, принадлежат одному пользователю базы данных. Этот пользователь называется владельцем схемы (которая объединяет все таблицы и индексы) и имеет имя SAP<SCHEMA-ID>. Стандартно в SAP инсталляциях имя владельца схемы - SAPSR3,  но иногда может быть SAP<SID>, а в старых системах пользователь носил имя - SAPR3 (до версии SAP Basis 4.6D). Владельца схемы в текущей инсталляции можно определить, если на начальном экране в системе выбрать пункт меню «Система -> Статус…» (рис. 1 и 2).

Рис. 1. Просмотр владельца схемы в базе данных.

Рис. 2. Пример владельца схемы в базе данных.

Для получения полного доступа к таблицам базы данных рабочие процессы SAP инстанции должны соединяться именно под этим пользователем. Данный пользователь на уровне Oracle (как и любой другой) защищён паролем. Но рабочие процессы SAP не знают этот пароль, так как это пользователь другого уровня, не уровня сервера приложений. Поэтому в своих решениях для рабочих процессов SAP использует механизм, который позволяет узнать пароль владельца схемы в процессе создания соединения. Об этом механизме я и хотел сегодня рассказать.

Данный механизм основан на сохранении пароля пользователя SAP<SCHEMA-ID> не только в системной таблице Oracle (в которой хранятся пароли всех пользователей на уровне базы данных), а еще и в специальной таблице. Специальная таблица имеет имя SAPUSER, и принадлежит схеме другого пользователя базы данных - OPS$<SID>ADM (в UNIX) или OPS$<DOMAIN>\<SID>ADM (в Windows). В Windows, к этой таблице также имеет доступ пользователь OPS$<DOMAIN>\SAPService<SID>, от которого и работают рабочие процессы SAP, как я написал выше.

Небольшое отступление про OPS$-пользователей (OPS$<USERS>) или OPS$-механизм базы данных Oracle. При разворачивании SAP системы, на этапе установки базы данных Oracle, программа установки спрашивает пароли для создаваемых пользователей: SYS, SYSTEM и SAP<SCHEMA-ID>. Это отдельные пользователи базы данных, которые создаются на уровне Oracle. Но помимо этих пользователей, программа установки создаёт отдельную группу пользователей, которые используют механизм Oracle, называемый "OS authentication". Эти пользователи имеют префикс "OPS$" и содержат имя пользователя операционной системы. Для UNIX систем это OPS$<SID>ADM, OPS$ORA<SID> и, в последних релизах Oracle, OPS$ORACLE. А для Windows соответственно OPS$<DOMAIN>\SAPService<SID> и OPS$<DOMAIN>\<SID>ADM. Заметьте, что в случае с Windows обязательное условие это добавление домена в имя OPS$-пользователя. Если сервер не в домене, то используется hostname сервера (рис. 3). 

Рис. 3. Пример списка пользователей базы данных Oracle, развернутой в ОС Linux.

OPS$-механизм разрешает пользователям операционной системы (для которых создан соответствующий OPS$<USER>) соединяться с базой данных без ввода пароля. То есть аутентификация пользователя переносится на уровень операционной системы, где и проводится проверка пароля.

Для активации OPS$-механизма необходима установка двух параметров инстанции Oracle:

• REMOTE_OS_AUTHENT=TRUE – разрешает удалённое соединение (OS authentication) для тех пользователей операционной системы UNIX, у которых в базе данных есть соответствующий OPS$-пользователь. То есть соединение возможно с любого компьютера в сети, с которого возможно открыть соединение с базой данных,
• OS_AUTHENT_PREFIX=OPS$ - начальный префикс для таких пользователей в базе данных. Для SAP систем значение по умолчанию "OPS$".

Теперь вернёмся к вопросам соединения рабочих процессов SAP инстанции к базе данных Oracle.

SAP инстанция может работать как на том же сервере, где работает сервер базы данных, так и на отдельном сервере. Поэтому при старте рабочего процесса он не знает: база данных доступна локально или удаленно. Следовательно в Oracle должен быть разрешён удаленный логин (параметр REMOTE_OS_AUTHENT). Стоит сразу обозначить, что в целях обеспечения безопасности права OPS$-пользователя ограничены. Он может лишь присоединиться к базе данных и прочитать запись только в таблице SAPUSER, так как эта таблица принадлежит ему. Читать, добавлять или изменять данные в других SAP таблицах (в основной схеме базы данных) ему запрещено.

Рис. 4. Схема соединения рабочих процессов SAP к базе данных Oracle.

Когда рабочий процесс SAP запускается и пытается соединиться с базой данных Oracle, он выполняет следующие шаги (рис. 4):

1. Рабочий процесс открывает коннект к базе данных как соответствующий OPS$-пользователь с аутентификацией на уровне операционной системы.
2. С помощью SQL-запроса SELECT к таблице SAPUSER рабочий процесс читает пароль пользователя SAP<SCHEMA-ID>.
3. Текущее соединение с базой данных Oracle закрывается.
4. Рабочий процесс открывает новое соединение с использованием уже пользователя SAP<SCHEMA-ID> и пароля, который он получил на предыдущем этапе из таблицы SAPUSER.

Если один из вышеуказанных шагов по какой-то причине не выполнен, то соединение не устанавливается и рабочий процесс на уровне операционной системы сервера останавливается с ошибкой.

А вот как этот процесс коннекта к базе данных выглядит на уровне сообщений журнала рабочего процесса SAP (рис. 5).

Рис. 5. Пример журнала рабочего процесса SAP.

Также стоить добавить, что такой двух этапный механизм коннекта к базе данных используют не только рабочие процессы, но и некоторые SAP утилиты. Например, R3trans или R3load. 

Для смены пароля владельца схемы (пользователь SAP<SCHEMA-ID>) нельзя использовать методы базы данных Oracle (например, команду password) (рис. 6). Так как в этом случае пароль изменится только в системных таблицах Oracle, а в таблице OPS$<USER>.SAPUSER останется старым и рабочие процессы не смогут соединиться с базой данных (рис. 7).

Рис. 6. Пример смены пароля владельца схемы методами Oracle.

Рис. 7. Пример ошибки при попытке рабочего процесса открыть соединение с базой данных.

Чтобы смена пароля не привела к ошибкам в работе системы, для этой операции необходимо использовать утилиты BR*Tools (в старых системах - SAPDBA). Про эти утилиты я писал в этой статье. Утилита от SAP изменит пароль владельца схемы не только в системных таблицах Oracle, но и таблице OPS$<USER>.SAPUSER. А это обеспечит корректную работу описанного выше механизма соединения рабочих процессов (рис. 8 и 9).

Рис. 8. Корректный способ смены пароля владельца схемы - 1.

Рис. 9. Корректный способ смены пароля владельца схемы - 2.

А если обратить внимание, что на нижнем уровне в brtools запускается утилита BRCONNECT, то пароль можно сменить, запустив эту программу напрямую одной командой вида:

> brconnect -u / -f chpass 

Хотя пароль владельца схемы в таблице SAPUSER и хранится в зашифрованном виде, рекомендую дополнительно ознакомиться с рекомендациями по организации более безопасной инфраструктуры, прочитав SAP note #157499 - OPS$ connect and security aspects. Там описано, например, как ограничить список IP-адресов машин, с которых возможен удалённый коннект к серверу базы данных, используя OPS$-механизм. 

А начиная с Oracle 11g была прекращена поддержка со стороны Oracle OPS$-механизма для удалённого подключения и, SAP (начиная с SAP Kernel 7.20) стал использовать новый механизм для организации соединения рабочих процессов SAP и базы данных. Но об этом я расскажу уже во второй части статьи. 

Автор: Шиболов Вячеслав Анатольевич

Создание ярлыка для соединения с SAP системой без пароля

В последнем посте "Саповские секретики - V", в качестве одного из секретов, я рассказывал, как создать ярлык для соединения к SAP системе. При создании ярлыка можно было указать, помимо целевой системы, манданта и языка, транзакцию, которую необходимо запускать сразу после входа в систему. Так же можно было указать имя пользователя, из под которого будет создаваться соединение (рис. 1). Пароль же вводится при открытии соединения через ярлык. И это безопасно и правильно. В данном случае пароль хранится у вас в голове и в SAP системе.

Рис. 1. Создание ярлыка для соединения.

Но, если очень хочется, то можно указать пароль в SAP систему прямо во вновь созданном ярлыке. Для этого необходимо внести изменения в реестр Windows, открыв его командой regedit и добавив по пути HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security параметр "EnablePassword"="1" (рис. 2).

Рис. 2. Внесение изменений в реестр Windows.

Либо можно создать файл-корректировку для реестра (расширение .reg) с содержимым вида:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security]
"EnablePassword"="1"

Выполнить созданный файл, внеся изменения в реестр. И перезапустить программу SAP Logon.

После этого при создании ярлыка для соединения, поле пароля будет открыто на изменение и можно будет внести пароль пользователя, из под которого будет выполняться соединение в будущем (рис. 3).

Рис. 3. Сохранение пароля в ярлыке для соединения.

Вносим пароль пользователя и сохраняем ярлык. После этого вход в систему будет осуществляться без ввода пары пользователь/пароль.

Хотя пароль хранится в ярлыке не в явном виде, всё равно SAP не рекомендуется сохранять его там (рис. 4).

Рис. 4. Пример содержимого ярлыка для соединения с SAP системой.

Функция описана в SAP note # 146173 - SAPShortcut: Saving password in SAPShortcut - not recommended.

В SAP note указано, что, начиная с SAP GUI 7.40 (SP 01) функция была удалена. И экран создания ярлыка в версии SAP GUI 7.50 выглядит без поля пароля вообще (рис. 5).

Рис. 5. Диалоговое окно для создания ярлыка в SAP GUI 7.50.

Но, ярлык, созданный в SAP GUI 7.30 с сохранённым паролем, работает и в SAP GUI 7.50. :)

Но опять же повторюсь, SAP не рекомендует использовать эту функцию.


Автор: Шиболов Вячеслав Анатольевич

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

При начальной конфигурации транспортной системы в AS ABAP любой SAP системы в 000 манданте автоматически создаётся системный пользователь TMSADM.

Данный пользователь имеет тип "Communication" или "System" (рис. 1). Но ни в коем случае не "Диалоговый", то есть вход в систему через SAP GUI ему должен быть запрещен.

Рис. 1. Тип учетной записи TMSADM.

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

Рис. 2. RFC-соединения, использующиеся в работе транспортной системы.

RFC-соединения используются для обмена информацией между системами транспортного ландшафта (рис. 3).

Рис. 3. Схема настройки RFC для работы транспортной системы.

Как видно из схемы и рис. 2, используется 2 вида RFC-соединений:

• TMSADM@<SID>.<DOMAIN_NAME> - для аутентификации используется пользователь TMSADM, используется для некритичных операций, прежде всего на чтение информации;
• TMSSUP@<SID>.<DOMAIN_NAME> - используется для более критичных операций, прежде всего операций записи, для аутентификации требует пару пользователь/пароль.

Эти два вида RFC-соединений создаются в каждой системе, которая подключена к транспортному домену. И пользователь TMSADM есть в каждой, но только в 000 манданте.

Так как пользователь TMSADM генерируется автоматически, то для него хранится стандартный пароль, который знают все системы транспортного ландшафта. В разных версиях SAP систем использовались два вида паролей:

• PASSWORD;
• $1Pawd2&.

Начиная с версии системы SAP NetWeaver 7.40, при настройке транспортной системы можно задать свой пароль. Или выбрать один из стандартных вариантов паролей (рис. 4).

Рис. 4. Установка пароля для пользователя TMSADM.

Установка своего пароля удовлетворяет требованиям безопасности, но старые системы в одном ландшафте с такой системой работать не смогут. Хотя ситуация работы систем разных версий в одном ландшафте очень редка, всё равно выбор оставили.

Проверить пароль пользователя TMSADM, не трогая учетную запись, можно через отчёт RSUSR003. Данный отчет проверяет пароли системных пользователей во всех мандантах системы на предмет их безопасности. То есть, в программе есть список хэшей стандартных паролей, которые он сверяет с реальными в системе. Например, для пользователей SAP* и DDIC, про которых я писал в этом посте.

Результатом работы отчета будет список системных пользователей и вердикт по их паролям (рис. 5).

Рис. 5. Проверка паролей системных пользователей.

Если отчёт в системе не отображает информацию по пользователю TMSADM, то необходимо заглянуть в SAP note # 1552894 - RSUSR003: Checking the standard password for user TMSADM. Установив исправления из ноты или соответствующий пакет поддержки для вашей версии системы, получите новую версию отчёта, которая проверяет пароль для пользователя TMSADM. Как работать с SAP нотами я описывал в цикле статей - часть 1, часть 2, часть 3.

Просто так, войдя в транзакцию SU01, изменить пароль для TMSADM нельзя. Как правильно изменить стандартный пароль для пользователя TMSADM описано в SAP note # 1414256 - Changing TMSADM password is too complex.

Дополнительно на данную тему можно найти информацию в курсе SAP "ADM325 - SAP Software Logistics for ABAP" и SAP note # 761637 - Logon restrictions prevent TMSADM logon.

  

Автор: Шиболов Вячеслав Анатольевич

Полные полномочия в SAP системе

Как я уже отмечал, в AS ABAP SAP системы для разграничения доступа к информации существует набор ролей и полномочий. Исходное правило: что не разрешено, то запрещено. Таким образом, чтобы пользователь смог выполнить действие в системе или получить доступ к информации, необходимо ему назначить роль, с которой ассоциируется профиль полномочий, в котором, в свою очередь, содержатся конкретные полномочия. Подробнее в посте "Как понять каких полномочий не хватает пользователю?".

Для получения полного набора полномочий в ABAP части SAP системы существует 2 готовых профиля полномочий:

• SAP_ALL - составной профиль полномочий, который содержит все полномочия в SAP системе;
• SAP_NEW - составной профиль полномочий, который используется при обновлении системы. Обеспечивает достаточный набор полномочий во время операций обновления, таких как установка пакетов поддержки или обновление версии SAP системы. 

Таким образом, для того чтобы создать в системе пользователя со всеми полномочиями, некого Super User, достаточно в транзакции SU01 добавить ему профили полномочий SAP_ALL и SAP_NEW (рис. 1).

Рис. 1. Добавление всех полномочий пользователю в SAP системе.

Начиная с релизов SAP_BASIS 700 и выше, профиль полномочий SAP_NEW был заменен на роль с таким же именем - SAP_NEW. Подробности в SAP note # 1711620 - Role SAP_NEW replaces profile SAP_NEW. 

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

SAP ноты на эту тему:

• 28186 - What does the profile SAP_NEW do?
• 82390 - Generating profile SAP_ALL.
• 85327 - Generating SAP_ALL does not work.

Так же можно посмотреть SAP курсы "ADM 940 - ABAP AS Authorization Concept" и "ADM 950 - Secure SAP System Management".

Автор: Шиболов Вячеслав Анатольевич

Oracle + Unix: полномочия на директории

Все кто сталкивался с операционными системами семейства Unix знают, что базовые полномочия на файлы/директории разделяются на 3 группы:

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

Полномочия можно получить на три типа операции: чтение (read), запись (write) и выполнение (execute) для файлов и переход в директорию для директорий. Кратко они записываются по первым буквам английских понятий: rwx. Последовательность именно такая. Сложив все 3 группы, имеем:

rwx rwx rwx

Например, права на чтение и запись для владельца и группы и запрет всего для остальных пользователей (рис. 1).

Рис. 1. Пример полномочий на файл в Unix.

Существует правило преобразования символьного обозначения в цифровое. Записываем разрешение в виде битов. Например, в приведенном примере это: 

rw- rw- --- = 110 110 000 = 6 6 0 = 660

То есть, выставляем биты-разрешения и получаем 3 числа в двоичном исчислении. Записываем их в десятичном и получаем результат. Кто-то считает по другому r = 4, w = 2, x = 1, а затем просто складывает. Хотя, по-моему по-админски, это считать в двоичном исчислении.

Затем эти числа можно использовать в команде chmod, которая присваивает файлу нужные полномочия. Например, 

 # chmod 660 ./log_g11m2.dbf 

Теперь, к делу. При использовании системы SAP в связке с базой данных Oracle в Unix-подобной операционной системе на ряд директорий и файлов, которые составляют в совокупности экземпляр (инстанцию) базы данных, необходимо установить и поддерживать правильный набор полномочий. Корректные полномочия обеспечивают базовый уровень безопасности системы и бесперебойную работу системы и утилит BR*Tools, про которые я рассказывал в постах: "Утилиты для администрирования ORACLE в SAP. Часть I" и "Утилиты для администрирования ORACLE в SAP. Часть II". Итак, памятка по полномочиям:

Рис. 2. Полномочия на директории Oracle в Unix.

Дополнительная информация:

- страница SAP Help Portal с полномочиями,

- небольшая инструкция о том, как их устанавливать.

Автор: Шиболов Вячеслав Анатольевич

Вопросы производительности при использовании больших меню в SAP

В комментариях к одному из прошлых постов ("Как понять каких полномочий не хватает пользователю?") Zeroes поднял вопрос производительности системы при использовании меню. Сегодня мне хотелось бы немного осветить эту тему.

В SAP системе действует правило "что не разрешено, то запрещено", поэтому для настройки полномочий в системе создаются роли. Обычно у роли настраивается меню, представляющее собой набор транзакций, оформленных в виде дерева папок, а полномочия генерируются в специальном профиле полномочий, который связан с ролью. Пользователю, в зависимости от бизнес-процессов, которые он выполняет в системе, присваиваются роли (с привязанными к ним профилями полномочий) (рис. 1).

Рис. 1. Пример присвоения пользователю роли и соответствующего профиля полномочий.

Итоговое меню пользователя на основном экране SAP GUI формируется как совокупность всех меню присвоенных ему ролей. При большом количестве пунктов в итоговом меню, то есть транзакций и папок, затрачиваются большие объемы памяти. Причем, память выделяется для каждой открытой сессии в рамках одного логона в систему. О процессе выделения памяти я писал в посте "Организация памяти в SAP AS ABAP - II".

Стоит так же упомянуть, что структура меню хранится в таблицах AGR_HIER и AGR_HIERT. Если посмотреть технические настройки данных таблиц (транзакция SE11 -> "Имя таблицы" -> "Технические параметры настройки"), то можно увидеть, что обе эти таблицы буферизируются по ключу на уровне сервера приложений SAP. Хочу напомнить, что про процесс буферизации таблиц я писал в посте "Буферизация таблиц на уровне сервера приложений SAP - I". Таким образом, для больших меню выделяются большие области в буфере таблиц, что так же негативно сказывается на общей производительности системы.

Оказывающим влияние на производительность системы считается меню с 2 000 пунктами и более. Для поиска пользователей с объемными меню в системе можно воспользоваться отчетом EASY_ACCESS_NUMBER_OF_NODES. На начальном экране есть возможность ограничить поиск только по диалоговым и действующим пользователям, у которых стоит в настройках показывать меню пользователя, а так же указать пограничное количество пунктов меню (рис. 2).

Рис. 2. Начальный экран отчета EASY_ACCESS_NUMBER_OF_NODES.

В предыдущих версиях системы был другой отчет - PROFGEN_CORR_REPORT_5. Начальный экран имеет похожий набор фильтров и параметров (рис. 3).

Рис. 3. Начальный экран отчета PROFGEN_CORR_REPORT_5.

Результатами работы программы будет список пользователей, отсортированных по количеству пунктов в меню (рис. 4).

Рис. 4. Список пользователей с большим количеством пунктов меню.

Как можно облегчить нагрузку на систему со стороны таких пользователей? SAP предлагает несколько решений.

1. Можно отключить пользовательские меню для всех в системе. Для этого достаточно в таблице SSM_CUST параметру ALL_USER_MENUS_OFF присвоить значение "YES". После этого у всех пользователей в системе будет только стандартное меню SAP, которое, к слову, содержит меньше 2 000 пунктов. Данную настройку я подробно описывал в этом посте. В этом случае есть возможность выделить и сохранить нужные транзакции в подразделе "Фавориты".
2. Можно принудительно выставить для всех пользователей в системе меню SAP, как меню по-умолчанию при открытии первоначального логина в систему или нового режима. В данном случае, у пользователя останется возможность открыть своё личное меню через соответствующую кнопку на панели основного экрана SAP GUI, но при открытии нового режима будет открываться именно стандартное меню SAP. Для этого необходимо в таблице SSM_CUST параметру FORCED_MENU присвоить значение "SAP".
3. Можно отключить пользовательское меню только для конкретных пользователей. Например, для тех, что были обнаружены отчетом EASY_ACCESS_NUMBER_OF_NODES (рис. 4). Для этого в таблице USERS_SSM необходимо добавить имя пользователя и выбрать тип предпочитаемого для него меню (SAP) (рис. 5).
   
   

   

   Рис. 5. Настройка типа меню для каждого пользователя индивидуально.

   
   
4. Если вы не можете отказаться от меню пользователя, то можно активировать систему сжатия и удаления избыточности в меню. Активация производится через набор параметров, выставляемых в таблице SSM_CUST. Кратко механизм можно описать так: система удаляет дубликаты транзакций из разных папок, затем удаляет пустые папки и, в конце, объединяет содержимое папок с одинаковыми именами. Подробности можно найти в SAP note # 357693 - Redundacy avoidance in Easy Access.
5. Так же можно для пользователей, которым необходимо большое количество полномочий, создать групповую роль. В меню групповой роли считываются все меню, присвоенных ей ролей. После создания меню групповой роли можно оптимизировать, например, нажав пункт "Свернуть меню" в транзакции PFCG (рис. 6).
   
   

   

   Рис. 6. Опция "Свернуть меню" при создании групповой роли.

Еще дополнительно по данной теме можно заглянуть в следующие SAP notes:

• # 380029 - FAQ: Customizing of SAP Easy Access,
• # 203617 - High memory consumption with SAP Easy Access menu.

Автор: Шиболов Вячеслав Анатольевич

Мульти-логин в SAP систему

Как вы знаете, для входа в ABAP часть SAP системы используется клиентское место SAP GUI. При входе в SAP систему пользователь указывает свой ID (учетную запись), который часто, в российской SAP практике, совпадает с фамилией пользователя. Хотя, изначально подразумевалось, что ID пользователя будет совпадать с его табельным номером. Поэтому даже в последних релизах SAP систем это поле не больше 12 знаков (рис. 1). Но на каких российских предприятиях сотрудники знают свой табельный номер наизусть? :)

Рис. 1. Начальное окно входа в SAP систему.

После успешного входа в систему, при попытке повторно войти в систему с тем же ID появится окно с предупреждением, в котором указывается с какого терминала (IP адрес + hostname) и в какое время уже был выполнен вход в систему (рис. 2).

Рис. 2. Попытка входа в систему дважды.

В таком случае, по-умолчанию, система предлагает выбрать из трёх вариантов:

• Выполнить этот логин, а прежние регистрации в систему отменить, то есть, принудительно выбросить из системы без сохранения данных.
• Выполнить логин в систему параллельно. 
• Отменить эту попытку входа.

При втором варианте произойдет, так называемый, мульти-логин в систему. Данные об этом SAP система тщательно сохраняет в таблице USR41_MLD (рис. 3).

Рис. 3. Пример записи в таблице USR41_MLD.

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

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

Информация о текущих регистрациях в систему хранится в таблице USR41 (рис. 4).

Рис. 4. Пример содержимого таблицы USR41.

Таким образом, когда пользователь входит в SAP систему, информация об этом записывается в таблицу USR41. При новой попытке входа, происходит считывание записей из этой таблицы и при обнаружении записи с таким ID, выдается вышеуказанное предупреждение (рис. 2).

Как вы, наверное, уже знаете, SAP системы лицензируются по количеству пользователей, работающих в продуктивной системе. Таким образом, мульти-логины, когда несколько пользователей одновременно работают в системе под одним ID, не только снижают безопасность системы и подвергают риску сохранение консистентности данных, но и нарушают лицензионное соглашение. Поэтому компания SAP SE отслеживает эти нарушения. При проведении лицензионного аудита (транзакция USMM) в отчёт, помимо всего прочего, попадает информация из таблицы USR41_MLD. На основании этого компания оставляет за собой право пожурить клиента за мульти-логины в систему.

Дабы не доводить до греха и повысить безопасность системы, можно отключить возможность мульти-логина в систему через установку параметра профиля SAP: login/disable_multi_gui_login = 1 (рис. 5).

Рис. 5. Описание параметра login/disable_multi_gui_login.

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

Рис. 6. Попытка входа в систему дважды после установки запрета на мульти-логин.

Одновременно с этим, в параметре login/multi_login_users можно указать пользователей, которым будет разрешён мульти-логин в SAP систему (рис. 7). ID пользователей следует перечислять через запятую без пробелов, заглавными буквами.

Рис. 7. Описание параметра login/multi_login_users.

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

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

Подробности про лицензионный аудит можно найти тут.


Автор: Шиболов Вячеслав Анатольевич

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

В клиентском месте SAP GUI на верхней панели слева есть две кнопки: "Меню пользователя", которое основано на ролях присвоенных пользователю и "Меню SAP", представляющее собой общее стандартное древовидное меню (рис. 1).

Рис. 1. Кнопки вызова меню SAP и меню пользователя.

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

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

Отдельные пункты меню пользователь SAP системы может добавлять в Избранное или Фавориты, которые отображаются в верхней части при выборе любого типа меню. Добавить транзакцию в избранный список можно двумя способами. Либо через нажатие правой клавиши мыши на нужной функции в меню и выбор пункта "Добавить в избранное" (рис. 2). Либо через код транзакции, нажав правой клавишей на папку "Избранное" и выбрав пункт "Вставить транзакцию" (рис. 3).

Рис. 2. Добавление пункта меню в избранное.

Рис. 3. Добавление в избранное транзакции через её код.

Очень часто возникает ситуация, когда пользователь, случайно нажав на кнопку "Меню SAP", получил на экране не привычное ему меню, а стандартное меню SAP, в котором он не может найти необходимые ему для работы функции и транзакции. Поведение системы по-умолчанию подразумевает показ из двух этих типов меню того, которое было выбрано в последнюю сессию работы в системе. Таким образом, нажав однажды не на ту кнопку, пользователь будет при каждом логине иметь одну и ту же пугающую картину: огромное древовидное стандартное меню (рис. 4).

Рис. 4. Стандартное меню SAP.

Для решения этой проблемы есть два пути.

Первый предполагает деактивацию кнопки "Меню SAP" для всей системы. Для этого необходимо войти в транзакцию SM30, выбрать ракурс ведения для таблицы SSM_CUST (рис. 5) и параметру SAP_MENU_OFF присвоить значение 'YES' или 'X' (рис. 6). Следует помнить, что эта настройка производится для всех мандантов системы.

Рис. 5. Ведение ракурса таблицы SSM_CUST.

Рис. 6. Отключение кнопки стандартного меню SAP.

В результате у пользователей в системе всегда будет только меню на основе их ролей, а кнока "Меню SAP" будет деактивирована (рис. 7).

Рис. 7. Кнопка "Меню SAP" неактивна.

Если у пользователя нет ролей или в ролях нет меню, то его экран будет пустой (рис. 8).

Рис. 8. Пустое меню пользователя.

Таким же образом можно дективировать кнопку "Меню пользователя", указав в том же ракурсе ведения параметр ALL_USER_MENU_OFF =  'YES' (или 'X') (рис. 9 и 10).

Рис. 9. Отключение кнопки "Меню пользователя".

Рис. 10. Кнопка "Меню пользователя" неактивна.

При выставлении обоих параметров в 'YES' (или 'X') у пользователей будут на экране только списки избранного (рис. 11). То есть меню будет отключено.

Рис. 11. Деактивация меню у пользователей.

Второе решение подразумевает настройку доступности разных типов меню для каждого отдельного пользователя. Для этого необходимо в транзакции SM30 выбрать ракурс ведения к таблице USERS_SSM (рис. 12).

Рис. 12. Ведение ракурса таблицы USERS_SSM.

В таблице можно для каждого пользователя прописать какой тип меню для него будет доступен (рис. 13).

Рис. 13. Настройка меня для каждого пользователя.

Настройка из данной таблицы имеет больший приоритет, чем общесистемная настройка в таблице SSM_CUST. Поэтому для пользователей ADMIN и SHIBOLOV экраны будут выглядить согласно настройке из таблицы USERS_SSM (рис. 14 и 15).

Рис. 14. Экран пользователя ADMIN c активным "Меню пользователя".

Рис. 15. Экран пользователя SHIBOLOV с активным "Меню SAP".

В транзакции SSM2 можно переопределить меню, которое будет показываться в качестве начального "Меню SAP" (рис. 16).

Рис. 16. Установка меню в качестве стандартного.

Если выбрать в качестве основного, например, "S002 -Системное администрирование", то основной экран со стандартным меню будет выглядеть совсем по-другому (рис. 17).

Рис. 17. Стандартное начальное меню SAP с поддеревом "Системное администрирование".

Таким образом, данный набор настроек позволяет гибко настроить меню в системе:

• отключить всё меню для всех,
• деактивировать кнопку "Меню SAP" для основного числа пользователей или конкретных лиц,
• деактивировать кнопку "Меню пользователя" для всех пользователей или конкретных лиц.

Подробности по этой теме можно найти в SAP note # 380029 - FAQ: Customizing of SAP Easy Access.


Автор: Шиболов Вячеслав Анатольевич