Par Dmitry Gutsko, SAP Security Expert
Nous savons que les systèmes de base de données SAP sont souvent négligés au niveau de l’infrastructure de sécurité d’une entreprise. Nous sommes souvent confrontés à des silos et des angles morts, mais ce qui est plus inquiétant encore, c’est que les dirigeants le savent très bien. Par exemple, 66 % d’entre eux s’inquiètent de l’augmentation du niveau de menace dans le monde. Qu’en est-il des menaces internes ? Ces incidents ont augmenté de 44 % au cours des deux dernières années, avec un coût s’élevant à 15,38 millions de dollars par incident. Alors à quoi pourrait bien ressembler l’avenir de la sécurité SAP ?
Aujourd’hui, nous évoluons dans l’univers du Big Data et à l’avenir nous allons être confrontés à des exigences encore plus importantes pour comprendre les clients, les données des clients et leurs besoins. De plus, nous savons que la migration SAP, prévue pour 2027, va nous pousser encore davantage vers SAP HANA. Une étude publiée en mars 2021 a montré que seuls 24 % des clients SAP avaient déjà effectué la transition vers SAP S/4HANA, 23 % déclaraient par contre qu’ils n’avaient pas prévu de migration.
Commençons donc par ce constat. À l’heure actuelle, (SAP) S/4HANA est sous-estimé au sein de la sécurité SAP, mais avec la migration prévue dans quelques années seulement, il est important que nous comprenions les besoins, les défis et les méthodes qui peuvent être utilisées.
Quels sont les principaux défis pour les équipes de sécurité SAP ?
- Comment protéger les données contre les accès non autorisés ?·
- Comment garder le contrôle des administrateurs et des utilisateurs avec des privilèges élevés ?·
- Et enfin comment identifier du code ABAP malveillant dans votre paysage SAP ?
Ensuite, nous devons déterminer comment nous pouvons facilement détecter tous ces cas d’usage en utilisant une seule source de log.
Comme vous le savez peut-être, il existe un grand nombre de modules métier SAP basés sur la plateforme SAP NetWeaver ABAP. Chaque module fournit de nombreuses fonctionnalités aux utilisateurs finaux et aux consultants SAP. Il est évident que les membres de l’équipe de sécurité IT ne peuvent pas connaître tous les aspects de chaque module, mais ils peuvent par contre contrôler l’accès aux tables contenant des informations sensibles au niveau de la base de données.
Les tables et les requêtes SQL sont des termes bien connus dans le monde informatique et tous les experts en sécurité les connaissent. En utilisant une telle approche, vous n’avez plus besoin de dépendre de nouvelles technologies SAP telles que FIORI, SAPUI5 et S/4 HANA. En effet, tout code exécute une requête SQL au niveau de tables de base de données contenant elles-mêmes des données. Ainsi, nous pouvons unifier les contrôles de sécurité SAP, quels que soient les logiciels et technologies SAP spécifiques que vous utilisez. Nous devons seulement contrôler quelles requêtes SQL ont été lancées et quelles tables ont été exécutées au niveau de HANA et par qui. Ainsi, le Modern SIEM pourra distinguer les requêtes courantes de celles qui sont anormales et identifier les accès (ou les modifications) malveillants aux données sensibles dans SAP.
La protection des logiciels SAP contre les administrateurs ne disposant pas d’une sécurité au niveau de HANA semble franchement hors sujet. En effet, le moyen le plus simple pour les experts SAP BASIS souhaitant consulter les salaires est d’utiliser HANA Studio, l’outil SAP HANA hdbsql ou DBCOCKPIT. Dans la plupart des cas, les requêtes seront générées au niveau des bases de données via l’utilisateur technique SAPABAP1 (propriétaire du schéma) ou l’utilisateur SYSTEM. Ainsi, ces dernières échapperont facilement à toute détection et à d’éventuelles questions indésirables, car une telle activité provenant d’utilisateurs techniques accédant aux données est tout à fait classique.
Que doit faire l’équipe de sécurité dans ce cas ?
En fait, il n’y a qu’une seule option : activer la protection au niveau de SAP HANA et la journalisation (logging) pour les tables critiques, même pour les utilisateurs techniques de HANA (l’administrateur qui a de mauvaises intentions n’utilisera jamais son propre nom d’utilisateur dans la base de données SAP HANA).
Il existe de nombreux cas où les développeurs et les sous-traitants créent un code ABAP malveillant dans les systèmes de production des clients, puis l’exécutent. La durée de vie de ces programmes peut n’être que de cinq minutes. Des programmes ABAP ont même la capacité d’exécuter du code dynamique. C’est pourquoi il est extrêmement difficile de détecter un tel code malveillant à l’aide de scanners de code source. Il est important de souligner que même ce cas d’usage peut être facilement détecté à l’aide des logs HANA. Quel que soit le code ABAP utilisé (standard ou personnalisé) par d’éventuelles personnes infiltrées, dans ce cas précis, ce dernier lancera alors probablement une requête SQL spécifique pour accéder aux données sensibles et les modifier. Ce type d’action pourrait également révéler les intentions et la personnalité de l’attaquant.
De nos jours, le nombre d’utilisateurs de la base de données SAP HANA ne cesse de croître. Au début, seuls les administrateurs recevaient un accès légitime à la base de données SAP. La situation actuelle est complètement différente. Les sous-traitants, les développeurs, les consultants SAP et même les utilisateurs finaux ont leurs propres comptes utilisateur dans une base de données HANA, rendant ainsi d’autant plus importante la nécessité de vérifier plus attentivement les privilèges utilisateur ainsi que les actions menées avec ces derniers, en particulier ceux concernant les tables de schéma SAPABAP1.
Comment faire pour sécuriser SAP HANA ?
Il est essentiel de ne pas oublier les technologies modernes telles que les vues de calcul/vues analytiques dans HANA, qui peuvent contenir un accès indésirable à des données sensibles. De même, le nombre d’intégrations de type HANA-to-HANA entre les systèmes SAP ne cesse de croître, et toutes ces intégrations peuvent générer d’éventuelles menaces de sécurité pour vos données.
La sécurité au niveau de HANA est vitale et deviendra encore plus importante à l’avenir. Les logs HANA peuvent tous nous aider à protéger nos systèmes SAP, mais un seul élément en matière de sécurité SAP est largement reconnu dans le monde : SoD (Segregation of Duties). Seules quelques personnes déploient des solutions SIEM et essaient de détecter un comportement anormal dans les systèmes SAP. Peu de clients pensent à la protection au niveau de HANA. Néanmoins, cette situation changera à mesure que de plus en plus d’entreprises se tourneront vers des outils comme Logpoint BCS for SAP qui prend en charge la source de log HANA et se connecte à n’importe quel SIEM. La protection de vos environnements SAP n’aura jamais été aussi simple et aussi complète.
