Mise en œuvre du Zero Trust — Étape 5 : Conception de la politique

Cette série de blogs développe les idées présentées dans mon billet de mars, »Zero Trust n'est pas difficile... Si vous êtes pragmatique. »

Dans ce billet, j'ai décrit six étapes pour atteindre Zero Trust, et je voudrais ici développer l'une de ces étapes, à savoir la conception de la politique. Je vais vous montrer comment cette étape peut favoriser la mise en œuvre d'un cadre solide qui peut être utilisé par tout praticien de la microsegmentation pour améliorer la réussite de ses projets, quelle que soit la taille de l'organisation.

Avant de commencer, voici un rappel des six étapes :

Étape 5 : Conception de la politique

Dans le dernier post à partir de cette série, j'ai examiné la question de « prescrire les données nécessaires ». Dans cet article, j'ai fait le point suivant :

« L'un des aspects les plus importants de Zero Trust, qui est loin d'être couvert autant qu'il le devrait, est que la mise en œuvre efficace de Zero Trust repose sur l'accès aux informations contextuelles, ou métadonnées, pour aider à formuler des politiques. Ainsi, lorsqu'il est question de microsegmentation dans le contexte de la protection des charges de travail, les métadonnées minimales en dehors d'un rapport de trafic standard dont vous avez besoin décrivent les charges de travail dans le contexte des applications et des environnements de votre centre de données. »

Sur la base de cette déclaration, les trois données clés dont nous avons besoin sont les suivantes :

1. Événements de trafic en temps réel pour les charges de travail que nous voulons protéger.
2. Données contextuelles pour chaque charge de travail et connexion — cela inclut les métadonnées associées à la charge de travail qui proviendraient d'un système d'enregistrement, tel qu'une CMDB, ainsi que des informations telles que les détails du processus de communication provenant directement de la charge de travail. '
3. Un carte des dépendances des applications (dérivé des éléments 1 et 2) qui permet au propriétaire d'une application ou à un praticien de la segmentation de visualiser rapidement les dépendances en amont et en aval d'une application spécifique.

Assembler le tout

Vous êtes donc presque prêt à élaborer cette politique, mais permettez-moi de vous rappeler les objectifs :

• Vous souhaitez élaborer une politique de microsegmentation pour protéger vos charges de travail.
• Vous souhaitez que cette politique suive les principes de Zero Trust.
• Par conséquent, les règles que vous créez doivent autoriser uniquement l'accès aux charges de travail nécessaires à l'exécution de leurs fonctions métier et en sortir.

Sur la base des données que j'ai qualifiées de « nécessaires », vous trouverez ci-dessous des exemples de quelques entrées du journal de trafic qui peuvent être utilisées pour élaborer une politique :

Connexion au journal de trafic 1 :

• Les sources : 10.0.0.1, 10.0.0.2
• Contexte source : serveur Web, application de paiement, production, Royaume-Uni
• Destination : 192.168.0.1
• Destination : Contexte : répondeur DNS, infrastructure DNS, production, Royaume-Uni o Processus de destination : nommé
• Hafen : 53
• Protocole : UDP
• Action : Autoriser

Connexion au journal de trafic 2 :

• Source : 10.0.0.1, 10.0.0.2
• Contexte source : serveur Web, application de paiement, production, Royaume-Uni
• Destination : 10.0.1.5, 10.0.1.6, 10.0.1.7
• Contexte de destination : serveur d'applications, application de paiement, production, Royaume-Uni
• Processus de destination : Tomcat
• Hafen : 8080
• Protocole : TCP
• Action : Autoriser

Connexion au journal de trafic 3 :

• Sources : 10.0.1.5, 10.0.1.6, 10.0.1.7
• Contexte source : serveur d'applications, application de paiement, production, Royaume-Uni
• Destination : 192.168.0.1
• Destination : Contexte : répondeur DNS, infrastructure DNS, production, Royaume-Uni
• Processus de destination : nommé
• Hafen : 53
• Protocole : UDP
• Action : Autoriser

Connexion au journal de trafic 4 :

• Source : 10.1.0.1, 10.1.0.2
• Contexte source : serveur Web, application de paiement, production, Allemagne
• Destination : 10.0.1.5, 10.0.1.6, 10.0.1.7
• Contexte de destination : serveur d'applications, application de paiement, production, Royaume-Uni
• Processus de destination : httpd
• Hafen : 80
• Protocole : TCP
• Action : Autoriser

Connexion au journal de trafic 5 :

• Source : 10.1.2.1, 10.1.2.2
• Contexte source : serveur de base de données, application de paiement, production, Allemagne
• Destination : 10.0.1.5, 10.0.1.6, 10.0.1.7
• Contexte de destination : serveur d'applications, application de paiement, production, Royaume-Uni
• Processus de destination : httpd
• Hafen : 80
• Protocole : TCP
• Action : Autoriser

Grâce à cela, vous pouvez rapidement dériver la carte des dépendances des applications.

Jusqu'ici, tout va bien.

Vous pouvez maintenant consulter la carte de dépendance de votre application pour déterminer les flux que vous souhaitez réellement autoriser. Sur la base de la connaissance de votre application, vous savez que les flux suivants sont requis, par exemple :

1. Serveur Web, paiements, production, Royaume-Uni -> Répondeur DNS, infrastructure DNS, production, Royaume-Uni sur 53/udp
2. Serveur d'applications, paiements, production, Royaume-Uni -> Répondeur DNS, infrastructure DNS, production, Royaume-Uni sur 53/udp
3. Serveur Web, paiements, production, Royaume-Uni -> Serveur d'applications, paiements, production, Royaume-Uni sur 8080/tcp

Vous savez également que les deux flux suivants ne semblent pas corrects et ne devraient donc pas être inclus dans vos règles initiales :

1. Serveur Web, paiements, production, Allemagne -> Serveur d'applications, paiements, production, Royaume-Uni sur 80/tcp
2. Serveur de base de données, paiements, production, Allemagne -> Serveur d'applications, paiements, production, Royaume-Uni sur 80/tcp

La carte de dépendance des applications que vous utiliserez pour créer des règles finira par ressembler à ceci :

Maintenant, comment exprimez-vous réellement ces règles ? Avec les pare-feux traditionnels, vous seriez obligé de les définir à l'aide des adresses IP source et de destination. Mais procéder de cette façon supprime complètement toutes les informations contextuelles riches dont vous avez bénéficié lors de la découverte de ces flux et, pire encore, signifie que ce contexte doit être réinséré lorsque la règle est en cours de révision. Que se passe-t-il également lorsque vous ajoutez un répondeur DNS supplémentaire ou un nouveau serveur d'applications ou un nouveau serveur Web pour l'application de paiement ?

N'oublions pas que vous essayez d'élaborer une politique qui adhère aux principes Zero Trust, à savoir garantir qu'il s'agit toujours du moindre privilège. Une approche contextuelle, avec un moteur de sécurité adaptatif opérant sa magie en arrière-plan, facilite exactement cela. Ainsi, au fur et à mesure que votre politique s'étend pour intégrer un nouveau serveur dans le contexte existant, vous souhaiterez également que votre politique soit réduite lorsque vous mettez un serveur hors service. Si vous retirez l'un de vos répondeurs DNS, par exemple, vous souhaiterez que toutes les règles qui autorisaient auparavant l'accès vers/depuis celui-ci soient mises à jour afin que cet accès ne soit plus possible. C'est exactement ce que propose Illumio Moteur de calcul des politiques (PCE) est censé fonctionner : la politique de microsegmentation est définie à l'aide de métadonnées, puis le PCE détermine quelles charges de travail correspondent aux métadonnées à un moment donné pour calculer les règles réelles qui doivent être appliquées à chaque charge de travail afin de maintenir leur posture de sécurité Zero Trust. Chaque fois qu'il y a un changement de contexte, le PCE adapte la politique et informe les charges de travail des mises à jour.

Dans cette optique, votre politique Zero Trust se résume aux règles suivantes :

Règle 1 :

• Source : serveur Web, paiements, production, Royaume-Uni
• Destination : répondeur DNS, infrastructure DNS, production, Royaume-Uni
• Service de destination : 53/udp
• Processus de destination : nommé

Règle 2 :

• Source : App Server, Payments, Production, Royaume-Uni
• Destination : répondeur DNS, infrastructure DNS, production, Royaume-Uni
• Service de destination : 53/udp
• Processus de destination : nommé

Règle 3 :

• Source : serveur Web, paiements, production, Royaume-Uni
• Destination : serveur d'applications, paiements, production, Royaume-Uni
• Service de destination : 8080/TCP
• Processus de destination : Tomcat

Et c'est tout.

Êtes-vous prêt à passer à l'étape suivante de votre parcours Zero Trust ? Visitez notre page sur la façon de mettre en œuvre votre stratégie Zero Trust grâce à la microsegmentation pour en savoir plus.