C’est un fait : les APIs et l’API Management sous-tendent les projets de transformation. Passé le développement d’APIs pour un usage interne, la question de leur ouverture et de leur mise à disposition en externe se pose pour les organisations.
Mais aussi populaire soit-elle, la publication d’APIs sur Internet doit être sécurisée et leur accessibilité réduite au minimum requis. Olivier Arzalier, Directeur Cybersécurité, en charge du SOC de CGI, livre quatre conseils à même de garantir la sécurité de vos APIs.
Threat Modeling ou comment identifier les menaces et vulnérabilités
Dans une approche DevSecOps, la réalisation d’ateliers de Threat Modeling lors de chaque sprint est fondamentale, afin de sécuriser le design en lui-même ainsi que le code qui en découlera. Ces ateliers basés sur l’idéation consistent à faire réfléchir ensemble les différents membres des équipes de développement et de sécurité pour identifier des menaces et vulnérabilités tant au niveau du design que du code. Cela permet de découvrir des vulnérabilités aux prémices du projet et de manière itérative. La compréhension des exigences de sécurité est mieux maitrisée, le produit livré de meilleure qualité, tout cela grâce à une correction au plus tôt. Le tout en préservant les méthodologies habituelles des équipes.
Intégrer la sécurité « by design » dès le départ
En matière de sécurité «by design», un bon point de départ consiste à faciliter l’écriture du code produit et de rendre ainsi difficile l’accès à certaines fonctionnalités qui pourraient être dangereuses. Ensuite, il est important de mettre en place des systèmes de templating et rendre l’usage des frameworks obligatoire pour construire des contrôles proactifs. Enfin, empêcher les injections de code malveillants, utiliser des en-têtes sécurisées, proposer une mire d’authentification simple et sécurisée font partie des pratiques à adopter. La bonne nouvelle, c’est que le retour sur investissement peut être important. En revanche, cela implique une très forte collaboration entre les équipes de développement et de sécurité ainsi que des compétences avérées en développement sécurisé, design et architecture.
Du self-service pour plus d’autonomie
L’outillage du self-service permet de renforcer la sécurité en gardant la philosophie DevOps. La sécurité doit être disponible, pratique, transparente et efficace. Pour atteindre cet objectif, il existe sur le marché des outils pour l’Intégration et la Livraison Continue (CI/CD). Ceux-ci permettent de récupérer les résultats simplement, le développeur pouvant également vérifier les résultats et les valider ou non. Cela fait partie d’une nouvelle étape du cycle de vie de développement qui inclue désormais la sécurité. La mise à disposition de cet ensemble d’outils tend à rendre autonome et à responsabiliser le développeur.
La sécurité itérative, une amélioration continue
Le DevOps et la livraison continue réduisent les risques liés à des changements en mode "big bang". Cela permet de tester progressivement la capacité des équipes à s’adapter au changement à chaque livraison. La confiance augmente et les processus s’affinent. L’automatisation permet la rationalisation des processus, y compris la gestion de la configuration. Les tests et le déploiement sont plus facilement reproductibles, fiables et permettent des audits plus réguliers. Les changements plus progressifs sont considérés comme plus sécurisés par nature. Les erreurs sont plus faciles à détecter car les modifications incrémentielles par petits lots sont plus simples à examiner et à comprendre.
Le cycle DevSecOps permet de rester proactif en matière de sécurité, et apporte une différenciation stratégique ainsi que plus de transparence sur la sécurité. Les équipes sont par ailleurs plus impliquées dans les tâches et les processus. Cette approche tire parti de l’automatisation pour déployer des applications mieux sécurisées.