Ce qui est bien avec NSX-T c’est qu’on peut faire absolument ce qu’on veut avec le distributed firewall et les routeurs TIER0/TIER1 en matière de règles de sécurité, y compris n’importe quoi… un peu compliqué, déstabilisant, même. Du coup, quand on se retrouve à organiser et planifier la sécurité générale d’un tel produit avec à terme plusieurs milliers de VMs, les directions à prendre sont tellement nombreuses qu’il est difficile de trouver “la bonne voie” pour son cas précis, même avec de l’aide.

Malgré tout, il a fallu faire des choix pour démarrer et surtout éviter trop de redondance dans les règles entre les flux Est-Ouest (DFW) et les flux Nord-Sud (TIERx). Je vous propose de vous présenter notre stratégie de départ, qui a au moins le mérite, je pense, de respecter la philosophie de NSX-T tout en assurant un passage en douceur vers la micro-segmentation et le tout sécurisé.

Respecter les règles globales, autant que faire se peut

Les règles de bases et les concepts édictées dans la docs et représentées graphiquement dans l’interfaces de NSX sont assez précises pour ce qui concerne le DFW. En effet, dans la partie Est-Ouest, vous disposez de 5 sections bien distinctes pour trier vos politiques et vos règles : Ethernet, Emergency, Infrastructure, Environnement, Application. Ces sections ne sont pas là par hasard, elles permettent de pouvoir organiser au minimum votre politique de sécurité interne. Vous pouvez consulter la documentation NSX ici même qui décrit chacune de ces sections.

D’autre part, du coté des routeurs TIERx, là aussi, vous pouvez plus classiquement mettre en place des règles de filtrage, gérées directement par les Service Routeurs associés à vos routeurs. On travaille ici avec des flux Nord-Sud. Dans la pratique, une machine virtuelle peut en même temps fournir un service nord-sud et est-ouest. Du coup, vous avez la possibilité de filtrer à deux niveaux, mais vous êtes de facto contraint, si vous souhaitez rester très précis, de créer des règles quasi en trois exemplaires : une pour l’ouverture en est-ouest et une seconde sur le routeur tier-1 et une enfin sur le routeur tier-0. En tout cas, rien ne vous en empêche techniquement. Il faut aussi savoir que par défaut, tout routeur est “passant” et ne filtre pas ce qui oblige aussi faire une gymnastique intellectuelle dont on a pas l’habitude (fermer les flux interdits, plutôt que de n’ouvrir que ceux autorisés).

Enfin, NSX vous permet de configurer le distributed firewall lui-même en mode “blacklist” ou “whitelist”. Dans le mode Blacklist, par défaut vous autorisez tous les flux, vos règles ayant surtout un rôle de filtrage. Dans l’autre, plus classique pour un firewall, vous bloquez tout et vous autorisez explicitement certains flux.

Il faut se lancer …

La première décision concerne les deux niveau de routing TIER0/TIER1. Pour nous, le TIER0 doit au maximum rester un pur routeur périmétrique et nous avons donc fait le choix de n’implanter aucune règle de sécurité sur ce niveau (pour l’instant du moins). Tous les flux entrants et sortants sont gérés uniquement via les règles de routage (routes statiques et BGP).

Le TIER1 détermine chez nous un client et ses services associées. De ce coté, nous avons placé une règle par défaut rejetant tous les flux et mis en place des politiques très générales travaillant sur des flux réseau in-out mais pas au niveau VMs : range d’IPs autorisés, services fournis en interne, etc. Cela permet de se concentrer sur “les grosses masses” et, grâce à la règle par défaut, de travailler dans un mode plus habituel sur des règles positives et non négatives.

Ensuite, coté DFW, nous avons mis en oeuvre des règles sur la plupart des sections ad-hoc, en finissant pas la partie la plus granulaire avec des groupes spécifiques de VMs. Nous avons finalement choisi le mode whitelist, qui nous paraissait le plus naturel et définitif.

Nous utilisons NSX-T pour deux use cases bien distincts (comme déjà évoqué dans un précédent billet), un premier en mode full overlay dédié à notre activité d’hébergement, le second en mode vlan, permettant de sécuriser progressivement nos VMs déjà en production sur nos datacenter, via la mise en oeuvre de la micro-segmentation. Sur ce dernier cas, et afin de pouvoir dé-corréler la migration des VMs sur les segments de NSX-T et l’activation de la micro-segmentation sur ces même machines, nous avons mis en place une règle spéciale basée sur un tag dit “microseg”. Toute VM qui dispose de ce tag est microsegmentée. Elle hérite donc de la sécurité en mode whitelist. Si une VM ne dispose pas de ce tag (par défaut c’est donc le cas), la règle en question bypasse la sécurité et autorise par défaut les flux. On dispose ainsi du meilleur des deux mondes : on reste en mode “whitelist” pour le DFW mais celui-ci ne filtre réellement que lorsque la VM est prête (tagguée).

Cartographie mon amour

D’autre part, nous allons nous lancer dans une analyse de la carthographie des flux remontés par vRealize Network Insight afin de s’occuper progressivement des applications legacy. Cela va prendre du temps, mais c’est à notre avis le seul moyen de vraiment identifier les flux, n’en oublier aucun et pouvoir travailler plus sereinement activer la micro-segmentation. La cartographie vRNI est au passage un outil vraiment exceptionnel pour commencer à gérer globalement la sécurité, je vous ferai, quand je serai plus acéré sur le produit, une petite découverte graphique de ce qu’on est capable de retirer des informations récoltées.

Pour toutes les nouvelles applications : JE NE VEUX VOIR QU’UNE SEULE TETE !

Nous allons également nous préparer à intégrer le process d’identification des flux applicatifs et de micro-segmentation associé à partir d’une date encore à définir (avant la fin de l’année c’est certain). Cela va être compliqué au début, surtout face à certains de nos fournisseurs qui n’ont pas dépassé les années 80 en matière d’informatique, certes. Cependant, ce sera nécessaire, après une phase d’apprentissage, autant pour nos équipes internes que pour l’ensemble de nos partenaires externes, comme l’a été en son temps la prise en compte progressive de la virtualisation et les règles de bonne pratiques associées. C’est d’autant plus important que tout le travail de fond que nous menons en matière de certification ISO (27k principalement) nous obligeront tôt ou tard à maîtriser aussi cet aspect de la production interne.

Les fondamentaux : les Tag,les segments et les appID

Pour terminer, je tiens à mettre en avant le fait que nous avons pas mal tâtonné au début avec la mise en place des politiques de sécurité. En effet, NSX offre un large choix d’outils de sélections des objets sur lesquels on va s’appuyer pour construire nos règles. Il est même possible de travailler “à l’ancienne” on créant des groupes de sécurité contenant exclusivement des IPs ou de Ranges d’IP.

Progressivement, nous avons pris conscience que NSX avait beaucoup plus à offrir en matière de souplesse grâce à l’usage de trois concepts : les tags, les objets réseau et les appID.

Pour les tags j’en ai déjà parlé lors de la description de notre règle de micro-segmentation, c’est de loin la meilleure méthode pour sélectionner dynamiquement des objets NSX et des VMs et leur appliquer des règles. On parle ici d’un tag au sens NSX-T. N’espérez pas ré-utiliser les tags vSphere, il faut tout reconstruire, ou répliquer par automation éventuellement (il n’existe pas à l’heure actuelle de processus de synchronisation des tags entre vSphere et NSX-T). Vous pouvez en outre tagguer, en plus des VMs, a peu près n’importe quel objet NSX : segment, routeur, port … ça donne surement des idées à certains ^^.

Nous avons utilisé aussi ponctuellement les segments logiques pour créer des règles. Par exemple : une règle porte sur tous les segments de type VLAN (que l’on met dans un security group), une autre va porter sur l’ensemble des segments présent dans un tenant etc. Cela permet d’adresser l’ensemble des machines connectées aux segments en question plutôt qu’à sélectionner l’ensemble de machines actuelles et futures via un autre critère (tag par exemple). Très utile pour réaliser un filtre “par défaut” sur tout un domaine applicatif ou un tenant.

Nous avons également utilisé les appID, une fonction très intéressante permettant d’identifier le flux applicatif (L7) pour l’autoriser globalement, sans être obligé de préciser le/les ports ou même la direction du/des flux. Vous voulez autoriser une VM à faire du CIFS. Vous lui autorisez l’accès à l’appID “CIFS” et le tour est joué. Ces appID sont utilisable à travers les “context profiles”. Il en existe beaucoup, cela permet de gagner beaucoup de temps dans l’établissement de vos règles tout en les rendant bien plus claires à ceux qui les consultent pour la première fois.

On est capable enfin d’autoriser uniquement l’accès, par exemple, au service “Windows Update”, qui correspond derrière à un ensemble de services web identifiés par des FQDN chez Microsoft. Sur le principe c’est parfait, malheureusement, aujourd’hui en 2.4.1, la liste est figée et ne comportent qu’une centaine d’URL. Impossible d’en ajouter d’autres spécifiques à votre environnement où à d’autres webservices que ceux connus par NSX (ça va sans doute évoluer en 2.5 ou 3.0… à suivre !).

Ce n’est que le début …

Il est clair aujourd’hui qu’on est qu’au début de notre réflexion et de notre maturité sur la sécurité NSX-T, mais tous les tests et les questions que nous nous sommes déjà posé nous permettent au moins de démarrer notre production avec un périmètre et une organisation des politiques relativement clair. C’est important d’y voir clair, n’est-ce pas, surtout en matière de sécurité, pour éviter les trous béants ou des règles trop touffues ou redondantes. Qui n’a pas déjà pesté sur ses centaines de règles de firewall impossibles à dé-tricoter ? J’en vois un qui lève le bras tout au fond … soit il ment, soit il a des problèmes de mémoire ^^

N’hésitez-pas à m’indiquer quels ont été vos choix au début, de votre coté ? comment avez-vous géré la séparation Est-Ouest et Nord-Sud par exemple (vaste sujet) ?

Et tiens, j’en profite pour vous rappeler que je serai au VMGFR à Paris le 26 Septembre prochain, précisément pour un retour d’expérience de mise en oeuvre de NSX-T chez nous. Ce sera la meilleure occasion pour en discuter ! J’espère vous y retrouver !