Contexte : la décentralisation des systèmes d’information

Commençons par un peu de vulgarisation sur les nouvelles technologies web : jusqu’en 2015, les systèmes d’information centralisés s’ouvraient partiellement et sous contrôle à des terminaux distants utilisateurs.

La révolution numérique actuelle, la généralisation des services cloud, la multiplication des données hétérogènes provenant de sources diverses (personnes, appareils, objets connectés …), la digitalisation des services accessibles en 1 clic depuis son PC comme de son smartphone … font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

Tout cela repose sur des architectures nouvelles et ouvertes, qui combinent le plus souvent :

• Des bases de données (hétérogènes)
• Des fournisseurs de données alimentant ces bases (formulaires en lignes, réseaux sociaux, appareils mobiles, objets connectés et capteurs …)
• Des réseaux de communication pour les faire transiter vers un ou plusieurs systèmes centraux distants (wifi, Lora, Sigfox, fibre …)
• Des middlewares, qui récupèrent, agrègent et redistribuent de ces données sur un ou plusieurs canaux (application mobile, siteweb, intranet …)
• Le tout via des échanges réalisés automatiquement par des APIs, des interfaces de programmation applicative par lesquelles un logiciel « fournisseur » offre des services à d’autres logiciels « consommateurs »

Les failles de sécurité peuvent se trouver à tous niveaux, et il n’est pas dans l’ambition de cet article d’en faire un panorama exhaustif, mais de rappeler quelques pièges / règles pour garantir la sécurité et la confidentialité des données dans ce nouveau paysage.

10 Pièges et conseils pour assurer la sécurité des données de vos applications

Néanmoins, voici quelques pièges à éviter pour s’assurer pleinement de la sécurité des données dans ces nouvelles architectures :

1. Attention aux solutions applicatives cloud publiques : les solutions applicatives en mode Saas sont pratiques et permettent de gagner du temps (clouds Amazon, Google, Azur …) et proposent des services à haute valeur ajoutée pour déployer rapidement et efficacement ses solutions. Attention cependant à ces services pour des données personnelles identifiées comme sensibles ou critiques, compte-tenu de l’hébergement externalisé par des entreprises étrangères soumises à d’autres règlementation (ex : les US et le cloud act : https://www.usine-digitale.fr/article/le-cloud-act-un-texte-securitaire-americain-qui-inquiete.N800995  …).  Conseil : plus on traite de données critiques, plus il est (vivement) conseillé de monter ses architectures sur un cloud privé, dans un serveur dédié, hébergé en France sans redondance à l’étranger (dans un data center correctement sécurisé, évidemment).
2. Attention aux solutions cloud de code hébergé (type Gitlab) : quand on souhaite protéger son code source (qui est la base de la PI d’une startup web …), mieux vaut monter son repository Git sur un serveur « internalisé »
3. Sanctuariser ses données : les bases de données doivent être hébergées sur des serveurs différents des applicatifs, avec un accès contrôlé (ex :, accès restreint aux API, et toujours de manière authentifiée, etc)
4. Mettre en place les sécurités réseau : ex : pare-feu, réduction du nombre de ports, restriction par adresse IP, authentification par mots de passe forts (> 13 caractères), sécuriser les communications sensibles (ex VPN)
5. Mettre en place des solutions de monitoring : exemple serveur Syslog pour enregistrer les logs + solutions IDS pour l’analyse
6. Ne jamais laisser passer en clair des informations critiques, dont les mots de passe (exposition par les API, envoi par mail, etc)
7. Sécuriser ses APIs : https://www.riskinsight-wavestone.com/2017/06/securite-api/
8. Choisir ses outils de développement en prenant en compte la sécurité : confronterles bénéfices / risques de chaque solution en fonction des besoins et des failles de sécurité connues.
9. Ne pas oublier les postes utilisateurs et développement dans les mises en place de règles de sécurité
10. Commencer un projet par une analyse des risques (ex : Ebios de l’ANSSI : https://www.ssi.gouv.fr/administration/management-du-risque/la-methode-ebios-risk-manager)