Dérive de l’infrastructure cloud : le bon, le mauvais et le pire

Les erreurs de configuration de l’infrastructure sont la principale cause de violation de données dans le cloud. Elles sont souvent dues à la dérive de la configuration de l’infrastructure, c’est-à-dire à des changements qui surviennent dans un environnement cloud après son provisionnement. Si vous êtes responsable de la sécurité et de la conformité des environnements cloud, vous consacrez probablement beaucoup de temps à analyser les dérives de l’infrastructure et à y remédier.

Il est facile de penser que toute dérive est néfaste ou indésirable. Et ne vous y trompez pas : certaines sont vraiment mauvaises, voire catastrophiques ! Mais d’autres sont bénéfiques et souhaitées. Comprendre les différences entre le bon, le mauvais et le pire, et savoir les reconnaître, peut vous éviter, à vous et à votre équipe, bien des frustrations et une perte de temps.

Les bonnes dérives : pourquoi nous utilisons le cloud

L’infrastructure cloud est élastique et évolutive. Nous voulons que nos environnements cloud s’adaptent dynamiquement aux besoins de nos applications, seconde après seconde, sans intervention humaine. Fini le temps où il fallait planifier les capacités et préprovisionner les ressources dans les centres de données.

De nombreux changements souhaités de l’infrastructure cloud doivent se produire après le provisionnement. Les ressources cloud comme les groupes AWS Autoscaling et DynamoDB peuvent réagir à l’utilisation et au débit afin d’adapter dynamiquement l’infrastructure aux nouveaux besoins. Les applications peuvent créer de nouvelles ressources, comme des files d’attente SQS, des rubriques SNS ou des compartiments S3, pendant leur exécution. Les ALB connectés à un Elastic Container Service ou à AWS Fargate effectuent des opérations qui modifient la configuration de l’infrastructure.

Toute approche de la sécurité et de la conformité du cloud doit tenir compte de ces « bons » changements, surtout si vous souhaitez corriger automatiquement les dérives. Vous ne voulez pas que votre outil de sécurité entre en conflit avec l’automatisation de votre application. Bien sûr, vous devrez vous assurer que ces « bons » changements le sont réellement, mais ce sera le sujet d’un autre article.

Les mauvaises dérives : notre application est en panne !

La dérive de configuration est depuis longtemps un véritable fléau pour les équipes d’exploitation et d’infrastructure : elle provoque des interruptions de service et des échecs de déploiement. Elle survient lorsque l’environnement de production change sans que l’équipe d’exploitation en soit informée. Une règle de groupe de sécurité peut être supprimée, ou une politique IAM retirée. Une simple erreur de saisie dans la console AWS peut mettre une application entière à l’arrêt. Il faut alors déclencher une intervention d’urgence pour en trouver la cause. Le bilan post-incident est pénible.

Avec un peu de chance, vous avez simplement affaire à un échec de déploiement, et non à une interruption de service majeure. Dans tous les cas, ce type de mauvaise dérive mobilise des ressources d’ingénierie. Et lorsque les applications sont essentielles à l’activité, les mauvaises dérives peuvent entraîner une perte de revenus ou entamer la confiance des clients.

C’est là que des approches efficaces de la sécurité cloud peuvent profiter aux équipes applicatives et d’exploitation. Elles n’apprécient pas que l’on change les règles du jeu, et à juste titre. Corriger les mauvaises dérives contribue à sécuriser votre environnement et à assurer sa conformité, mais aussi à éviter les interruptions de service imprévues. Tout le monde y gagne lorsque l’on dispose d’une source unique et fiable pour savoir ce qui s’exécute dans les environnements cloud.

Les pires dérives : violation de données !

La dernière catégorie de dérive de l’infrastructure cloud comprend les changements qui exposent des données sensibles à une exploitation ou à une fuite. Ce sont ces incidents qui font la une des journaux. Et ils sont toujours imputables au client du cloud, jamais au fournisseur.

La dérive catastrophique la plus courante consiste à rendre accessible au public une ressource de stockage d’objets sensible, souvent AWS S3, ne serait-ce qu’en raison de l’immense popularité du service. Par défaut, S3 est configuré en privé. Pourtant, il n’est pas rare que des utilisateurs du cloud modifient cette configuration par inadvertance et la rendent publique, ce qui risque d’exposer des données sensibles ou privées. Les gros titres ne manquent pas sur les dangers des violations de données cloud dues à une mauvaise configuration de S3.

Au-delà de S3, il faut également détecter et corriger rapidement les dérives de configuration des règles de groupes de sécurité, des VPC (y compris les sous-réseaux et les ACL), des politiques IAM et des politiques d’accès aux bases de données. Vous éviterez ainsi que votre organisation fasse la une des journaux, sans parler de lourdes amendes pour non-conformité et d’une perte de confiance des clients.

Élaborer un plan d’action

La correction et la prévention des erreurs de configuration cloud doivent être une priorité absolue pour toute équipe de sécurité ou d’exploitation cloud en entreprise. Maîtriser les dérives est essentiel pour y parvenir. Savoir classer les événements de dérive vous aidera à consacrer vos ressources limitées à ceux qui comptent et à choisir la meilleure façon d’y remédier (manuellement ou automatiquement).

• Bonnes dérives : Ignorez-les ! Vous souhaiterez toutefois, à terme, soumettre l’éventail de configurations possibles d’une application à des contrôles de sécurité. Nous aborderons ce sujet dans un prochain article.

• Mauvaises dérives : Surveillez-les ! Assurez-vous de surveiller en continu les dérives de cette catégorie et de pouvoir y remédier rapidement. Pour les ressources qui ont tendance à dériver fréquemment, comme les groupes de sécurité, envisagez de déployer une solution de correction automatisée afin d’éviter les interruptions de service.

• Pires dérives : Prévenez-les ! Pour éviter une violation de données due à une dérive de l’infrastructure, il est indispensable de disposer d’une solution qui détecte et corrige automatiquement les dérives touchant les ressources sensibles. Vous ne pouvez pas vous permettre de laisser vos données sensibles exposées pendant des heures, des jours ou plus longtemps encore.