Hétpecsét Információbiztonsági Egyesület – Információvédelem menedzselése
28 perc olvasás
A Hétpecsét Információbiztonsági Egyesület 68.fórumát tartotta 2015.novemberében.Vezető témája az információvédelem menedzselése volt.
A Hétpecsét Információbiztonsági Egyesület 68.fórumát tartotta 2015.novemberében.Vezető témája az információvédelem menedzselése volt.
Tarján Gábor alelnök az információvédelem aktualitásaival nyitotta meg a találkozót, említés került az egyesület megújuló honlapja is.
dr. Szabó István, egyetemi docens (ELTE), a Hunguard Kft. munkatársa a 2013. évi 50.törvény végrehajtási rendelete alapján folytatott biztonsági tanúsítások tapasztalatairól szólt előadásában. Az előadó egyetemi munkája során kriptográfiát, adatvédelmet, információvédelmet oktat, emellett végzi szakértői tevékenységét.
Az előadás témakörének jogszabályi környezetét az un. közműtörvények alkotják.
A közműtörvények szó szerint azonos megfogalmazásban, különböző paragrafusokban kimondják; a számlázó rendszereket tanúsítani kell, a zártság követelményeinek megfelelően, a 2013. évi 50. (L.) törvény rendelkezései szerint. Az egyedi számlázó szoftverek esetében a vizsgálatnak ki kell terjednie a szoftverek forráskód szintű elemzésére is. A szakmai elemeket a törvény 2013-ban megjelent NFM rendelete tartalmazza. Ez a több mint 60-oldalas rendelet több száz elvárást fogalmaz meg.
A rendelet forrása az egyre szélesebb körben elfogadott, óriási tapasztalatokra épülő dokumentum, a NIST 800-53. Ez részletesen tartalmazza az elvárásokat.
http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800-53-rev4-ipd.pdf
Ennek létezik további 113, NIST 800. sorozatú támogatott dokumentuma, és 67 vonatkozó szabvány-hivatkozása. http://whatis.techtarget.com/definition/NIST-800-Series
A jelen témakörben a szakma számára legfontosabb a 800-53/a jelű, részletes módszertani leírás az összes, 18 intézkedés-családban 300 intézkedéshez. Közülük is kiemelhető a kockázat-elemzéssel, ill. az információbiztonság mérésével foglalkozó dokumentum.
2015-ben megújították az 1977-es rendeletet, s kiadták a 41/2015-ös BM rendeletet, amely több mint 95%-ában, szó szerint megegyezik az előzővel. Kimondja, októberig a korábbi rendelet is használható bizonyos esetekben.
A 800-53 dokumentum esszenciáját jelenti nagyon sok más dokumentumnak, szerepel pl. az ISO 27.000/1 felvezetésében is. Megfelel a termékértékelés területén az egész világon elfogadott Common Criteria módszertannak, ill. az ISO 15.408-nak is.
http://sirkan.iit.bme.hu/~kondor/SZTAUDIT/CC1ff.pdf
http://wiki.hup.hu/index.php/Common_Criteria
Az értékesítési és tanúsítási folyamat értelmezésére, előzetes információk alapján, első lépésként egy értékelő munkacsapat áll össze. A szakértők többsége auditor, etikus hacker végzettségű, szoftver-tesztelői végzettségű szakemberek, akik elvégzik a vizsgálatot.
Ennek során találhatnak olyan kritikus maradvány-kockázatokat, amelyek alapján nem állítható, hogy a rendszer zárt, pl. az internetről be lehet hatolni, ilyenkor nem adható ki a tanúsítvány.
Az esetek túlnyomó többségében találnak ilyet. Ilyenkor egy Observation Report készül visszajelzésként, megjelölve, mi az ami nem megfelelő, mit kell kijavítani a vizsgálatok folytatásához.
Általában 2-3 ilyen riport fordul elő szervezetenként. Ezeket mindig újra kell értékelni, így egy ilyen vizsgálat egy-két hónapig is eltart. Amikor már nem található kritikus maradvány-kockázat, akkor fejeződik be az értékelési folyamat. A folyamatot az akkreditáló testület is ellenőrzi, s az egész eljárást egy tanúsítási folyamat zárja le, az értékelés kontrolljaként. Ennek eljárásrendjét az ISO 17065 határozza meg. Természetesen, ezek után is maradnak enyhe megfelelőségi hibák, amelyeket érdemes kijavítani a következő felülvizsgálatra.
Ezek a tapasztalatok száznál több szervezetnél végzett vizsgálat során gyűltek össze.
A legtöbb szervezet a 2013. évi 50. törvény szerinti eljárás révén határozza meg saját biztonsági rendszerének érzékenységi osztályát. Mindez 95 követelmény vizsgálatát jelenti. A vizsgálat első lépéseként megvizsgálják, van-e az adott követelmény teljesülését érvényre juttató intézkedés. Ez jelenti a vizsgálatok elenyészően kisebb részét, a nagyobb rész azt vizsgálja, milyen hatásfokú ez az intézkedés, eléri-e eredeti célját. Amennyiben találnak kritikus maradvány kockázatokat, ezeket ki kell javítani.
A kritikus maradvány-kockázatok döntő többsége a sérülékenység-vizsgálat (penetration test) nyomán kerül felszínre, amikor black-box teszteket és egyéb célzott teszteket végeznek, de a forráskód-elemzés és egyéb hiányosságok is hozhatnak elő kritikus maradvány-kockázatot.
Tapasztalat szerint, az internethez kapcsolódó IT rendszerek 95%-ában a külsődleges sérülékenység teszt kritikus maradvány-kockázatot tárt fel. További tapasztalat, hogy ezek a feltárt kritikus maradvány-kockázatok minimális erő-ráfordítással javíthatók beállításokkal, portok letiltásával, felesleges szolgáltatások letiltásával.
A forráskód-elemzést nem sok szervezetnél kellett elvégezni, mert a legtöbb nagy rendszer, mint az SAP, Oracle, stb. saját sérülékenységi adatbázissal dolgozik, s ezekre létezik folyamatos frissítés. Itt a rendszeres frissítés végrehajtása, ill. a megfelelő beállítások számítanak kritikus tényezőnek.
Ahol viszont saját fejlesztésű, vagy egyedi szoftvereket használtak, ott sokszor fordultak elő súlyos hibák. Tapasztalat szerint, a hazai biztonságos szoftverfejlesztés oktatásában eléggé el vagyunk maradva. A fejlesztők a biztonsági szempontokat vagy nem ismerik, vagy nem tartják be. Mindezen hiányosságok következtében a hackerek könnyedén támadhatták az érintett rendszereket.
Egyéb elvárások terén is sok hiányosság tapasztalható, a szabályzattól a felelősségi rendszer kialakításáig, elavult szoftverek, pl. XP használatáig. Olyan rendszereket működtetnek, ahol nem biztosítható az újonnan feltárt gyengeségek javítása. A legtöbb helyen formálisan nagyon sok eljárást teljesítettek, de ezek érvényesítésére nem kellő erősségű megoldásokat alkalmaztak.
Példaként említhető; az adathordozók védelmét szolgáló intézkedések körében az adathordozók törlése, ill. az azonosítás és hitelesítés témakörben a jelszó alapú hitelesítés megoldása sokszor nem megfelelő.
A rendelet előírja, adathordozók törlésekor a helyreállíthatatlanságot biztosító törlési techniká(ka)t és eljárás(oka)t kell alkalmazni, ugyanezt az eljárást kell alkalmazni kivonáskor, szervizbe szállításkor, vagy más munkatársnak való átadáskor.
Merevlemezek és pendrájvok esetén mindezt általában szabályozzák is a vizsgált szervezetek. Ezzel a témakörrel a 888.sz., nagy részletességű támogató dokumentum foglalkozik, felsorolva az alkalmazandó adathordozókat.
Az intelligens nyomtatók, másoló-, és faxgépek is sokszor tartalmaznak érzékeny adatokat, nem is beszélve a mobiltelefonokról és más mobil eszközökről. Az előírások betartását nem csak szabályzással, de megfelelő, eszközre szabott törlési technikával ezekre is biztosítani kell.
A 77., és 41. sz. rendelet hasonló módon rendelkezik a jelszó alapú hitelesítés elvárásairól. A legtöbb szervezet meghatározza a jelszó-policy-t; a karakterek számát, néhány szervezetnél ezt ki is kényszerítik, a rendeletnek megfelelően. A vonatkozó dokumentum kimondja; meg kell határozni a jelszavak maximális és minimális élettartamát.
A szervezetek a maximális időtartamot általában 3-6 hónapban határozzák meg. Ezen idő után cserélni kell a jelszavakat. A jelszavak minimális érvényességi idejét viszont sehol sem szabályozták.
A dokumentum előírásai szerint a jelszavakat titkosítási védelemmel kell ellátni. Sajnálatos módon, sok esetben tapasztaltak nyíltan tárolt jelszavakat, vagy nem kellő erősségű kriptográfiai védelmet.
A 800. sorozatban a 63/2 foglalkozik a jelszavakkal. A szervezetek a gyakorlatban általában 8 karaktert alkalmaznak, ennek az entrópiája 30, azaz 2-nek a 30. hatványának megfelelő próbálkozással megfejthető a jelszó. Ezért a dokumentum kiegészítő intézkedéseket ír elő, különösen arra az esetre, amikor a 94 karaktert tartalmazó ABC-ből kis számú alkotóelemet választunk ki jelszavunkhoz.
Korlátozni kell, vagy a jelszó-kipróbálások számát, vagy a próbálkozások közötti időt.
Biztonságos kriptográfiai függvénnyel kell dolgozni (MB4, MB5 nem elegendő), így ha a támadó hozzá is tud férni egy tárolt jelszó-képhez, akkor se okozhasson kárt.
A felhasználó által megadott jelszavakat a rendszernek ki kell egészítenie véletlen elemekkel, ezzel biztosítva a védelmet a tárolt jelszó-adatbázisokkal, pl. szivárvány táblákkal támadó behatolók ellen.
A mai szabványok ingyenesen elérhetők a neten, s tartalmazzák a jelszó tárolásnál alkalmazható titkosító függvényeket.
A vizsgált rendszerek biztonsági szintjét három kategóriába sorolták; megkülönböztetve alacsony, közepes, magas és enyhe nem-megfelelőségű maradványkockázatokkal, amelyeket ajánlatos javítani. Különösen elvárt, hogy a magas kockázatúakat a szervezet javítsa.
A tanúsítási folyamat végén, amikor már nem maradt kritikusnak minősített maradvány-kockázat, a maradvány kockázatok mintegy 15%-a az adminisztratív védelmi kategóriába volt sorolható, a fizikai kategóriába nagyon kevés, a logikai-technológiai védelembe pedig 82% esett. Utóbbiakban a konfiguráció-kezelés, az azonosítás kezelés, naplózás-elszámoltathatóság volt többségben. A legkevesebb nem-kritikus maradvány-kockázatot az elektronikus hírközlési törvény alá tartozó szervezetek mutatták. Átlag 20-40 kockázat volt a jellemző érték. Mindenképpen szem előtt tartandó, hogy az alacsonyabb minősítésű maradvány-kockázatokat is érdemes javítani.
Egy-egy értékelés alá vont rendszer az értékelés után egy hónappal már nem ugyanaz a fejlesztések, frissítések, vagy éppen kritikus frissítések elmaradása miatt. Új munkatársak lépnek be, új szabályzatok lépnek érvénybe, stb. Az egész rendszer folyamatosan, dinamikusan változik. Tapasztalat, hogy az első tanúsítás után nagyon sokan megszívlelik a tanúsítási szerződésben leírt, a maradvány-kockázatokról szóló megállapításokat, és kijavítják a hibákat.
Az ismételt felülvizsgálat megállapította, hogy a módosítások miatt új kritikus maradvány-kockázatok (5) jelentek meg, ami miatt a rendszer zártsága nem volt tartható. Emiatt ezeket a kockázatokat is javítani kellett. Az össz-kockázat végül az első felülvizsgálat után mérthez képest közel 50%-os mértékben csökkent. Összesítve; lényegesen javult az informatikai biztonság átlagos szintje.
Biztonsági követelményeket nem csak ezek a közmű-törvények írnak elő, hanem más jogszabályok is, amelyek sokszor büntető szankciókkal is fenyegetnek. Ilyen pl. a személyes adatok védelméről szóló törvény is, amely előírja, hogy minden üzemeltető köteles gondoskodni a személyes adatok védelméről. Ily módon az üzemeltetők nem csak partnereik, de saját üzemi titkaik védelmét is magasabb szinten tudják ellátni.
A közműtörvény kimondja, forráskód vizsgálatot kell végezni az egyedi szoftverekre, mindkét fenti rendeletben szerepel ez a kitétel a sérülékenység vizsgálaton belül, magasabb szintű elvárásként. A NIS 53-ban szerepel a két rendelet forrás-anyaga, a Code Review.
Pék Gábor, a CrySyS Lab munkatársa a szakmai csoport önérvényesítő pályafutását ismertette.
Tevékenységük a sérülékeny szolgáltatások védelmére indult.
Szervezetek, iskolák, egyetemek szoktak olyan hacker-versenyeket rendezni a CTF (capture-the-flag competition) jegyében; az egyes csapatoknak a nekik kiosztott sérülékeny szolgáltatásokat kell megvédeniük, vagy letölteni azokat és megtalálni bennük a sérülékenységet. A megtört szolgáltatásokról egy kis "flag"-et, egy különleges szöveges infót kell elcsenni és utána beküldeni a zsűri szerverére.
A meghírdetett versenyek többféle szabály szerint zajlanak, egyik típusuk a Jeopardi; ilyenkor nem maguknak a csapatoknak kell üzemeltetni a szolgáltatásokat, hanem letöltik a binárisokat, helyben megnézik a gépen, van-e bennük valamilyen sérülékenység. Feladatuk ezután, hogy a szerver gépen levő szolgáltatást a lokálisan kipróbált módszernek megfelelően megtörjék, megszerezzék a szerverről a flag-et és beküldjék.
A másik játéktípusnál, az Effect Defence CTF-nél a csapatok frontálisan küzdenek meg egymással. Különböző WLAN-okba regisztrálva elhelyezkednek és megtámadják egymást. A játék lényege; nem a csapatok üzemeltetik a szolgáltatásokat, hanem közvetlenül kell támadást intézniük azon szolgáltató ellen, ahonnan a sérülékeny szolgáltatás fut, onnan kell ellopni az információt. Meg kell küzdeniük pl. az ellenfél DOS támadásaival, újra kell indítani a szolgáltatásokat, stb.
Ilyen versenyekben a CrySys Labor is résztvesz, az egyetemi oktatók így motiválhatják saját diákjaikat, gyakorlatibbá téve a képzést, a versenyek legjobbjait emellett díjazzák is.
A Labor 2011-ben megalapította saját, évente rendezett versenyét, a CrySysSec HackChallange-et. Eddig kizárólag BME hallgatók számára szólt a verseny, ezévtől bármely magyar állampolgár nevezhet rá. Jeopardi típusú a verseny, melynek során le kell tölteni a szolgáltatásokat, ki kell próbálni lokálisan és a távoli gépen kell feltörni azokat. A versenyen előfordultak webes sérülékenységek, binárisok megtörése, stb.
A verseny akadálymentes lebonyolítása érdekében 2014-ben építettek egy saját virtuális labort, a versenyek azóta ezen futnak, sőt önképzőköri formában az egyetemi gyakorlati képzésben is szerepet kapnak, résztvevői a legtehetségesebb hallgatók. Hazai és külföldi előadókat is meghívnak a heti diákkörre, mely a CTF csapatépítésben is jó szolgálatot tesz.
Ebből a körből nőtt ki a SpamAndHacks hacker-csapat is, amely 2015-ben megnyerte a legnagyobb, iCTF hackerversenyt, 2015-ben pedig kijutott Los Angelesbe a "hacker-világbajnokság", a DEFCON döntőjére. Hivatalos besorolás szerint, jelenleg a világ hétezer regisztrált csapata közül a magyarok a 4. helyet foglalják el. Első helyen az USA csapata áll, második egy lengyel, harmadik egy kínai.
A CTF versenyek sok tanulsággal szolgálnak, világossá válik a problémák sokféle megközelítése, megoldása, túllépve a hobby szintű gyakorlaton.
https://en.wikipedia.org/wiki/Capture_the_flag
Budai Péter, a Tresorit Kft. munkatársa a felhő alapú mobil-alkalmazások biztonságáról szólt.
A Trezorit olyan biztonsági, együttműködést biztosító szoftver, amely fájlokat tárol, szinkronizál és ezek felhő-alapú megosztását teszi lehetővé, a lehető legerősebb szintű biztonsággal.
A titkosítás a kliens oldalon kerül alkalmazásra, s a Tresorit jelenleg nyolc platformon érhető el, közte négy mobil megoldással.
A Tresorit a Microsoft Azure felhő-szolgáltatására támaszkodik, az adatok és kiszolgáló szerverek tárolása ezzel történik. Ezt a felhőszolgáltatást egy titkosító rétegen keresztül éri el. Az alkalmazás-logika nagy része egy közös kódbázisban összpontosul, erre épülnek az asztali és mobil alkalmazások. Ily módon biztosítható az erőforrások jó kihasználása, a felhasználók számára pedig a könnyű használhatóság.
Mobil biztonságról szólva, a Tresorit elsősorban a felhasználó személyes adatainak biztonságára összpontosít. Ezen adatok biztonsága a mobil eszköz eltulajdonításakor, elvesztésekor könnyen sérülhet. Figyelni kell rá, hogy milyen alkalmazások futnak készülékünkön, amelyek az adatbiztonságot befolyásolhatják, s adatainkra pályázhatnak. Adataink megfordulnak a készülékgyártóknál, a mobil és hálózati, valamint felhőszolgáltatók körében is. Hackerek és más támadó felek is ebbe a körbe tartoznak.
A Tresorit által kínált megoldások
Mobil ellopása, és elvesztése esetére alapvető a jelkódok, blokkoló jelszavak beállítása. Mostanában kezd terjedni a biometrikus azonosítás mobil eszközöknél is. iPhone5-től kezdődően minden iOS eszköz tartalmazza az ujjlenyomat olvasót, feltűnt már az Androidnál is. Ezen megoldásokat jól lehet illeszteni sajátjainkkal, pl. ujjlenyomatunkat a Tresorit zárókódjával.
Elvesztés, sőt szétszedés esetére is védelmet nyújt az adatok titkosított tárolása a háttértáron. A három legnagyobb mobilplatformon a jelkód megoldása össze van kötve a háttértárral, így közvetlenül a diszk-titkosítást védjük.
Elvesztés esetére webes felületről távoli törlés, vagy lezárás is indítható, bár ez aktív hálózat hiányában könnyen kijátszható.
A Tresorit további titkosítási szintet nyújt mindehhez, az összes olyan adatot, amellyel a felhasználó fájljaihoz, felhőben tárolt adataihoz hozzá lehetne férni, azt saját jelszóval titkosítva tárolja. A készüléken letilthatók eszközök, platformok, országok, IP cím tartományok.
A felhasználói készüléken futó egyéb alkalmazások alapvetően csökkentett hozzáférési jogosultággal futnak, s minden személyes adathoz, kapcsolatokhoz, hely-információkhoz, fényképekhez, internethez külön-külön jogosultságot kérnek. Ez védi a rendszert, az alkalmazást és a felhasználó adatait is, alkalmazásonként ki-be kapcsolhatóan.
Van, amikor az alkalmazás telepítésekor adhatunk jogosultságot bizonyos adatokhoz, s később vagy töröljük az alkalmazást, vagy hozzáférünk az alkalmazás adataihoz.
A 6.0 Android előtt és a WindowsPhone-on ilyen megoldás élt, az iOS-ben, ill. az új Androidos platformon már az alkalmazás hozzáférés-kezdeményezésekor felnyílik egy ablak az engedélyezés eldöntésére, ill. ezt az opciót utólag is letilthatjuk.
Mindez barátságosabb megoldás a felhasználó szempontjából, szemmel tartható az alkalmazás viselkedése. Fejlesztői oldalról ez a nehezebb, mert fel kell készülni a nem-engedélyezett esetekre is, amelyeket szintén kezelni kell. Problémát jelent, amikor root jogokat tudunk szerezni saját telefonunkon, mert ezekkel kikerülhetünk a beépített védelemből. A készülékgyártók próbálnak erre is felkészülni.
Sok olyan kényelmi szolgáltatást találunk, ami nagyon megkönnyíti a mobil eszközök használatát. ezek azonban elég szabadon bánnak a felhasználó adataival, mint teszi ezt a biztonsági mentés és a visszaállítás.
Új eszköz vásárlásakor beírom az adataimat és azonnal minden alkalmazásomat, adatomat viszontlátom a régi eszközömről… Amennyiben alkalmazásom olyan adatokat is tárolt, amelyet nem szeretnék a készülékgyártó elé tárni, ajánlott a szolgáltatások működésével jobban tisztában lenni.
Az iOS-nél a mentés automatikus, s figyelnünk kell, hogy az alkalmazás sandboxban futó rendszerén belül hova történik az érzékeny adatok mentése. Programozott módon letilthatjuk bizonyos fájlok és mappák biztonsági mentését.
A WondowsPhone-nál is felkínálja a platform a biztonsági mentést, de itt az alkalmazás jelzi, hogy milyen adatot szeretne biztonsági mentésbe helyezni.
Az Android egyelőre nem támogat gyári, központi backup megoldást, de léteznek letölthető célmegoldások. Olyan szintű szintű támogatás létezik, hogy az alkalmazás megjelölhet bizonyos adatokat, amit nem szeretne az ember láthatóvá tenni backup számára. Sajnos, az alapvetően jól működő alkalmazások legtöbbször root jogokat igényelnek.
A Tresorit érzékeny adatokat helyez biztonságba, érdemes figyelni, hogy mit hogyan és hol tárolunk az eszközön.
A felhőhasználat alapvető kérdéseket vet fel. Adataink a céges hálózatról felkerülnek a felhőbe, egy szolgáltató tárhelyére, az útközben lévő internet szolgáltató alapból nem védett. Akár támadók, akár a szolgáltató számára ki vagyunk szolgáltatva. Emiatt érdemes mindíg titkosított hálózati kapcsolatra építeni ezt a szolgáltatásunkat.
A Tresorit is a legújabb, 1.2 TLS csatornát használja saját szervereinek elérésére, így csak a vonal két végén lévő fél ismerheti az adatokat.
http://compalg.inf.elte.hu/~attila/materials/ITbiztonsag_08_kripto.pdf
Ezt a megoldást a Tresorit kiegészítette különféle szabványos tanúsítványokat használó azonosító megoldásokkal, szerver és kliens oldalon egyaránt.
További kérdés, hogy a felhőszolgáltató mit kezd a hozzá érkezett adatokkal. A legtöbb esetben titkosítás nélkül, vagy valamilyen szerver-oldali titkosítással tárolják adatainkat.
Ez aggályos, mivel ő tetszés szerint hozzáférhet adatainkhoz, ill. az őt érő, esetleges hacker támadás esetén az egy helyen tárolt kulcsok és adatok hozzáférést kínálnak adatainkhoz. Ez ellen még a feltöltés előtti, kliens-oldali titkosítással tudunk védekezni; úgy töltjük fel az adatokat, hogy a titkosító és a feloldó kulcs kezelése az eszközökön történik, így adott esetben még saját adminisztrátoraink sem férhetnének hozzá az adatokhoz.
A felsorolt megoldások a rosszindulatú támadók, hackerek esetében is működnek.
Root elérés esetén alapvetően meg kell bíznunk az operációs rendszerben, abban, hogy alapvető biztonsági szolgáltatásai megfelelően működnek, s ezeket nem lehet kikerülni.
Azonban az operációs rendszerekben mindíg lehet találni biztonsági réseket, ezért érdemes az alkalmazásfejlesztőnek és szolgáltatónak mindíg egy saját rétegű védelmet beépíteni saját felhasználói adatainak védelmére.
Szolgáltatói szemszögből, a felhasználónak a mi szolgáltatói alkalmazásunkban kell megbíznia, de mindíg van egy pont, ahol a bizalmi jelleg dominál. Rosszindulatú támadók az alkalmazást is támadhatják, egy szándékosan meggyengített alkalmazással a felhasználó akár alkalmazás-szintű phishing támadással is szembesülhet. Trükkösen rá lehet venni a felhasználót, hogy beírja kulcsait, jelszavát egy sérült, megtámadott alkalmazásba. Ez ellen a legtöbb mobilplatform-készítő biztosít valamilyen autentikációt alkalmazásaink aláírására, s a felhasználó meggyőzésére, hogy mi készítettük azt az alkalmazást.
A legjobb megvalósítás az iOS esetében taláható, nagyon összetett, jól kitalált rendszerrel.
A fejlesztő a saját alkalmazását feltöltés előtt egy kulccsal, tanúsítvánnyal digitálisan aláírja, amit az Apple-től igényel. Ezt feltöltés után az Apple ellenőrzi, majd az alkalmazás ellenőrzése után maga is aláírja, így az operációs rendszer csak az Apple tanúsítványa által szignált, hitelesített alkalmazást enged telepíteni.
A Windows Phone esetén csak a letöltési oldalon van ilyen aláírás.
Az Androidnál kicsit sérült ez a rendszer, nincs lehetőség a kulcsok visszavonására. Egyetlen privat-publikus kulcspárral dolgozik, s ha ezek kompromittálódnak, akkor csak az alkalmazás törlésével és más néven történő újrakészítésével kerülhető el, hogy a felhasználóhoz észrevétlenül rossz, vagy manipulált alkalmazás kerüljön.
Összegezve; a mobil alkalmazások biztonsága ma már nem csak személyes szinten, de céges vonatkozásban is kiemelt jelentőségű. Érzékeny adatok még inkább a frontvonalba kerülhetnek. Az operációs rendszerek Janus-arcúak, a biztonság látszatát igyekeznek kelteni, de a felhasználók adatai számukra értéket jelentenek, s szeretnék fel is használni.
A szolgáltatóknak igyekezni kell saját védelmet beépíteni saját szolgáltatásaikba.
dr. Farkas Tamás, a Blue Key Kft. biztonsági vezetője az adatvédelmi szabványok és a biztonsági követelmények összehangolásáról szólt előadásában.
A két területet nem lehet gyorsan összeilleszteni.
Az adatvédelemben azonosítható szerepkörök:
a személyes adat tulajdonosa
az adatkezelő
az adatfeldolgozó.
Adatgazda mindenki, akire az adat vonatkozik, azaz olyan természetes személy, akivel az adatok összefüggésbe hozhatók.
Az adatkezelőre jellemző kitétel a döntés, olyan személyt jelent, aki dönthet az adatok sorsáról.
Az adatfeldolgozó az adatkezelő döntéseit "mechanikusan" végrehajtja, ő külön döntést nem hoz. Az adatkezelő és az adatfeldolgozó között rendkívül kicsi a távolság.
Az adatfeldolgozást szerződésben kell lefektetni, de az adatfeldolgozó átminősítheti magát adatkezelővé is, ezáltal a felelősség is más megvilágításba kerül.
Az adatvédelmi szabvány alapelvei megtalálhatók az információ-biztonsági szabványban, de itt sajátos értelmezést nyernek. A regisztrációnál pl. nagyon fontos a hozzájárulás, de az adatvédelem törvényi szabályozási oldalról is elvárja, hogy ez kifejezett legyen. Ráutaló magatartással való hozzájárulás nem jelent arra jogalapot, hogy az adatkezelő hozzájárulással megkapta az adatkezelésre az engedélyt.
Az önkéntességet regisztrációnál nem kell vizsgálni, de különös figyelmet kell fordítani a munkaviszonyban történő adatkezelésre. Az önkéntesség kulcskérdése, mennyire lehet elhajlítani az érintett akaratát, ez, a munkaviszonyból adódóan, eléggé nehezen meghatározható. A regisztrációnál ez teljesen egyértelmű helyzetet jelent. A célhoz kötöttség vonatkozásában; meg kell határozni, milyen célra fogja ezt felhasználni.
Nagyon fontos, hogy a cél megszűnésekor az adatkezelés nagyon fontos kritériuma is megszűnik.
A jogalapok tekintetében sokfajta megközelítés létezik. Az OECD-nek, az EU 46/95. irányelvének, ill. az infotörvénynek is vannak erre vonatkozó részei. A nemzeti szabályozás érvényességére való tekintettel, a két legfontosabb, mérvadó irányelvnek tekinthető a 46/95., amelynek 7. cikkelye foglalkozik az idevágó jogalapokkal, másrészt, az infotörvény jogalap rendszere is kiindulásul kell, hogy szolgáljon.
A két szabályozás átfedése abból adódik pl., amikor az érdek-mérlegelés, mint jogalap, alapvetően az irányelvben kerül kifejtésre, a hazai törvényi szabályozásban ez kevert jogalapként jelenik meg. Ha valaki az adatkezelés jogalapjaként az érdek-mérlegelést helyezi előtérbe, akkor elképzelhető, hogy ezen álláspont megfelelőségét akár egy bírósági eljárásban is bizonyítania kell, az alapvető hatósági eljárásba ezt nehezebben fogják bevenni, a törvényi szabályozásban ugyanis nem szerepel ilyen konkrétan, nevesítve.
Az irányelv közvetlenül hatályos viszont azokban a kérdésekben, amelyeket a nemzeti szabályozás nem rendez.
Az adatkezelés korlátozása terén, a megfogalmazás nehézségei és a tevékenység sajátosságai miatt, mindenképpen az adatgyűjtés kerül előtérbe. Alapvetően azokat, és kizárólag csak azokat az adatokat gyűjtse a hivatott megoldás, amelyekre valóban szükség van. Önéletrajzok esetében pl., az alapvető személyes adatok megadása helyénvaló, de az egészségi állapot, nemzetiségi hovatartozás már különleges adatnak számít. Ez külön kategória, ahol az adatkezelés csak az érintett írásos hozzájárulával történhet.
Az adatminimalizálás helytelen kezelésének példája, amikor a banki ügyintézéshez elkérik az ügyfél személyi igazolványát és fénymásolatot készítenek róla, ráadásul ehhez írásos hozzájárulást is kérnek. Ez a jogellenes adatkezelés esete, a hatósági igazolvány tartalmának egésze nem tartozik a bankra, tartalmaz pl. fényképet is, ez pedig a banki ügyletekhez nem kötelező. Az adatminimalizálás tehát arról szól, hogy csak az adott cél eléréséhez szükséges adatokat lehet kezelni.
Az adatfelhasználás lényege; csak a megadott célra lehet felhasználni az adatokat, az adatmegőrzésnél pedig alapvető, hogy személyes adatoknál meg kell állapítani a hozzájuk fűzött megőrzési időt. Az adatokhoz való hozzáférésnél pedig a jogosulatlan személyek hozzáférésének korlátozásáról van szó.
A pontosság biztosítható, amikor mindenki maga viszi be adatait a regisztráció során, a minőséget pedig az biztosítja, ha nem elavult adatok kerülnek kezelésre.
Az adatvédelmi jogviszony sajátossága, hogy úgy is lehet valaki adatkezelő, ha ez eredetileg nem állt szándékában; bárki, aki nem magáncélra kezel személyes adatot, az az érintett hozzájárulásától függetlenül adatkezelővé minősül. Onnantól kezdve rá is kötelezőek a szabályok.
Az egyéni részvétel és hozzáférés kérdése; mind az alapelv, mind a törvény az érintett részére maximális hozzáférést és részvételt biztosít. Külön jogokat határoz meg mindkettő. Gyakorlatilag minden, személyes adatkezelését érintő dologra rákérdezhet az ügyfél. Ezeket a tudnivalókat az érintettnek tájékoztatás formájában, előzetesen kell megkapnia, hogy a hozzájárulás során már ennek tudatában tudjon eljárni. Utólag is megkérdezhet olyan dolgokat, amelyek első ránézésre nem magától értetődőek. Kérheti pl. az érintett az adatkezelőtől, hogy tárolt adatait elektronikus formában adja ki számára. (Nem könnyű informatikai feladat a vonatkozó folyamat beillesztése…)
A számonkérhetőség elsősorban az info-törvény előírásaiban megszabott nyilvántartási eljárásokat érinti. Új, további feldogozásra váró téma még az adatvédelmi incidens fogalma.
Nem csak a bejelentésre kötelezett incidensek fontosak, az adatkezelőnek feladata, hogy minden személyes adatkezelést külön-külön célonként nyilvántartson, a formai követelményeknek megfelelően.
Az információ-biztonság nevesítve van az adatvédelmi követelmények sorában, klasszikus értelmezése itt is érvényes.
Az adatvédelmi rendelkezések betartása a nemzeti szabályzás körébe tartozik, az EU adatvédelmi rendelete most formálódik.
A szabályzás körébe tartozó szereplőket a 27.000. szabvány általánosságban azonosítja, a 29.100. adatvédelmi szabvány ennél konkrétabb.
Információ alatt az adott természetes személyhez kötött információt kell érteni. További információ-kategóriát jelentenek a különböző szakmai titkok, az ügyvédi, orvosi, banki, üzleti titok, stb.
Fontos, hogyan közelítik meg a szabványok azokat az eseményeket, amelyek kárt okozhatnak. Az adatvédelmi szabvány egyfajta sérelmet fogalmaz meg, a 27.000. pedig kifejezetten incidensről szól.
A sérelem pl. alapvetően annak lehetőségével létrejön, ha az érintett nem kap tájékoztatást az adatkezelés megkezdése előtt. Ez már egyfajta kockázatot jelent.
A két szabvány közös felülete
Az adatvédelmi szabvány felől nézve, a szabványcsalád közös keretét maga a 29.100. szabvány adja. Az irányítási rendszerre, ill. magának a kockázatkezelésnek a rendszerére a még meg nem jelent 29.134. számú adatvédelmi kockázat-elemzés fog utat mutatni, utóbbit itt adatvédelem-hatásvizsgálatnak nevezik. A 27.000. szabvány a kontroll folyamatoknál kapcsolódik be egyrészt az információ-biztonság irányításba, másrészt a 27.018.ban a felhő alapú adatkezelésbe. Az adatvédelmi technológia megközelítésnél, a 29.101. megadja magát a szerkezetét a rendszernek, a 29.191. pedig a speciális részeket szabályozza.
Az adatvédelmi szabványban a hatásvizsgálat egyik pontja a kockázatok határozott azonosítása, ez pedig nem nélkülözheti az informatikai szakemberek részvételét.
Az adatvédelem jellegzetes pontja az adatok jogellenes összekapcsolása, hol válnak az adatok az érintettekhez hozzárendelhetővé.
Az adatkezelő és adatfeldolgozó viszonyában fontos, hogy a hatásvizsgálatot ne csak az adatkezelő, de az adatfeldolgozó is végezze el. Az adatkezelő általános felelősséget visel ugyan az adatkezelésért, de köteles az adatkezelés teljesülését a feldolgozónál is ellenőrizni és érvényesíteni.
A 29.101. szabvány rétegeket határoz meg a személyes adatok védelmére, az azonosításra és a hozzáférésre, ill. magának a szabályzó rendszernek mikéntjére. Itt is számos olyan megoldásmód található, amelyeket az IT nélkül nem lehet végigvinni…
Az adatvédelmi irányelv és jogi vonzataira nézve kiegészítő információkat hordoz a gazdasági reklámról szóló törvény, az elektronikus kereskedelmi törvény,
a direct-marketing törvény, s az egészségügyi adatok kezeléséről szóló törvény is.
Az értelmezési kérdésekben a hazai irányadó álláspontokon kívül nagyon sok magyar nyelvű anyag is keletkezik a nemzeti adatvédelmi hatóságok vezetőiből álló EU 29. munkacsoport webes felületén.
Az adatvédelem jogi vonzatai az alapjogból kiindulva nagyon sok jogi szempontot ölelnek fel. Az információ-biztonságnál a már jól kidolgozott, rendszerekre épülő szabályzással találkozunk, ehhez vissza lehet nyúlni s alkalmazásba venni. Az adatvédelem területén azonban éppen fordított a megközelítés a szabályozásra és a szabványra vonatkozóan.
Fontos, hogy mindkét terület (adatvédelem, információ-biztonság) meghatározó szakembereinek legyen rálátása a másik terület működésére, hogy véleményt tudjanak alkotni a felmerülő kérdésekről, az egész rendszer működéséről.
Az adatvédelem tervezésénél lényeges, hogy a két szabványból adódó ellenőrzéseket, a kockázat-elemzést és a hatásvizsgálat elemzéseket az alkalmazók végrehajtsák.
Az adatkezelés végrehajtásánál alapvető feltétel, hogy adott esetben a kezelő bejelentéssel éljen a hatósághoz. Az adatvédelem oldaláról is fontos, hogy az információbiztonság gyakorlatát kövessék.
Megállapítható, hogy a két területet nem lehet maradéktalanul összeilleszteni, így maradnak nyitott kérdések. Az a követelmény, hogy az adatvédelmi kérdéseket nyilvánossá kell tenni, adatbiztonság vonatkozásában nem lenne szerencsés, nem lehet kirakni az információ biztonsági szabályzatot teljes terjedelmében.
Ütközések is adódnak, pl. a biztonsági mentések terén. Elvileg a biztonsági mentés több példányban létezik, de amennyiben törölni kell, akkor ez a biztonsági mentés nem biztos, hogy megjelenik a törlésekben is; ez nehezen feloldható ellentétet jelent.
További ütközések lehetnek még a korábban említett adatvédelmi incidensen kívül is, ezek a kérdések még nincsenek lezárva.
Amennyiben adatkezelési kérdés merül fel, akkor a személyes adatkezelésekről fel kell venni nyilvántartást, függetlenül attól, hogy az hozzájáruláson, vagy törvényi kötelezettségen alapuló, s meg kell nézni a személyes adatkezelési hátteret, valamint azokat az informatikai eszközöket, amelyek ezzel összefüggésbe hozhatók. A szakembereknek biztosítaniuk kell a személyes adatbiztonság érvényesülését.
Joga az érintettnek, hogy adatvédelmi incidensnél, pl. ami biztonsági mentések mentén lép fel, megkérdezheti, hogy az esemény az ő adatai közül milyen típusúakat érintett.
https://en.wikipedia.org/wiki/Organisation_for_Economic_Co-operation_and_Development
Az elhangzott előadások kísérő anyaga az egyesület LinkedIn oldalán megtalálható.
Harmat Lajos
