Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

DevOps : Comment accélérer le « Fast IT » sans sacrifier la sécurité

octobre 2016 par Kevin Bocek, Vice President of Security Strategy & Threat Intelligence chez Venafi

En début d’année, une étude Gartner révélait que 60% des entreprises mettent déjà en pratique les principes du DevOps ou le feront prochainement. Ces acteurs adoptent l’informatique bimodale — s’en remettant à la fois à un processus informatique (lent) classique et à de nouvelles méthodes qui écourtent les délais de commercialisation et perfectionnent en permanence leurs technologies métier. Le DevOps, l’une des nouvelles philosophies les plus en vogue, accélère la fourniture de services informatiques pour soutenir l’innovation et le développement de nouvelles fonctionnalités.

Il est incontestable que le DevOps accélère le déploiement et favorise l’évolution des technologies métier, tout en offrant de nombreux avantages tels que :

 ? des temps de réaction très courts, permettant de prendre plus rapidement en compte les variations du marché ou les impératifs des clients. Les entreprises qui ont adapté la méthodologie DevOps ont amélioré de 20 % leurs délais de mise sur le marché.

 ? une satisfaction accrue des clients, due par la fréquence des actualisations produits, réalisées à partir des retours utilisateurs.

 ? une meilleure efficacité opérationnelle grâce à l’automatisation, se traduisant par un taux d’adoption du DevOps supérieur à 60 % chez les entreprises.

Pourtant, comme pour toute nouvelle technologie, les bénéfices ne sont pas exempts de risques. En fait, près de 80% des DSI sont préoccupés par une approche DevOps qui complique la donne puisqu’elle permet de dissocier beaucoup plus difficilement ce qui est digne de confiance de ce qui ne l’est pas. Il n’est pas rare que les équipes DevOps, soucieuses de maximiser la vitesse de déploiement de ces services, négligent la sécurité. Cette omission peut être lourde de conséquences, ne serait-ce qu’en fuites de données, pannes applicatives et audits infructueux.

Intéressons-nous par exemple à la façon dont, aujourd’hui, la lourdeur des processus de sécurité handicape le DevOps. Les clés cryptographiques et certificats numériques constituent les fondements de la confiance et de la confidentialité des données. Ces mêmes fondements, à l’origine de la croissance explosive de l’Internet dans les années 1990, nous permettent aujourd’hui de ne pas douter de nos transactions sur Internet. Depuis quelque temps, les clés cryptographiques et certificats numériques ont été élargis au cloud et à l’Internet des objets (IdO).

Clés et certificats ouvrent des communications cryptées, en mode privé, et nous indiquent qu’un site web est digne de confiance via le protocole HTTPS (Hypertext Transfer Protocol Secure). Sans eux, n’importe quel site web pourrait se faire passer pour votre banque, votre boutique en ligne préférée ou votre prestataire cloud. Ils sont rompus à la connexion des applications, administrateurs et clouds via SSH (Secure Shell). Les clés et certificats numériques autorisent l’exécution d’une signature de code sur les terminaux iOS et Android, les systèmes d’exploitation Windows et OS X et même les avions Boeing et Airbus.

Pour autant, le mécanisme d’émission et de déploiement des clés et certificats est, depuis toujours, lent et complexe – c’est-à-dire tout le contraire des ambitions et objectifs du DevOps. L’obtention de certificats numériques dignes de confiance peut prendre des jours, et non les quelques secondes escomptées par un environnement DevOps automatisé et parfaitement orchestré.

Les équipes DevOps n’hésitent pas à contourner ce problème. Dans certains cas, elles se servent de certificats non fiables ou non autorisés, tels que ceux proposés librement par Let’s Encrypt ou GoDaddy. Dans d’autres, elles se passent tout simplement de certificats. Quelle que soit l’approche adoptée, celle-ci complique la détection des menaces et, en l’absence de chiffrage HTTPS, les données ne sont pas à l’abri des pirates. A contrario, si le protocole HTTPS est utilisé, les systèmes de sécurité ont toutes les peines du monde à inspecter le trafic crypté en vue d’y déceler des menaces et attaques, ce qui ajoute encore à la confusion.

La communauté Open Source, à l’instar du Lemur de l’équipe en charge de la sécurité et des opérations Netflix, a trouvé des moyens de faciliter l’utilisation de clés et de certificats par les équipes DevOps. Mais jusqu’à présent, ces tentatives visant à améliorer la sécurité des systèmes DevOps n’ont fait que créer de nouveaux angles morts.

La question reste donc entière : Comment les entreprises peuvent-elles recueillir les fruits d’une démarche DevOps sans s’exposer elles-mêmes à d’autres risques en matière de sécurité ? Pour résoudre ce problème, les équipes de sécurité doivent raisonner différemment – à nous d’intégrer la sécurité au DevOps en privilégiant rapidité et facilité. Tout comme en Formule 1 où les ingénieurs donnent aux pilotes les moyens de repousser sans cesse les limites, les équipes de sécurité doivent faire preuve de créativité pour permettre au DevOps de mettre les gaz, sans compromettre la sécurité.

Voici quelques meilleures pratiques éprouvées en matière de clés et de certificats, qui aideront les équipes DevOps à faire preuve de célérité sans renoncer pour autant à la sécurité :

Automatisation : misez sur la rapidité et la simplicité

Les entreprises devraient mettre des procédures en place pour automatiser la création et la distribution de clés et certificats utilisables avec les protocoles HTTPS et SSH, afin que les équipes DevOps n’aient pas à le faire. Dotez ces dernières d’une API simple d’emploi, utilisable à toutes les sauces. Cette approche permet aux professionnels de la sécurité informatique d’éviter les kludges et autres verrues en matière de clés et de certificats (autrement dit, de procéder à une remise à plat), en préservant la sécurité des données et applications.

Maximisez la visibilité afin d’éviter des pannes liées à des certificats

La satisfaction des clients nécessite des efforts constants ; une simple interruption de service et vous vous exposez à voir dégringoler la note attribuée par la clientèle. Le non-renouvellement de certificats avant expiration ou des erreurs de configuration (comme dans le cas des pannes de service Microsoft Azure) peuvent se révéler onéreux. Des défaillances sur des applications utilisant le protocole HTTPS risquent d’entraîner des temps morts, pouvant atteindre 1 million de dollars l’heure d’immobilisation, s’il s’agit de gros volumes de services. Afin d’éviter des pannes inutiles, assurez-vous d’être en mesure de localiser tous vos certificats applicatifs.

Innovez : utilisez un catalogue de recettes

Avec des applications informatiques « lentes », il faut compter 4 heures 30 environ pour assurer l’allocation manuelle de chaque certificat. Or, les équipes DevOps auront peut-être à diffuser plusieurs dizaines, voire centaines de certificats en quelques secondes. Il est possible de créer des « recettes » (recipes) – des collections d’automatismes transitant par des API – pour orchestrer l’ensemble des étapes indispensables à l’utilisation de clés et certificats. Des catalogues de recettes exploitables dans tous les environnements de développement et d’orchestration sont indispensables pour accélérer et faciliter l’allocation de clés et de certificats, et préserver la compatibilité et la mobilité entre clouds. Vos équipes DevOps ne devraient jamais avoir à choisir entre agilité et sécurité. En implémentant des contrôles et automatismes pour les clés et certificats, vous ferez en sorte que vos processus DevOps évoluent au rythme de votre entreprise, sans sacrifier la sécurité.


Voir les articles précédents

    

Voir les articles suivants