Комментарии по теме

«Тра­нза­кция SM02: сообщения в SAP системе»
Олег Башкатов:
С помощью ФМ TH_POPUP можно отправить сообщение конкретному пользователю :-)
«Тра­нспо­ртная система SAP для чайников»
Вячеслав Шиболов:
Хорошая метафора с коробками. Наглядная.
«Вызов тра­нза­кции SAP из писем в MS Outlook»
Олег Точенюк:
Из ABAP для работы с фронт-эндом можно воспользоваться классом CL_GUI_FRONTEND_SERVICES, там есть методы по работе с реестром виндовс.

SAP Professional Journal Россия

В данном разделе представлены электронные варианты статей журнала «SAP Professional Journal Россия», который является русскоязычной версией всемирно известного издания «SAP experts»

Рекомендации по обеспечению безопасности и контроля SAP HANA

2391
1

Ключевое понятие

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

SAP HANA предоставляет следующие функции обеспечения безопасности: аутентификация, авторизация, шифрование и ведение контрольных журналов. Эти функции позволяют настроить собственную политику безопасности на основе сценариев, поддерживаемых в SAP HANA. Систему SAP HANA можно использовать для разработки приложений посредством SAP HANA Extended Services (XS) для обработки отчетности и аналитики в информационных витринах, а также как базу данных в приложениях SAP Business Warehouse (SAP BW) и SAP Business Suite. Перед внедрением средств безопасности SAP HANA важно учесть особенности различных сценариев и воздействие средств обеспечения безопасности/контроля. В следующем разделе будут подробнее рассмотрены различные сценарии.

SAP HANA как трехуровневая архитектура (клиент, сервер приложений и база данных)

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

С точки зрения средств обеспечения безопасности и контроля важно защитить учетную запись технического пользователя. Необходимо протестировать средства контроля ограниченного доступа и убедиться, что администраторы базы данных могут получить доступ к SAP HANA согласно требованиям обеспечения соответствия нормативам. В SAP HANA доступно несколько стандартных ракурсов (например, GRANTED_PRIVILEGES), которые можно использовать для проверки и тестирования ограничения доступа. Конечные пользователи в этом сценарии не должны иметь возможность получения прямого доступа к SAP HANA. С точки зрения авторизации применяются существующие методы (проверка полномочий и определение ролей в коде транзакции PFCG), а привилегии SAP HANA не применяются. Примерами такой архитектуры являются приложения SAP Business Suite, например, SAP ERP Central Component (ECC) на базе SAP HANA, SAP BW на базе SAP HANA, а также другие приложения на базе SAP HANA. 

SAP HANA как информационная витрина 

В этом сценарии данные тиражируются из исходной системы в SAP HANA, а затем на основе данных, хранящихся в SAP HANA, формируются отчеты. Например, инструменты SAP BusinessObjects Business Intelligence могут напрямую использовать данные, хранящиеся в SAP HANA, для предоставления конечным пользователям подходящих отчетов и инструментальных панелей для анализа данных. Конечным пользователям и администраторам требуется прямой доступ к базе данных SAP HANA с соответствующими привилегиями на получение доступа к нужной информации.

Этот сценарий подразумевает аутентификацию конечных пользователей из собственных клиентов и приложений SAP HANA и не требует какой-либо непосредственной аутентификации в базе данных SAP HANA для получения доступа к отчетам. Например, имя пользователя/пароль для базы данных SAP HANA, хранящиеся на сервере BusinessObjects Explorer, безопасно перенаправляют идентификатор пользователя в базу данных SAP HANA. В хранилище идентификаторов базы данных SAP HANA необходимо настроить идентификаторы именованных пользователей. С точки зрения средств обеспечения безопасности и контроля важно протестировать средства контроля ограниченного доступа для гарантии корректного предоставления доступа к данным конечным пользователям. Безопасность в SAP HANA должна проверяться с предоставлением пользователям соответствующих привилегий.

SAP HANA как сервер приложений 

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

Аутентификация SAP HANA

SAP HANA обеспечивает возможность прямой регистрации в базе данных SAP HANA с применением инструмента на базе Eclipse, SAP HANA Studio, через имя и пароль обычного пользователя, Kerberos на базе MIT и Security Assertion Markup Language (SAML) на базе XML. Для непрямой регистрации в базе данных SAP HANA, т.е. из приложений, работающих на основе SAP HANA, в целях аутентификации требуются данные именованных пользователей. Например, именованные пользователи SAP HANA XS или пользователи, работающие с инструментами с инструментами BusinessObjects Data Analytic (Web Intelligence), должны быть заведены в SAP HANA. Дополнительные изменения в аутентификации для приложения не требуются.

Типы пользователей SAP HANA

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

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

Управление пользователями и ролями

Управление пользователями и ролями в SAP HANA осуществляется посредством SAP HANA Studio. На Рис. 1 показаны основные данные пользователя с полномочиями на доступ к SAP HANA.

Рис. 1

Основные данные пользователя в SAP HANA с информацией аутентификации и авторизации

 

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

С точки зрения средств обеспечения безопасности и контроля, несмотря на возможность присвоения привилегий пользователям напрямую, успешной практикой в сфере безопасности является присвоение привилегий ролям SAP HANA в период проектирования с последующим присвоением этих ролей пользователям (т.е. с использованием репозитария). Роли, созданные в базе данных разработки SAP HANA, являются проектными ролями при переносе в продуктивную базу данных SAP HANA. После активации они становятся динамическими ролями SAP HANA. Управление пользователями и ролями осуществляется с помощью SAP HANA Studio или команд SQL в инструменте SAP HANA Studio. Рекомендуется присваивать роли пользователям посредством команд SQL для защиты объектов базы данных, поскольку в результате присвоения пользователей и ролей с помощью HANA Studio может возникнуть риск потери объектов и привилегий в случае удаления базы данных.

Приложения SAP HANA XS полностью интегрированы в базовые процедуры управления пользователями и ролями SAP HANA. На Рис. 2 показаны основные данные роли с различными привилегиями, доступными для присвоения. Для перехода к этому экрану используется папка "Security" (Безопасность) в системе SAP HANA. Щелкните правой кнопкой мыши по пиктограмме роли для вызова экрана, показанного на Рис. 2.

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal

Комментарии:

Дмитрий Буслов (Рейтинг: 1320) 16:02, 02 апреля 2015


Комментарий эксперта

(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД, но платформа! Достаточно просто зайти на help.sap.com, чтобы увидеть какое количество опций уже реализовано. Это и обработка гео-данных, и хранение на дисках, обработка потоковых данных, обработка текстов, предиктивная аналитика и многое другое…

(2) Хотелось бы отметить, что BO на текущий момент оптимизирован под HANA, то есть в юниверсах можно создавать HANA бизнес слой, который автоматически подтягивает наименования полей. Кроме этого, так как HANA — это поколоночная база данных, для неё имеет значение какое количество полей выбирается(чем меньше — тем быстрее), соответственно в BO на уровне юниверса, а также на уровне WebI сделали специальные галки — query stripping, которые позволяют извлекать только необходимые поля(те, которые используются в самом отчете).

(3) Также роли и полномочия можно присваивать через Web IDE. Далее автор говорит о том, то рекомендуется присваивать роли и полномочия с использованием SQL. По факту — одно и то же и ничем эти способы не отличаются, за исключением случаев когда присвоение происходит автоматически с использованием процедуры. При удалении базы (что в одном, что в другом случае) присвоения пользователям будут утеряны. (Так что помогут тут скорее бэкапы)

(4) Копирование возможно с использованием «mass copy», а также есть возможность переноса всех объектов в другой пакет с использованием «Refactoring».

(5) Есть возможность выбора — где именно хранить журналы аудита — файлы в ОС, либо запись в таблицу

(6) Единица поставки (Delivery Unit) — это скорее пакет приложений или цельная функциональность, чем запрос в ECC. Например, отдельным DU в HANA является вся библиотека SAPUI5.


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.