SysAdminDay - 2020

Всех причастных с праздником!

Желаю:
Стабильной работы систем! 
Меньше рутины, но больше интересных задач!
Уважения коллег и руководства!
Удовольствия от работы и материальных благ!


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

Вебинар "Решения Fujitsu и Red Hat для SAP HANA"

В прошлый вторник, 21 июля, присутствовал на вебинаре "Сотрудничество для достижения успеха: Решения Fujitsu и Red Hat для SAP HANA". Открыл для себя несколько интересных моментов и хочу ими поделиться.

В первой части вебинара от компании Fujitsu выступал бессменный консультант по бизнес-приложениям Николай Гришин (рис. 1). А от компании Red Hat архитектор по решениям Дмитрий Алехин представил свою презентацию во второй части.

Рис. 1. Николай Гришин из компании Fujitsu.

Компания Fujitsu использует в своих решениях Linux, в частности для SAP систем, уже больше 20 лет. Первый проект, в котором она принимала участие, был 1999 году и в нём работала система SAP R/3 4.0. Измеренный уровень производительности был 241 SAPS (рис. 2).

Рис. 2. Первые инсталляции SAP на Fujitsu/Linux.

Их современные серверные решения показывают гораздо больший уровень производительности (рис. 3).

Рис. 3. Сервера PRIMEQUEST - рекорды производительности.

В решениях компании активно используется новый тип энергонезависимой памяти - Intel Optane DC persistent memory (DCPMM) (рис. 4).

Рис. 4. Память Intel Optane DC.

Утверждается, что использование данного типа памяти отлично ложится на концепцию SAP HANA и позволяет получить выигрыш, в первую очередь, при рестарте базы данных (рис. 5).

Рис. 5. Преимущества использования Intel Optane DCPMM в SAP HANA.

Вторая часть вебинара, как я уже упоминал, была посвящена решениям Red Hat. 

К свою стыду, впервые узнал, что у компании  Red Hat есть готовые решения операционных систем для разворачивания SAP систем. И существуют они уже с 2008 года (рис. 6). Наивно полагал, что такие готовые решения (for SAP Applications) есть только у SUSE.

Рис. 6. История партнёрства Red Hat и SAP.

  

У RHEL for SAP Applications есть практически те же опции и решения, что и у SLES: встроенные программные модули для отказоустойчивости, увеличенный срок поддержки, встроенные профили для быстрого разворачивания и мониторинга, а также Live Patching (рис. 7).

Рис. 7. RHEL for SAP Solutions.

Причём, на данный момент существует два вида подписок "RHEL for SAP Applications" и "RHEL for SAP Solutions" (рис. 8). Сравнение этих редакций RHEL тоже были освещены в вебинаре.

Рис. 8. Сравнение двух редакций.

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

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

Уязвимость в 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 и базы данных. Но об этом я расскажу уже во второй части статьи. 

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