Razvijalci obožujejo zabojnike. So enostavni za uporabo in hitri za zagon. Veliko jih lahko zaženete na celo preprosti strojni opremi. Režijski stroški zagona so bili vedno napor za razvoj in preizkušanje, in ti režijski stroški se povečujejo le z arhitekturami mikro storitev. Če razvijalec potrebuje pol ducata storitev, lahko dan ali dva z lahkoto zapravi z nastavitvami - konfiguriranjem strojne opreme, izvajanjem namestitvenih programov, bojem proti nezdružljivosti.
S posodami se ta zruši na minute ali sekunde in jo je mogoče zagnati na eni razvojni delovni postaji. Hitro dostopna skladišča uporabnih slik vsebnikov povečajo produktivnost razvijalcev, podobno kot to počne odprtokodna različica, vendar brez težav pri izdelavi. Operativne skupine so počasneje sprejele zabojnike. Eden od razlogov je, da številne aplikacije, ki jih morajo podpirati, še niso v kontejnerjih. Drugi razlog je nenaklonjenost odmiku od VM-jev.
Za operacijske sisteme je bil prehod z gole kovine na VM naravni. Posamezni VM so videti in jih je mogoče upravljati kot posamezni sistemi z uporabo istih orodij in procesov. Zgodnje pomisleke glede varnosti VM so ublažile dolga zgodovina proizvodnje VM-jev v svetu glavnih računalnikov, zmožnost uporabe enakih kontrol, kot se uporabljajo za sisteme brez kovin, podpora za virtualizacijo strojne opreme in razvijajoča se zrelost orodij za upravljanje VM.
Številne zgodnje varnostne skrbi so se nanašale na eno vprašanje: ali so bili VM varni kot gola kovina? Zdaj se podobna vprašanja zastavljajo tudi glede zabojnikov. Kako varni so zabojniki in kako se primerjajo z VM-ji? Če primerjamo storitve, ki se izvajajo v vsebnikih, z istimi storitvami, ki se izvajajo kot ločeni procesi v istem sistemu, je različica vsebnika bolj varna. Ločitev, ki jo omogočajo imenski prostori Linuxa in skupine skupin, predstavlja ovire, ki med navadnimi procesi ne obstajajo. Primerjava z VM je manj jasna. Oglejmo si VM-je in vsebnike z vidika varnosti.
V tem članku bom uporabil dva različna pristopa k primerjanju varnosti VM in vsebnika. Prvi pristop bo bolj strukturni ali teoretični, če bo značilnosti vsakega obravnaval z vidika varnosti. Potem bom uporabil bolj praktično analizo, tako da bom pogledal, kaj se zgodi pri tipični kršitvi in kako bi lahko nanjo vplivale arhitekture vsebnikov in VM.
Strukturni pogled
Za strukturni pristop bom primerjal napadalno površino obeh sistemov. Napadna površina predstavlja število točk, na katerih je sistem mogoče napasti. Ni natančno določeno (na primer kot številka), je pa uporabno za primerjave. Za vlomilca ima hiša z 10 vrati večjo napadalno površino kot hiša z enimi vrati, četudi so vrata enaka. Ena vrata morda ostanejo odklenjena; ena ključavnica je morda okvarjena; vrata na različnih lokacijah lahko vsiljivcu ponudijo več zasebnosti itd.
V računalniških sistemih napadalna površina vključuje vse, kjer se napadalec (ali programska oprema, ki deluje v njegovem imenu) lahko "dotakne" ciljnega sistema. Omrežni vmesniki, povezave strojne opreme in skupni viri so možne točke napada. Upoštevajte, da površina napada ne pomeni, da obstaja dejanska ranljivost. Vseh 10 vrat je lahko popolnoma varnih. Toda večja napadalna površina pomeni več prostorov za zaščito in večja verjetnost, da bo napadalec našel slabost vsaj v enem.
Skupna površina napada je odvisna od števila različnih stičnih točk in zahtevnosti vsake točke. Oglejmo si preprost primer. Predstavljajte si staromoden sistem, ki postreže z borznimi tečaji. Ima en sam vmesnik, preprosto zaporedno linijo. Tudi protokol v tej vrstici je preprost: strežniku se pošlje simbol zaloge s fiksno dolžino, recimo pet znakov, ki odgovori s ponudbo cene s fiksno dolžino - recimo 10 znakov. Ni Etherneta, TCP / IP, HTTP itd. (S takimi sistemi sem dejansko delal že davno v galaksiji daleč stran.)
Napadna površina tega sistema je zelo majhna. Napadalec lahko manipulira z električnimi značilnostmi serijske linije, pošilja nepravilne simbole, pošilja preveč podatkov ali drugače spreminja protokol. Zaščita sistema bi vključevala izvajanje ustreznega nadzora pred temi napadi.
Zdaj si predstavljajte isto storitev, vendar v sodobni arhitekturi. Storitev je na voljo na internetu in ponuja RESTful API. Električne strani napada ni več - vse, kar bo storil, je, da napadalcu napade lastni usmerjevalnik ali stikalo. Toda protokol je izjemno bolj zapleten. Ima sloje za IP, TCP, morda TLS in HTTP, od katerih vsak ponuja možnost izrabljive ranljivosti. Sodobni sistem ima veliko večjo površino napada, čeprav je napadalcu še vedno videti kot ena vmesna točka.
Napadna površina brez kovine
Za napadalca, ki fizično ni prisoten v podatkovnem centru, je začetna površina napada omrežje v strežnik. To je privedlo do "obodnega pogleda" varnosti: zaščitite vstopne točke v podatkovni center in nič ne vstopi. Če napadalec ne more vstopiti, ni pomembno, kaj se zgodi med notranjimi sistemi. Dobro je delovalo, ko so bili obodni vmesniki preprosti (pomislite na klicno povezavo), vendar so spodbujali slabosti notranjih vmesnikov. Napadalci, ki so našli luknjo v obodu, pogosto odkrijejo, da je notranja površina napada strežniške farme veliko večja od zunanje in da lahko enkrat naredijo znatno škodo.
Ta notranja površina napada je vključevala omrežne povezave med strežniki, pa tudi medsebojne interakcije znotraj enega strežnika. Še huje, ker številne storitve delujejo s povišanimi privilegiji ("root" uporabnik), bi uspešen vdor v enega dejansko pomenil neoviran dostop do česar koli drugega v tem sistemu, ne da bi bilo treba iskati dodatne ranljivosti. Celotna industrija je zrasla okoli zaščite strežnikov - požarnih zidov, protivirusne programske opreme, odkrivanja vdorov in še in še - z manj kot popolnimi rezultati.
Obstajajo tudi zanimivi napadi na "stranski kanal" na strežnike. Raziskovalci so prikazali primere uporabe porabe energije, hrupa ali elektromagnetnega sevanja iz računalnikov za pridobivanje informacij, včasih zelo občutljivih podatkov, kot so kriptografski ključi. Drugi napadi so izkoristili izpostavljene vmesnike, kot so protokoli brezžične tipkovnice. Na splošno pa so ti napadi težji - morda na primer zahtevajo bližino strežnika - zato je pogostejša glavna pot do "žice".
VM napadna površina
Kadar se VM uporabljajo enako kot gola kovina, brez kakršne koli razlike v arhitekturi aplikacije (kot so pogosto), si delijo večino istih napadalnih točk. Dodatna površina napada je potencialna napaka v hipervizorju, OS-ju ali strojni opremi, da pravilno izolira vire med VM-ji, kar omogoča VM-ju, da nekako prebere pomnilnik drugega VM-ja. Vmesnik med VM in hipervizorjem predstavlja tudi napadalno točko. Če se VM lahko prebije in v hipervizorju zažene poljubno kodo, potem lahko dostopa do drugih VM v istem sistemu. Hipervizor sam predstavlja napadalno točko, saj razkriva vmesnike za upravljanje.
Obstajajo dodatne točke napada, odvisno od vrste sistema VM. Sistemi VM tipa 2 uporabljajo hipervizor, ki se izvaja kot postopek v osnovnem gostiteljskem OS. Te sisteme je mogoče napasti z napadi na gostiteljski OS. Če lahko napadalec v gostiteljskem sistemu zažene kodo, lahko vpliva na hipervizor in VM, še posebej, če lahko dostopa kot privilegiran uporabnik. Prisotnost celotnega operacijskega sistema, vključno s pripomočki, orodji za upravljanje in morebitnimi drugimi storitvami in vstopnimi točkami (kot je SSH), ponuja številne možne točke napada. Sistemi VM tipa 1, kjer hipervizor deluje neposredno na osnovno strojno opremo, odstranijo te vstopne točke in imajo zato manjšo površino napada.
Napadna površina kontejnerja
Tako kot pri VM-jih imajo tudi zabojniki osnovne točke napadov v omrežje golokovinskih sistemov. Poleg tega so, tako kot navidezni stroji tipa 2, tudi v sistemih zabojnikov, ki uporabljajo "popolnoma naloženi" gostiteljski OS, napadi enaki, ki so na voljo proti pripomočkom in storitvam tega gostiteljskega OS. Če lahko napadalec pridobi dostop do tega gostitelja, lahko poskusi dostopati do tekočih vsebnikov ali kako drugače vplivati na njih. Če dobi privilegiran ("root") dostop, bo lahko napadalec dostopal do katerega koli vsebnika ali ga nadziral. "Minimalistični" OS (na primer Apcera's KurmaOS) lahko pomaga zmanjšati to površino napada, vendar je ne more popolnoma odpraviti, saj je za upravljanje vsebnika potreben nekaj dostopa do gostiteljskega OS.
Osnovni mehanizmi za ločevanje vsebnikov (prostori imen) ponujajo tudi potencialne točke napada. Poleg tega niso vsi vidiki procesov v sistemih Linux razporejeni po imenih, zato so nekateri elementi skupni vsebnikom. To so naravna območja za preiskovanje napadalcev. Na koncu je postopek vmesnika jedra (za sistemske klice) velik in izpostavljen v vsakem vsebniku, v nasprotju z veliko manjšim vmesnikom med VM in hipervizorjem. Ranljivosti v sistemskih klicih lahko nudijo potencialni dostop do jedra. Eden od primerov tega je nedavno poročana ranljivost v obroču za ključe Linux.
Arhitekturni premisleki
Tako na VM kot na vsebnike lahko na velikost napadne površine vpliva arhitektura aplikacije in način uporabe tehnologije.
Številne starejše aplikacije VM obravnavajo VM kot golo kovino. Z drugimi besedami, svojih arhitektur niso prilagodili posebej za VM-je ali varnostne modele, ki ne temeljijo na varnosti oboda. Na isti VM lahko namestijo veliko storitev, jih zaženejo s korenskimi privilegiji in med storitvami nimajo veliko ali nič nadzora. Ponovno razvrščanje teh aplikacij (ali verjetneje njihovo nadomeščanje z novejšimi) bi lahko uporabljalo VM-je za zagotavljanje varnostne ločitve med funkcionalnimi enotami in ne zgolj kot sredstvo za upravljanje večjega števila strojev.
Zabojniki so zelo primerni za arhitekture mikro storitev, ki "združujejo" veliko število (običajno) majhnih storitev z uporabo standardiziranih API-jev. Takšne storitve imajo pogosto zelo kratko življenjsko dobo, ko se kontejnerska storitev na zahtevo zažene, se odzove na zahtevo in je uničena ali kjer se storitve hitro povečujejo in spuščajo glede na povpraševanje. Ta vzorec uporabe je odvisen od hitrega primerka, ki ga podpirajo vsebniki. Z vidika varnosti ima tako prednosti kot slabosti.
Večje število storitev pomeni večje število omrežnih vmesnikov in s tem večjo površino napadov. Omogoča pa tudi več kontrol na omrežni plasti. Na primer, v platformi Apcera mora biti ves promet med zabojniki izrecno dovoljen. Prevarantski vsebnik ne more samovoljno doseči nobene končne točke omrežja.
Kratka življenjska doba kontejnerja pomeni, da je v primeru, da napadalec vstopi, čas, ki ga mora nekaj storiti, omejen, v nasprotju z okencem priložnosti, ki ga ponuja dolgotrajna storitev. Slaba stran je, da je forenzika težja. Ko posode ni več, je ni mogoče preizkusiti in pregledati, da bi našli zlonamerno programsko opremo. Te arhitekture tudi otežujejo napadalcu namestitev zlonamerne programske opreme, ki preživi po uničenju zabojnika, saj lahko na golo kovino namesti gonilnik, ki se naloži ob zagonu. Posode se običajno naložijo iz zaupanja vrednega skladišča, ki je samo za branje, in jih je mogoče dodatno zaščititi s kriptografskimi čeki.
Zdaj pa razmislimo, kaj se dogaja med kršitvijo.
Zaščita pred kršitvami
Napadalci imajo običajno en ali dva cilja pri vdoru v strežniški sistem. Želijo dobiti podatke ali narediti škodo.
Če lovijo podatke, se želijo vnesti v čim več sistemov z najvišjimi možnimi privilegiji in čim dlje ohraniti ta dostop. Če to dosežejo, imajo čas, da poiščejo podatke, ki so morda že na voljo - na primer slabo zavarovana baza podatkov - ali pa bodo morda sčasoma počasi zbirali, ko bodo kapljale, na primer zbiranje transakcij, ko pridejo od uporabnikov. Dolgotrajno vzdrževanje dostopa zahteva prikritost. Napad zahteva tudi način, kako pridobiti podatke.
Če napadalec skuša preprosto narediti škodo, je cilj spet dostop do čim večjega števila sistemov in privilegijev. Vendar obstaja izravnalno dejanje: Ko se škoda začne, bo verjetno opažena, toda dlje, ko napadalec čaka, da se zažene (medtem ko zlonamerna programska oprema filtrira od sistema do sistema), večja je možnost, da jo odkrijejo. Prenos podatkov je manj pomemben kot usklajen nadzor zlonamerne programske opreme. Ideja je okužiti čim več sistemov, nato pa jih poškodovati na sinhronizirani točki, bodisi vnaprej dogovorjeni ali po ukazu.
Kršitve vključujejo številne elemente. Oglejmo si vsako in poglejmo, ali lahko VM in kontejnerske arhitekture vplivajo na površino napada za vsako.
