Még mindig kevés figyelmet szentelnek a szervezetek az alkalmazásbiztonságnak (AppSec), miközben ma már egyértelműen kritikus a szerepe az adatvédelmi incidensek kivédésében. Mint azt összeállításunk előző részében bemutattuk, a vállalati felhasználók és a biztonsági megoldások gyártói is ugyanarra látják az „előrét”: a mesterséges intelligencia helyes alkalmazásában, a DevSecOps elvek érvényesítésében és az eszközkonvergenciában.

Mondani könnyű – csinálni nehéz

Minden elmélet annyit ér, amennyit a gyakorlat visszaigazol belőle. A jó biztonsági szakemberek talán ezért is egytől egyig megveszekedett popperiánusok, azaz folyamatosan megkérdőjelezik a biztonsági rendszerek és megközelítések megbízhatóságát (Karl Popper tudományfilozófus azt tartotta, hogy egyetlen ellentmondó megfigyelés is elég ahhoz, hogy alapjaiban cáfoljon egy elméletet.)

A vállalatok napi működésében azonban nem mindig érvényesül ez a megközelítés. A Gartner folyamatosan méri egy ún. SRM pontszámmal (IT Score for Security & Risk Management) a vállalatok biztonsági felkészültségét. A kutatócég kérdőívét 2020 és 2024 között közel 3400-an töltötték ki. A kitöltők 43 százaléka dolgozik olyan cégnél, amelynek biztonsági felkészültsége a legalacsonyabb érettségi szinten van: ad hoc módon, szervezetlen és dokumentálatlan folyamatok mentén reaktív biztonságot próbálnak megvalósítani. Ez még érdekesebb annak fényében, hogy az AppSec-érettség szintjének emelését szoftverfejlesztési vezetők közel kétharmada kulcsfontosságúnak tartja az üzletmenet-folytonosság biztosításához.

A megvalósítás azonban nehéz, ugyanis a modern üzleti alkalmazások sokfélék lehetnek. Egyszerre kell védeni szerveroldali rendereléssel előállított weboldalakat, mobil API-kat, konténerizált mikroszolgáltatásokat, JavaScript alkalmazásokat stb. És hogy még bonyolultabb legyen a képlet, az alkalmazások egy lényegében permanens CI/CD folyamatlánc részeként jelennek meg on-pemise, hibrid és/vagy többfelhős környezetekben.

Ilyen környezetben az alkalmazásbiztonság csak akkor teremthető meg, ha a teljes szoftver-életciklust lefedi a magas prioritású biztonsági szemlélet. De mi kell ehhez a gyakorlatban?

Biztonsággal turbózott szoftverfejlesztési életciklus

Könnyen belátható, hogy mivel a szoftvereket emberek készítik embereknek, technikai, folyamatbeli és szervezeti feltételei is vannak annak, hogy egy cég az AppSec-érettség magasabb szintjére lépjen.

Az alkalmazásfejlesztés folyamatát sztenderdizáló szoftverfejlesztési életciklus (SDLC, Software Development Life Cycle) szerves részlévé, sőt központi elemévé kell tenni a biztonságot. Számos sebezhetőség ugyanis arra vezethető vissza, hogy a tervezési, kódolási és tesztelési fázis végrehajtásából is hiányzik a biztonságtudatosság. A kiterjesztett modellben viszont a fejlesztés első lépéseitől jelen van a biztonsági és megfelelőségi követelmények azonosítása, valamint a fenyegetésmodellezés, azaz a lehetséges fenyegetések és sebezhetőségek feltárása. A kódolási folyamatban érvényesíteni kell a biztonságos fejlesztési gyakorlatokat (OWASP, NIST stb.), és be kell építeni a CI/CD folyamatba az automatizált statikus és dinamikus biztonsági tesztelést. A telepítés előtt átfogó kódellenőrzés és megfelelőségi audit kell végrehajtani, amit penetrációs teszteket követnek. És mivel tökéletes szoftver nincs, szükség lesz a folyamatos monitorozásra, a felfedezett sebezhetőségek javítására.

Számos jó gyakorlat van ezeknek a lépéseknek az integrálására az SDLC folyamatba. Letisztult például a fenyegetésmodellezés módszertana, amely akkor a leghatékonyabb, ha már a fejlesztés sikerül pontosan azonosítani, hogy adott alkalmazásnál milyen érzékeny adatokat és kritikus összetevőket kell védeni, és milyen fenyegetésekkel szemben. Ez segít rangsorolni biztonsági fenyegetéseket (valószínűség, hatás), és kidolgozni a kockázatcsökkentő stratégiákat.

A kódolási folyamatban pedig ki kell kényszeríteni a biztonságos kódolási irányelvek alkalmazását. Így megelőzhető például, hogy API-kulcsok, jelszavak vagy más bizalmas hitelesítő adatokat kerüljenek fixen a forráskódba.

Titkosítás és hitelesítés

A biztonság fontos pillére az erős titkosítást és a szigorú hozzáférés-engedélyezés. Titkosítani kell az inaktív adatokat tároláskor (pl. AES-256) és átvitelkor (pl. TLS 1.2) is. Célszerű végponttól végpontig terjedő titkosítást (E2EE) megvalósítani, és a titkosítási kulcsokat valamilyen biztonságos kulcskezelő rendszerbe zárni.

A titkosítást az árnyalt és erős hitelesítés és engedélyezés (autentikáció és autorizáció) teszi még biztonságosabbá. Garantálja, hogy minden adathoz csak az arra jogosult felhasználó férhessen hozzá. Ezért javasolják szakértők a többtényezős hitelesítést, az erős jelszavak kikényszerítését vagy szerepköralapú hozzáférés-vezérlést. De ugyancsak ide tartozik a rövid élettartamú munkamenet-tokenek vagy érzékeny műveleteknél az újrahitelesítés bevezetése.

Megkerülhetetlen kérdés az API-k (application programming interface) biztonsága. Ezek a modern alkalmazások fontos, ám kritikus elemei. API (a magyar terminológiában: alkalmazásprogramozási felület) biztosítja, hogy a különböző szolgáltatások és rendszerek kommunikálhassanak egymással (adatokat kérjenek, küldjenek és fogadjanak). Emiatt például elengedhetetlen az API-hitelesítés kikényszerítése (OAuth 2.0, API-kulcsok, JSON Web Token), a felhasználónkénti vagy IP-címenkénti API-kérések számának korlátozása vagy a titkosítás (HTTPS legalább TLS 1.2-vel).

Az API-tevékenységek monitorozásával és naplózásával kiszűrhetők a gyanús API-kérések, láthatóvá tehetők a sikertelen hitelesítési kísérletek és a potenciális visszaélések.

És az ember…

A fenti ökölszabályok többé-kevésbé évek óta érvényesek – és ismertek – az alkalmazásfejlesztésben. A DevSecOps sem új fogalom, ám a mesterséges intelligencia alaposan átértelmezte. Megjelent ugyanis a korábban low-code vagy no-code platformként emlegetett eszközök egy új szintje: a vibe kódolás.

Ez már valóban bárki számára elérhetővé – és ezáltal nehezen kontrollálhatóvá – tette az (üzleti)alkalmazás-fejlesztést, egyben még inkább igazzá tette a tételt, miszerint a biztonságban a leggyengébb láncszem az ember, azaz az ember nem tudása, figyelmetlensége, trehánysága. A Gartner a tavaly publikált Hype Cycle for Application Security, 2025 tanulmányában azt jósolta, hogy 2027-re AppSec kockázatok legalább 30 százalékát a vibe kódolás szüli.

Mivel innentől bárki alkalmazásfejlesztővé válhat, felértékelődött a biztonságtudatossági képzések szerepe. Az alkalmazásbiztonság javításához ugyanis elengedhetetlen a biztonságos kódolási gyakorlatokkal és a kiberbiztonsági fenyegetésekkel kapcsolatos képzések kiterjesztése. Ezeket minden alkalmazott számára rendszeressé kell tenni, aki bármilyen módon szoftverfejlesztési projekt közreműködője lehet. A vibe kódolással dolgozóknak is képben kell lenniük például a biztonságos kódolás, a fenyegetésmodellezés, a hitelesítés biztonság vagy az API-biztonság aktuális kihívásaival.

Szakértők szerint a security-first hozzáállás és az elméleti ismeretek elmélyítését célzó képzés mellett rendszeres gyakorlatokra is szükség van. A képzés leghatékonyabb módja, ha valós támadástípusok szimulációján keresztül ismerkedhetnek meg az érintett alkalmazottak a kockázatokkal.

Mindemellett azonban szigorú ellenőrzés alá kell a vállalati rendszerekhez kapcsolódó vibe kódolással létrehozott egyszerű alkalmazásokat.

Összeállításunk következő, záró részében azt vizsgáljuk meg, hogy mi a szerepe az informatikai vezetőnek a DevSecOps modell szerint működő informatikában.

Ez a cikk független szerkesztőségi tartalom, mely a Clico Hungary támogatásával készült. Részletek »