Az elavult szoftverek egyszerűen a rohanó technológiai életünk ténye. A technológiai csapatok tudják, hogy kezelniük kell a szoftver életciklusát. A csapatok azt is tudják, hogy mindenáron el kell kerülniük a már nem támogatott szoftverek futtatását.

Ennek ellenére a szervezetek néha forró vízbe kerülnek az elavult szoftverek miatt, és néha önhibájukon kívül.

Ebben a cikkben az életciklusuk végére érkező szoftverek kezelésének stratégiáit tárgyaljuk, különös tekintettel az operációs rendszerekre - bár tanácsaink bármely életciklusa végére érkező technológiára is érvényesek, legyen szó hardverről vagy szoftverről.

Mit jelent a támogatás vége?

A technológiai változásokkal való lépéstartás érdekében a legtöbb szoftvermegoldás néhány évente nagy frissítésen esik át. A felhasználóktól elvárják, hogy áttérjenek a szoftververziók újabb kiadásaira, de időre is szükségük van ahhoz, hogy ezt az áttérést végrehajtsák - különösen, ha olyan dolgokról van szó, mint például egy operációs rendszer.

Ezért van az, hogy egy újabb verzióval leváltott szoftverkiadás folyamatos támogatást élvez: ez időt biztosít a tesztelésre és a migrációra.

A szoftvergyártónak azonban egy bizonyos ponton be kell fejeznie a szoftver régebbi kiadásait. Nem reális például egy 30 éves operációs rendszer további támogatása.

Az ilyen típusú szoftvereket, amelyeket a gyártó már nem támogat és nem tart fenn többé, életciklusuk végével (EOL) jellemezzük. Ez azt jelenti, hogy a gyártó nem biztosít többé frissítéseket, hibajavításokat vagy technikai támogatást, és - a legtöbb esetben - kritikus biztonsági frissítések sem lesznek.

Ne számítson tehát a gyártó javítócsomagjára, ha egy életciklusának végét jelentő operációs rendszerben súlyos biztonsági hibát találnak. Ehelyett a gyártó arra számít, hogy az Önhöz hasonló felhasználók mostanra már áttértek az operációs rendszer egy támogatott verziójára.

Ennek következtében mindenki, aki a gyártó támogatása nélküli, elavult szoftverre támaszkodik, ki lesz téve a biztonsági réseknek, mivel nem lesz képes alkalmazni a gyártó által biztosított javítást az újonnan felfedezett sebezhetőségek elleni védelem érdekében.

Miért jelent egyáltalán problémát az EOL szoftver?

Az “életciklus vége” kifejezés mindent elmond, és a rendszergazdáknak nem is kell több motiváció, hogy frissítsenek egy operációs rendszer legújabb verziójára, mielőtt túl késő lenne. Emellett a gyakorlatban a technikai csapatoknak bőven van idejük értesülni, mivel a szoftvergyártók jóval előre közzéteszik a támogatási ütemterveket.

Mi az, ami elromlik? Miért van az, hogy az életciklus végi szoftvereket a kockázatok ellenére is olyan gyakran használják?

Ennek több oka is van. Az életciklus végi szoftverek megtévesztően stabilak, mert végül is még mindig minden működik. Miért dobnánk ki egy olyan megoldást, amely hibátlanul szolgálja a célját, csak néhány hamis biztonsági aggály miatt?

A szerver frissítése a következő generációs operációs rendszerre enyhén szólva is nehézkes, ezért sok rendszergazda halogatja a folyamatot. Néha egyszerűen csak túl kevés a személyzeti erőforrás az áttéréshez.

Aggodalomra ad okot a kockázat: csak azért, mert a jelenlegi verzió zökkenőmentesen fut, még nem jelenti azt, hogy a legújabb verzió is problémamentesen fog működni. Előfordulhat, hogy a jelenleg telepített szoftverek nem működnek az újabb verziókkal, és a konfigurációs változások kieséseket okozhatnak.

Mindazonáltal az operációs rendszer támogatott, javított kiadására való áttérés a technikai csapatok elsődleges feladata, és a legtöbb esetben ez időben megtörténhet és meg is kell történnie.

CentOS mint elrettentő példa

Azért mondtuk, hogy “a legtöbb esetben”, mert az EOL szoftverekkel való bajba kerülés nem feltétlenül a túlhajszolt vagy hanyag rendszergazdák hibája. Az elavult szoftverek futtatásának gyakorlati következményei mögött számos ok állhat, beleértve a gyártó döntéseit is.

Ez történt a CentOS-szal is. A CentOS egy széles körben használt Linux-disztribúció, amely a Red Hat Enterprise Linuxon (RHEL) alapul. A CentOS-t azért ünnepelték, mert az RHEL ingyenes, nyílt forráskódú alternatívája volt, amely jól illeszkedett az adatközpontok és más vállalati szintű alkalmazások számára.

2021 decemberében a Red Hat hirtelen bejelentette, hogy megszünteti a CentOS támogatását, ami egyes CentOS-disztribúciók számára életciklus végi sziklaszirtet jelentett.

A CentOS körüli hirtelen életciklus-vég bejelentése sok szervezetet stabil és megbízható operációs rendszer nélkül hagyott, mivel a gyártó támogatásának visszaszerzése azt jelentette, hogy jelentős összegeket kellett kiadni a RHEL-ért, vagy tesztelni és átállni egy olyan alternatívára, mint az AlmaLinux vagy a RockyLinux.

A végeredmény az, hogy a szervezetek jelentős része a CentOS 6 vagy CentOS 8 elavult gépeit futtatja, és nem kapnak gyártói támogatást. És ez tényleg számít, mert azok a szervezetek, amelyeknek rossz stratégiájuk volt az életciklus végét jelentő szoftverekkel kapcsolatban, nagyon nehéz helyzetbe kerültek.

Miért fontos: Biztonság

Oké, nézzük meg alaposabban, miért olyan nagy dolog egy életciklusának végét jelentő operációs rendszer futtatása. Az EOL operációs rendszer használatából eredő legnagyobb veszélyt messze a támogatás lejárta után felfedezett sebezhetőségek jelentik. Hogy miért? Mert a gyártó nem ad ki javítócsomagokat.

A Linux kernel 2.6.32 például már régóta nyugdíjazva van, de számos sebezhetőséget fedeztek fel azóta, hogy elérte az életciklusa végét, még 2019-ben is. A régebbi kernelen alapuló disztribúciókat futtató Linux-kiszolgálók sebezhetőek lennének a szolgáltatásmegtagadási támadásokkal szemben.

Egy EOL operációs rendszer telepítve hagyása azt jelenti, hogy nem kap több biztonsági javítást, így minden nyilvános sebezhetőségi bejelentés nyílt célponttá teszi a szerverét. A javítások hiánya azt jelenti, hogy a rendszergazdák nem tudják megvédeni az infrastruktúrát.

A támadás valószínűsége is nagyobb, mint gondolná: mivel sok szerver nyilvánosan elérhető, és mivel a támadók automatizált keresőeszközöket használnak, valós a veszélye annak, hogy a támadók előbb-utóbb rájönnek, hogy a szerverek sebezhetőek.

A támadók lényegében a nap 24 órájában ujjlenyomatot vesznek az Ön architektúrájáról, és lecsapnak egy nem támogatott, sebezhető operációs rendszerre. A következmények súlyosak lehetnek.

Miért fontos: Megfelelési kockázat

A pénzügyi és egészségügyi információkkal kapcsolatos szabályozási előírások olyan speciális kiberbiztonsági eljárásokat írnak elő, amelyek védik az ügyfelek adatait. A nem támogatott, nem javított szoftverek futtatása egyenesen ellentétes számos ilyen megfelelési szabvány előírásaival.

Ez magában foglalja a kritikus sebezhetőségek meghatározott időn belüli foltozását. De mi van akkor, ha nem tudja beszerezni a javítást? Hasonlóképpen, a megfelelőségi szabályozás előírja, hogy az érintett szervezetek nem használhatnak olyan szoftvert, amelyre nem vonatkozik a gyártó vagy harmadik fél által nyújtott támogatás.

A PCI DSS követelményei például a fizetési kártyaadatokat kezelő vállalatokra vonatkoznak, és tartalmazzák azt a konkrét követelményt, hogy a kritikus sebezhetőségeket 30 napon belül javítsák ki. Azok a szervezetek, amelyek nem tartják be ezt a határidőt, nem felelnek meg a PCI DSS-nek.

Az elavult szoftverek súlyos bírságokat és visszamaradó pereket eredményezhetnek, amelyek az adatszegés után még évekig eltarthatnak. Például a 2013-as Target-adatbetörés miatt indított 40 millió dolláros pert csak 2016-ban rendezték.

Miért fontos: A legjobb a többi közül

Ha a kiberbiztonsági és megfelelőségi aggályok az életciklusuk végét jelentő szoftverek futtatásával kapcsolatban nem elég riasztóak, akkor javasoljuk, hogy vegye figyelembe a következő okokat is:

• Nem kompatibilis szoftver: Ha egy operációs rendszer már nem támogatott, a harmadik féltől származó alkalmazások fejlesztői is megszüntetik a régebbi rendszer támogatását. Lehetséges, hogy a jelenlegi alkalmazások frissítései problémákat okozhatnak a régebbi operációs rendszerrel, vagy a szoftver egyszerűen már nem fog működni az EOL operációs rendszerrel.
• Gyenge teljesítmény: Nem ritka, hogy a régebbi szoftverek régebbi hardveren futnak. Ez azt jelenti, hogy a szűk keresztmetszetek a hálózat régebbi infrastruktúrájából adódhatnak. Ha elavult operációs rendszerre támaszkodik, akkor a legújabb operációs rendszerek teljesítményjavulását is elveszíti.
• Megbízhatóság: Mivel a régebbi alkalmazások már nem támogatottak, az összeomlások és a hibák sem kerülnek javításra. Ha a szoftver meghibásodik, a kiszolgálója potenciálisan már nem tud elindulni, ami hatással van az SLA-kra és az üzemidőre.
• Magas költségek: A gyártó által már nem támogatott szoftverek javítása és karbantartása érdekében történő folyamatos sebtapaszok alkalmazása gyorsan költségessé válik, és sosem tudhatja, hogy egy váratlan hiba mikor csapódik a zsebébe. Az EOL-szoftverek fejlesztői eszközönként felárat számítanak fel a támogatásért, ami egy nagy szervezet számára igen költséges lehet.

Tehát igen, úgy tűnhet, hogy az EOL operációs rendszerek jól működnek, de az igazság sokkal baljósabb, és jó eséllyel inkább előbb, mint utóbb falba ütközik. Kezdetnek elég annak megállapítása, hogy hol van kitéve az elavult szoftverek tekintetében.

Kezdje a status quo megállapításával

Ha még nem rendelkezik leltározási stratégiával, itt az ideje, hogy készítsen egyet. Nem csak a szoftverekről van szó; a hardverek is elérhetik azt a pontot, amikor ideje nyugdíjba vonulni. A leltárkezelés segít meghatározni, hogy milyen infrastruktúrát és szoftvert kell frissíteni, és melyik infrastruktúrát kell nyugdíjazni.

A leltározási folyamat rávilágít arra, hogy melyik szoftver érte el az élettartam végét, és lehetővé teszi az informatikai részlegek számára, hogy gyorsan és egyszerűen megállapítsák, hogy a gyártó mely szoftvereket nem támogatja már - ha van ilyen -, és hogy terveket készítsenek a frissítésre vagy a mielőbbi cserére.

A leltár alapján azonosítani fogja, hogy mely gépeken vagy csomópontokon fut olyan operációs rendszer, amely közel áll az élettartam végéhez - és ahol még bőven van ideje az EOL problémával foglalkozni. A leltározási folyamatnak azt is meg kell határoznia, hogy melyek az életciklusuk végén járó (vagy közel az életciklusuk végéhez álló) operációs rendszer példányai a legkritikusabbak, így rangsorolhatja a példányok eltávolításával, nyugdíjazásával vagy cseréjével kapcsolatos intézkedéseket.

A leltározási folyamat bevezetésével a szervezetek megtervezhetik az elavult szoftverek hatékony cseréjét vagy frissítését, csökkentve ezzel a váratlan leállások vagy biztonsági rések kockázatát.

Migráljon olyan gyorsan, amilyen gyorsan csak tud - ha tud

A szoftverek és az operációs rendszerek frissítése a legújabb verziókra gyorsan felgyorsulhat. Az áttérést a lehető leggyorsabban kell elvégezni, hogy elkerüljük a késedelmes frissítések láncreakcióját - és hogy elkerüljük a kapkodó áttérést, amely a végén tönkreteheti a dolgokat.

A tervezés ezért kritikus fontosságú. Alapos leltárral a kezükben és a gyártók EOL-menetrendjével együttműködve a technikai csapatoknak képesnek kell lenniük arra, hogy a migrációt úgy ütemezzék, hogy csökkentsék a nyomást, de a munkát időben elvégezzék.

A küldetéskritikus infrastruktúrát frissíteni kell, de az új operációs rendszert mindig először tesztelni kell. A termelés tükörképe egy átmeneti környezetben segíthet kiküszöbölni az előre nem látható problémákat a migráció során.

A visszavonás is egy lehetőség. Végül, ha nem frissít egy kiszolgálót, lehet, hogy itt az ideje nyugdíjazni. Alternatív megoldás lehet a nyugdíjazott berendezések felhőbe költöztetése és virtualizált környezetbe történő áttelepítése.

Utolsó mentsvár lehetőségek

Tehát igen, néha egyszerűen nem működik. Nem tud elég gyorsan áttérni, nem áll rendelkezésre kiterjesztett támogatás, vagy - valamilyen okból kifolyólag - a munkaterhelés egyszerűen megköveteli, hogy egy elavult operációs rendszert futtasson a jelenlegi állapotában, akár tetszik, akár nem.

Ha feltétlenül egy nem támogatott, nem javított és potenciálisan sebezhető operációs rendszert kell futtatnia, akkor elszigetelési és kockázatkezelési szempontból kell gondolkodnia:

• Hálózati elszigetelés: használjon külön hálózatot annak megakadályozására, hogy a nem támogatott operációs rendszert futtató rendszerek kapcsolatba lépjenek külső gépekkel. A hálózaton lévő más eszközökhöz és az internethez való hozzáférés blokkolásával a hálózati szegmentálás néha megvédheti az EOL-eszközöket a potenciális fenyegetésektől - bár ez nem egy légmentes megoldás, és a hatékonyságnak ára van.
• Virtualizálás az elszigetelés érdekében: Az elavult operációs rendszerek virtualizált környezetben történő elhelyezése javítja az ellenőrzést ezen eszközök felett - megkönnyíti az újbóli leképezést biztonsági incidens esetén, miközben korlátozza az EOL-rendszer külső környezetnek való kitettségét. A célzott eszközök gyorsan elszigetelhetők és újraindíthatók.
• Alkalmazás-ellenőrzés és fehérlista: az előző javaslatokhoz hasonlóan ez a stratégia elszigeteli a sebezhető operációs rendszert azáltal, hogy csak az ismert “jó” alkalmazások futtatását - és a vele való interakciót - teszi lehetővé. Ez a modell alapértelmezés szerint megtagadja a hozzáférést, és csak az előre jóváhagyott kapcsolatokat engedélyezi.

Mindazonáltal az, hogy egy nem támogatott operációs rendszer elkülönítésével próbáljuk megúszni a futtatást, kétségtelenül kockázatos stratégia - számtalan támadási vektor létezik, és megvan rá az esély, hogy egy ravasz támadó egy kis oldalirányú mozgással meghiúsíthatja az elszigetelési erőfeszítéseket.

Következtetés

Elegendő tervezéssel nem kell kétségbeesett intézkedésekre, például a nem támogatott operációs rendszereket futtató gépek elszigetelésére kényszerülni. Ideális esetben a csapatnak időben kell áttérnie, és mindig támogatott operációs rendszert kell futtatnia, amely a könnyen elérhető gyártói javításoknak köszönhetően biztonságban van.

De a technológiai élet útjába állhat - beleértve a gyártók elhamarkodott döntéseit is, ahogy azt a CentOS példával illusztráltuk.