Développement d'applications dans des environnements Cloud : aspects clés en matière de sécurité

Lignes directrices

Les pratiques et technologies de développement modernes (CI/CD, conteneurs, serverless, etc.) nécessitent une approche intégrée avec des capacités offrant une protection connectée tout au long du cycle de vie de l'application, ainsi que la garantie que les services cloud respectent les meilleures pratiques de sécurité tout en permettant aux développeurs de travailler, avec de multiples et exhaustifs contrôles de sécurité pour se protéger contre les vulnérabilités, les fuites, les attaques de malware et les violations de conformité réglementaire.
Voici quelques-uns des aspects essentiels à prendre en compte :

• Sécurité dans la pipeline : C'est une étape préalable et fondamentale pour garantir la sécurité. Il est recommandé de réaliser une analyse continue des logs et des images de conteneurs, y compris celles situées dans des instances Open Source, ainsi que des scans exhaustifs de la pipeline CI/CD.
• Protection des applications : L'automatisation de la sécurité doit permettre de protéger les processus de développement contre les principales menaces pour les applications sur serveurs, APIs, conteneurs, plateformes serverless, etc.
• Protection du système d'exploitation de l'hôte. En général, tous les conteneurs partagent un même noyau, il sera donc essentiel de le protéger contre les vulnérabilités et les attaques au niveau de l'hôte.
• Sécurité du stockage. Le système doit analyser tout type de fichier à la recherche de malware et intégrer la sécurité dans des workflows personnalisés avec un support pour tous types de plateformes de stockage cloud.
• Protection des conteneurs. Dans ce domaine également, il est recommandé d'avoir un niveau maximal de contrôle sur les événements et les notifications pour répondre aux exigences de sécurité et de conformité réglementaire, y compris une surveillance exhaustive du trafic dans les conteneurs.
• Sécurité dans les processus DevOps. L'intégration d'APIs spécifiques permet d'améliorer les cycles de développement et de réduire les délais de livraison, mais c'est aussi un allié pour réduire les points de contact et le facteur humain.
• Sécurité du réseau : Il est vrai que cette section inclut de nombreux éléments pour la protection du trafic réseau : pare-feux, systèmes de détection d'intrusions, surveillance, gestion des actifs et des composants... L'objectif est de réduire au maximum la surface d'attaque.
• Sécurité Open Source. Un autre aspect fondamental, surtout si l'on considère qu'une grande partie du code en circulation est open source. Il sera nécessaire d'avoir une visibilité sur les vulnérabilités des environnements open source, y compris la gestion des risques de licence.

Codage sécurisé : Principaux risques selon l'OWASP.

Le OWASP Top 10 est un document de sensibilisation standard pour les développeurs et la sécurité des applications web, reconnu mondialement par les développeurs comme la première étape vers une codification plus sécurisée.

Les entreprises doivent adopter ce document et commencer le processus de garantir que leurs applications web minimisent ces risques. Utiliser le OWASP Top 10 est peut-être la première étape la plus efficace pour changer la culture de développement de logiciels de l'organisation. Voici chacun de ces risques :

• A01. Violation du contrôle d'accès. Permet aux attaquants de compromettre les données en obtenant un accès privilégié ou en s'appropriant des comptes. 94 % des applications testées présentaient ce type de problème.
• A02. Défaillances cryptographiques. Ce sont des défaillances liées au chiffrement qui conduisent souvent à l'exposition de données confidentielles ou à la prise de contrôle des systèmes. Elles sont souvent plus un symptôme qu'une cause profonde.
• A03. Injection. Cette catégorie (injections SQL, injections JavaScript) fait référence à l'insertion de code malveillant dans l'application et présente le deuxième plus grand nombre de cas. Le Cross-site Scripting fait désormais partie de cette catégorie.
• A04. Conception non sécurisée. Une nouvelle catégorie par rapport aux rapports précédents qui fait référence aux risques liés aux défauts de conception. OWASP recommande des éléments tels que la modélisation des menaces, les modèles et les architectures de référence.
• A05. Erreurs de configuration. De plus en plus courantes en raison de l'utilisation du cloud comme environnement de développement et du développement avec des images de conteneurs. 90% des applications testées par l'OWASP ont révélé un type d'erreur de ce genre.
• A06. Défaillances des composants. Un problème connu, mais difficile à évaluer. Normalement, ces vulnérabilités proviennent de l'utilisation de cadres ou de bibliothèques obsolètes qui sont faciles à exploiter.
• A07. Échecs d'identification et d'authentification. Une mauvaise gestion des sessions, des mots de passe faibles ou l'absence de limitation du taux de tentatives de connexion continuent de poser problème, mais sont moins critiques en raison de la disponibilité croissante de cadres standardisés.
• A08. Défaillances d'intégrité des données et des logiciels. Une catégorie ajoutée dans le dernier rapport qui fait référence aux vulnérabilités dans les logiciels, les données critiques et les pipelines CI/CD.
• A09. Défaillances d'enregistrement et de surveillance. Les défaillances dans cette catégorie peuvent affecter la capacité de votre entreprise à détecter et à répondre aux éventuelles violations, car elles compliquent la visibilité, les alertes sur les incidents et l'analyse médico-légale.
• A10. Falsification des requêtes côté serveur. Ajouté dans le dernier rapport, c'est un problème relativement mesurable et surveillable. Il se produit lorsque les attaquants font en sorte que les serveurs effectuent des requêtes non autorisées.

Sécurité à chaque étape du processus

La définition de niveaux acceptables de sécurité et de confidentialité dès le début de chaque projet aide les équipes DevOps à comprendre les risques, à identifier et corriger les erreurs pendant le développement et à appliquer ces niveaux tout au long du projet.

1. Conception

Au cours de cette phase, il faudra aborder des questions fondamentales de sécurité et de confidentialité, en anticipant tous les vecteurs d'attaque et les vulnérabilités. La définition des niveaux acceptables de sécurité et de confidentialité au début d'un projet aide une équipe à comprendre les risques associés aux problèmes de sécurité, à corriger les failles de sécurité pendant le développement et à appliquer les niveaux adéquats de sécurité et de confidentialité tout au long du projet.

2. Mise en œuvre

Avant d'insérer le code dans le dépôt, il sera nécessaire de réaliser des révisions pour augmenter la qualité générale et réduire le risque d'erreurs. L'analyse du code source est un élément clé dans la révision de code statique pour trouver d'éventuelles vulnérabilités dans le code qui n'est pas en cours d'exécution. De même, il sera nécessaire de prévenir les attaques par injection en validant les entrées pour éviter que les données au format incorrect soient conservées dans la base de données ou déclenchent des erreurs dans d'autres composants. L'encodage des sorties fournit des défenses par niveaux pour augmenter la sécurité du système dans son ensemble.

Il sera également essentiel de séparer les données de production et de ne pas les utiliser pour le développement, les tests ou tout autre objectif différent de celui établi. Et, bien sûr, suivre d'autres bonnes pratiques telles que l'anonymisation pour tout le processus, ou éviter le stockage en cache de contenu confidentiel.

3. Vérification

Cette phase consiste à vérifier que le code respecte les principes de sécurité et de confidentialité établis lors des phases précédentes. Elle inclut, par exemple, la recherche et la correction des vulnérabilités dans les dépendances de l'application.

Une autre bonne pratique consiste à tester l'application en état opérationnel. Les tests dynamiques de sécurité des applications (DAST, pour son sigle en anglais) permettent de les analyser pendant leur exécution afin de rechercher des vulnérabilités telles que des dommages à la mémoire, des configurations de serveur non sécurisées, des attaques de script entre sites, des injections de code, etc. Les tests de vulnérabilités, quant à eux, consistent à induire une erreur en introduisant des données aléatoires ou mal formatées, ce qui aide à révéler d'éventuels problèmes de sécurité avant le passage en production.

Enfin, la révision de la surface d'attaque après avoir complété le code aidera à garantir que les changements dans la conception et l'implémentation ont été pris en compte, et que les nouveaux vecteurs d'attaque ont été examinés et atténués. Pour sa part, les tests de pénétration (ou pentesting) sont des attaques simulées pour trouver les vulnérabilités de sécurité et tous les systèmes qui pourraient avoir accès aux applications, à leur fonctionnalité et à leurs données.

DevSecOps : une nouvelle façon de concevoir le développement

Selon un rapport publié en 2020, 92 % des professionnels de l'informatique ne croient pas que leur organisation soit prête à protéger les services de cloud public. Cela se produit parce que cela ne dépend pas seulement de la sécurité en tant que partie de l'équipe de développeurs et d'opérateurs, mais aussi de l'infrastructure de sécurité elle-même.

DevSecOps est la pratique consistant à intégrer les tests de sécurité à chaque étape du processus de développement logiciel. Il comprend des outils et des processus qui favorisent la collaboration entre les développeurs, les spécialistes de la sécurité et les équipes d'opérations pour créer un logiciel à la fois efficace et sécurisé.

Les avantages sont multiples et parfaitement visibles : réduction du temps de livraison, détection précoce et automatique des vulnérabilités, développement de nouvelles fonctionnalités de manière sécurisée, amélioration de la collaboration et de la communication entre les équipes et garantie de conformité réglementaire, entre autres.

En définitive, aujourd'hui, le cloud est un espace privilégié pour créer des applications et des services, et des méthodes comme DevSecOps sont fondamentales pour le fonctionnement de l'infrastructure et la sécurité de la technologie dans les entreprises. Mais seule une stratégie intégrale mise en œuvre dès le début de chaque projet permettra d'accélérer les délais, de réduire les coûts et de garantir la sécurité dans le développement.