Adatközponti biztonság kapcsán felmerül a kérdés miután bevezettük a mikroszegmentációs megoldásunkat a DC-ben, hogy „készen vagyunk?”.

Megérkeztünk már? Hátra dőlhetünk végre? Ez már a network és security nirvána?

A nyugtalan részünk megkérdezheti:  gondoltam mindenre…? Mit teszünk pl. ha a főnök finoman megkér minket, hogy a gigászi Orákulum adatbázis szervereket is vonjuk be a „tűzfalazott/védett” infrastruktúra komponensek körébe, a hatályos házon belüli biztonsági sémáinkhoz igazodva, teljesítmény csökkenés nélkül, a meglévő fizikai tűzfalakat használva, tegnapra?

Néhányat hátralépve érdemes tisztáznunk, hogy miért “nagy durranás” a mikroszegmentáció. Miért szeretjük? Mit old meg számunkra?

Adatközpontjaink és adataink védelmére már évtizedek óta használunk különböző határvédelmi (perimeter defense) megoldásokat. Először – sok éven át – jellemzően csak ez a határvédelmi réteg volt jelen az adatközpontokban, a tehetősebb és az IT biztonság tekintetében tudatosabb vállalatok esetén általában valamilyen IDS/IPS jellegű behatolásvédelmi megoldással kiegészítve. Néhány éve, elsősorban a virtualizáció robbanásszerű terjedésének köszönhetően az adatközpontjainkban működő szerverek száma a korábbiakhoz képest több nagyságrenddel megnőtt, amely a virtualizáció által behozott előnyök mellett olyan feladatok, kihívások elé is állított minket, amikre korábban nem volt szükség, vagy egyszerűen nem gondoltunk rá.

A mikroszegmentáció használatával lehetségessé vált olyan fajta hálózatbiztonsági elkülönítés (szegmentáció) az azonos Layer-2 domain-ben (tipikusan egyazon IP subnet-ben) lévő host-okra vonatkozóan, amely korábban évtizedeken át nem volt elérhető. Az azonos Layer-2 domain-ben lévő host-ok (tipikusan egyazon VLAN ill. IP subnet) egymás közötti forgalma csak a hálózati switch-eken halad keresztül, és az IP subnet-eket elválasztó Layer-3 tűzfalakig már nem jut el.

A mikroszegmentáció lehetővé teszi, hogy a biztonsági kontrollokat ne csak IP-subnet granularitással, hanem sokkal kisebb egységekben, akár egy-egy host-ra vonatkozó szabályzással tegyük meg. A megoldás extra szépsége, hogy mindez a kontroll lehetőség független attól, hogy azok a host-ok, amelyek közötti kommunikációt szabályozni szeretnénk azonos VLAN-ban és IP-subnet -ben vannak, vagy különbözőben.

A különböző IP-subnet-ek közötti kommunikációk kontroll alatt tartása az elmúlt évtizedekben sem jelentett gondot, ott voltak – és vannak – erre a tűzfalak. Az azonos VLAN-ban egymással kommunikáló gépek közötti kontroll beiktatására csak a switch-ekben volt lehetőség, ahol a megvalósíthatóság is erősen korlátozott volt: a switch-ek forgalomtovábbító áramköreit nem tűzfalas szabályok beiktatására tervezték és optimalizálták. A switch-ekben – a komolyabb switchekben – maximum statikus szűrőlistákat (ACL – access control list) lehetett létrehozni, amely szűrőlistáknak sem a mennyisége (szabályok száma), sem a testreszabhatósága nem volt megfelelő mértékű, a manuális szabályok naprakészen tartása gyakorlatilag nem megvalósítható. Plusz hátrány volt, hogy csak ún. “stateless packet filter” szabályokat lehetett definiálni a switch-eken, emiatt adott kommunikáció mindkét irányára vonatkozóan létre kellett hozni a szabályokat (ennek szükségessége ismét csak a skálázhatóságot és a karbantarthatóságot rontotta). A tűzfalak – és a mai mikroszegmentációs megoldások – ún. “stateful packet filtering” funkciót valósítanak meg, ahol csak a kommunikáció egyik irányát kell definiálnunk (honnan-hová, forrás-cél), és a visszirányra vonatkozóan – kommunikáció idejére – dinamikusan jönnek létre a szabályok az ún. állapot-táblában.

Miért jó nekünk ha “egymás melletti” (pl. 192.168.1.5 és 192.168.1.6 IP címekkel rendelkező VLAN82-beli host-ok) között tudunk részletekbe menő, granuláris tűzfalszabályokat létrehozni?

Tekintsük az alábbi egyszerű ábrát:

A kívülről – jellemzően az Internet felől – érkező támadó (narancssárga gép a külső hálózatban) a határvédelmi megoldásunkat megkerülve-kicselezve feltör egy belső gépet (a támadás útjának első állomása), majd ezt a gépet ugródeszkának használva, erről a gépről indít további támadásokat a többi belső hálózatban lévő “szomszédos” host felé.

Ez az a pont, ahol a már megismert mikroszegmentációnk valódi értelmet nyer: a “mikroszegmentált” környezetben nem tud a támadó – vagy csak nagyon korlátozott mértékben – további támadásokat indítani a többi belső szerverünk/host-unk felé. Azonos VLAN / IP subnet -ben lévő szervereink egymás közötti kommunikációjára általában nem a mindenki-mindenkivel mintázat a jellemző, és a mikroszegmentáció segítségével lehetőségünk van a megengedett kommunikációt a minimumra (a legbiztonságosabb verzióra) szorítani.

A mikroszegmentációval nagyot léptünk előre az adatközponti biztonság terén, de azért maradtak megoldásra váró problémák. A mikroszegmentációs megoldás “hatóköre” alá bevonni olyan workload-okat tudunk, amelyek virtualizálhatók, és ezáltal bevonhatók az egész adatközpontot átfogó virtualizációs rendszer alá.

Vannak speciális kiszolgálók, amelyek fizikai, licencelési, vagy egyéb okból nem virtualizálhatók – pl. NAGY adatbázis szerverek, vagy speciális alkalmazás szerverek, vagy olyan szerverek, amelyeket jó okkal tartunk közvetlenül fizikai hardveren. Fontos, hogy ezen szerverek számára is biztosítsuk a tűzfallal való védelmet.

Erre a kihívásra – a fizikai-gép <-> fizikai-gép illetve a fizikai-gép <-> virtuális-gép kommunikációk tűzfalazhatóságára – ad kiváló választ az adatközponti hálózatok vezető gyártója, az Arista ún. MSS Macro-Segmentation Service megoldása.

Az alábbi ábra szemlélteti a tradícionális peremvédelem, a mikroszegmentációs megoldás, és a hézagpótló makroszegmentáció szerepeit egy tipikus adatközponti megvalósítás esetén:

Néhány alapvető információ a makroszegmentációval kapcsolatban:

Ez egy olyan megoldás, amely erősen támaszkodik az adatközponti hálózati switchek és az őket irányító Arista automatizációs platform képességeire, így az MSS csak akkor vehető igénybe, ha az adatközponti hálózat (fabric) Arista eszközökből áll, és a vezérlő/automatizációs platformot (CloudVision) is megfelelően üzembe állítottuk.

A makroszegmentáció nem kiváltója vagy konkurense a mikroszegmentációnak, hanem sokkal inkább kiegészítője, és segítségünkre lehet abban, hogy az adatközpontunkban felmerülő biztonsági igényeket minél teljeskörűbben tudjuk lefedni.

Az MSS nem egy kötelező technológia az adatközpontban, de ha az igény a Fizikai-Fizikai és/vagy a Fizikai-Virtuális workload-ok közötti kommunikációk tűzfalas védelme, akkor igen nagy hasznunkra lehet, kihúzhat a bajból.

Az Arista network fabric – a későbbiekben részletesebben is kifejtem – képes intelligensen “követni” ha a kommunikáló fél “elmozog”, vagyis egy másik szerverswitchre kötjük át fizikailag, vagy a virtualizációs rendszerben a VM egy másik fizikai host-ra mozog át. Nincs szükség manuális újrakonfigurálásra sem szerver, sem hálózat, sem tűzfal oldalon. Az alábbi ábra szemlélteti egy MSS integrációt alkalmazó DC fabric fizikai és logikai topológiáját:

A zöld háttérrel kiemelt Arista fabric (leaf-spine) a példánkban 4 db Spine switch-ből és 4 x 2 = 8 Top-of-Rack (ToR) switch-ből áll, ahol a ToR switch-ek kettesével vannak MLAG-párban (MLAG = MultiChassis Link Aggregation Group). Az MLAG-párban lévő switch-ek “eljátsszák” a csatlakozó szerver vagy másik switch felé azt, hogy ők egyazon switch különböző port-jai, így a csatlakozó eszköz – tipikusan a szerver – szabványos 802.1ax link aggregációt alkalmazva egyszerre tudja használni az MLAG-pár felé menő link-eket (Layer-2 bonding, bundling, etherchanneling, port-channeling, stb.). Ennek a gyakran alkalmazott setup-nak az előnye, hogy – hálózati oldalon – node- és link-redundancia is megvalósul: akár a szerver-uplink kapcsolat szakad meg, akár az egyik ToR switch esik ki, a szerver nem marad uplink és működő hálózati kapcsolat nélkül.

A Leaf-Spine (vagy Spine-Leaf) fabric előnyeiről, jellemzőiről egy későbbi cikkben bővebben is fogok írni.

A ToR switch-ekhez csatlakozó szürke szerver dobozok színezett háttere az azonos security/biztonsági szegmensbe tartozó gépeket jelképezi, legyenek azok akár fizikai, akár logikai szerverek. Azonos szín = azonos logikai/biztonsági szegmens. Ahogy az ábra is mutatja, a szerverek bármelyik ToR switch párhoz csatlakhatnak. A gyakorlatban gyakran külön “Compute”, külön “Storage” és külön “Network/Security Services” rack-eket használunk: Compute rack-ben szerverek, Storage rack-ben storage-ok…

A mi témánk szempontjából azonban ami külön figyelmet érdemel, az a “Network/Security Services” rack, a benne található eszközök, és csatlakozásuk a DC network fabric-hoz. Itt tipikusan nagy teljesítményű tűzfalak, load-balancer-ek találhatók. Azokat a hálózati/security szolgáltatásokat amelyeket nem lehetséges (vagy nem célszerű) a mikroszegmentációs megoldással megvalósítani, azokat a “Services” rack-ünkben elhelyezett fizikai tűzfalakkal, terheléselosztókkal tudjuk megvalósítani.

Példánkban a jobb szélső ToR MLAG-párhoz csatlakoznak a nagy teljesítményű fizikai tűzfalak, amelyek a különböző színekkel illusztrált biztonsági szegmensek szétválasztását és kommunikációs kontrollját megvalósítják.

A különböző színű workload-ok mozoghatnak is a host-ok között (ha virtuálisak), így a megoldásnak ezt is kezelnie kell majd.

A később részletezett “varázslat” eredményeként a jobb oldali topológiai ábrán látható logikai működés valósul meg, ahol a tűzfalat dinamikusan tudjuk a vizsgálni kívánt adatfolyamok útjába iktatni, pontosabban az adatfolyamokat fogjuk dinamikusan – igény szerint – tűzfalakhoz eljuttatni, hogy azok a kívánt részletes biztonsági elemzéseiket meg tudják tenni. Ami megvalósul, az egy dinamikus “Service Insertion”, melyet vázlatosan az alábbi ábrán láthatunk:

Az ábrán mind az MSS fő jellemzőit, mind pedig fő alkotóelemeit és egymáshoz való viszonyukat láthatjuk.

A virtuális és a baremetal workload-ok közötti “tűzfalazáshoz” a fabric intelligensen elviszi/átírányítja az érdekesként felismert forgalmat a tűzfalakhoz, ahol a mélyelemzés és szűrés megvalósulhat.

A megoldás fontos jellemzői:

• Egyetlen kontroll-pont: a security csapat által üzemeltetett Firewall Manager szoftver (tipikusan egy GUI).
• A meglévő security policy-vel teljesen összehangban lévő megoldás, a meglévő biztonsági-zónáinkat, zóna-modellünket tovább használhatjuk.
• A megoldás hálózati komponense – az Arista fabric – semmilyen gyártóspecifikus protokollt, megoldást stb. nem alkalmaz: nincs spec tagging, nincs spec enkapszuláció.
• A szervereinket nem kell át- vagy újrakonfigurálnunk.
• Az alkalmazásainkat tekintve nem jelentkezik semmilyen érzékelhető hátrány, overhead.

• Végül, de nem utolsósorban a security/tűzfal üzemeltetés szabályrendszer-módosítás stb. kapcsán nem kell a hálózatos csapatot bevonni, nem jelentkezik hálózat konfigurációs igény.

Mi van a motorháztető alatt?

Mivel a hálózati fabric egy EVPN-VXLAN -os megoldás, ahol a control-plane szinte teljes egésze megmarad elosztottnak, így minden egyes switch felett teljes kontrollunk marad (full CLI, GUI vagy központi management).

A megoldás kulcsa a szoros integráció, amely a Firewall Manager szoftver és az Arista fabric “agya”, a CloudVision között, nyílt szoftveres interface-eken – API-kon – keresztül valósul meg:

A CloudVision egy ún. real-time visibility and automation platform, amely egyrészt valósidejű információval rendelkezik a switch-ek minden lényeges jellemzőjéről, másrészt képes a switch-eket – egyet, többet, vagy akár az összeset – vezérelni, konfigurációt módosítani.

A switch-ek streaming telemetria alkalmazásával folyamatosan küldik állapotinformációikat a CloudVision felé, amely jellemzők között a MAC address tábla, ARP tábla, routing tábla, stb. aktuális állapota is megtalálható. Ennek köszönhetően a CloudVision-nek pontos valósidejű képe van (néhány msec a késleltetés míg a switch által riportolt információk rendelkezésre állnak a CV-ben) a fabric aktuális állapotáról, így pl. arról a fontos tényről is, hogy adott workload-ok (MAC/IP címek) éppen a fabric melyik részén (melyik ToR switch, melyik port) érhetőek el. A működési modell a következő:

1. a Firewall Manager-ben beállítjuk a security policy-nknek megfelelő szabályokat. Ezen a ponton kritikus, hogy a tűzfalszabályban szerepeljen a megfelelő “Tag” – egy olyan címke, egy olyan rövid karaktersor -, ami logikailag összeköti a CloudVision automatizmusait a tűzfalszabályokkal. A CV folyamatosan lekérdezi a FW Manager-t, hogy van-e változás vagy új szabály azok között, amelyek számára érdekesek (Tag!)
2. a CloudVision-ben engedélyezzük az MSS szolgáltatást és felparaméterezzük az API kommunikációt (IP cím, password stb.)
3. Ha van érdekes szabály, akkor a CV letölti magához
4. a CV a letöltött szabályoknak megfelelően azonnal átírja az érintett ToR switchek forwarding-tábláit olyan módon, hogy az “érdekes” forgalmakat eltereli/átirányítja a switchről a tűzfalak felé
5. a tűzfal végzi a szűréseket és kontrollokat
6. a szűrt/tisztított forgalom visszaküldésre kerül a célállomás felé

A Macro-Segmentation Service több olyan képességre épít, amely egyedi sajátossága – és előnye – az Arista alapú megoldásnak.

• A CloudVision valósidejű rálátása a hálózati fabric állapotára
• DirectFlow feature – a switchek forwarding tábláit nem csak a switching és/vagy routing processzek képesek írni, hanem akár mi is kézzel (!), vagy pl. egy API-n keresztüli integrációs megoldás… és ezzel megérkeztünk az MSS-hez
• Nyílt API-n keresztüli integrációs lehetőség a vezető tűzfal gyártókkal (PaloAlto, Fortinet, Checkpoint)

A kialakítás peremfeltételeit az alábbi ábra foglalja össze

Az MSS kialakítás jellemzőinek rövid összefoglalása az alábbi:

1. A Macro-Segmentation Service a tűzfalakat dinamikusan illeszti be az adatfolyamok útjába.
2. Specifikusan a Fizikai-Virtuális illetve a Fizikai-Fizikai workload-ok közötti kommunikációk szabályzására nyújt kiváló megoldást, kiegészítve a mikroszegmentációs megoldásokat.
3. Az MSS szoftver-vezérelt, dinamikus és jól skálázható szolgáltatás.
4. Egyedi sajátossága, hogy képes a szabályok kikényszerítését a a tűzfalról a hálózati eszközököre átruházni.
5. A CloudVisionExchange egypontos integrációs lehetőséget biztosít a fabric és a tűzfal-megoldás között.
6. Az MSS meglévő gyártói API-kra épít, a CVX ezen keresztül kapja meg az érdekes tűzfal-szabályokat.
7. A tűzfalak egy központi helyen kerülhetnek elhelyezésre.
8. A tűzfalak mind Layer-2 bridged (virtual-wire), mind pedig Layer-3 routed üzemmódban működhetnek, mindkét üzemmód támogatott.

A Macro-Segmentation szolgáltatás adatközponti alkalmazásának fő előnyei az alábbiak:

• Bármely FIZ-VIRT vagy FIZ-FIZ workload viszonylatban képes a biztonsági funkciót beiktatni.
• A biztonsági funkció beiktatása az adatfolyam útjába automatikus és dinamikus.
• A biztonsági funkció „követi” a mozgó workload-ot, ha az másik host-ra mozog (mobility).
• Nem használ semmilyen gyártóspecifikus tagging, encapsulation, magic-bit, stb. megoldást.
• Egyetlen kontroll-pont a fizikai tűzfalak FW Manager szoftvere.
• A felelősségi körök nem változnak:  Sec csapat csak Sec, Network csapat csak Network.
• Sem a szervereket, sem az alkalmazásokat nem érinti az MSS service-redirect.
• Szerver átkonfigurálás vagy alkalmazás átállítás nem szükséges.
• Végezetül – kedvcsinálónak – egy egyszerű példa nagyteljesítményű adatközponti tűzfal-integrációra:

Összefoglaló

Az MSS mint hiánypótló adatközponti biztonsági megoldás, lehetőséget ad az Arista network fabric-ot használó ügyfelek számára, hogy a fabric intelligens integrációs lehetőségeit kihasználva lefedjék az eddig “blind-spot”-nak számító Fizikai<->Virtuális és Fizikai<->Fizikai workload-ok kommunikációi közötti biztonsági/kontroll igényeket.

Kiválóan kiegészíti az adott esetben már meglévő mikroszegmentációs megoldásunkat, amely a Virtuális<->Virtuális workload kommunikáció biztonságáért és kontrolljaiért felel.

Az Arista MSS alkalmazása esetén a tűzfal és más hálózatbiztonsági szolgáltatások adatfolyamokba iktatása dinamikus, és oly módon valósul meg, hogy sem a hálózati közművet (fabric), sem pedig szerveinket és alkalmazásainkat nem kell hozzá átkonfigurálnunk.

A hálózatos és a security “népek” ítélete: BIG LIKE

A dolog egyetlen “hátulütője”, hogy adatközponti hálózatunkat Arista eszközökre kell építenünk, amivel – tekintve, hogy az Arista az adatközponti hálózati megoldások között a legmagasabb minőséget (legkevesebb kiesés, ill. zero downtime-ot) képviseli – talán meg fogunk tudni barátkozni.

Kiss Csaba