Programavimas

Ar VM yra saugesni nei konteineriai?

Mes dažnai sakome: „HTTPS yra saugus“ arba „HTTP nėra saugus“. Bet mes turime omenyje tai, kad „HTTPS sunku iššniukštinėti ir apsunkina vidurio žmogaus atakas“ arba „mano močiutė neturi problemų šnipinėdama HTTP“.

Nepaisant to, į HTTPS buvo įsilaužta ir tam tikromis aplinkybėmis HTTP yra pakankamai saugus. Be to, jei atrandu išnaudojamą trūkumą bendrame įgyvendinime, palaikančiame HTTPS (pagalvokite apie „OpenSSL“ ir „Heartbleed“), HTTPS gali tapti įsilaužimo vartais, kol diegimas nebus ištaisytas.

HTTP ir HTTPS yra protokolai, apibrėžti IETF RFCs 7230-7237 ir 2828. HTTPS buvo sukurtas kaip saugus HTTP, tačiau sakydamas, kad HTTPS yra saugus ir HTTP vis dar neslepia svarbių išimčių.

Virtualiosios mašinos (VM) ir talpyklos nėra griežtai apibrėžtos ir nė viena nebuvo tyčia sukurta taip, kad būtų saugesnė už kitas. Todėl saugumo klausimai vis dar murklesni.

Kodėl manau, kad VM yra saugesni nei konteineriai

„Skaldyk ir užkariauk“ yra laimi strategija kare ir programinėje įrangoje. Kai architektūra suskirsto vieną sudėtingą, sunkiai išsprendžiamą saugos problemą į lengvesnes problemas, rezultatas daugeliu atvejų bus saugesnis nei vienas sprendimas, kuris išspręs visas problemas.

Konteineriai yra padalijimo ir užkariavimo pavyzdys, horizontaliai pritaikytas programoms. Užrakinant kiekvieną programą savo kalėjime, vienos programos trūkumai nesusilpnina programų kitose talpyklose. VM taip pat dalijasi ir užkariauja, tačiau jie žengia žingsnį toliau atskirai.

Marvin Waschke /

Įkalintos programos trūkumas negali tiesiogiai paveikti kitų programų, tačiau užfiksuota programa gali sugadinti vieną operacinę sistemą (OS), bendrinamą su kitais konteineriais, ir paveikti visus konteinerius. Naudojant bendrą OS, trūkumai bet kurioje programos, sudėtinio rodinio ir OS diegimo kamino vietoje gali pakenkti viso kamino saugumui ir pakenkti fizinei mašinai.

+ Taip pat „Network World“: kas yra pigiau: konteineriai ar virtualios mašinos? +

Daugiasluoksnė architektūra, pvz., Virtualizacija, atskiria kiekvienos programos vykdymo kaminą iki aparatinės įrangos, pašalindama galimybę programoms trukdyti viena kitai per bendrą OS. Be to, sąsaja tarp kiekvienos programos kamino ir aparatūros yra apibrėžta ir apribota, kad būtų išvengta piktnaudžiavimo. Tai suteikia papildomą tvirtą perimetrą, apsaugantį programas viena nuo kitos.

VM atskiria OS, valdančią vartotojo veiklą, nuo hipervizoriaus, valdančio svečio OS ir aparatinės įrangos sąveiką. VM svečių OS kontroliuoja vartotojo veiklą, bet ne aparatinės įrangos sąveiką. Mažai tikėtina, kad programos ar svečių OS trūkumas paveiks fizinę aparatinę įrangą ar kitas VM. Kai VM svečio OS ir konteinerį palaikanti OS yra tapačios, kas dažnai būna, tas pats pažeidžiamumas, dėl kurio bus pažeisti visi kiti OS veikiantys konteineriai, nekels pavojaus kitoms VM. Taigi, VM atskirai išskiria programas horizontaliai, taip pat vertikaliai atskiria OS nuo aparatūros.

VM virš galvos

Papildomas VM saugumas kainuoja. Valdymo perdavimas visada yra brangus skaičiavimo sistemose, tiek procesorių cikluose, tiek kituose šaltiniuose. Vykdymo kaminai yra saugomi ir atstatomi, išorines operacijas gali tekti pristabdyti arba leisti atlikti ir pan.

Perėjimas tarp svečio OS ir hipervizoriaus kainuoja daug ir dažnai nutinka. Net jei specialios valdymo instrukcijos įrašomos į procesoriaus lustus, valdymo perdavimo pridėtinės išlaidos sumažina bendrą VM efektyvumą. Ar sumažėjimas yra reikšmingas? Sunkus klausimas. Programos gali būti sureguliuotos taip, kad būtų sumažintos pridėtinės išlaidos valdant valdymo perdavimą, o dauguma serverio procesorių dabar suprojektuoti supaprastinti valdymo perdavimą. Kitaip tariant, reikšmė priklauso nuo programos ir serverio, tačiau pridėtinės išlaidos niekada negali būti visiškai pašalintos, o tik sumažintos.

Hipervizoriaus pažeidžiamumas

Kad būtų dar sudėtingiau, atskiriant sluoksnius VM architektūroje kyla dar vienas vaidmuo: hipervizoriaus trūkumai. Hipervizoriaus pažeidimas yra vienas nesėkmės taškas, galintis sukelti didelių padarinių, ypač viešuose debesyse. Tikėtina, kad vienas įsilaužėlis galėtų paleisti VM kodą, kuris perima kitų viešųjų debesų vartotojų valdomų programų kontrolę, vienu išnaudojimu ištraukdamas viešojo debesies dalį.

Tvirta architektūra vis tiek gali turėti įgyvendinimo defektų, kurie iš esmės susilpnina sistemą. Hipervizoriaus pažeidimai dažnai yra išvengiami teigiant, kad jų niekada neatsitiks: Pasakojama, kad hipervizoriai yra tokie paprasti, tokie gerai parašyti, taip kruopščiai patikrinti, kad niekada nesugenda. Hipervizoriaus pažeidimas gali būti toks pat pražūtingas kaip „WannaCry“, bet nesijaudinkite dėl to. Bet „Heartbleed“ įvyko. O OpenSSL turi daug mažiau kodo eilučių nei hipervizorius. Man dabar reikia išeiti - mano skraidanti kiaulė nori daugiau kiaulių.

Nežinau jokių reikšmingų hipervizoriaus pažeidimų iki šiol. Tačiau greitai peržvelgus „Common Vulnerlights and Exposures“ (CVE) duomenų bazę, paaiškėja, kad tyrėjai randa išnaudojamų hipervizoriaus trūkumų. Hipervizoriaus kūrėjai ir pardavėjai greitai užtaisė spragas, kai jie atsirado. 2017 m. Kovo mėn. „Microsoft“ išleido saugos biuletenį MS17-008, kuriame užfiksuotos septynios „Hyper-V“ hipervizoriaus pataisytos spragos, visos svarbios arba kritinės.

Aš vis dar tikiu, kad VM užtikrina geresnį saugumą nei konteineriai, tačiau į VM sistemų saugumą turime žiūrėti aiškiai. Ateityje planuoju išsamiau aptarti hipervizoriaus silpnybes. Be to, konteineriai ir VM dažnai derinami. Dar daug ką reikia pasakyti.

$config[zx-auto] not found$config[zx-overlay] not found