Les meilleures pratiques de sécurité DevOps ou comment Uber a perdu 57 millions de comptes d'utilisateurs

Meilleures pratiques de sécurité DevOps

La sécurité est d’une importance capitale pour DevOps. Selon Business Insider, plus de 1,2 milliard de comptes d’utilisateurs ont été violés aux États-Unis l’année dernière. En conséquence, Facebook tente toujours de redorer son blason, et Google a dû fermer son réseau social Google Plus. Ces exemples devraient suffire à inciter une entreprise, quelle qu’elle soit, à mettre en place et à suivre les meilleures pratiques de sécurité DevOps afin d’éviter un fiasco.

Pourquoi les échecs de la sécurité DevOps se produisent-ils ? Qui devrait en être responsable ? Quelles sont les réponses à ces défis de sécurité DevOps ? Et surtout : Pourquoi devriez-vous vous en préoccuper ? Nous répondons à ces questions et à d’autres questions liées à la sécurité DevOps pour vous aider à fournir des applications inviolables à vos clients.

Divulgation : ce billet ne traitera pas de DevSecOps, car DevSecOps est un mot à la mode qui n’a aucun sens (même sans page dédiée sur Wikipédia) et qui signifie simplement DevOps sécurisé. Ce n’est pas comme si vous pouviez venir voir votre PDG et lui demander : “ Patron, quel type d’Ops souhaitez-vous ? DevOps, DevSecOps ou SecDevOps ?” La réponse est toujours DevOps, et toujours sécurisée.

Pourquoi la sécurité DevOps est-elle un problème ?

Récapitulons rapidement ce qu’est DevOps - juste pour être sûrs que nous sommes sur la même longueur d’onde. La définition de DevOps donnée par le géant du logiciel Amazon semble assez crédible :

Ou, en termes simples, DevOps est l’état d’esprit collaboratif d’une équipe de projet et les outils permettant d’automatiser le développement, les tests, la livraison et la maintenance des produits numériques.

Agile - Rapide

DevOps fait partie d’Agile, un cadre de développement logiciel extrêmement populaire qui favorise des itérations de développement rapides et fréquentes et met fortement l’accent sur la collaboration entre les membres de l’équipe. Certaines entreprises livrent plusieurs mises à jour de leurs produits numériques sur une base hebdomadaire, d’autres quotidiennement. Quoi qu’il en soit, un tel rythme ne laisse pas beaucoup de temps pour des tests rigoureux. Et bien sûr, les vulnérabilités finissent par se glisser dans ces projets.

Sécurité - Lenteur ?

On pense souvent à tort que des contrôles de sécurité plus nombreux entraînent des cycles de livraison plus longs et, par conséquent, des délais non respectés. Bien que personne ne souhaite des retards supplémentaires dans ses projets, les dommages qu’une seule faille de sécurité peut causer peuvent être dévastateurs pour une entreprise qui sacrifie la sécurité au nom de l’agilité.

En 2012, Path, une application sociale pour iOS, a connu un immense succès jusqu’à ce que quelqu’un découvre que l’application téléchargeait les contacts des utilisateurs vers ses serveurs via un protocole non sécurisé et sans autorisation. En conséquence, l’application Path n’existe plus, malgré une base de deux millions d’utilisateurs et tout le battage médiatique autour d’un réseau social mobile longtemps attendu, réservé aux amis proches et à la famille.

Open-source & Conteneurs - Effrayant

Pour accélérer le développement, les équipes DevOps peuvent s’appuyer sur des solutions open-source qui ne font souvent pas l’objet de tests de sécurité. Même une simple bibliothèque ou un composant de serveur provenant d’une source non vérifiée peut provoquer une cascade d’erreurs et finalement rendre votre service ou votre produit indisponible pour les clients.

Les conteneurs représentent un autre élément indispensable d’une configuration DevOps moderne, en plus du code et des outils open-source. Les développeurs, les administrateurs système et les ingénieurs d’assurance qualité utilisent les conteneurs pour rendre presque instantanément un projet disponible sur une nouvelle machine, ou pour revenir à une version de développement antérieure d’un produit. Cependant, les conteneurs n’offrent qu’une faible visibilité sur leur contenu et sont souvent analysés de manière inadéquate. Un rapport de Threat Stack a révélé que 94 % des personnes interrogées considéraient les conteneurs comme une menace pour la sécurité.

Stratégies pour sécuriser le DevOps

Obtenir l’adhésion de tous

Les entreprises gèrent DevOps différemment. Certaines confient à leurs développeurs de logiciels toutes les opérations de post-codage, c’est-à-dire la création, le test et le déploiement des applications. D’autres ont des équipes de développement et d’exploitation séparées. Mais pour un environnement DevOps sécurisé, la meilleure pratique consiste à obtenir l’adhésion de tous, quel que soit le groupe auquel ils appartiennent. En fait, les entreprises qui ont réussi à mettre en place des politiques de sécurité dans le cadre de DevOps ont commencé par le sommet - la direction - tout en impliquant activement leurs services juridiques et informatiques dans la conversation.

Élaborer une politique de sécurité concise

L’intérêt d’une politique de sécurité est de permettre à votre équipe de réagir rapidement en cas d’urgence. La règle empirique consiste à préparer un PSI (plan écrit de sécurité de l’information) et un PIRD (plan d’intervention en cas d’incident sur les données) qui soient suffisamment brefs et clairs pour permettre de prendre des mesures immédiates en cas de besoin. Un bon point de départ serait l’énumération des faiblesses communes (Common Weakness Enumeration), une liste de faiblesses communes en matière de sécurité des logiciels élaborée par la communauté. Une politique digne de ce nom devrait également mettre l’accent sur des modèles de codage sûrs qui ne laissent aucune place aux exploits.

Formez votre personnel

Bien entendu, tous les participants au projet doivent connaître les politiques et les exigences en matière de sécurité, en fonction de leur rôle. Par exemple, les ingénieurs logiciels doivent éviter de conserver des informations d’identification dans le code source pour des raisons de commodité, les membres de l’équipe d’assurance qualité n’ont pas nécessairement besoin d’accéder à l’environnement de développement, et les administrateurs système doivent configurer correctement les pare-feu, entre autres choses. Veillez donc à ce que votre processus d’intégration couvre les bases de la sécurité.

Automatiser les processus et outils de sécurité DevOps

Le DevOps a toujours été axé sur l’automatisation. La mise à disposition rapide de produits logiciels nécessite des pipelines d’intégration continue (CI) et de livraison continue (CD) correctement configurés - lorsque les nouvelles versions des produits sont compilées, vérifiées et contrôlées automatiquement. Il est essentiel d’inclure la vérification automatique de la sécurité dans ces processus DevOps.

Une chaîne d’outils DevOps habilement déployée vous aide à repérer le code vulnérable avant qu’il n’atteigne l’environnement de production. Une telle chaîne d’outils surveillera également votre produit tout au long des cycles de test, d’intégration, de déploiement et de publication, vous donnant ainsi des indications sur les menaces potentielles pour la sécurité.

Prenez le contrôle de la gestion des accès privilégiés

Selon une étude de Beyond Trust, près de la moitié des atteintes à la sécurité résultent d’une mauvaise gestion des accès privilégiés (PAM). Il ne s’agit pas d’un intrus extérieur, mais plutôt des membres de votre équipe qui, avec de bonnes intentions, ont plus de droits d’accès qu’ils ne le devraient ou qui gèrent mal ces droits. Les trois mesures que les entreprises peuvent prendre pour maîtriser la PAM sont les suivantes :

• Faire le point sur les comptes et les actifs privilégiés

Un environnement DevOps peut parfois être un véritable fouillis. Encore faut-il aller au bout de la démarche et dénicher tous les comptes d’utilisateurs privilégiés et tous les endroits auxquels ils ont accès.

• Interdisez les comptes partagés et les mots de passe codés en dur

Les ingénieurs DevOps peuvent parfois coder en dur des identifiants dans un outil qu’ils utilisent par commodité ou utiliser des comptes partagés, ce qui complique l’audit.

• Mettre en œuvre le principe du moindre privilège

Par exemple, un compte avec l’outil qui recueille des métriques sur les bogues dans un environnement de test n’a probablement pas besoin d’accéder aux environnements de production et de développement.

Mettre en place un programme de lutte contre les vulnérabilités

La gestion des vulnérabilités peut vous aider à sécuriser vos produits et vos clients en examinant vos actifs numériques du point de vue d’un pirate informatique, puis en effectuant des tests de pénétration (ou simplement des tests d’intrusion). Les entreprises utilisent deux variantes principales de tests d’intrusion :

Les tests de pénétration externes

Lorsqu’une entreprise recherche des vulnérabilités dans son périmètre de défense externe : mauvaises configurations, noms d’utilisateur et mots de passe par défaut, logiciels non corrigés, ports ouverts, etc.

Test de pénétration interne

Lorsqu’une entreprise souhaite vérifier l’ampleur des dégâts qu’un pirate ou un employé malhonnête peut causer s’il a déjà accès au système. Peuvent-ils accéder aux parties critiques de votre produit, y compris aux données des clients ?

Découper l’environnement DevOps en couches sécurisées

La logique de l’application et la base de données ne doivent pas nécessairement se trouver sur le même serveur. En fait, du point de vue de la sécurité, il est préférable d’exécuter des serveurs distincts pour chacun et de regrouper ces éléments et d’autres actifs DevOps dans des unités logiques qui ne se font pas confiance par défaut. Ajoutez un serveur de saut avec authentification multifactorielle et autorisation d’accès adaptative pour connecter les unités, puis appliquez des sessions - et le tour est joué. Désormais, si un pirate s’introduit dans un segment, au moins les autres resteront sécurisés.

Votre DevOps est-il sécurisé comme celui d’Uber ou de Tesla ?

Si vous vendez un service ou un produit numérique, la sécurité DevOps doit être votre priorité absolue. À cet égard, aucune entreprise ne fait exception. Des entreprises comme Tesla et Uber semblent être suffisamment grandes et matures pour être la proie de failles de sécurité. Pourtant, la première a laissé des pirates utiliser ses serveurs pour extraire une crypto-monnaie, et la seconde a exposé les informations personnelles d’environ 57 millions de clients et de chauffeurs. Dans les deux cas, la raison en est une mauvaise configuration de DevOps.

La bonne nouvelle est qu’aujourd’hui, on peut facilement trouver de nombreuses sociétés de conseil et de développement qui peuvent aider les entreprises à sécuriser leurs processus DevOps, même si une entreprise ne fait que commencer à mettre en œuvre DevOps. Contactez-nous dès aujourd’hui