Kontteja on kaikkialla: kuinka suojaat ne?

Konttien määrä kasvaa päivä päivältä ja näyttää olevan kaikkialla, kun organisaatiot haluavat hyötyä niiden tarjoamista monista eduista, kuten ketterästä sovellusten kehittämisestä ja käyttöönotosta kaikilla alustoilla.

Monet uskovat myös, että konttien käyttö voi auttaa heitä minimoimaan turvarajoituksia niiden lyhyen käyttöiän vuoksi. Onko tämä totta vai vain yksi väärinkäsitys?

Vaikka konteissa ei ole luontaisia ​​epävarmuustekijöitä, niitä käytetään usein epäturvallisella tavalla, mikä johtaa lukuisiin tietoturvahaasteisiin.

Tietoturvahaasteita säiliöitä otettaessa

Käytettyjen konttien valtava määrä, monipuolisuus ja lyhytaikainen tila sekä se, että konttien on kommunikoitava muiden yksiköiden kanssa, johtavat siihen, että organisaatioilla ei ole kykyä omistaa riittävää konttien välistä liikenteen näkyvyyttä.

Näkyvyyden puutteen ansiosta kontit usein unohdetaan, ja tunkeutumisen ehkäisytoimenpiteet ja turvatarkastukset tulevat tehottomiksi, mikä lisää hyökkäyspinta-alaa ja siten koko liiketoimintariskiä. Lisäksi näkyvyyden puute voi johtaa vastuullisuuden niukkuuteen, kun kontit kulkevat eri ympäristöissä kehitysvaiheesta tuotantoon.

Toinen kontteihin liittyvä turvallisuushaaste on heikko haavoittuvuuksien hallinta. Esimerkiksi kloonattaessa olemassa olevia kuvia uusien säiliöiden luomiseksi, myös niiden haavoittuvuudet replikoituvat.

Tämä korostaa tarvetta turvallisuuden olla olennainen osa organisaation konttistrategiaa. Muuten määritysvirheet ja puuttuvat korjaustiedostot voivat olla syynä luvattomien kuvien käyttöönotolle ja suorittamiselle tuotantoympäristöissä, mikä lisää hyökkäyspinta-alaa ja onnistuneempia hyökkäyksiä.

Lopuksi, koska säilöissä käytetään jaettua käyttöjärjestelmäydintä, isäntäkäyttöjärjestelmän ytimen vaarantaminen väärän säilön toimesta voi johtaa pääsyn menettämiseen kaikkiin tai kaikkiin isäntäkoneen käynnissä oleviin säilöihin samoin kuin mahdollisesti muihin verkon isänteihin.

Kuinka kiinnität säiliösi

Ehkä paras käytäntö konttiympäristösi turvaamiseksi on sen välttämättömyyden tunnustaminen. Tätä peruskonseptia lukuun ottamatta on joitain hyviä neuvoja noudatettava konttisi tehokkaaseen suojaamiseen.

Näkyvyys kontteihisi

Ennen kuin otat kontin käyttöön, varmista, että ymmärrät sen riippuvuudet ja sen sisällön. Varmistaaksesi, että konttikuvasi ovat koskemattomia, sinun on saatava näkyvyyttä jokaisessa vaiheessa kehityksestä tuotantoon.

Säilön ohjelmistoon luottaminen on hyvä lähtökohta. Sinun on tarkistettava se erittäin perusteellisesti ymmärtääksesi "mistä ne ovat peräisin, kuinka ne on tuotettu ja niitä vastaavat lähteet", kuten Dirk Hohndel, VMwaren varapuheenjohtaja, huomautti vuoden 2019 Open Source Leadership Summitissa.

Lyhyesti sanottuna, tarkista säiliöiden sisältö ennen niiden käyttöönottoa äläkä koskaan käytä säilöä tuntemattomilla tai vanhentuneilla ohjelmistoilla. Se, että säilön kuva väittää sisältävän uusimmat ja parhaat ohjelmat ja kirjastot, ei tarkoita, että se todella sisältää.

Yksi tapa lieventää tätä ongelmaa on käyttää sovelluksia, jotka voivat auttaa sinua siivoamaan säiliösi. Vaikka en pidäkään pyörän keksimisestä uudelleen, ehkä paras tapa on lopettaa muiden ihmisten konttikuvien käyttö.

Jos sinä, aivan kuten Hercules, valitset hyveen vaikeamman tien ja alat rakentaa omia konttikuviasi, ymmärrät paljon paremmin, mitä konteissa tapahtuu, mistä on etuja turvallisuuden lisäksi.

Hallitse pääkäyttäjän oikeuksia

Useimmat säilöistä on oletuksena rakennettu pääkäyttäjän oikeuksin. Tämä on kuitenkin kyseenalainen käytäntö. Vaikka kehittäjien on helpompi käyttää säiliöitä pääkäyttäjänä, pääkäyttäjän oikeuksiin liittyy valtavia riskejä.

Tämän ongelman ratkaisemiseksi on useita lähestymistapoja. Yksi tapa on varmistaa yrityksen käytäntö, että yksikään säilö ei saa koskaan toimia pääkäyttäjänä. Vaihtoehtoinen tapa on käyttää vähiten etuoikeusperiaatetta. Voit määrittää Docker-tiedostossa ei-root-käyttäjän, kun luot säilön kuvan, suorittamaan säilöä kyseisenä käyttäjänä, jolla on vähimmäisvaatimukset järjestelmälle.

Lopuksi voit myös käyttää käyttäjän nimiavaruutta ajaessasi etuoikeutettuja säilöprosesseja suojattujen säilöjen auttamiseksi. Tällä menetelmällä näiden prosessien suorittamisen UID säilön sisällä on nolla (joka on juuri), mutta säilön ulkopuolella UID on etuoikeutettu 1000.

Tarkista säilön käyttöaika

National Institute of Standards and Technologyn (NIST) SP 800-190 " Application Container Security Guide " huomauttaa, että myös kontin ajonajat ovat alttiina hyökkäyksille. Vaikka tämä ei ole yleinen tietoturvavaje, NIST huomauttaa, että kontin ajonaikaiset tietoturvahaavoittuvuudet voivat olla " erityisen vaarallisia ", jos ne sallivat skenaariot, joissa haittaohjelmat voivat hyökätä muiden säiliöiden resursseihin ja itse isäntäkäyttöjärjestelmään.

Hyökkääjä voi myös pystyä hyödyntämään haavoittuvuuksia vaarantaakseen itse ajonaikaisen ohjelmiston ja sitten muuttaa ohjelmistoa siten, että se antaa hyökkääjälle pääsyn muihin säilöihin, valvoa säiliöiden välistä viestintää jne.

Suojausongelmat ovat paljon yleisempiä ajonaikaisissa kokoonpanoissa. Säilön suoritusajat tarjoavat yleensä monia määritettäviä vaihtoehtoja. Niiden väärä asetus voi heikentää järjestelmän suhteellista turvallisuutta.

Esimerkiksi Linux-säilöisännissä sallittujen järjestelmäkutsujen joukko rajoitetaan usein oletusarvoisesti vain niihin, joita tarvitaan säiliöiden turvalliseen käyttöön. Jos tätä luetteloa laajennetaan, se voi altistaa säilöt ja isäntäkäyttöjärjestelmän vaarantuneen säilön aiheuttamalle riskille.

Vastaavasti, jos säilöä ajetaan etuoikeutetussa tilassa, sillä on pääsy kaikkiin isäntäkoneen laitteisiin, jolloin se voi olennaisesti toimia osana isäntäkäyttöjärjestelmää ja vaikuttaa kaikkiin muihin siinä käynnissä oleviin säilöihin.

Toinen esimerkki turvattomasta ajonaikaisesta määrityksestä on se, että säiliöiden sallitaan liittää arkaluontoisia hakemistoja isäntään. Jos vaarantunut säilö voi tehdä muutoksia näihin polkuihin, sitä voidaan käyttää oikeuksien nostamiseen ja hyökätäkseen itse isäntään sekä muihin koneessa pyöriviin säilöihin.

Koveta käyttöjärjestelmä

NIST suosittelee myös konttikohtaisen käyttöjärjestelmän käyttämistä, koska uhat ovat yleensä vähäisempiä, koska käyttöjärjestelmät on suunniteltu erityisesti isännöimään säilöjä ja muut palvelut ja toiminnot on poistettu käytöstä.

Lisäksi, koska nämä optimoidut käyttöjärjestelmät on suunniteltu erityisesti säilöjen isännöintiin, niissä on tyypillisesti vain luku -tiedostojärjestelmät ja oletusarvoisesti muita kovetuskäytäntöjä. Aina kun mahdollista, organisaatioiden tulisi käyttää näitä minimalistisia käyttöjärjestelmiä vähentääkseen hyökkäyspintojaan ja lieventääkseen yleiskäyttöisiin käyttöjärjestelmiin liittyviä tyypillisiä riskejä ja kovettuvia toimia.

Organisaatioiden, jotka eivät voi käyttää säilökohtaista käyttöjärjestelmää, tulee noudattaa NIST SP 800-123:n, Guide to General Server Security -oppaan ohjeita, jotta he voivat vähentää isäntiensä hyökkäyspintaa mahdollisimman paljon.

Esimerkiksi säilöjä suorittavien isäntien tulee suorittaa vain säilöjä, eivätkä muita sovelluksia, kuten verkkopalvelinta tai tietokantaa, säilöjen ulkopuolella. Isäntäkäyttöjärjestelmä ei saa käyttää tarpeettomia järjestelmäpalveluita, kuten taustatulostusta, joka lisää sen hyökkäyspintaa.

Lopuksi isäntiä tulee jatkuvasti tarkistaa haavoittuvuuksien varalta, ja päivitykset on asennettava nopeasti, ei vain säilön ajon aikana, vaan myös alemman tason komponentteihin, kuten ytimeen, johon säiliöt luottavat turvallisessa, lokeroidussa toiminnassaan.

Konttien turvallisuus on ykkösprioriteetti

Yhä useammat yritykset ottavat käyttöön ja ottavat käyttöön kontteja, joten niiden turvallisuudesta on tulossa liiketoiminnan tärkein prioriteetti. Tuoreen tutkimuksen mukaan 94 % vastaajista on kokenut turvallisuushäiriön konttiympäristössään. Tämä vain korostaa, kuinka tärkeää on hankkia kontin suojausoikeudet yrityksesi ja asiakkaidesi suojaamiseksi.