Créez des microservices résilients et sécurisés grâce à la microsegmentation

Cet article a été initialement publié dans Le nouveau Stack.

Il y a environ 10 à 12 ans, le monde des logiciels a connu une évolution des aspects architecturaux des applications d'entreprise. Les architectes et les concepteurs de logiciels ont commencé à abandonner les applications monolithiques géantes, étroitement couplées et déployées dans les centres de données privés pour adopter une architecture davantage axée sur les microservices hébergée dans une infrastructure de cloud public. La nature distribuée inhérente aux microservices constitue un nouveau défi de sécurité dans le cloud public. Au cours de la dernière décennie, malgré l'adoption croissante d'une 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 cloud par rapport aux centres de données traditionnels. Cela inclut les préoccupations liées à la multilocation et au manque de visibilité et de contrôle de l'infrastructure, ainsi que de l'environnement opérationnel. Ce changement d'architecture complique la réalisation des objectifs de sécurité, notamment en raison de l'importance primordiale accordée à des déploiements plus rapides basés sur des conteneurs.

Le but 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 sécurité informatique de créer des microservices sécurisés et résilients. Plus précisément, je parlerai de sécurité du réseau défis associés au célèbre mécanisme d'orchestration de conteneurs Kubernetes, et je vais illustrer l'intérêt de la microsegmentation pour empêcher les mouvements latéraux en cas de violation.

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

L'architecture orientée microservices nécessite de diviser les applications en services plus petits et faiblement couplés. En raison de la nature distribuée de ces services, ils finissent souvent par disposer de leurs propres banques de données. Chacun de ces services est déployé indépendamment à l'aide d'un conteneur, qui permet à une application de tout empaqueter, qu'il s'agisse de code objet, de bibliothèques tierces, de systèmes d'exploitation, d'outils et d'autres dépendances. Une fois que toutes les nécessités sont emballées, les conteneurs fournissent l'environnement d'exécution nécessaire à leur bon fonctionnement. Ces conteneurs sont gérés à l'aide d'orchestrateurs tels que Kubernetes.

Selon l'idée populaire, l'écosystème de conteneurs est conçu pour renforcer la sécurité grâce à l'isolation. Cependant, l'isolation entre les conteneurs ne fournit pas nécessairement les limites de sécurité requises. Kubernetes propose plusieurs fonctionnalités de sécurité telles que l'authentification, l'autorisation, la politique 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 de Kubernetes donnent la priorité aux fonctionnalités plutôt qu'à la sécurité dans leur configuration par défaut. Par conséquent, un développeur ou un ingénieur en fiabilité responsable de la création, du déplacement et de la destruction de ces conteneurs ne sait pas toujours comment garantir la sécurité des déploiements. Examinons de plus près certains des aspects importants de Kubernetes du point de vue de la mise en 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 aucun segmentation du réseau. Notez qu'un espace de noms n'est pas une limite de sécurité et que, par conséquent, les services d'un espace de noms peuvent accéder à des services d'un autre espace de noms.
2. Politique du réseau : La politique réseau Kubernetes est une structure spécifique à l'application qui permet la communication entre les couches 3 et 4 entre les espaces de noms, les pods et les blocs d'adresses IP. Lorsque Kubernetes est installé, la politique réseau n'est pas disponible par défaut. Il faut installer et configurer des plugins réseau pour appliquer les politiques réseau avant de créer des pods. Il convient également de noter que les politiques réseau ne peuvent pas être appliquées au niveau du service. Il s'agit d'une lacune importante du point de vue de la sécurité, étant donné que le contrôle d'accès ne peut pas être étendu aux services.
3. Norme de sécurité des pods : Dans un cluster, les pods prennent en charge plusieurs conteneurs qui partagent la même machine physique ou virtuelle. Ils permettent le partage de données et la communication entre les conteneurs du pod. Une norme de sécurité des pods permet à un administrateur de contrôler les ressources et leurs autorisations à l'aide d'un modèle d'autorisation précis. Ce contrôle de sécurité nécessite un contrôleur d'admission, qui n'est pas activé par défaut. Un module privilégié offre un accès administratif à tous les conteneurs. Par conséquent, l'attaquant qui obtient l'accès à des conteneurs privilégiés peut obtenir un accès administratif aux ressources de l'hôte.
4. Stockage secret : Kubernetes stocke les informations sensibles et confidentielles telles que les mots de passe, les jetons OAuth et les clés SSH sous forme de secrets sous forme codée en base 64, considérée comme du texte en clair. La politique d'autorisation, qui est utilisée pour restreindre l'accès aux secrets, n'est pas configurée par défaut. Ils sont partagés via des variables environnementales 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 en l'absence de gestion robuste des secrets, les secrets deviennent une cible attrayante pour les mouvements latéraux.

Les mouvements latéraux 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 être capables de communiquer entre eux via des espaces de noms. Cependant, les politiques réseau par défaut au niveau de la couche de cluster n'implémentent pas nécessairement le principe du moindre privilège sorti de la boîte. 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 à des mouvements latéraux au sein de la grappe. 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, réduisant ainsi de manière significative le rayon d'explosion et augmentant la résilience pour se remettre d'une attaque réussie.

La deuxième menace majeure que présente le modèle de sécurité du framework Kubernetes existant 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 de politiques strictes de contrôle d'accès ou d'autorisation, des attaques telles que la falsification des requêtes côté serveur (SSRF) permettent à l'attaquant de tirer parti d'un accès authentifié à un espace pour obtenir un accès non autorisé aux ressources d'un autre espace.

Comme indiqué ci-dessus, nous avons constaté que des contrôles de sécurité adéquats ne sont pas disponibles pour protéger les secrets par défaut. Le fait de ne pas chiffrer et de modifier les secrets, ainsi que de ne pas restreindre l'accès aux secrets, sont en effet des problèmes indépendants, mais en l'absence d'un contrôle de sécurité (dans ce cas, absence de cryptage), le second contrôle de sécurité (c'est-à-dire la restriction de l'accès aux magasins secrets) devient crucial pour éviter toute exploitation par un initié malveillant (par exemple, un administrateur mécontent).

Présentation de la cyberrésilience grâce à la microsegmentation

Dans le contexte de la sécurité, la résilience est la capacité à se remettre rapidement d'une panne simple due à des attaques ou à des événements catastrophiques tels que des violations. La première étape de la création de microservices résilients consiste à comprendre ce que nous voulons protéger contre 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 les données essentielles ou les systèmes critiques tolérants aux 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 ne sont pas touchées.

Le cycle de vie de développement logiciel moderne d'aujourd'hui met particulièrement l'accent sur la fourniture rapide de fonctionnalités. Ces fonctionnalités sont déployées en production via des conteneurs encore plus rapidement, principalement par les mêmes développeurs ou DevOps. Si nous prenons en compte tous les types de vulnérabilités auxquelles sont exposés le code des microservices, des bibliothèques tierces et d'autres dépendances, des conteneurs ou des clusters, comment pouvons-nous identifier et prévenir toutes ces attaques ? La solution est de bloquer l'accès aux ressources critiques et de ne les autoriser que sur la base du « besoin de savoir » en utilisant la microsegmentation.

Commencez à utiliser la microsegmentation

Il n'existe pas de stratégie universelle pour démarrer avec la microsegmentation, mais voici quelques bonnes pratiques lorsque vous lancez un projet de microsegmentation pour les microservices :

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

La connaissance des 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 à adapter plus rapidement.

Contrairement aux applications monolithes géantes é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 impliquent la division des applications en sous-domaines ou en transactions en fonction 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 chaî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 la base de données par service, la base de données partagée, la recherche d'é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 des journaux, le traçage distribué, le bilan de santé, etc.
• Les modèles de préoccupations transversaux aident à gérer les fonctionnalités au niveau des applications telles que la sécurité, la tolérance aux pannes, la communication service à service et la gestion de la configuration dans un emplacement centralisé. Les exemples incluent un disjoncteur, une découverte de service, etc.

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

2. Choisir la bonne approche de microsegmentation

Il existe actuellement sur le marché plusieurs fournisseurs de microsegmentation proposant différentes approches de solutions. 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 soit basées sur des agents, soit pare-feux de nouvelle génération.
2. Les solutions de microsegmentation dépendantes de la technologie sont basées sur l'hyperviseur ou les structures réseau.

Les microservices font appel à une pile technologique variée, et leur déploiement rapide exige une capacité d'évolution rapide. Par conséquent, une solution de microsegmentation indépendante de la technologie, mais spécialement adaptée à un écosystème de conteneurs capable de segmenter des clusters, des pods, des conteneurs et des services, serait un choix optimal.

3. Visibilité du réseau

La capacité de visualiser les applications segmentées et le flux de trafic fait partie intégrante des solutions de microsegmentation. Visibility offre à l'administrateur, aux architectes de sécurité et au directeur de la sécurité (CSO) une vue unique de l'ensemble du réseau.

4. Contrôle centralisé facile à utiliser

La rédaction d'une politique pour chaque application peut être une tâche ardue au début. Cela 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 contribue à accélérer le processus. L'utilisation des modèles de segmentation, qui sont personnalisés selon le modèle de conception des microservices, peut également être utile.

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

L'application de politiques de microsegmentation nécessite d'analyser le trafic et de déployer des politiques de manière efficace en temps réel. L'attaquant peut tirer parti des retards de performance pour renforcer 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 problèmes de sécurité liés aux 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 tenir compte de la limitation de l'accès aux ressources critiques. La microsegmentation offre un puissant mécanisme de contrôle d'accès qui minimise l'impact des violations. Il favorise également la résilience des applications d'entreprise en mettant en œuvre des microzones sécurisées.

La microsegmentation, lorsqu'elle est planifiée et exécutée correctement, constitue certainement 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 réfléchir à la mise en œuvre de la sécurité et de la résilience à grande échelle et de les planifier de manière proactive avec toutes les parties prenantes.