Меню

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

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

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

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.

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

Войти

Обсуждения Количество комментариев1

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

Дмитрий Буслов

  |  02 апреля 2015, 16:02

(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.