La sécurité du cloud est devenue de plus en plus complexe ces derniers temps. Les fournisseurs de cloud utilisent des dizaines de milliers d'API, les systèmes d'orchestration de conteneurs sont de plus en plus nombreux et complexes, et de plus en plus de plateformes et de services entrent dans le cercle du cloud natif. De plus, chacun de ces composants représente un risque de sécurité potentiel pour les organisations. Et c'est vous, en tant que client, qui êtes responsable de la configuration et de la sécurité de ces composants. Il n'est donc pas surprenant que Gartner prédit, « jusqu'en 2025 « 99 % des défaillances de sécurité du cloud seront la faute du client. » ¹

Pour examiner cette complexité, nous avons eu le plaisir d'accueillir Dan Hubbard, PDG de Lacework, fournisseur de sécurité cloud, pour prendre la parole lors de la toute première conférence mondiale virtuelle de PagerDuty, le Summit, en septembre. Dan a donné son point de vue sur le casse-tête de la sécurité cloud et a évoqué le « modèle d'irresponsabilité partagée ».

« Malheureusement, dans de nombreuses entreprises, on voit des DevOps pointer du doigt la sécurité et dire : « Oh, cette sécurité. Ils nous ralentissent toujours avec ces processus de sécurité lourds. » Et les responsables de la sécurité disent : « Oh, DevOps. Ils évoluent tellement vite. Ils ne font que nous rendre peu sûrs », explique Dan.

En réalité, a-t-il expliqué, il est possible d'opérer dans le cloud à la fois rapidement et en toute sécurité. Les conflits entre DevOps et sécurité sont souvent futiles, et l'irresponsabilité n'a pas à se produire dans vos pratiques de sécurité dans le cloud. Au contraire, à mesure que les clients deviennent de plus en plus responsables de la sécurité de leur environnement cloud, il est impératif que les équipes DevOps et de sécurité trouvent de meilleures façons de travailler ensemble.

Les quatre principes du conflit de sécurité dans le cloud

Dan a expliqué comment le modèle d’irresponsabilité partagée s’articule autour de quatre facteurs clés :

1. Architecture et infrastructure

Si l'architecture de sécurité ne s'aligne pas sur l'infrastructure cloud, les équipes DevOps peuvent être frustrées par des produits de sécurité cloud qui ne correspondent pas à leurs pratiques. C'est pourquoi nous avons besoin de modèles de responsabilité organisationnelle, a expliqué Dan.

La collaboration et la communication entre DevOps et la sécurité sont essentielles pour que la responsabilité de gérer une faille de sécurité soit clairement définie. « Des problèmes de rejet de responsabilité, de désalignement et de gouvernance se produisent ici », a-t-il déclaré, ce qui peut être un problème critique.

2. Outillage et réglage

Les entreprises consacrent beaucoup de temps à la mise en place des outils, mais elles commettent souvent des erreurs. « Nous constatons assez souvent que DevOps et la sécurité fonctionnent à partir de deux sources et plans de données différents », explique Dan.

Idéalement, les équipes devraient disposer d'outils communs. Il n'est pas nécessaire qu'ils soient exactement les mêmes, mais ils doivent provenir du même plan de données. De cette façon, le développement et la sécurité peuvent s'entendre sur la personne qui ajuste les performances et peuvent également partager les modèles de risque. Les deux équipes peuvent donc comprendre la cause et l'effet des opérations de sécurité-DevOps.

3. Comprendre les changements dans les données

L’époque où les changements se faisaient une fois par mois dans un centre de données privé est révolue : le cloud est beaucoup plus dynamique. « Aujourd’hui, tout se passe en temps quasi réel, la sécurité doit donc suivre le rythme, et il faut comprendre les risques associés au changement », a déclaré Dan.

La clé est donc que les équipes DevOps et de sécurité corrèlent ces changements et ces risques en temps quasi réel. Elles doivent travailler ensemble et éviter de se pointer du doigt pour déterminer si un changement d’infrastructure de DevOps augmente le risque de faille de sécurité. Et si une interruption de service se produit, elles doivent travailler ensemble pour comprendre si elle est due à un événement de sécurité ou à une erreur de développeur.

4. Flux de travail et automatisation

Un autre facteur clé qui contribue au modèle d’irresponsabilité partagée est non seulement de savoir quels flux de travail créer et exécuter, mais aussi quels flux de travail automatiser. « La capacité à fusionner et à créer des flux de travail communs grâce à l’automatisation va être très importante », a déclaré Dan. « Il y a beaucoup de choses répétables qui sont en fait automatisables. »

Il peut s’agir, par exemple, d’automatiser la désactivation de l’authentification multifacteur ou d’automatiser une réponse lorsque les employés ouvrent des buckets sans les privilèges appropriés. Et avec l’automatisation, les équipes DevOps et de sécurité doivent s’entendre sur l’infrastructure sous-jacente et la posture de sécurité nécessaire pour permettre cela.

Activer la collaboration avec PagerDuty

Pour permettre aux développeurs et aux équipes de sécurité d'harmoniser leur réponse aux incidents, Dentelle et PagerDuty a récemment annoncé un partenariat d'intégration. En peu de temps, a déclaré Dan, environ 40 % des clients de Lacework utilisent l'intégration de PagerDuty .

L'intégration informera les équipes DevOps et de sécurité comment l'incident doit être corrigé. 'Nous vous donnons un maximum d'informations pour vous permettre de répondre', a-t-il précisé. 'L'intégration est un très bon moyen de récupérer les informations que nous collectons, puis de les transmettre directement à PagerDuty pour garantir que la bonne personne obtient les bonnes données pour clôturer ou trier le ticket directement.'

Vous souhaitez regarder la session complète ? Inscrivez-vous ici gratuitement pour le regarder à la demande, ainsi que d'autres sessions partenaires et clients.

¹ Source : Smarter With Gartner, Inc., Le cloud est-il sécurisé ?, 10 octobre 2019, https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/.