Rizika virtualizace a cloudů z pohledu dedikace HW a síťového prostředí

Již několikrát jsem s různými lidmi diskutoval na téma virtualizace a cloudových technologií a o tom, jak rychlý rozvoj v tomto oboru (i když nejen v něm) předbíhá schopnosti a/nebo ochotu firem starat se o adekvátní bezpečnost dat ať již čistě svých nebo svých zákazníků a korektní vyhodnocování rizik.

Abych byl dobře pochopen: ano, cloudové technologie poskytují dostatek nástrojů, jak i ve virtuálním prostředí svá data zabezpečit na všech možných úrovních, včetně např. síťové segmentace. Nemá smysl si kazit byznys tím, že budu ignorovat současné technologie, které mi jej zlevní a zjednoduší. Je potřeba to však dělat s rozumem a vážit, jak se k těmto technologiím postavím.
Pokud provedu analýzu rizik a po akceptaci zbytkového rizika mi vyjde, že mohu svá data svěřit např. komerčnímu cloudu, pak se samozřejmě proč ne. Někdy mi vyjde, že je vhodnější nasadit cloudové technologie on premise. A o tom je v tomto článku řeč.

Jedním z problémů, na který jsme narazili, je problém perimetru sítě v oblasti datových center a firemních privátních cloudů provozovaných on premise.
Položili jsme si otázku, zda je rozumné v konkrétním prostředí sdílet jeden hypervisor virtuálními servery, které mají být provozovány v bezpečnostně odlišných segmentech sítě, které jsou mezi sebou chráněny firewallingem. Stejně tak jako sdílení stejného hw (teď pomíjím provozní pohled - škálování je zde možné) pro virtuální firewally. Prostudoval jsme nekonečné řady různých pojednání a doporučení a zjistil jsem, že názory pro a proti jsou zhruba půl na půl.

Odpověď tedy není jednoznačná a záleží na míře spolehnutí se na (bezpečnostní) spolehlivost samotných virtualizačních technologíí a orchestrace cloudu včetně sítě.

V úvahách figurovala skutečnost, že i firewally samotné jsou pouze sw, který běží na dedikovaném HW, tudíž jejich virtualizace pomocí stejného SW nepřináší zásadní změny. Ano - to je pravda. Nicméně je zde potřeba počítat s tím, co se stane v případě bezbřehého a nepromyšleného sdílení HW, pokud se podaří něco, čemu se říká VM escape, tedy únik z virtuálního stroje do hypervisoru.
Není to nic nového - v minulosti jsme byli svědky opuštění chroot prostředí, jailu, apod., tudíž je možné očekávat podobné problémy i v oblasti virtualizace podporované HW, i když by to mělo být obtížnější (a je).
V našich rozpravách jsem byl za příliš opatrného do doby, než se objevila zranitelnost KVM, konkrétně: http://venom.crowdstrike.com/ nebo https://www.blackhat.com/presentations/bh-usa-09/KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-SLIDES.pdf. Hezké starší pojednání je i zde: http://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf nebo zde: http://conference.hitb.org/hitbsecconf2016ams/materials/D1T1%20-%20Shengping%20Wang%20and%20Xu%20Liu%20-%20Escape%20From%20The%20Docker-KVM-QEMU%20Machine.pdf.

Co s tím? Zcela zavrhnout virtualizaci a budování cloudů? Nikoliv. Odpovědí je rozumné plánování dedikace HW zdrojů pro bezpečnostně důležité komponenty a rozumné zvážení, zde je vhodné sdílet HW (hypervisor) virtálními servery s odlišnou bezpečnostní klasifikací/určením (do bezpečnostní zóny).
Toto opatření nijak radikálně nezesložiťuje prostředí, nezamezuje efektivnímu využití HW prostředků cloudu ani nijak zásadně nezvyšuje administrativní nároky na budování cloudu. Naopak nám pomůže zachovat o něco vyšší bezpečnost.

  • obsah/bezpecnost/virtualizace_escape.txt
  • Last modified: 2018/10/17 18:57
  • by profors