2. Követelmények - SoosSarolta/ITSecHW_Virucid GitHub Wiki

Mielőtt belekezdenénk az online webáruház implementálásába, első lépésként szükség van a követelmények meghatározására; ideértve a funkcionális és biztonsági előírásokat is. A funkcionális követelményeket UML use-case diagramok segítségével, a biztonsági követelményeket pedig az ún. Threat, Risk, Vulnerability Analysis módszerrel dokumentáljuk.

Mivel a rendszernek többféle felhasználója (regisztrált vásárlók, adminisztrátorok) is lesz, számos alkalmazási szcenárióra kell felkészíteni, melyeket az 1. ábrán foglaltuk össze.

A szoftverrel szemben támasztott funkcionális követelmények az alábbiak:

• A felhasználók számára lehetővé kell tenni különböző CAFF fájlok feltöltését, letöltését; a közöttük való keresést
• A felhasználók számára lehetővé kell tenni megjegyzés hozzáfűzését az egyes CAFF fájlokhoz
• Az adminisztrátorok feladata a webshop üzemeltetése, adatok, illetve felhasználói információk módosítása és törlése
• A program távolról is elérhető kell, hogy legyen

A rendszerben található távoli szolgáltatásnak képesnek kell lennie a CAFF fájlformátum feldolgozására, illetve abból egy előnézet generálására a webshop-ban való megjelenítéshez.

1. ábra: A rendszer felhasználási szcenáriói

A funkcionális követelmények segítségével a rendszert és annak környezetét nagyvonalakban fel tudjuk vázolni, ahogy azt a 2. ábra is mutatja. Az online áruházat regisztrált vásárlók és adminisztrátorok használhatják, velük kerülhet interakcióba a rendszer. Mivel a tőlük érkező kéréseket, a viselkedésüket nem tudjuk kontrollálni, ezért a velük történő interakció bizalmi kérdéseket vet fel. Ezen kérdéskörök az ábrán piros szaggatott vonallal vannak jelölve. A rendszer működtetéséhez szükség lesz a felhasználók (adminisztrátorok, vásárlók) adatainak, illetve az áruházban vásárolható egyedi formátumú animált képek tulajdonságainak tárolására is. A tárolt adatok közötti kapcsolatok létesítését is meg kell valósítanunk: a felhasználók és a feltöltött képeik, továbbá a CAFF fájlok és a felhasználók által hozzájuk fűzött megjegyzések között van összeköttetés. Az online áruház, mint szoftver, biztonsági követelményeit hat nagy kategóriába sorolhatjuk: CIA és AAA. Az egyes kategóriákhoz az alábbi követelményeket határozhatjuk meg:

2. ábra: Az online áruház és környezete

Bizalmasság (confidentiality)

• Az online áruház regisztrált felhasználóinak személyes adatait csak ők maguk, illetve az adminisztrátorok ismerhetik meg.
• Az adminisztrátorok minden felhasználó személyes adatait megismerhetik, mivel ezeket módosítani is tudniuk kell.
• A felhasználók csak a saját (múltbéli) vásárlásaikat láthatják.
• A felhasználók bármely más felhasználó által bármely CAFF fájlhoz írt hozzászólást megtekinthetik.

Integritás (integrity)

• A regisztrált felhasználók csak saját személyes adataikat módosíthatják.
• Csak regisztrált felhasználók tölthetnek fel / le CAFF fájlokat.
• Csak regisztrált felhasználók fűzhetnek megjegyzést CAFF fájlokhoz.
• Csak az adminisztrátorok jogosultak bármely felhasználó adatainak módosítására, illetve a felhasználói fiók törlésére.

Elérhetőség (availability): A mi esetünkben ezen követelménykategória nem releváns, semmilyen tevékenység nincs időszakhoz kötve.

Autentikáció (authentication)

• A regisztrált felhasználók csak bejelentkezés után írhatnak megjegyzéseket, tölthetnek fel, illetve vásárolhatnak fájlokat.
• Adatok módosítását és törlését csak adminisztrátori jogosultsággal lehet végrehajtani.
• A regisztrált felhasználók csak saját nevükben tölthetnek fel CAFF fájlokat.

Autorizáció (authorization)

• A CAFF fájl feltöltése, vásárlása, illetve megjegyzések írása szerepkörhöz kötött tevékenység.

Auditálás (auditing)

• A felhasználók, illetve adminisztrátorok tevékenységét naplózni kell.

A követelmények ismeretében meghatározhatjuk a megvalósítandó biztonsági célokat. Ilyen cél például a biztonságos adattárolás, a naplózás, a szerepkör alapú hozzáférés-védelem, valamint a felhasználói fiókok menedzsmentje.

3. ábra: Felhasználóhoz köthető use case-k

A threat assessment két nagyobb elemből áll: assetek azonosítása és az assetekre leselkedő veszélyek (threat) azonosítása. Az assetek azonosításához iteratívan kell elemeznünk a rendszer use case-eit, figyelembe véve a biztonsági követelményeket is. Ezek a követelmények a 2.2-es pontban találhatók.

A kezdeti adatfolyam diagramot kibővíthetjük további komponensekkel az assetek megállapítása és elemzése folyamán. Ehhez egyesével elemeznünk kell az 1. ábrán látható use-case-eket. Három assetet különböztethetünk meg:

• emberi assetek
• fizikai assetek
• logikai assetek

Kezdjük az emberi assetekkel. Egy ilyen assetünk van: ezek a felhasználók, hiszen az adminisztrátor is csak egy különleges jogokkal rendelkező felhasználó a rendszerünk szempontjából. A felhasználók négy különböző use-case-ben jelennek meg: CAFF fájl feltöltése, CAFF fájl letöltése, CAFF fájlok közti keresés, és megjegyzés fűzése CAFF fájlokhoz. Ezen use-case-ek a 3. ábrán láthatók. Az adminisztrátoroknak képesnek kell lenniük továbbá a CAFF fájlok törlésére, és a felhasználók adatainak módosítására, ill. törlésére. Ezen use-case-eket az 5. ábráról olvashatjuk le. A biztonsági követelmények kielégítéséhez csak egy további use-case-re van szükségünk: a bejelentkezésre.

A rendszer üzemeltetéséhez szükségünk lesz fizikai assetekre is. A szoftverek futtatásához kelleni fognak szerverek, melyek kezdeti számának pontos meghatározásához és későbbi skálázhatóságához figyelembe kell vennünk a felhasználók számát. Távoli elérést biztosítandó hálózati eszközökre is szükségünk lesz. Végül pedig a felhasználói elvárással arányos méretű adatbázist is biztosítanunk kell.

A logikai assetek meghatározásához elemeznünk kell a use-case-ek által megfogalmazott adatfolyamokat. A feladat specifikálja, hogy a rendszerhez távoli elérést kell biztosítsunk, ezért az alkalmazás webes felülettel fog rendelkezni. Ezt a 4. ábra webszerver komponense reprezentálja. Az autentikációt megvalósító komponens hivatott a bejelentkezés elvégzésére. Itt a felhasználónak vagy az adminisztrátornak meg kell adnia a személyes adatait, melyeket egy adatbázisban fogunk eltárolni, és kezelésükre egy autentikációs adatkezelő komponenst implementálunk. A CAFF fájlokat szintén adatbázisban tároljuk. Ezzel az adatbázissal kommunikál a CAFF fájlkezelő komponens, amely az alapvető műveletek végrehajtásáért felelős (feltöltés, letöltés, keresés, megjegyzés hozzáfűzése). Ezeken túl adminisztrátori funkció a CAFF fájl törlése, ill. a felhasználói adatok módosítása, törlése. A megállapított use-caseket az 5. ábra mutatja. Ahhoz, hogy meg tudjuk állapítani, hogy az adott felhasználó milyen tevékenységeket végezhet, szükségünk van egy autorizációs komponensre is. Ez a komponens az adatbázisból fogja kiolvasni a felhasználó adatait, és az így kapott információ segítségével engedélyezi, vagy elutasítja a műveletet.

Az assetek által meghatározott végleges adatfolyam-diagram a 4. ábrán látható. A felhasználók autentikációs adatait védenünk kell a szivárgás és az illetéktelen hozzáférés ellen, ezért ezeket titkosítanunk kell tárolás, illetve átvitel során. A jelszavak tárolására további biztonsági lépéseket tehetünk (hashelés, sózás). Végül pedig jelszó policy-t vezethetünk be, mellyel a jelszavak erősségét; így további biztonságosságát növelhetjük.

4. ábra. A rendszer adatfolyam ábrája

A támadó modell kidolgozásához figyelembe kell vennünk a rendszerkomponensek potenciális gyengeségeit, valamint hogy ezeket egy támadó milyen módon lehet képes kihasználni. Egy jó kiindulási pont a STRIDE keretrendszer, így ennek elemein megyünk végig először, egy-egy példát említve minden támadási formához:

• Spoofing (megszemélyesítés): Egy felhasználó megpróbál másnak a nevében CAFF-fájlt feltölteni a weboldalra, vagy megjegyzést fűzni egy képhez.
• Tampering (hamisítás): A támadó igyekszik megváltoztatni egy animált képet, amit éppen valaki megvásárolt és éppen le szeretne tölteni.
• Repudiation (tevékenységek letagadása): Egy felhasználó arra próbál hivatkozni, hogy valójában nem töltött le egy képet.
• Information disclosure (információ szivárgás): Hétköznapi felhasználókról és adminisztrátorokról információt (jelszavakat) próbál kideríteni egy támadó.
• Denial of Service (szolgáltatás-megtagadás): Olyan fájlt tölt fel egy felhasználó, amitől összeomlik / elérhetetlenné válik a rendszer.
• Elevation of privilege (jogosultsági szint emelése): Egy felhasználó megpróbál adminisztrátori jogosultságokat szerezni, hogy feltöltött animált képeket töröljön, illetve felhasználói adatokat módosítson, és/vagy töröljön.

A felsorolt esetek összevethetők az adatfolyam diagram különböző részleteivel. Megszemélyesítés azért lehetséges, mert több fajta felhasználónk is be tud jelentkezni különböző jogosultsági körökkel. Hamisítás a CAFF fájlkezelőhöz intézett kérések során jöhet szóba. Tevékenységek letagadása szintén ennél a lépésnél történhet, amennyiben el lehet érni, hogy a tevékenységről való visszajelzést meg tudja gátolni a támadó, hogy elérje a webszervert és benne legyen a saját azonosítója. Információ szivárgás akkor történhet, ha felhasználói adatokhoz tud külső vagy belső személy engedély nélkül hozzáférni. Ezt az autentikációs komponens kijátszásával próbálhatja meg elérni. Szolgáltatás-megtagadást a CAFF fájlkezelőbe való feltöltéssel érhet el egy támadó; jogosultsági szint emelését pedig az autorizációs komponens megkerülésével lehet elérni.

5. ábra. Adminisztrátorhoz köthető use case-ek

A biztonsági követelmények kielégítéséhez többféle biztonsági funkcionalitást kell megterveznünk, implementálnunk és tesztelnünk. A szükséges biztonsági funkcionalitásokat a biztonsági követelmények és a különböző támadási szcenáriók vizsgálatával kaphatjuk meg.

Mindenekelőtt a webáruház használatához autentikációt kell megvalósítanunk. Mivel a tervezett rendszerrel böngészőn keresztül léphetnek interakcióba a felhasználók, érdemes jelszó alapú autentikációt választani.

A felhasználókhoz kétféle szerepkört tudunk meghatározni: regisztrált felhasználó és adminisztátor. Az egyes tevékenységek elvégzése előtt ellenőriznünk kell, hogy az adott user jogosult-e, pl. megjegyzést fűzni CAFF fájlokhoz. Ehhez szerep alapú autorizációs mechanizmust kell implementálnunk.

Az adminisztrátorok tevékenysége a felhasználói adatok módosítására és törlésére, valamint CAFF fájlok törlésére terjed ki. Szükséges azonban korlátozni őket további, csak regisztrált felhasználó számára engedélyezett tevékenységek tekintetében: CAFF fájlok fel- illetve letöltésében, valamint megjegyzés írásában. Hasonlóan, regisztált felhasználók nem hajthatnak végre admin-specifikus műveleteket, vagyis nem módosíthatják vagy törölhetik más felhasználók fiókjait, fájljait vagy megjegyzéseit. A rendszer felhasználóinak elszámoltathatóságában kiemelt jelentősége van a tevékenységek naplózásának.

A felhasználók személyes adatait és az autentikációhoz szükséges jelszót védenünk kell szivárgás és illetéktelen hozzáférés ellen. A személyes adatokat titkosítanunk kell tárolás és átvitel során, a jelszavakat pedig biztonságosan kell tárolnunk (hashelés + sózás).