Une sécurité efficace commence par la conception de l'infrastructure


Les clients existants de SAP doivent passer aux nouvelles générations de logiciels de Walldorf d'ici 2025. Ils profitent de l'occasion pour transformer numériquement leurs processus et leurs modèles commerciaux.
Mais ils doivent également être conscients des risques de sécurité qui en découlent. En effet, plus de numérisation signifie plus de possibilités d'attaques pour les cyberespions et les pirates, notamment par le biais de failles de sécurité.
La migration vers S/4 Hana s'accompagne d'une modernisation des paysages informatiques, la virtualisation étant le moyen de choix. Une opportunité que les clients SAP existants devraient saisir, non seulement du point de vue de la gestion d'entreprise, mais aussi pour une sécurité plus efficace.
En effet, dans les environnements virtualisés, en plus des failles de sécurité dans les systèmes d'exploitation invités des machines virtuelles, il faut tenir compte des fuites potentielles dans l'hyperviseur et les couches sous-jacentes, y compris le stockage et la mise en réseau. Le problème est d'autant plus aigu que les systèmes logiques et les applications sont beaucoup plus nombreux dans ce type d'infrastructure.
Une conception sécurisée des infrastructures contribue à réduire le nombre de failles de sécurité. Un déploiement plus rapide des mises à jour de sécurité réduit la vulnérabilité.
Mais même dans ce cas, il reste un risque résiduel qui doit être couvert par des solutions spécialisées. Le moyen le plus simple d'y parvenir est de mettre à la disposition des fournisseurs de sécurité informatique des infrastructures virtualisées et pilotées par logiciel, avec des possibilités d'intégration prédéfinies.
Les infrastructures pilotées par logiciel ont l'avantage de pouvoir implémenter la sécurité comme une fonctionnalité à part entière, à côté de toutes les autres.
Celle-ci illustre toutes les étapes d'un développement axé sur la sécurité : de la conception et du déploiement du logiciel jusqu'aux tests et au "durcissement" supplémentaire de la solution.
Dans le jargon, le processus global est appelé "Security Development Lifecycle" (SecDL). Dans ce processus, le code du programme est systématiquement examiné à la recherche de failles de sécurité.
S'ils en trouvent, les développeurs s'attaquent immédiatement à leur élimination. Cette procédure se répète constamment et s'étend sur tout le cycle de vie du développement logiciel.
SecDL offre en outre la possibilité de prendre en compte les règles de sécurité dans le processus. Il s'agit notamment de Common Criteria Certified selon EAL-2, FIPS 140-2, NIST-SP800-131A, NSA Suite B Support, Section 508 VPAT et TAA Compliant.
Un autre avantage d'une infrastructure purement logicielle est qu'elle permet d'identifier et de combler les failles de sécurité de manière largement automatisée.
Les listes de contrôle de sécurité dans le langage de description lisible par machine XCCDF (Extensible Configuration Checklist Description Format) servent notamment à cela. Cela permet d'implémenter facilement des guides de sécurité, appelés Security Technical Implementation Guides (STIGs).
Les outils d'évaluation automatisés peuvent être utilisés par les STIG pour identifier les failles de sécurité. Dans la pratique, le temps nécessaire à cet effet se réduit, selon les cas, de neuf à douze mois à quelques minutes.
Si le logiciel d'infrastructure comprend en outre des fonctions de réparation automobile, il peut rétablir de manière autonome l'état correct des systèmes de production.
Les disques auto-chiffrables permettent en outre le chiffrement des données au repos ("Data at Rest Encryption"), c'est-à-dire celles qui ne sont pas actuellement utilisées pour le traitement des services et des applications.
Soyons honnêtes : même le meilleur logiciel d'infrastructure ne peut pas garantir une protection à 100 % contre les attaques. Il doit donc permettre aux clients existants de profiter facilement du savoir-faire des fournisseurs de sécurité informatique établis et offrir des possibilités de connexion via des interfaces de programmation (API) ouvertes.
Qu'ils soient grands ou petits, les clients existants qui travaillent sur l'avenir de leur environnement SAP ont l'occasion unique de minimiser les risques de sécurité dès le début, et non plus après coup comme c'était le cas auparavant.