Microsegmentatie met Nutanix Flow

Ronald de Jong

Sinds een aantal jaren heeft PQR een sterk partnerschap met Nutanix. Een zeer succesvolle samenwerking en al vele klanten hebben gekozen voor een implementatie van een Nutanix omgeving. Nutanix biedt de mogelijkheid om gebruik te maken van externe hypervisors, zoals VMware vSphere, Citrix XenServer en Microsoft HyperV, maar het biedt ook de mogelijkheid om gebruik te maken van een eigen hypervisor, genaamd Acropolis Hypervisor (afgekort als AHV). Deze hypervisor is gebaseerd op een open standaard, te weten KVM (Kernel-based Virtual Machine) en heeft in de afgelopen jaren een hoop functionaliteiten toegevoegd gekregen, waardoor het een serieuze concurrent is geworden voor de eerdergenoemde marktleiders in dit segment.

Zoals frequente volgers van mijn blogs en tweets weten, houd ik me vooral bezig met het Software Defined DataCenter en dan met name op het gebied van de VMware portfolio. Eén van de onderdelen daarin is VMware NSX, een netwerkvirtualisatie platform, waar onder andere microsegmentatie mee mogelijk is.

Sinds kort biedt ook Nutanix microsegmentatie, in de vorm van Nutanix Flow. Deze functionaliteit is beschikbaar voor de eigen AHV-hypervisor (wat logisch is gezien de nauwe integratie tussen hypervisor en netwerk-connectiviteit) als apart aan te schaffen product en werkt nauw samen met de managementomgeving van Nutanix: Prism.

Hoewel de functionaliteit van Flow wel wat weg heeft van NSX, werkt het toch op een eigen manier. Dit blog is dan ook geenszins een poging om de twee te vergelijken, maar gaat vooral om Nutanix Flow en in hoeverre de microsegmentatie functionaliteit daarvan kan worden ingezet voor het beveiligen van uw omgeving.

Aanmaken Test-Applicatie

Omdat mijn ervaring met Nutanix in de afgelopen tijd wat beperkt is geweest, heb ik hier en daar wat tijd moeten spenderen aan het vinden van mijn weg in de interface, maar deze is op zich behoorlijk intuïtief. Nutanix Flow maakt gebruik van “applications” en van “categories”. Dit zijn entiteiten binnen de omgeving die zijn te koppelen aan virtuele machines en waarmee is te definiëren hoe de onderlinge verbanden tussen virtuele machines zijn. Door gebruik te maken van appliations is het ook mogelijk om datastromen te definiëren binnen een applicatie en tussen een applicatie en de buitenwereld.

Om te beginnen was het voor mij zaak om een applicatie aan te maken binnen de testomgeving. Omdat Nutanix met Calm ook automation-functionaliteit kent, heb ik me opgesteld als eenvoudige gebruiker en heb ik gebruik gemaakt van de voor gedefinieerde blueprint: LAMP_demo:

Een applicatie bestaande uit drie lagen, te weten een frontend (HAProxy), een applicatielaag (Apache_php) en een database (MySQL). Het uitrollen van de applicatie zal ik niet uitgebreid beschrijven, het volstaat te melden dat ik eenvoudig een applicatie heb uitgerold en deze bestaat uit een viertal virtuele machines:

Voor meer informatie over Nutanix Calm verwijs ik u graag naar een blog van mijn collega Viktor van den Berg: https://pqr.com/blogs/een-eerste-blik-op-nutanix-calm.

Vervolgens heb ik een nieuwe waarde aangemaakt onder de categorie AppType, genaamd RJO. Door op deze manier een applicatie te definiëren binnen de omgeving, is het mogelijk om (in een volgende fase) de applicatie te beveiligen, zowel intern (tussen de vm’s zelf) als van binnen naar buiten en vice versa.

De volgende stap was het aanmaken van een drietal Application Tiers en het koppelen van de betreffende virtuele machines:

Per virtuele machine worden nu twee categorieën toegevoegd. Eén categorie om de virtuele machine te koppelen aan een applicatie en een tweede categorie om de virtuele machine zijn rol binnen de applicatie toe te kennen (de applicatielaag). Uiteraard is het mogelijk om nog meer categorieën toe te passen, zoals “test” en “productie” of een categorie voor een afdeling, maar voor nu was dit voor mij genoeg om de test mee uit te voeren. Hieronder het voorbeeld van de twee virtuele machines die gekoppeld zijn aan de rjo-applicatie en binnen de applicatie aan de rjo-app tier:

Hierna is het heel eenvoudig om inzichtelijk te maken en vast te stellen welke datastromen zijn toegestaan en welke niet. Zowel voor verkeer binnen de applicatie, als voor verkeer van binnen naar buiten en van buiten naar binnen.
Dit kan gerealiseerd worden door een nieuwe Security Policy aan te maken en vervolgens binnen de policy te definiëren welke datastromen zijn toegestaan en welke niet.

Eerst selecteer je één van de tiers en vervolgens klik je op het plusje van een andere tier om te definiëren dat verkeer van de geselecteerde tier naar de andere tier is toegestaan.

Hierin kan dus ook bepaald worden wélk soort verkeer is toegestaan. In dit voorbeeld sta ik alles toe:

  

En zo is te zien dat een datastroom tussen rjo-app en rjo-db is toegestaan. Als ik een bewegend plaatje kon laten zien, kon je in bovenstaande ook nog de richting van de datastroom zien, namelijk van app naar db (en dus niet andersom). Als ik de datastroom andersom ook zou willen toestaan, dan selecteer ik de bron (rjo-db) en klik ik op het plusje van rjo-app. Vervolgens kan ik wederom aangeven welke poorten zijn toegestaan en is het resultaat dat er zowel heen als terug kan worden gecommuniceerd:

  

Van buiten naar binnen                                                                                                        En van binnen naar buiten 

Nadat ik dat voor alle tiers heb gedaan (en even heb gewacht, totdat er wat datastromen zijn ontstaan), houd ik het volgende overzicht over:

Het mooie van bovenstaand overzicht is dat ik niet alleen zie welke datastromen ik heb toegestaan (de blauwe lijnen), maar ook welke datastromen ik niet heb toegestaan, die wel plaatsvinden. Zo zie ik een datastroom van rjo-db naar rjo-app en als ik met mijn muis over de lijn beweeg kan ik zelfs zien welk type verkeer dat is:

In dit geval was het een ping.

In bovenstaande voorbeeld heb ik de instelling op “monitor” staan. Dat houdt in dat er enkel gekeken wordt naar de datastromen, maar er wordt niets daadwerkelijk geblokkeerd. De volgende stap (nadat ik zeker ben van het feit dat ik alle benodigde datastromen heb vastgelegd) is het daadwerkelijk blokkeren van alle niet gedefinieerde datastromen. Dat kan ik doen door in plaats van te kiezen voor “Save and Monitor” te kiezen voor “Apply Now”:

Ik zal dan zien dat ik niet meer kan pingen tussen de database-vm en de applicatie-vm:

En zo heb ik dus mijn applicatie beschermd tegen de boze buitenwereld!

Vervolgens kan ik zien zien welke datastromen er nu daadwerkelijk zijn geblokkeerd:

Wat ik helaas niet lijk te kunnen (maar dat kan liggen aan mijn beperkte kennis van de interface ;)) is de mogelijkheid om de geblokkeerde datastromen die ik toch toe wil staan, met één (of twee) kliks toe te voegen. Hopelijk in een volgende versie.

Al met al een zeer interessante toevoeging op de functionaliteit van Nutanix. Voor organisaties die al gebruik maken van AHV en hun applicaties op micro niveau willen beveiligen, is dit zeker iets om eens naar te kijken.

Mocht u meer willen weten, neem dan vooral contact op met mij: rjo@pqr.nl of met uw accountmanager. We laten u graag zien hoe Nutanix Flow ook in uw omgeving kan leiden tot een betere beveiliging!

Reacties

Reactie toevoegen