Hana nécessite de repenser la sécurité

Hana a d'abord été développée comme base de données relationnelle pour les systèmes SAP. Elle est basée sur la technologie en mémoire. Le principal avantage de cette technologie est qu'elle permet d'augmenter considérablement les performances par rapport aux systèmes de base de données traditionnels.

Avec l'introduction de Hana, SAP a également emprunté de nouvelles voies en ce qui concerne l'environnement de développement et l'interface utilisateur : Java et HTML5 ou Fiori et SAPUI5 sont au premier plan.

Il en résulte également de nouvelles possibilités d'application pour Hana dans le cadre de l'utilisation professionnelle. Hana est donc de plus en plus considérée comme une plateforme de développement sur laquelle n'importe quelle application Java et HTML5 peut être exécutée dans des environnements d'exécution.

L'élargissement du spectre des applications a également des répercussions sur le modèle et l'architecture de sécurité. L'accent est désormais mis sur cinq niveaux de sécurité primaires, qui découlent de l'environnement de développement Java ainsi que de la technologie de base de données :

Sécurité du réseau, authentification et SSO (Single Sign-on), autorisation, cryptage (transport et données) ainsi qu'audit et journalisation.

Dans le domaine de la sécurité du réseau, l'accent est mis sur les mesures classiques, c'est-à-dire sur l'architecture du système avec plusieurs zones de sécurité et la mise à disposition limitée des services nécessaires.

La communication réseau doit être réduite aux ports les plus nécessaires, notamment en ce qui concerne les possibilités d'accès aux données et à l'administration : par exemple via le protocole SQLDBC, Hana Studio ou SolMan.

En ce qui concerne l'authentification, Hana prend en charge de nombreuses méthodes sécurisées, telles que le nom d'utilisateur et le mot de passe, Kerberos, SAML (Security Assertion Markup Language) 2.0, les tickets de connexion SAP ou X.509.

Il est important de l'implémenter et de l'intégrer correctement dans l'environnement d'authentification existant, c'est-à-dire par exemple de le relier à Microsoft AD (Active Directory) et aux services d'annuaire LDAP (Lightweight Directory Access Protocol), de l'intégrer dans des environnements PKI (Public Key Infrastructure) ou de le relier à des procédures d'authentification basées sur des jetons comme SAML ou à des services de fédération d'Active Directory (Active Directory Federation Services, AD FS).

C'est dans le domaine de l'autorisation que les changements les plus importants ont été apportés à Hana. Pour simplifier, les administrateurs SAP doivent désormais maîtriser le "langage DBA".

Si, par le passé, la gestion des rôles et des autorisations était toujours liée aux applications ERP SAP, elle est désormais transférée à la couche de la base de données. Ainsi, pratiquement chaque application au sein du runtime Hana reprend le modèle d'autorisation de l'environnement de la base de données.

Or, celui-ci se distingue nettement des modèles d'autorisation utilisés jusqu'à présent, par exemple dans le système ERP. Un administrateur SAP doit désormais comprendre comment les bases de données fonctionnent et comment les rôles et droits précédents peuvent être transférés. Grâce au nouveau modèle d'autorisation de Hana, un contrôle d'accès extrêmement détaillé et précis est possible.

Pour ce faire, on utilise des rôles dans lesquels les droits sont regroupés et structurés. Les droits sont basés sur les autorisations SQL standard pour les objets et les spécifications Hana pour les applications professionnelles.

En ce qui concerne le cryptage, les deux niveaux de transport et de données doivent être pris en compte. Le cryptage du transport implique tout d'abord le cryptage SSL, mais il convient également d'examiner des alternatives telles que les techniques VPN.

Le cryptage des données ne fonctionne que lorsque les données sont stockées dans des volumes de stockage. Le cryptage des données dans la mémoire principale est ici le point crucial, surtout si plusieurs instances doivent être exécutées sur le même système.

Dans de tels cas, la question cruciale - mais souvent sans réponse - est la suivante : "Qui assure alors l'intégrité des données et empêche que les données ne 'sautent' d'une instance à l'autre ?"

Hana offre en outre de nombreuses possibilités d'audit et de journalisation. L'espace de stockage disponible est toutefois le facteur limitant. En raison de l'afflux de requêtes (SQL) sur le système, la mémoire risque rapidement d'atteindre ses limites de capacité.

Dans ce cas, seuls des outils externes peuvent aider à répondre aux exigences de conformité. Hana apporte donc intrinsèquement plusieurs fonctions de sécurité. Son utilisation nécessite toutefois un changement de mentalité de la part des administrateurs SAP.

Le plus grand défi concerne la gestion des rôles et des autorisations, car elle a complètement changé par rapport aux environnements ERP SAP précédents, dans lesquels les niveaux application et base de données étaient clairement séparés.

C'est d'ailleurs sur ce thème que NTT Security reçoit actuellement le plus de demandes de la part de ses clients. En revanche, le cryptage n'est pas encore au centre des préoccupations des utilisateurs.

Mais là aussi, un changement interviendra bientôt, car il reste encore beaucoup à faire en raison des exigences de conformité. Enfin, il ne faut pas oublier qu'en cas d'accès réussi à Hana, les pirates peuvent sans grand effort voler, modifier ou supprimer des données critiques pour l'entreprise.