Hana Security - trois scénarios

Hana peut être utilisé comme base de données dans une architecture traditionnelle, une autre possibilité est d'utiliser Hana comme plateforme, ou encore d'intégrer Hana comme Data-Mart dans un paysage BW.

Les trois différents scénarios ont une influence directe sur le concept de sécurité Hana.

Premièrement Base de données dans une architecture traditionnelle à 3 niveaux : dans ce scénario, la base de données qui se trouve sous le serveur d'application est remplacée par Hana.

Deuxièmement : Hana comme plateforme : dans ce scénario, la base de données est également remplacée par Hana, mais les applications sont également mises à disposition sur la plateforme Hana.

Troisièmement Hana comme Data-Mart dans un paysage BW : dans ce scénario de déploiement, Hana est utilisé parallèlement à une base de données existante. Les données peuvent alors être répliquées dans la base de données SAP Hana à partir de différents systèmes sources, par exemple à partir d'un système SAP ou d'un système tiers.

Avec Hana, une nouvelle terminologie a également fait son apparition dans le domaine de la sécurité. Dans Hana, on distingue les rôles de catalogue et les rôles de référentiel. Les rôles Catalog contiennent des objets runtime (schémas, tables, vues et rôles), tandis que les rôles Repository contiennent des objets design-time (package, vues, autorisations et rôles).

Une autre caractéristique est que les rôles de référentiel - comme tout autre objet dans le référentiel Hana - sont transportables, alors que cela n'est pas applicable aux rôles de catalogue.

Les rôles Repository ont l'utilisateur _SYS_REPO comme propriétaire, alors que les rôles Catalog ont le développeur comme propriétaire, ce qui a pour conséquence que si l'utilisateur développeur est supprimé, le contenu des rôles Catalog est également supprimé.

Comme dans Abap, les rôles dans le conteneur Hana sont destinés aux droits d'accès. Dans un rôle, les autorisations (privileges) sont regroupées de manière structurée.

Les rôles dans Hana sont des objets et l'accès est contrôlé en conséquence par les autorisations d'objets (Object Privileges). Les rôles peuvent toutefois contenir d'autres rôles en plus des autorisations.

Modèle de sécurité

Le modèle de sécurité Hana prévoit différents types d'autorisation (Privilege Types) :

Privilèges d'objet : L'accès aux objets est contrôlé par les Object Privileges. Dans Hana, il s'agit par exemple de tables/vues, de rôles, de procédures stockées, de synonymes. Dans le cas des tables ou des vues, on pourrait comparer les "Object Privileges" à l'objet S_TABU_NAM dans le monde Abap.

Privilèges analytiques : L'accès au modèle de données Hana est fondamentalement contrôlé par les Analytic Privileges. Alors que les privilèges d'objet contrôlent l'accès à l'objet (table, vue), les privilèges analytiques contrôlent l'accès à certaines données de l'objet à un niveau granulaire.

Le pendant dans Abap serait l'objet d'autorisation S_TABU_LIN, qui permet également de contrôler l'accès à certaines lignes en conséquence. Les Analytic Privileges sont toutefois prévus pour l'accès en lecture seule aux modèles d'information Hana (Attribute View, Analytic Views, Calculation Views).

Dans une Hana Attribute View, les données de base sont modélisées et une Attribute View peut effectuer des tâches similaires à celles des Linked Universes dans SAP BO. Dans une Hana Analytic View, une table de faits est modélisée avec ses attributs correspondants.

Une Analytic View peut être comparée à un univers SAP-BO avec exactement une table de faits. Les Hana Calculation Views sont utilisées pour représenter plusieurs faits ou jointures calculées et permettent de relier plusieurs tables de faits, comparables aux contextes SAP-BO dans des univers.

Les privilèges du système : Les privilèges du système permettent de contrôler l'accès aux fonctions administratives.

Package Privileges : Les packages sont utilisés dans Hana pour structurer le contenu du référentiel. L'accès correspondant au package et à tous les sous-packages correspondants est contrôlé par les Package Privileges. La structure des packages n'est pas imposée par SAP et est laissée à l'appréciation des clients.

Privilèges d'application : Les privilèges d'application permettent de contrôler l'accès à l'application et aux fonctionnalités Hana-XS. Ils permettent par exemple de contrôler quelles applications peuvent être lancées et quelles fonctions et écrans sont affichés.

Rôles - Bonnes pratiques : Pour les raisons déjà mentionnées, la priorité doit être donnée aux rôles de référentiel lors de la création de rôles. SAP lui-même recommande l'utilisation des rôles de référentiel.

De plus en plus, les applications intégrées - qui sont livrées avec Hana - sont également dotées de rôles de référentiel prédéfinis. Les exigences en matière de sécurité devraient en tout cas être prises en compte à temps dans la phase de conception et dans le processus de développement.

Une adaptation ultérieure peut entraîner un travail considérable. Lors de la conception de la structure des paquets, il est conseillé de tenir également compte des contrôles correspondants (Package Privileges), par exemple HR, Non-HR/Sensitive, Non-Sensitive.