Programmēšana

Vai VM ir drošāki par konteineriem?

Mēs bieži sakām: “HTTPS ir drošs” vai “HTTP nav drošs”. Bet tas, ko mēs domājam, ir tas, ka “HTTPS ir grūti snoopēt un tas apgrūtina cilvēka uzbrukumus vidē” vai “manai vecmāmiņai nav problēmu snoopēt HTTP”.

Neskatoties uz to, HTTPS ir uzlauzts, un dažos gadījumos HTTP ir pietiekami drošs. Turklāt, ja es atklāju izmantojamu defektu kopējā ieviešanā, kas atbalsta HTTPS (domāju, ka OpenSSL un Heartbleed), HTTPS var kļūt par hakeru vārteju, līdz ieviešana tiek izlabota.

HTTP un HTTPS ir protokoli, kas definēti IETF RFC 7230-7237 un 2828. HTTPS tika veidots kā drošs HTTP, taču sakot, ka HTTPS ir drošs un HTTP joprojām neslēpj svarīgus izņēmumus.

Virtuālās mašīnas (VM) un konteineri ir definēti mazāk stingri, un neviens no tiem nav apzināti izstrādāts tā, lai būtu drošāks par otru. Tāpēc drošības jautājumi joprojām ir neskaidrāki.

Kāpēc es uzskatu, ka VM ir drošāki nekā konteineri

Dalīt un iekarot ir uzvaroša stratēģija karā un programmatūrā. Kad arhitektūra sadala vienu sarežģītu, grūti atrisināmu drošības problēmu vieglākās problēmās, rezultāts vairumā gadījumu būs drošāks nekā viens risinājums, kas risina visas problēmas.

Konteineri ir sadalīšanas un iekarošanas piemērs, kas horizontāli tiek piemērots lietojumprogrammām. Bloķējot katru lietojumprogrammu savā cietumā, vienas lietojumprogrammas vājās vietas vājina lietojumprogrammas citos konteineros. Arī VM dala un iekaro, taču izolācijā viņi iet soli tālāk.

Mārvins Vaskē /

Ieslodzījuma aplikācijas trūkums nevar tieši ietekmēt citas lietojumprogrammas, taču ieslodzītā lietojumprogramma var izjaukt vienoto operētājsistēmu (OS), kas koplietota ar citiem konteineriem, un ietekmēt visus konteinerus. Izmantojot koplietojamu operētājsistēmu, trūkumi jebkurā lietojumprogrammas, konteinera un OS ieviešanas kaudzes punktā var padarīt nederīgu visa kaudzes drošību un apdraudēt fizisko mašīnu.

+ Arī tīklā World: kas ir lētāks: konteineri vai virtuālās mašīnas? +

Slāņveida arhitektūra, piemēram, virtualizācija, atdala katras lietojumprogrammas izpildes kaudzi līdz aparatūrai, novēršot iespēju lietojumprogrammām iejaukties savā starpā, izmantojot koplietojamo OS. Turklāt interfeiss starp katru lietojumprogrammu kaudzīti un aparatūru ir noteikts un ierobežots, lai novērstu ļaunprātīgu izmantošanu. Tas nodrošina papildu izturīgu perimetru, lai aizsargātu lietojumprogrammas viena no otras.

VM nošķir operētājsistēmu, kas kontrolē lietotāja darbību, no hipervizora, kas kontrolē mijiedarbību starp viesa OS un aparatūru. VM viesu OS kontrolē lietotāja darbību, bet ne aparatūras mijiedarbību. Lietojumprogrammas vai viesa OS kļūda, visticamāk, neietekmēs fizisko aparatūru vai citas VM. Kad VM viesa OS un konteineru atbalstošā OS ir identiskas, kas bieži notiek, tā pati ievainojamība, kas apdraudēs visus pārējos OS darbojamos konteinerus, neapdraudēs citas VM. Tādējādi VM nošķir lietojumprogrammas horizontāli un arī vertikāli atdala OS no aparatūras.

VM virs galvas

VM papildu drošība nāk uz rēķina. Vadības pārsūtīšana skaitļošanas sistēmās vienmēr ir dārga gan procesoru ciklos, gan citos resursos. Izpildes skursteņi tiek glabāti un atiestatīti, ārējās darbības var būt jāpārtrauc vai jāļauj tām pabeigt utt.

Pārslēgšanās starp viesu OS un hipervizoru maksā daudz un notiek bieži. Pat ar īpašām vadības instrukcijām, kas sadedzinātas procesora mikroshēmās, vadības pārsūtīšanas pieskaitāmās izmaksas samazina VM kopējo efektivitāti. Vai samazinājums ir ievērojams? Grūts jautājums. Lietojumprogrammas var noregulēt, lai samazinātu pieskaitāmās izmaksas, pārvaldot vadības pārsūtīšanu, un lielākā daļa servera procesoru tagad ir paredzēti vadības pārsūtīšanas vienkāršošanai. Citiem vārdiem sakot, nozīme ir atkarīga no lietojumprogrammas un servera, taču pieskaitāmās izmaksas nekad nevar pilnībā novērst, tikai mazināt.

Hipervizora ievainojamība

Lai vēl vairāk sarežģītu situāciju, slāņu atdalīšana VM arhitektūrā rada vēl vienu rēgu: hipervizora trūkumus. Hipervizora pārkāpums ir viens neveiksmes punkts, kam var būt milzīgas sekas, īpaši publiskos mākoņos. Iedomājams, ka viens hakeris varētu palaist kodu VM, kas pārņem kontroli pār lietojumprogrammām, kas pieder citiem publiskiem mākoņu patērētājiem, vienlaicīgi izmantojot publiskā mākoņa daļu.

Stingrā arhitektūrā joprojām var būt ieviešanas defekti, kas ievērojami vājina sistēmu. Hipervizora pārkāpumus bieži novērš, apgalvojot, ka tie nekad nenotiks: Stāsts vēsta, ka hipervizori ir tik vienkārši, tik labi uzrakstīti, tik rūpīgi pārbaudīti, ka nekad neizdodas. Hipervizora pārkāpums varētu būt tikpat postošs kā WannaCry, taču neuztraucieties par to. Bet notika Heartbleed. Un OpenSSL ir daudz mazāk koda rindiņu nekā hipervizoram. Man tagad jāiet ārā - mana lidojošā cūka vēlas vairāk latvāņu.

Es nezinu, ka līdz šim būtu bijuši ievērojami hipervizora pārkāpumi. Bet, ātri ieskatoties datu bāzē “Common Vulnerilities and Exposures” (CVE), atklājas, ka pētnieki atklāj izmantojamas hipervizora vājās vietas. Hipervizora izstrādātāji un pārdevēji ir ātri aizlāpījuši ievainojamības, kad tās rodas. 2017. gada martā korporācija Microsoft izdeva drošības biļetenu MS17-008, dokumentējot Hyper-V hipervizorā septiņas ielāpītas ievainojamības vietas, kuras visas ir nozīmētas vai kritiskas.

Es joprojām uzskatu, ka VM nodrošina labāku drošību nekā konteineri, taču mums ir skaidri jāskatās uz VM sistēmu drošību. Es plānoju nākotnē sīkāk apspriest hipervizora vājās vietas. Arī konteineri un VM bieži tiek apvienoti. Vēl ir daudz ko teikt.

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