Rendszer audit, szoftver audit, IT audit

Mikor van szükséged rendszer auditra?

A legtöbb rendszerrel addig nincs probléma, amíg nem kell hozzányúlni, skálázni vagy átadni valakinek. Ilyenkor derül ki, hogy kellett volna egy rendszer audit.

Tipikus helyzetek:

Beszállítóváltás előtt – nem tudod, milyen állapotban veszed át a rendszert. Az audit objektív kiindulási képet ad
Skálázás előtt – a rendszernek megnövelt terhelést kell kezelnie, és tudni akarod, elbírja-e a jelenlegi architektúra
Biztonsági aggály esetén – adatszivárgás, szabályozói elvárás vagy belső audit után tudni akarod, mennyire biztonságos a rendszered
Teljesítményproblémák esetén – a rendszer lassul, de nem világos, mi az oka
Technikai adósság felmérése – a fejlesztés egyre lassabb, a hibák egyre gyakoribbak, de nincs objektív mérce
Tech due diligence – befektető vagy felvásárló tudni akarja, mit ér a szoftver és mekkora a kockázat

Transzparens audit folyamat – tényalapú értékelés, erősségek és problémák dokumentálása

Az IT-audit tényalapú értékelés. A problémákat és az erősségeket egyaránt tartalmazza.

Ha a meglévő beszállítód jó munkát végzett, azt elismerjük és dokumentáljuk, mert az is fontos információ a döntéshez.

Az audit eredménye a tiéd
A megállapítások és javaslatok priorizált javaslatlista alapján te döntöd el, hogyan tovább: javítás a meglévő csapattal, javítás velünk, vagy vagy akár a rendszer újragondolása.

Kódminőség és szoftverarchitektúra audit vizualizáció

Kódminőség és architektúra vizsgálat

A kódminőség és az architektúra határozza meg, mennyire fejleszthető, karbantartható és skálázható a rendszered.

Kódminőség

Struktúra és olvashatóság – mennyire követi a kód az iparági konvenciókat, egy új fejlesztő mennyi idő alatt tud produktívan dolgozni a kódbázisban
Tesztelhetőség – milyen mértékű az automatizált tesztlefedettség, a tesztek valóban validálnak-e
Technikai adósság – mennyi a "majd megcsináljuk később" típusú megoldás, ami azóta sem lett megcsinálva
Kódismétlés – hol vannak a copy-paste megoldások, amelyek karbantartási kockázatot jelentenek

Architektúra

Modularitás – mennyire szétválasztottak a felelősségek, van-e clean separation of concerns
Skálázhatóság – képes-e a rendszer növekvő terhelést kezelni
Függőségi struktúra – vannak-e körkörös függőségek vagy túlzottan szoros csatolások
Architekturális minta értékelése – az alkalmazott minta illik-e a rendszer aktuális és tervezett méretéhez

Security audit és teljesítményvizsgálat vizualizáció

Biztonsági audit (security audit) és teljesítmény vizsgálat

A biztonság és a teljesítmény az üzleti működés része. Mindkettőt vizsgáljuk.

Biztonság

Ismert sérülékenységek – ellenőrizzük, hogy a használt könyvtárak és keretrendszerek tartalmaznak-e ismert CVE-ket
Autentikáció és authorizáció – átnézzük a felhasználókezelést, jogosultságkezelést, a session és token management robusztusságát
Adatvédelem – vizsgáljuk, hogyan tárolja a rendszer az érzékeny adatokat, megfelel-e a titkosítás és a GDPR elvárásainak
Szabályozói megfelelés – felmérjük, hogy a rendszer megfelel-e az iparági és jogszabályi elvárásoknak (compliance audit)
Input validáció – teszteljük, mennyire védett a rendszer SQL injection, XSS, CSRF és más támadási vektorok ellen

Teljesítmény

Terhelés alatti viselkedés – mérjük, hogyan reagál a rendszer megnövekedett terhelésre és hol vannak a szűk keresztmetszetek
Adatbázis-lekérdezések – feltárjuk a lassú query-ket, hiányzó indexeket és N+1 problémákat
Válaszidők – megmérjük, hogy a rendszer válaszidői megfelelnek-e az üzleti elvárásoknak
Erőforrás-használat – azonosítjuk a memóriaszivárgásokat és a felesleges erőforrás-foglalást

Infrastruktúra és függőségek

A szoftver környezete és a harmadik féltől származó komponensek ugyanakkora kockázatot hordoznak, mint maga a kód - ezért az audit ezeket is lefedi.

Infrastruktúra

Üzemeltetési környezet – átnézzük a szerver konfigurációt, az OS és middleware verziók naprakészségét
Monitoring – vizsgáljuk, van-e valós idejű állapotfigyelés, vagy az ügyfelek jelentik a hibákat
Backup és disaster recovery – ellenőrizzük, hogy létezik-e rendszeres, tesztelt backup, és mennyi idő alatt állítható helyre a rendszer
CI/CD és deployment – felmérjük, mennyire automatizált a deploy, mekkora kockázat egy új verzió kibocsátása, van-e rollback

Függőségek

Third-party könyvtárak – azonosítjuk az elavult, deprecated vagy end-of-life verziókat
Licencelési kockázatok – ellenőrizzük, hogy az open-source és kereskedelmi komponensek licencelése kompatibilis-e az üzleti modellel
Frissítési stratégia – felmérjük, van-e rendszeres dependency update és mekkora az elmaradás

A fejlesztési folyamatok auditja

A rendszer állapota a fejlesztési folyamatoktól függ. Ha a folyamatok nem tartanak lépést a kódbázissal, a technikai adósság észrevétlenül halmozódik.

Amit vizsgálunk:

Branching stratégia és verziókezelés – milyen git workflow-t használ a csapat, mennyire átlátható a fejlesztési folyamat
Code review gyakorlat – van-e szisztematikus code review, milyen kritériumok alapján fogadnak el egy pull requestet
Tesztelési kultúra – vizsgáljuk, hogy a tesztelés szerves része-e a fejlesztésnek, vagy utólagos, formális lépés
Dokumentáció – van-e naprakész technikai dokumentáció, értik-e az új csapattagok a rendszert
Incident management – hogyan kezelik a production hibákat, van-e post-mortem kultúra, tanulnak-e a hibákból

Audit eredmény – priorizált megállapítások, kockázati szintek, javaslatok

Az audit eredménye: priorizált értékelés

Minden megállapítás mellé konkrét javaslatot adunk, priorizálva.

Minden megállapításhoz tartozik:

Leírás – mi a probléma, pontosan és egyértelműen
Kockázati szint – Kritikus / Magas / Közepes / Alacsony, az üzleti hatás alapján
Üzleti hatás – milyen következménye van, ha nem kezelik, mit jelent pénzben, időben, kockázatban
Javasolt megoldás – konkrét, megvalósítható lépés
Becsült ráfordítás – mekkora erőforrás szükséges a javításhoz
Prioritás – mit kell azonnal javítani, mit ütemezetten, és mi az elfogadható kockázat

Audit munkamódszer – senior fejlesztők, csapatbevonás, dokumentált folyamat

Hogyan dolgozunk az audit során

Az IT-auditot olyan senior fejlesztők és architektek végzik, akik napi szinten dolgoznak hasonló rendszerekkel.

Együttműködés
Bevonunk mindenkit, aki releváns információval rendelkezik: fejlesztőcsapat, üzemeltetők, termékfelelős. Az interjúk során a rendszerben keressük a problémákat, nem az emberekben.

Dokumentáltság
Az audit teljes folyamata dokumentált. Bármikor látod, hol tartunk, mit vizsgáltunk, és milyen módszertant alkalmazunk.

Gyakran ismételt kérdések a rendszer auditról

⚖️ Mennyibe kerül egy IT audit vagy rendszer audit?
A költség a rendszer méretétől, komplexitásától és a vizsgálandó területek számától függ. Egy fókuszált audit (pl. kódminőség és architektúra) néhány hét alatt elkészülhet. Egy átfogó audit, amely a kódot, a biztonságot, a teljesítményt, az infrastruktúrát és a folyamatokat is lefedi, 1–2 hónapot vehet igénybe. A bevezető megbeszélés után indikatív ajánlatot adunk.

⚙️ Az audit során hozzáfértek a forráskódhoz?
Igen, a kódminőség és architektúra vizsgálatához forráskód-hozzáférés szükséges. NDA-t kötünk, és a hozzáférést a vizsgálat időtartamára korlátozzuk. Ha a forráskód nem elérhető (pl. vendor termék esetén), az auditot a hozzáférhető elemekre (infrastruktúra, konfiguráció, folyamatok, teljesítmény) fókuszáljuk.

▶️ Az audit eredménye alapján kötelező a LogiNettel javíttatni?
Nem. Az audit eredménye a tiéd, a javítást bármely csapattal elvégezheted. Ha a meglévő fejlesztőcsapatod alkalmas a feltárt problémák kezelésére, az audit felhasználható a backlog prioritizálásához. Ha velünk javíttatsz, az audit alapján pontos scope-pal és becsléssel tudunk ajánlatot adni.

❓ Ha a meglévő beszállítóm jó munkát végzett, az kiderül az auditból?
Igen. Az audit tényalapú: ami jól van megcsinálva, azt elismerjük és dokumentáljuk.

⚔️ Mi a különbség a rendszer audit és a penetrációs teszt között?
A penetrációs teszt a biztonsági sérülékenységeket vizsgálja, jellemzően a rendszer kívülről elérhető felületein. A rendszer audit ennél szélesebb: a kódminőséget, az architektúrát, a teljesítményt, az infrastruktúrát, a függőségeket és a fejlesztési folyamatokat is vizsgálja. A biztonsági audit a rendszer audit egyik komponense.

⚡ Mennyi ideig tart egy IT-audit?
Egy fókuszált IT-audit 2–4 hét, egy átfogó audit 1–2 hónap. Az időtartamot a rendszer mérete, a vizsgálandó területek száma és a hozzáférések biztosításának sebessége befolyásolja.

♾️ Mi az a tech due diligence?
Technológiai átvilágítás felvásárlás vagy befektetés előtt. A befektető tudni akarja, mit ér a szoftver, milyen kockázatokat hordoz, mekkora a technikai adósság, és mennyire fenntartható a rendszer a jelenlegi formájában. A rendszer audit eredménye felhasználható tech due diligence céljára.

➕ Az auditnak van hatása a production rendszerre?
Az audit nem avatkozik be a production rendszerbe. A forráskódot, a konfigurációt és a dokumentációt vizsgáljuk, a teljesítményteszteket tesztkörnyezetben végezzük. Ha production környezetben szükséges mérés, azt előre egyeztetjük és minimális hatással végezzük.