IT audit - amikor nagyító alá kerül a kód (2. rész)

Szoftverrendszerek üzemeltetésének és fejlesztésének átadás-átvételekor, illetve cégek felvásárlásakor gyakran merül fel az IT-rendszerek átvilágításának fogalma. Mit is jelent ez pontosan? Miért érdemes ezt elvégezni? És egyáltalán, hogyan kell elképzelni egy ilyen audit folyamatot? Kétrészes összeállításunkban 9 témakört mutatunk be, amelyet érdemes megvizsgálni egy audit során. Az első részben 4 témakört érintettünk, a második részben a további 5-öt ismertetjük részletesen. Szó esik az üzemeltetési kérdésekről, a biztonsági szempontok feltérképezéséről, a jogi megfelelésről, AI toolok használatáról.

5. Üzemeltetési kérdések

Egy szoftver hatékony üzemeltetésének alapja a megfelelő infrastruktúra, a fejlesztési workflow és annak szoftveres támogatása. A jelenlegi körülmények felmérése az átvilágítás (audit) egyik fontos része lehet.

Infrastruktúra vizsgálata

Fizikai vagy virtualizált környezet

Első lépésként nem mindegy, hogy a rendszer jelenleg fizikai szervereken, virtualizált környezetben (VM-eken), felhőszolgáltatónál, vagy konténerizált megoldáson fut. Ez az üzemeltetés és az esetleges költöztetés szempontjából is kiemelkedően fontos kérdés.

Erőforrásigény és kihasználtság

Érdemes megvizsgálni a rendszer erőforrásigényét (CPU, GPU, memória, tárhely, sávszélesség), valamint az aktuálisan rendelkezésre álló erőforrások, és a tényleges kihasználtság arányát. Ha a rendszer már most a teljes infrastruktúra határait feszegeti, akkor a közeljövőben számolni kell a bővítéssel vagy skálázással.

• Fizikai gépek skálázása általában magasabb költséget és több átalakítást jelent.
• Virtualizált környezet esetén a bővítés jellemzően könnyebben megvalósítható.

Egy skálázási feladat kapcsán a kód minősége és annak skálázhatóságra való alkalmassága is előtérbe kerül – ez már részben szóba került a szoftverminőség vizsgálatánál.

Monitorozás és riasztások

A rendszer stabil és hatékony üzemeltetéséhez elengedhetetlen egy jól kiépített monitorozó és riasztási rendszer. Az átvilágítás során érdemes megvizsgálni:

• Milyen monitorozási rendszer működik jelenleg (ha egyáltalán létezik)?
• Milyen metrikákat figyelnek (hardver adatok, szolgáltatások állapota, üzleti KPI-ok stb.)?
• Hogyan működik a riasztás (milyen értékhatároknál, kinek és milyen formában küld jelzéseket)?

Ha a monitorozó és riasztási rendszerek hiányoznak, akkor ezek kialakításával is számolni kell az üzemeltetés átvételekor.

Mentési és helyreállítási folyamatok

Hibák, hardver- vagy szoftverproblémák esetén kiemelten fontos a megfelelő mentési és helyreállítási folyamatok megléte. Ha egy rendszer üzemeltetését vesszük át, akkor ellenőrizni kell:

• Vannak-e kialakított „backup policy”-k?
• Milyen gyakran készülnek mentések, és hová?
• Hogyan zajlik a helyreállítás (restore) folyamata?

Ezek hiánya vagy hiányosságai esetén a mentési eljárások kiépítése külön feladatot és költséget jelenthet. Emellett tisztázni kell a rendszer RTO és RPO elvárásait is:

• RTO (Recovery Time Objective): Az az időtartam, amelyen belül a rendszert vagy szolgáltatást helyre kell állítani egy incidens után.
• RPO (Recovery Point Objective): Az az elfogadható adatvesztési időtartam, amelyet egy rendszer helyreállításakor még tolerál a szervezet.

Ha a jelenlegi mentési és helyreállítási folyamatok nem elégítik ki ezeket az elvárásokat, a megfelelő megoldásokat mindenképpen tervezni kell a jövőben.

Verziókezelés, branching stratégia és CI/CD folyamatok

A forráskódok verziókezelésére használt eszközök (például Git) és a hozzájuk kapcsolódó branching stratégia és workflow jelentősen megkönnyíthetik a fejlesztést és az üzemeltetést. Az audit során hasznos lehet megvizsgálni:

• Milyen verziókezelőt használnak?
• Van-e kialakított CI/CD folyamat (Continuous Integration / Continuous Delivery)?

A CI/CD rendszerek lehetővé teszik az új verziók gyors és biztonságos kiadását, valamint könnyen integrálják az automatizált teszteket. Ha ezek a megoldások hiányoznak, a bevezetésük – és annak költsége – az üzemeltetés átvételekor fontos szempont lehet.

SLA (Service Level Agreement)

Az SLA egy szolgáltatási szint megállapodás, amely meghatározza a rendszerrel szembeni elvárásokat: például rendelkezésre állás, válaszidő, hibaelhárítási idő, támogatási szint.

• Milyen SLA elvárások vannak a rendszerrel szemben?
• Milyen teljesítményszinteket kell garantálni (akár törvényi, iparági standardek, akár ügyfélspecifikus elvárások alapján)?
• Képes-e a rendszer a jelenlegi állapotában ezeknek megfelelni?

Ha a rendszer nem alkalmas az elvárt szolgáltatási szint biztosítására, akkor a fejlesztési és üzemeltetési feladatok, illetve a költségek is jelentősen növekedhetnek.

Ezeknek a területeknek a vizsgálata rávilágíthat arra, hogy milyen állapotban van a rendszer üzemeltetése, és milyen lépésekre lesz szükség a zökkenőmentes átadás-átvétel, illetve a hosszú távú, költséghatékony működtetés érdekében.

6. Korábbi üzemeltetési adatok elemzése

A szoftver állapotának és karbantarthatóságának megismerésében komoly segítséget nyújtanak a már rendelkezésre álló üzemeltetési adatok. A bugtracker és a verziókezelő rendszerekbe bekerült adatok elemzése olyan fontos információkkal szolgálhat, amelyek alapján pontosabb képet kaphatunk a rendszer hibáiról, fejlesztési trendjeiről és kritikus pontjairól.

Bugtracker-rendszer elemzése

Ha a szoftver rendelkezik bugtracker-rendszerrel (pl. Jira, Bugzilla, GitHub Issues stb.), és abban a hibák adminisztrálása is folyik, rengeteg hasznos információt nyerhetünk ki belőle:

Nyitott és visszatérő hibák listája

• Vannak-e kritikus hibák, amelyek még megoldatlanok?
• Akadnak-e olyan, rendszeresen előforduló problémák, amelyek infrastruktúra- vagy kódminőségi hiányosságra utalnak?

Incidensek és leállások előzményei

• Melyek a leggyakoribb okaik a rendszerösszeomlásoknak vagy a teljesítményproblémáknak?
• Milyen idő alatt és milyen módszerekkel sikerült ezeket megoldani?

Javítási idők és reakcióidők (SLA-megfelelés)

• Mennyi idő alatt reagálnak egy-egy hibabejelentésre?
• Teljesülnek-e az SLA-ban rögzített válaszidők és javítási idők?

Hibák besorolása és trendek

• Milyen arányban vannak jelen a kritikus és az alacsony prioritású hibák?
• A hibák száma nő vagy csökken az utóbbi időszakban?

Kapcsolódó workaround-ok és megoldási dokumentációk

• Vannak-e ideiglenes megoldások, amelyeket a fejlesztők vagy az üzemeltetők alkalmaznak?
• Mennyire fenntarthatók ezek, és szükséges-e végleges megoldások kidolgozása?

Verziókövető rendszer elemzése

A verziókezelő rendszer (pl. Git) előzményei is számos hasznos információt nyújthatnak a szoftver állapotáról és a fejlesztés menetéről. A következő módszerekkel azonosíthatjuk a problémás komponenseket vagy kódrészeket:

Code Churn (változás gyakorisága)

• Azok a fájlok vagy modulok, amelyeket gyakran módosítanak, refaktorálnak, illetve ahol gyakran fordulnak elő hibajavítások, valószínűleg alacsonyabb minőségűek vagy rosszul tervezettek.
• Mérési eszközök: Git Analytics, CodeScene.

Bugfixek és hibák kapcsolata

• A bugfix-commitek gyakoriságának vizsgálata megmutatja, mely fájlokban fordul elő a legtöbb hiba.
• Mérési eszközök: Git log és issue-tracker integrációk (pl. Jira, GitHub Issues).

Ownership-elemzés

• Ha egy fájlt vagy modult túl sok különböző fejlesztő módosít, az azt jelezheti, hogy a komponens bonyolult vagy rosszul dokumentált.
• Mérési eszközök: Git blame, GitHub Insights.

Nagy és komplex commitok elemzése

• A nagyméretű commitok gyakran utalnak túlzottan komplex vagy monolitikus kódrészekre, amelyeknek hasznos lehet a refaktorálása.
• Mérési eszközök: GitLens, GitStats.

Elhanyagolt kód és régi függőségek

• Olyan fájlok azonosítása, amelyeket régóta nem módosítottak, de mégis kritikus funkciókat látnak el.
• Mérési eszközök: Git Age Analysis, CodeScene.

Az így kinyert adatok segíthetnek megítélni a várható üzemeltetési és fejlesztési feladatok nagyságrendjét, valamint felhívhatják a figyelmet a rendszer esetleges gyenge pontjaira vagy buktatóira. Az átvilágítás részeként tehát érdemes mind a bugtracker-, mind a verziókövető rendszer adatait részletesen átnézni, hogy megalapozott döntéseket tudjunk hozni a jövőbeni üzemeltetési és fejlesztési tervekhez.

7. Biztonsági kockázatok felmérése

Egy rendszer auditja során elengedhetetlen a biztonsági szempontok feltérképezése. Szoftverüzemeltetés átvételekor különösen fontos tisztában lennünk a rendszer sebezhetőségeivel és azokkal a kockázatokkal, amelyeket a jövőben orvosolnunk kell.

Sebezhetőségi vizsgálat

Egy szoftver sérülékenységeinek feltérképezése többféle nézőpontból és számos eszköz segítségével is elvégezhető:

Forráskód-elemzés (Static Application Security Testing – SAST)

A kódban rejlő biztonsági hibák és kódminőségi problémák azonosítása. Ilyen hibák lehetnek például: SQL-injection, XSS-támadási lehetőségek, hibásan tárolt jelszavak, API-kulcsok vagy privát kulcsok kódba ágyazása.

• Példaeszközök: SonarQube, Checkmarx, Snyk, Fortify

Automatizált sérülékenységvizsgálat (Vulnerability Scanning)

Ismert biztonsági rések és elavult szoftverkomponensek azonosítására szolgál.

• Példaeszközök: Nessus, OpenVAS, Qualys, Rapid7 InsightVM

Webalkalmazások biztonsági tesztelése

Az OWASP Top 10 sérülékenységek (SQL-injection, XSS, CSRF stb.) feltérképezését célozza.

• Példaeszközök: OWASP ZAP, Burp Suite, Nikto

Penetrációs tesztelés (Penetration Testing)

Manuális és szimulált támadások végrehajtása a rendszer védelmi vonalainak tesztelésére. Az ilyen tesztek elvégzése előtt fontos az aktuális üzemeltetővel való egyeztetés, valamint ügyelni kell arra, hogy ne okozzunk szolgáltatáskiesést vagy adatvesztést.

• Példaeszközök: Metasploit, Burp Suite, Kali Linux eszközök (pl. Nmap, Hydra, John the Ripper)

Hálózati sérülékenységek vizsgálata

Nyitott portok, hibás tűzfalszabályok és titkosítási problémák feltérképezése.

• Példaeszközök: Nmap, Wireshark, Snort

A fentieken túl hasznos lehet, ha rendelkezésre állnak korábbi penetrációs tesztek (Pentestek) eredményei is. Érdemes áttekinteni, mely sebezhetőségek derültek ki korábban, és azok milyen arányban kerültek javításra. Az így szerzett információk nagyban hozzájárulhatnak a rendszer biztonsági kockázatainak megalapozottabb felméréséhez és kezeléséhez.

8. Jogi megfelelés vizsgálata

Egy szoftver üzemeltetésének átvételekor fontos, hogy tisztában legyünk a vonatkozó törvényi előírásokkal és iparági szabványokkal, amelyeket az üzemeltetés, valamint a fejlesztések során be kell tartanunk.

Adatvédelmi előírások

A szoftverrel kapcsolatos adatvédelmi követelmények felmérése és a jelenlegi rendszer ennek való megfelelésének ellenőrzése elsődleges feladat. Amennyiben hiányosságokat találunk, ezek kezelésével már az üzemeltetés átvételekor foglalkozni kell.

Néhány kiemelt szempont az adatvédelmi megfelelőség vizsgálatához:

• Adatkezelési elvek betartása: Vizsgálni kell, hogy az adatgyűjtés, -tárolás és -feldolgozás megfelel-e a GDPR előírásainak (például célhoz kötöttség, adattakarékosság).
• Felhasználói jogok biztosítása: A rendszer támogatja-e a felhasználók adatkezelési jogaival kapcsolatos kéréseket (adatokhoz való hozzáférés, törlés – „right to be forgotten”, hordozhatóság)?
• Adatvédelmi incidenskezelés: Van-e dokumentált eljárás az adatszivárgások bejelentésére és kezelésére?
• Adatbiztonsági intézkedések: Milyen titkosítási, anonimizálási, hozzáférés-kezelési és naplózási megoldások működnek jelenleg?
• Hozzájárulás-kezelés: Megfelelően naplózzák-e a felhasználók hozzájárulásait, és lehetőséget biztosítanak-e azok visszavonására?

Kapcsolódó jogszabályok és szabványok:

• GDPR (General Data Protection Regulation): Az Európai Unió adatvédelmi rendelete, amely a személyes adatok kezelését szabályozza.
• CCPA (California Consumer Privacy Act): Az USA-ban érvényes, a GDPR-hoz hasonló elveket tartalmazó szabályozás.
• HIPAA (Health Insurance Portability and Accountability Act): Az egészségügyi adatok védelmét szabályozza az USA-ban.
• ISO 27001: Az információbiztonsági irányítási rendszerek (ISMS) nemzetközi szabványa.

Iparági szabványok és törvényi előírások megfelelőségének vizsgálata

Az adatvédelmi előírásokon túl érdemes tisztázni, hogy milyen egyéb iparági szabványok vagy törvényi előírások vonatkoznak a szoftverre. Az átvilágítás során ellenőrizni kell, hogy a rendszer ezeknek mennyiben felel meg. Előfordulhatnak például pénzügyi, egészségügyi vagy éppen távközlési szektorból eredő előírások, amelyeket szintén be kell tartani.

Licencfeltételek ellenőrzése

Végezetül fontos, hogy az átadás-átvétel során fordítsunk kellő figyelmet a használt rendszerek, keretrendszerek és könyvtárak licencfeltételeinek ellenőrzésére. Ha a projektben „commercial license” alatt használt komponensek is szerepelnek, akkor tisztázni kell, hogy ki viseli ezeknek a költségeit, illetve a licencek fenntartásának vagy megújításának feltételeit.

9. AI alapú toolok használata

Egy rendszer megismerésében és feltérképezésében hatékony segítséget nyújthatnak az AI-alapú eszközök, amelyek képesek átvizsgálni és elemezni a teljes kódbázist. Ennek eredményeként nemcsak sérülékenységeket és kritikus kódrészeket azonosíthatnak, de akár dokumentációt is generálhatnak, illetve chatfelületen keresztül válaszolhatnak a rendszerrel kapcsolatos kérdésekre.

Fontos azonban tisztázni a szoftver tulajdonosával, hogy milyen feltételek mellett kívánjuk használni ezeket az eszközöket, hiszen gyakran a teljes forráskódot is át kell adni az LLM rendszernek elemzésre. Elengedhetetlen, hogy meggyőződjünk a választott LLM modell biztonsági és adatkezelési gyakorlatáról, valamint a forráskód további felhasználására vonatkozó engedélyekről.

Néhány példa az AI-alapú elemző-toolokra:

• DeepCode (Snyk Code): AI-alapú statikus kódelemző, amely kódszintű hibák és biztonsági rések azonosításában segít
• CodeGuru (AWS): Az Amazon AI-eszköze, amely kódanalízist és teljesítményoptimalizálást végez
• Tabnine: AI-alapú kódkiegészítő, amely a fejlesztés közben segíti az optimális kódírást
• Cursor IDE: AI-alapú fejlesztői környezet, amely automatikusan támogatja a refaktorálást, a kódelemzést és a hibajavítást, ezzel meggyorsítva az auditot és a fejlesztési folyamatokat
• Sourcegraph Cody: Olyan kódelemző AI, amely az egész kódbázisra nézve tesz javaslatokat a kódminőség javítására