Hana Security – drei Szenarien
Hana kann als Datenbank in einer traditionellen Architektur verwendet werden, eine weitere Möglichkeit ist, Hana als Plattform einzusetzen, oder aber Hana als Data-Mart in eine BW-Landschaft einzubinden.
Die drei unterschiedlichen Szenarien haben direkten Einfluss auf das Hana-Security-Konzept.
Erstens: Datenbank in einer traditionellen 3-tier-Architektur: In diesem Szenario wird die Datenbank, die unter dem Applikationsserver liegt, durch Hana ausgetauscht.
Zweitens: Hana als Plattform: In diesem Szenario wird ebenfalls die Datenbank durch Hana ersetzt, zusätzlich werden aber auch die Anwendungen auf der Hana-Plattform bereitgestellt.
Drittens: Hana als Data-Mart in einer BW-Landschaft: In diesem Einsatzszenario wird Hana parallel zu einer bestehenden Datenbank eingesetzt. Die Daten lassen sich dann aus verschiedenen Source-Systemen, beispielsweise aus einem SAP- oder Fremdsystem, in die SAP-Hana-Datenbank replizieren.
Mit Hana hat auch eine neue Begrifflichkeit Einzug in das Thema Security gehalten. Man unterscheidet in Hana zwischen Catalog-Rollen und Repository-Rollen. Catalog-Rollen beinhalten Runtime-Objekte (Schemas, Tabellen, Views und Rollen), während Repository-Rollen Design-time-Objekte beinhalten (Packet, Views, Berechtigungen und Rollen).
Ein weiteres Merkmal ist, dass Repository-Rollen – wie jedes andere Objekt in der Hana Repository – transportierbar sind, während das auf die Catalog-Rollen nicht anwendbar ist.
Die Repository-Rollen haben den _SYS_REPO-Benutzer als Owner, während Catalog-Rollen den Entwickler als Owner haben, was zur Folge hat, dass wenn der Entwicklerbenutzer gelöscht wird, auch der Inhalt der Catalog-Rollen gelöscht wird.
Ähnlich wie im Abap sind die Rollen im Hana-Container für Zugriffsberechtigungen. In einer Rolle werden die Berechtigungen (Privileges) strukturiert gruppiert.
Rollen in Hana sind Objekte und der Zugriff wird entsprechend über die Objektberechtigungen (Object Privileges) gesteuert. Rollen können aber neben Berechtigungen auch andere Rollen beinhalten.
Security Model
Das Hana Security Model sieht verschiedene Berechtigungstypen (Privilege Types) vor:
Object Privileges: Über die Object Privileges wird der Zugriff auf Objekte gesteuert. In Hana sind dies beispielsweise Tabellen/Views, Rollen, Stored Procedures, Synonyms. Im Falle von Tabellen oder Views könnte man die „Object Privileges“ mit dem Objekt S_TABU_NAM in der Abap-Welt vergleichen.
Analytic Privileges: Über die Analytic Privileges wird grundsätzlich der Zugriff auf das Hana-Daten-Modell gesteuert. Während Object Privileges den Zugriff auf das Objekt (Tabelle, View) steuern, wird über die Analytic Privileges der Zugriff auf bestimmte Daten aus dem Objekt auf granularer Ebene gesteuert.
Das Pendant dazu im Abap wäre das Berechtigungsobjekt S_TABU_LIN, über welches sich ebenfalls der Zugriff auf bestimmte Zeilen entsprechend steuern lässt. Analytic Privileges sind jedoch vorgesehen für den Read-only-Zugriff auf die Hana-Informationsmodelle (Attribute View, Analytic Views, Calculation Views).
In einer Hana Attribute View werden Stammdaten modelliert und ein Attribute View kann ähnliche Aufgaben wie Linked Universes im SAP BO übernehmen. In einer Hana Analytic View wird eine Faktentabelle mit ihren zugehörigen Attributen modelliert.
Eine Analytic View kann mit einem SAP-BO-Universum mit genau einer Faktentabelle verglichen werden. Die Hana Calculation Views werden verwendet, um mehrere Fakten oder berechnete Joins abzubilden, und erlauben die Verbindung von mehreren Faktentabellen, vergleichbar mit SAP-BO-Kontexten in Universen.
System Privileges: Über die System Privileges wird der Zugriff auf die administrativen Funktionen gesteuert.
Package Privileges: Packages werden in Hana genutzt, um den Repository Content zu strukturieren. Über die Package Privileges wird der entsprechende Zugriff auf das Package und alle dazugehörigen Sub-Packages gesteuert. Die Struktur der Packages ist nicht durch SAP vorgegeben und den Kunden überlassen.
Application Privileges: Über die Application Privileges wird der Zugriff auf die Hana-XS-Applikation und Funktionalität gesteuert. Hierüber wird beispielsweise gesteuert, welche Applikationen gestartet werden können und welche Funktionen und Screens angezeigt werden.
Rollen – Good Practices: Aus den bereits genannten Gründen ist bei der Rollenerstellung den Repository-Rollen der Vorrang zu geben. SAP selbst empfiehlt die Benutzung von Repository-Rollen.
Mehr und mehr werden auch die integrierten Applikationen – welche mit Hana ausgeliefert werden – mit vordefinierten Repository-Rollen versehen. Die Anforderungen an die Security sollten auf jeden Fall rechtzeitig in der Design-Phase und im Entwicklungsprozess entsprechend berücksichtigt werden.
Eine nachträgliche Anpassung kann einen erheblichen Aufwand mit sich bringen. Beim Design der Packet-Struktur ist es ratsam, auch die entsprechenden Kontrollen zu berücksichtigen (Package Privileges), beispielsweise HR, Non-HR/Sensitive, Non-Sensitive.
