Microsegmentatie-features toegelicht
[vc_row][vc_column][vc_column_text]
Enige tijd geleden heb ik mijn eerste Cloud Architect Alliance-communitymeeting bijgewoond. De CAA is een bijzonder goed georganiseerd evenement waar zo’n honderd cloudarchitecten bij elkaar worden gebracht om discussie te voeren over de diverse aspecten rondom cloud. Het thema van deze CAA was ‘Security Revised’. Topics als zero trust architectures en microsegmentatie werden vanuit diverse hoeken belicht.
Met name op het gebied van microsegmentatie merk ik dat de nieuwste functies niet bij iedereen bekend zijn, zoals intra EPG-isolatie. Ik leg graag wat uit over de microsegmentatie-opties die er nu zijn.
Wat doet microsegmentatie?
Microsegmentatie verdeelt het datacenter in kleinere, beter beschermde zones. Dit hoort te gelden voor zowel fysieke als virtuele workloads, onafhankelijk van het type hypervisor. In traditionele netwerken werd er veel aandacht besteed aan de perimeter beveiliging, maar het verkeer mocht, eenmaal in het datacenter, eigenlijk alle kanten op – ook wel east-west verkeer genoemd. In een micro-gesegmenteerd datacenter wordt beveiliging zowel in de perimeter, als tussen applicatie-tiers en zelfs tussen endpoints in een applicatie-tier toegepast. De theorie hierachter is dat, als er bijvoorbeeld een endpoint gecompromitteerd raakt, de impact beperkt blijft vanwege een kleiner fault domain.
In traditionele netwerken wordt er gebruikgemaakt van een zogenaamd blacklisting-model. In dit model geven we door middel van ACLs aan welk verkeer we niet willen toestaan. Vanuit een beheerdersoogpunt kost het beheren en troubleshooten van dit model veel tijd. Waarschijnlijk zijn velen van jullie ondertussen bekend met Cisco Application Centric Infrastructure (ACI). In een ACI-netwerk zijn de zaken omgedraaid en wordt er gebruikgemaakt van een whitelisting-model. In dit model wordt gespecificeerd welk verkeer we wél willen toestaan en de rest is per definitie niet toegestaan. Zonder een expliciete policy waarin we verkeer beschrijven en toestaan wordt er dus geen verkeer doorgestuurd over het netwerk.
Sinds de eerste dag dat ACI op de markt is gekomen, biedt deze oplossing microsegmentatie voor alle type workloads in een datacenter. ACI is op het moment van schrijven ongeveer twee jaar op de markt en er zijn ondertussen diverse microsegmentatie-functies bijgekomen. Ik licht er graag een aantal toe.
End-Point Groups (EPGs)-microsegmentatie
In ACI kunnen we door middel van policy End-Point Groups (EPGs) maken om zo endpoints te segmenteren in hetzelfde broadcast-domain. Een endpoint kan bijvoorbeeld een fysieke server, VM, een Linux-container of zelfs een legacy mainframe zijn. Het endpoint wordt in een EPG genormaliseerd en daarom is het type endpoint niet meer relevant.
In ACI wordt nog steeds gebruikgemaakt van het traditionele L2-segment; dit wordt ook wel een Bridge Domain (BD) genoemd. IP Subnets kunnen vervolgens worden gekoppeld aan een BD. Indien wenselijk kun je een BD koppelen aan één enkele EPG, om zo een traditioneel VLAN na te bouwen. Maar door het gebruik van meerdere EPGs kunnen we ook het BD verder segmenteren. Eigenlijk zijn EPGs dus microsegmenten van een BD.
Een van de standaard instellingen in ACI is dat endpoints in een EPG wel met elkaar mogen praten, maar niet met endpoints in andere EPGs. Om connectiviteit toe te staan tussen endpoints in twee of meerdere EPGs, dient er een contract te worden aangemaakt. Een contract beschrijft de inbound en outbound permit, deny, QoS rules en andere policies, zoals redirect. De afbeelding hieronder geeft een voorbeeld van hoe bepaald verkeer tussen EPGs wordt toegestaan door middel van contracten. Vanwege het whitelist-model wordt verkeer dat niet is gedefinieerd automatisch geblokkeerd.
Attribute- / IP- / MAC-based microsegmentatie
Endpoints kunnen ook worden gesegmenteerd door het gebruik van bijvoorbeeld tags of attributen. Een attribuut kan onder andere een IP/MAC-adres, VM-naam, OS-naam, Host-naam of FQDN zijn. Zo kun je bijvoorbeeld een policy maken waarin alle Windows VMs met Server 2003 als OS worden opgenomen in een micro-EPG (uSeg EPG).
Een interessante use-case zou een security-feedbackloop kunnen zijn. Stel je voor dat je verkeer kopieert naar een IPS-systeem. Op het moment dat de IPS detecteert dat een host gecompromitteerd is, wordt het endpoint automatisch in een apart microsegment geplaatst waar vervolgens alleen connectiviteit mogelijk is naar een update/patching-server.
Intra EPG-isolatie
Intra EPG-isolatie is een van de laatst geïntroduceerde features in ACI. Zoals ik eerder al aangaf, is de standaard werking van EPGs dat intra EPG-verkeer wordt toegestaan. Er bestaan echter bepaalde use-cases waarin we ook dit verkeer willen blokkeren. Stel je een EPG voor met diverse endpoints waar management-tooling op draait. Er is geen enkele reden dat deze endpoints met elkaar mogen praten, maar het is wel handig als ze allemaal bij de back-upserver kunnen komen. Met de intra EPG-isolatiefeature blokkeren we intra EPG-verkeer en kan inter EPG-verkeer worden toegestaan door middel van contracten. Overigens is attribute based-segmentatie ook te gebruiken in combinatie met intra EPG-isolatie. In het voorbeeld van de security-feedbackloop zou dit bijvoorbeeld betekenen dat ook de gecompromitteerde endpoints in een uSEG EPG niet met elkaar mogen praten.
Dieper de intra EPG-isolatie in
Het leuke van blogs schrijven op een zaterdag, is dat er opvallend weinig telefoontjes en e-mails binnenkomen. Laten we daarom eens wat dieper ingaan op de intra EPG-isolatiefeature en wat er daadwerkelijk gebeurt met twee endpoints die zich in een isolated EPG bevinden. Allereerst zetten we Intra EPG-isolatie in stelling op de EPG op Enforced.
Bij het aanzetten van de intra EPG-isolatiefeature wordt de pcEnfPref-eigenschap van de EPG op enforced gezet. Dit kunnen we controleren door een SSH-verbinding te openen naar de APIC en een ‘moquery’ uit te voeren op de EPG. De pcTag is een unieke identifier van de EPG. Deze waarde kunnen we later gebruiken om verdere details op te vragen.
Nadat de intra EPG-isolation op enforced is ingesteld, wordt de EPG gekoppeld aan een VMM-domain. Dit is een vSphere 6.0-omgeving met twee ESXi-hosts op UCS B200-servers. Op deze omgeving draaien twee Debian VMs, respectievelijk met de IP-adressen 10.0.1.3 en 10.0.1.4, ieder in het 10.0.1.0/24-subnet. Als we kijken naar de endpoints in de VRF op de leaf-switch, zijn beide VMs hier geleerd. Het encap-VLAN is 3082, een dynamisch gealloceerd private VLAN.
Op het moment dat de intra EPG-feature wordt aangezet, wordt er een nieuwe zoning-rule toegevoegd op de leaf-switch. Eerder hadden we de pcTag van de EPG opgevraagd. Deze waarde kan gebruikt worden om de output te filteren. Wat we hier zien is dat er dus een implicit deny zoning-rule wordt aangemaakt, die verkeer van en naar de betreffende EPG blokkeert en logt.
Als we de linecard-shell op een leaf-switch openen, kunnen we nog verder gedetailleerde informatie opvragen. Zo is in onderstaande output te zien dat het betreffende VLAN isolated is. VLAN 3083 is het promiscious VLAN en vlan 3082 is het Isolated VLAN. Overigens is er geen ondersteuning voor community-VLANs.
Om te testen of het allemaal echt werkt, blijft een ping-test natuurlijk handig. Op de leaf is te zien dat icmp-verkeer van 10.0.1.3 naar endpoint 10.0.1.4 wordt geblokkeerd.
‘State of practise’-security
Tijdens de CAA ontstond een discussie over de wetgevingen omtrent databeveiliging. Hier wordt in beschreven dat data adequaat beveiligd moet zijn. Maar wat is de exacte definitie van ‘adequaat’? Volgens de experts betekent dit het toepassen van ‘state of practise’-security, met inachtneming van de technologische vooruitgang van security-oplossingen. Dit hoeft dus niet per se ‘state of the art’-beveiliging te zijn. ACI is op dit moment een ‘state of the art’-netwerk als het gaat om totale microsegmentatie van de IT-infrastructuur.
Uiteindelijk is een aantal van deze microsegmentatie-features mogelijk gemaakt door hardware-innovatie. Inmiddels is de nieuwe -EX based Nexus 9000 uitgekomen. Op dit platform worden vrijwel alle features ondersteund. Fred Rabouw heeft een goed artikel geschreven over dit nieuwe Nexus-platform. Hierbij een supportmatrix van ondersteuning van de diverse features op het Nexus 9000-platform:
| Gen1 | -E based hardware | -EX based hardware | |
| AVS uSeg (VM, IP, MAC) | Ja | Ja | Ja |
| Microsoft uSeg (VM, IP, MAC) | Ja | Ja | Ja |
| vDS uSeg (VM, IP, MAC) | Nee | Nee | Ja |
| Bare-Metal (IP-EPG) | Nee | Ja | Ja |
| Bare-Metal (MAC-EPG) | Nee | Ja | Ja |
| Openstack (ML2, GBP) | N/A | Roadmap | Roadmap |
| Container | Nee | Roadmap | Roadmap |
| Intra EPG isolation | Ja | Ja | Ja |
Bedankt voor het lezen van deze post. Neem gerust contact met mij op bij vragen en/of opmerkingen. Ik denk ook graag met jullie mee over bepaalde microsegmentatie use-cases.
[/vc_column_text][/vc_column][/vc_row]
