La transformation Cloud a commencé en 2015 chez Bouygues Telecom, et après une première expérimentation en production, le Cloud est rapidement devenu la norme. La généralisation de l’infrastructure as code s’est accompagnée d’une sécurisation accrue par l’automatisation. Pour aller plus loin dans l’adoption, Bouygues a lancé fin 2018 le programme Go to Cloud, qui vise à donner plus d’autonomie aux équipes dans leurs projets. D’un point de vue sécurité, l’enjeu pour Bouygues était que cette autonomie n’entraîne pas une augmentation des risques liés aux nouvelles technologies et pratiques Cloud et Devops. Pour cela, le programme Go To Cloud comporte un large volet de sécurisation opérationnelle de la plateforme AWS et des applications qu’elle supporte. Ce volet est articulé autour de 3 axes : la définition d’une politique de sécurité des SI (PSSI) spécifique au Cloud, l’intégration de la sécurité dans le cycle de vie des applications Cloud à travers la déclinaison de la PSSI en règles de sécurité opérationnelles et la mise en place d’un outil de suivi de conformité, Dome 9.

Conception de la politique SSI

La politique de sécurité des systèmes d’information pour le Cloud AWS vise à définir les grands principes établissant le cadre des activités Cloud et les limites qui y sont appliquées en termes de sécurité. Cette politique indique les enjeux et besoins de sécurité de Bouygues pour sa plateforme, les cadres légaux et réglementaires à respecter, le périmètre d’application, la répartition des rôles et responsabilités…

Elle mentionne également ce qui est autorisé ou non sur les axes majeurs : gouvernance et organisation des comptes, contrôle des flux réseau, gestion des identités et accès, gestion des secrets, nomenclature, inventaire et classification, gestion des vulnérabilités et de la conformité, protection des données, et traçabilité des actions. 

Pour l’ensemble de ces points les équipes D2SI ont établi les bonnes pratiques, par exemple la séparation des environnements afin de minimiser la propagation d’attaque d’un environnement à un autre, avec la création d’un compte dédié pour chaque environnement.

Intégration opérationnelle dans le cycle de vie des applications

Comme nous l’explique Christophe François, Responsable Cloud Bouygues Telecom, la sécurité est totalement intégrée au cycle de vie des applications Cloud :

“Le RSSI est le meilleur allié des projets Cloud. Les équipes SSI et Cloud accompagnent les projets tout au long des cycles de développement, ce qui nous assure que la sécurité soit intégrée au quotidien dans le travail des équipes. La sécurité n’est pas une mission ponctuelle, c’est un prérequis pour tout projet Cloud et les équipes de D2SI nous assistent dans la définition et l’application de ces règles.”

L’étape suivante consiste à identifier l’ensemble des mesures opérationnelles à déployer pour chaque application développée sur le Cloud ou qui y migre. A ce titre, ont été définies et mises en place plus de 300 règles de sécurité, qui respectent les bonnes pratiques énoncées dans le Well Architected Framework AWS. Parmi ces règles, citons quelques exemples :

• Chiffrement au repos : utilisation du service KMS
  pour chiffrer toutes les données stockées dans les volumes EBS, les instances RDS, les buckets S3, les données générées par Elasticsearch et CloudWatch (logs) ainsi que le code source des fonctions lambda. 
• Chiffrement en transit : toutes les connexions entre applications passent par des flux HTTPS.
• Identité : utilisation exclusive par les applications de rôles créés à partir du service IAM pour accéder aux ressources AWS. En complément, les politiques IAM s’appliquent aux groupes et non aux utilisateurs (il n’y a d’ailleurs pas de gestion d’utilisateurs sur la plateforme).
• Accès : toutes les politiques IAM sont construites de façon à respecter le principe de « least privilege », c’est-à-dire en limitant les accès aux besoins stricts de l’application. De plus, le respect de ce principe de « least privilege » est vérifié à travers la revue des logs issus de CloudTrail centralisés dans un bucket S3 (accès multi-compte via dans AWS Organization). Enfin, tous les comptes AWS utilisés sont organisés au sein du service AWS Organization, afin de faciliter la bonne attribution des droits. 
• CI/CD : les codes source sont centralisés dans des repository Git et l’usage d’une chaîne CI/CD est obligatoire.
• Automatisation :  les déploiements doivent se faire exclusivement de façon automatisée et via CloudFormation.
• Gestion des secrets :  les secrets sont stockés dans une solution tierce de coffre-fort numérique Cyberark. De plus, en accord avec les bonnes pratiques AWS, une rotation est imposée des access key/secret key (renouvellement tous les 6 mois).

Conformité

Au niveau opérationnel, les équipes D2SI ont assuré l’intégration de Dome 9 pour prendre en charge le suivi de conformité de l’ensemble de ces règles. 

Le 1er use case de vérification porte sur le socle Cloud : Dome 9 effectue des audits réguliers sur la plateforme et vérifie que son usage est conforme aux règles édictées (instances, services, réseau, etc.). Dome 9 intègre un certain nombre de règles de sécurité, auxquelles nous avons ajouté des règles spécifiques au contexte de Bouygues Telecom, comme l’ajout d’un Web Application Firewall pour tous les frontaux web, ou des règles spécifiques au stockage des données en regard de la GDPR. 

Il est à noter que par la suite, les équipes Bouygues ont complété leur boîte à outils de solutions de conformité en utilisant en parallèle le service AWS Config Rule. Des règles ont notamment été déployées pour contrôler la non-exposition publique des buckets S3. 

Le 2ème use case, en cours de mise en place, est l’automatisation de l’audit de compliance lors du déploiement des stacks : l’objectif est qu’aucune stack ne soit déployée en production sans signature. C’est peut-être là une des plus grandes avancées en matière de sécurité : avant sa mise en production une application doit répondre à toutes les règles de sécurité applicables parmi le socle générique des 300 mesures déployées auparavant. Cet audit de pré-déploiement a aussi pour objectif de permettre aux développeurs de comprendre rapidement quels enjeux de sécurité ont mal été pris en compte. Lorsqu’une stack est bloquée en pré-production, les points non conformes sont indiqués de façon à pouvoir être corrigés rapidement.

L’utilisation conjointe de solutions managées AWS et d’outils du marché a permis à Bouygues de mettre en place un dispositif de vérification de sa conformité qui lui permet de prendre en compte à la fois ses besoins de contrôle et les différents niveaux de maîtrise de ses équipes.

En résumé

Afin de s’assurer de la sécurité de la plateforme AWS et des applications qu’elle héberge, tout en conservant un maximum d’autonomie aux équipes devops, Bouygues, avec le support de D2SI, a mis en place un plan d’action articulés autour de trois étapes clés : définition d’une PSSI, déclinaison et mise en œuvre de mesures de sécurité opérationnelles (en s’appuyant notamment sur des services managés de sécurité AWS tels que IAM, KMS, CloudTrail…) et suivi du niveau de conformité à ces règles à travers l’utilisation conjointe d’un outil tiers, Dome 9 et du service managé AWS Config Rule.

En complément, l’interview de Christophe François, Bouygues Telecom, sur le chemin vers le Cloud :