Управление полномочиями
для разработки в SAP HANA

Сегодня практически каждый пользователь SAP сталкивается с SAP HANA – системой управления базами данных, которая также используется как среда разработки приложений. Но прежде чем начать разрабатывать приложения или даже писать простые запросы к базе, необходимо настроить доступ пользователей и определить доступные для них полномочия.

В этой статье мы не касаемся конкретных требований по безопасности, так как они зависят от предприятия. Приведём лишь общие сведения о работе с полномочиями – создании и присвоении ролей пользователям. Всё нижеописанное актуально для версии SAP HANA Studio 2.3.17.00000. В других версиях могут быть небольшие различия, но общая концепция сохраняется.

Предположим, что HANA Studio уже установлена, настроена, в ней созданы системы (ландшафты) для разработки.

Прежде всего необходимо создать учётную запись пользователя. Для этого выбирается система, в которой будет создан пользователь. В дереве каталогов выбирается папка Security и объект Users внутри папки. В контекстном меню надо нажать на пункт New User – это стандартный пользователь. Также можно выбрать Restricted User – такой пользователь не может создавать объекты, видеть данные, и он подключается только по HTTP.

В открывшемся окне вводится имя пользователя в соответствии с порядками, введёнными в организации. Далее нужно выбрать тип аутентификации. Если по паролю, то вводится и подтверждается начальный пароль. Также возможна аутентификация по протоколу Kerberos, сопоставляющему идентификацию в Windows Active Directory. Для этого указывается login, по которому будет осуществляется авторизация по протоколу.

На следующем скриншоте показано, что пользователь создан с параметром аутентификации по протоколу Kerberos. Выставленный чекбокс напротив параметра SAML означает, что для данного пользователя используется сертификат SAML. С помощью данного сертификата реализуется технология единого входа, т.е. он позволяет не осуществлять повторную аутентификацию и использовать учётную запись для нескольких систем и программных продуктов. Например, таким образом можно получить доступ к SAP HANA и Business Object – инструменту разработки отчётности. Настройка сертификата осуществляется с помощью кнопки Configure:

Предполагается, что при настройке систем сертификат уже был установлен в систему. В открывшемся окне нажимается кнопка Add (добавить), выбирается из списка необходимый сертификат и указывается пользователь для целевой системы – в данном случае Business Object:

Также имеется возможность использовать сертификат X.509. Он необходим для доступа SAP HANA XS по протоколу HTTP. Для его использования нужно повторить действия, аналогичные для протокола SAML.

После того как всё введено, необходимо произвести активацию:

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

Созданной учётной записи необходимы полномочия, чтобы осуществлять полноценную разработку. При создании стандартного пользователя по умолчанию присваивается роль PUBLIC, предоставляющая доступ только на чтение:

Остальные роли присваиваются по необходимости. Каждая роль даёт определённые полномочия на определённые объекты. Если взять конкретную роль, то в ней может быть несколько типов привилегий. Ниже на картинке представлена общая схема:

1. System Privileges – полномочия для администрирования (создание и изменение схем, мониторинг, управление пользователями). Для обычного пользователя и большинства разработчиков данный тип привилегий не требуется.

2.Object Privileges – полномочия на конкретный объект (каталог, схему, представление и т.д.). Ниже пример того, как на объект – схему – предоставлены полномочия только на запуск операции select:

3. Analytic Privileges – полномочия на доступ к данным в определённом объекте. Они используются, когда есть необходимость разграничить выгружаемые данные в зависимости от роли пользователя. Обычно аналитические привилегии привязаны к конкретному объекту, например, к представлению. В общей же роли, допустим, на целую схему аналитические привилегии не добавляют, хотя это зависит от регламентов безопасности, принятых на предприятии.

4.Package Privileges – полномочия на пакеты (каталоги, папки), в которых находятся объекты. К примеру, в общей роли на схему можно разграничить, к каким пакетам будет доступ у пользователя и какие опции будут при этом доступны. На указанном ниже примере видно, что данная роль предоставляет доступ к списку пакетов, с возможностью чтения, редактирования, активации как для уже имеющихся объектов, так и для импортированных:

5. Application Privileges – полномочия на использование приложений SAP HANA XS. В таком случае приложение будет указано как объект.

6. Privileges on Users – полномочия, предоставляемые конкретному пользователю. Например, такая роль применяется для возможности осуществлять дебаг объекта.

После создания учётной записи пользователя и определения необходимости предоставляемых полномочий создаётся роль в соответствии с правилами безопасности предприятия. Для создания роли необходимо выбрать папку Security в выбранной системе и в контекстном меню выбрать пункт New Role:

В меню создания роли необходимо указать наименование роли в соответствии с положениями, принятыми на предприятии. Далее в соответствующих разделах по нажатию кнопки «плюс» добавляются необходимые роли и привилегии, если это необходимо. Таким образом можно создать и так называемую групповую роль, в которую включены несколько ролей, и отдельную роль на конкретный объект. После всех выбранных объектов роль необходимо активировать.

Созданную роль можно назначить необходимому пользователю, открыв свойства учётной записи пользователя и при нажатии «плюса» в разделе присвоенных ролей выбрав необходимую из списка:

После выполнения всех этих действий будет готова учётная запись пользователя, для него будет создана и присвоена роль. Пользователь уже сможет осуществлять разработку в SAP HANA Studio, если, конечно, ему были присвоены необходимые роли. Как только разработчик создаст объекты – например, аналитический отчёт для пользователей – потребуется сделать роли для такого объекта. Это позволит разграничить доступ к данным, выгружаемым из этого отчёта.

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

В предыдущем разделе был описан процесс, в результате которого имеется учётная запись пользователя с присвоенной ролью (например, на конкретный пакет с объектами). Однако при создании отчёта в Business Object может возникнуть необходимость в полномочиях на объект (т.е. на конкретное представление) и в доступе к определённым данным. В таком случае, чтобы ограничить доступ к объекту, создаётся объектная роль, а для ограничения данных создаётся аналитическая привилегия.

Объектная роль, как понятно из названия, нужна для предоставления доступа к конкретному объекту. Если имеется возможность создания ролей в каталоге Security, то процесс уже был описан выше. В каталоге создаётся новая роль. В разделе Object Privileges перечисляются объекты, к которым будет предоставлен доступ. Если речь идёт об отчёте Business Object, то указывается модель отчёта в HANA и возможные операции (в случае доступа пользователя к отчёту указывается только select).

Может произойти ситуация, когда возможности создавать роли в каталоге Security нет, например, если роль создаётся разработчиком, а полномочия на создание ролей в этом каталоге есть только у администратора системы. В таком случае роль создаётся в репозитории, т.е. локально у себя на диске, а затем переносится в общий каталог. Если репозитория нет в разделе рядом с системами, то для его открытия нужно зайти в раздел Window, далее Show View – Other. В появившемся окне выбирается раздел SAP HANA и в нём Repositories:

В открывшемся репозитории выбирается нужная система (при первом запуске HANA Studio предложит выбрать место на диске для локального хранения файлов). Далее в нужном каталоге создаётся роль – подчеркнём, что желательно хранить роли отдельно от других объектов, в отдельном пакете. Правым кликом по пакету вызывается контекстное меню, в котором выбирается пункт New, далее Other и в открывшемся окне в разделе Database Development нужно найти объект Role.

Указывается наименование и выбирается действие Finish. Созданная роль откроется в рабочей области HANA Studio. В самой роли в виде SQL кода указывается адрес нахождения роли, включаемые в роль объекты и допустимые операции с ними:

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

Если объектная роль ограничивает доступ к конкретному объекту, то аналитическая привилегия ограничивает определённый срез данных. Например, данные формируются в разрезе нескольких отделов предприятия. В таком случае имеет смысл разделить вывод данных в отчёте в зависимости от принадлежности пользователя к отделу (подобное разделение зависит от политики безопасности в компании).

На модели SAP HANA для отчёта должен быть выставлен параметр Classical Analytic Privileges. Это означает, что пользователь не сможет запустить отчёт для просмотра данных, если у него нет аналитической привилегии на этот отчёт.

Создание аналитической привилегии осуществляется в разделе Systems. Для этого необходимо выбрать систему и каталог, в котором будет создан объект. Правым кликом по каталогу вызывается контекстное меню, в нём выбирается пункт New – Analytic Privilege. Указывается наименование, и, если нужно, привилегия создаётся как копия другой привилегии.

Далее в разделе Secured Models указываются необходимые для отчёта модели, в которых выставлен параметр аналитических привилегий (см. выше). В разделе Associated Attributes Restrictions определяются поля, по которым будет ограничиваться разрез данных. В разделе Assign Restrictions указываются значения полей, по которым будут ограничены данные. После всех необходимых действий привилегия сохраняется и активируется.

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