Vos recommandations de sécurité cloud pour 2021

Vos recommandations de sécurité cloud pour 2021 (en supposant que 2020 finisse un jour)

2020. Voilà, C’EST arrivé.

En matière de sécurité cloud, 2020 a été comme verser du carburant de fusée sur un feu d’essence : nos plans à trois ans se sont transformés en exécutions de trois mois. Et comme tout bon feu de cheminée, cela apporte des avantages, des opportunités, mais aussi une part de danger. Personnellement, la pandémie a mis fin à la plupart de mes déplacements et m’a en réalité permis d’accomplir davantage de travail auprès d’une clientèle plus diversifiée. Alors que nous commençons tous à faire comme si nous allions pouvoir lever le pied pour profiter des fêtes (cela ne se passe jamais vraiment ainsi), je me suis dit que le moment était bien choisi pour rassembler quelques-unes des tendances et des leçons que j’ai retenues et qui peuvent nous servir à tous pour la planification de 2021.

Comme l’a dit le grand auteur Terry Pratchett : « Faites du feu pour un homme, et il aura chaud une journée. Mettez le feu à un homme, et il aura chaud pour le reste de sa vie. » 2021 consiste à maîtriser les feux pour alimenter la croissance sans réduire votre maison en cendres.

J’ai rassemblé quelques recommandations de sécurité cloud qui répondent à bon nombre des défaillances systémiques courantes que j’ai observées au cours de projets, mais qu’il est aussi raisonnable d’aborder de façon progressive. Nous avons accéléré l’adoption du cloud de manière assez spectaculaire en 2020, ce qui signifie que de nombreuses organisations ont avancé vite sans avoir le temps de bâtir des fondations solides. C’est tout à fait normal, mais il ne faut pas trop attendre avant de consolider l’ensemble. Chaque point ci-dessous correspond aux causes profondes de défaillances très médiatisées.

Commencez par corriger la gouvernance du cloud

En 2020, j’ai travaillé avec des dizaines d’organisations et échangé avec des centaines d’autres. Une gouvernance déficiente est de loin le problème le plus constant que j’observe dans le cloud. Il se décline de plusieurs façons. Je rencontre le plus souvent ces deux extrêmes : soit l’organisation n’impose aucune restriction aux développeurs, soit la sécurité verrouille tout dans des modèles standards peu adaptés au cloud. Je vous suggère de trouver un juste milieu : exigez une validation de la sécurité pour tout nouveau fournisseur et service, et donnez à la sécurité le pouvoir de dire « non », mais uniquement lorsqu’elle peut justifier son raisonnement. Imposez ensuite à la sécurité d’élaborer des politiques et des procédures cloud-native qui reflètent les pratiques cloud-native, plutôt que de transposer tout son outillage de sécurité de datacenter, d’une lenteur exaspérante et contre-productif. Réunissez tout le monde autour de la même table au sein d’un Cloud Center of Excellence. Une très grande partie des défaillances de sécurité du cloud public que nous observons trouvent leur origine dans un échec de gouvernance plutôt que dans un échec technologique.

À propos de gouvernance, le moment est idéal pour adopter le concept de « security champion »

Les security champions ne sont pas des BISO (business information security officers) ; ce sont des développeurs ou des administrateurs locaux au sein des équipes projet qui reçoivent une formation complémentaire, profitent de pizzas offertes (vous pouvez les faire livrer tant que les quarantaines COVID durent) pendant les réunions de comité, et servent d’intermédiaire entre un projet et une équipe de sécurité. Considérez-les comme un point de contact et un relais.

Améliorez la visibilité sur la sécurité de votre cloud

Un autre problème courant de gouvernance consiste à exclure la sécurité des comptes cloud, à l’exception de quelques journaux. Corrigez cela en 2021 en fournissant à la sécurité des outils et un accès en lecture seule à chaque déploiement cloud (y compris les environnements de dev/test/sandbox), puis un accès en lecture/écriture d’urgence pour la réponse aux incidents. En contrepartie, la sécurité définit des politiques afin de n’appliquer elle-même des modifications d’urgence que dans les cas les plus extrêmes, lorsqu’elle ne peut pas joindre l’équipe de déploiement pour assurer la remédiation. La visibilité doit porter sur l’état de configuration continu des déploiements (CSPM) ainsi que sur les flux d’événements et de journaux des modifications en temps réel (CDR).

Si vous n’utilisez pas plusieurs comptes pour limiter le rayon d’impact des attaques, commencez dès maintenant

Je ne parle pas seulement de comptes de production et hors production, mais de plusieurs comptes par pile applicative. Pourquoi ? Parce que l’identité est le nouveau périmètre et que plus vous entassez d’éléments dans quelques grands environnements, plus il est difficile de mettre en œuvre des contrôles de moindre privilège. Difficile au point d’en être impossible. En 2021, vous pouvez commencer par une règle « nouveau projet, nouveau compte ». Je masque ici beaucoup de complexité, principalement du côté réseau lorsqu’il faut interconnecter des piles applicatives, mais ces problèmes se résolvent dès lors que vous adoptez des modèles cloud-native, et les bénéfices sont considérables.

Faites progresser votre réponse aux incidents cloud-native

Je constate que la réponse aux incidents accuse un retard sur deux plans. Premièrement, il s’avère que les modèles de journalisation par défaut figurant dans la documentation des fournisseurs cloud ne sont généralement pas optimaux, avec de longs délais entre la survenue d’un événement et l’apparition d’une notification. C’est le plus visible chez AWS, mais tous les fournisseurs peinent sur ce point. Si vous vous appuyez sur des connexions SIEM standards, vous offrez peut-être de larges fenêtres aux attaquants. Deuxièmement, le processus de réponse lui-même n’est ni correctement défini ni correctement outillé. Répondre manuellement à des attaques automatisées est perdu d’avance. En 2021, formez votre équipe de réponse aux incidents, optimisez vos alertes basées sur les événements et commencez à réduire les fenêtres de réponse grâce à l’acheminement des incidents et à l’automatisation. Et oui, je recommande mon propre produit, mais nous ne l’avons pas conçu pour le plaisir. Vous pouvez d’ailleurs en faire une bonne partie vous-même avec de l’open source et du code si vous n’êtes pas prêt pour un outillage commercial.

Passez en revue de fond en comble votre implémentation IAM/RBAC et resserrez-la

Réduisez les privilèges inutiles et ajoutez autant de restrictions de ressources que possible. Activez chacun des outils d’analyse et d’alerte liés à l’identité que propose votre fournisseur cloud. Commencez à utiliser les attributs et les politiques conditionnelles. Soyons clairs : chacune des grandes défaillances de sécurité du cloud public en 2020 impliquait une défaillance IAM – identifiants perdus, privilèges trop nombreux, ou absence de MFA ou de restrictions conditionnelles pour contrôler le périmètre IAM. S’il vous faut une préoccupation qui vous empêche de dormir en 2021, c’est celle-là.

La gouvernance. Des services partagés fondamentaux. Quelques améliorations tactiques. L’époque où chaque année de cloud computing semblait exiger des programmes et des outils entièrement nouveaux est révolue. 2021 consiste à maîtriser les fondamentaux, mais en les faisant évoluer pour gagner en évolutivité, en efficacité et en coût. Nous en savons beaucoup plus qu’il y a quelques années seulement sur les pratiques qui fonctionnent le mieux, et l’essentiel est de rechercher les occasions de moderniser et d’abandonner les éléments hérités qui ne fonctionnent vraiment pas très bien.