Cisco ACI netwerk segmentatie

Datacenter segmentatie is een cruciale maatregel in het waarborgen van de veiligheid en efficiëntie van moderne datacenters. Hier zijn enkele redenen waarom netwerk (datacenter) segmentatie belangrijk is:

Beveiliging: Segmentatie helpt bij het beperken van de toegang tot kritieke delen van het netwerk. Door verschillende delen van het datacenter te isoleren (bijvoorbeeld door gebruik te maken van VLANs of firewalls), wordt de impact van een eventuele inbraak beperkt. Dit betekent dat als een aanvaller toegang krijgt tot een bepaald segment, hij niet automatisch toegang heeft tot andere delen van het netwerk.

Beheersbaarheid: Door het datacenter op te delen in kleinere segmenten, wordt het makkelijker om het netwerk te beheren en problemen op te lossen. Elk segment kan apart worden beheerd en geoptimaliseerd zonder dat dit invloed heeft op andere segmenten.

Compliance: Veel industrieën hebben strenge regels en normen voor gegevensbescherming. Segmentatie maakt het mogelijk om gevoelige gegevens of processen te scheiden van minder kritieke gegevens, waardoor het makkelijker wordt om aan regelgeving te voldoen.

Prestaties: Door segmentatie kunnen netwerkverkeer en workloads efficiënter worden beheerd. Dit kan leiden tot betere prestaties, aangezien verkeer binnen een segment blijft en niet onnodig door het hele netwerk verspreid wordt.

Veerkracht: Als een deel van het datacenter wordt aangetast door een storing of aanval, kan segmentatie voorkomen dat het hele datacenter wordt beïnvloed. Dit verhoogt de algehele veerkracht van de infrastructuur.

In essentie zorgt datacenter segmentatie voor een beter beheersbare, veiligere en efficiëntere IT-infrastructuur, wat cruciaal is voor het beschermen van bedrijfsgegevens en het waarborgen van continue bedrijfsvoering.

Wat is Cisco ACI?

Cisco Application Centric Infrastructure (ACI) is een geavanceerde netwerkoplossing ontwikkeld door Cisco die een software-gedefinieerd netwerk (SDN) biedt voor datacenters. Het product is ontworpen om netwerkbeheer te vereenvoudigen en de prestaties van applicaties te optimaliseren door netwerkbeleid te centraliseren en te automatiseren. Hier zijn enkele kernpunten over Cisco ACI:

Software-Defined Networking (SDN): Cisco ACI maakt gebruik van SDN om netwerkresources te beheren. In plaats van dat netwerkinstellingen handmatig worden geconfigureerd op individuele netwerkapparaten, stelt ACI netwerkbeheerders in staat om netwerkbeleid centraal te definiëren en te beheren via een software-interface.

Application-Centric: In tegenstelling tot traditionele netwerken die vaak gebaseerd zijn op netwerkapparatuur en -structuren, richt Cisco ACI zich op de behoeften van applicaties. Het netwerk wordt geconfigureerd en beheerd op basis van de vereisten van de applicaties die erop draaien. Dit betekent dat netwerkinstellingen automatisch worden aangepast om te zorgen voor optimale prestaties en veiligheid van de applicaties.

Netwerksegmentatie en Beveiliging: ACI biedt gedetailleerde netwerksegmentatie en geavanceerde beveiligingsfuncties. Dit omvat de mogelijkheid om beveiligingsbeleid te definiëren en te handhaven op basis van de vereisten van de applicatie, en zo te zorgen dat verschillende delen van het netwerk geïsoleerd en beschermd blijven.

Automatisering en Orchestratie: ACI automatiseert veel van de routinematige netwerkbeheerprocessen, wat leidt tot een efficiëntere operationele workflow. Het biedt ook integratie met andere orkestratie- en beheerplatforms, waardoor een naadloze end-to-end netwerkbeheerervaring wordt geboden.

Flexibiliteit en Schaalbaarheid: ACI ondersteunt zowel fysieke als virtuele netwerkomgevingen en biedt een flexibele en schaalbare oplossing die kan groeien met de behoeften van de organisatie. Het kan worden geïntegreerd met zowel bestaande netwerkinfrastructuren als nieuwe SDN-implementaties.

Centraal Beheer: De Cisco ACI-oplossing wordt beheerd via de Application Policy Infrastructure Controller (APIC), een centraal managementsysteem dat alle netwerkapparatuur beheert die onder ACI valt. APIC stelt beheerders in staat om netwerkbeleid in te stellen en te wijzigen, monitoring en probleemoplossing te doen, en netwerkintegriteit te waarborgen vanuit een enkele interface.

Samengevat biedt Cisco ACI een krachtige, flexibele en geautomatiseerde manier om netwerken te beheren in complexe datacenteromgevingen, met een sterke focus op de optimalisatie van applicatieprestaties en -beveiliging.

Oftewel genoeg reden om aan de gang te gaan met Cisco ACI.

Startpunt

In dit geval gaan we er vanuit dat je een Cisco ACI deployment hebt waarbij de leafs/spines (en een eventueel interpod netwerk) reeds geïmplementeerd en ge-onboard zijn in je ACI fabric. Zo niet, en heb je hierbij hulp nodig? Dan kunnen we vanuit ANT Networks hierbij helpen, neem dan contact op via: Klik hier

Netwerk centrisch / Applicatie centrisch

Wat belangrijk is bij de start van de implementatie van netwerksegmentatie in het datacenter is het tiering model wat je wilt hanteren. Omdat we met segmentatie afstappen van een netwerk centrisch design (lees: 1 netwerk = 1 subnet = 1 vlan) en overstappen naar een applicatie centrisch design zullen we gaan werken met (vaak) grotere subnets waarin meerdere systemen landen van een bepaald type. Het is belangrijk om bij de start de requirement op te halen waaraan het netwerk ontwerp moet voldoen. Binnen ACI heb je veel opties om verkeer via policy based routing (PBR) via een andere next hop te routeren.

Stel je organisatie heeft de eis om verkeer tussen de front-end en mid-tier via een firewall te laten scannen en inspecteren boven laag 4 (van het osi model) dan kan dit. Echter hebben niet alle organisaties hebben deze eis. Vandaar dat het belangrijk is om eerst te bekijken waaraan het netwerk moet voldoen voordat je gaat bouwen / implementeren.

Tiering model

Na het ophalen van de eisen is het belangrijk om een tiering model te kiezen. Hieronder een aantal zaken om over na te denken:

• Ga ik multi-tenant draaien? (heb ik behoefte om objecten binnen ACI administratief te scheiden?)
• Ga ik met meerdere VRF’s (virtual routing and forwarding instances) werken? Om verkeersstromen op “Macro niveau” te kunnen scheiden?
• Hoe moet mijn netwerk eruit komen te zien? Wil ik gebruik maken van een Web/App/Data tier? Of wil ik enkel een LAN/DMZ netwerk? Misschien wil ik enkel onderscheid maken tussen Business applicaties en IT applicaties (Business tier / IT tier)?
• Wil ik een netwerk voor alle generieke diensten (bijvoorbeeld DNS/DHCP etc.)?
• Wil ik alles laten landen in een groter netwerk per functie of meerdere kleinere netwerken
• Moet er L4+ inspectie plaatsvinden voor connecties tussen systemen binnen het Datacenter (dezelfde VRF).
• Ga ik segmenteren per dienst (workload) (minder beheerslast en minder veilig) of op micro niveau (hoge beheerslast maar veiliger)?
• Moet ik rekening houden met Ontwikkel / Test / Acceptatie omgevingen?

Dit zijn een aantal voorbeelden waarmee je rekening moet houden.

Tiering model implementeren

Na de keuze van je tiering model en hoe het datacenter eruit moet komen te zien, kun je overstappen op implementatie. Binnen ACI zijn er een aantal objecten erg belangrijk:

• Tenants
  • Een tenant is een administratieve afbakening van alle objecten die aangemaakt worden onder de tenant. Vaak worden meerdere tenants ingezet als er meerdere klanten worden bediend via dezelfde ACI omgeving zodat objecten van klant-A niet zichtbaar zijn in de tenant van klant-B.
• VRF’s (virtual routing and forwarding instance)
  • VRF’s creëeen virtuele routeringstabellen (op dezelfde hardware), dit wordt vaak ingezet om meerdere netwerken logisch te scheiden. Vaak word er via VRF’s een splitsing gemaakt tussen Productie en O/T/A omgevingen. Hiermee kun je ervoor zorgen dat systemen van Macro segment productie niet zomaar bij systemen van macro segment Test kunnen komen.
• Bridge domain (BD)
  • Een bridge domain is het netwerk construct binnen ACI, hier definieer je voornamelijk de laag 2 settings van een netwerk.
• Endpoint group (EPG)
  • Een endpoint group werd in het verleden door Cisco veel gebruikt om contracten op te koppelen / segmentatie mee te implementeren. Maar in nieuwere versies is Cisco overgestapt op Endpoint Security Groups omdat deze subnet onafhankelijk zijn en dus meer flexibiliteit bieden. (EPG’s moeten altijd gekoppeld zijn aan een bridge domain).
• Endpoint Security group (ESG)
  • Endpoint security groups zijn objecten waarop je contracten kunt koppelen en waarin je systemen kunt opnemen (subnet onafhankelijk) om diensten / applicaties te vormen.
• Contracten
  • Een object vergelijkbaar met een firewall regel welke gekoppeld word om communicatie tussen ESG’s / EPG’s toe te staan of juist niet.

 In onderstaande plaat zie je de concepten en de functie binnen het ACI ecosysteem terug komen.

Stel we hebben de netwerken (bridge domain en EPGs) “Web”, “App” en “Data” en we hebben een ontwikkel / test / acceptatie en productie omgeving.

Dan zouden we kunnen kiezen voor 1 tenant met de naam van de organisatie. Vier VRF’s (per lifecycle omgeving 1 VRF, dus O/T/A/P). Binnen deze VRF’s zou je netwerken kunnen aanmaken met de tiers Web App en Data.

Vervolgens plaatsen we 1 systeem in Web, 1 systeem in App en 1 systeem in de Data tier.

Web (subnet 10.0.0.0/24) Systeem 1 IP adres: 10.0.0.2

App (subnet 10.0.1.0/24) Systeem 2 IP adres: 10.0.1.2

Data (subnet 10.0.2.0/24) Systeem 2 IP adres: 10.0.2.2

Je kunt daarna een ESG aanmaken waarin je alle drie de endpoints qua ip in de ip selector opneemt.

Zie ook:

Doordat je deze drie systemen op neemt in 1 ESG heb je de mogelijkheid om “intra ESG isolation” op un-enforced te zetten. Oftewel: systemen binnen dezelfde ESG mogen vrij communiceren zonder dat er contracten aangemaakt / gekoppeld hoeven te worden.

Op deze manier kun je alle workloads/applicaties in je datacenter opnemen en hoef je enkel koppelingen tussen applicaties via contracten op ESG niveau open of dicht te zetten. Hoe ver je wilt gaan met ESG’s is aan jezelf, in dit geval had je ook 3 ESG’s kunnen maken (1x web 1x app 1x data) en had je ook voor communicatie tussen Web <> App <> Data contracten kunnen vereisen of middels een service graph (policy based routing) verkeer via een firewall kunnen routeren voor extra inspectie.

Conclusie

Ben je na het lezen geïnteresseerd geraakt in deze implementatie, heb je vragen of je wil vrijblijvend contact hebben? Neem dan vooral contact met ons op via Klik hier