Dev
Les chaînes DevOps achoppent sur l’émission des certificats…
Par Laurent Delattre, publié le 18 décembre 2019
Clés de chiffrement et certificats numériques sont indissociables du développement d’applications. Or l’obtention et la gestion des certificats restent des sujets complexes qui viennent mettre des grains de sable dans les rouages des chaînes DevOps.
Aujourd’hui, il n’y a pas de stockage sécurisé, de communications sécurisées, de déploiements d’application, de containers sécurisés ni même d’appels d’API sans clés de chiffrement et émissions de certificats.
Profitant de la dernière conférence DevOps Enterprise Summit 2019 (DOES19) à Las Vegas, le spécialiste de la protection des identités machine Venafi s’est livré à un petit sondage auprès des professionnels présents.
Selon leur étude Venafi, 75 % des professionnels DevOps considèrent que les politiques d’émission de certificats mises en place dans leur entreprise ralentissent le développement.
Pas étonnant, dès lors, de découvrir que plus d’un tiers (39 %) considèrent que les développeurs devraient être capables de contourner les politiques pour répondre aux SLA.
Pire encore, moins de la moitié (48 %) des personnes interrogées estiment que les développeurs de leur entreprise emploient systématiquement les méthodes et les canaux approuvés par l’équipe de sécurité pour obtenir les certificats servant d’identités machine. Autrement dit, 52% des développeurs tricheraient avec les règles en place, et donc au moins en théorie avec la sécurité de l’entreprise, pour parvenir à produire leurs applications en temps et en heure.
Pas étonnant non plus que 55% des entreprises aient connu un incident lié à un certificat en 2019.
Une dure réalité
Dans un monde DevOps où tout se veut automatisé, de tels chiffres peuvent surprendre et paraissent certainement anormaux. Mais ils trahissent plusieurs réalités qui démontrent à quel point des efforts sont encore à consentir dans la gestion des certificats numériques pour obtenir des chaînes DevOps aussi fluides qu’on peut les espérer.
Pour Venafi, le premier problème vient des mécanismes d’attribution et d’installation des certificats publics. Dans la plupart des entreprises, les processus sont loin d’être suffisamment automatisés et s’appuient sur un mécanisme de tickets certes rigoureux mais lent, administratif et lourd. Les équipes DevOps soumettent un ticket via un système comme ServiceNow, attendent ensuite que l’équipe gérant la sécurité et les clés émettent le certificat, puis téléchargent le certificat et l’installent sur leurs propres serveurs avant de le transmettre à l’équipe Infrastructure qui l’installera sur le Load Balancer frontal.
En outre, il n’existe souvent aucune gestion centrale qui permettrait par exemple d’alerter les « application owners » lorsque les certificats expirent. Souvent, ce sont les équipes infrastructures qui s’en aperçoivent en premier et trop tard, sans savoir ensuite à quelles équipes de développement ils doivent s’adresser.
Une telle lourdeur génère de la frustration à tous les étages mais surtout ralentit les temps de développements. Et lorsque les développeurs se sentent ralentis, ils ont une tendance naturelle à chercher une voie de contournement qu’ils pensent souvent temporaire et qui se retrouve ad-vitam déployée. Ils utilisent des certificats émis par des autorités de certification (CA) non autorisées ainsi que des certificats autosignés ou génériques sans que les équipes de sécurité n’aient la moindre visibilité.
Replacer la sécurité au cœur de DevOps
Pour Senafi, le problème n’est pas uniquement lié à ces comportements. Alors qu’il existe de nombreux outils pour automatiser à peu près tout et n’importe quoi (pousser du code en test ou en prod, tester du code, vérifier la présence de vulnérabilités, etc.), les processus d’émission et gestion de certificats manquent d’unité et ressemblent bien trop à un assemblage de solutions mixant OpenSSL, ACME, Amazon Certificate Manager, Ansible Vault, Pivotal CredHub, etc.
En outre, la diversité applicative d’aujourd’hui (containers, VM, microservices, infra serverless sans oublier l’historique existant) ne vient pas simplifier la problématique d’une gestion unifiée des certificats.
« Les professionnels de la sécurité n’ont malheureusement pas conscience des risques que les processus DevOps font courir à leur entreprise » alerte Kevin Bocek, vice-président du département de sécurité et d’analyse des menaces de Venafi. « En définitive, les équipes de sécurité doivent simplifier l’utilisation des identités machine par les développeurs : il doit être plus simple et rapide de les protéger que de contourner la politique. Dans le cas contraire, ces problèmes continueront de connaître une croissance exponentielle. Les organisations qui recourent aux processus DevOps ont besoin de visibilité, d’intelligence et d’automatisation pour protéger leurs identités de machine. »
Bien sûr, Senafi prêche ici pour sa paroisse. Mais son étude vient à point nommé, à l’heure des bonnes résolutions de nouvelle année, pour inviter les DSI à se pencher sur cette problématique des certificats qui est au cœur finalement de la nécessaire évolution du DevOps vers le DevSecOps.
___________________
Source:
Venafi : DevOps Environments Still Prone to Certificate-Related Outages
