Ne így kerülj címlapra!

2019-ben már senkit nem kell meggyőzni arról, hogy tegyen a hálózata elé tűzfalat. Olyat sem látni a XXI. században, hogy a vállalati levelezőszerveren ne szűrnék a vírusokat. Ahogy az is evidens, hogy a cégnél nem mindenki rendelkezik rendszergazda jogokkal. És mi a helyzet a konténertechnológiában?

A felhasználói igények kiszolgálása szempontjából az elmúlt két évtized számos változást hozott. Először a virtualizációval, amely a 2000-es évek közepén indult meg: ekkortól könnyebb lett magas rendelkezésre állású klasztereket építeni virtuális gépekből, azok pedig a korábbinál rugalmasabban tudtak megfelelni a felhasználói igényeknek. Könnyebbé vált az automatizáció is. A korábban költséges és bonyolult szolgáltatások olcsóbbak és egyszerűbbek is lettek, a rendszer üzemeltetése pedig nem igényelt a korábbihoz hasonló mértékű emberi erőforrást sem.

Ezt követte aztán a konténertechnológia elterjedése, amelynek révén még rugalmasabb, még gyorsabb változásokat tud lekövetni a kapcsolódó infrastruktúra, még kisebb mértékű emberi beavatkozás mellett. A konténerek 2013 körül indultak hódító útjukra, mára pedig a csapból is ez folyik. A népszerűség egy idő után magával hozta az IT biztonsági kérdéseket. Erre néhány, nagy visszhangot kiváltó botrány is ráirányította a figyelmet. A rózsaszín köd eloszlott, a szakemberek ezúttal is felismerték: sztenderdeket kell alkotni annak érdekében, hogy ez az egyébként méltán elterjedt megoldás amennyire lehet, biztonságos legyen.

‍

Image

‍

Mielőtt rátérnénk a botrányokra, érdemes megismerkedni az image fogalmával. Az image leegyszerűsítve egy file, ami a konténerek lelke. Amikor egy konténert elindítunk, ezt az image-et kezdjük el futtatni. Image-ek már a virtuális gépek esetében is léteztek, de azok még egy teljes operációs rendszert tartalmaztak. Ami újdonság, hogy a konténertechnológiában használt image jóval kisebb: csak a futásához szükséges függvény-könyvtárakat, és alapvetően egyetlen alkalmazást tartalmaz. Minden konténernek egyetlen, jól meghatározott feladata van a rendszerünkben.

És most lássuk a biztonsági aspektusok előtérbe kerülését kiváltó botrányokat!

‍

Címlapsztorik

‍

Az első példa a klasszikus üzemeltetés világából való, ami automatizálással (és konténerek alkalmazásával) nagy valószínűséggel elkerülhető lett volna. 2017-ben történt, hogy az amerikai Equifax hitelbíráló cég rendszerébe történt behatolás következtében közel 150 millió ügyfél személyes adatait lopták el. A botrányt súlyosbítja a tény, hogy a betörést a helyi üzemeltetők több mint két hónapig nem vették észre, mivel a hálózatukat ellenőrző megoldás már hónapok óta nem működött megfelelően. Az automata frissítés sem volt bekapcsolva, a hibát emberi mulasztás okozta.

A Docker Hub publikus image tárolóval történt eset viszont már konténertechnológia a javából. E felületen bárki tárolhatja, és megoszthatja a saját maga által készített image-ket. 2017 májusában azonban valaki fertőzött tartalmat töltött fel rá. Egy évnek kellett eltelnie, amíg az üzemeltető vállalat a biztonságtechnikai cégek figyelmeztetéseinek hatására eltávolította a fertőzött tartalmakat. Mint kiderült, az időszak alatt 90 ezer dollárnyi kriptovalutát bányásztak ki a gyanútlan felhasználók. Minthogy a Hub szolgáltatása ingyenes, azt sokan szívesen használják, ennél fogva a letöltések száma milliós nagyságrendű lett. Közben pedig nem vették észre, hogy a konténer amellett, hogy hasznos alkalmazást tartalmaz, mást is csinál: a processzor és a memória egy részét arra használja fel, hogy valaki másnak kriptovalutát bányászik. Az illetőt, aki nagyjából öt perc alatt alkothatta meg az image-et, sosem kapták el, a kriptovaluták világa már csak ilyen.

2019 februárjában látott napvilágot egy sebezhetőség a runC alacsony szintű futtató környezetben. Mivel a runC-re épül az összes elterjedt konténeres megoldás, ez a sebezhetőség gyakorlatilag a világ összes számítógépét érintette, amin futtatnak konténereket.

A hiba kihasználásával rendszergazdai jogok szerezhetőek a hoszt gépeken, ezzel teljesen kiszolgáltatja azt a támadóknak. A problémát maguk a runC készítői fedezték fel, és a bejelentéssel együtt kiadtak egy javítást is, amely megszünteti a rést. A kérdés csak az, hányan telepítik a frissítést, és kik azok, akik még mindig a régi verziót használják.

‍

Nincs elavult eszköz

‍

S hogy miképpen lehet elkerülni hasonló eseteket? Ez nem bonyolult, nem is költséges, de odafigyelést és tudatosságot igényel. Léteznek ugyanis szervezetek, amelyek ingyenesen közzétesznek leírásokat a biztonsági ajánlásokkal kapcsolatban, hogy miképpen érdemes rendszereket bebiztosítani.

Hasonló megoldás régebben is létezett már – operációs rendszerekre, szerveralkalmazásokra –, de immár konténertechnológiára is elérhetőek. Ezeket a segédanyagokat persze nem elég letölteni, fel is kell dolgozni azokat. Ebben automata eszközök is segítségünkre lehetnek. A teljes megoldás természetesen hozzáértő szakember közreműködését igényli, aki lehet külső szakértő vagy belső üzemeltető is.

Fontos figyelembe venni, hogy a biztonságtechnológiában nincs elavult eszköz. A “régi” és új megoldásokat együtt kell alkalmazni! Ha elhanyagoljuk a korábbi védelmet, és például a belső hálózatunk hozzáférhetővé válik, akkor onnan fog a támadás érkezni. Minden, ami eddig biztonságtechnikai szempontból fontos volt, az ezután sem nélkülözhető, de az új elemekhez új eszközökre van szükség.

‍

Sebezhetőségvizsgálat

‍

A sérülékenységekről elérhetőek nyilvánosan hozzáférhető adatbázisok is. Itt gyűjtik össze a bejelentések alapján a sebezhetőségeket. A korábban említett runC leírása például megtekinthető itt: https://nvd.nist.gov/vuln/detail/CVE-2019-5736

Ezeket a gyűjteményeket fel tudjuk használni, így a konténer image összerakása közben automatán ellenőrizhetjük a tartalmat (a pipeline részeként) statikusan, még mielőtt az image-eket a végfelhasználók kézhez kapnák.

Azonban ezzel a módszerrel még nem tudunk kiszűrni minden hibaforrást. Ezért a már futó konténert is fontos szemmel tartanunk.

Ezekre a műveletekre szintén léteznek nyílt forrású, ingyenes és persze fizetős monitorozó eszközök is.

A vállalatoknak maguknak kell házirendet felállítaniuk arra vonatkozóan, hogy amennyiben hibát, sérülést találnak a rendszerükben, az milyen hatással legyen az infrastruktúrára. Csak riasszon – emailt vagy SMS-t küldjön –, vagy durva hiba esetén akár be is avatkozzon biztonsági szoftver, elzárva például a hibás entitást a hálózat többi részétől.

‍

Kockázatok

‍

Amint láttuk, a konténertechnológia sem mentes a biztonsági kockázatoktól, mégis számtalan előnye van: költséghatékonyság, rugalmasság, nagyfokú automatizálhatóság. Aki még nem szállt fel a vonatra, az lemarad, és végül kiesik a játékból. A biztonságról azonban soha nem szabad megfeledkezni!

Ami cégünket illeti, mi csak megbízható komponensekből építkezünk, így amikor létrehozunk egy infrastruktúrát, akkor azt a lehető legbiztonságosabbra készítjük el. Aki tőlünk kér konténertechnológia szolgáltatást, az számíthat arra, hogy azt „bebiztosítva” kapja kézhez.

Nap mint nap derülnek ki azonban új sérülékenységek. Bár minimális humán erőforrás szükséges csak ahhoz, hogy egy automatizált rendszert karban tartsunk, mindig vannak emberi közreműködést igénylő döntések. Ezért érdemes a támogatásra és karbantartásra is gondolni.

‍

Mint a légzsák

‍

A fent említett megoldásoknak nem magas az addicionális költségigénye – nagy kiadásokkal inkább akkor kell számolni, ha a rendszer nincs biztosítva, és megtörténik a legrosszabb. Olyan ez, mint a légzsák az autóban: lehet anélkül is kérni a kocsit, mondván, hogy jól vezetünk, de ha netán mégis belénk jön egy kamion, összetörik a jármű is, és mi is.

Érdemes ennek elejét venni.