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

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

1. Модели безопасности в SAP HANA

1.1 Традиционная 3-уровневая модель

SAP HANA можно использовать как реляционную базу данных в классической 3-звенной архитектуре, включающей клиентскую базу данных сервера приложения. SAP HANA предоставляет стандартные программные интерфейсы доступа к базам данных, такие как JDBC и ODBC, и поддерживает стандартный SQL-код (со специфичными расширениями SAP HANA).

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

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

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

SAP Business Suite и SAP Business Warehouse на базе SAP HANA являются классическими примерами такой архитектуры.

1.2 Информационная витрина для аналитики (3- или 2-уровневая)

SAP HANA изначально использовалась для поддержки аналитических сценариев. В таких сценариях данные, как правило, тиражируются из исходной системы, такой как SAP Business Suite, в SAP HANA. Пользовательские отчеты и инструментальные панели имеют прямой доступ для чтения к данным SAP HANA (2-уровневая архитектура) и поддерживают различные инструменты BI, включая SAP BusinessObjects Intelligence (3-уровневая архитектура), как показано на Рис.1.

Рис.1. Информационная витрина для аналитики (3- или 2-уровневая)

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

1.3 Встроенная 2-уровневая архитектура

SAP HANA Extended Application Services (SAP HANA XS) представляет собой встроенный в SAP HANA полнофункциональный сервер приложений, веб-сервер и среду разработки. Приложения можно разворачивать напрямую на сервере SAP HANA XS, который предоставляет доступ конечным пользователям через веб-интерфейс, как показано на Рис.2.

Рис.2. Встроенная 2-уровневая архитектура

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

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

Кроме того, SAP HANA XS поддерживает защиту от типичных уязвимостей веб-приложений, например, XSRF. Подробную информацию и рекомендации по разработке безопасных приложений на базе SAP HANA см. в SAP HANA Developer Guide.

2. Функции безопасности

SAP HANA включает функции безопасности, которые позволяют реализовывать различные политики безопасности и обеспечивают соответствие нормативным требованиям.

В соответствии со сценарием использования на уровне SAP HANA могут потребоваться только определённые функции безопасности, а прочие могут потребоваться (применяться) на других уровнях архитектуры. Обзор функций безопасности представлен на Рис.3.

Рис.3. Обзор функций безопасности SAP

2.1 Аутентификация и Single Sign-On

Методы аутентификации представлены в Таблице 4.

Таблица 4. Методы аутентификации SAP HANA

Метод аутентификации	Доступ через JDBC/ODBC	Доступ по HTTP (SAP HANA XS)
Имя пользователя/пароль Можно определить политики паролей, например, длину и сложность пароля	Да	Да (базовая аутентификация, вход через формуляр)
Kerberos	Да	Да (SPNEGO)
SAML 2.0	Да (маркер предъявителя)	Да
Мандаты входа/утверждения SAP	Да	Да
X.509	–	Да

 

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

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

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

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

Рис.5. Жизненный цикл ролей в SAP HANA

2.3 Архитектура полномочий

SAP HANA поддерживает различные механизмы авторизации на основе стандартных привилегий SQL и специфичных расширений SAP HANA для бизнес-приложений.

Привилегии определяют возможности пользователей и присваиваются как ролям, так и пользователям. Рекомендуется объединять привилегии в ролевые. Методы и шаблоны ролей приведены в документе “How To... Define Standard Roles for Administrators and Developers in SAP HANA Database”.

Типы привилегий SAP HANA представлены в Таблице 6.

Таблица 6. Типы привилегий SAP HANA

Тип привилегий	Целевые пользователи	Описание