ÚTMUTATÓ RENDSZER INTEGRÁTOROK SZÁMÁRA

Átírás

1 ÚTMUTATÓ RENDSZER INTEGRÁTOROK SZÁMÁRA

2 A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az Elektronikus közigazgatási keretrendszer tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett: EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 2

3 Metaadat-táblázat Megnevezés Leírás Cím (dc:title) Útmutató rendszer integrátorok számára Kulcsszó (dc:subject) IT biztonság; értékelés; útmutató Leírás (dc:description) Az elkészült e-közigazgatási alkalmazásokat, valamint az ezt biztosító informatikai rendszereket használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A követelménytár tartalmazza a szolgáltató (informatikai) rendszerek megfelelıség vizsgálatára alkalmazható biztonság értékelési módszertant. A módszertan egyaránt meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer tulajdonosi és rendszer integrátori feladatokat, illetve a biztonságot értékelık feladatait. Ez a dokumentum a rendszer integrátorok számára biztosít kiegészítı útmutatást az értékelési módszertan néhány kiemelten fontos részterületéhez. Típus (dc:type) Szöveg, táblázat Forrás (dc:source) Kapcsolat (dc:relation) e-közigazgatási Keretrendszer egyéb dokumentumai Terület (dc:coverage) KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialakítása projekt Kiadó (dc:publisher) Miniszterelnöki Hivatal Résztvevı (dc:contributor) Hunguard Kft Jogok (dc:rights) e-közigazgatási Keretrendszer Dátum (dc:date) Formátum (dc:format).doc Azonosító (dc:identifier) Nyelv (dc:language) Magyar Verzió (dc:version) V3 Státusz (State) Végleges Fájlnév (FileName) EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.doc Méret (Size) Ár (Price) Felhasználási jogok (UserRights) Korlátlan EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 3

4 Verziókövetési táblázat A dokumentum neve Útmutató rendszer integrátorok számára A dokumentum készítıjének neve Hunguard Kft A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám V3 Összes oldalszám 39 A projekt azonosítója E-közigazgatási keretrendszer kialakítása Változáskezelés Verzió Dátum A változás leírása V Elsı tartalomjegyzék V Elsı változat V Részteljesítésként átadott V Végleges változat EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 4

5 Szövegsablon Megnevezés Leírás 1. Elıszó (Foreword) 1. fejezet 2. Bevezetés (Preamble) 2. fejezet 3. Alkalmazási terület (Scope) 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia nincs 8. Rövidítésgyőjtemény 9. fejezet 9. Fogalomtár 10. Ábrák nincs 11. Képek nincs 12. Fogalmak 5. fejezet 13. Verzió V3 14. Mellékletek (Appendix) nincs EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 5

6 Tartalomjegyzék 1. Elıszó Bevezetés A dokumentum célja A dokumentum felépítése Alkalmazási terület Rendelkezı hivatkozások Fogalom-meghatározások Útmutatók a rendszer integrálás kritikus területeihez Gyakorlati útmutató a biztonságos rendszer integrálásra Operációs rendszerek helyes konfigurálása Web szerverek védelme Webes alkalmazások védelme Adatbázisok védelme Útmutató a rendszer biztonsági teszteléséhez Eltérı feladatok és felelısségek a tesztelésben Különbözı tesztelési típusok Tesztelési lehetıségek a szoftver különbözı életciklus fázisaiban Biztonsági hibajavítás, javítócsomagok kezelése A javítócsomagok alkalmazásának szerepe Mérföldkövek a javítócsomagok alkalmazásában Mellékletek Bibliográfia Rövidítésgyőjtemény Fogalomtár Ábrák Képek Táblázatok Verziószám EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 6

7 1. Elıszó Jelen dokumentum az e-közigazgatási Keretrendszer részét képezi. Az elkészült e-közigazgatási alkalmazásokat használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A megfelelıség vizsgálatra alkalmazható biztonság értékelési módszertan a követelménytár alábbi dokumentumaiban található: Termékekre vonatkozó értékelési módszertan [1], Összetett termékekre vonatkozó értékelési módszertan [2], Rendszerekre vonatkozó értékelési módszertan [3]. A rendszer szintő értékelési módszertan felhasználja a rendszert alkotó komponensekre (termékekre, illetve összetett termékekre) korábban elvégzett értékelési és tanúsítási munkák eredményeit. A rendszerek integrátorainak figyelembe kell venniük a biztonsági követelményeket, a rendszerben felhasznált értékelt, tanúsított termékek tanúsítására vonatkozó érvényességi feltételeket, de a rendszerértékelés elıkészítéséhez is meghatározott feladatokat kell teljesíteniük. A rendszer szintő értékelési módszertan meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer integrátori feladatokat, valamint a biztonságot értékelık feladatait. A rendszer szintő értékelési módszertanban meghatározott integrátori és értékelıi feladatok végrehajtásához két gyakorlati útmutató kapcsolódik: Útmutató rendszer integrátorok számára (jelen dokumentum), Útmutató rendszer értékelık számára [4]. 2. Bevezetés 2.1. A dokumentum célja Jelen dokumentum a rendszer szintő értékelési módszertanban [3] meghatározott integrátori feladatok végrehajtásához nyújt gyakorlati útmutatót. Feltételezi [3] 6.1 alfejezetének (Elıkészítı feladatok informatikai rendszerek biztonsági értékeléséhez) ismeretét. A dokumentum célja a [3] által meghatározott rendszer integrátori feladatok elvégzéséhez használható ismeretek nyújtása, s ezzel [3] gyakorlati szemlélető kiegészítése néhány fontos területen. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 7

8 2.2. A dokumentum felépítése Az 1. fejezet elhelyezi a dokumentumot az e-közigazgatási Keretrendszeren belül, tájékoztatást adva a célközönségrıl és a kapcsolódó dokumentumokról. A 2. fejezet bevezetı információkat tartalmaz, megadva a dokumentum célját és felépítését. A 3. fejezet meghatározza az alkalmazás lehetséges területeit. A 4. és 5. fejezet a rendelkezı hivatkozásokat, illetve a fogalom-meghatározásokat tartalmazza. A 6. fejezet tartalmazza a dokumentum lényegi részét, 3 alfejezetben. A 6.1 alfejezet a biztonságos rendszer integrálásra ad gyakorlati útmutatást. Felhasználható a rendszer architektúra megtervezéséhez, a rendszer integrálásához, valamint számos értékelési bizonyíték elkészítéséhez. Egy tipikus rendszer alábbi biztonság-kritikus területeit tekinti át: az operációs rendszerek alapértelmezéső telepítésének (alapkonfigurációk) veszélyei, a web szerverek védelmére meghozandó általános biztonsági intézkedések, a webes alkalmazások védelmét szolgáló biztonsági ajánlások, az adatbázisok védelmét szolgáló javaslatok. A 6.2 alfejezet a rendszer biztonsági teszteléséhez nyújt útmutatást. Elıbb áttekinti a termék fejlesztık, rendszer integrátorok és biztonságot értékelık eltérı feladatait és felelısségeit a tesztelés területén (6.2.1). Ezt követıen áttekinti a különbözı tesztelési típusokat, (rámutatva a funkcionális és biztonsági tesztelés közötti különbségekre is (6.2.2), valamint a szoftverfejlesztés különbözı életciklus fázisaiban végzendı teszteléseket (6.2.3). A 6.3 alfejezet a biztonság szempontjából kritikus javítócsomagok kezelését tárgyalja. Jelen dokumentumnak nincsenek mellékletei. A fejezetek kiegészítı információkat tartalmaznak (8. Bibliográfia, 9. Rövidítésgyőjtemény, 10. Fogalomtár, 11. Ábrák, 12. Képek, 13. Táblázatok, 14. Verziószám). 3. Alkalmazási terület A [3] által meghatározott rendszer értékelési módszertan, s így az ezt gyakorlati útmutatóval kiegészítı jelen anyag is elsıdlegesen a közigazgatási operatív programok keretében megvalósított szolgáltató rendszerek biztonsági értékelésére vonatkozik. Ezáltal a közigazgatási operatív programok végrehajtásával elkészülı szolgáltató rendszerekre irányuló megfelelıségi vizsgálatok eljárásrendjének részét képezi. Ugyanakkor az informatikai rendszerek biztonsági értékelési módszertana az elektronikus közigazgatáson kívül, a közszféra más területein, valamint a magánszférában is EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 8

9 alkalmazhatók, minden olyan esetben, amikor rendszerek megfelelıség vizsgálatára, ezen belül biztonsági értékelésére van szükség. 4. Rendelkezı hivatkozások A jelen dokumentumban megfogalmazott irányelvek és követelmények az alábbi mértékadó dokumentumokon alapulnak: [1]: Termékekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [2]: Összetett termékekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [3]: Rendszerekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [4]: Útmutató rendszer értékelık számára (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) 1. táblázat - A rendelkezı hivatkozások elérhetısége Cím Külföldi elérhetıség Magyar elérhetıség Termékekre vonatkozó értékelési e-közigazgatási Keretrendszer módszertan Összetett termékekre vonatkozó e-közigazgatási Keretrendszer értékelési módszertan Rendszerekre vonatkozó értékelési e-közigazgatási Keretrendszer módszertan Útmutató rendszer értékelık számára e-közigazgatási Keretrendszer 5. Fogalom-meghatározások Jelen dokumentum a [3]-ban meghatározott fogalmakon kívül egyéb külön meghatározandó fogalmakat nem használ. Jelen dokumentum ugyanakkor feltételezi a [3]-ban meghatározott fogalmak ismeretét. 6. Útmutatók a rendszer integrálás kritikus területeihez 6.1. Gyakorlati útmutató a biztonságos rendszer integrálásra Az alábbi útmutatót érdemes már a rendszer architektúrájának megtervezésekor, majd a rendszer összeépítése (integrálása) során figyelembe venni. Ebben a megközelítésben az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: biztonsági architektúra leírás (ASDV_ARC, lásd [3] ), rendszer interfész specifikáció (ASDV_SIS, lásd [3] ), EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 9

10 rendszer biztonsági terv (lásd ASDV_SDS, lásd [3] ). Az alábbiakban megfogalmazott javaslatok ugyanakkor elsısorban a már integrált rendszer biztonságos konfigurálását segítik. Ebben a megközelítésben az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: Elıkészítési útmutató (ASGD_PRE, lásd [3] ), Konfigurálási útmutató (ASGD_CON, lásd [3] ). A következı logikai sorrendet követjük: az operációs rendszerek alapértelmezéső telepítésének (alapkonfigurációk) veszélyeinek a kivédése ellenırzı listák alkalmazásával (6.1.1), a web szerverek védelmére meghozandó általános biztonsági intézkedések (6.1.2), a webes alkalmazások védelmét szolgáló biztonsági ajánlások (6.1.3), az adatbázisok védelmét szolgáló javaslatok (6.1.4) Operációs rendszerek helyes konfigurálása A telepített operációs rendszerek és szolgáltatásaik biztonságának növelésére ajánlások, biztonsági ellenırzı listák (security checklist) léteznek, melynek használata feltétlenül javasolt. Ezek lényege az alábbi két ellentétes szempont figyelembe vétele: az operációs rendszerek alapértelmezéső telepítése a biztonság szempontjából hiányos, ezért kiegészítésre, megerısítésre szorul, az operációs rendszerek alapértelmezéső telepítése számos olyan tulajdonságot és szolgáltatást biztosít, mely a biztonságra kifejezetten veszélyes, ezért ezek (hacsak a funkcionalitás oldaláról külön nem indokolható feltétlen szükségességük) eltávolítandók, korlátozandók, kikapcsolandók Windows rendszerek Windows rendszerek esetén az alábbi mértékadó dokumentum tartalmaz hasznos ötleteket: A biztonsági ellenırzı lista fıbb javaslatai az alábbiak: Jelszóhasználat megerısítése (password length, password age, ), Kizárás megerısítése (lockout threshold, lockout duration, ), Naplózás megerısítése, Felhasználói jogosultságok megerısítése, Utolsó bejelentkezett felhasználó elrejtése a bejelentkezési ablakban, Fájlrendszer ellenırzése (NTFS), Rendszerkönyvtár megerısítse (System), Jelszófájl megerısítése (SAM), Antivírus szoftver beállítása, Naplóállományok védelmének beállítása, Registry megerısítése. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 10

11 Javaslat_1: Tanulmányozzuk és fogadjuk el a fenti ellenırzı lista javaslatait. Kiegészítı javaslat a Null Session kizárására A Windows rendszerek Achilles sarkának emlegetett Common Internet File System / Server Message Block (CIFS/SMB) protokoll tartalmazza annak lehetıségét, hogy egy rendszerhez hitelesítés nélkül is csatlakozhatunk. Csatlakozás után felhasználókról, megosztásokról, registry kulcsokról kaphatunk információkat. A Microsoft tett ugyan már lépéseket, hogy kizárja ezt a Null Session szolgáltatást az egyes alaptelepítésekbıl, de ez a szolgáltatás szervereken (Windows Server 2003 és 2008) alapértelmezésben még mindig elérhetı. Javaslat_2: Állítsuk le az SMB szolgáltatást, ha nincs rá feltétlen szükség. Javaslat_3: Amennyiben az SMB szolgáltatásra feltétlenül szükség van: Biztosítsuk, hogy minden adminisztrátori jelszó különösen erıs legyen, és felhasználók ne kaphassanak adminisztrátori jogosultságot. (A számítógép által létrehozott rejtett felügyeleti megosztások - mint az ADMIN$ és a C$ - törlése nem megoldás, mert a Kiszolgáló szolgáltatás leállítása és újraindítása, vagy a számítógép újraindítása után a rendszer ismét létrehozza azokat.) Töröljük a felhasználók által létrehozott rejtett megosztásokat. (Ezeket újraindítás után a számítógép nem hozza ismét létre. A Microsoft Windows XP Home Edition nem hoz létre rejtett felügyeleti megosztásokat. Lásd még errıl részletesebben: Kiegészítı javaslatok a megosztások kezelésére A megosztások (Shares) gyakran súlyos incidensekhez vezetnek, amennyiben a felhasználóknak megengedett megosztásokat létrehozni vagy létezı megosztásokba fájlokat másolni. Ha szabályozatlanul történik a megosztások kezelése, akkor számítani lehet rá, hogy érzékeny adatokat is meg fognak osztani, véletlenül is bemásolnak védendı információkat, mert az átlag felhasználók nincsenek tisztában a megosztások veszélyeivel. A megosztások ezenkívül nagyban elısegítik a kártékony programkódok, férgek, vírusok terjedését, mert számos károkozó terjed úgy, hogy csalogató névvel bemásolja magát az elérhetı megosztásokba, amelyet a gyanútlan felhasználó elindít, megnyit. Javaslat_4: a felhasználók számára tiltsák meg a megosztások létrehozását, vagy létezı megosztások fájlokba másolását. A közös projektekben dolgozó munkatársaknak hozzanak létre projektkönyvtárakat, s ezek jogosultságának megfelelı beállításával érjék el, hogy azt csak az arra jogosultak láthatják/írhatják. Alaptelepítésben a Windows rendszerek megosztják az összes partíciójukat (c$, d$, ), távoli adminisztrációs célokkal. Ezeket távolról fel lehet csatolni rendszergazdai jogosultsággal, vagyis local admin illetve domain admin joggal. Sikeres felcsatolás után távolról a partíció teljes tartalma hozzáférhetı, írható, olvasható. Helyi adminisztrátor jelszót gyakran nem is kell sokáig kutatni, mert a felhasználók (gyakran nem is tudatosan) adminisztrátori joggal használják a gépüket. Domain admin jogosultságot pedig a már ismertetett null session szolgáltatáson keresztül elérhetı kiinduló információk alapján lehet megpróbálni kitalálni. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 11

12 Linux rendszerek Linux rendszerek esetén például a Sans féle Linux Security Checklist írás tartalmaz hasznos javaslatokat a biztonság növelésére. A biztonsági ellenırzı lista fıbb javaslatai az alábbiak: Boot és mentılemez készítése, Biztonsági javítócsomagok (system patches) rendszeres alkalmazása, Felesleges szolgáltatások letiltása, Kulcsfontosságú fájlok hozzáférésvédelme, Alap jelszópolitika, Root hozzáférés korlátozása, Szerver szoftverek árulkodó fejléceinek (banner) megváltoztatása, SSH kiszolgáló megerısítése, Csomagszőrı tőzfal beállítása, Inetd felesleges szolgáltatások kikapcsolása, Tcpwrapper alkalmazása, Naplózás beállítása, Biztonsági mentések beállítása, Kritikus fájlokon az integritás ellenırzése, Web szerver (Apache) megerısítése, Web szerver biztonsági mudul (mod_security) alkalmazása, Xwindow rendszer megerısítése, Biztonsági kernel bıvítések (pl.:lids, Selinux) alkalmazása, szolgáltatás megerısítése, Fájlmegosztások (Samba) megerısítése, Rejtjelezések beállítása (SSL), Antivírus szoftver alkalmazása. Javaslat_5: Tanulmányozzuk és fogadjuk el a fenti ellenırzı lista javaslatait Web szerverek védelme Az alábbi lista segíti a rendszeradminisztrátorokat, hogy a rendszerükben található web szerverek biztonságát növeljék. Általános biztonsági ajánlások: Bizonyosodjunk meg, hogy az összes web szerver szoftver és betöltött moduljai (Microsoft IIS, Apache, OpenSSL, PHP, mod_perl) naprakész, legfrissebb szoftvercsomagokat tartalmaznak, amelyek biztosítják, hogy a már ismert és publikált biztonsági hiányosságokat nem lehet kihasználni a szerver ellen. Ha a web szerver nem szolgál ki dinamikus tartalmakat (PHP, ASP, PERL), akkor gondoskodjunk róla, hogy a web szerver ne töltse be ezen lapok kiszolgálására képes modulokat (mod_php, mod_perl, stb.). Ezen dinamikus tartalmak moduljai a web szerverek leggyakrabban támadott pontjai. A legtöbb puffer túlcsordulásos támadás kivitelezésekor a támadó kód kikapcsolódik egy távoli szerverre, hogy onnan parancsot töltsön le. Az ilyen támadások EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 12

13 detektálására hasznos lehet, ha szőrjük / figyeljük a web szerverrıl kimenı kapcsolati kezdeményezéseket, mert ezek támadásra utalhatnak. Kapcsoljuk ki az autoindex funkciókat, amelyek megvédik a felderítésektıl a szerver azon könyvtárait, amelyekben nincs kezdıpont (index.html, index.php, stb.). Kapcsoljuk ki a szerveroldali alkalmazások hibakiírását, vagy naplózzuk ıket fájlba, mert a kliensnek kiküldött hibajelentések érzékeny adatokat tartalmazhatnak a rendszerrıl. Javaslat_6: Tanulmányozzuk és fogadjuk el a fenti általános biztonsági ajánlásokat. Microsoft specifikus biztonsági ajánlások: Ellenırizzük az IIS szerverünk konfigurációját a Microsoft honlapján található eszközökkel: URLScan és IIS Lockdown. Távolítsuk el a fölösleges ISAPI kiterjesztéseket. Ne futtassuk az Outlook Web Access szolgáltatást könnyen kitalálható elérési úton (/owa, /exchange, /mail). Védjük ezt a fontos szolgáltatást SSL protokollal a lehallgatástól. Minimalizáljuk a futtatható adminisztrációs tartalmakat, amelyek számos sérülékenységet tartalmaztak /tartalmazhatnak. Ilyenek: /msadc, /scripts, /_vti_bin Ha nem használjuk, kapcsoljuk ki a WebDAV szolgáltatást, ami megakadályozza a veszélyes PUT, DELETE, SEARCH kérések teljesítését. Javaslat_7: Tanulmányozzuk és fogadjuk el a fenti Microsoft specifikus biztonsági ajánlásokat Webes alkalmazások védelme Fontosabb biztonsági ajánlások webes alkalmazások esetén: Bizonyosodjunk meg, hogy a webes szolgáltatásban részt vevı szoftverek biztonsági frissítései folyamatosan települnek a rendszerre, nem tartalmaznak már ismert biztonsági réseket. A webes alkalmazás minden esetben ellenırizze a klienstıl érkezı adatokat, szőrje ki a veszélyes karaktereket ( ; -- ). Javasolt a web szerver biztonsági modulok használata, például mod_security vagy Microsoft URLscan. Gondoljuk jól át a session használatot, használjuk a rendszer beépített session management-jét, állítsunk be a session azonosítókra lejárati idıt. Ha nem használunk szerver oldali nyelvet, ne legyen betöltve annak modulja. A háttéradatbázis használatakor a webes alkalmazás korlátozott jogosultsággal használja az adatbázist, ne tudjon más adattáblákhoz hozzáférni, rendszerszintő utasításokat végrehajtani (SA). Javaslat_8: Tanulmányozzuk és fogadjuk el a fenti biztonsági ajánlásokat. További hasznos információk és segédanyagok találhatók e témában az alábbi két dokumentumban: A Security Checklist for Web Application Design EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 13

14 A Guide to Building Secure Web Applications and Web Services Adatbázisok védelme Az adatbázisok az informatikai rendszerek, ezen belül a webes szolgáltatások elengedhetetlen részét alkotják. Mivel a háttérben kiszolgáló funkciót ellátó adatbázisszervereken értékes információk találhatók, ezért az adatbázisszerverek a támadások gyakori célpontjai. A legtöbb hazai szervezet (köztük a közigazgatási szervek is) informatikai rendszerei SQL szervereket tartalmaznak. A legismertebb és leggyakrabban alkalmazott SQL szerverek az alábbiak: Microsoft SQL Server (MsSQL), Oracle, MySQL Általános biztonsági ajánlások SQL szerverek esetén SQL szerverek esetén általános biztonsági ajánlások az alábbiak: Bizonyosodjunk meg arról, hogy a telepített SQL szerverek alapértelmezett felhasználóinak (MsSQL esetén sa és probe, Oracle esetén sys, system, scott, dbsnmp, MySQL esetén root ) megfelelıen erıs jelszó van beállítva. Szőrjük és ellenırizzük a kívülrıl megvalósítható adatbázishoz kapcsolódási lehetıségeket a beépített jogosultság kezelésével, illetve tőzfal alkalmazásával. Ezzel megakadályozható, hogy bárki belépési próbálkozásokat végezzen az SQL szerveren. Amennyiben a webes alkalmazás egy hoszton fut az SQL kiszolgálóval (ez nagyon gyakran így van), akkor nincs is szükség, hogy az SQL szerver távolról kapcsolatokat fogadjon el, tiltsuk ezt le. Az elıre telepített rendszerszintő tárolt eljárások hozzáférését korlátozzuk. Kísérjük figyelemmel az SQL szerverünket érintı biztonsági bejelentéseket, a javításokat azonnal telepítsük a rendszerre. Javaslat_9: Tanulmányozzuk és valósítsuk meg a fenti biztonsági ajánlásokat. Az SQL szerverek biztonságával kapcsolatos hasznos publikációkat és eszközöket találunk a következı oldalakon: Biztonsági ajánlás MsSQL szerverek esetén MsSQL szerverek esetén speciális biztonsági ajánlás a következı: Javaslat_10: Mivel az MsSQL szerver adminisztrátori jogosultságú felhasználója (sa) alaptelepítésben jelszó nélkül tud bejelentkezni egészen az SQL Server 2003 verzióig, EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 14

15 ezért lehetıleg ezt követı verziókat használjunk (melyek már nem engedik meg a jelszó nélküli bejelentkezést), vagy állítsunk be megfelelı erıs jelszót az "sa" felhasználónak Biztonsági ajánlások Oracle szerverek esetén Oracle szerverek esetén a TNS protokollon keresztül lehet csatlakozni a szerveren hallgató TNS listener szolgáltatáshoz. Ehhez a szolgáltatáshoz alaptelepítés esetén hitelesítés nélkül is lehet csatlakozni, sıt parancsok is futtathatók, akár az adatbázisrendszeren kívüli környezetben is. Javaslat_11: Tiltsuk meg az adatbázishoz való távoli hozzáférést. Javaslat_12: Amennyiben az adatbázishoz való távoli hozzáférés feltétlenül szükséges: Erısítsük meg a TNS listener alapértelmezett beállításait: állítsunk be jelszót a TNS listener számára, kapcsoljuk be a naplózását. Tőzfalszabályok alkalmazásával szőrjük az adatbázishoz kapcsolódásokat. A fentiekrıl részletesebben lásd az alábbi dokumentumot: Oracle Database Listener Security Guide: Speciális biztonsági ajánlások MySQL szerverek esetén MySQL szerverek esetén speciális biztonsági ajánlások a következık: Javaslat_13: A MySQL alaptelepítésekor létrejön egy saját root felhasználó, amelynek a jelszava üres. Ezt feltétlenül cseréljük le megfelelıen erıs jelszóra. Javaslat_14: További veszélyforrás lehet, ha a webes alkalmazások root felhasználóval kapcsolódnak az adatbázishoz, mert ennek jelszava gyakran visszakereshetı a konfigurációs állományokból. Ezért soha ne használjuk a webes alkalmazásunkban a MySQL root felhasználót az adatbázis mőveletek végrehajtására, hanem hozzunk létre egy új MsSQL felhasználót a webes alkalmazás számára. Az új felhasználó jogosultságát korlátozzuk az alkalmazás által használt adattáblák elérésére Útmutató a rendszer biztonsági teszteléséhez Ez az alfejezet az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: Tesztelési dokumentáció (ASTE_FUN, lásd [3] ), Tesztlefedettség elemzés (ASTE_COV, lásd [3] ), Tesztmélység elemzés (ASTE_DPT, lásd [3] ), Regressziós tesztelés dokumentációja (ASTE_MOD, lásd [3] ), EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 15

16 Eltérı feladatok és felelısségek a tesztelésben A teszteléssel kapcsolatban a szoftver termékek fejlesztıinek, a termékbıl rendszert összeépítı rendszer integrátoroknak, illetve a rendszer biztonságát értékelıknek eltérı feladataik és felelısségük van A szoftver termék fejlesztıjének feladata és felelıssége A szoftver termékek fejlesztıinek a szoftverminıség legtöbb jellemzıjére figyelemmel kell lenniük munkájuk során, köztük az MSZ ISO/IEC 9126 szabvány által megadott alábbiakra: Funkcionalitás (Azon tulajdonságok összessége, amelyek valamilyen kifejezett vagy elvárt igényt kielégítı funkciókra és ezek tulajdonságaira vonatkoznak. Segédjellemzıi: alkalmasság, pontosság, együttmőködés, alkalmazhatóság, biztonság.), Megbízhatóság (Azon tulajdonságok összessége, amelyek a szoftver azon képességére vannak hatással, hogy - adott feltételek között és adott idıszakon belül - teljesítményszintjét fenntartsa. Segédjellemzıi: kiforrottság, hibatőrés, helyreállíthatóság.), Használhatóság (Azon tulajdonságok összessége, amelyek a használathoz szükséges ráfordításra, és az ilyen használat egyedi felmérésére vannak hatással, a felhasználók közvetlenül vagy közvetetten meghatározható körében. Segédjellemzıi: érthetıség, megtanulhatóság, üzemeltethetıség.), Hatékonyság (Azon tulajdonságok összessége, amelyek a szoftver teljesítményszintje és az ehhez felhasznált erıforrások mennyisége között fennálló kapcsolatra vannak hatással. Segédjellemzıi: idıigény, erıforrásigény.), Karbantarthatóság (Azon tulajdonságok összessége, amelyek konkrét változtatások - pl. helyesbítés, továbbfejlesztés, külsı változásokhoz való illesztés - elvégzéséhez szükséges ráfordításokra vannak hatással. Segédjellemzıi: elemezhetıség, változtathatóság, stabilitás, tesztelhetıség.), Hordozhatóság (Azon tulajdonságok összessége, amelyek a szoftver azon képességére vannak hatással, hogy a szoftver egyik környezetbıl a másikba lehessen átvinni. Segédjellemzıi: adaptálhatóság, telepíthetıség, mőszaki megfelelıség, kiválthatóság.) A szoftver termékek (modul és termék szintő) tesztelésénél valamennyi fenti szempont figyelembe veendı, és ez elsısorban a termék fejlesztı feladata és felelıssége A rendszer integrátor feladata és felelıssége A termékbıl rendszert összeépítı rendszer integrátoroknak nincs lehetıségük a fenti jellemzık és segédjellemzık utólagos megvalósítására, megerısítésére, de még teljes körő vizsgálatára, tesztelésére sem. Az ı feladatuk és felelısségük kettıs: kihasználni a fejlesztık által megvalósított jellemzıket a rendszer integrálásánál (pl. telepíthetıség, változtathatóság, üzemeltethetıség), biztosítani azt, hogy a különbözı fejlesztık által megvalósított jellemzık ne vesszenek el, ne sérüljenek a rendszer integrálás során (pl. együttmőködés, biztonság). EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 16

17 A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél döntıen az interoperabilitás és a biztonság szempontjaira kell koncentrálniuk, mivel ezek azok a tulajdonságok (segédjellemzık), amelyek különbözı termékekbıl integrált rendszerekben könnyen sérülhetnek. Jelen útmutató a biztonsági tesztelésre irányul. Ugyanakkor nem szabad elfelejteni, hogy számos hagyományos szoftver hibának biztonsági kihatása is lehet. A hibás mőködés szinte kivétel nélkül elıre nem látott mőködés, s így ez lehetıséget biztosít a támadónak egy potenciális hiba kihasználására. Számos jól ismert sebezhetıség (mint pl. a puffer túlcsordulás, a formátum sztring hiba, a kettıs felszabadítás) rendszer összeomláshoz vezethet (feltéve, hogy véletlenül kerültek végrehajtásra és nem egy támadó direkt támadási kísérlete idézte elı ezeket). A rendszer összeomlás bizalmas adatokat is elérhetıvé tehet a diagnosztikai és adat kilistázások formájában. Még ha a szoftver nem is omlik össze egy hiba miatt, a belsı állapota megsérülhet, ami késıbb nem várt viselkedést eredményezhet. Maguk a hibakezelık is gyakran célpontjai a rosszindulatú támadóknak. A fenti okok miatt a hagyományos program hibákat is figyelembe kell venni a biztonsági tesztelés során. A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél tehát az interoperabilitás és a biztonság szempontjain túl a megbízhatóság szoftverminıség jellemzıre is kiemelt figyelmet kell fordítaniuk A rendszer értékelı feladata és felelıssége Egy informatikai rendszer értékelıjének feladata alapvetıen a rendszer biztonságára irányul. A biztonságra irányuló vizsgálata során az alábbiakra támaszkodhat: a rendszert alkotó szoftver termékek fejlesztıi által végzett tervezı/megvalósító/ ellenırzı munka, ez utóbbin belül a termék modul és termék szintő tesztelése (a szoftverminıségi valamennyi jellemzıje szerint), a rendszert alkotó szoftver termékek független értékelését elvégzı értékelık és tanúsítók eredményei (melyek döntıen az interoperabilitásra és a biztonságra irányultak), a rendszer integrátor által készített értékelési bizonyítékok, melyek elsısorban a biztonságra irányulnak, s tartalmazzák a komponens (termék), alrendszer és rendszer szintő biztonsági tesztelés eredményeit is. Ahogy a rendszer integrátoroknak nincs lehetıségük a termékek általános minıségi jellemzıinek teljes körő vizsgálatára, tesztelésére, úgy a rendszer értékelıknek sincs lehetıségük egy bonyolult rendszer termék komponenseinek teljes körő biztonsági vizsgálatára és tesztelésére. Egy rendszer biztonsága jelentıs mértékben azon múlik, hogy a komponensek fejlesztıi milyen megbízható munkát végeztek, illetve, hogy a biztonság szempontjából fontos (a biztonságot érvényre juttató és támogató) termékekre végeztek-e független értékeléseket. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 17

18 A rendszer szintő biztonsághoz azonban kevés az alkotó termékek biztonsága, akár magas garanciaszinten értékelt és tanúsított termékek integrálását is el lehet rontani, helytelen koncepcióval, tervezéssel és konfigurálással, illetve hibás üzemeltetési paraméterek alkalmazásával. A rendszer integrátor által elvégzendı és dokumentálandó biztonsági tesztelés egy fontos eleme a rendszer biztonság megvalósításának Különbözı tesztelési típusok Jelentıs különbség van a szoftverek funkcionális, biztonsági és behatolás tesztelése között. A funkcionális tesztelés célja a szoftver megfelelıségének ellenırzése az általános szoftverminıségi követelményeknek. Ez alapvetıen a szoftver fejlesztı feladata és felelıssége. A biztonsági tesztelés célja a szoftver megfelelıségének ellenırzése a biztonsági követelményeknek. Termékek esetén ez alapvetıen a fejlesztı, míg rendszerek esetén a rendszer integrátor feladata és felelıssége. A (termék vagy rendszer) értékelıje ezt a tesztelést ellenırzi, egy mintavételezéssel kiválasztott részét megismétli, illetve független teszteléssel kiegészíti. A behatolás tesztelés célja potenciális biztonsági sebezhetıségek felfedése (a termékben vagy rendszerben). Ez alapvetıen az értékelı feladata és felelıssége, minthogy különleges (támadói) szemléletet, valamint speciális szaktudást és eszközöket igényel. Az alábbiakban részletesen jellemezzük a funkcionális és biztonsági tesztelést. A behatolás tesztelés témáját [4] részletezi. Mivel a funkcionális tesztelés tartalmazza a biztonsági tesztelést is, s ez utóbbi útmutatónk elsıdleges irányultsága, ezért a funkcionális tesztelésnél is elsısorban biztonsággal kapcsolatos példákat tárgyalunk A funkcionális tesztelés A funkcionális tesztelés célja a szoftver megfelelıségének ellenırzése az általános szoftverminıségi követelményeknek. Ezen belül általában a legnagyobb hangsúly a funkcionális követelményeknek való megfelelésre esik ( a szoftver úgy viselkedik-e, ahogy kell ). A funkcionális tesztelés bevett gyakorlata, hogy minden egyes (funkcionális) követelménynek megfelel egy szoftver elem, amely ezt a követelményt hivatott megvalósítani. Ebbıl következıen egy adott követelménynek való megfelelıséget ellenırzı tesztelı számára egyértelmő, hogy melyik szoftver (kód) elemet kell tesztelnie. Így általában hármas megfeleltetésbe hozhatók a követelmények, a kód elemek és a funkcionális tesztek. A negatív követelmények azonban kihívást jelentenek a funkcionális tesztelés fenti gyakorlata számára. A negatív követelmények olyan dolgokat határoznak meg, amit a szoftvernek nem szabad megtennie, ellentétben azokkal, amelyek azt mondják, hogy mit kell tenni. Negatív EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 18

19 követelményre két példa az alábbi: a szoftver ne legyen érzékeny az SQL beszúrásos támadásra, a szoftver védjen a jelszó feltörési támadás ellen. A negatív követelmények megfeleltetése egy adott kód elemre, illetve egy funkcionális tesztre problematikus lehet. Nyilvánvaló, hogy a példákban említett követelmények nem csak egy helyen kerülnek megvalósításra. Számos esetben a negatív követelmény által megjelenített kockázat csökkenthetı pozitív követelmény (másképpen fogalmazva ellenintézkedés) segítségével. Az SQL beszúrásos támadás kockázata például egy input ellenırzési fehérlista alkalmazásával csökkenthetı, amely nem tartalmazza az ilyen támadás kivitelezéséhez szükséges karaktereket. A jelszó feltörési támadás kockázata pedig például csökkenthetı úgy, hogy elıírjuk a felhasználói fiók letiltását adott számú sikertelen próbálkozás után. Az ilyen pozitív követelmények (ellenintézkedések) már a hagyományos megközelítéssel is tesztelhetık, és ez nem csak a helyes implementációt ellenırzi, hanem a kivédendı kockázat csökkentését is megerısíti. A funkcionális tesztelés kimutathatja egy hiba létezését, de alkalmatlan a hibák hiányának igazolására. E mögött az a gyakorlati probléma áll, hogy a tesztelı csak korlátozott számú tesztesetet próbálhat ki, és lehetséges, hogy ezekben jól mőködik a szoftver, de más esetekben mégsem. Ezért az ellenintézkedések tesztelése nem elég az érintett kockázat kivédésének a garantálására. A funkcionális tesztelésnek számos technikája van, az alábbiakban vázlatosan áttekintjük a legismertebbeket, [Risk-Based and Functional Security Testing] alapján Követelmény alapú tesztelés Egy adott követelményrendszerbıl a tesztek származtatása úgy történik, hogy minden követelményhez tartozik egy teszt készlet. A tesztesetek visszavezetésre kerülnek a követelményekre, hogy biztosítva legyen, hogy minden követelmény lefedésre került. Ez a technika a biztonsági tesztelés egyik alap technikája is. A biztonsági követelmények lefedését egy külön értékelési bizonyítékban [3] el is várja a rendszer integrátortól (lásd [3] ASTE_COV, ) Tapasztalat alapú tesztelés A tesztek származtatása a tesztelı szakértelmén, megérzésein és korábbi tapasztalatain alapul. Ez a teszt fajta csak akkor hatékony, ha képzett és tapasztalt tesztelı hajtja végre, különösen olyan speciális tesztesetek mellett, amelyek nem férnek bele más formális tesztekbe. Ez a fajta tesztelés elınyös lehet, ha a tesztelı közvetett bizonyítékokat fedezett fel egy sebezhetıséggel kapcsolatban, és utána kíván ennek járni. Az értékelık független biztonsági tesztelése során is gyakran alkalmazzák, az értékelı megérzéseinek kivizsgálására. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 19

20 Specifikáció alapú tesztelés Adott egy specifikáció (ami lehet akár egy külsı interfész vagy egy API specifikációja), a tesztesetek pedig ebbıl akár automatikusan is származtathatóak (fıleg egy formális nyelven megírt specifikáció esetén). A biztonsági tesztelés során hasznos lehet olyan esetek tesztelése is, amelyek nem szerepelnek a specifikációban A bemeneti tartomány ekvivalencia osztályokra bontása A bemeneti tartományt részhalmazok összességére (ekvivalencia osztályokra) bontjuk, és az egy osztályba kerülı elemeket azonosnak tekintjük. Minden osztályra reprezentatív teszteket választunk (néha csak egyet-egyet). Az ekvivalencia osztályokra bontás a kimenetekre, az útvonal és a program struktúrára is végrehajtható. Ez a fajta tesztelés fıleg a kezelhetetlenül sok bemenet véges számra csökkentésére alkalmas. Biztonsági tesztelés esetén különösen arra kell ügyelni, hogy az ekvivalencia osztályok biztonsági szempontból hasonló teszteseteket fogjanak át Határérték elemzés A teszteseteket a változók bemeneti tartomány határaihoz közeli értékeibıl válasszuk, abból a megfontolásból, hogy sokszor a bemeneti értékek szélsı értékei közelében lép fel hiba. A biztonsági tesztelésben egy klasszikus példa a határérték elemzésre, amikor egy hosszú bemeneti sztringgel próbálunk potenciális puffer túlcsordulást elıidézni. Ez a tesztelés fajta arra a tapasztalatra épít, hogy a fejlesztık általában a nem biztonságos viselkedést nem látják elıre a határértékek közelében, mivel elsısorban az átlagos értékekre fókuszálnak Hibatőrés tesztelés A határérték elemzés egy speciális esete, amikor a teszteseteket a tartományon kívülrıl választják, ezzel tesztelve a szoftver robusztusságát a nem várt és hibás bemenetekkel kapcsolatosan. Ez hasznos a hibakezelés kipróbálására is. Biztonsági szempontból ez a tesztelés fajta azért fontos, mert az így elıidézett hibák nem biztonságos állapotot eredményezhetnek, akár érzékeny információk felfedésével is járhatnak (például a debug üzenetekben és a memória tartalom listázásában) Döntési tábla alapú tesztelés A döntési táblázatok logikai kapcsolatokat teremtenek a feltételek (pl. bemenetek) és a tevékenységek (pl. kimenetek) között. Tesztesetek származtathatók az összes lehetséges feltétel és tevékenység kombináció szisztematikus számba vételével. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 20

21 A biztonsági tesztelık gyakran olyan feltételekre koncentrálnak, amelyeket nem fednek le a követelmények vagy a specifikációk Állapot alapú tesztelés Modellezzük úgy a programot, mint egy véges állapotterő absztrakt gépet, és különbözı technikákkal válasszunk úgy teszteket, hogy azok lefedjék az állapotokat és az átmeneteket. Ez elsısorban tranzakció feldolgozó, reaktív és valós idejő rendszerek esetében lehet megfelelı. Biztonsági tesztelés esetén gyakran hasznos lehet olyan tranzakciókat kierıszakolni, amelyek nem szerepelnek a magasabb szintő terv dokumentumokban, mivel a sebezhetıségek gyakran akkor keletkeznek, amikor a szoftver egy nem várt állapotba lép Vezérlési folyamat tesztelés A vezérlési folyamat alapú tesztelés célja, hogy egy programban lefedjen minden utasítást, osztályt vagy blokkot (vagy ezek egy meghatározott kombinációját). Egyszerősítsük a programot egy irányított gráffá, és elemezzük a gráfot. Egy példa erre a döntés/feltétel lefedés. Ez a fajta tesztelés általában csak nagyon egyszerő programok esetén kivitelezhetı Adatáramlás alapú tesztelés Címkézzük fel a program vezérlési folyamat gráfját azzal az információval, hogy hogyan vannak a változók definiálva és használva. Használjuk az alábbi definíció/használat párokat (gyakran ezt d/h tesztelésnek is hívják): ha V egy változó és d egy olyan csúcs, ahol a V definiálva van, valamint a h egy másik csúcs, ahol ugyanaz a V használva van, ezen kívül létezik út a d-bıl a h-ba. A cél gyenge vagy potenciálisan helytelen program struktúra (d/h pár) keresése. Az adatáramlás tesztelést gyakran használják alrendszerek közötti interfész tesztelésére Használat alapú és használati eset alapú tesztelés Készítsünk teszteket a termék valóságos használata során mőködési profilok létrehozásával, vagy használati esetek létrehozásával. Esetenként lehetıség van arra, hogy következtetéseket vonjunk le a késıbbi megbízhatóságról a teszt eredményekbıl (feltéve, hogy van egy statisztikailag helyes mőködési profilunk). Ezt úgy tehetjük meg, ha a bemenetekhez valószínőségi eloszlást rendelünk hozzá a tényleges mőködés elıfordulási gyakorisága alapján. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 21

22 Kód alapú tesztelés A vezérlési struktúra, az adatáramlás struktúra, a döntési vezérlés és a modularitás figyelembe vételével lefedjük a kódot. Lefedettség elemzés segítségével felmérjük a teszt teljességét és megfelelıségét. Ez a technika magába foglalja a vezérlési folyamat tesztelést és az adatáramlás tesztelést is Hiba alapú tesztelés Szándékosan hibákat követünk el a teszt során, hogy ezzel teszteljük a program robusztusságát és megbízhatóságát. Itt a kihívást az jelenti, hogy milyen hibákat ejtsünk, és hogy figyeljük meg a hatását. E módszer sikeres használatához megfelelı tapasztalat szükséges Protokoll megfelelıségi tesztelés Használjuk a program kommunikációs protokollját a program tesztelésének közvetlen alapjaként. Ez akkor hasznos, ha a programnak értelmeznie kell valamilyen protokollt. Kombinálva a határérték elemzés és a bemeneti tartomány ekvivalencia osztályokra bontása teszteléssel, ez a módszer igen hasznos web alapú és más internet alapú kódok esetében. A protokoll alapú elemzés különösen fontos webes alkalmazások biztonsági tesztelése során, mivel a távoli támadók számára ezen alkalmazások elérése a legkönnyebben a web protokollokon keresztül lehetséges Terheléses és stressz tesztelés Ennek a tesztelés fajtának a speciális célja annak ellenırzése, hogy egy alrendszer megfelel-e bizonyos teljesítmény követelményeknek (pl. kapacitás és válaszidı). Terheléses és stressz tesztek során a rendszert a maximális tervezett terhelésnek vagy még annál is magasabbnak tesszük ki. Biztonsági szempontból a stresszes helyzetek olyan sebezhetıségekre világíthatnak rá, amelyeket másképp nehéz észrevenni. Sebezhetıségeket olyan mechanizmusok is okozhatnak, amelyeket a szoftver az extrém helyzetek kezelésére használ. Az ilyen mechanizmusok megvalósításakor a fejlesztık gyakran csak az ideális esetekre fókuszálnak, nem törıdve a biztonsággal A biztonsági tesztelés A biztonsági tesztelés célja a szoftver megfelelıségének ellenırzése a biztonsági követelményeknek. Termékek esetén ez alapvetıen a fejlesztı, míg rendszerek esetén a rendszer integrátor feladata és felelıssége. A (termék vagy rendszer) értékelıje ezt a tesztelést ellenırzi, egy mintavételezéssel kiválasztott részét megismétli, illetve független teszteléssel kiegészíti. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 22

23 Fontos megállapítás, hogy nem a biztonsági tesztelés során (akár annak elsı lépésében) kell kockázat elemzést végezni, s ebbıl levezetni a tesztelendı követelményeket. A követelményeket már korábban, más feladatokban (kockázat elemzés, biztonsági elıirányzat készítés) meg kellett határozni. A biztonsági teszteléshez az alábbi feladatokat kell elvégezni: teszt stratégia kidolgozása, amely meghatározza a tesztelési célok eléréséhez szükséges tesztelési tevékenységeket, részletes teszt terv kidolgozása, amely összeszervezi az elkövetkezı teszt folyamatokat, a teszt környezet kiépítése a teszt végrehajtására, a tesztesetek végrehajtása és az eredmények rögzítése, a tesztelés eredményeinek elemzése Teszt stratégia kidolgozása A teszt stratégia célja, hogy világossá váljanak a fı tevékenységek, a meghozott kulcsfontosságú döntések, és a tesztelés során várható kihívások. Ide tartoznak az alábbiak meghatározása: a tesztelés hatóköre, a tesztelési technikák, a lefedettség mérési módszere (mérıszámok, metrikák), tesz környezet, a tesztelést végzık elvárt szakértelme. A teszt stratégia lényegében menedzsment tevékenység. A teszt menedzser (vagy hasonló pozíció) felelıs a teszt stratégia kidolgozásáért és menedzseléséért. A rendszer integrátori és tesztelı csapat tagjai segíthetik a menedzsert a teszt stratégia kidolgozásában. A teszt stratégia elkészítése során figyelembe kell venni, hogy az idı és költségvetési korlátok miatt nem végezhetı el a rendszer valamennyi elemének a tesztelése, ezért egyensúlyba kell hozni a teszt hatékonyságát a teszt eredményességével a rendszer kockázatai alapján. A hatékonyság szintje nyilvánvalóan függ a szoftver használati módjától és a hiba következményétıl. A tervezett tesztelés ezért szelektív, és ez a szelektálás a rendszer kockázatelemzésén alapul. A kockázatok prioritása (vagy sorrendje) alapján kell a tesztelés fókuszát megválasztani, egyszerően azért, mert a nagy mértékben sebezhetı területeket alaposabban kell tesztelni. A teszt stratégia összefoglalja a döntéseket, prioritásokat, tevékenységeket és a tesztelés fókuszát, amelyek mind a szoftver hibák lehetséges következményein alapulnak Teszt terv készítése A teszt terv testesíti meg a teszt stratégiát. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 23

24 A teszt terv kidolgozásának az a célja, hogy megszervezze a következı tesztelési tevékenységeket. Ide tartoznak a teszteléssel lefedendı területek meghatározása, a teszt technikák megvalósítása, tesztesetek és tesztadatok kiválasztása, a teszt eredmények érvényesítése, teszt ciklusok, valamint a belépési és kilépési feltételek a lefedettségi mérték alapján. A teszt terv egy másik célja a tesztelési folyamat elérhetı legjobb automatizálása, mely nem csak megkönnyíti a tesztelést, hanem megismételhetıségét is biztosítja. A teszt tervnek magába kell foglalnia mindannak a magas szintő meghatározását, hogy mely szoftver elem kerül tesztelésre, és milyen módszerek alkalmazásával, továbbá tartalmaznia kell a tesztek általános leírását is, beleértve az elıfeltételeket, a beállításokat, azok végrehajtását, és hogy mit keressünk a teszt eredményekben. A magas szintő áttekintés hasznos a vezetés részére, tervezési és jelentési céllal, míg a részletesebb leírás célja a tesztfolyamat gördülékeny haladását biztosítani. A teszt terv számos elınyt biztosít: Írásban rögzíti az elvégzendı feladatokat. Lehetıséget biztosít a projekt vezetıjének a tervezett tesztek jóváhagyására. /Aki ezzel kinyilvánítja egyetértését a terv elemeivel, s ez a teszteléssel kapcsolatos erıfeszítések támogatását is jelenti./ Elısegíti az elırehaladás mérését. /A tesztelı ennek alapján meghatározhatja, hogy a tervezettnek megfelelıen halad-e./ Lehetıvé teszi a tesztelési prioritások áttekintését. A teszt terv egyik látszólagos hátránya, hogy merevségével és elıre meghatározottságával korlátozhatják a tesztelıt és meggátolhatják abban, hogy ad hoc módon utána járjon olyan megfigyeléseinek és gyanúinak, melyek nem várt felfedezéseket hozhatnak. Ez különösen igaz lehet a biztonsági tesztelések során, amikor a negatív követelmények kimondottan elvárják a tesztelések során tapasztalt ellentmondások további vizsgálatát. A fenti hátrány valóban csak látszólagos, amennyiben a tesztelık eltérhetnek a teszt tervben vázolt egyes tervektıl, ha ezeket a változtatásokat megfelelıen dokumentálják és indokolják. A teszt tervezés iteratív tevékenység. Maga a teszt folyamat is generál olyan információt, amely felhasználható további tesztek tervezésére. A teszt terv elkészítése során figyelembe kell venni a rendszer különbözı komponensei közötti függıségeket, a szükségessé váló tesztismétlések minimalizálása érdekében. Ideális esetben úgy lehet meghatározni a komponensek tesztelési sorrendjét, hogy minden modul a tıle függı modul elıtt kerül tesztelésre. A gyakorlatban ez nem mindig ilyen egyszerő, de a tervezéskor mégis ésszerő figyelembe venni ezeket a függıségeket. A teszt tervnek ki kell dolgoznia a végrehajtandó teszteseteket. A tesztesetek tipikusan információt tartalmaznak a teszt elı- és utófeltételeirıl, a tesztek felépítésére és lebontására vonatkozó adatokról, és arról, hogy hogyan kell a teszt eredményeket kiértékelni. A teszteset meghatározza a teszt feltételt is, amely a vizsgált eset aktuális állapota, például a tesztelı olyan teszt feltételt készít, amely a szoftver válaszát vizsgálja. Egy tipikus biztonsági teszt terv a következı elemeket tartalmazza: EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 24

25 a) Cél b) A vizsgált szoftver áttekintése ba) Szoftver és komponensek bb) Teszt határok bc) Teszt korlátozások c) A kockázat elemzés eredményeinek (a meghatározott biztonsági követelmények) összegzése d) Teszt stratégia da) Feltételezések db) Teszt megközelítés dc) Nem tesztelendı elemek e) Teszt követelmények ea) Telepítési/konfigurálási teszt követelmények eb) Felhasználói dokumentációra vonatkozó követelmények ec) Személyi követelmények ed) Berendezés és hardver követelmények f) Teszt környezet g) Teszteset specifikációk ga) Egyedi teszt azonosító gb) Követelmény megfeleltetés (melyik követelményre irányul a teszteset) gc) Input specifikációk gd) Output specifikációk (várt eredmények) ge) Környezeti elvárások gf) Függıségek a tesztesetek között h) Teszt automatizálás és teszttermék ha) Teszttermék architektúra hb) Tesz eszközök hc) Teszttermék i) Teszt végrehajtás ia) Teszt belépési feltételek ib) Teszt eljárások (speciális követelmények, eljárás lépések) ic) Teszt ütemezés id) Teszt kilépési feltételek j) Teszt menedzselés terv (a terv folyamatos változtatására, kezelésére) k) Fogalom-meghatározások és rövidítések. Ugyanakkor a teszt tervezés egy folyamat. Gyakran létezik egy fı teszt terv, amely az egész rendszer tesztelési folyamatát körvonalazza, s ezt különbözı teszt fázisok, részletesebb teszt tervek egészítik ki, melyek nem feltétlenül a teljes rendszerre, esetenként csak egyes komponensekre vagy alrendszerekre vonatkoznak. Egy fı teszt terv körvonalazhatja például az alábbiakat: A modul (függvények, metódusok, osztályok) teszteket a fejlesztık, a komponens (könyvtárak, futtatható állományok) teszteket a teszt mérnökök végzik el. Ezután következnek az alrendszer szintő integrációs tesztek speciális teszt környezetben, majd a rendszer szintő tesztek szimulált valós környezetben. Végül speciális eszközök felhasználásával egy stressz tesztelés zárja a biztonsági tesztelést. Minden teszt fázisnak lehet saját részletes teszt terve. EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.docx 25