Assurer la sécurité des données

Mendix pour le Cloud Privé assure la sécurité des données grâce à la mise en œuvre de TLS de plusieurs manières :

• « Entrée TLS » – est utilisé pour crypter le trafic entre un navigateur Web (ou un autre client HTTP) et le Mendix Durée.
• « Client TLS » – Les certificats clients (tels que vous pouvez les configurer dans le Runtime) sont utilisés par le serveur distant pour valider l'identité du Mendix Durée d'exécution. Simultanément, le Mendix Runtime utilise le certificat présenté par le serveur distant pour valider son identité.
• « Confiance TLS » – qui est utilisé pour faire confiance à une autorité de certification racine privée lors de la connexion à une base de données, un stockage de fichiers ou un registre. Les certificats racines approuvés valident l'authenticité du serveur distant et sont également utilisés lors de la connexion à d'autres services externes (par exemple, tout service REST ou SOAP consommé dans un Mendix app).

Alors, à quoi sert Service Mesh ? En fait, à quoi sert-il ? Commençons par comprendre les fondements d'une communication sécurisée.

Qu'est-ce que TLS ?

TLS (Transport Layer Security) est un protocole cryptographique qui garantit une communication sécurisée entre deux appareils sur un réseau potentiellement non fiable en cryptant les données, en vérifiant les identités et en préservant l'intégrité des données.

Les principaux composants sont:

• Deux clés, appelées clés publiques et privées.
• Les deux clés sont dotées d’une période d’expiration définie.
• Les données chiffrées par la clé publique ne peuvent être déchiffrées que par sa clé privée.
• Les données chiffrées par la clé privée ne peuvent être déchiffrées que par sa clé publique.

Comment fonctionne TLS ?

En un mot, le serveur dispose d'un certificat TLS et de la paire de clés. Le processus se déroule alors comme suit :

1. Le client se connecte au serveur.
2. Le serveur envoie son certificat TLS.
3. Le client vérifie le certificat du serveur (TLS handshake).
4. Le client et le serveur échangent des informations via une connexion TLS cryptée.

La clé ici est de comprendre que dans TLS, seul le client vérifie l’identité du serveur.

Ok, alors qu’est-ce que mTLS ?

Le protocole mTLS (Mutual Transport Level Security) est basé sur le protocole TLS. Le processus est très similaire, mais avec en plus le client qui apporte son propre certificat et sa propre paire de clés. En d'autres termes, le client et le serveur vérifient l'identité de l'autre.

Voici comment fonctionne mTLS :

1. Le client se connecte au serveur.
2. Le serveur envoie son certificat TLS.
3. Le client vérifie le certificat du serveur (TLS handshake).
4. Le client envoie son certificat TLS.
5. Le serveur vérifie le certificat du client (poignée de main TLS, encore une fois).
6. Ensuite, la connexion est établie via un canal sécurisé.

Alors, que sont les maillages de services ?

Un maillage de services est une infrastructure réseau qui fonctionne au sein d'une architecture de microservices. Son objectif principal est d'améliorer la sécurité et de gérer le chiffrement des données lors de leur transfert entre ces services.

Dans le cadre de cet article, je me concentrerai uniquement sur trois des nombreuses fonctionnalités qu’un service mesh peut offrir :

• Chiffrement de service à service : Un maillage de services utilise TLS et mTLS pour crypter et authentifier ces communications interservices.
• Gestion des certificats : Un service mesh simplifie la gestion des certificats TLS en automatisant l’émission, la rotation et la distribution des certificats.
• Réseautage Zero Trust : Les maillages de services adoptent souvent une approche « zero trust », ce qui signifie que la communication entre les services n’est pas approuvée par défaut. TLS et mTLS jouent un rôle crucial dans cette approche, car ils vérifient l’identité des parties communicantes et chiffrent les données, même au sein de réseaux de confiance.

Service mesh dans Mendix pour le Cloud privé

Pour cette démonstration, le module de déploiement officiel Terraform pour AWS EKS a été utilisé pour provisionner le cluster Kubernetes. Par conséquent, l'infrastructure configurée offre dès le départ les fonctionnalités clés suivantes :

• A Mendix Opérateur et agent configurés dans un espace de noms appelé « mendix ».
• Une connexion sécurisée établie (TLS) entre Mendix applications et composants essentiels comme la base de données, le stockage et le registre.
• Une connexion sécurisée établie entre l'équilibreur de charge et le Mendix charges de travail.

L'objectif ici est donc de permettre à un Service Mesh de garantir une mise en réseau Zero Trust : tous les pods communiqueront avec tous les services Kubernetes internes de manière sécurisée avec TLS mutuel.

Autre chose ? Oui, nous allons également inclure le contrôleur Ingress dans le « maillage » pour sécuriser tout le trafic externe acheminé vers les pods.

Cela semble excitant?

Peut-être déroutant ?

Peut-être que quelques diagrammes seraient utiles :

Voilà où nous en sommes maintenant…

Noter la Mendix Les portails Agent et Développeur ne s'appliquent qu'au mode connecté

…et voici notre état final souhaité :

À partir de la version 2.5, Mendix L'opérateur est compatible avec Istio et Linkerd, pour les offres connectées et autonomes.

Pour garder cela simple, j'explorerai et activerai uniquement Linkerd, mais le processus pour Istio est très similaire.

Installation de Linkerd

Suivez l' documentation officielle à installer:

• Linkerd CLI, selon votre système d'exploitation.
• CRD Linkerd
• Extensions Linkerd (viz et dashboard sont tous deux fortement recommandés)

Mendix pour l'injection de maillage de Cloud privé

Une fonctionnalité plutôt cool dans Mendix pour le Cloud privé, l'« injection » de maillage peut être activée soit par environnement (idéal pour un test de validation rapide ou un isolement) soit pour l'ensemble de l'espace de noms.

Consultez l'image ci-dessous pour une référence rapide sur la façon d'activer Linkerd, mais consultez la documentation officielle pour Connectée et Standalone pour plus de détails.

Activation de Linkerd pour un environnement

Tout d’abord, l’annotation Linkerd sera activée directement depuis le portail des développeurs pour une application appelée terrapp1.

Comme vous pouvez le voir, une fois activé et les modifications appliquées, le Mendix Le Pod redémarre et le tableau de bord Linkerd détecte l'annotation et marque le Pod comme maillé :

Super, notre première application a maintenant été ajoutée avec succès à Linkerd et mTLS est déjà en action.

Activation de Linkerd pour l'ensemble de l'espace de noms

Passons à l'étape suivante, qui consiste à ajouter l'ensemble Mendix espace de noms au maillage, sécurisant la connexion entre l'opérateur, l'agent et l'application !

Comme le montre la vidéo ci-dessous, nous devons :

1. Annoter l'ensemble de l'espace de noms (appelé « mendix ») pour l'injection Linkerd
2. Confirmez que l’annotation a été ajoutée à l’espace de noms en examinant la configuration.

Remarque : si les pods ne sont pas ajoutés automatiquement au maillage, il est recommandé de réduire et d'augmenter chaque déploiement :

• • Déploiement à l'échelle de Kubectl Mendix-operator —réplicas=0
  • Déploiement à l'échelle de Kubectl Mendix-Agent —réplicas=0
  • Répétez l'opération ci-dessus en ajoutant des répliques = 1

Wohoo ! Nous nous rapprochons désormais de l'objectif de mise en réseau Zero Trust. Déployons une nouvelle application depuis le portail des développeurs et voyons comment elle est automatiquement ajoutée au maillage !

Ajout de l'entrée NGINX au maillage

Dans la plupart des configurations client, Terminaison TLS est configuré dans le contrôleur d'entrée qui réside dans le cluster Kubernetes. En termes simples, cela signifie que le trafic entrant externe arrive au service d'entrée chiffré (TLS) et qu'il est servi au Pod sans chiffrement (http simple).

Notre dernière étape ici consiste également à garantir mTLS entre le contrôleur d'entrée et tous les services au sein du Mendix espace de noms. Pour ce faire, nous devons :

• Ajoutez le déploiement du contrôleur d’entrée NGINX dans le maillage. Suivez les instructions selon la façon dont vous avez installé NGINX dans votre cluster (helm ou depuis YAML).
• Assurez-vous d'ajouter thenginx.ingress.kubernetes.io/service-upstream annotation correctement pour garantir que le contrôleur n'utilise pas les points de terminaison du Pod, mais utilise à la place l'adresse IP et le port du cluster du service.

Il est maintenant temps de confirmer qu'une fois Nginx ajouté au maillage, tout le trafic vers les pods utilise mTLS :

NGINX est maillé et envoie en toute sécurité le trafic vers Mendix Application

Conclusion

L’importance d’une architecture de service mesh robuste ne peut être surestimée et sa capacité à fournir une visibilité granulaire, une communication sécurisée et l’application des politiques au sein d’un environnement de microservices est primordiale pour la protection des données et des systèmes.

Tirer parti Mendix L'intégration transparente de Private Cloud avec Istio et Linkerd permet aux organisations d'atteindre un mélange harmonieux d'agilité et de sécurité. MendixLes capacités de développement rapide de complètent les mesures de sécurité rigoureuses d'un maillage de services, permettant aux entreprises d'innover sans compromettre leur posture de défense.

À l’ère des menaces en constante évolution, la fusion du maillage de services et Mendix for Private Cloud illustre une approche tournée vers l’avenir en matière de sécurité de l’information.

Bon maillage !