Izstrādātājiem patīk konteineri. Tās ir viegli lietojamas un ātri iedarbināmas. Daudzus no tiem varat palaist pat ar vienkāršu aparatūru. Startēšanas pieskaitāmās izmaksas vienmēr ir bijušas izstrādes un testēšanas grūtības, un šīs izmaksas palielinās tikai ar mikropakalpojumu arhitektūru. Ja izstrādātājam ir nepieciešams pusducis pakalpojumu, viņš var viegli iztērēt vienu vai divas dienas ar iestatīšanu - aparatūras konfigurēšanu, instalētāju palaišanu, cīņu pret nesaderību.
Ar konteineriem tas sabrūk minūtēs vai sekundēs un var darboties vienā izstrādes darbstacijā. Viegli pieejamie noderīgo konteineru attēlu krātuves palielina izstrādātāju produktivitāti, līdzīgi kā to dara atvērtais avots, taču bez grūtībām veikt veidošanu. Operāciju komandas lēnāk pieņem konteinerus. Viens no iemesliem ir tas, ka daudzas lietojumprogrammas, kas tām jāatbalsta, vēl nav konteineros. Vēl viens iemesls ir nevēlēšanās attālināties no VM.
Opiem pāreja no tukša metāla uz VM bija likumsakarīga. Atsevišķi VM izskatās un tos var pārvaldīt tāpat kā atsevišķas sistēmas, izmantojot tos pašus rīkus un procesus. Agrās bažas par VM drošību kliedēja garā VM ražošanas vēsture lieldatoru pasaulē, spēja pielietot tādas pašas vadīklas kā tukša metāla sistēmām, aparatūras virtualizācijas atbalsts un VM pārvaldības rīku brieduma pakāpe.
Daudzas agrīnas drošības problēmas bija saistītas ar vienu jautājumu: vai VM bija tikpat droši kā kails metāls? Tagad līdzīgi jautājumi tiek uzdoti par konteineriem. Cik droši ir konteineri un kā tos salīdzina ar VM? Protams, ja mēs salīdzinām konteineros darbotos pakalpojumus ar tiem pašiem pakalpojumiem, kas darbojas kā atsevišķi procesi tajā pašā sistēmā, konteinera versija ir drošāka. Atdalīšana, ko nodrošina Linux nosaukumvietas un cgroups, nodrošina šķēršļus, kas nepastāv starp vienkāršiem procesiem. Salīdzinājums ar VM ir mazāk skaidrs. Apskatīsim VM un konteinerus no drošības viedokļa.
Šajā rakstā es izmantoju divas dažādas pieejas, lai salīdzinātu VM un konteineru drošību. Pirmā pieeja būs strukturālāka vai teorētiskāka, aplūkojot katras īpašības no drošības viedokļa. Tad es izmantošu praktiskāku analīzi, aplūkojot to, kas notiek tipiskā pārkāpumā, un to, kā to varētu ietekmēt konteineru un VM arhitektūras.
Strukturālais skats
Strukturālajai pieejai es salīdzināšu abu sistēmu uzbrukuma virsmu. Uzbrukuma virsma norāda punktu skaitu, kuros sistēmai var uzbrukt. Tas nav precīzi definēts (piemēram, kā skaitlis), bet ir noderīgs salīdzinājumiem. Uzlaupītājam mājai ar 10 durvīm ir lielāka uzbrukuma virsma nekā mājai ar vienām durvīm, pat ja durvis ir identiskas. Vienas durvis var atstāt neaizslēgtas; viena slēdzene var būt bojāta; durvis dažādās vietās var piedāvāt iebrucējam lielāku privātumu utt.
Datorsistēmās uzbrukuma virsma ietver visu, kur uzbrucējs (vai programmatūra, kas darbojas viņa vārdā) var “pieskarties” mērķa sistēmai. Tīkla saskarnes, aparatūras savienojumi un koplietojamie resursi ir visi iespējamie uzbrukuma punkti. Ņemiet vērā, ka uzbrukuma virsma nenozīmē, ka pastāv reāla ievainojamība. Visas 10 durvis varētu būt pilnīgi drošas. Bet lielāka uzbrukuma virsma nozīmē vairāk vietu, kur aizsargāties, un lielāka iespējamība, ka uzbrucējs atradīs vājumu vismaz vienā.
Kopējā uzbrukuma virsma ir atkarīga no dažādu saskares punktu skaita un katra sarežģītības. Apskatīsim vienkāršu piemēru. Iedomājieties vecmodīgu sistēmu, kas kalpo akciju tirgus kotācijām. Tam ir viena saskarne, vienkārša sērijas līnija. Arī šīs līnijas protokols ir vienkāršs: serverim tiek nosūtīts fiksēta garuma akciju simbols, teiksim, piecas rakstzīmes, kas atbild ar fiksēta garuma cenu piedāvājumu - teiksim, 10 rakstzīmes. Nav Ethernet, TCP / IP, HTTP un tā tālāk. (Es jau sen strādāju pie šādām sistēmām galaktikā tālu, tālu.)
Šīs sistēmas uzbrukuma virsma ir ļoti maza. Uzbrucējs var manipulēt ar sērijas līnijas elektriskajām īpašībām, nosūtīt nepareizus simbolus, nosūtīt pārāk daudz datu vai citādi mainīt protokolu. Aizsargājot sistēmu, būtu jāīsteno atbilstoša kontrole pret šiem uzbrukumiem.
Tagad iedomājieties to pašu pakalpojumu, bet modernā arhitektūrā. Pakalpojums ir pieejams internetā un atklāj RESTful API. Uzbrukuma elektriskā puse ir pazudusi - viss, kas būs jādara, būs apcept uzbrucēja pašu maršrutētāju vai slēdzi. Bet protokols ir ārkārtīgi sarežģītāks. Tam ir slāņi IP, TCP, iespējams, TLS un HTTP, no kuriem katrs piedāvā izmantojamas ievainojamības iespēju. Mūsdienu sistēmai ir daudz lielāka uzbrukuma virsma, lai gan tā joprojām uzbrucējam izskatās kā viens saskarnes punkts.
Kailmetāla uzbrukuma virsma
Uzbrucējam, kurš fiziski neatrodas datu centrā, sākotnējā uzbrukuma virsma ir tīkls serverī. Tas noveda pie drošības “perimetra skata”: aizsargājiet ieejas punktus datu centrā, un nekas nenokļūst. Ja uzbrucējs nevar iekļūt, nav svarīgi, kas notiek starp sistēmām iekšpusē. Tas darbojās labi, kad perimetra saskarnes bija vienkāršas (domājiet par iezvanpieeju), taču veicināja iekšējo saskarņu vājās vietas. Uzbrucēji, kas perimetrā atrada caurumu, bieži atklāja, ka serveru fermas iekšējā uzbrukuma virsma bija daudz lielāka nekā ārējā, un, nonākot iekšā, viņi varēja nodarīt ievērojamus postījumus.
Šī iekšējā uzbrukuma virsma ietvēra tīkla savienojumus starp serveriem, bet arī procesu savstarpēju mijiedarbību vienā serverī. Sliktāk, tā kā daudzi pakalpojumi darbojas ar paaugstinātām privilēģijām (“root” lietotājs), veiksmīga iekļūšana tajā faktiski nozīmētu neierobežotu piekļuvi jebkuram citam šajā sistēmā, nemeklējot papildu ievainojamības. Ap serveru aizsardzību - ugunsmūri, antimalware, ielaušanās noteikšana un ieslēgšana un ieslēgšana - uzauga vesela nozare, kuras rezultāti bija ne visai perfekti.
Ir arī interesanti “sānu kanālu” uzbrukumi serveriem. Pētnieki ir parādījuši piemērus, kā datoros izmantot enerģijas patēriņu, troksni vai elektromagnētisko starojumu, lai iegūtu informāciju, dažreiz ļoti sensitīvus datus, piemēram, kriptogrāfiskās atslēgas. Citi uzbrukumi ir izmantojuši atklātās saskarnes, piemēram, bezvadu tastatūras protokolus. Tomēr kopumā šie uzbrukumi ir sarežģītāki - tiem, piemēram, var būt nepieciešams tuvums serverim, tāpēc galvenais ceļš, kas nāk “pa vadu”, ir biežāk sastopams.
VM uzbrukuma virsma
Ja VM tiek izmantoti tāpat kā kailais metāls, bez jebkādas atšķirības lietojumprogrammas arhitektūrā (kā tas parasti ir), viņiem ir kopīgi tie paši uzbrukuma punkti. Viena papildu uzbrukuma virsma ir hipervizora, OS vai aparatūras potenciāla kļūme, lai pareizi izolētu resursus starp VM, ļaujot VM kaut kā nolasīt citas VM atmiņu. VM un hipervizora saskarne ir arī uzbrukuma punkts. Ja VM var izlauzties un iegūt patvaļīgu kodu, kas darbojas hipervizorā, tas var piekļūt citiem tajā pašā sistēmā esošajiem VM. Pats hipervizors ir uzbrukuma punkts, jo tas atklāj vadības saskarnes.
Atkarībā no VM sistēmas veida ir papildu uzbrukuma punkti. 2. tipa VM sistēmās tiek izmantots hipervizors, kas darbojas kā process pamatā esošajā resursdatora OS. Šīm sistēmām var uzbrukt, uzbrūkot resursdatora OS. Ja uzbrucējs var iegūt kodu, kas darbojas resursdatora sistēmā, viņš potenciāli var ietekmēt hipervizoru un VM, it īpaši, ja viņš var piekļūt kā priviliģēts lietotājs. Visa OS klātbūtne, ieskaitot utilītprogrammas, pārvaldības rīkus un, iespējams, citus pakalpojumus un ieejas punktus (piemēram, SSH), nodrošina vairākus iespējamos uzbrukuma punktus. 1. tipa VM sistēmas, kurās hipervizors darbojas tieši uz pamatā esošās aparatūras, novērš šos ieejas punktus un tāpēc tiem ir mazāka uzbrukuma virsma.
Konteinera uzbrukuma virsma
Tāpat kā ar VM, arī konteineriem ir tukša metāla sistēmu galvenie tīkla ieejas uzbrukuma punkti. Turklāt, tāpat kā 2. tipa virtuālajām mašīnām, arī konteineru sistēmām, kas izmanto “pilnībā ielādētu” resursdatora OS, tiek pakļauti visi tie paši uzbrukumi, kas pieejami šīs uzņēmējas OS utilītprogrammām un pakalpojumiem. Ja uzbrucējs var piekļūt šim resursdatoram, viņš var mēģināt piekļūt skriešanas konteineriem vai kā citādi ietekmēt to. Ja viņam tiks piešķirta privileģēta (“root”) piekļuve, uzbrucējs varēs piekļūt jebkuram konteineram vai to kontrolēt. "Minimālistiska" operētājsistēma (piemēram, Apcera KurmaOS) var palīdzēt samazināt šo uzbrukuma virsmu, taču to nevar pilnībā novērst, jo konteineru pārvaldībai ir nepieciešama zināma piekļuve resursdatora OS.
Pamata konteineru atdalīšanas mehānismi (nosaukumvietas) piedāvā arī iespējamos uzbrukuma punktus. Turklāt ne visi Linux sistēmu procesu aspekti ir nosaukumvietā, tāpēc daži vienumi tiek koplietoti konteineros. Šīs ir dabiskas zonas, kurās uzbrucēji var pārbaudīt. Visbeidzot, process uz kodola saskarni (sistēmas izsaukumiem) ir liels un pakļauts katrā konteinerā, atšķirībā no daudz mazākā saskarnes starp VM un hipervizoru. Sistēmas zvanu ievainojamība var piedāvāt potenciālu piekļuvi kodolam. Viens piemērs tam ir nesen ziņotā ievainojamība Linux atslēgas gredzenā.
Arhitektūras apsvērumi
Gan VM, gan konteineriem uzbrukuma virsmas lielumu var ietekmēt lietojumprogrammas arhitektūra un tas, kā tiek izmantota tehnoloģija.
Daudzas mantotās VM lietojumprogrammas pret VM izturas kā pret tukšu metālu. Citiem vārdiem sakot, viņi nav pielāgojuši savas arhitektūras tieši VM vai drošības modeļiem, kuru pamatā nav perimetra drošības. Viņi var instalēt daudzus pakalpojumus tajā pašā VM, palaist pakalpojumus ar root tiesībām un starp pakalpojumiem ir maz vai nav drošības kontroles. Pārskatot šīs lietojumprogrammas (vai, visticamāk, aizstājot tās ar jaunākām), var izmantot VM, lai nodrošinātu drošības nodalīšanu starp funkcionālajām vienībām, nevis vienkārši kā līdzekli lielāka skaita mašīnu pārvaldīšanai.
Konteineri ir labi piemēroti mikropakalpojumu arhitektūrām, kas “saliek kopā” lielu skaitu (parasti) mazu pakalpojumu, izmantojot standartizētas API. Šādiem pakalpojumiem bieži ir ļoti īss kalpošanas laiks, kad konteineru pakalpojums tiek uzsākts pēc pieprasījuma, reaģē uz pieprasījumu un tiek iznīcināts vai kur pakalpojumi tiek strauji paaugstināti un samazināti, pamatojoties uz pieprasījumu. Šis lietošanas veids ir atkarīgs no ātras izpausmes, ko konteineri atbalsta. No drošības viedokļa tam ir gan priekšrocības, gan trūkumi.
Lielāks pakalpojumu skaits nozīmē lielāku tīkla saskarņu skaitu un līdz ar to lielāku uzbrukuma virsmu. Tomēr tas ļauj arī vairāk kontrolēt tīkla slāni. Piemēram, Apcera platformā ir skaidri jāatļauj visa satiksme no konteinera līdz konteineram. Negodīgs konteiners nevar patvaļīgi sasniegt nevienu tīkla galapunktu.
Īss konteinera kalpošanas laiks nozīmē, ka, ja uzbrucējs tomēr iekļūst, laiks, kas viņam jādara, ir ierobežots, atšķirībā no iespēju loga, ko piedāvā ilgstošs serviss. Negatīvais ir tas, ka tiesu ekspertīze ir grūtāka. Kad konteiners vairs nebūs, to nevar pārbaudīt un pārbaudīt, lai atrastu ļaunprātīgo programmatūru. Šīs arhitektūras arī padara uzbrucēju grūtāku instalēt ļaunprātīgu programmatūru, kas izdzīvo pēc konteinera iznīcināšanas, kā tas varētu notikt uz tukša metāla, instalējot draiveri, kas tiek ielādēts bootē. Konteineri parasti tiek ielādēti no uzticama, tikai lasāma krātuves, un tos var vēl vairāk nodrošināt ar kriptogrāfiskām pārbaudēm.
Tagad izskatīsim, kas notiek pārkāpuma laikā.
Aizsardzība pret pārkāpumiem
Uzbrucējiem parasti ir viens vai divi mērķi ielauzties servera sistēmā. Viņi vēlas iegūt datus vai nodarīt kaitējumu.
Ja viņi meklē datus, viņi vēlas iefiltrēties pēc iespējas vairāk sistēmās ar visaugstākajām privilēģijām un saglabāt šo piekļuvi pēc iespējas ilgāk. Lai to panāktu, viņiem ir laiks atrast datus, kas, iespējams, jau ir - piemēram, slikti aizsargāta datu bāze - vai, iespējams, būs vajadzīga lēna vākšana laika gaitā, piemēram, lai savāktu, piemēram, apkopotu darījumus, kad tie nāk no lietotājiem. Lai ilgstoši uzturētu piekļuvi, nepieciešama slepena rīcība. Uzbrukumam ir nepieciešams arī veids, kā iegūt datus.
Ja uzbrucējs mēģina vienkārši nodarīt kaitējumu, atkal mērķis ir piekļūt pēc iespējas vairāk sistēmām un privilēģijām. Bet ir līdzsvarojošs akts: Kad kaitējums sāksies, tas, domājams, tiks pamanīts, bet jo ilgāk uzbrucējs gaida sākumu (kamēr ļaunprātīgā programmatūra filtrē no sistēmas uz sistēmu), jo lielāka ir iespēja tikt atklāta. Datu iegūšana ir mazāk svarīga nekā saskaņota ļaunprogrammatūras kontrole. Ideja ir inficēt pēc iespējas vairāk sistēmu, pēc tam sabojāt tās sinhronizētā punktā, vai nu iepriekš sakārtojot, vai pēc komandas.
Pārkāpumi ietver vairākus elementus. Apskatīsim katru un redzēsim, vai VM un konteineru arhitektūras var ietekmēt katra uzbrukuma virsmu.
