Créez des microservices résilients et sécurisés avec la microsegmentation

Cet article a été publié à l'origine dans La nouvelle pile.

Il y a environ 10 à 12 ans, le monde du logiciel a connu un changement dans les aspects architecturaux des applications d'entreprise. Les architectes et les concepteurs de logiciels ont commencé à s'éloigner des applications géantes, étroitement couplées et monolithiques déployées dans les centres de données privés pour adopter une architecture plus orientée vers les microservices hébergée dans l'infrastructure publique en nuage. La nature distribuée inhérente aux microservices constitue un nouveau défi en matière de sécurité dans le nuage public. Au cours de la dernière décennie, malgré l'adoption croissante de l'architecture orientée microservices pour créer des applications d'entreprise évolutives, autonomes et robustes, les entreprises ont souvent du mal à se protéger contre cette nouvelle surface d'attaque dans le nuage par rapport aux centres de données traditionnels. Il s'agit notamment de préoccupations liées à l'utilisation multiple et au manque de visibilité et de contrôle sur l'infrastructure, ainsi que sur l'environnement opérationnel. Ce changement d'architecture rend plus difficile la réalisation des objectifs de sécurité, en particulier avec l'importance primordiale accordée aux déploiements plus rapides basés sur des conteneurs.

L'objectif de cet article est de comprendre ce qu'est la microsegmentation et comment elle peut permettre aux architectes logiciels, aux ingénieurs DevOps et aux architectes de la sécurité informatique de construire des microservices sécurisés et résilients. Plus précisément, je discuterai des défis de sécurité réseau associés au mécanisme populaire d'orchestration de conteneurs Kubernetes, et j'illustrerai la valeur de la microsegmentation pour empêcher les mouvements latéraux lorsqu'une brèche se produit.

Défis de sécurité liés aux déploiements de microservices

L'architecture orientée microservices nécessite la décomposition des applications en services plus petits et faiblement couplés. En raison de la nature distribuée de ces services, ils finissent souvent par avoir leurs propres magasins de données. Chacun de ces services est déployé indépendamment à l'aide d'un conteneur, qui offre un mécanisme permettant à une application de tout emballer, du code objet aux bibliothèques tierces, en passant par les systèmes d'exploitation, les outils et autres dépendances. Une fois que tous les éléments nécessaires sont emballés, les conteneurs fournissent l'environnement d'exécution nécessaire à leur bon fonctionnement. Ces conteneurs sont gérés à l'aide d'orchestrateurs comme Kubernetes.

Selon l'idée reçue, l'écosystème des conteneurs est conçu pour renforcer la sécurité par l'isolement. Cependant, l'isolation entre les conteneurs ne fournit pas nécessairement les limites de sécurité requises. Kubernetes offre plusieurs fonctionnalités de sécurité comme l'authentification, l'autorisation, la politique de réseau et la norme de sécurité des pods, etc. Mais malheureusement, ni les conteneurs ni Kubernetes n'offrent de sécurité par défaut. Les déploiements Kubernetes privilégient la fonctionnalité à la sécurité dans leur configuration par défaut. Par conséquent, un développeur ou un ingénieur en fiabilité qui est responsable de la création, du déplacement et de la destruction de ces conteneurs ne sait pas toujours comment assurer la sécurité des déploiements. Examinons de plus près certains des aspects importants de Kubernetes du point de vue du réseau et de la sécurité :

1. Espace de noms : Dans Kubernetes, un espace de noms est un moyen logique de diviser les ressources du cluster en espace virtuel entre plusieurs utilisateurs. Contrairement à Linux, il n'impose aucune segmentation du réseau. Veuillez noter qu'un espace de noms n'est pas une frontière de sécurité et que, par conséquent, les services d'un espace de noms peuvent accéder aux services d'un autre espace de noms.
2. Politique de réseau : La politique de réseau Kubernetes est une construction spécifique à l'application qui permet la communication de couche 3 et de couche 4 entre les espaces de noms, les pods et les blocs d'adresses IP. Lorsque Kubernetes est installé, la stratégie réseau n'est pas disponible par défaut. Il est nécessaire d'installer et de configurer les plugins réseau pour appliquer les politiques de réseau avant la création des pods. Il convient également de noter que les politiques de réseau ne peuvent pas être appliquées au niveau des services. Il s'agit d'une lacune importante du point de vue de la sécurité, car le contrôle d'accès ne peut pas être étendu aux services.
3. Norme de sécurité pour les pods : Dans un cluster, les pods prennent en charge plusieurs conteneurs qui partagent la même machine physique ou virtuelle. Ils permettent le partage des données et la communication entre les conteneurs au sein du pod. Une norme de sécurité podologique permet à un administrateur de contrôler les ressources et leurs autorisations à l'aide d'un modèle d'autorisation à grain fin. Ce contrôle de sécurité nécessite un contrôleur d'admission, qui n'est pas activé par défaut. Un pod privilégié offre un accès administratif à tous les conteneurs. Par conséquent, l'attaquant qui obtient un accès aux conteneurs privilégiés peut obtenir un accès administratif aux ressources de l'hôte.
4. Stockage des secrets : Kubernetes stocke des informations sensibles et confidentielles telles que des mots de passe, des jetons OAuth et des clés SSH en tant que secrets sous forme codée en base 64, ce qui est considéré comme du texte en clair. La politique d'autorisation, qui sert à restreindre l'accès aux secrets, n'est pas configurée par défaut. Ils sont partagés via des variables d'environnement ou des fichiers manifestes, qui sont également considérés comme une pratique peu sûre pour la gestion des secrets. En l'absence de chiffrement par défaut des secrets au repos et de gestion robuste des secrets, ces derniers deviennent une cible attrayante pour les mouvements latéraux.

Le mouvement latéral et l'initié malveillant

La nature distribuée des microservices rend la connectivité extrêmement importante. Plus précisément, les conteneurs et les pods doivent pouvoir communiquer entre eux à travers les espaces de noms. Cependant, les politiques de réseau par défaut au niveau de la grappe ne mettent pas nécessairement en œuvre le principe du moindre privilège. Par conséquent, quelle que soit la manière dont vous sécurisez votre code, l'accès implicite non autorisé aux ressources partagées ne peut être interdit. Par conséquent, l'application peut devenir sensible aux mouvements latéraux au sein du cluster. La microsegmentation permet de mettre en œuvre un contrôle d'accès granulaire, en créant des zones sécurisées autour de chaque microservice au niveau du conteneur, du pod et du cluster, ce qui réduit considérablement le rayon d'action et augmente la résilience en cas d'attaque réussie.

La deuxième menace importante que le modèle de sécurité du cadre Kubernetes existant présente en ce qui concerne les microservices est un initié malveillant. Du point de vue d'un attaquant, lorsque la sécurité n'est pas disponible par défaut, plusieurs erreurs de configuration sont possibles. En l'absence d'un contrôle d'accès fort ou de politiques d'autorisation, des attaques telles que leSSRF (Server-Side Request Forgery) permettent à l'attaquant de tirer parti d'un accès authentifié à un module pour obtenir un accès non autorisé à des ressources au sein d'un autre module.

Comme nous l'avons vu plus haut, nous avons constaté qu'il n'existe pas de contrôles de sécurité adéquats pour protéger les secrets par défaut. L'absence de cryptage et de rotation des secrets, ainsi que l'absence de restriction d'accès aux secrets, sont en effet des problèmes sans rapport entre eux, mais en l'absence d'un contrôle de sécurité (dans ce cas, l'absence de cryptage), le second contrôle de sécurité (c'est-à-dire la restriction d'accès aux stocks de secrets) devient crucial pour éviter qu'un initié malveillant (par exemple, un administrateur mécontent) ne l'exploite.

Introduire la cyber-résilience avec la microsegmentation

Dans le contexte de la sécurité, la résilience est la capacité à se remettre rapidement d'une simple défaillance due à des attaques ou à des événements catastrophiques tels que des violations. La première étape de la construction de microservices résilients consiste à comprendre ce que nous souhaitons protéger de l'attaquant et, si l'actif ou la ressource est compromis, comment nous pouvons en limiter l'impact. La microsegmentation nous aide à déterminer les ressources contenant des données essentielles ou des systèmes critiques à tolérance de pannes, et elle fournit également un mécanisme pour verrouiller l'accès sur la base du moindre privilège. Ainsi, même si une ressource critique est compromise, les autres n'en subissent pas les conséquences.

Aujourd'hui, le cycle de développement des logiciels modernes met l'accent sur la fourniture rapide de fonctionnalités. Ces fonctionnalités sont déployées en production via des conteneurs encore plus rapidement, le plus souvent par les mêmes développeurs ou DevOps. Si nous considérons tous les types de vulnérabilités auxquelles le code des microservices, les bibliothèques tierces et les autres dépendances, le conteneur ou le cluster sont susceptibles d'être exposés, comment pouvons-nous identifier et prévenir toutes ces attaques ? La réponse consiste à bloquer l'accès aux ressources critiques et à ne l'autoriser que sur la base du "besoin de savoir" à l'aide de la microsegmentation.

Commencez avec la microsegmentation

Il n'existe pas de stratégie unique pour démarrer la microsegmentation, mais voici quelques bonnes pratiques pour lancer un projet de microsegmentation pour les microservices :

1. Connaître les modèles de conception de microservices et utiliser un modèle de microsegmentation

Connaître les modèles de conception permet de mieux comprendre les composants architecturaux, les flux de données et les actifs contenant des données critiques. Sur la base de ces modèles de conception fréquemment utilisés, il est possible de créer des modèles de microsegmentation correspondants. Une fois que ces modèles auront été approuvés par l'équipe chargée de la sécurité et de la mise en réseau, ils seront faciles à réutiliser et évolueront plus rapidement.

Contrairement aux applications monolithiques géantes et étroitement couplées, les applications basées sur une architecture orientée microservices suivent un ou plusieurs modèles de conception spécifiques. Ces modèles de conception peuvent être l'un des suivants :

• Les modèles de décomposition consistent à diviser les applications en sous-domaines ou en transactions sur la base des capacités de l'entreprise.
• Les modèles d'intégration impliquent des modèles de conception d'intégration de services tels que la passerelle API, l'agrégateur, les microservices enchaînés, etc.
• Les modèles de base de données se concentrent sur la position des bases de données dans l'architecture globale des applications. Les exemples incluent les bases de données par service, les bases de données partagées, l'approvisionnement en événements, etc.
• Les modèles d'observabilité consistent en des modèles de conception axés sur l'audit, la journalisation et la surveillance, tels que l'agrégation de journaux, le traçage distribué, la vérification de l'état de santé, etc.
• Les modèles de préoccupations transversales aident à gérer les fonctionnalités au niveau de l'application, telles que la sécurité, la tolérance aux pannes, la communication de service à service et la gestion de la configuration dans un lieu centralisé. Les exemples incluent les disjoncteurs, la découverte des services, etc.

(Pour plus d'informations sur les différents modèles de conception de microservices, cliquez ici).

2. Choisir la bonne approche de microsegmentation

Il existe actuellement sur le marché plusieurs fournisseurs de solutions de microsegmentation avec des approches différentes. D'une manière générale, les techniques de microsegmentation se répartissent en deux catégories :

1. Les solutions de microsegmentation indépendantes de la technologie sont basées sur des agents ou des pare-feu de nouvelle génération.
2. Les solutions de microsegmentation dépendantes de la technologie sont basées sur l'hyperviseur ou les réseaux.

Les microservices utilisent une pile technologique variable, et le déploiement plus rapide exige une capacité d'évolution rapide. Par conséquent, une solution de microsegmentation agnostique sur le plan technologique, mais spécifiquement adaptée à un écosystème de conteneurs capable de segmenter les clusters, les pods, les conteneurs et les services, constituerait un choix optimal.

3. Visibilité du réseau

La possibilité de visualiser les applications segmentées et le flux de trafic fait partie intégrante des solutions de microsegmentation. La visibilité offre à l'administrateur, aux architectes de la sécurité et au responsable de la sécurité une vue d'ensemble de l'ensemble du réseau.

4. Contrôle centralisé facile à utiliser

L'élaboration d'une politique pour chaque application peut s'avérer une tâche décourageante au départ. Elle nécessite une série de conversations avec les architectes informatiques, de réseau et de sécurité. Le fait de disposer d'un contrôle centralisé pour faciliter la création et l'application des politiques permet d'accélérer le processus. L'utilisation des modèles de segmentation, qui sont personnalisés en fonction du modèle de conception des microservices, peut également s'avérer utile.

5. La performance ne doit pas être le goulot d'étranglement

L'application de politiques de microsegmentation nécessite l'analyse du trafic et le déploiement efficace de politiques en temps réel. L'attaquant peut tirer parti des retards de performance pour poursuivre l'attaque. Il est donc extrêmement important de tester les performances, en particulier pour les microservices sensibles à la latence.

Conclusion

Dans ce billet de blog, j'ai abordé certains des problèmes de sécurité présentés par les mécanismes de déploiement basés sur les conteneurs et Kubernetes utilisés par les microservices. Le mot "résilience" commence à disparaître lorsque nous déployons les microservices en production de manière continue tout au long du cycle de vie CI/CD, à un rythme plus rapide, sans trop se soucier de limiter l'accès aux ressources critiques. La microsegmentation offre un mécanisme de contrôle d'accès solide qui minimise l'impact des violations. Il favorise également la résilience des applications d'entreprise en mettant en place des microzones sécurisées.

La microsegmentation, lorsqu'elle est planifiée et exécutée correctement, crée assurément une barrière solide contre les mouvements latéraux dans le monde des microservices. Il est difficile de sécuriser les microservices tout en évoluant rapidement, mais il est important de s'arrêter et de réfléchir à la mise en œuvre de la sécurité et de la résilience à l'échelle et de la planifier de manière proactive avec toutes les parties prenantes.