Le Cloud est un nouveau terrain de jeu qui change les règles et l’organisation de la DSI, et notamment la sécurité. Les fournisseurs de Cloud public proposent un modèle de responsabilité partagée, où le provider gère la sécurité du Cloud, et où la sécurité dans le Cloud relève du client. Il s’agit cependant d’un modèle de sécurité très différent de celui appliqué on premise, dont nous vous proposons ici de découvrir les principes et les bonnes pratiques.

Sécurité on premise : ce qu’il faut oublier

De nombreuses pratiques de sécurité on premise sont rendues obsolètes par le Cloud et ses services natifs, et continuer à les appliquer peut se révéler contre-productif, sans pour autant apporter la sécurité attendue. Nous avons en effet souvent constaté que les DSI, en essayant de reproduire les pratiques de sécurité appliquées en interne sur le cloud, ont créé des procédures longues et inadaptées au Cloud. Avec pour conséquence de perdre les bénéfices attendus du Cloud, comme l’accélération du time to market, ou la scalabilité.

Si la sécurité est trop contraignante, les utilisateurs essaieront de trouver des moyens de contournement ! Pour être efficace sur le Cloud, il faut donc de conserver les fondamentaux de la sécurité, mais modifier les méthodes de mise en oeuvre pour s’adapter aux nouvelles exigences des équipes DevOps. Cela implique de :

• Remplacer les outils traditionnels par les fonctionnalités de sécurité déjà embarquées par défaut sur le Cloud
• S’appuyer sur la souplesse du Cloud et les principes DevOps & Agile pour passer d’une logique manuelle (“right side”) à une logique automatisée (“shift left”).

Sécuriser l’accès à l’environnement cloud

Dans le monde on premise, la tendance est de contrôler l’accès aux infrastructures d’administration en centralisant les flux à travers un bastion, via Citrix par exemple. Cela peut avoir un lourd impact sur la productivité dans un environnement Cloud, sans pour autant que l’environnement soit vraiment sécurisé.

Pour un environnement Cloud, on utilisera soit un VPN, soit un bastion, soit les deux, en respectant le principe que les machines ne doivent pas être accessibles de l’extérieur. Le bastion permet de faire un rebond vers une autre instance, en lui communiquant l’adresse IP privée de la machine et la clé SSH. Le bastion autorise ensuite la connexion à cette machine uniquement.

Point de vigilance : Le bastion est une bonne pratique pour accéder aux machines sur AWS, mais la sécurité doit y être particulièrement forte étant donné sa position stratégique dans le réseau.

Le filtrage réseau

Gérer la sécurité sur chaque machine on premise était complexe, et c’est pour cette raison qu’un point central d’accès était établi avec une DMZ. Sur le Cloud AWS, au contraire, il est très simple de gérer les règles de sécurité par machine ou par projet. La sécurité devient distribuée, elle n’est plus centralisée en un seul point.

Le Cloud implique néanmoins de réfléchir en amont à la sécurité de chaque application. Avant même le développement de l’application, il convient de définir ce dont elle aura besoin pour fonctionner : quels ports, quelles communications vers quelles IP, quelle ouverture sur le réseau interne/externe ? Chaque projet et chaque application étant différents, les paramètres de sécurité sont adaptés en fonction des besoins. De fait, il n’est pas possible de se limiter à un modèle d’infrastructure avec des règles pré-établies.

Point de vigilance : Il faut garder à l’esprit que le modèle du cloud demande de paramétrer la sécurité de chaque machine, et notamment ce à quoi elle peut accéder.

Nous conseillons d’utiliser au maximum la sécurité du Cloud comme première couche de sécurité : AWS offre par défaut un niveau de sécurité très élevé et de très loin supérieur à ce qui peut être réalisé en interne (pen testers, analyse automatique des flux et comportement des machines…), mais il incombe à l’utilisateur de configurer les règles de sécurité de façon à restreindre les accès au strict nécessaire. Par exemple, par défaut les Security Groups sont fermés, et on devra donc établir quelles sont les règles de communication entre les machines.

On choisira aussi les services Cloud les plus adaptés aux besoins de l’application, comme un ALB (application load balancer) permettant de filtrer et de n’accepter que certains ports (et éviter d’exposer la machine sur Internet), avec un certificat SSL pour faire du HTTPS. Ceci ne dispense pas de corriger les failles de l’application elle-même, mais permet déjà de se prémunir contre les scans de port ou le bruteforce.

Point de vigilance : Hors des phases d’expérimentation ou POC, nous recommandons aussi d’utiliser un outillage (AWS ou outil tiers) pour scanner sa configuration et vérifier que rien n’a été oublié. Malgré les bonnes volontés, il est toujours possible d’oublier de fermer des ports qui ont été ouverts dans le cadre d’un test.

Gestion des accès

La gestion des identités et des accès reste un fondamental de la sécurité, pour se prémunir au maximum des risques de mauvaises manipulation ou d’oubli.

Dans un environnement on premise, on visait à déployer une gestion basée sur des référentiels centraux et uniques. Dans le monde du cloud, il faut prendre en compte une nouvelle couche qui est la gestion des accès à l’infrastructure cloud elle-même (IAM chez AWS).

En bonne pratique, il faudra donc définir en avance de phase l’architecture d’accès la plus adaptée aux utilisations qui sera faite du cloud et à ses utilisateurs, et assurer le maillage entre compte cloud, utilisateurs cloud et accès applicatifs (création et configuration des comptes master et secondaires, comptes dédiés à des activités transverses comme la gestion des logs, l’audit, etc, shared accounts, logique d’attribution des politiques d’accès à des users, rôles, groupes, utilisation du principe de boundaries…). Et prévoir de réviser cette architecture régulièrement pour rester cohérent avec les nouveaux usages de l’organisation.

Point de vigilance : Il faut adapter dès le début les procédures d’attribution des droits pour garder le contrôle sur l’expansion non contrôlée des comptes. Cela permet de garantir que les actions les plus critiques ne puissent être attribués qu’à un groupe restreint d’administrateurs, disposant des connaissances appropriées.

Le chiffrement

Comme le préconise Werner Vogels : “Dance like no one is watching. Encrypt like everyone is.”

Dans un environnement dont la plus grande partie est accessible uniquement en interne, l’impératif du chiffrement semble moins important. D’autant plus que toutes les organisations ne disposent pas d’une infrastructure adaptée et hésitent à assumer les coûts et les règles de fonctionnement qui viennent avec un dispositif de PKI : achat et diffusion des certificats et des clés, rotation fréquente, etc

Dans le cloud, on dispose de fonctionnalités par défaut qui permettent de faciliter les pratiques. Du coup, il n’y a plus d’excuse, tout doit être chiffré… ou presque : bases de données, S3, communications entre instances, notamment les remontées de logs, dont les informations pourraient être exploitées si interceptées. Il faut chiffrer les données au repos et en transit, mais tout de même réfléchir à ce qui doit être protégé : par exemple sur un site web, on chiffrera la base de données, mais pas le logo. A noter également qu’une communication chiffrée prend plus de temps, et donc cela a un impact sur les performances.

Sécuriser en interne la chaîne CI/CD

S’il faut évidemment sécuriser le front et le réseau, on n’oubliera pas non plus de sécuriser chacune des machines : nous avons déjà vu beaucoup de sécurité sur le front, avec des machines non sécurisées disposant de rôles puissants, et c’est une pratique fortement déconseillée.

Point de vigilance : ne pas se focaliser uniquement sur le danger externe et oublier celui venu de l’interne.

Dans le cas du pipeline CI/CD par exemple, les machines qui portent les pipelines ont des droits forts comme la mise à jour d’un service (ECS, EC2, Lambda, …), ou certaines informations importantes comme les identifiants des bases de données. Il est donc important de détecter toute action illicite sur ces machines (démarrage d’un shell, certaines commandes de scan comme nmap, etc), et tout aussi important de cloisonner les projets pour éviter le partage d’information d’un projet à un autre, surtout quand l’accès au CI/CD est donné à des prestataires freelance.

Ce problème ne se posait pas avant la généralisation du CI/CD : la mise en production était gérée par les Ops. Dans ce nouveau paradigme, l’enjeu de la sécurité dans le Cloud est de bien segmenter les applications et de s’adapter aux nouvelles méthodes de développement et de déploiement. Cela demande également d’accompagner le changement des mentalités, puisque la tendance à “faire comme avant” reste très forte.

Le cas des nouvelles applications

Pour les applications Cloud Native, développées pour le Cloud, la sécurité doit être incluse dès la conception des applications. Elle doit être aussi pensée dans tout le cycle de vie de l’application, et notamment au niveau du CI/CD où on évitera de mettre des mots de passe en clair.

Parmi les réflexions importantes :

• Identifier les ports utilisés par l’application (interne/externe), les applications avec lesquelles elle interagit, et choisir les ports et les IP à ouvrir en fonction.
• Configurer les Load Balancer pour faire un premier filtrage des ports et URL.
• Définir de façon précise les rôles à donner à chaque type de machines, pour leur associer des paramètres de sécurité prédéfinis standards.
• Utiliser un gestionnaire de secrets, comme Vault ou AWS Secret Manager, qui permet de gérer les mots de passe et tokens, et évite ainsi de dévoiler ces informations sensibles. Les développeurs peuvent déployer en production sans connaître les mots de passe des bases de données, de la même façon il est également possible de générer des token à durée limitée, juste le temps du déploiement. Si le token est compromis, il le sera sur une durée très limitée.

Les contrôles

Dans un environnement de développement relativement linéaire et qui s’étire sur plusieurs mois, la tendance générale est de positionner les points de contrôle sécurité en une seule fois, en fin de phase (avant mise en production) et de façon souvent manuelle. Dans un environnement agile qui repose sur une chaîne CI/CD, ce n’est plus possible.

Il faut définir des règles de contrôles générales, quelque soit le projet, à compléter au besoin avec des règles spécifiques à chaque projet, en définissant des seuils d’alerte en fonction de la criticité de l’environnement et de l’application. Ces contrôles seront appliqués à la fois sur l’infrastructure cloud, la chaîne CI/CD et le code développé.

Point de vigilance : mettre en place des contrôles en continu et d’autres en mode “spot check”, et automatiser la surveillance, la remontée des alertes et, lorsque c’est pertinent, la remédiation. Dans un premier temps, on utilisera pour cela les fonctionnalités de compliance dans l’environnement Cloud, avant d’acquérir ou développer en interne des outils de contrôle avec une couverture plus large.

La coopération et la formation pour une sécurité portée par tous

Avec l’arrivée du Cloud, les grands principes de la sécurité n’ont pas fondamentalement changé, mais ils s’appliquent désormais différemment. La sécurité, qui était l’affaire de quelques spécialistes, et concentrée en des points uniques de l’infrastructure, est devenue distribuée. L’identification, le déploiement des mesures de sécurité et la réalisation des contrôles ne sont plus le pré-carré des experts. Nous aurons toujours besoin de spécialistes de la sécurité, mais un transfert de compétences s’est opéré en direction des DevOps : une partie des tâches de sécurité doit maintenant être prise en charge par ces équipes. Cela demande de former les équipes sécurité au Cloud et DevOps, et inversement de diffuser les bonnes pratiques sécurité au sein des équipes DevOps, de façon à ce que les équipes sécurité comprennent les besoins et façons de faire des équipes IT, et que ces dernières puissent intégrer au plus tôt les concepts sécurité et ce en partenariat avec les équipes sécurité.

Pour continuer à explorer ce sujet, dans un prochain article, nous verrons plus en détail des exemples concrets mis en place chez nos clients.