Opérationnalisation de la confiance zéro - Étape 5 : Conception de la politique

Cette série de blogs développe les idées présentées dans mon article de mars, "La confiance zéro n'est pas difficile... si vous êtes pragmatique".

Dans ce billet, j'ai décrit six étapes pour parvenir à la confiance zéro, et j'aimerais ici développer l'une de ces étapes, à savoir la conception de la politique. Je vous montrerai comment cette étape peut soutenir la mise en œuvre d'un cadre solide qui peut être utilisé par tout praticien de la micro-segmentation 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 : Élaboration de la politique

Dans le dernier article de cette série, j'ai abordé la question de la "prescription des données nécessaires". Dans cet article, j'ai soulevé le point suivant :

"L'un des aspects les plus importants de la confiance zéro - et qui n'est pas suffisamment pris en compte - est que sa mise en œuvre efficace repose sur l'accès à des informations contextuelles, ou métadonnées, pour aider à formuler des politiques. Ainsi, lorsque l'on parle de micro-segmentation 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. Des é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 - elles comprennent 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. An la carte des dépendances des applications (dérivée des points 1 et 2), qui permet à un propriétaire d'application ou à un praticien de la segmentation de visualiser rapidement les dépendances en amont et en aval d'une application spécifique.

La mise en place de l'ensemble

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

• Vous souhaitez mettre en place une politique de micro-segmentation pour protéger vos charges de travail.
• Vous souhaitez que cette politique suive les principes de la confiance zéro.
• Par conséquent, les règles que vous élaborez ne doivent autoriser que l'accès aux charges de travail nécessaires à l'exécution de leur fonction.

Dans le prolongement des données que j'ai qualifiées de "nécessaires", vous trouverez ci-dessous des exemples d'entrées de journaux de trafic qui peuvent être utilisées pour élaborer une politique :

Connexion au journal de trafic 1 :

• Source : 10.0.0.1, 10.0.0.2
• Source Contexte : Serveur web, application de paiement, production, Royaume-Uni
• Destination : 192.168.0.1
• Destination : Contexte : DNS Responder, DNS Infrastructure, Production, UK o Destination Process : named
• Port : 53
• Protocole : UDP
• Action : Autoriser

Connexion au journal de trafic 2 :

• Source : 10.0.0.1,10.0.0.2
• Source Contexte : Serveur web, application de paiement, production, Royaume-Uni
• Destination : 10.0.1.5,10.0.1.6,10.0.1.7
• Contexte de destination : App Server, Payments Application, Production, UK
• Processus de destination : tomcat
• Port : 8080
• Protocol: TCP
• Action : Autoriser

Connexion au journal du trafic 3 :

• Source : 10.0.1.5, 10.0.1.6,10.0.1.7
• Source Contexte : App Server, Application de paiement, Production, UK
• Destination : 192.168.0.1
• Destination : Contexte : Répondant DNS, Infrastructure DNS, Production, UK
• Processus de destination : nommé
• Port : 53
• Protocole : UDP
• Action : Autoriser

Connexion au journal du trafic 4 :

• Source : 10.1.0.1,10.1.0.2
• Source Contexte : Serveur web, application de paiement, production, Allemagne
• Destination : 10.0.1.5,10.0.1.6,10.0.1.7
• Contexte de destination : App Server, Payments Application, Production, UK
• Processus de destination : httpd
• Port : 80
• Protocol: TCP
• Action : Autoriser

Connexion au journal du trafic 5 :

• Source : 10.1.2.1,10.1.2.2
• Source Contexte : 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 : App Server, Payments Application, Production, UK
• Processus de destination : httpd
• Port : 80
• Protocol: TCP
• Action : Autoriser

Vous pouvez ainsi obtenir rapidement la carte des dépendances de l'application.

Jusqu'à présent, tout va bien.

Vous pouvez maintenant consulter la carte des dépendances de votre application pour déterminer les flux que vous souhaitez autoriser. Sur la base de la connaissance de votre application, vous savez que les flux suivants sont nécessaires, par exemple :

1. Serveur Web, Paiements, Production, UK -> Répondeur DNS, Infrastructure DNS, Production, UK sur 53/udp
2. App Server, Paiements, Production, UK -> DNS Responder, Infrastructure DNS, Production, UK on 53/udp
3. Serveur Web, Paiements, Production, UK -> Serveur App, Paiements, Production, UK 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 App, 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 des dépendances de l'application que vous utiliserez pour élaborer des règles se présentera comme suit :

Maintenant, comment exprimez-vous concrètement ces règles ? Avec les pare-feu traditionnels, vous seriez obligé de les définir à l'aide des adresses IP source et destination. Mais en procédant de cette manière, vous supprimez complètement toutes les informations contextuelles dont vous avez bénéficié lors de la découverte de ces flux et, pire encore, cela signifie que ce contexte doit être réinséré lorsque la règle est réexaminée. De même, que se passe-t-il lorsque vous ajoutez un répondeur DNS supplémentaire ou un nouveau serveur d'application ou serveur Web pour l'application de paiement ?

Gardons à l'esprit que vous essayez d'élaborer une politique qui adhère aux principes de la confiance zéro, c'est-à-dire qui garantisse toujours le moindre privilège. Une approche basée sur le contexte, avec un moteur de sécurité adaptatif opérant en arrière-plan, facilite précisément cette démarche. Ainsi, tout comme votre politique s'élargit pour intégrer un nouveau serveur dans le contexte existant, vous voudrez également qu'elle se réduise lorsque vous mettez un serveur hors service. Si vous mettez à la retraite l'un de vos répondeurs DNS, par exemple, vous voudrez que toutes les règles qui autorisaient auparavant l'accès à ce répondeur soient mises à jour de manière à ce que cet accès ne soit plus possible. C'est exactement ce que le Policy Compute Engine (PCE) d'Illumio est censé faire - la politique de micro-segmentation est définie à l'aide de métadonnées, et le PCE détermine alors quelles charges de travail correspondent aux métadonnées à ce moment précis pour ensuite calculer les règles réelles qui doivent être appliquées à chaque charge de travail pour maintenir leur posture de sécurité Zero Trust. À chaque changement de contexte, le PCE adapte la politique et notifie les mises à jour aux charges de travail.

Dans cette optique, votre politique de confiance zéro se résume aux règles suivantes :

Règle 1 :

• Source : Serveur Web, Paiements, Production, Royaume-Uni
• Destination : Répondant DNS, Infrastructure DNS, Production, UK
• Service de destination : 53/udp
• Processus de destination : nommé

Règle 2 :

• Source : App Server, Paiements, Production, UK
• Destination : Répondant DNS, Infrastructure DNS, Production, UK
• Service de destination : 53/udp
• Processus de destination : nommé

Règle 3 :

• Source : Serveur Web, Paiements, Production, Royaume-Uni
• Destination : App Server, Paiements, Production, UK
• Service de destination : 8080/tcp
• Processus de destination : tomcat

Et c'est tout.

Prêt à passer à l'étape suivante de votre parcours Zero Trust ? Consultez notre page sur l'opérationnalisation de votre stratégie de confiance zéro avec la micro-segmentation pour en savoir plus.