Kūrėjai mėgsta konteinerius. Jas lengva naudoti ir greitai paleisti. Daugelį jų galite paleisti net su paprasta aparatine įranga. Paleisties pridėtinės išlaidos visada buvo kūrimo ir bandymų banga, ir šios pridėtinės išlaidos tik didėja, naudojant mikropaslaugų architektūrą. Jei kūrėjui reikia pusės dešimties paslaugų, jis gali lengvai sugaišti dieną ar dvi, atlikdamas sąranką - aparatūros konfigūravimą, diegimo programų paleidimą, kovą su nesuderinamumais.
Su konteineriais, kurie sugenda iki kelių minučių ar sekundžių ir gali būti paleisti vienoje kūrimo darbo vietoje. Lengvai prieinamos naudingų talpyklinių vaizdų saugyklos padidina kūrėjų produktyvumą, panašiai kaip tai daro atvirasis šaltinis, tačiau nekyla problemų kuriant. Operacijų komandos lėčiau priėmė konteinerius. Viena iš priežasčių yra ta, kad daugelis programų, kurias jie turi palaikyti, dar nėra sudėtiniai. Kita priežastis yra nenoras nutolti nuo VM.
Opams perėjimas nuo pliko metalo prie VM buvo natūralus. Individualūs VM atrodo ir gali būti valdomi kaip atskiros sistemos, naudojant tuos pačius įrankius ir procesus. Ankstyvą susirūpinimą dėl VM saugumo panaikino ilga VM gamybos istorija didžiųjų kadrų pasaulyje, galimybė taikyti tuos pačius valdiklius, kurie naudojami plikoms metalinėms sistemoms, techninės įrangos virtualizacijos palaikymas ir besikeičianti VM valdymo įrankių branda.
Daugelis ankstyvų saugumo rūpesčių nulėmė vieną klausimą: ar VM buvo tokie pat saugūs kaip plikas metalas? Dabar panašūs klausimai keliami ir dėl konteinerių. Kiek saugūs yra konteineriai ir kaip jie lyginami su VM? Žinoma, jei palyginsime konteineriuose veikiančias paslaugas su tomis pačiomis paslaugomis, kurios veikia kaip atskiri procesai toje pačioje sistemoje, sudėtinio rodinio versija yra saugesnė. Atskyrimas, kurį teikia „Linux“ vardų sritys ir „cgroups“, suteikia kliūčių, kurių nėra tarp paprastų procesų. Palyginimas su VM yra ne toks aiškus. Pažvelkime į VM ir konteinerius iš saugumo perspektyvos.
Šiame straipsnyje aš atsižvelgsiu į du skirtingus metodus palygindamas VM ir sudėtinių rodinių saugumą. Pirmasis požiūris bus labiau struktūrinis arba teorinis, atsižvelgiant į kiekvieno ypatybes saugumo požiūriu. Tada pritaikysiu praktiškesnę analizę, atsižvelgdama į tai, kas vyksta tipiškame pažeidime ir kaip tai gali paveikti sudėtinių rodinių ir VM architektūros.
Struktūrinis vaizdas
Struktūriniam požiūriui palyginsiu abiejų sistemų atakos paviršių. Atakos paviršius nurodo taškų, kuriuose sistema gali būti užpulta, skaičių. Jis nėra tiksliai apibrėžtas (pavyzdžiui, kaip skaičius), tačiau yra naudingas palyginimams. Įsilaužusiam namui su 10 durų yra didesnis užpuolimo paviršius nei namui su vienomis durimis, net jei durys yra tapačios. Vienos durys gali likti neužrakintos; viena spyna gali būti sugedusi; durys skirtingose vietose gali suteikti įsibrovėjui daugiau privatumo ir pan.
Kompiuterinėse sistemose atakos paviršius apima viską, kur užpuolikas (arba jo vardu veikianti programinė įranga) gali „paliesti“ tikslinę sistemą. Tinklo sąsajos, aparatūros jungtys ir bendri ištekliai yra visi galimi atakos taškai. Atminkite, kad atakos paviršius nereiškia, kad yra tikras pažeidžiamumas. Visos 10 durų gali būti visiškai saugios. Bet didesnis atakos paviršius reiškia daugiau vietų apsaugoti ir didesnė tikimybė, kad užpuolikas ras bent vienos silpnybę.
Bendras atakos paviršius priklauso nuo skirtingų sąlyčio taškų skaičiaus ir jų sudėtingumo. Pažvelkime į paprastą pavyzdį. Įsivaizduokite senamadišką sistemą, kuri aptarnauja akcijų rinkos kotiruotes. Jis turi vieną sąsają, paprastą nuoseklią liniją. Toje eilutėje esantis protokolas taip pat yra paprastas: fiksuoto ilgio akcijų simbolis, tarkim, penki simboliai, siunčiamas į serverį, kuris atsako pateikdamas fiksuoto ilgio kainos pasiūlymą - tarkime, 10 simbolių. Nėra „Ethernet“, TCP / IP, HTTP ir pan. (Aš iš tikrųjų seniai dirbau tokiose sistemose toli toli esančioje galaktikoje.)
Šios sistemos atakos paviršius yra labai mažas. Užpuolikas gali manipuliuoti serijinės linijos elektrinėmis charakteristikomis, siųsti neteisingus simbolius, per daug duomenų ar kitaip pakeisti protokolą. Apsaugant sistemą būtų įgyvendinta atitinkama šių atakų kontrolė.
Dabar įsivaizduokite tą pačią paslaugą, tačiau modernioje architektūroje. Paslauga yra prieinama internete ir atskleidžia RESTful API. Elektrinės atakos pusės nebėra - tereikia apkepti paties užpuoliko maršrutizatorių ar jungiklį. Tačiau protokolas yra labai sudėtingas. Jame yra IP, TCP, galbūt TLS ir HTTP sluoksniai, kiekvienas iš jų suteikia galimybę pasinaudoti pažeidžiamumu. Šiuolaikinė sistema turi daug didesnį atakos paviršių, nors ji vis tiek puolėjui atrodo kaip vienas sąsajos taškas.
Pliko metalo atakos paviršius
Užpuolikui, kuris fiziškai nėra duomenų centre, pradinis atakos paviršius yra tinklas į serverį. Tai paskatino saugumo „perimetrinį vaizdą“: Apsaugokite įėjimo taškus į duomenų centrą ir niekas nepateks. Jei užpuolikas negali patekti, nesvarbu, kas vyksta tarp sistemų viduje. Tai gerai veikė, kai perimetro sąsajos buvo paprastos (pagalvokite, kad bus įjungtas telefono ryšys), tačiau sustiprino vidinių sąsajų silpnybes. Užpuolikai, radę skylę perimetre, dažnai pastebėjo, kad serverio fermos vidinis atakos paviršius buvo daug didesnis nei išorinis, ir patekę į vidų jie galėjo padaryti nemažai žalos.
Šis vidinis atakos paviršius apėmė tinklo ryšius tarp serverių, bet ir procesų tarpusavio sąveiką viename serveryje. Dar blogiau, kadangi daugelis paslaugų veikia su padidintomis privilegijomis („root“ vartotojas), sėkmingai įsilaužus į jas, faktiškai reikštų nevaržomą prieigą prie bet ko kito toje sistemoje ir nereikėtų ieškoti papildomų pažeidžiamumų. Aplink serverių apsaugą užaugo visa pramonė - ugniasienės, antimalware, įsibrovimo aptikimas, įjungimas ir įjungimas - ir rezultatai buvo ne tokie geri.
Taip pat yra įdomių „šalutinio kanalo“ atakų prieš serverius. Mokslininkai parodė kompiuterių energijos suvartojimo, triukšmo ar elektromagnetinės spinduliuotės panaudojimo pavyzdžius, norint gauti informaciją, kartais labai jautrius duomenis, tokius kaip kriptografiniai raktai. Kiti išpuoliai panaudojo atviras sąsajas, tokias kaip belaidžio klaviatūros protokolai. Tačiau apskritai šios atakos yra sunkesnės - joms gali prireikti, pvz., Serverio, taigi pagrindinis kelias „nusileisti laidu“ yra dažnesnis.
VM atakos paviršius
Kai VM yra naudojami taip pat, kaip ir plikas metalas, be jokio skirtumo programos architektūroje (kaip dažnai būna), jie dalijasi daugeliu tų pačių atakos taškų. Vienas papildomas atakos paviršius yra hipervizoriaus, OS ar aparatūros galimas gedimas tinkamai izoliuoti išteklius tarp VM, leidžiant VM kažkaip nuskaityti kito VM atmintį. Sąsaja tarp VM ir hipervizoriaus taip pat reiškia atakos tašką. Jei VM gali prasiveržti ir gauti savavališką kodą, veikiantį hipervizoriuje, tada jis gali pasiekti kitus tos pačios sistemos VM. Pats hipervizorius yra atakos taškas, nes jis atskleidžia valdymo sąsajas.
Yra papildomų atakos taškų, priklausomai nuo VM sistemos tipo. 2 tipo VM sistemose naudojamas hipervizorius, veikiantis kaip procesas pagrindinėje pagrindinėje OS. Šias sistemas galima užpulti atakuojant pagrindinę OS. Jei užpuolikas gali paleisti kodą pagrindinėje sistemoje, jis gali paveikti hipervizorių ir VM, ypač jei jis gali pasiekti kaip privilegijuotas vartotojas. Visa OS, įskaitant komunalines paslaugas, valdymo įrankius ir galbūt kitas paslaugas bei įėjimo taškus (pvz., SSH), suteikia daugybę galimų atakos taškų. 1 tipo VM sistemos, kai hipervizorius veikia tiesiai ant pagrindinės aparatūros, pašalina šiuos įėjimo taškus ir todėl turi mažesnį atakos paviršių.
Konteinerio atakos paviršius
Kaip ir VM, konteineriai dalijasi pagrindiniais neapsaugotų metalų sistemų patekimo į tinklą taškais. Be to, kaip ir 2 tipo virtualios mašinos, konteinerių sistemoms, naudojančioms „visiškai įkrautą“ pagrindinę OS, taikomos visos tos pačios atakos, prieinamos šios pagrindinės OS komunalinėms paslaugoms ir paslaugoms. Jei užpuolikas gali patekti į tą šeimininką, jis gali pabandyti pasiekti ar kitaip paveikti veikiančius konteinerius. Jei jis gauna privilegijuotą („root“) prieigą, užpuolikas galės prieiti prie bet kurio konteinerio arba jį valdyti. „Minimalistinė“ OS (pvz., „Apcera“ „KurmaOS“) gali padėti sumažinti šio užpuolimo paviršių, tačiau negali jo visiškai pašalinti, nes tam, kad būtų galima tvarkyti konteinerius, reikalinga tam tikra prieiga prie pagrindinės OS.
Pagrindiniai konteinerių atskyrimo mechanizmai (vardų erdvės) taip pat siūlo potencialius atakos taškus. Be to, ne visi „Linux“ sistemų procesų aspektai yra pavadinimai, todėl kai kurie elementai yra bendrinami konteineriuose. Tai yra natūralios zonos, kurias užpuolikai gali ištirti. Galiausiai, branduolio sąsajos procesas (sistemos iškvietimams) yra didelis ir matomas kiekviename konteineryje, priešingai nei daug mažesnė sąsaja tarp VM ir hipervizoriaus. Sistemos skambučių pažeidžiamumas gali suteikti galimybę pasiekti branduolį. Vienas to pavyzdžių yra neseniai pranešta apie „Linux“ raktų paketo pažeidžiamumą.
Architektūriniai sumetimai
Tiek VM, tiek talpyklose atakos paviršiaus dydį gali paveikti programos architektūra ir tai, kaip naudojama technologija.
Daugelis senų VM programų VM traktuoja kaip pliką metalą. Kitaip tariant, jie nepritaikė savo architektūros specialiai VM ar saugos modeliams, kurie nėra pagrįsti perimetro saugumu. Jie gali įdiegti daug paslaugų tame pačiame VM, paleisti paslaugas su pagrindinėmis teisėmis ir turėti mažai arba visai neturi saugos kontrolės. Tiriant šias programas (arba greičiausiai jas pakeičiant naujesnėmis), gali būti naudojamos VM, kad būtų užtikrintas saugus funkcinių vienetų atskyrimas, o ne paprasčiausiai kaip priemonė valdyti didesnį mašinų skaičių.
Konteineriai yra tinkami mikropaslaugų architektūroms, kurios „sujungia“ daugybę (paprastai) mažų paslaugų, naudodamos standartizuotas API. Tokių paslaugų tarnavimo laikas dažnai būna labai trumpas, kai konteineriais vežama paslauga pradedama pagal pareikalavimą, atsakoma į užklausą ir yra sunaikinama arba kai paslaugos greitai padidėja ir mažėja, atsižvelgiant į paklausą. Šis naudojimo būdas priklauso nuo greito konteinerių palaikymo. Žvelgiant iš saugumo perspektyvos, jis turi ir privalumų, ir trūkumų.
Didesnis paslaugų skaičius reiškia didesnį tinklo sąsajų skaičių ir didesnį atakos paviršių. Tačiau tai taip pat leidžia daugiau valdyti tinklo sluoksnį. Pavyzdžiui, „Apcera“ platformoje turi būti aiškiai leidžiamas visas konteinerių – konteinerių srautas. Nesąžiningas konteineris negali savavališkai pasiekti bet kurio tinklo galinio taško.
Trumpas konteinerio tarnavimo laikas reiškia, kad jei užpuolikas patenka, laikas, kurį jis turi padaryti, yra ribotas, o ne galimybių langas, kurį teikia ilgai veikianti tarnyba. Trūkumas yra tas, kad teismo ekspertizė yra sunkesnė. Kai konteinerio nebeliks, jo negalima ištirti ir ištirti, norint rasti kenkėjišką programą. Šios architektūros taip pat apsunkina užpuoliko diegimą kenkėjiškų programų, išgyvenančių po konteinerio sunaikinimo, nes jis gali ant pliko metalo įdiegdamas tvarkyklę, įkeliamą įkrovos metu. Konteineriai paprastai kraunami iš patikimos, tik skaitymo saugyklos, ir jas galima dar labiau apsaugoti atliekant kriptografinius patikrinimus.
Dabar apsvarstykime, kas vyksta pažeidimo metu.
Apsauga nuo pažeidimų
Užpuolikai paprastai turi vieną ar du tikslus įsilaužti į serverio sistemą. Jie nori gauti duomenų arba padaryti žalos.
Jei jie ieško duomenų, jie nori įsiskverbti į kuo daugiau sistemų su kuo didesnėmis privilegijomis ir išlaikyti šią prieigą kuo ilgiau. Tai pasiekus, jiems suteikiama laiko surasti duomenis, kurie jau gali būti, pvz., Blogai saugoma duomenų bazė, arba laikui bėgant gali tekti lėtai juos rinkti, pavyzdžiui, rinkti operacijas, kai jos gaunamos iš vartotojų. Norint išlaikyti prieigą ilgą laiką, reikia slapta. Ataka taip pat reikalauja būdo gauti duomenis.
Jei užpuolikas bando padaryti tiesiog žalą, vėl siekiama pasiekti kuo daugiau sistemų ir privilegijų. Tačiau yra pusiausvyros veiksmas: kai tik žala prasidės, ji greičiausiai bus pastebėta, tačiau kuo ilgiau užpuolikas laukia pradžios (tuo tarpu kenkėjiškos programos filtruojamos iš sistemos į sistemą), tuo didesnė tikimybė būti aptiktai. Išgauti duomenis yra mažiau svarbu nei koordinuota kenkėjiškų programų kontrolė. Idėja yra užkrėsti kuo daugiau sistemų, tada jas sugadinti sinchronizuotame taške, arba iš anksto parengus, arba pagal komandą.
Pažeidimai apima daugybę elementų. Pažvelkime į kiekvieną ir pažiūrėkime, ar VM ir konteinerinės architektūros gali paveikti kiekvieno iš jų atakos paviršių.
