Pogosto rečemo: »HTTPS je varen« ali »HTTP ni varen«. Mislimo pa na to, da je "HTTPS težko vohljati in otežuje napade človeka v sredini" ali "moja babica nima težav s smradanjem HTTP-ja."
Kljub temu so HTTPS vdrli in v nekaterih okoliščinah je HTTP dovolj varen. Poleg tega, če v običajni izvedbi, ki podpira HTTPS (odkrijem OpenSSL in Heartbleed) odkrijem napako, ki jo je mogoče izkoristiti, lahko HTTPS postane vdoren prehod, dokler se izvedba ne popravi.
HTTP in HTTPS sta protokola, opredeljena v IETF RFC 7230-7237 in 2828. HTTPS je bil zasnovan kot varen HTTP, vendar pravi, da je HTTPS varen in HTTP še vedno ne skriva pomembnih izjem.
Navidezni stroji (VM) in zabojniki so manj natančno opredeljeni in nobeden ni bil namenoma zasnovan tako, da bi bil bolj varen kot drugi. Zato so varnostna vprašanja še vedno bolj motna.
Zakaj verjamem, da so VM varnejši od zabojnikov
Delite in osvojite je zmagovalna strategija v vojni in programski opremi. Ko arhitektura en sam zapleten, težko rešiv varnostni problem razdeli na lažje, bo rezultat v večini primerov bolj varen kot ena sama rešitev, ki obravnava vse težave.
Posode so primer delitve in osvajanja, ki se horizontalno uporablja za aplikacije. Če vsako aplikacijo zaklenete v svoj zapor, slabosti ene aplikacije ne oslabijo aplikacij v drugih zabojnikih. VM se prav tako delijo in osvajajo, vendar grejo korak dlje v izolaciji.
Marvin Waschke /Napaka v zaprti aplikaciji ne more neposredno vplivati na druge programe, vendar lahko zaprta aplikacija zlomi posamezen operacijski sistem (OS), ki je v skupni rabi z drugimi vsebniki, in vpliva na vse vsebnike. S skupnim operacijskim sistemom lahko pomanjkljivosti na kateri koli točki sklada za izvajanje aplikacije, vsebnika in OS oslabijo varnost celotnega sklada in ogrozijo fizični stroj.
+ Tudi v omrežju Network World: Kaj je cenejše: zabojniki ali navidezni stroji? +
Večplastna arhitektura, kot je virtualizacija, ločuje izvedbeni sklad vsake aplikacije vse do strojne opreme in odpravlja možnost, da se aplikacije medsebojno motijo prek skupnega OS. Poleg tega je vmesnik med posameznim skladom aplikacij in strojno opremo definiran in omejen, da se prepreči zloraba. To zagotavlja dodaten robusten obseg za zaščito aplikacij med seboj.
VM ločujejo OS, ki nadzoruje uporabniško aktivnost, od hipervizorja, ki nadzoruje interakcijo med gostujočim OS in strojno opremo. Gostujoči OS VM nadzoruje aktivnost uporabnika, ne pa tudi interakcije s strojno opremo. Napaka v aplikaciji ali gostujočem OS verjetno ne bo vplivala na fizično strojno opremo ali druge VM-je. Ko sta gostujoči OS VM in OS, ki podpirata vsebnik, enaka, kar se pogosto zgodi, ista ranljivost, ki bo ogrozila vse druge vsebnike, ki se izvajajo v OS, ne bo ogrozila drugih VM. Tako VM ločujejo aplikacije vodoravno in tudi vertikalno ločujejo OS od strojne opreme.
VM režijski stroški
Dodatna varnost VM-jev je na račun. Prenos nadzora je v računalniških sistemih vedno drag, tako v ciklih procesorjev kot v drugih virih. Izvedbeni skladi se shranijo in ponastavijo, zunanje operacije bo morda treba zaustaviti ali dovoliti, da se dokončajo itd.
Premiki med gostujočim operacijskim sistemom in hipervizorjem stanejo in se zgodijo pogosto. Tudi s posebnimi navodili za nadzor, zapisanimi v čipe procesorja, režijski stroški prenosa nadzora zmanjšajo splošno učinkovitost VM-jev. Je zmanjšanje pomembno? Težko vprašanje. Aplikacije lahko nastavite tako, da zmanjšate režijske stroške z upravljanjem prenosa nadzora, večina strežniških procesorjev pa je zdaj zasnovanih za poenostavitev prenosa nadzora. Z drugimi besedami, pomembnost je odvisna od aplikacije in strežnika, toda režijskih stroškov ni mogoče popolnoma odpraviti, temveč le zmanjšati.
Ranljivosti hipervizorja
Če želite še bolj zapletati zadeve, ločevanje plasti v arhitekturi VM sproži še en spekter: hipervizorske napake. Kršitev hipervizorja je ena sama točka okvare, ki lahko povzroči velike posledice, zlasti v javnih oblakih. Možno je, da bi en heker lahko zagnal kodo v VM, ki prevzame nadzor nad aplikacijami v lasti drugih potrošnikov v javnem oblaku, in v enem samem izkoriščanju zastavil tranš javnega oblaka.
V trdni arhitekturi lahko še vedno obstajajo napake pri izvedbi, ki sistem močno oslabijo. Kršitve hipervizorja pogosto omilimo s trditvijo, da se nikoli ne bodo zgodile: zgodba pravi, da so hipervizorji tako preprosti, tako dobro napisani in tako skrbno preverjeni, da nikoli ne odpovedo. Kršitev hipervizorja je lahko uničujoča kot WannaCry, vendar ne skrbite zaradi tega. Toda Heartbleed se je zgodil. In OpenSSL ima veliko manj vrstic kode kot hipervizor. Zdaj moram ven - moj leteči prašič si želi več svinjarije.
Do danes ne poznam nobene pomembnejše kršitve hipervizorja. Toda hiter vpogled v zbirko podatkov o skupnih ranljivostih in izpostavljenosti (CVE) razkrije, da raziskovalci ugotavljajo izkoriščevalne slabosti hipervizorja. Razvijalci in prodajalci hipervizorja so hitro popravili ranljivosti, ko se pojavijo. Marca 2017 je Microsoft izdal Varnostni bilten MS17-008, v katerem je v hipervizorju Hyper-V dokumentiral sedem popravljenih ranljivosti, ki so bile označene za pomembne ali kritične.
Še vedno verjamem, da VM zagotavljajo boljšo varnost kot zabojniki, vendar moramo na varnost sistemov VM gledati z jasnimi očmi. V prihodnosti nameravam podrobneje razpravljati o slabostih hipervizorja. Prav tako se pogosto kombinirajo zabojniki in VM. Veliko je še treba povedati.
