Sécurité sur le Cloud : nos 4 convictions

Temps de lecture : 6 minutes

Aujourd’hui les entreprises migrent massivement sur le Cloud dans l’objectif d’innover, d’accélérer, et de réduire les coûts. Si le Cloud apporte ces opportunités, il soulève aussi de nouveaux challenges : ce cadre technologique est nouveau, et il impacte les pratiques agiles et devops. De plus, l’entreprise doit également s’adapter aux nouveaux cadres réglementaires (RGPD, NIS, LPM…). Tous ces facteurs contribuent à créer des antagonismes importants et posent le challenge d’arriver à concilier les enjeux métiers et sécurité sur les terrains de jeu pratiqués par les équipes plateforme, projet et sécurité.

Le Cloud disrupte la sécurité

Culture, organisation, équipes, processus, outils et technologies… le Cloud bouscule les habitudes établies en matière de sécurité. D’après une étude Outscale de 2018, 77% des entreprises considèrent la sécurité comme un challenge du cloud.

Les entreprises ont la conviction que les pratiques doivent changer, mais comment ? Principalement, le Cloud oblige à revoir le nombre d’acteurs concernés par la sécurité : la sécurité devient une compétence de base pour tous les acteurs de l’IT (DevSecOps, référents DevOps, architectes Cloud…), et elle doit être intégrée aux projets dès la phase de build. 

Comment ? Notre expérience nous a mené à nous forger 4 convictions principales sur ce sujet.

Conviction 1 : une approche concertée et progressive entre les équipes sécurité et devops

Pour être réussie, cette approche doit se faire en plusieurs étapes. 

Dans un premier temps, la définition et la préparation : durant cette étape, les équipes expérimentent, testent les nouveaux environnements. Point de vigilance : s’assurer de la formation, en amont et au fil de l’eau, des différentes équipes (sécurité et devops), aussi bien sur les aspects sécurité que sur les concepts de plateforme Cloud, de devops et de chaîne CI/CD.

Il est également indispensable que l’équipe sécurité définisse comment elle propose d’adapter sa stratégie interne à l’environnement cloud. Quel est le niveau de risque acceptable pour l’organisation? On positionnera le curseur différemment selon la culture de l’entreprise, son secteur d’activité et la maturité de ses intervenants.

Dans un second temps, sécuriser les environnements se fait de façon concertée entre les équipes : l’équipe sécurité est en charge de sécuriser l’infrastructure, tandis que l’équipe devops collabore avec la sécurité pour développer des briques dans un environnement sécurisé, tout en répondant aussi aux besoins métiers et à ses propres besoins de fonctionnement. Les deux équipes enrichissent ainsi mutuellement leurs connaissances des services managés proposés par les cloud providers, qu’ils soient sécurité ou métier.

Troisième étape, la transformation. La sécurité gagne en efficacité à travers notamment :

  • L’utilisation des environnements Cloud pour ses propres besoins – par exemple, mise en place d’un laboratoire de sécurité afin de tester des produits, créer ses propres services en complément des services managés, et ainsi construire un catalogue de service. Ceci montrera la capacité de l’équipe sécurité à être force de proposition et à accompagner de façon concrète les Devops et les architectes dans les projets de transformation digitale.
  • le déploiement d’une organisation DevSecOps – à travers une nouvelle répartition des tâches, les DevOps vont notamment pouvoir gérer une partie des activités de sécurité opérationnelle, et les intégrer dans leurs processus d’exploitation (ex. : filtrage réseau, gestion des secrets, chiffrement, détection des vulnérabilités…). Ceci permet d’assurer une meilleure prise en compte des enjeux sécurité sans augmenter la taille des équipes. Ainsi les perspectives changent : la sécurité n’est plus un goulet d’étranglement, elle vient s’intégrer au coeur des processus projets et production 
  • l’intégration des mécanismes d’automatisation – par exemple, pour faciliter la mise en place de points de contrôle en amont et en aval des chaînes CI/CD et des activités des DevOps ou le déclenchement des mesures d’alerting et de remédiation

Enfin, dans un dernier temps, la sécurité est alors prête à pleinement participer à la plateformisation de l’organisation en à sa chaîne de valeur. L’automatisation apporte de la vitesse et de la simplicité aux processus métier, elle limite les erreurs humaines et facilite les contrôles en amont et en aval.

Cela permet de valoriser la confiance mise en avant dans une relation client, comme dans le cas de l’IoT où la protection des données personnelles est un avantage concurrentiel. La sécurité peut aussi apporter des fonctionnalités qui sont des différenciateurs, comme la détection des actes malveillants ou des activités inhabituelles, dans le secteur bancaire.

Si cette transformation s’opère en quatre étapes, elle doit également se faire à travers les quatre fondamentaux d’une organisation que sont sa culture, ses collaborateurs, sa gouvernance et processus et ses outils technologiques.

Enfin, on veillera au développement de parcours de formation et d’auto-formation adaptés au Cloud, DevOps et à la sécurité.

Conviction 2 : la nécessité de casser les silos

Il n’y a pas de transformation réussie sans une collaboration accrue des équipes sécurité avec les autres équipes. L’entreprise a tout intérêt à valoriser et favoriser les notions de co-construction et de collaboration, à travers des règles de gouvernance et des processus qui supportent ces notions. 

Cette collaboration doit s’articuler autour de différents moments clés : la formation, mais aussi les phases de préparation et de construction des projets, pour que toutes les équipes puissent apprendre à travailler ensemble et à se forger des convictions communes par la pratique. Pour les équipes sécurité, il s’agit de monter en compétence sur le Cloud et ses technologies. Pour les équipes de développement, l’enjeu est de se former aux principes de la sécurité appliqués au Cloud.

Faire ensemble, co-construire, est indispensable pour développer des convictions qui soient en phase avec la réalité du terrain. Un bon moyen de mettre en oeuvre cette idée est également de s’appuyer sur des projets pilotes, sur lesquels on pourra embarquer des individus issus de différentes équipes. 

De la même façon, il est important d’identifier des référents sécurité au sein des autres équipes. Pouvoir s’appuyer sur des devops ou des architectes devenus des sponsors de la sécurité facilitera la mise en place d’une logique de pollinisation et de diffusion des bonnes pratiques. 

Enfin, l’organisation aura tout à gagner à encourager la mise en place de communautés réunissant des représentants d’équipes IT / Processus / Sécurité / Métier. Ces communautés permettront de favoriser le partage d’information, sur les succès comme sur les échecs (car il y a matière à apprendre dans les deux cas), pour optimiser l’apprentissage en condition. 

Conviction 3 : il n’y a pas de solution prête à l’emploi

En matière de sécurité,  il n’existe pas de one size fits all. Tout dépend des besoins métier, de la culture, de l’appétence aux risques et des processus et environnements en place. Cependant, deux principes sont incontournables et doivent être intégrés à toute stratégie de sécurité : l’infrastructure immuable et l’automatisation. Bannir les processus manuels de mise à jour des différents environnements pour utiliser des images sources et des re-déploiements automatiques de l’ensemble du parc permet notamment de limiter les erreurs et d’accélérer les mises à jour.

Quant à l’automatisation, elle offre l’opportunité d’assurer la régularité et la massification des contrôles a priori et a posteriori et de fiabiliser les déploiements, laissant plus de liberté équipes devops pour expérimenter leurs environnements. La détection, l’alerting, la remédiation peuvent également être automatisés, à travers le scripting et le couplage des services de contrôle avec tous les autres services managés. On libère ainsi les équipes de tâches répétitives à faible valeur ajoutée, pour leur permettre d’intervenir sur des activités où leur jugement est plus essentiel.

Conviction 4 : s’appuyer sur les services managés

Identité, contrôle, sécurité d’infrastructure, protection des données, réponse aux incidents… les services managés des Cloud providers, comme AWS Inspector, offrent une très large palette de réponses aux besoins opérationnels de sécurité. Bien maîtrisés, les services Cloud peuvent enfin fournir la boîte à outils dont rêve chaque RSSI pour déployer rapidement ses mesures et contrôles, à moindre coût et de façon beaucoup plus uniforme et intégrée. 

Ainsi, plutôt que de plaquer de façon arbitraire des façons de faire et des outils hérités des environnements internes, il nous semble indispensable de bien comprendre la portée et la réelle valeur de chacun de ces services, et de les intégrer à leur juste place dans la stratégie globale de sécurité de l’organisation.

Il sera ainsi possible de favoriser l’approche “défense en profondeur” plutôt que dépenser temps et énergie à multiplier les outils et services concurrents. Et ainsi bénéficier des avantages liés à l’interopérabilité des services, pour déployer des solutions facilement automatisables et se libérer des activités techniques sans valeur ajoutée, comme la maintenance technique.

Commentaires :

A lire également sur le sujet :