L’incendie qui a frappé OVH en mars dernier a eu l’effet d’une bombe dans le secteur de l’IT. Quelques heures ont suffi pour rendre inaccessibles des millions de sites et d’applications, parfois durant plusieurs jours. Certaines structures ont perdu définitivement leurs données… Cet événement a été exceptionnel par sa nature et sa portée. De mémoire, aucune catastrophe de cette ampleur ne s’était jusqu’alors produite. Elle a jeté, sans raison fondée, un voile de discrédit sur la sécurité des données, des sites et des applications hébergées sur le cloud.
À tort. Ma démarche ne consiste pas ici à interroger la stratégie d’OVH et sa gestion des risques. Mais plutôt de partir de mon expérience dans l’univers no-code pour rassurer toutes les entreprises utilisatrices d’applications cloud. La responsabilité des éditeurs et le respect de certaines bonnes pratiques contribuent directement à la sécurité des données et des applications no code (ou low code) disponibles en SaaS. En voici une grille de lecture synthétique pour vous aider à avancer et faire les choix les plus éclairés.
Assurer la sécurité de l’hébergement : haute disponibilité et sauvegarde
L’incendie chez OVH a rappelé la réalité du risque « infrastructure », infrastructure sans laquelle il n’est plus possible de délivrer le service au client. Pour faire les bons choix en matière d’hébergement, il est nécessaire de distinguer deux critères : celui de la haute disponibilité et celui de la sauvegarde.
Concernant le premier, l’éditeur doit optimiser la Durée Maximale d’Interruption Admissible d’activité (DMIA ou RTO pour Recovery Time Objective) qu’il est en mesure de proposer aux clients de son application. Plusieurs choix permettent cette optimisation, certains sont du ressort de l’hébergeur, d’autres de l’infogérant et d’autres encore de l’éditeur.
C’est le cas du Plan de Reprise d’Activité (PRA) qui définit les procédures et les moyens mis en place pour assurer une DMIA en cas de désastre important.
D’un éditeur à l’autre, les délais varient de plusieurs jours… à quelques heures !
Les modalités d’exécution d’un PRA constituent également un critère important :certains réalisent leur bascule de serveur de façon automatisée, d’autres non. L’approche manuelle du PRA présente l’avantage de laisser aux équipes le temps d’identifier l’origine et la gravité du problème, parfois de le résoudre en marche avant. Une bascule de serveur n’est pas irréversible, mais un retour en arrière est complexe à réaliser et peut dégrader encore l’origine des dysfonctionnements constatés. Le PRA reste une solution plutôt dédiée aux incidents graves.
Les procédures de sauvegarde sont un autre point d’attention. Elles ne sont pas la garantie d’une reprise d’activité après une défaillance humaine ou technique, mais elles permettent à l’application de revenir en arrière, au point que l’éditeur et le client ont fixé ensemble pour restaurer les données. Les pratiques diffèrent grandement aussi chez les
éditeurs de ce point de vue. Nombreux sont ceux qui pratiquent des sauvegardes quotidiennes. Une fréquence plus soutenue, réalisée par tranche d’une heure, limite grandement les pertes de données.
Les clients ont tout intérêt à prendre conseil auprès de professionnels du logiciel, seuls capables d’ajuster au plus près les mesures de sécurité des données et les choix d’hébergement en fonction de leur besoin d’accessibilité et de la sensibilité des données exploitée et des types d’application utilisés.
Assurer la sécurité dans l’application
Autre risque bien connu qui pèse sur les applications : celui des cyberattaques. Celles-ci ne visent plus tant le réseau ou l’infrastructure, généralement bien protégés à l’égard de ce type de risque que les applications elles-mêmes : la sécurité applicative, qui consiste justement à protéger les données par des développements au cœur du code, est un enjeu fort pour les entreprises.
Pour cela, l’éditeur d’une solution no code doit apporter à ses clients des garanties sur la sécurisation de sa plateforme, même si aucune obligation réglementaire n’existe sur le sujet. Pour autant, différents cabinets d’expertise proposent la réalisation d’un audit, complété par des tests réguliers d’intrusion. Cette évaluation externe et neutre est indispensable pour mettre au clair la robustesse de l’application, évaluer ses vulnérabilités potentielles et mettre en place des améliorations, dans une dynamique de progrès continu. Les cyber risques évoluent en permanence !
Les éditeurs qui ont recours à une démarche d’audit assurée par des spécialistes et de tests d’intrusion témoignent d’une véritable « culture sécurité ». Combien d’entre eux se prêtent à l’exercice et avec quelle régularité ?
Choisir avec vigilance son infogérance
Rares sont les éditeurs à s’attarder sur le choix de l’infogérance de leurs serveurs. C’est pourtant un paramètre clé en matière de sécurité : l’infogérant a en charge le maintien en conditions opérationnelles des infrastructures de ses clients. C’est lui qui conseille et met en place l’architecture globale du SI et le niveau de service qu’il peut atteindre. L’infogérant installe, configure, sécurise les serveurs, et ce au fil du temps, 24 heures sur 24.
Avec les trois premiers critères énumérés plus haut, c’est une pièce essentielle de la confiance qu’un client peut avoir en un éditeur. Aucune de ces composantes de sécurité ne doit être négligée : la juste combinaison de ces éléments seule permet d’atteindre le niveau d’excellence en matière de sécurité attendue par les clients.
Sensibiliser les équipes métier à la sécurité dans la construction de leurs applications
Il est un dernier paramètre trop souvent négligé : l’humain. Le comportement des individus est bien identifié comme un point de faiblesse en matière de risque naturel. C’est aussi une faille possible en matière d’application no code puisque c’est l’utilisateur lui-même qui la construit.
L’éditeur maîtrise parfaitement sa plateforme, ses équipes sont rompues à la sécurité et à ses exigences. L’utilisateur final, client de la plateforme, travaille lui dans une direction métier. Ses connaissances en matière de sécurité sont limitées : sans le vouloir, souvent sans le savoir, il est susceptible de créer des brèches dans la gestion des droits d’accès ou des failles dans le paramétrage initial. C’est une proie facile pour les spécialistes du phishing.
Ses collègues de la DSI le sont beaucoup moins : de nouvelles complémentarités entre les services sont à trouver aux étapes clés de la construction d’une application métier. Cela doit passer par la mise en place d’une coordination optimale entre les métiers et la DSI, un transfert de compétences entre les équipes, des validations croisées. Des modules de formation, assurés par l’éditeur, peuvent efficacement compléter le dispositif. C’est la garantie d’un time-to-market rapide de l’application, dans le respect des critères de sécurité.
Serveurs d’hébergement : un ou plusieurs sites géographiques ?
Qu’il s’agisse de basculer de serveur dans le cadre d’un PRA ou de réaliser des sauvegardes, le choix de l’implantation géographique des serveurs est un point critique. Si la réalisation de PRA synchrone suppose d’avoir recours à un même hébergeur pour la qualité du réseau proposé, la diversification des serveurs sur plusieurs sites, plusieurs data centers, permet de se prémunir à l’égard d’un spectre plus large de risques. L’incendie d’OVH l’a bien montré, accélérant la prise de conscience chez de nombreux éditeurs.
Plus que jamais il est nécessaire de mobiliser différents serveurs, répartis dans des data centers géographiquement distants. Sachant qu’en aucun cas, le PRA ne doit être une option !
Par Nicolas Thery, Fondateur et CTO de DAMAaaS
