Az üzleti igények és külső kényszerítő erők katalizátorként hatottak az alkalmazásfejlesztésre, egyre nagyobb sebességre kényszerítve a vállalatokat. A DevOps szemlélettel, az agilitás bevezetésével az üzleti igények kielégítésre kerültek, azonban ennek sok esetben a biztonság látta kárát. Mit tehetünk annak érdekében, hogy a biztonság alappillére legyen az üzleti elvárásoknak, ne pedig utólagos feladat, amely jellemzően jelentős többletkiadásokra kényszeríti a vállalatokat? A DevSecOps szemlélet megoldást jelent?

DevOps és DevSecOps

A 2009-ben indult DevSecOps szemlélet az új technológiák térhódításával válik egyre népszerűbbé, lássuk, hogy miről van szó pontosan.

A hagyományos DevOps megközelítésben a biztonsági tesztelés a fejlesztési folyamat vége felé történik – jellemzően akkor, amikor az alkalmazást már telepítették a termelési környezetbe. Ennek oka, hogy a biztonsággal kapcsolatos feladatok, például a biztonságos konfigurációkezelés és a sebezhetőségi vizsgálat meglehetősen időigényes lehet, ami lelassítja a fejlesztési folyamatot.

A DevSecOps szemlélet ezzel szemben a biztonsági tudatosság folyamatos integrálásának gyakorlata a szoftver, vagy alkalmazásfejlesztés teljes életciklusa során.

Annyit tesz, mindenki felelőssé válik a biztonságért, hogy a fejlesztési és üzemeltetési döntéseket azonos mértékben és sebességgel hajthassuk végre.

A megfeleltetés költségei csökkennek, a szoftverek pedig hamarabb szállíthatóak, a fokozott automatizálás és a teljes szoftvertovábbítási pipeline kiküszöböli a hibákat, csökkenti a támadásokat és az állásidőt

Új kockázati környezet

A felhőtechnológia, valamint a konténerek és mikroszolgáltatások térhódítása alapvetően megváltoztatta a szoftverfejlesztés módját, megkövetelve a szervezetektől, hogy újraértékeljék biztonsági irányelveiket, gyakorlataikat és eszközeiket.

A DevOps-kultúrában az alkalmazásprogramozási interfész (API) és konfigurációs eszközökre van szükség az infrastruktúra kódként való lebontásához, amelyet aztán a fejlesztőcsapat adaptálhat és átdolgozhat. Ez lehetővé teszi a fejlesztők számára, hogy külön infrastrukturális csapat bevonása nélkül biztosítsák és skálázzák a szükséges infrastruktúrát.

Ugyanakkor a szerver nélküli funkciók, mikroszolgáltatások és konténerek fejlesztők általi elterjedése új biztonsági kockázatokat hozott, amelyekkel számolni kell. Az IT-nek meg kell felelnie annak a kihívásnak, hogy konzisztens biztonságot tartson fenn az adatközpontjában és a nyilvános felhőkörnyezetben, ahol az alkalmazásokat telepítik.

Szembe kell nézni a jól kidolgozott eszközök hiányával is, amik a konténerek, az API sebezhetőségek és egyéb problémák megoldására szolgálnak.

A virtuális gép (VM) alapú felhőalapú telepítésekben a biztonsági eszközök és a legjobb gyakorlatok kiforrottabbak, és teljesebb körű felismerést és átláthatóságot biztosítanak a fenyegetések és a teljesítményproblémák tekintetében. Ugyanez nem mondható el a mikroszolgáltatásokat és konténereket kihasználó cloud native környezetekről. Röviden, a fenyegetési modell megváltozott.

Best practice a DevSecOps csapat felkészítésénél

Az új szemlélet szerint a legjobb, ha a biztonsági tesztelést a fejlesztőcsapat végzi el, illetve lehetővé kell tenni számukra a tesztelés során feltárt problémák kezelését és megoldását.

Lehetőség szerint automatizáljunk! A DevOps a gyorsaságról szól, és ezt nem kell, hogy változzon az új szemléletmód miatt. A fejlesztési ciklus korai szakaszában automatizált biztonsági ellenőrzéseket és tesztek lehetővé teszik az alkalmazás gyors átadását.

Bátran használjunk speciális alkalmazásokat! Számos open source megoldás lehet segítségünkre (például CyberArk Conjur) már a kódírás közben is, ezek képesek átvizsgálni és megtalálni bizonyos biztonsági problémákat.

Végezzünk kockázati modellezést! Ezzel megmutatható eszközeink sebezhetősége (Forcepoint dinamikus adatvédelem).

A legpraktikusabb, ha a DevOps csapaton belül kijelölünk egy dedikált információbiztonsági vezetőt. Rendelkezzen szakértelemmel. Olyan jelölt legyen, aki az alkalmazásbiztonság terén a csapat többségénél magasabb szintű képzést végzett ezen a területen. Ő felülvizsgálhatja a biztonsági javításokat és segíthet meghatározni és kidolgozni az alkalmazáshoz szükséges biztonsági ellenőrzéseket.

Az IT terület változékonysága elengedhetetlenné teszik, hogy az IT csapatot időről időre képezzük tovább. A biztonsági szemlélet korábban nem tartozott a DevOps-mérnökök vagy szoftverfejlesztők alapvető feladatai. Így itt a lehetőség, hogy tantervet vagy képzési programot dolgozzunk ki, hogy az IT-csapatukat felkészítsük a DevSecOps alapelveire.

Ha egy lépést teszünk hátrafelé, a vállalat szabályozási környezetét is meg kell vizsgálnunk.

Fontos, hogy végezzünk kockázat/haszon elemzést a szervezet jelenlegi kockázattűrő képességének meghatározásához.

Legyen átfogó, beépített biztonsági stratégiánk, amely a biztonsági környezet meglévő sebezhetőségeit és ismert fenyegetéseit kezeli.

Így az informatikai folyamat minden egyes fázisába beépül a biztonsági szemlélet. Ezáltal

• minimalizálhatóak a sebezhetőségek és
• biztosított a megfelelőség
• a kiadási ciklusok sebességét nem befolyásoljuk.