La mise en œuvre d’une approche de sécurité de type shift-left dans le cycle de développement peut susciter des réticences chez certains développeurs et responsables IT. La raison ? Une asphyxie et un alourdissement des workflows. Mais aujourd’hui, face à la menace cyber, les entreprises doivent non seulement moderniser leurs technologies, mais elles doivent aussi faire évoluer leur culture et leur philosophie. Mes ingénieurs logiciels doivent envisager la sécurité comme faisant partie intégrante du processus de développement. Comme un élément indissociable.
L’infrastructure à clés publiques ou PKI (Public Key Infrastructure) représente actuellement l’un des outils d’authentification de sécurité les plus fiables. Mais comment rationaliser une infrastructure PKI et l’intégrer au processus de développement sans perturber la production ? Les frameworks, comme le DevOps, visent la mise en œuvre de logiciels fiables dans des délais records. Dans ce guide à l’attention des responsables IT, nous expliquerons comment utiliser et automatiser la PKI pour DevOps.
Qu’est-ce que la PKI ?
La PKI est un cryptosystème asymétrique à doubles clés. Elle confère aux systèmes IT des niveaux élevés de chiffrement des données, de confidentialité des informations et de gestion des identités grâce à l’utilisation de certificats et de signatures numériques.
La PKI est essentiellement connue pour son utilisation dans les échanges de messages chiffrés (c’est également l’exemple le plus simple à expliquer). Les messages sont alors chiffrés à l’aide d’une clé publique, puis déchiffrés à l’aide d’une clé privée.
Si la clé publique peut être accessible à tous, la clé privée n’appartient généralement qu’à une seule entité. Mais, avant de pouvoir ouvrir ou déchiffrer un message, le destinataire doit valider l’identité de l’expéditeur.
C’est là qu’intervient la PKI. En s’appuyant sur l’authentification par certificat numérique, elle vérifie l’identité du détenteur de la clé publique. En plus d’un rôle préventif antifraude, l’ensemble du processus garantit la confidentialité et la sécurité des messages. Alors en quoi ce processus peut-il intéresser les équipes de développement de logiciels ? Pourquoi l’implémenter dans votre pipeline DevOps, et comment ?
PKI et développement de logiciels
Derrière son apparente simplicité, le concept de PKI n’en reste pas moins suffisamment flexible et puissant pour s’appliquer à de nombreux cas d’utilisation propres au monde du logiciel. Si la validation de certificats (SSL/TLS) peut être utile pour les développements web, la PKI permet aux développeurs web d’implémenter facilement une authentification multifacteur.
Cette fonctionnalité permet d’élaborer des processus d’identification sophistiqués, sans avoir à stocker les identifiants utilisateurs dans des bases de données classiques ou sur fichiers. La PKI peut, bien entendu, servir à sécuriser l’accès au code source quand l’accès aux dépôts et fichiers est restreint à des identités spécifiques. Autre point : avec la signature de code, la PKI peut également aider les développeurs à gérer le chiffrement et le déchiffrement du code source et de leurs logiciels.
L’importance de signer son code
Pour les développeurs, la principale difficulté réside dans l’intégration de la PKI au processus de développement, qui doit être la plus transparente possible. Il y a deux façons d’utiliser DevOps pour la PKI. La méthodologie DevOps peut être utilisée pour intégrer les validations qui s’appuient sur la PKI dans les logiciels et les services d’entreprise. L’autre possibilité (ou possibilité complémentaire) consiste à automatiser le déploiement et la configuration d’une PKI à l’aide du DevOps. Naturellement, la réalisation de l’une ou l’autre de ces opérations nécessite d’utiliser les bons outils.
Étapes et outils pour le déploiement et l’automatisation d’une PKI avec le DevOps
Face à l’actuelle popularité des PKI, leur émergence pourrait sembler récente. Et pourtant, l’apparition des infrastructures à clés publiques remonte aux années 1990. Côté DevOps, la méthodologie a été conceptualisée en 2008 et visait à remplacer les anciennes approches du pipeline de développement, comme l’agilité. Les deux techniques ont fait l’objet d’essais, de tests et d’ajustements minutieux au fil des ans.
Aujourd’hui, les développeurs disposent de nombreux outils et instruments pour mettre efficacement en œuvre une PKI avec le DevOps. Dans cette partie de notre guide, nous vous présentons concrètement la marche à suivre et les outils à utiliser.
Choisir votre autorité de certification
Lorsque vous établissez votre stratégie de déploiement PKI-DevOps, assurez-vous de solliciter une autorité de certification (AC) sûre, digne de confiance et fiable… comme GlobalSign. GlobalSign est un fournisseur mono-source de certificats privés et publics basé dans le cloud.
Aujourd’hui, les développeurs disposent de nombreux outils et instruments pour mettre efficacement en œuvre une PKI avec le DevOps. Dans cette partie de notre guide, nous vous présentons concrètement la marche à suivre et les outils à utiliser.
L’entreprise fournit par ailleurs le stockage des clés hors ligne, une autorité d’horodatage, des services de révocation et une infrastructure pour la gestion des certificats. GlobalSign propose également une solution de déploiement automatisé des certificats. Accompagnée de l’API REST et EST de GlobalSign, cette solution représente l’outil idéal pour une intégration DevOps.
Les développeurs à la recherche d’une alternative open-source pourront se tourner vers EJBCA (Enterprise Java Beans Certificate Authority), solution de gestion de PKI évolutive. Ils pourront l’utiliser avec des services de déploiement automatisé et d’orchestration de conteneurs, comme Kubernetes, pour délivrer en toute transparence des certificats vers des progiciels, microservices et conteneurs.
Le code source EJBCA est disponible selon les termes de la licence publique générale limitée GNU. Publié en 2001, il a fédéré autour de lui une vaste communauté en ligne et fait de nombreux adeptes. Toute l’aide possible est donc facilement accessible pour les développeurs. Cela dit, n’oubliez pas que votre autorité de certification constitue le socle de votre système PKI. Il faut donc faire les bons choix. Votre AC doit en effet s’aligner sur vos besoins en matière de développement et de sécurité.
Choisir votre outil d’automatisation
Une fois que vous avez décidé de la façon dont vous allez générer et gérer votre système de PKI, reste à choisir comment le déployer et l’intégrer. Ici encore, GlobalSign propose des solutions d’automatisation des inscriptions et d’intégration d’API pour faciliter vos déploiements.
Toutefois, si vous n’êtes pas prêt à vous lancer dans cette aventure, d’autres solutions sont envisageables. Les outils open-source comme Certbot permettent aux développeurs de générer et gérer automatiquement leurs SSL/TLS. Nous préconisons toutefois l’usage de solutions d’automatisation IT comme Ansible qui rendent la configuration et la distribution automatisées de certificats PKI plus fiables.
Ansible convient aux environnements complexes d’une certaine envergure comprenant un grand nombre de serveurs et/ou de conteneurs. Pour les projets plus modestes, un service comme Jenkins peut tout à fait convenir. Jenkins est couramment utilisé dans les frameworks d’intégration et de déploiement continus (CI/CD) pour automatiser les builds, les tests et les déploiements de projets.
Il est possible, à ce titre, de se l’approprier et l’utiliser pour les déploiements DevOps. Il pourra alors être utilisé pour configurer et délivrer automatiquement des certificats, et pour effectuer des validations. Tout comme EJBCA, Jenkins est un projet open-source basé sur Java. Cet aspect permet d’envisager l’interfaçage et la personnalisation avec flexibilité.
Petite précision, vous n’avez pas à choisir entre Ansible et Jenkins : les deux services peuvent fonctionner côte à côte. Ansible pourra être utilisé pour l’orchestration, et Jenkins pour la configuration et l’optimisation. Vous utiliserez donc Ansible comme solution de déploiement pour votre « PKI pour DevOps » et Jenkins comme outil « DevOps pour PKI ».
Sécuriser les déploiements PKI et DevOps
Une fois que les équipes IT ont déterminé la façon dont elles souhaitent mettre en œuvre et automatiser leur système de PKI, elles doivent s’assurer de la sécurité du processus. Malgré toutes les garanties de sécurité apportées par la PKI, cette dernière présente encore quelques vulnérabilités. C’est notamment le cas des messages chiffrés via une infrastructure à clés publiques qui peuvent être déchiffrés et stockés en clair sur le serveur d’un fournisseur, d’un expéditeur ou d’un destinataire
Les organisations doivent vérifier la fiabilité du fournisseur ou de l’autorité de certification qu’elles sollicitent et poser les questions qui dérangent. Ainsi, si votre fournisseur déchiffre les messages et les données, vous lui demanderez s’il archive ou s’il stocke les informations dans un fichier ou dans une base de données ? Effectue-t-il un nettoyage après le déchiffrement ? L’archive contenant les données déchiffrées est-elle sécurisée ? Pour résumer, vous ne devez pas vous contenter d’évaluer votre AC potentielle sur les seuls critères de compatibilité à votre solution DevOps. La sécurité compte aussi.
Imaginez que des personnes mal intentionnées trouvent le moyen de s’infiltrer dans une machine abritant du texte stocké en clair. Elles pourraient contourner la sécurité de la PKI en copiant ce texte et en le déchiffrant. Il faut donc ajouter une couche de sécurité supplémentaire à votre DevOps et votre PKI. C’est aux responsables IT de veiller à ce que tous les serveurs soient sécurisés. La mise en œuvre d’une solution de détection et de réponse étendues (XDR), par exemple, leur permet de traquer les menaces et les violations.
L’utilisation d’un outil de gestion des secrets comme HashiCorp Vault (proposé via la plateforme Atlas de GlobalSign) et le gestionnaire de secrets AWS permet d’ajouter une couche de sécurité supplémentaire. On peut, sur ces deux plateformes cloud, stocker et sécuriser les clés de chiffrement, les certificats et les informations d’identification. Les développeurs peuvent ainsi s’assurer que les clés et les certificats ne sont ni exposés ni enregistrés par les API lors du déchiffrement. Ils veillent également à ce que les certificats soient émis et déployés dans les bons conteneurs, les bonnes machines et entités.
PKI pour DevOps et automatisation de la sécurité
L’époque où l’on stockait les secrets dans des fichiers de journaux, des bases de données et des variables environnementales est révolue, tout comme le temps où on les cachait dans des attributs codés en dur. Les approches comme le DevOps augmentent la quantité de développements et de déploiements applicatifs. Les anciennes techniques de validation d’identité et de gestion des secrets sont par conséquent devenues obsolètes. En cause, leur inefficacité, mais aussi leur manque de souplesse. Ces techniques ne conviennent tout simplement pas aux déploiements DevOps à grande échelle.
Pour garantir la sécurité tant du processus que des applications en développement, les équipes doivent créer une batterie de tests automatisés au tout début du développement. Ces tests peuvent être configurés pour s’effectuer au fur et à mesure du développement de l’application via des processus automatisés.
Certains de ces tests peuvent comprendre des tests fonctionnels garantissant le bon fonctionnement des connexions et des validations d’identifiants. Vous pouvez également tester les vulnérabilités (mauvaises configurations, expositions des plateformes et chiffrements SSL insuffisants) susceptibles de se répercuter sur la sécurité des applications. Les développeurs peuvent aussi exécuter des tests d’intrusion automatisés qui évaluent en permanence la sécurité du système d’exploitation et de l’application en cas d’attaque de tout type.
Malgré sa puissance comme outil de sécurité, la PKI n’offre pas de solution exhaustive pour les tests de sécurité et les cas d’usage. La sécurité doit être envisagée de manière globale par les développeurs. Et comme ces processus peuvent être automatisés, la création n’a pas à souffrir des opérations visant à sécuriser les développements et les déploiements applicatifs.
