La sécurité peine encore à se fondre dans les DevOps
Son intégration transparente et automatisée restant difficile, elle est perçue comme un frein. Et le recours toujours croissant à des briques logicielles tierces n’aide pas forcément.
L’intégration de la sécurité dans les approches DevOps apparaît difficile. C’est du moins ce que souligne Gartner dans une récente note à destination de ses clients. De fait, si les entreprises adoptent DevOps pour gagner en agilité, tant les professionnels de la sécurité (77 %) que ceux des opérations informatiques (81 %) estiment que les équipes et politiques de sécurité ralentissent l’entité informatique. Pour autant, selon le cabinet, « les équipes DevOps comprennent que la sécurité et la conformité sont nécessaires ».
Pour satisfaire ces besoins multiples et pour l’heure encore antinomiques, Gartner identifie une piste : « incorporer automatiquement des contrôles de sécurité sans configuration manuelle, tout au long du cycle ». Mais cette automatisation ne peut pas se faire sans la bonne volonté des fournisseurs de solutions de sécurité. Dans cette perspective, le cabinet recommande aux entreprises « d’obliger » leurs fournisseurs à « adapter entièrement leurs services de plateforme aux API et exposer 100 % des fonctionnalités via des API ». Il ajoute à cela de « proposer un support explicite » pour les environnements DevOps les plus populaires tels que Chef ou Puppet, mais également pour les conteneurs et les systèmes de gestion et d’orchestration de ceux-ci.
En termes de contrôles de sécurité, Gartner recommande d’abord l’intégration du contrôle des accès basé sur les rôles en lien avec une solution d’IAM : « à mesure que les services nouveaux et mis à jour évoluent dans le processus DevSecOps itératif, les auditeurs et les architectes de la sécurité voudront avoir une séparation claire entre qui peut faire quoi, où et quand, en termes de développement et déploiement de services ». Cela implique donc de définir et d’attribuer les rôles liés au développement et à la production : « dans l’idéal, personne n’a le droit de toucher directement à l’environnement actif, sauf via des scripts et des API ». Mais le cabinet va plus loin, en suggérant d’exiger « que l’équipe en charge des produits soit responsable et puisse faire l’objet d’audits pour les changements qu’elle apporte aux produits, sur la base de la confiance et de la vérification ».
Au-delà du contrôle des accès, Gartner se penche sur la sécurité des données et recommande de « former les développeurs aux meilleures pratiques de codage sécurisé et à la manière de rédiger du code résistant qui nettoie les contributions et bloque les schémas d’attaque courants, tels que les dépassements de mémoire tampon, l’injection SQL et les scripts sur des sites ». Le cabinet suggère en outre de mettre en place un outil « simple d’évaluation des modèles de menace et de risque » dans le cadre du processus de planification et de conception. Et surtout de prévoir « d’anonymiser ou synthétiser les données utilisées dans le développement à des fins de test ».
Plus loin, Gartner recommande de tester et d’analyser le code personnalisé pour rechercher d’éventuelles vulnérabilités et, dans la mesure du possible, de se reposer pour cela sur l’automatisation, ainsi que sur des analyses différenciées pour éviter d’avoir à repasser en revue l’intégralité du code à chaque modification. Mais cela tout acceptant l’impossibilité de n’avoir aucune vulnérabilité pour concentrer les efforts sur celles qui sont potentiellement les plus critiques. Et l’analyse ne doit pas se limiter au code personnalisé : le code source ouvert mérite également une surveillance étroite pour éviter d’intégrer des vulnérabilités connues.
Cette logique d’analyse et de recherche de vulnérabilités s’étend naturellement aux systèmes, Gartner suggérant de « structurer le processus DevOps de sorte à analyser automatiquement le contenu de toutes les images système » ou encore à éviter la présence de « modules superflus ». Sans omettre de suivre les pratiques de référence en matière de sécurisation des systèmes et de l’infrastructure.
La liste de conseils du cabinet ne s’arrête pas là, soulignant l’ampleur de la tâche si c’est nécessaire. Gartner recommande ainsi de traiter « scripts, recettes, modèles et couches comme du code sensible » parce que « si l’infrastructure devient du code, les principes de codage sécurisé doivent alors s’appliquer » à tous ces éléments et « les référentiels contenant le code qui contrôle l’infrastructure doivent aussi être sécurisés ». Ne serait-ce que pour éviter qu’un « script mal rédigé ou mal géré ne puisse amplifier une erreur si elle arrive en production ». Et cela touche aussi aux fichiers de configuration, même si le cabinet reconnaît qu’il « faut du temps pour déployer de telles pratiques de sorte à englober l’infrastructure entière ». Mais selon lui, « ce point est essentiel pour s’assurer que les auditeurs internes et externes donnent leur accord à l’expansion de DevOps à travers le domaine de l’infrastructure et des applications.
Gartner suggère par ailleurs de mesurer et surveiller l’intégrité des systèmes et la validité de la configuration à l’occasion de changements, de verrouiller l’infrastructure et les services de production, ou encore de miser sur des listes de blanche pour mieux maîtriser les systèmes de production, « y compris les implémentations basées sur des conteneurs ». Et cela parce qu’il convient de partir du principe « que la compromission est inévitable ». La surveillance constante et étendue du périmètre s’avère donc essentielle à la détection et à la remédiation rapides.
Pas de doute, face à ces multiples recommandations, le chemin doit paraître bien long à beaucoup. En fait, selon Gartner, moins de 10 % des entreprises en 2016 intègrent l’analyse automatisée des configurations et des vulnérabilités dans les composants de code. Mais plus de 70 % des initiatives DevOps devraient avoir passé le cap d’ici à trois ans. Et elles sont aussi aujourd’hui moins de 10 % à avoir incorporé des tests de sécurité applicative sur le code personnalisé, et moins de 5 % à avoir implémenté contrôle de versions et gestion rigoureuse des outils d’administration de l’infrastructure. Mais ces chiffres devraient passer à 50 % pour le premier et à 60 % pour le second, d’ici 2019.
