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 potentiel pour la sécurité des 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 ait publié un rapport. 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, lors de la toute première conférence mondiale virtuelle de PagerDuty, le Summit, en septembre. Dans son analyse du casse-tête de la sécurité cloud, Dan a évoqué le « modèle d'irresponsabilité partagée ».

« Malheureusement, dans beaucoup d'entreprises, on voit des DevOps pointer du doigt la sécurité et dire : 'Oh, cette sécurité ! Ils nous ralentissent constamment avec ces processus de sécurité lourds et contraignants.' Et les équipes de sécurité disent : 'Oh, DevOps ! Ils évoluent tellement vite qu'ils ne font que nous rendre vulnérables' », explique Dan.

En réalité, a-t-il expliqué, il est possible d'opérer dans le cloud avec rapidité et sécurité. Les conflits entre DevOps et sécurité sont souvent futiles, et l'irresponsabilité n'est pas une fatalité dans vos pratiques de sécurité cloud. Au contraire, à mesure que les clients assument une part croissante de la sécurité de leur environnement cloud, il est impératif que les équipes DevOps et sécurité trouvent de meilleures façons de collaborer.

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é n'est pas alignée avec l'infrastructure cloud, les équipes DevOps peuvent être frustrées par des produits de sécurité cloud inadaptés à 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 la gestion d'une faille de sécurité soit clairement définie. « Des accusations, des décalages et des problèmes de gouvernance peuvent survenir ici », a-t-il déclaré, ce qui peut être critique.

2. Outillage et réglage

Les organisations consacrent beaucoup de temps au processus d'outillage, mais des erreurs surviennent régulièrement. « Nous constatons 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 identiques, mais ils doivent provenir du même plan de données. Ainsi, les équipes de développement et de sécurité peuvent s'accorder sur l'optimisation des performances et partager des modèles de risque. Les deux équipes peuvent ainsi comprendre les causes et les effets des opérations sécurité-DevOps.

3. Comprendre les changements dans les données

L'époque où l'on effectuait des modifications une fois par mois dans un centre de données privé est révolue : le cloud est bien plus dynamique. « Désormais, tout se déroule en temps quasi réel, la sécurité doit donc s'adapter à ce rythme, et il est essentiel de comprendre les risques associés au changement », a déclaré Dan.

La clé est donc que les équipes DevOps et sécurité corrèlent ces changements et ces risques en temps quasi réel. Elles doivent collaborer et éviter de se chercher mutuellement des coupables pour déterminer si un changement d'infrastructure lié aux équipes DevOps augmente le risque de faille de sécurité. En cas d'interruption de service, elles doivent collaborer pour déterminer si elle est due à un incident de sécurité ou à une erreur de développement.

4. Flux de travail et automatisation

Un autre facteur clé contribuant au modèle d'irresponsabilité partagée réside non seulement dans la connaissance des flux de travail à créer et à exécuter, mais aussi dans la connaissance de ceux à automatiser. « La capacité à fusionner et à créer des flux de travail communs grâce à l'automatisation sera essentielle », a déclaré Dan. « De nombreuses tâches répétables sont automatisables. »

Par exemple, il peut s'agir d'automatiser la désactivation de l'authentification multifacteur ou la réponse automatique lorsque les employés ouvrent des buckets sans les privilèges appropriés. L'automatisation implique que les équipes DevOps et de sécurité doivent s'accorder sur l'infrastructure sous-jacente et la posture de sécurité nécessaire pour la mettre en œuvre.

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 Lacework a récemment annoncé un partenariat d'intégration. Dan a déclaré qu'en peu de temps, environ 40 % des clients de Lacework utilisent l'intégration PagerDuty .

L'intégration informera les équipes DevOps et de sécurité comment L'incident doit être résolu. « Nous vous fournissons un maximum d'informations pour vous permettre de réagir », a-t-il déclaré. « L'intégration est un excellent moyen de récupérer les informations que nous collectons et de les transmettre directement à PagerDuty afin de garantir que la bonne personne obtienne les données nécessaires pour clôturer ou trier le ticket directement. »

Intéressé à 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/.