5. fejezet - Ügyviteli védelem

Az előző fejezetekből már kiderül, hogy az adatok védelme nagyon szerteágazó probléma. Otthoni számítógépeinket is óvni kell a különböző veszélyforrásoktól; nem visszük vizes helységbe, úgy helyezzük el, hogy az áramellátás és a hálózati kapcsolat folyamatos legyen; jogtiszta szoftvereket használunk, és hatékony eszközöket telepítünk a kártékony programok ellen. Óvjuk az általunk készített dokumentumokat az illetéktelen hozzáféréstől.

A vállalatoknak, az állami és önkormányzati szervezeteknek is egyre növekvő feladatot jelent az adatok védelme. Kis szervezeteknél elegendő a szabályok szóban történő ismertetése. Nagy, sok dolgozót alkalmazó szervezeteknél ez ma már nem elegendő. Ilyen szervezeteknél írásban kell megfogalmazni az adatok védelmével kapcsolatos szabályokat. Az ügyviteli védelem az informatikai rendszert üzemeltető szervezet ügymenetébe épített védelmi intézkedések, biztonsági szabályok, tevékenységi formák együttese. A védelemnek ezt a formáját adminisztratív védelemnek is szokták nevezni. A szabályozás alapját a vonatkozó törvények és jogszabályok jelentik, de ezeket a konkrét tevékenységnek megfelelően pontosítani kell.

Az ügyviteli védelemnek két szintjét különböztethetjük meg, mégpedig a stratégiai, tervezési szintet és a mindennapi gyakorlatot érintő és szabályozó szintet. Előbbit az Informatikai Biztonsági Koncepció (IBK), utóbbit az Informatikai Biztonság Szabályzat (IBSz) tartalmazza. A szabályozás két formája szorosan összefügg egymással és a szervezet más szabályzataival. Fentebb már rámutattunk, hogy kisebb szervezeteknél nem is foglalják írásba a követendő szabályokat. Nagyobb szervezeteknél is összemosódhat a két szabályozás, esetleg az IBSz impliciten vagy expliciten tartalmazza a stratégiai elképzeléseket. Ez a megoldás nagy szervezeteknél azért nem célszerű, mert az IBSz-t sokkal gyakrabban kell a napi igényeknek megfelelően módosítani, mint az IBK-t.

A szabályozás - jellegénél fogva – uniformizál, csökkenti az egyéni kreativitást, kisebb-nagyobb kényelmetlenséget okoz. Előírhatják például, hogy kik jogosultak a hardver- vagy szoftverhibák elhárítására. Ilyenkor az ügyintézőnek meg kell várnia az illetékes kolléga intézkedését, ami esetleg hosszabb időt is igénybe vehet, és addig nem tudja végezni a saját munkáját. Még akkor is így kell tennie, ha tudja, hogyan háríthatja el a hibát. A szabályozás a kényelmetlenségek mellett biztonságot is nyújt a dolgozóknak. A szabályok betartása esetén nem lehet őket felelősségre vonni. Ha nem szabályozzák megfelelően az ügyviteli védelmi megoldásokat, akkor hiba esetén a rendszergazdákra hárul a felelősség.

A sorok írójával, aki akkor a DE Informatikai Intézetének igazgatója volt, tanulságos eset történt néhány évvel ezelőtt. Egy verőfényes tavaszi délutánon az irodámban ültem és már készültem a napi munka befejezésére, amikor felhívott az ügyeletes rektorhelyettes és közölte, hogy nem hagyhatom el az irodát és senkivel sem beszélhetek, amíg a rendőrség meg nem érkezik hozzám. A „vendégek” érkezéséig eltelt néhány percben lázasan gondolkodtam, hogy milyen törvénytelenséget követtem el, de semmi sem jutott eszembe. A nyomozók a számítógépeink elhelyezéséről és az általunk használt IP címekről érdeklődtek. Többszöri kérdésükre sem tudtam kielégítő választ adni, hiszen az IP címek adminisztrálásával én nem foglalkoztam. Miután sikerült ezt megértetnem velük, engedélyezték a Rendszergazda Csoport vezetőjének bevonását a kihallgatásba. Ő már érdemi válaszokat tudott adni és átadta a keresett számítógépet is. A nyomozás nálunk jegyzőkönyv felvételével befejeződött, de az egyetemen még késő éjszakáig folytatódott.

Kiderült, hogy a nyomozók – nemzetközi akció keretében – egy fájlcserélő hálózatra csaptak le. Egyetemünkön a nagy sávszélességet kihasználva néhány tárolót helyeztek el. A hálózatnak ebben segítséget nyújtott néhány kolléga, akik sajátjukként helyezték el a számítógépeket a szerverszobában és felügyelték azok működését. A szabályozás hiányosságát kihasználva csak a rendszergazdáktól kértek baráti segítséget a gépek elhelyezésére. Az esetből gyorsan levontuk a tanulságokat és szigorúan szabályoztuk a berendezések be- és kihozatalát az épületből, valamint azt, hogy milyen eszközöket és milyen engedélyekkel lehet a szerverszobában elhelyezni.

Végezetül felhívjuk a figyelmet arra, hogy a legkörültekintőbb szabályozás sem lehet eredményes a dolgozók együttműködése nélkül. Csak a jól felkészült és a szabályokat tudatosan alkalmazó dolgozók képesek az elveket a gyakorlatba átültetni. Az informatikai biztonsági követelmények a technológia és szervezet fejlődése miatt folyamatosan változnak, amelyekre a munkatársakat nemcsak a betanulási időszakban, hanem rendszeres képzéssel kell felkészíteni.

5.1. Informatikai Biztonsági Koncepció

Az Informatikai Biztonsági Koncepció a szervezet felső vezetésének informatikai biztonsággal kapcsolatos stratégiai elképzeléseit foglalja össze. A koncepció tartalmazza a szervezet informatikai biztonságának követelményeit, az informatikai biztonság megteremtése érdekében szükséges hosszú távú intézkedéseket, ezek kölcsönhatásait és következményeit.

A koncepció tartalma függ a szervezet tevékenységétől és nagyságától, de fontosabb tartalmi összetevőit meg tudjuk határozni:

  • a védelmi igény leírása: jelenlegi állapot, fenyegetettségek, fennálló kockázatok,

  • az intézkedések fő irányai: a kockázatok menedzselése,

  • a feladatok és felelősségek meghatározása és felosztása a védelmi intézkedésekben,

  • idő- és költségterv a megvalósításra és időterv az IBK felülvizsgálatára.

A koncepció több lépésben készül, amelynek főbb szakaszai az alábbiak:

1. Védelmi igény feltárása: Ebben a szakaszban választjuk ki a szervezet működése szempontjából lényeges informatikai rendszereket, informatikai-alkalmazásokat, amelyek értékük alapján érdemesek a védelemre. Ide tartoznak a vállalat szerverei, és tárolóegységei, a lokális hálózata aktív és passzív elemei. Meg kell vizsgálni a vállalat tágabb környezetét: a világhálón való megjelenését, a beszállítókkal és alvállalkozókkal szembeni követelményeket. Át kell gondolni az aktuális, a közép és esetleg a hosszú távú technológiai és szervezeti fejlesztéseket és változtatásokat.

2. Fenyegetettség elemzés: Feltárjuk azokat a biztonságot fenyegető tényezőket, amelyek az első szakaszban kiválasztott alkalmazásokra veszélyesek lehetnek, kárt okozhatnak. A lehetséges veszélyforrásokat a 3. fejezetben foglaltuk össze. Itt kell vizsgálni az informatikai rendszer gyenge pontjait is, ahol a rendszer a külvilággal érintkezik.

Egyre több tanulmány hívja fel a figyelmet arra, hogy az informatikai rendszerek biztonságát elsősorban nem külső támadók, hanem a belső munkatársak fenyegetik. Meg kell tehát határozni az eszközökhöz és az adatokhoz való hozzáférés irányelveit. Mely munkahelyeken lehet saját tárolókapacitással és kimeneti lehetőséggel – pl. USB port - rendelkező számítógépeket elhelyezni. Kik és milyen mértékben férhetnek hozzá a világhálóhoz, illetve milyen jogosultsággal és módon lehet hozzáférni külső számítógépről a vállalat erőforrásaihoz. A hozzáférések naplózásának módját is meg kell határozni.

3. Kockázatelemzés: Ebben a szakaszban azt értékeljük, milyen káros hatása lehet a fenyegető tényezőknek az informatikai rendszerre. Meghatározzuk a lehetséges károk bekövetkezésének gyakoriságát, valamint a kárértéket és ennek függvényében a szükséges védelem technológiáját és mértékét.

4. Kockázat menedzselés: Kiválasztjuk a fenyegető tényezők elleni intézkedéseket és azok hatását értékeljük. Megvizsgáljuk, hogy az egyes intézkedések mennyire hasznosak és milyen költséggel járnak. Ide tartozik a veszélyforrások elleni védekezés módjainak meghatározása, intézkedési tervek. Nemcsak az előre jelezhető veszélyekre és kockázatokra kell felkészülni, hanem a váratlan helyzetekben teendő lépéseket is meg kell határozni. Nagyon fontos a felelősök kijelölése és felelősségi körük definiálása. Időtervet kell készíteni az intézkedések bevezetésére és az intézkedések hatása felülvizsgálatának ütemezésére. Egyetlen stratégia sem él örökké, különösen igaz ez az informatikával összefüggő stratégiára. Előre meg kell tehát határozni az IBSz felülvizsgálatának az ütemezését.