Konteinereid on kõikjal: kuidas neid kaitsta?

Konteinerite arv kasvab iga päevaga ja näib olevat kõikjal, kuna organisatsioonid soovivad saada palju eeliseid, mida need pakuvad, nagu agiilne rakenduste arendamine ja juurutamine kõigil platvormidel.

Paljud usuvad ka, et konteinerite kasutamine võib aidata neil nende lühiealisuse tõttu turvapiiranguid minimeerida. Kas see on tõsi või lihtsalt järjekordne väärarusaam?

Kuigi konteineritel ei ole loomupärast ebaturvalisust, kasutatakse neid sageli ebaturvaliselt, mis toob kaasa arvukalt turvaprobleeme.

Turvaprobleemid konteinerite juurutamisel

Kasutusele võetud konteinerite suur hulk, mitmekülgsus ja lühiajaline olek ning asjaolu, et konteinerid peavad suhtlema teiste üksustega, viivad selleni, et organisatsioonidel ei ole võimalik omada piisavat konteineritevahelise liikluse nähtavust.

Tänu sellisele nähtavuse puudumisele unustatakse konteinerid sageli ning sissetungimise ennetamise meetmed ja turvakontrollid muutuvad ebatõhusaks, suurendades rünnaku pinda ja seega ka üldist äririski. Lisaks võib vähene nähtavus kaasa tuua vastutuse nappuse, kuna konteinerid läbivad arendusest tootmiseni erinevaid keskkondi.

Teine konteineritega seotud turvaprobleem on nõrk haavatavuse haldamine. Näiteks olemasolevate piltide kloonimisel uute konteinerite loomiseks kopeeritakse ka nende haavatavused.

See rõhutab vajadust, et turvalisus oleks organisatsiooni konteineristrateegia lahutamatu osa. Vastasel juhul võivad konfiguratsioonivead ja puuduvad paigad olla tootmiskeskkondades volitamata piltide juurutamise ja käivitamise põhjuseks, mis suurendab rünnakute pinda ja edukamaid rünnakuid.

Lõpuks, kuna konteinerid kasutavad jagatud OS-i tuuma, võib hosti OS-i kerneli kompromiteerimine võltskonteineri poolt kaasa tuua juurdepääsu kaotamise kõigile või mis tahes hostis töötavatele konteineritele, nagu ka potentsiaalselt teistele võrgu hostidele.

Kuidas oma konteinereid kinnitada

Võib-olla on konteinerkeskkonna kaitsmise parim tava selle tegemise vajaduse tunnistamine. Kui see põhikontseptsioon välja arvata, on konteinerite tõhusaks kinnitamiseks järgida mõnda head nõu.

Olge oma konteineritesse nähtav

Enne konteineri juurutamist veenduge, et mõistaksite selle sõltuvusi ja selle sisu. Tagamaks, et teie konteinerikujutised oleksid puutumatud, peate saavutama nähtavuse igal etapil alates arendusest kuni tootmiseni.

Mahuti tarkvara mitte usaldamine on suurepärane lähtepunkt. Peate seda väga põhjalikult kontrollima, et mõista, kust need pärinevad, kuidas need on toodetud ja nende vastavad allikad, nagu märkis Dirk Hohndel, VMware asepresident 2019 aasta avatud lähtekoodiga juhtimise tippkohtumisel.

Lühidalt, kontrollige oma konteinerite sisu enne nende juurutamist üle ja ärge kunagi käivitage tundmatu või vananenud tarkvaraga konteinerit. See, et konteineri kujutis väidetavalt sisaldab uusimaid ja parimaid programme ja teeke, ei tähenda, et see seda tegelikult sisaldab.

Üks viis selle probleemi leevendamiseks on kasutada rakendusi, mis aitavad teil konteinereid puhastada. Kuigi mulle ei meeldi ratast uuesti leiutada, on võib-olla parim viis lõpetada teiste inimeste konteinerpiltide kasutamine.

Kui sina, nagu Hercules, lähed Virtue'i raskemale teele ja hakkad oma konteinerikujutisi ehitama, mõistad konteinerites toimuvat palju paremini, millel on lisaks turvalisusele ka eeliseid.

Juurjuurdepääsu juhtimine

Enamik konteinereid on vaikimisi loodud juurjuurdepääsuga. See on aga küsitav praktika. Kuigi arendajatel on lihtsam kasutada konteinereid juurjuurdepääsuga, kaasnevad juurjuurdepääsuga tohutud riskid.

Selle probleemi lahendamiseks on mitu lähenemisviisi. Üks võimalus on kindlaks teha ettevõtte poliitika, et ühelgi konteineril pole kunagi lubatud root kasutajana töötada. Alternatiivne viis on kasutada vähima privileegi põhimõtet. Konteinerpildi loomisel saate Dockerfile'is määrata mittejuurkasutaja, kes käitab konteinerit selle konkreetse kasutajana, kellel on minimaalne nõutav juurdepääs süsteemile.

Lõpuks saate konteinerite kaitsmiseks kasutada ka privilegeeritud konteineriprotsesside käitamisel kasutajanimeruumi . Selle meetodi puhul on konteineris nende protsesside käitamiseks UID null (mis on juur), kuid väljaspool konteinerit on UID privilegeerimata 1000.

Kontrollige konteineri tööaega

Riikliku standardite ja tehnoloogia instituudi (NIST) SP 800-190 " Rakenduskonteinerite turbejuhend " juhib tähelepanu sellele, et ka konteinerite käitusajad on rünnakute suhtes haavatavad. Kuigi see ei ole tavaline turvalünk, juhib NIST tähelepanu sellele, et konteineri käitusaegsed turvanõrkused võivad olla „ eriti ohtlikud ", kui need võimaldavad stsenaariume, mille korral pahatahtlik tarkvara võib rünnata teiste konteinerite ressursse ja hosti OS-i ennast.

Ründaja võib samuti olla võimeline turvaauke ära kasutama, et kahjustada käitusaegset tarkvara ja seejärel muuta seda tarkvara nii, et see võimaldaks ründajal pääseda juurde teistele konteineritele, jälgida konteineritevahelist sidet jne.

Turvaprobleemid on käitusaja konfiguratsioonide puhul palju tavalisemad. Konteinerite käitusajad pakuvad tavaliselt palju konfigureeritavaid valikuid. Nende vale seadistamine võib vähendada süsteemi suhtelist turvalisust.

Näiteks Linuxi konteineri hostides on lubatud süsteemikutsete hulk sageli vaikimisi piiratud ainult nendega, mis on vajalikud konteinerite ohutuks kasutamiseks. Kui seda loendit laiendatakse, võib see ohustada konteinereid ja hosti OS-i ohustatud konteineri tõttu.

Samamoodi, kui konteinerit käitatakse privilegeeritud režiimis, on sellel juurdepääs kõigile hosti seadmetele, mis võimaldab tal sisuliselt toimida hosti OS-i osana ja mõjutada kõiki teisi sellel töötavaid konteinereid.

Teine näide ebaturvalisest käitusaja konfiguratsioonist on lubada konteineritel hosti ühendada tundlikke katalooge. Kui ohustatud konteiner suudab neid teid muuta, võib seda kasutada õiguste tõstmiseks ja hosti enda ja ka teiste hostis töötavate konteinerite ründamiseks.

Karmistage operatsioonisüsteemi

NIST soovitab kasutada ka konteineripõhist operatsioonisüsteemi, kuna ohud on tavaliselt minimaalsemad, kuna operatsioonisüsteemid on spetsiaalselt loodud konteinerite majutamiseks ning muud teenused ja funktsioonid on keelatud.

Lisaks, kuna need optimeeritud OS-id on loodud spetsiaalselt konteinerite majutamiseks, sisaldavad nad tavaliselt kirjutuskaitstud failisüsteeme ja kasutavad vaikimisi muid kõvastusmeetodeid. Kui vähegi võimalik, peaksid organisatsioonid kasutama neid minimalistlikke OS-e, et vähendada oma ründepinda ja leevendada tavalisi riske ja üldiste OS-idega seotud tegevusi.

Organisatsioonid, mis ei saa kasutada konteinerispetsiifilist OS-i, peaksid järgima NIST SP 800-123, Üldise serveriturbe juhendi juhiseid, et vähendada oma hostide rünnakupinda nii palju kui võimalik.

Näiteks peaksid konteinereid käitavad hostid käitama ainult konteinereid, mitte aga muid rakendusi, nagu veebiserver või andmebaas, väljaspool konteinereid. Host OS ei tohiks käivitada tarbetuid süsteemiteenuseid, nagu prindispuuler, mis suurendab selle rünnakupinda.

Lõpuks tuleks hoste pidevalt turvaaukude tuvastamiseks skannida ja värskendusi kiiresti rakendada, mitte ainult konteineri käitusajal, vaid ka madalama taseme komponentidele, nagu kernel, millele konteinerid turvaliseks ja lahterdatud tööks tuginevad.

Konteinerite turvalisus on esmatähtis

Kuna üha rohkem ettevõtteid võtab konteinereid kasutusele ja juurutab, on nende turvalisus saamas ettevõtte peamiseks prioriteediks. Hiljutise uuringu kohaselt on 94% vastanutest oma konteinerikeskkonnas turvaintsidente kogenud. See rõhutab ainult seda, kui oluline on saada konteineri turvaõigused teie ettevõtte ja klientide kaitsmiseks.