Communiquer en toute sécurité avec Hana

Les architectures des paysages SAP ont fondamentalement changé avec l'introduction de SAP Hana. Hana avait d'abord été développé comme une base de données relationnelle pour les systèmes SAP, basée sur la technologie in-memory.

L'ensemble du traitement et du stockage des données s'effectue alors dans la mémoire principale de l'environnement système, ce qui entraîne un énorme gain de performance par rapport aux systèmes de base de données traditionnels.

Mais Hana ouvre également de nouvelles possibilités dans l'utilisation professionnelle et devient ainsi de plus en plus une plateforme de développement sur laquelle les applications Java et HTML5 sont exécutées dans des environnements d'exécution.

L'accent est désormais mis sur les applications basées sur le web qui communiquent via HTTP.

Toutefois, sous Hana, le noyau SAP ne peut plus être modifié par l'utilisateur lui-même au niveau de la programmation ; Hana est donc considéré comme un système fermé et met ses fonctions à disposition via une multitude de connecteurs et d'interfaces auxquels des programmes d'application développés par l'utilisateur peuvent ensuite accéder.

Actuellement, plus de 2000 connecteurs et interfaces de ce type sont implémentés dans le noyau Hana - la tendance est fortement à la hausse, car de nouveaux domaines d'application doivent être couverts en permanence. En général, on peut distinguer les chemins de communication suivants sur cette plate-forme :

Connexions à Hana via le client de la base de données : elles servent principalement à la gestion du système de base de données - par exemple Hana Cockpit ou Hana Studio - ou pour les requêtes classiques dans la base de données, par exemple avec des outils de business intelligence ou tout simplement avec Excel. La communication se fait à l'aide du protocole SQLDBC, qui est un dérivé d'ODBC/JDBC.

Connexions de ce que l'on appelle des clients web. Il peut s'agir par exemple d'applications qui fonctionnent dans le runtime Java de Hana XS et qui sont directement intégrées dans l'environnement de la base de données.

L'extension XS est alors nécessaire ; la communication, généralement basée sur le web (HTTP/HTTPS), passe généralement par les ports TCP 3xx33, où xx représente le numéro d'instance correspondant. Dans cette configuration, XS met à disposition la machine d'exécution Java ainsi que le serveur web.

Cela pose un certain nombre de problèmes pour la sécurité de la plate-forme et des applications : Au sein de la plateforme, la communication se fait en "plain text", ce qui signifie que toutes les données sont échangées sans être cryptées ; cela vaut aussi bien pour les clients de la base de données que pour les clients web.

Les composants respectifs doivent s'authentifier mutuellement. Les options possibles sont Basic Auth (nom d'utilisateur/mot de passe), SAML Assertions et les certificats X.509. Toutefois, Basic Auth est généralement considéré comme peu sûr ; SAML et X.509 nécessitent à leur tour une gestion des certificats correspondante, qui n'est toutefois disponible que de manière limitée au sein du paysage Hana.

Le thème de la "protection des données" est donc de plus en plus mis en avant. Que se passe-t-il exactement, par exemple, lorsque des applications compromises accèdent aux données via les connecteurs ?

Actuellement, la plateforme Hana ne propose pas de chiffrement de la mémoire vive. Un pirate pourrait donc installer une application qui aurait accès à l'ensemble des données non cryptées.

La solution la plus évidente serait ici un cryptage de la RAM, mais celui-ci ne sera disponible qu'avec la dernière génération de processeurs ainsi que les modules correspondants dans le système d'exploitation.

Le défi de la validation

Cela met de plus en plus l'accent sur le thème du développement d'applications sécurisées, qui accorde par exemple une très grande priorité à la validation et à l'autorisation des données et des flux de données.

Dans le passé, lorsqu'un environnement SAP était encore un système ouvert, la majorité des fonctions étaient créées par le développement Abap lui-même, puis intégrées dans le noyau SAP.

Certes, des failles de sécurité pouvaient également apparaître, mais leur impact restait limité, car le noyau SAP assurait une certaine protection ; en tout cas, il n'était pas possible de compromettre toute une infrastructure de cette manière.

Le développeur travaille maintenant à un autre niveau, où le système ne le protège plus ; son application accède aux connecteurs et aux interfaces et s'il commet une erreur de sécurité critique à ce niveau, toute l'infrastructure est, dans le pire des cas, ouverte aux attaquants, qui peuvent alors également accéder aux connecteurs concernés.

Les développeurs d'applications doivent s'assurer que leurs flux XML, par exemple, sont correctement validés, afin d'éviter que des vulnérabilités ne permettent à un pirate d'accéder à l'intégralité de l'application, de la modifier et d'accéder ainsi à toutes les données de la mémoire vive.

Il faut aussi désormais tenir compte de la prise en compte et de la spécification des exigences de sécurité dans la phase de design et de conception, mais aussi des investissements dans le testing - par exemple dans le Static Application Security Testing (SAST), le Dynamic Application Security Testing et les tests de pénétration.

Dans les grands paysages SAP, les utilisateurs doivent en outre s'occuper de plus en plus de questions d'infrastructure comme les Web Application Firewalls (WAF) et les XML-Firewalls.

Ainsi, les développeurs utilisent de plus en plus souvent des microservices basés sur des API REST pour l'échange de données - par exemple avec SAP Leonardo, la plateforme d'échange et d'analyse d'informations IoT.

Ces données doivent être transmises rapidement et en toute sécurité, une compromission des données doit être évitée dans tous les cas. Pour cela, les signatures numériques, le cryptage de transport au moyen de 2-Way-SSL-Handshakes, la validation XML sont par exemple des moyens de choix.

De nombreux développeurs renoncent encore à mettre en place de telles mesures de sécurité dans leurs applications, car ils craignent une réduction des performances globales de leurs systèmes, mais d'autre part, les systèmes ne sont parfois pas non plus en mesure de prendre en charge de telles mesures au niveau de l'application.

C'est pourquoi les composants d'infrastructure mentionnés sont indispensables pour un fonctionnement sécurisé dans un environnement Hana.

Paradoxalement, c'est justement parce que Hana est un système programmatiquement fermé qu'il faut se concentrer sur le thème des voies de communication et des partenaires de communication.

En cas d'attaque réussie sur les applications Hana, la plateforme pourrait devenir une porte d'entrée pour les pirates, leur permettant d'accéder à n'importe quelles données critiques de l'entreprise.