1 Biztonságos elektronikus kereskedelmi rendszer létrehozása PKI alapokon Szerz: Krasznay Csaba Konzulens: Dr. Magyar Gábor BME Távközlési és Telemati...
Biztonságos elektronikus kereskedelmi rendszer létrehozása PKI alapokon
Szerz : Krasznay Csaba Konzulens: Dr. Magyar Gábor BME Távközlési és Telematikai Tanszék Kisteleki Róbert MÁV Informatika Kft.
Nyilatkozat Alulírott Krasznay Csaba, a Budapesti M szaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból vettem, egyértelm en, a forrás megadásával megjelöltem.
A VÁLLALAT VIZSGÁLATA..................................................................................................... 32 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.5.4
5
INFORMATIKAI BIZTONSÁG ........................................................................................................ 7 A kriptográfia története........................................................................................................ 7 Az információ biztonsága ..................................................................................................... 8 Szimmetrikus kulcsú titkosítás ............................................................................................ 10 Nyilvános kulcsú titkosítás ................................................................................................. 11 Hitelesítés aszimmetrikus kulccsal ..................................................................................... 12 PKI RENDSZEREK..................................................................................................................... 14 Tanúsítványok, CA-k .......................................................................................................... 14 A digitális aláírás felhasználási területek szerint............................................................... 19 ELEKTRONIKUS KERESKEDELMI RENDSZEREK ......................................................................... 24 BIZTONSÁGI MIN SÍTÉSEK ....................................................................................................... 27 Auditálási szabványok........................................................................................................ 28 Az auditálás folyamata ....................................................................................................... 30 JELENLEGI INFRASTRUKTÚRA .................................................................................................. 32 AZ ELEKTRONIKUS ALÁÍRÁS HASZNÁLATÁNAK INDOKLÁSA .................................................... 35 A VÁLLALAT KOCKÁZATELEMZÉSE ......................................................................................... 36 Bevezetés ............................................................................................................................ 36 Magas szint kockázatelemzési áttekintés .......................................................................... 38 Kockázatelemzési kérd ívek ............................................................................................... 42 JAVASOLT ARCHITEKTÚRA ...................................................................................................... 61 KOCKÁZATELEMZÉS A JAVASOLT KÖRNYEZETBEN .................................................................. 63 Módosított kockázatelemzési kérd ívek.............................................................................. 63 Veszélyforrás értelmez adatlap ........................................................................................ 66 Kockázatelemzési grafikon ................................................................................................. 66 Védelmi intézkedések.......................................................................................................... 67
AZ ELEKTRONIKUS KERESKEDELMI RENDSZER MEGVALÓSÍTÁSA....................... 69 5.1 5.2 5.3 5.4
BIZTONSÁGOS ELEKTRONIKUS BOLT LÉTREHOZÁSA – JEGYZ KÖNYV ..................................... 69 AZ ALÁÍRÓ MODUL M KÖDÉSE:............................................................................................... 77 TAPASZTALATOK ÖSSZEFOGLALÁSA: ...................................................................................... 82 JAVASLAT EGY M KÖD KÉPES MEGOLDÁSRA: ........................................................................ 83
1 Bevezetés Életünknek egyre jobban a részévé válik az információs világhálózat. Napjainkban már több elektronikus üzenetet küldünk, mint hagyományos levelet. Az utóbbi években már a kereskedelem sem ugyanazt jelenti, mint korábban. Megszületett az elektronikus kereskedelem, amivel létrejöttek a napi 24 órában, heti hét napban nyitva tartó üzletek. Ellenben megsz nt a személyes jelenlét, ami viszont nagyban csökkentette mind a vásárlók, mind az eladók bizalmát az új technológiákkal szemben. A bizalomvesztés indokolttá teszi olyan megoldások használatát, mint a nyilvános kulcsú infrastruktúra (PKI), ami lehet séget biztosít mindkét fél azonosítására. Emellett fokozott figyelemmel kell lenni a hagyományos informatikai biztonságra is, mert ahogy a hagyományos kereskedelemnél, itt is megjelennek azok a rosszindulatú emberek, akik ki szeretnék használni a rendszerek gyengeségeit, ezzel anyagi el nyt szerezve maguknak. Diplomatervem célja egy olyan elektronikus kereskedelmi rendszer létrehozása, ami teljesíti a gyakorlati biztonsági követelményeket, emellett lehet séget nyújt elektronikus aláírással hitelesített tranzakciók lebonyolítására. A biztonság ellen rzésére el kell végezni a rendszer kockázatelemzését, amib l kiderülnek a hiányosságok és a veszélyek, majd védelmi intézkedéseket javasolni, ami kiküszöböli a ezeket. A dolgozat els része áttekintést nyújt a felölelt témáról, a szakirodalom segítségével. Ebben a részben részletesen foglalkozom az informatikai biztonsággal, a PKI rendszerekkel, az elektronikus kereskedelemmel és a biztonsági min sítésekkel. A második részben az elektronikus kereskedelmi rendszer elméleti megtervezése található. Az „állatorvosi ló” szerepét egy olyan vállalat infrastruktúrája tölti be, amely korábban már próbálkozott B2C kereskedelemmel, de megfelel tervezés híján ez nem m ködött megfelel en. Most újra bele kíván vágni ebbe az üzletbe, viszont ehhez biztonságosabb környezetre van szüksége, és a fel kívánja használni a PKI technológiát. El ször ismertetem a cég jelenleg rendelkezésre álló informatikai eszközeit és üzleti folyamatait, majd bebizonyítom az elektronikus aláírás használatának ésszer ségét. Ebb l kiindulva elvégzem a jelenlegi infrastruktúra kockázatelemzését a The National Electronic Commerce Coordinating Council által kiadott „Risk Assessment Guidebook For e-Commerce/e-Government” segítségével. Ezután javaslok egy olyan rendszert, ami tartalmazza a PKI-t, valamint megsz nteti a legnyilvánvalóbb biztonsági hibákat. Végül elvégzem a javasolt architektúrára is a kockázatelemzést és ennek tapasztalatai alapján védelmi intézkedéseket ajánlok. A dolgozat utolsó részében részletesen leírom, hogy hogyan történt a rendszer gyakorlati megvalósítása, és a m ködésb l milyen tapasztalatokat sz rtem le. Végül ajánlatot teszek egy olyan rendszerre, ami képes egy általános üzleti környezetben, szabványos felületekkel m ködni.
5
2 Introduction Information networks become part of our lives. Today we send more electronic messages than usual letters. In the recent years trade has taken on another meaning. Electronic commerce was born which enables 24 hours and 7 days opening for stores. But personal presence has disappeared which reduced the confidence of both the vendors and the costumers towards new technologies. The loss of confidence calls for the use of solutions such as private key infrastructure (PKI) which assures the identification of both parties. Attention to conventional information security is still important because – just like in the real life commerce – we face the threat of malicious attacks that try to exploit the weaknesses of the system in search of personal financial advances for themselves. The goal of my thesis is the development of an electronic commerce system which complies with general practical security requirements and has the ability for handling commerce transactions which are authenticated with digital signatures. To ensure a proper level of security risk assessment should be completed, which exposes the potential defects and risks. I suggest protection measures to avoid the arising risks and defects. The first part of my thesis offers a summary about the scope of my work. I introduce the information security, PKI systems, e-commerce and security qualifications. In the second part the theoretical design of the e-commerce system is to be found. The reviewed system’s owner is firm that has tried B2C commerce but was unsuccessful because of the lack of proper design. Now the company wants to begin this business again but it needs more secure environment and wants to use PKI technology. First I introduce the company’s current IT environment and business processes then I prove the rationalism of the usage of electronic signature. I make the risk assessment of the current infrastructure about the “Risk Assessment Guidebook For e-Commerce/eGovernment” published by The National Electronic Commerce Coordinating Council. Then I offer a system that involves PKI and avoids the well-known security related mistakes. Finally I complete the risk assessment of the new architecture and offer protection measures. In the last part of my thesis I display the detailed development of the e-commerce system and the experiences of the working test. At last I offer a system that can work in a real business situation with standard interfaces.
6
3
Szakirodalmi összefoglaló
3.1 Informatikai biztonság 3.1.1 A kriptográfia története Az információ elrejtésének vágya szinte egyid s az emberi kultúrával. Az els emlékek id számításunk el tt 1900 évvel, az ókori Egyiptomból származnak. Ekkor már használták a titkosítást a diplomáciai és katonai életben. A korai zsidó írástudók például az ábécéjüket fordították meg, ha valamilyen információt el akartak titkolni. Talán a legismertebb kódolást Julius Caesar Rómájában használták. Itt a kód ábécé az eredetib l úgy jött ki, hogy hárommal eltolták a karaktereket. A középkorban a titkosírás egyre fontosabb szerepet töltött be az országok diplomáciai életében. Az ókorból származó technikákat leginkább a pápai állam és az olasz városállamok vették át és fejlesztették tovább. A XIV. században jelentek meg az els kódszótárak, amik jelent sen megkönnyítették az államok titkos kapcsolattartását követeikkel és bizalmasaikkal. Az els kriptográfiával foglalkozó nyomtatott m 1510ben jelent meg. Ezt Johannes Trithemius, Spanheim apátja írta, címe Polygraphia volt. A XIX. századra teljesen elterjedt a titkosítás. A hadseregek azonban nem szívesen használták, mert nagyon nehéz volt megvédeni a kódkönyveket, amik a komoly kódoláshoz elengedhetetlenül szükségesek voltak. Az amerikai polgárháborúban ezért a teljes kódszó helyett egy rövidebb szó jelezte a kód helyét a könyvben. Kés bb ezek a kódolások terjedtek el a polgári életben is. [Grimm01] A kriptográfia azonban egészen a XX. századik inkább m vészet volt, mintsem tudomány. A matematika csak a múlt század elején fedezte fel magának a kriptoanalízis diszciplínáját. Nagy lökést adott a II. világháború, ami a frontok mögött a kódfejt k csatáját is eredményezte. Ennek a titkos háborúnak köszönhetjük a számítógépek megjelenését – amikre az ellenség üzeneteinek megfejtésére volt szükség. A kor legjobb matematikusai dolgoztak a katonai laboratóriumokban, akik olyan felfedezéseket tettek, amik megalapozták mai infokommunikációs társadalmunkat. Az információtudomány atyjának Claude Shannon-t tartják, aki többek között jelent s szerepet játszott a kriptográfiában is. 1949-ben bizonyította be, hogy létezik tökéletes kódolás. Az 1960-as években a számítógépek egyre szélesebb kör polgári használata miatt vált szükségessé a kódolás elterjedése. Megjelent ugyanis a bankok közötti adatforgalom, ami komoly biztonsági kérdéseket vetett fel. A probléma megoldását az IBM-nél kezdték el kutatni Horst Feistel vezetésével. Ekkor született meg a LUCIFER, az els komputeres kódoló. Ezt fejlesztették tovább, aminek eredménye az 1977-ben megszületett Data Encryption Standard (DES) kódolás lett. A DES egészen 2001-ig az USA hivatalosan elfogadott titkosítási szabványa volt. 1998-ig nem tudták feltörni. A DES a legismertebb szimmetrikus kulcsú titkosítás, aminek helyét a Rijndael algoritmuson alapuló Advanced Encryption Standard (AES) vette át. [Buttyán03] Egészen új fejezetet nyitott a kriptográfia történetében Whitfield Diffie és Martin E. Hellman, akik 1976-ban megalkották a nyilvános kulcsú kriptográfia elméletét. Bár k akkor nem tudták az elméletet gyakorlatra váltani, nem kellett sokat várni az els
7
adaptációra. 1978-ban Ronald Rivest, Adi Shamir és Leonard Adleman publikálta az RSA kódolás elvét, ami azóta a legelterjedtebben használt titkosításnak számít.
3.1.2 Az információ biztonsága Modern világunk alapja az információ, ami érték és hatalom lehet. Ezért mindent megteszünk, hogy biztonságban tudjuk. A megszerzett információt számos szemszögb l kell megvizsgálnunk. Jó lenne, ha csak az látná, akire tartozik. Biztosak akarunk lenni abban, hogy a kapott információ egyezik-e azzal, amit elküldtek nekünk. Ismerni szeretnénk a kommunikációban részvev szerepl ket és az adat forrását. Az információt szeretnénk konkrét személyhez kötni. Meg akarjuk határozni, hogy egy kommunikáció során melyik szerepl mit tehessen, és mihez férhessen hozzá és ezeket a jogokat akár vissza is tudjuk vonni. Az információ érvényességi idejét tudnunk kell. Szeretnénk egy megbízható harmadik személyt l jóváhagyást kapni az információ hitelességére. Tudni akarjuk az információ keletkezésének pontos idejét. Erre tanukat is szeretnénk. Meg akarjuk er síteni az információ érkezését. Érdekel, hogy a küld nek volt-e joga elküldeni az információt. Néha szükség van a kommunikáló felek névtelenségére, viszont azt is szeretnénk, ha senki nem tagadhatná le az információcserét. Az évszázadok során kialakultak azok a protokollok és eljárások, amivel a fizikai dokumentumokat meg lehet védeni. Ezek azonban nem feltétlenül elégségesek, szükséges még a törvényi biztosíték és az adatkezelés megbízhatósága. Ilyen például a postai levélküldésnél a boríték, amivel a dokumentum bizalmasságát tudjuk meg rizni. A digitális világban is érvényesek ezek az elvek, csak a bitek világában a megvalósítás körülményesebb feladat. A kriptográfia alapelvei biztosítják azt, hogy az elektronikus dokumentumok is eleget tegyenek minden elvárásnak, amit az információ biztonságával szemben támasztunk. Ezek az elvek a következ k: • • • •
Bizalmasság: az információt mindenki el l el kell rejteni, kivéve azokat, akik fel vannak hatalmazva a tartalomhoz való hozzáférésre. A bizalmasságot mind fizikai mind matematikai megoldásokkal biztosítani tudjuk. Sértetlenség: biztosítja az adat változatlanságát, jelzi, ha illetéktelenül megváltoztatták az információt. A megváltoztatás lehet beszúrás, törlés vagy helyettesítés. Hitelesség: biztosítja mind a kommunikáló felek, mind az adatok azonosítását. Letagadhatatlanság: lehetetlenné teszi a felek számára valamely korábbi tevékenység letagadását.
A kriptográfia ennek a négy elvnek az elméleti és gyakorlati vizsgálatával foglalkozik. Az alapelvek kielégítésére szolgáló segédeszközöket nevezzük kriptográfiai primitíveknek, amiknek osztályrendszerét az 1. ábrán láthatjuk. Ezeket a primitíveket használhatjuk a négy elv kiszolgálására. Kiválasztásuknál mérlegelni kell a biztonság szintjét: mekkora biztonságra van szükségünk egy adat védelmére. Tipikusan annyit érdemes a védelemre költeni, hogy a kódolás feltörése költségesebb legyen, mint amennyit az adat ér.
8
a használhatóságot: nem mindig a legjobb titkosítás a leghasználhatóbb. Például Shannon tökéletes, one-time pad kódolója esetében a kulcsnak akkorának kell lennie, amekkora az elküldend bitfolyam, tehát a gyakorlatban használhatatlan. a m ködési módszert: más célokra más módszereket érdemes használni. Egy elektronikus aláírásra a legjobb választás a nyilvános kulcsú titkosítás, viszont ez nagyméret adatok kódolására a gyakorlatban nem alkalmas. Tetsz leges hosszúságú hash függvények Kulcs nélküli primitívek
Egyirányú permutációk
Véletlen sorozatok
Biztonsági primitívek
Szimmetrikus rejtjelezés
kulcsú
Blokktitkosítók Folyamtitkosítók
Tetsz leges hosszúságú hash függvények (MAC) Szimmetrikus kulcsú primitívek
Aláírások
Pszeudovéletlen sorozatok
Azonosító primitívek
Nyilvános titkosítás Nyilvános kulcsú primitívek
kulcsú
Aláírások
Azonosító primitívek
1. ábra: A kriptográfia osztályrendszere [MOV96]
9
a teljesítményt: azonos feladatoknál a jobb teljesítmény primitívet érdemes használni. a megvalósítás könny sége: az a primitív az ideális, amit könny megvalósítani. Különösen akkor jó, ha hardver elemekkel is elkészíthet .
3.1.3 Szimmetrikus kulcsú titkosítás Definíció szerint a titkosító és titkosítást feloldó transzformációk halmaza legyen {Ee : e ∈ } és {Dd : d ∈ }, ahol a kulcstér. Szimmetrikus kulcsú titkosításról akkor beszélünk, ha minden (e,d) kulcspárra igaz, hogy könny e-b l d-t és d-b l e-t el állítani. Ez praktikusan azt jelenti, hogy e és d azonos. A definíció a 2. ábrával szemléltethet . Eve Támadó
titkosítás Ee(m) = c
c
m
NEM BIZTONSÁGOS CSATORNA
dekódolás Dd(c) = m m
nyílt szöveg forrás
nyílt szöveg cél
Alice
Bob
2. ábra: Szimmetrikus kulcsú titkosítás
Feltételezzük, hogy az összes kommunikáló fél ismeri a kódoló és dekódoló algoritmusokat. Az egyetlen dolog, amit titokban kell tartani, a d dekódoló kulcs. Mivel szimmetrikus kulcsokról beszélünk, ez megegyezik az e kódoló kulccsal, tehát ezt is védeni kell. Ha ezek a feltételek teljesülnek, Alice a mindenki által ismert algoritmussal és e kulccsal titkosítja m szöveget, majd továbbítja ezt a nem biztonságos csatornán. Eve le tudja hallgatni c kódolt üzenetet, de a d kulcs nélkül nem tud vele mit kezdeni. Bob a c kódolt üzenetet az általa is ismert függvények és kulcs segítségével meg tudja fejteni. A szimmetrikus kulcsú titkosításnak két fajtáját ismerjük: a folyam- és a blokktitkosítókat. A folyamtitkosító bitenként kódolja az adatot. Megvalósítása a 3. ábrán látható.
10
nyílt szöveg
Pszeudo-véletlen bitfolyam generátor
mag kódolt szöveg
+ 3. ábra: Folyamtitkosító
Az általánosabban elterjedt megoldás a blokktitkosító. Ez a bitfolyamot el re meghatározott méret darabokra, stringekre vágja, majd ezeket kódolja. Ha nem sikerül az el re meghatározott méret darabokat el állítani, akkor az algoritmus kipótolja a bitfolyamot. A kódolás folyamata a 4. ábrán látható. kulcs nyílt szöveg
kódolt szöveg Blokktitkosító
kitöltés 4. ábra: Blokktitkosító
Az architektúra legnagyobb hiányossága, hogy a kulcsokat nehéz biztonságosan elküldeni a résztvev feleknek. Ezt hívjuk kulcskiosztási problémának. Jó tulajdonsága viszont, hogy a kulcsok kicsik és nagyon gyors kódolást tesznek lehet vé. Legelterjedtebb változata a DES és a 3DES kódolás, újabban az AES kódolás.
3.1.4 Nyilvános kulcsú titkosítás Definíció szerint a titkosító és titkosítást feloldó transzformációk halmaza legyen {Ee : e ∈ } és {Dd : d ∈ }, ahol a kulcstér. Nyilvános kulcsú titkosításról beszélünk akkor, amikor az (e,d) kulcspárok közül e nyilvánosan hozzáférhet , míg d titkos kulcs. Hogy ez az eljárás titkos legyen, d kiszámítása lehetetlen e-b l. A definíció megvalósítása az 5. ábrán látható.
11
Eve Támadó e NEM BIZTONSÁGOS CSATORNA kódolás Ee(m) = c m nyílt szöveg forrás
c NEM BIZTONSÁGOS CSATORNA
Alice
kulcsforrás d dekódolás Dd(c) = m m cél
Bob
5. ábra: Nyilvános kulcsú kódolás
Ee olyan függvény, aminek az inverz függvénye d dekódoló kulcs nélkül nem állítható el . A titkosítás els lépése, hogy Bob elküldi Alice-nak a saját e kódoló kulcsát. Ezt akár Eve is megszerezheti a nem biztonságos csatornán, hiszen ez a kulcs a nyilvános kulcs, ami bárki számára hozzáférhet . Ennek segítségével Alice a mindenki által ismert Ee függvénnyel titkosítani tudja m üzenetet. Az így elkészült c üzenetet visszaküldi a nem biztonságos csatornán. Eve ezt az üzenetet is le tudja hallgatni, de mivel csak e kulcsot, Ee függvényt és c üzenetet ismeri, d kulcsot nem, nem tudja visszafejteni az üzenetet. Bob viszont d titkos kulcs segítségével végre tudja hajtani Dd függvényt, ami Ee inverze. A titkos kulcs a nyilvános kulcs nélkül nem használható és ez fordítva is igaz. Ezért kulcspárnak nevezzük ket. A nyilvános kulcsú titkosítás a kulcskiosztási problémára megoldást kínál, hiszen e nyilvános kulcsot bármilyen nem biztonságos csatornán el lehet küldeni bárkinek, a bizalmasság nem sérül. Hátránya, hogy nagy kulcsokkal dolgozik, ezért a titkosítás folyamata lassú. Legelterjedtebb fajtája az RSA titkosítás, ami a prímszám faktorizáció NP teljes problémáján alapul.
3.1.5 Hitelesítés aszimmetrikus kulccsal Eve, a támadó azonban fel tudja törni a titkosítást anélkül, hogy ismerné a d titkos kulcsot. Bob elküldi saját e nyilvános kulcsát Alice-nak. Eve azonban elfogja ezt az üzenetet. Alice kap egy e nyilvános kulcsot, amir l azt hiszi, hogy Bobé. Azonban ezt Eve küldte neki, Bob aláírással. Alice titkosítja az üzenetet e kulccsal, és elküldi Bobnak. A nem biztonságos csatornán azonban Eve elfogja a levelet, majd saját d kulcsával dekódolja az üzenetet, Bob nyilvános kulcsával pedig újra titkosítja. Az új c üzenetet továbbküldi Bobnak. Alice és Bob így nem is sejti, hogy üzenetük Eve-nél van. Ezt nevezzük megszemélyesítésnek, aminek folyamatát a 6. ábrán láthatjuk. 12
Eve
kulcs forrás d’ e’
kódolás Ee(m) = c
dekódolás Dd’(c) = m
m
c’
kódolás Ee’(m) = c’
e
c kulcsforrás d dekódolás Dd(c) = m
m
m
nyílt szöveg forrás
nyílt szöveg cél
Alice
Bob
6. ábra: Megszemélyesítés
A nyilvános kulcsú titkosítás lehet séget ad arra, hogy a küld is azonosítsa magát. Ezt nevezik elektronikus aláírásnak. Segítségével Bob meggy z dhet arról, hogy a levelet tényleg Alice küldte. Alice az üzenetet kódolja a saját d titkos kulcsával. Ezt küldi Bobnak, aki Alice e nyilvános kulcsával megfejti az üzenetet. Ha értelmes az üzenet, akkor a küld tényleg Alice volt. A folyamatot a 7. ábra szemlélteti.
e
Ee(s) h’ elfogadva, ha h’∈M’ ellen rz Bob
s
kulcsforrás d Dd(h) = s h eredeti üzenet M aláíró Alice
7. ábra: A hitelesítés folyamata
13
Alice h üzenetét a gyakorlatban hash-nek, azaz lenyomatnak hívjuk. Ez az eredeti üzenetb l egy speciális függvény segítségével el állított, fix méret bithalmaz. A hash függvényt úgy kell megválasztani, hogy az m üzenethez h kivonat egyértelm en tartozzon, viszont csak a lenyomatból ne lehessen visszafejteni az üzenetet. A függvényt mind a két kommunikáló félnek ismernie kell. Alice M üzenetéb l a függvény segítségével elvégzik a lenyomatolást, majd saját titkos kulcsával ezt rejtjelezi. A titkosított üzenet mellett elküldi a hash függvényt is. Bob, miután saját titkos kulcsával megfejtette az üzenetet, elvégzi a lenyomatolást. Ezután Alice nyilvános kulcsával visszafejti a kódolt lenyomatot és összehasonlítja a saját hash-ével. Ha ezek egyeznek, akkor az üzenet nem sérült, és tényleg Alice volt a küld . A megszemélyesítést sajnos még így sem sikerült teljesen kivédeni, hiszen el fordulhat, hogy Alice helyett Eve végzi el a hash függvény kódolását, azaz a digitális aláírást. Ezért Alice-nak és Bobnak választaniuk kell egy harmadik felet, aki garantálja, hogy a másik fél nyilvános kulcsát kapják meg, és így Eve nem tudja megszemélyesíteni egyik felet sem. Ezt a közbens kulcskiosztót nevezik trusted third party-nak (TTP), azaz megbízható harmadik félnek. Vizsgáljuk meg, hogy a nyilvános kulcsú titkosítás eleget tud-e tenni a biztonság négy alapelvének! • • • •
Bizalmasság: mivel lehet ség van oly módon titkosítani, hogy azt harmadik személy ne tudja megfejteni, a bizalmasság alapelve teljesül Sértetlenség: a lenyomat oly módon keletkezett, hogy az csak az elküldött üzenethez tartozhat, így az üzenet bármilyen változtatása esetén a fogadó oldalon számolt hash nem fog egyezni az eredetivel. Hitelesség: az elektronikus aláírás biztosítja mindkét fél kilétének a felfedését, így erre az alapelvre is van megoldás. Letagadhatatlanság: a megbízható harmadik fél garantálja azt, hogy mindkét fél az, akinek mondja magát, így egy aláírt üzenetet biztosan az küldött, akinek az aláírása szerepel az üzenet mellett.
A nyilvános kulcsú titkosítás tehát kiegészítésekkel teljesíti mind a négy alapelvet. A titkosítást, a kivonatolást és a megbízható harmadik felet együttesen nyilvános kulcsú infrastruktúrának, azaz PKI-nak (Public Key Infrastructure) hívjuk. Más megközelítésben a PKI eljárások, folyamatok, emberek, létesítmények, szoftverek és hardverek olyan halmaza, ami lehet vé teszi nyilvános kulcsú tanúsítványok kiadását, szétosztását és folyamatos menedzselését. [Certicom01]
3.2 PKI rendszerek 3.2.1 Tanúsítványok, CA-k A gyakorlatban a kulcspárokat egy meghatározott entitáshoz köt adatobjektumot, ami az entitáshoz kapcsolódó információk halmazából áll digitális tanúsítványnak, certificate-nek nevezzük. A tanúsítvány felfogható elektronikus személyi igazolványnak, hiszen szerepel benne például az entitás neve, megkülönböztetett neve, e-mail címe és persze a nyilvános kulcsa is. Ezek mellett rengeteg kötelez és nem kötelez mez is megtalálható, részletesen az ITU X.509v3 szabvány szabályozza. Egy
14
tipikus tanúsítvány a 8.ábrán látható. Az elektronikus aláírás tehát megfeleltethet a hagyományos, kézzel írt aláírással.
8. ábra: Digitális tanúsítvány
A kulcstároló azonban, hasonlóan a hagyományos személyazonosítókhoz, elveszthet . Kompromittálódásnak nevezzük azt az esetet, amikor a titkos kulcs tulajdonosa valamilyen okból elveszíti a kapcsolatot a kulccsal. Ebben az esetben a tanúsítványt érvényteleníteni kell. Az érvénytelenítés során a tanúsítvány azonosítója felkerül egy szolgáltató által közzétett listára. Ezt nevezik visszavonási listának (Certificate Revocation List, CRL), ami a 9. ábrán látható.
15
9. ábra: Visszavonási lista
A visszavonási listák helyettesítésére újabban az Online Tanúsítvány Állapot Protokollt (Online Certificate Status Protocol - OCSP) használják. Ez kiküszöböli a CRL-ek legnagyobb hibáját: nem kell folyamatosan frissíteni azt a kliens gépen. Az ellen rz környezet minden tanúsítványellen rzésnél lekérdezi az aktuális állapotot az OCSP szervert l, amire az „érvényes”, „visszavont” vagy „ismeretlen” választ kaphatja. A megbízható harmadik fél megnevezése Tanúsító Szervezet, röviden CA (Certification Authority). Feladata a tanúsítványok kiállítása az általa hitelesnek talált személyeknek és szervezeteknek, a kulcsok tárolása és szétosztása. A PKI rendszer architektúrájának a CA-n kívül része a Névadó Szervezet, röviden RA (Registration Authority), aminek feladata az entitások regisztrálása és a CA által kiosztott tanúsítványok eljuttatása az entitásokhoz. Ide tartozik még a Névtár (Directory), ahol a tanúsítványokat tárolják, illetve innen lehet elérni a már kiállított tanúsítványokat és a visszavonási listákat. Végül nem szabad elfelejtkeznünk a felhasználó-oldali alkalmazásokról (End-Entity Application). A teljes struktúra és a folyamatok a 9. ábrán láthatóak.
16
Névadó Szervezet
3. RA jóváhagyja a kérést, továbbítja a CAnak
2. RA meggy z dik a jelentkez személyér l
Tanúsító szervezet
5. CA elküldi a tanúsítványt és a visszavonási infót
Névtár 4. CA kiállítja a tanúsítványt
Felhasználó-oldali alkalmazás (a kulcsbirtokosnál)
Felhasználó-oldali alkalmazás (a címzettnél)
1. A felhasználó tanúsítványért jelentkezik
6. A felhasználó lekéri a tanúsítványt és a visszavonási infót
10. ábra: A PKI f komponensei és folyamatai
A felhasználó-oldali alkalmazás (szoftver és hardver elemek) feladatai: • A kulcspárok generálása, tárolása és a hozzáférés engedélyezése • Az els tanúsítványkérés elkészítése, aláírása és elküldése • A tanúsítvány megújítási kérésének elkészítése, aláírása és elküldése • A tanúsítvány visszavonási kérésének elkészítése, aláírása és elküldése • Tanúsítványok és visszavonási listák keresése és lekérése • Tanúsítvány elfogadása és tartalmának kiolvasása • Elektronikus aláírás készítése és ellen rzése A névadó szervezet (a CA-val és a felhasználó-oldali alkalmazással kompatibilis szoftver) feladatai: • Felhasználók felvétele: az entitás a PKI rendszer résztvev jévé válik. Az RA egy felhasználói objektumot generál az adatbázisába. Az objektum olyan elemeket tartalmaz, amik a szolgáltatási politikában el vannak írva (pl. név, cím, e-mail cím). • Megfelel gondosság: az az eljárás, aminek során az RA meggy z dik a jelentkez személyazonosságáról és összeköti az entitást a nyilvános kulcsával. • A végfelhasználói kérés jóváhagyása: az RA jóváhagyja, vagy elutasítja a végfelhasználók tanúsítványgenerálási és visszavonási kérését. • Tanúsítvány visszavonás: az RA felkéri a CA-t, hogy vonja vissza az entitás tanúsítványát. Erre vagy szolgáltat indokot vagy nem, attól függ en, hogy a szolgáltatási politika mit ír el . A tanúsító szervezet (nagybiztonságú tanúsító alkalmazás) feladatai: • Kulcs tanúsítás: az entitás nyilvános kulcsának aláírása és a tanúsítvány kibocsátása. • Tanúsítvány megújítás: új tanúsítvány kibocsátása, ha a régi lejárt.
17
• • • •
Tanúsítvány visszavonás: az entitás tanúsítványának hozzáadása a visszavonási listához, ezzel az az adott id t l érvénytelenné válik. Tanúsítvány postázás: a tanúsítvány elhelyezése a Névtárban, ezzel az kereshet vé és lekérhet vé válik. Visszavonási lista kezelése: a visszavonási lista mindig az aktuális állapotot mutassa a PKI-ban. Visszavonási lista postázás: a visszavonási lista elhelyezése a Névtárban, ezzel az kereshet vé és lekérhet vé válik.
A névtár (a gyakorlatban általában LDAP szabvány szerinti adatbázis) feladatai: • Tanúsítványtárolás: kereshet k és lekérhet k a benne tárolt tanúsítványok. • Visszavonási lista tárolása: kereshet és lekérhet a benne tárolt visszavonási lista. • Szolgáltatási politika tárolása: kereshet és lekérhet a benne tárolt szolgáltatási politika. • Karbantartás: az arra felhatalmazott felhasználó írhat és törölhet a névtár adatbázisából. Az üzleti életben azonban semmi értelme nem lenne a PKI rendszereknek, ha nem lehetne ket a meglev alkalmazásokba integrálni. Ezért fontos megemlítenünk a PKI fejleszt készleteket is. A jó fejleszt készlet a meglev rendszer interfészeire koncentrál, ezeket hangolja össze a PKI szabványokkal. Lehet leg minimális er forrásfelhasználás szükséges a PKI integrációhoz. A fejleszt készlet tartalmaz minden olyan könyvtárat és interfészt, ami szükséges egy alkalmazás PKI-képessé tételéhez. Ideális esetben a PKI mag-alkalmazásai is ezzel a fejleszt készlettel készültek. A legelterjedtebb felhasználói környezetek, ahol PKI-t használnak, az 1. táblázatban láthatók. Felhasználói környezet PKI-t támogató szabványok WML WTLS (www.wapforum.org) HTML SSL és TLS (www.ietf.org) E-mail S/MIME (www.ietf.org) VPN IPSec (www.ietf.org) 1. Táblázat: PKI-t használó felhasználói környezetek
A hitelesít központoknak nyilvánosságra kell hozniuk m ködési dokumentumait. Kétféle dokumentumot különböztethetünk meg: a hitelesítési szabályzatot (Certificate Policy, CP) és a szolgáltatási szabályzatot (Certification Practice Statement). Ezek összeállításának szabályai az RFC 2527-es számú szabványban találhatók meg. A hitelesít központhoz kapcsolódó felhasználói bizalom nagyban függ azoktól az eljárásoktól, amik a szolgáltatási szabályzatban vannak leírva. A CPS-ben van leírva az, hogy a PKI résztvev i hogyan generálják, kezelik, használják és érik el a kulcsokat és a tanúsítványokat. Tartalmazza, hogy a felhasználókat és az adminisztrátorokat hogyan regisztrálják, mik a CA általános m ködési szabályai, eljárásai és biztonsági követelményei, a felhasználó és a CA kötelezettségei. A piacon több hitelesít központ is lehet, akiknek együtt kell m ködniük. Az együttm ködéshez szabványos interfészek szükségesek. A hitelesítési szabályzat tartalmazza mindazokat a szabályokat és szabványokat, amiket a CA felhasznál.
18
Ezeknek a szabványoknak a betartásával válik lehet vé a különböz termékek közötti interoperabilitás. A titkos kulcsot biztonságos körülmények között kell tárolni, mert ez az egész PKI rendszer lelke. A gyakorlatban vagy a merevlemezen tárolják, titkosított formában, amihez csak jelszóval lehet hozzáférni vagy egy speciális kulcstárolón. Ez általában egy smart card (intelligens kártya) vagy újabban egy USB token. A kulcstárolók megfelelnek egyfajta számítógépnek, hiszen rendelkeznek központi feldolgozó egységgel, memóriával, háttértárral. A PKI rendszerekben felhasználható kulcstárolókban van egy speciális segédprocesszor, ami képes a kriptográfiai m veleteket végrehajtani. Ezek a rendszerek jól védettek, csak jelszó segítségével lehet hozzájuk férni.
3.2.2 A digitális aláírás felhasználási területek szerint
3.2.2.1 Az Európai Unió elképzelései Magyarország közelg Európai Uniós csatlakozása miatt el ször érdemes megvizsgálni, hogy az EU hol képzeli el az elektronikus aláírás használatát. Ehhez érdemes áttekinteni az eEurope kezdeményezés idevágó pontjait. Az e-Europe kezdeményezés 3 pilléren alapul. Ezek közül számunkra a harmadik az érdekes, ami „ Az Internet használatának ösztönzése” címet viseli Ebb l az els két pont kapcsolódik a diplomamunka témájához. Ennek els pontja „ Az elektronikus kereskedelem gyorsításáról” szól. Az elektronikus kereskedelem címszó alatt nem csak az ügyfél-eladó, más néven B2C kapcsolatot, hanem az üzletek közötti, B2B, és pl. az üzletek és kormányzat közötti B2G kapcsolatokat is értjük. Mindegyik különböz követelményeket támaszt, viszont közös bennük, hogy hiteles tranzakciókat kell folytatni egy szabványos elektronikus iratkezelési felületen. A szabványos iratkezelési platform az W3C XML nyelve. Erre épülve fejlesztik az XML aláírás, titkosítás és kulcs menedzsment szabványokat, amik a tranzakciók hitelességét teszik lehet vé nyilvános kulcsú infrastruktúra segítségével. Az elektronikus kereskedelem legkritikusabb pontja a kényelem és a bizalom. Az elektronikus aláírás tudatos használatával el lehet érni a felhasználókban a bizalom érzését. Így a jelenleg is széles körben használt vállalati PKI rendszerek mellett megjelenhetnek az egyéni felhasználók igényeit kielégít internetes boltok. A B2B kapcsolattartás pedig az eddiginél is könnyebbé válik, hiszen az elektronikus aláírás törvény rendelkezései miatt még nagyobb bizalommal használhatják érzékeny üzleti folyamatoknál. A második fejezet az „ On-line kormányzat – elektronikus hozzáférés a közszolgálatokhoz” nevet viseli. Az EU felismerte az elektronikus ügyvitel fontosságát, különös tekintettel a közvetlenebb demokráciára és a kisebb kiadásokra. Elkerülhetetlen tartani a lépést a vállalatokkal, akik már használják az új technológiákat. Éppen ezért 13 + 8 pontot határoztak meg, ahol érdemes áttérni az elektronikus ügyvitelre. Ezek a következ k:
19
3.2.2.1.1 Állampolgároknak szóló közszolgáltatások: • • •
•
•
• • • • • • • •
Adóbevallások beadása, értesítés a kivetett adóról A munkanélküli hivatalok munkaközvetítése Szociális segélyek igénylése, úgymint: o Munkanélküli segély o Családi pótlék o Az egészségügyi költségek elszámolása o Ösztöndíjak Személyes dokumentumok igénylése: o Útlevél o Személyi igazolvány o Vezet i engedély Gépjárm vek átíratása o Új gépjárm vek o Használt gépjárm vek o Importált gépjárm vek Építési engedélyek igénylése Rend rségi bejelentések Közkönyvtárak elérése o Katalógusok elérése o Keresési lehet ségek Anyakönyvi kivonatok igénylése és beadása o Születési anyakönyvi kivonat o Házassági anyakönyvi kivonat Fels oktatási jelentkezés beadása Lakcímváltozás bejelentése Egészségüggyel kapcsolatos ügyintézés o A különböz kórházak szolgáltatásainak elérése o Vizsgálati id pontok igénylése Közlekedéssel kapcsolatos ügyintézés o Parkolási információk o Tömegközlekedéssel kapcsolatos ügyintézés o Városi közlekedéssel kapcsolatos ügyintézés
A dolgozók után fizetend járulékok bevallása Ipar zési adó bevallása Általános forgalmi adó bevallása Új vállalkozás bejegyzése Statisztikai adatok benyújtása Vámterhek bevallása Eszközökkel kapcsolatos bevallási kötelezettségek Közbeszerzési eljárásokban való részvétel
Ez a lista többé-kevésbé lefedi azokat a területeket, ahol a kormányzati kapcsolatokat elektronizálása reális.
3.2.2.2 A gyártók szolgáltatásai Az EU-s elképzelések mellett érdemes még megnézni, hogy a PKI termékek gyártói milyen alkalmazásokat adnak el jelenleg. Ennek tanulmányozása során öt szektort lehet világosan elkülöníteni, a gyártók ide címezik a termékeiket. Az alábbiakban ezeket fogjuk felsorolni, mellettük a hozzájuk tartozó alkalmazásokkal. •
Üzleti szektor: o Cégen belüli folyamatok Biztonságos üzenetküldés: az évek során az e-mail elengedhetetlenül fontos részévé vált a vállalatok életének. Bár sokszor bizalmas adatok jelennek meg e-mailekben, kevés figyelmet fordítanak ezek biztonságára. Szükséges tehát az üzenetek bizalmasságának és sértetlenségének biztosítása. Mivel egy e-mail forrása elég nehezen meghatározható, a címekkel való visszaélés is el fordulhat. Elképzelhet továbbá, hogy egy vállalatnak sok küls munkatársa van, akiknek a személyazonosságát bizonyítani kell. Ezért a hitelesség is kritikus kérdés. Az e-mail mellett meg kell említeni a különböz messaging programokat (pl. ICQ, Windows Messenger), ami on-line kapcsolattartást tesz lehet vé, megbízhatatlan módon és a web alapú e-mail programokat. Ezek az üzenetküldési eljárások alapvet en befolyásolják egy cég életét, ezért nagyon fontos felhívni rá a figyelmet. Biztonságos kliensek: egy cég fontos dokumentumai mindig egy felhasználó kliens gépén keletkeznek. Éppen ezért a klienseket is legalább olyan jól, ha nem jobban kell védeni, mint a cég szervereit. ráadásul automatizáltan kell mindezt megtenni, hiszen a végfelhasználótól nem lehet olyan fokú informatikai tudást elvárni, mint egy szerverfelügyeletért felel s rendszergazdától. A legfontosabb tehát a dokumentumok bizalmassága. Másodsorban tör dni kell azzal, hogy a dokumentumokhoz az férhessen hozzá, akinek dolgoznia kell vele, tehát a hitelesség kérdését is meg kell oldani. A kliens gép lehet PC, notebook vagy PDA, lényeg, hogy a rajta lev adatok titkosítva legyenek, integritásuk biztosított legyen és csak az férhessen hozzá, akinek joga van erre. Biztonságos hozzáférés: a dokumentum hozzáférés mellett még sok helyen kell a személyazonosítást elvégezni. Ilyen az er forrásokhoz való hozzáférés, a számítógépek használata és a helyi hálózatba való belépés. Ennek megkönnyítésére szolgál a Single Sign On, azaz minden felhasználóhoz tartoznak jogosultságok, amiket egy belépéssel tud elérni. 21
Ezt érdemes úgy megoldani, hogy a tudásalapú, birtokalapú és biometriai azonosítások közül kett legyen szükséges a belépéshez. Ez hagyományosan egy jelszó és egy (esetleg titkos kulcsot) tartalmazó kártya segítségével megoldható. Virtuális magánhálózatok (VPN), vezeték nélküli hálózatok (WLAN): napjainkban a legtöbb vállalatnál megtalálhatók a különböz számítógépes hálózatok. Ezek hagyományosan rengeteg kábelt, több telephely esetén pedig bérelt vonali összeköttetést jelentenek. Ezek kiválthatók a VPN és Wireless LAN technológiákkal. A VPN egy olyan magánhálózat, ami kiváltja a drága bérelt vonalat, és helyette az Interneten köti össze a cég telephelyeit. Teljes mértékben Internetes technológiákon alapul, ennek minden veszélyével. Szükség van tehát a nagyobb biztonságra. Ez PKI technológiával elérhet , hiszen leváltja a régi felhasználónév/jelszó azonosítást. A WLAN technológia a házon belüli hálózat kiváltására szolgál, hiszen megszabadulva a vezetékekt l, az iroda teljesen szabad berendezését és mobilitását biztosítja. Mivel a rádióhullámok nem ismernek épületfalakat, a jelenlegi technológiákkal viszonylag könny egy ilyen hálózatba betörni. Fontos a hitelesség és a bizalmasság megteremtése, így a legtöbb visszaélés elkerülhet . o Cégek közötti folyamatok Biztonságos ERP, CRM, HR folyamatok: a cégen belüli biztonság az ideális szintet akkor éri el, ha már a különböz üzleti folyamatok is biztonságosak. Miután nagyvállalatoknál már teljesen IT alapú az üzleti folyamatok kezelése, ezek tervezésénél figyelembe kell venni azt, hogy az adatok titkosan közlekedjenek, a folyamatokba csak az arra jogosult emberek tekinthessenek be és az adatok ne sérülhessenek. A PKI szoftverek jellemz en egy másik szoftver mellett jelennek meg, kiegészítve azt. Elektronikus ügyiratkezelés: B2B kapcsolatoknál mindig keletkeznek olyan dokumentumok, amiket kezelni és tárolni kell, úgy hogy hitelesek legyenek. Optimális esetben ezek a dokumentumok digitális formátumban vannak. Mivel ezek többnyire nem nyilvánosak, meg kell oldani a titkosításukat. Kés bb bizonyító erejük kell, hogy legyen, ezért hiteleseknek és letagadhatatlanoknak kell lenni. Emellett vigyázni kell az integritásukra. Ez a legösszetettebb feladat, amit egy cégnek meg kell oldania, de számottev költségcsökkenés érhet el vele. Biztonságos csoportmunka: egy olyan cégnél, ahol távmunka folyik vagy távoli telephelyek dolgozóinak kell együttm ködni, meg kell oldani a biztonságos csoportmunkát. A felhasználóknak tudniuk kell, hogy kivel dolgoznak, munkájuknak bizalmasnak kell lenni. Az er források kiosztásánál is tudni kell, hogy ki használja a rendszert.
22
Csoportszoftverek alatt többek között az ütemez ket, kalendáriumokat, Electronic Meeting Systemeket, üzen táblákat, konferenciaszoftvereket, fórumokat, csoportos fejleszt eszközöket, csoportos szerkeszt ket értjük. o A cég és az ügyfelek közötti kapcsolat Biztonságos rlapok: az Internetes kereskedelem, kapcsolattartás során sokszor találkozhatunk rlapokkal (formokkal). Ezek biztonságos és hiteles kitöltése, az integritás meg rzése és a letagadhatatlanság az elektronikus kereskedelem alapvet kérdése. Az ügyfelekkel kapcsolatos legtöbb Internetes szolgáltatás elképzelhetetlen rlapok nélkül. Mindez PKI rendszer segítségével megoldható. Szolgáltatások on-line igénylése: biztonságos rlapokkal elkerülhet a sorban állás, a drága ügyfélszolgálatok fenntartása, egyszer bbé válik az élet. Bár telefonos ügyfélszolgálatok most is m ködnek, vannak olyan el fizetések, amit az ügyfeleknek még mindig személyesen kell elintézniük, holott ez csupán a személyi igazolvány bemutatása miatt szükséges. Ezt a tanúsítványokkal ki lehetne váltani. On-line játékok: az Interneten egyre jobban terjednek az on-line játékok. Pl. egy kaszinó alkalmazásnál elképzelhet , hogy valakinek a hitelkártyájával visszaélnek. Éppen ezért szükséges a hitelesítés. Ez persze els sorban a felhasználók igénye. •
Kormányzati szektor: Közbeszerzési eljárások: a jelenlegi költség és id igényes közbeszerzéseket mind az állam, mind a cégek számára átláthatóvá és egyszer vé kell tenni. Ennek legjobb módja egy központi közbeszerzési portál kiépítése, ahol a bizalmasság, a hitelesség, az integritás és a letagadhatatlanság megoldható PKI rendszerrel. Biztonságos rlapok Szolgáltatások on-line igénylése Elektronikus adóbevallások: a jelenlegi papír alapú adóbevallások beadás és ellen rzése is hatalmas költségcsökkenéssel jár. Ez már Magyarországon is megvalósulni látszik, igaz nem teljesen úgy, ahogy arra szükség lenne. A kormányzati szektor bels m ködésében és a vállalatokkal való kapcsolattartásban azonosnak min sül az üzleti szektorba tartozó entitásokkal.
•
Egészségügyi szektor:
23
Biztonságos adatátvitel: mivel a betegek egészségügyi adatai szigorúan titkos személyes adatnak min sülnek, nem szabad az egészségügyi informatikai rendszereket kitenni az adatlopás veszélyének. Fontos a bizalmasság. Biztonságos ügyiratkezelés: a betegek adataihoz csak az férhessen hozzá, akinek arra engedélye van. Sajnálatos módon a betegek jogai gyakran sérülnek, ráadásul a betegek sincsenek tisztában a jogaikkal. Az adatkezelés biztonságát PKI rendszerekkel rá lehet kényszeríteni a kórházi dolgozókra. On-line konzultáció: jobb min ség egészségügyi ellátás érhet el azzal, hogy az orvosnak nem csak a kórházban van konzultációs lehet sége, hanem akár az egész világon. De mivel személyes adatok futnak az Interneten, meg kell bizonyosodni arról, hogy ezek titokban maradnak, és csak azok tudják meg, akikre tartozik.
•
Az egészségügyi szektorra is érvényes a bels hálózaton belüli biztonság fontossága. Banki szektor:
Home-banking: a banki m veletek indításának, ellen rzésének leggazdaságosabb módja az Interneten keresztüli ügyintézés. Erre már számos példa van, hazánkban is m ködik olyan rendszer, ami PKI segítségével oldja meg az átvitel bizalmasságát, hitelességét, letagadhatatlanságát és sértetlenségét. Elektronikus t zsdézés: a t zsdén történ kereskedelem már most is teljesen elektronikus, itt terjedt el el ször a PKI rendszerek használata.
•
Telekommunikációs szektor: mivel a titkos kulcsokat többnyire intelligens kártyákon tároljuk, és a legelterjedtebb intelligens kártya a mobiltelefonokban használt SIM kártya, természetesnek t nik, hogy a digitális aláírás a jöv ben itt lesz a legelterjedtebb. A lehet ségek száma végtelen, a fenti felsorolásban lev legtöbb alkalmazás mobil környezetben is megoldható.
3.3 Elektronikus kereskedelmi rendszerek Az e-business fogalmát el ször 1997-ben az IBM definiálta. Eszerint ez nem más, mint „ sokszín üzleti értékek nyújtásának biztonságos, rugalmas és integrált megközelítése az alapvet üzleti folyamatokat futtató rendszerek és eljárások kombinálásával, kihasználva az Internetes technológiák nyújtotta egyszer séget és elérhet séget” . Addig az elektronikus üzlet csak a weben keresztüli eladásokat jelentette. Innent l viszont az e-business fogalmába más jelleg üzleti folyamatokat is be kell venni. Az e-business nem csupán technológia, hanem a meglev folyamatok hatékonyabbá tétele az Internet segítségével. Ahogy a hagyományos IT infrastruktúrát összekötjük az Internettel, egyb l e-businessr l beszélhetünk.
24
Az elektronikus üzlet azonban már az Internet kora el tt megjelent. A 70-es években azon vállalatok, akiknek rendelkezésére állt a megfelel hardver és szoftver környezet, már felhasználták az infrastruktúrát az egymással való kereskedésre. Kés bb kialakult az Electronic Data Interchange (EDI) szabvány, ami lehet vé tette a partnerek üzleti folyamatainak elektronikus összehangolását. A 90-es évek második felében az Internet azonban áttörést hozott a piacon. Korábban a helyi hálózatokat a kis- és közepes vállalatok nem engedhették meg maguknak, ezért az EDI szabvány sem tudott igazán széles körben elterjedni. Az olcsó világhálós adatátvitellel azonban elképzelhet vé vált pl. a kis és nagyvállalatok szoros együttm ködése elektronikus alapokon. Az Internet nemcsak szoftver és hardver, hanem a jöv (jelen?) üzletének és kommunikációjának a környezete is. Magába tudja foglalni a legtöbb meglev technológiát. A vállalati számítógépes hálózatok és a kommunikációs hálózatok mára a világháló részei. Ebben a rendszerben elképzelhet a különböz platformok együttm ködése, pl. e-mailr l faxot küldeni. Már az EDI-ben is megoldható volt a különböz nyelvek együttm ködése. Az Internet világában ez kiegészül a különböz rendszerek programnyelveinek együttm ködésével. Mindezen tulajdonságok miatt alkalmasak az Internetes technológiák az üzleti felhasználásra. A legf • • • • • •
bb okok, amiért egy vállalat kilép az Internetre: Piaci terjeszkedés: új szegmensek meghódítása. Láthatóság: a kiválasztott szegmensben történ markáns megjelenés. Érzékenység: a vásárlók és partnerek igényeinek legjobb kielégítése. Új szolgáltatások: a vásárlók és partnerek számára. Üzleti kapcsolatok meger sítése: a valós idej kapcsolatok minden résztvev fél számára nyereséget jelent. Költségcsökkentés: a termékek, szolgáltatások, támogatás és befektetések költségének csökkentése.
Az el nyök, amikkel az e-business jár: • Globális elérhet ség: az üzletek növelni tudják a vásárlói bázisukat és a termékskálájukat. • Közeli kapcsolat: az üzletek közötti kapcsolat szorosabbá válik. • Ingyenes minták: a termékek bemutatói gyorsan, könnyen és ingyenesen megjeleníthet k a világhálón. • Csökkentett költségek: a dinamikus árazással az üzletek növelni tudják profitjukat. • Reklám: az Internetes megjelenés csökkenti az információk átviteléhez szükséges reklámmennyiséget. • Gyors reagálás: a piaci igényekhez való gyors alkalmazkodás. • Vásárlói h ség: a szorosabb vásárlói kapcsolatokkal könnyebb az információk átadása. Az e-businessel kapcsolatos aggodalmak: • Verseny: a helyi verseny globális versennyé válik. • Szerz i jogok: az Interneten található tartalom könnyen másolható. • Vev i elfogadás: sok üzlet fél attól, hogy vásárlói nem fogják elfogadni az új csatornát. • Jogi kérdések: a jogi szempontból az Internet kevéssé szabályozott.
25
• • • • •
Lojalitás: a világháló személytelen, ezért nem biztos, hogy a vev marad az adott vállalatnál Árazás: a weben könnyebb az árakat összehasonlítani, ezért az árak esnek, a min ség és a hozzáadott szolgáltatások el térbe kerülnek. Biztonság: az Internetes vásárlás egyik legf bb kerékköt je, hogy a partnerek nem bíznak meg a világháló biztonságában. Szolgáltatások: a vev a különböz cégek szolgáltatásait is könnyebben össze tudja hasonlítani. Megvalósíthatóság: sok cég nem bízik az új csatorna megvalósíthatóságában.
Az elektronikus üzlet tehát egy halmaz, aminek elemei nem a felhasznált technológiától, hanem az üzleti modellt l függ. Az id el rehaladtával egyre több üzleti szegmens válik hálózativá. Néhány ezek közül [Amor01]: •
•
•
•
26
E-aukció: a hagyományos aukciók megkövetelik az emberek és tárgyak adott helyre való mozgatását. Esetleg hosszú telefonos kapcsolatra van szükség a licitáló és az aukciós ház között. Általában a licitálók zárt körb l kerülnek ki. Az Internet segítségével sokkal demokratikusabbá lehet tenni az árveréseket. Bárki, bárhonnan megteheti ajánlatát, ráadásul az aukció is gyorsabb lefolyású. Ráadásul a hagyományos árverések mellett lehet ség van akár hetekig tartót is szervezni. Ekkor sokkal szélesebb körben ismerik meg az eladandó árut, magasabb téteket lehet kapni. Az áruról minden információ részletesen megadható. A legismertebb aukciós webhely az amerikai eBay. E-bank: az elektronikus bank az egyik legsikeresebb e-business modell. Segítségével az ügyfél többek között le tudja kérdezni egyenlegét, és átutalásokat tud indítani. Ehhez mindössze egy böngész szükséges a kliens oldalon. A bank számára ráadásul egy on-line tranzakció olcsóbb, mintha az ügyfél akár a telefonos ügyfélszolgálaton indítaná átutalását. Az e-bank megvalósítható PKI alapú rendszeren, erre hazánkban is van példa. E-kereskedelem: talán a legismertebb e-business modell. Közismertebb neve ecommerce. Egy Internetes boltnak a nyitva tartása 24 órás az év minden napján. A virtuális polcrendszer mérete gyakorlatilag végtelen. Az Amazon.com 4,7 millió könyvet kínál eladásra. Ez egy hagyományos könyvesbolt esetében elképzelhetetlen. Mindezek teszik a világhálót kiválóan alkalmassá a kereskedésre. Cserébe a keresked nek alaposabb stratégiát kell kidolgoznia, mint hagyományos esetben. E-marketing: a hagyományos marketing csak a célcsoportra és a pozitív imázsra koncentrál. A kommunikáció csak egyirányú. A vezetés nem érzékeli azonnal a visszajelzéseket. Az információs világban mindet máshogy van. A termékeket, a stratégiát, az árakat a vásárló igénye alakítja. Az egész folyamat középpontjában a vásárló áll. A vev valós id ben reagál a stratégiára, amib l a marketing csapat azonnal következtetéseket tud levonni. Ráadásul lehet ség van személyre szabott stratégiával is el állni, ami még hatásosabbá teszi az üzletmenetet.
Az e-business látható.
létrehozásának
Létrehozás
Átalakítás
spirális
folyamata
a
10.
ábrán
M ködtetés
Hasznosítás
11. ábra: Az e-business spirál [Szigeti01]
A létrehozás során a felgy lt tapasztalatok és elképzelések alapján, az új igényeknek megfelel en kialakítunk új, az Internet technológiákra alapuló szolgáltatásokat és folyamatokat. A m ködtetés alatt az újonnan kialakított rendszereket beillesztjük a meglév keretekbe és használatba vesszük. A hasznosítás a m ködtetés alatti tapasztalatok kinyerése, pl. adatbányászati és tudásmenedzsment eszközökkel. Az átalakítás folyamán a rendszert az új igényeknek megfelel en, a tapasztalatok alapján alakítjuk át. Ezzel újabb kör kezd dik a spirálban. Az e-business tipikus feladataira különböz sémákat lehet kidolgozni: • Ügyfél – vállalat (user to business) • Ügyfél – online vásárlás (user to online buying) • Vállalatközi (business to business) • Ügyfél – adatelérés (user to data) • Ügyfélközi (user to user) • Alkalmazásintegráció (application integration)
3.4 Biztonsági min sítések A biztonsági auditálás célja a meglev technikai és szervezeti biztonsági intézkedések hatékonyságának a vizsgálata, a fenyegetettségek vizsgálata és a kockázat elemzése a szabályzatok, ajánlások, el írások teljesülése mértékében. Az audit lehet küls (pl. pénzintézetek kötelez ellen rzése) vagy bels (a cégvezetés kezdeményezésére). Az ellen rzés során el kell tekinteni a kizárólag m szaki szemlélett l, hiszen a szervezet 27
ismerete nélkül nem lehet sikeres munkát végezni. A gyakorlatban használatos auditálási eljárások a 11. ábrán láthatók. CobiT Összetett IT rendszerek
ISO TR 13335 IT Baseline Protection Manual ISO/IEC 17799
3.4.1 Auditálási szabványok FIPS 140-2: kriptográfiai modulok és egyedi IT eszközök kipróbálására szolgál. A szabvány meghatározza azokat a biztonsági követelményeket, amelyeket egy kriptográfiai modulnak teljesítenie kell, ha az a biztonsági rendszert véd érzékeny, a szabványban meg nem határozott információt tárol. A szabvány négy, emelked számozású min ségi osztályt különböztet meg. Ezek az osztályok hivatottak lefedni minden olyan alkalmazást és környezetet, amelyeket a kriptográfiai modul használ. A szabvány a modul biztonságos tervezésére és megvalósítására koncentrál. A FIPS 140-2 szabvány váltotta ki a FIPS 140-1 szabványt. [NIST01] ITSEC/Common Criteria: biztonsági ajánlás. Jelenlegi, 2.1-es változata az ISO/IEC 15408-as szabványa. A Common Criteria alapjául több nemzeti biztonsági szabvány szolgálta. Az els pillére az USA-ban használatos TCSEC, ami 1980-ban látott napvilágot az operációs rendszerek vizsgálatára (Orange Book). Kés bb ezt kiegészítették további kötetekkel (Rainbow Series). A TCSEC biztonsági osztályokat definiál. Másik pillére az 1991-ben megjelent, francia, német és angol fejlesztések alapján készült ITSEC. Ez a veszélyek kiküszöbölésére tett intézkedések ellen rzésére szolgál. Különböz szint vizsgálat lehetséges az ellen rzés mélysége és a megrendel elvárásainak megfelel en. Az ITSEC 7 biztonsági szinttel rendelkezik. A gyakorlatban viszont rugalmasabb megközelítésre volt szükség, ezért a különböz szabványok alkotói tapasztalataikat az 1996-ban megjelent Common Criteria modellben összegezték. A Common Criteria m szaki szemlélet szabvány, célja az IT rendszer biztonságát veszélyeztet fenyegetettségek és az ezek kivédésére szánt biztonsági funkciók vizsgálata. Ennek strukturális összegzése a Protection Profile, védelmi profil. A CCnek három célcsoportja van: a fejleszt k, akik a PP alapján biztonsági rendszertervet tudnak csinálni, a felhasználók, akiknek a termékválasztásban segít és az auditorok, 28
akiknek a közös szemlélet alapját nyújtja. A CC-nek nem része a környezet, a szervezet vizsgálata, a jogi, adminisztrációs ellen rzés és a speciális biztonsági mechanizmusok elemzése. ISO/IEC 17799: alapja a British Standard Institute BS7799 számú szabványa, amit 1995-ben hoztak nyilvánosságra. Célja egy biztonsági mátrix létrehozása az akkor induló e-business rendszerek számára. Els része, a Part I. a biztonsági menedzseléssel foglalkozik, második része, a Part II. a min sítési eljárást írja le. 1999-ben a BSI átdolgozta, hogy nyitottabb és még több szervezet számára is elérhet legyen. 2000 augusztusában nyújtották be az ISO-nak a Part I.-t, hogy nemzetközi szabvánnyá váljon. Azonban több ország – pl. az USA, Németország és Franciaország – ellenezte az elfogadását. Szerintük ajánlásnak alkalmasabb lenne, mint szabványnak. Az ISO ennek ellenére hamar elfogadta. A Part II. nem része a szabványnak. Az ISO/IEC 17799 nem nevezhet technológiai szabványnak, hiszen tág, üzleti megközelítést használ bármilyen információ védelmére vonatkozóan. Röviden az információbiztonság menedzselési segédletének tekinthet . 10 területet fed le. Ezek: biztonsági politika, biztonsági szervezet, eszközök osztályozása és felügyelete, személyzeti biztonság, fizikai és környezeti biztonság, kommunikációs és környezeti biztonság, hozzáférés ellen rzés, eszközfejlesztés és üzemeltetés, üzleti folytonosság menedzselése, el írások teljesítése. [Walsh02] IT Baseline Protection Manual: a német Bundesamt für Sicherheit in der Informationstechnik szervezet szabványa. Célja az információs rendszerek biztonságának megteremtése infrastrukturális, szervezeti, személyzeti és technológiai néz pontból. A szabvány komponens orientált. Részletesen kifejtett biztonsági elvárásokat tartalmaz, amik gyakorlatilag az összes IT rendszerre használhatóak. Magába foglalja az általános biztonsági szinteket, amik az informatikai rendszereknél elvárhatók, a fenyegetettségek meghatározását, a védelmi intézkedések implementációjához szükséges segítséget, a megfelel biztonsági szint eléréséhez szükséges intézkedéseket és ennek a szintnek az ellen rzését. Alkalmazkodva a gyorsan változó technológiához, az IT Baseline Protection Manual könnyen frissíthet . ISO TR 13335: a hatékony IT biztonság elérést segít Technical Report az ISO-tól. 5 fejezetb l áll. Az els fejezet az alapvet fogalmakat és modelleket tárgyalja, amik kés bb részletesen lesznek kifejtve. A második fejezet a tervezést segíti. Ez a fejezet tárgyalja az IT biztonság céljait, stratégiáit és vezérelveit, a szervezeti biztonsági követelményeket, a fenyegetettségek kezelését, a védelmi intézkedések megtervezését, a biztonsági tudatosság elérésének lépéseit, az ellen rzést és az incidensek kezelését. A harmadik fejezet foglalkozik a kockázatkezeléssel, az IT védelmi tervek kidolgozásával, létrehozásával és tesztelésével. A negyedik fejezet a védelmi igényeknek megfelel védelmi intézkedések kiválasztásában segít. Leírja, hogy hogyan lehet az elvárt védelmi szintet elérni, illetve a szervezet részér l milyen tevékenységek szükségesek.
29
Az ötödik fejezet az IT biztonságért felel s hálózatokkal és kommunikációs csatornákkal foglalkozik. CobiT: az Egyesült Államok információrendszer-ellen rök szövetsége, az ISACA által kiadott ajánlásgy jtemény. Els sorban üzleti megközelítés , vezet i szemlélet , alapja a nagygépes pénzügyi rendszerek ellen rzésének eljárása. els sorban a pénzügyi szektorban használatos. Célja az üzleti folyamatok megvalósításának biztosítása az IT eszközök felhasználásával. Jelenleg a CobiT 3rd Edition használatos. Komplex vizsgálatot tesz lehet vé. Hat kötetb l áll. Framework: elmagyarázza, hogy az informatikai folyamatok hogyan kezelik az üzleti célok eléréséhez szükséges információkat. Az információtovábbítást 34 magas szint szempontból vizsgálja meg. Meghatároz hét információs kritériumot (hatásosság, hatékonyság, bizalmasság, sértetlenség, rendelkezésre állás, megfelel ség, megbízhatóság) és öt er forrást (emberek, adatok, technológiák, alkalmazások, létesítmények), amik különösen fontosak ahhoz, hogy az IT folyamatok segítség az üzleti célokat. Executive Summary: a fels vezet knek szóló összefoglaló. Tartalmazza a CobiT céljait és elveit, a Framework vázlatát, ami részletesen tartalmazza az elveket és meghatározza a négy nagy tárgykört (Planning & Organization, Acquisition & Implementation, Delivery & Support, Monitoring) és a 34 IT folyamatot. Implementation Tool Set: tartalmaz Menedzsment Tudatosság és IT Irányítás Ellen rzési eljárásokat, Implementációs Útmutatót, gyakran ismételt kérdéseket, esettanulmányokat és bemutatókat. Segíti a CobiT megismertetését és bevezetését, a fels vezetésnek támpont a megfelel választáshoz. Audit Guidelines: a 34 magas szint IT folyamathoz javasol ellen rz tevékenységeket, illetve bizonyítja azokat a veszélyét, amelyek az egyes folyamatoknál a védelmi intézkedések hiánya esetén felléphetnek. Javaslatokat ad az auditoroknak, hogy hogyan készítsék fel a vállalatot a célok eléréséhez. Control Objectives: részletes intézkedési útmutató a 34 folyamatra. Összesen 318 részfolyamatot fejt ki. Platformfüggetlen szempontokat fogalmaz meg. Management Guidelines: mér számok segítségével segítséget nyújt a döntésekhez. Négy jelz számot vezet be: Maturity Models: hol állunk a többiekhez képest?; Critical Success Factors: mi a fontos és mi a kevésbé fontos?; Key Goal Indicators: valóban teljesülnek a céljaink?; Key Performance Indicators: mik a jó teljesítmény jellemz i? [KM02]
3.4.2 Az auditálás folyamata Az auditálás a vagyontárgyak sebezhet ségéb l következ fenyegetettségek hatásait vizsgálja, ezzel felméri az adott vagyontárgyhoz kapcsolódó kockázatot. A cél olyan állapot elérése, amelyben a kockázatok megvalósítható és értékarányos védelmi intézkedésekkel a vezet ség által meghatározott elviselhet ségi szintre csökkennek. Ehhez intézkedési célokat szükséges kit zni és megvalósítani. 30
Az auditálás általános folyamata az audit tárgyának és terjedelmének a meghatározásával kezd dik. Ekkor kell megismerni az el z audit eredményeket, beszélgetéseket folytatni a vezet kkel és a dolgozókkal, megismerni az egész szervezetet. Ezután fel kell mérni az igényelt er forrásokat és ki kell választani az auditálási módszert és az ehhez szükséges eszközöket. Ha mindez rendelkezésre áll, akkor kell az adatgy jtést és a tesztelést lefolytatni. Ez lehet megfelel ségi teszt, ami az eljárások és el írások tesztje, vagy lényegi teszt, ahol a nem megvalósított intézkedési célok kockázatának igazolására analitikus teszteket folytat le az auditor. Az utolsó lépés egy beszámoló elkészítése.
31
4 A vállalat vizsgálata 4.1 Jelenlegi infrastruktúra A vizsgálandó vállalat jelenleg egy internetes hardverportál fejlesztésével és tartalomszolgáltatással foglalkozik. Okulva az elmúlt évek tapasztalataiból, miszerint tisztán a hirdetésekb l nem lehet hosszú távon fenntartani az oldalt, korábban már megpróbálkozott az elektronikus kereskedelemmel, mely során számítógép alkatrészeket forgalmazott. Ez a próbálkozás azonban nem volt jól el készítve. Az ekereskedelmi szoftver rendelkezésre áll, azonban nem felel meg a biztonsági kritériumoknak, ezért szükséges azt továbbfejleszteni. A fejlesztés alapja a nyilvános kulcsú infrastruktúra bevezetése. A vásárlók az oldal olvasói közül kerülnek ki. k általában vagy magasan kvalifikált informatikai döntéshozók vagy döntésel készít k, vagy számítástechnikában járatos diákok. Ennél a közönségnél könnyen el lehet fogadtatni az új technológiákat, ezért érdemes az országban els ként olyan B2C kereskedelmet kipróbálni, ami használja az elektronikus aláírást. A vállalat informatikai berendezései jelenleg három jól elhatárolható helyen találhatók. A legfontosabb, a vállalat igazi értékét képvisel berendezés a webszerver, ami egy internet-szolgáltató szerverfarmján van. Itt az alapvet fizikai védelem biztosított számára. Az informatikai védelem azonban súlyos hiányosságokat mutat. Az elektronikus bolthoz tartozó adatbázis ugyanazon a gépen van, mint a webszerver, tehát nincs kialakítva demilitarizált zóna. Ezért sürg sen ki kell alakítani egy adatbázisszervert, hiszen így a bizalmas adatokat tartalmazó tábla ki van téve mind a szándékos, mind a véletlen károkozásnak. A szerver nincs tükrözve, így el fordulhat a több órás leállás is meghibásodás esetén. A javításra és újraindításra feljogosított személyek száma limitált és a szerverfarmra való bejutásuk is problémás. Javasolt ezért egy tüköroldal létrehozása, ahova probléma esetén át lehet irányítani a forgalmat A szerkeszt ségi számítógépek rendelkezésre állása kevéssé kritikus. Az itteni szervernek csak az újságírók Internet kapcsolatát kell biztosítania. Emellett a t zfal feladatát is ellátja. A bels hálózaton lev gépek védelme az elvárható szinten van megvalósítva. Itt jelenleg semmilyen olyan tevékenység nem folyik, ami szükségessé tenné a rendszer további er sítését. A harmadik telephelyen m ködik a pénzügyi részleg. Itt folyik a könyvelés és a banki tranzakciók. Megoldott a biztonsági mentés és a behatolások elleni védelem. A felhasználók felkészültek a bizalmas adatkezelésre. Egyetlen gyenge pont a banki kliens, ami a nyilvános telefonhálózaton keresztül fér hozzá a bank központi szerveréhez. Ahogy lehet, át kell térni az Internetes ügyintézésre. A rendszerhez négyféleképp lehet hozzáférni. A legalapvet bb hozzáférés az olvasás. Ekkor a felhasználó csak a saját adatait tudja módosítani, valamint új hozzászólásokat tud a rendszerbe vinni. Kiemelt felhasználók a moderátorok, akiknek jogukban áll a
32
hozzászólásokat módosítani, illetve bizonyos esetekben a felhasználók adatait is módosítani illetve törölni. Az újságírók szerkeszt i modulon keresztül tudják cikkeiket felvinni a rendszerbe. Be tudják állítani a cikkek összes paraméterét. Bizonyos szerkeszt k jogosultak a többiek cikkeinek módosítására, javítására, átütemezésére. A szerkeszt knek általában nincsen moderátori jogosultsága. A teljes hozzáférés csak két embernek áll lehet ségében. k képesek a fejlesztési feladatokat ellátni. Minden, felhasználókkal és szerkeszt kkel kapcsolatos feladatot jogukban áll elvégezni. Mivel el fordul, hogy kevésbé védett kliensekr l lépnek be a rendszerbe, fokozott figyelemmel kell rájuk lenni.
33
Könyvelés
Webszerver
Internet
Router, fájl szerver, t zfal
Szerverfarm
Banki kliens
Pénzügyi részleg
Router, fájl szerver, t zfal
Szerkeszt ség … Engine fejlesztés Szerkesztés
szerkesztés olvasás fejlesztés Jelmagyarázat 13. ábra: Jelenlegi infrastruktúra
… Olvasók
4.2 Az elektronikus aláírás használatának indoklása Az Internet terjedése, az Internet-használók számának növekedése lehet séget teremtett arra, hogy a világ legkülönböz bb pontjain él emberek, cégek – akár ismeretlenül is – kapcsolatba kerülhessenek egymással, így az internetes világban egyre n az igény a kézjeggyel történ hitelesítés elektronikus megfelel je iránt. Az egyszer levelezést l a kormányzati ügyeken át a pénzügyi tranzakciókig mindenhol szükségessé vált az ügyfél egyértelm beazonosíthatósága, és az általa küldött üzenet hitelessége. Az „ arc nélküli” , elektronikus világban nehéz kideríteni, hogy „ ki ül a vonal túlsó végén” , hogy pontosan kit l is kaptuk az üzenetet, de a digitális aláírás használatával megoldhatóvá válik a másik fél azonosításának problémája. Az egyszer levelezésen túl a kommunikációs csatornákon más üzenetek is vándorolhatnak. Ma már elfogadott, hogy szerz déseket küldenek egymásnak a partnerek Interneten keresztül. Ezen üzenetek továbbítása és aláírása során szerepet kapnak kriptográfiai eljárások. A cégek szintjén történ elektronikus kereskedelem (B2B, Business-to-Business) mellett már a magánszférában is teret hódít az „ e-business” . Az Egyesült Államokban az Internet-használóknál már bevett szokás, hogy a különböz katalógusokat Interneten keresztül rendelik meg, s abban böngészve választják ki a kívánt árut, s adják fel rendelésüket az Interneten – akár kihasználva a digitális aláírást. Magáról a használatról azonban az átlagember nem is biztos, hogy tud, hiszen az internetes kereskedelemben lév pénzmozgást segít protokollok (pl. SSL – Secure Socket Layer, SET – Secure Electronic Transaction) automatikusan elvégzik ezt. Magyarországon még nem örvend ilyen nagy népszer ségnek az Internet, illetve a benne rejl lehet ségek, mint az elektronikus kereskedelem, de a jogi háttér megszületésével elképzelhet , hogy a következ néhány évben ugrásszer en meg fog n ni itthon a digitális aláírást használók száma. A jogi háttér fontos a kereskedelemben is, de a digitális aláírás kapcsán szokták emlegetni az elektronikus kormányzat, elektronikus önkormányzat fogalmát is, aminek megteremtéséhez szintén szükséges volt a megfelel szabályozás. Az állampolgári bürokratikus ügyek közt els ként hozzák fel az adóbevallást, mint olyan hivatalos iratot, amit érdemes lenne elektronikus formában, digitálisan aláírva elküldeni az illetékes hatóságnak. Elektronikus adatszolgáltatásra már korábban is volt példa: a TB bevallásokat lehetett mágneses adathordozón beadni, de a mágneses adathordozók tárolása hatalmas problémát okozott. A 2001-ben elvégzett [SzK01] közvélemény-kutatás választ próbált kapni arra, hogy az Internetet használó közösség hogyan fogadná az elektronikus aláírást, illetve milyen félelmei vannak az elektronikus kereskedelemmel kapcsolatban. A kérd ívet 390 személy töltötte ki. A legtöbben attól félnek, hogy levelezésükhöz illetéktelenek is hozzáférnek (22,1%) és hogy böngészésüket megfigyelik (19,8%). Ha viszont azt nézzük meg, hogy egy cég világhálós jelenlétében mi okozza a legnagyobb veszélyt, már egészen más eredményre jutunk. Bár itt is az els veszély az, hogy a levelezéshez más is hozzájut (23,1%), szorosan a második helyen szerepel az a veszély, hogy a cég nevében illetéktelen személy küld levelet (22%). Elmondható tehát, hogy egy vállalat életében fontos az üzenetek hitelessége. 35
Felmerült az a kérdés is, hogy milyen területen használnák a válaszadók az elektronikus aláírásukat. Itt három válasz szorosan követte egymást. A banki tevékenység (27,4%) és az elektronikus levelezés (27,3%) mögött az elektronikus kereskedelem jutott dobogós helyezéshez (25%). Mindezt viszont csak akkor vennék igénybe, ha tanúsítványukra havonta kevesebb, mint 1000 forintot (70,9%) kellene költeniük, és ezt is éves átalánydíjban tudnák megfizetni (75,4%). A válaszadók az elektronikus aláírás minél egyszer bb használata esetén választanák csak a szolgáltatást (88,6%), nem kívánnak elmélyedni a technikai részletekben. A többség viszont elkezdené használni a szolgáltatást, ha a hozzávaló infrastruktúra (pl. smart card) akár állampolgári jogon, akár munkája miatt a rendelkezésére állna (57,7%). Viszont 71,8%-uk úgy gondolta, hogy az elektronikus aláírás lassan, több év alatt fog elterjedni. Az utóbbi években Magyarországon is egyre jobban elterjedtek az elektronikus boltok. Annak ellenére, hogy viszonylag alacsony a magyar netez k száma, ezen boltok forgalma egyre nagyobb. Az igazán nagy áttörés azonban a felhasználók bizalmatlansága miatt még várat magára. Az Egyesült Államokban az elektronikus kereskedelem sikertörténet. Ez annak köszönhet , hogy a kereskedelmi szokások teljesen mások, mint Európában. Itt a vásárlók sokkal kevésbé hajlandók kiadni bankkártya számukat egy Internetes keresked nek, még akkor is, ha azt a céget jól ismerik. Ha azonban az elektronikus kereskedelmi eljárások közelítenének a hagyományos megoldásokhoz, talán megn ne a bizalom az ilyen jelleg tranzakciók iránt. Ha a vásárló tudja, hogy kivel áll szemben, ha tudja, hogy az on-line kereskedelmet is törvények szabályozzák, ha a kártyaszámát csak a bankjának kell kiadnia, sokkal szívesebben használná az új kereskedelmi csatornákat. Mindez a keresked re is igaz, hiszen egy nagy érték megrendelés esetén egy aláírt szerz déssel a zsebében sokkal kisebb annak az esélye, hogy a megrendelt áru a nyakán marad. Egy elektronikusan aláírt megrendelési szerz dés tehát mind a vev bizalmát, mind az eladó biztonságát növeli.
4.3 A vállalat kockázatelemzése 4.3.1 Bevezetés A kockázatelemzés célja a vállalat veszélyeztetettségének els felmérése. Ennek nincs általánosan elfogadott szabálya, jelen dolgozatban a [NECC00] ajánlást használtuk fel, ami kifejezetten az elektronikus kereskedelem veszélyeinek felmérésére szolgál, alaposan tárgyalva a PKI rendszereket. A vizsgálat négy lépésb l áll. Az els egy magas szint kockázatelemzési áttekintés. Ezután részletes kérd ívek következnek az e-commerce tevékenységekkel kapcsolatos résztevékenységekr l. Az utolsó két lépésben kell kitölteni a veszélyforrás értelmez adatlapot és a kockázatelemzési grafikont. Jelen dokumentumban a részletes
36
kockázatelemzési kérd ívek kitöltése után ismertetjük az e-kereskedelmi rendszer megvalósítási architektúráját, aminek hatása van a rendszer veszélyeztetettségi mutatóira. Éppen ezért a javasolt architektúrát is beleértve a rendszerbe, a kérd ív azon pontjait, melyekre az új elemek hatással vannak, újra kitöltjük, és csak ezután végezzük el a harmadik és negyedik lépéseket. A magas szint kockázatelemzési áttekintés megkönnyíti a szervezet e-kereskedelmi tevékenységeivel kapcsolatos információk összegy jtését és elemzését. Segítségével meghatározhatók azok a rendszerek és alkalmazások, amik alaposabb vizsgálatra szorulnak. A vizsgálat tartalmazza a rendszerekben rejl veszélyek felismerését. Az eredmények alapján dönthet el, hogy a részletes vizsgálat milyen sorrendben történjen. A veszélyek min sítése lehet magas, alacsony vagy közepes. A veszélyeztetettséget a következ kritériumok alapján határozhatjuk meg: Magas a veszélyeztetettsége azon rendszereknek, melyek: • olyan nagy érték vagy kritikus tranzakciók futnak rajta, melyek megsz nése esetén a kereskedelmi vagy kormányzati folyamatok akadályozva vannak, vagy kés i feldolgozásuk az egészséget vagy a közbiztonságot negatívan befolyásolja. • olyan titkos vagy kényes adatot tartalmaz, melyek kikerülése valódi károkat tud okozni. • a népesség nagy százalékát érinti. • több rendszer résztvev i, ezzel más rendszerek veszélyeztetettségét is befolyásolják. Közepes a veszélyeztetettsége azon rendszereknek, melyek: • mérsékelt vagy alacsony összeg tranzakciókat futtatnak • olyan adatokat tartalmaz, melyek kellemetlenséget vagy apróbb problémákat okozhatnak. • a vásárlók kis százalékát érinti. Alacsony a veszélyeztetettsége azon rendszereknek, melyek: • függetlenek más rendszerekt l. • nyilvános adatokat tartalmaz. • a felhasználók elhanyagolható részét érinti. Egyes rendszerek kockázatát a fenti kritériumok mellett még a veszélyek bekövetkezésének valószín sége is befolyásolja. A kockázat tehát az adott id alatt a rendszert ért váratlan eseményekb l keletkez kár várható értéke. A szakirodalomban az r = pt × d t képlet t ∈T
használatos, ahol r a kockázat (risk), T a veszélyforrások (threats) halmaza, pt a t veszélyforrás valószín sége (probability), dt a t veszélyforrás bekövetkezésekor keletkez kár (damage). A részletes vizsgálat során öt veszélyeztetett területet vizsgálunk meg a [NECCC00] ajánlásnak megfelel en (Vezetés/Irányítás, Személyes adatok védelme, Biztonság, Jogi felkészültség, Vásárlói felkészültség és hozzáférés). A kérd ívek minden területen több 37
fontos vizsgálati szempontot tartalmaznak, amiket a mellékelt kérdésekkel lehet megvizsgálni. Minden vizsgálati területhez tartozik egy adatlap, amivel eldönthet , hogy az adott rendszer eleget tesz-e az elvárt követelményeknek. Az adatlap helyes kitöltéséhez alapos információkra van szükség. Az igen és nem válaszok mellett található még egy mez , ahol a kereszthivatkozásokat és a felhasznált dokumentumokat lehet beírni. Az auditor nem hagyatkozhat kizárólag a vállalattól kapott válaszokra, ki is kell próbálnia a különböz rendszereket, ezzel biztosítható a jól megalapozott rendszer. Az összefoglaló adatlap és grafikon segít az eredmények összegzésében és annak eldöntésében, hogy mely elemeknél szükséges további vizsgálat. El ször a kérd ívek után található adatlapokat kell kiértékelni. Minden vizsgálati szempontnál meg kell nézni a válaszokat, és ezek alapján egy ötös skálán kell értékelni az adott pontot. 1) A veszély nincs felismerve. 2) A veszélyt felismerték, de nem történt ellenintézkedés. 3) A veszélyt felismerték és alapvet intézkedések történtek az elhárítás érdekében. Alapvet intézkedésnek számítanak azok a formálisan dokumentált eljárások és szabályzatok, amik meghatározzák a célt, a hatáskört, a felel sséget, és tisztázza a folyamatokat, beleértve ebbe az eljárások és szabályzatok rendszeres átvizsgálását. 4) A veszélyt felismerték, de a védelmi intézkedések még nem lettek tökéletesen alkalmazva. Ekkor az új eljárások már a mindennapi munka részévé váltak és oktatásokon er sítik meg használatukat. A tulajdonosokat és a felhasználókat értesítették az új szabályokról. 5) A területet felügyelete teljesen ellátott és m köd képes. A szabályokat tesztelték, a tesztelést dokumentálták, minden változásnál ellen rzik, és újra kipróbálják. Ha minden területet pontoztunk, az eredményeket be kell vezetni a kockázatelemzési grafikonba. A legjobb az a megoldás, amikor minden vizsgálati szempont értékelése a fels régióba esik, különösen ott, ahol magas a veszélyeztetettség szintje. Ezekb l a lépésekb l eldönthet , hogy mely rendszereknél milyen ellenlépésekre van szükség.
4.3.2 Magas szint kockázatelemzési áttekintés A magas szint kockázatelemzési áttekintési adatlap kitöltése: • Soroljuk fel a meglev e-kereskedelmi rendszereket. • Soroljuk fel azokat az e-kereskedelmi elemeket, amiket a közeljöv ben be fogunk vezetni. • Szerezzük be a korábbi auditálási dokumentumokat. • Szerezzük be az e-kereskedelemmel foglalkozó személyzet oktatási anyagát. • Rajzoljuk meg a szervezet felépítését. • Minden rendszerhez gy jtsük össze az alábbi kérd ívben található kérdésekre kapott válaszokat.
38
Háttér Rendszer neve: Létrehozás dátuma: A technikai és m ködtet személyek felsorolása:
Internetes kiszolgáló 2001. 03. A. G., B. M.
A technikai és m ködtet személyzet vonatkozó oktatásának az ideje: (A jelenlegi és a tervezett oktatások ideje a következ évben
Kockázati mutatók Lekérdezések száma hetente: A lekérdezések utáni bevétel nagysága: Tranzakciók száma az ecommerce rendszerben: Az e-commerce rendszer utáni bevétel: Nyilvánosság foka: (magas, mérsékelt, alacsony) A rendszer m ködésének ideje: (id szakos, éves, periódikus) Az adatok bizalmasságának foka: (bizalmas, érzékeny, nyilvános) A rendszer típusa: (független, vállalati egységek közötti közötti, szervezetek közötti)
Válasz 500.000
Alacsony
Mérsékelt
Magas X X
X X Magas
X
Éves
X
Érzékeny
X
vállalati egységek közötti
X
Háttér Rendszer neve: Létrehozás dátuma: A technikai és m ködtet személyek felsorolása:
Szerkeszt ség 2003. 01. K. Cs., K. K., B. M.
A technikai és m ködtet személyzet vonatkozó oktatásának az ideje: (A jelenlegi és a tervezett oktatások ideje a következ évben
K. Cs., K. K.: Egyetemi képzés biztonságtechnika témában
39
Kockázati mutatók Lekérdezések száma hetente: A lekérdezések utáni bevétel nagysága: Tranzakciók száma az ecommerce rendszerben: Az e-commerce rendszer utáni bevétel: Nyilvánosság foka: (magas, mérsékelt, alacsony) A rendszer m ködésének ideje: (id szakos, éves, periódikus) Az adatok bizalmasságának foka: (bizalmas, érzékeny, nyilvános) A rendszer típusa: (független, vállalati egységek közötti közötti, szervezetek közötti)
Válasz 200
Alacsony X
Mérsékelt
Magas
X X X Alacsony
X
Periodikus
X
Bizalmas Független
X X
Háttér Rendszer neve: Létrehozás dátuma: A technikai és m ködtet személyek felsorolása:
Pénzügyi részleg 2001. 12. K. Cs., K. E.
A technikai és m ködtet személyzet vonatkozó oktatásának az ideje: (A jelenlegi és a tervezett oktatások ideje a következ évben
K. Cs.: Egyetemi képzés biztonságtechnika témában
Kockázati mutatók Lekérdezések száma hetente: A lekérdezések utáni bevétel nagysága: Tranzakciók száma az ecommerce rendszerben: Az e-commerce rendszer utáni bevétel: Nyilvánosság foka: (magas, mérsékelt, alacsony) A rendszer m ködésének ideje: (id szakos, éves, periódikus) Az adatok bizalmasságának foka: (bizalmas, érzékeny, nyilvános)
40
Válasz 300
Alacsony
Mérsékelt X
Magas
X X X alacsony
X
éves
X
bizalmas
X
A rendszer típusa: (független, vállalati egységek közötti közötti, szervezetek közötti)
független
X
Magas szint kockázatelemzési kérd ív
ID Vizsgálati szempont O.1 Hatékony elektronikus kereskedelmi rendszer létrehozásához er s vezetés, felhatalmazás és tisztázott viszonyok szükségesek. O.2 Megfelel infrastruktúrának lennie.
Kérdések Létezik olyan központi szervezet, ami felügyeli az e-commerce létrehozását?
A fels vezetés engedélyezte a rendszer létrehozását?
Igen Nem X
X
IT kell Korábbi bels vagy küls auditálás nem talált a rendszerben jelent s gyenge pontot? A korábbi auditok hatékonynak találták az általános felügyeletet?
Rendszeresen történnek kockázatelemzések, amik bizonyítják, hogy a változások nem befolyásolják a rendszer biztonságát? O.3 A vonatkozó törvényeknek Történt konzultáció jogi megfelel rendszert tanácsadóval az e-commerce jogi szükséges létrehozni alapjainak megismerése érdekében? O.4 A m ködtet Vannak olyan bels szabályok és infrastruktúrának eljárások, amik biztosítják az emegfelel szabályzatokkal commerce-hez kapcsolódó és folyamatokkal kell jogszabályok betartását? rendelkeznie valamint a hatékony és hatásos Az üzleti folyamatok át lettek rendszer fejlesztésére kell szervezve, úgy, hogy a szervezet ki koncentrálni. tudja használni az elektronikus kereskedelemmel járó költségmegtakarításokat? O.5 Hatékony rendszerfejlesztési technikákat kell alkalmazni, amik biztosítják az e-commerce rendszer kifejlesztési ciklusának rövidségét.
WP Ref
X
Nem volt ilyen korábban
X
Nem volt auditálás korábban
X
X
Számviteli szabályzat
X
X
A rendszer szabványos módszerrel lett kifejlesztve, figyelembe véve az üzleti és magánfelhasználók igényeit?
X
A rendszerfejlesztési id keretek léteznek és be vannak tartva?
X
41
Létezik vezet i ellen rzés a rendszerfejlesztés alatt, ami biztosítja, hogy a feladatok megfelel en legyenek elkülönítve, a változásmenedzsment helyes legyen és a tesztelési eljárások létezzenek?
X
A rendszerfejlesztési irányelvek különleges elvárásokat fogalmaznak meg a szervezetek között m köd rendszerekre?
X
4.3.3 Kockázatelemzési kérd ívek
4.3.3.1 Vezetés/Irányítás Az e-commerce-b l származó el nyök kihasználásához a vállalatnak át kell alakítania hagyományos szerkezetét és üzleti folyamatait. A döntéshozóknak tisztában kell lennie az új technológiákból származó megtakarítási lehet ségekkel. Az el relátó vezetés átgondolt tervezéssel és ellen rzéssel a vállalat motorjává teheti az e-kereskedelmi üzletágat. Ideális esetben a vállalat vezet je kinevez egy irányítót erre a területre, aki felel s a fejlesztésekért. Ennek a felel snek kell meghatároznia a m ködési szabályokat, célokat, és a finanszírozást. Egységes irányítás nélkül megn a sikertelenség veszélye. Lehetséges veszélyek: • Nincs megfelel vezet i segítség. • Nincs megfelel finanszírozás. • A projekt irányítása nem megfelel . • A projekt céljai nem tiszták vagy gyakran változnak. • A technológiai választás nem felel meg az üzleti elvárásoknak. • A folyamatok nem egységesek. • Nem megfelel a tervezés. • A tervek nem felelnek meg a gyakorlatnak. • Az üzleti folyamatok nem lettek áttervezve az új céloknak megfelel en. • A szervezeti felépítés nem megfelel az új célokhoz. • A szervezeti kultúra gátolja a megvalósítást. • Az eredmények nem mérhet k. • A partnerek nem úgy teljesítenek, ahogy a tervekben szerepelt. • Nincs vagy nem megfelel a vezet i ellen rzés. • A felhasznált források nem lettek megfelel en megtervezve.
42
ID
Vizsgálati szempont
Vezetés/Irányítás
LG.1 Megfelel tervezés, er s vezetés és hatalom, folyamatos ellen rzés szükséges a rendszerek helyes megvalósításához és az elvárt célok eléréséhez.
Kérdések
Igen Nem
A szervezetnek követnie kell a központi vezetés szabályait és eljárásait az e-commerce kezdeményezés kidolgozásában?
X
A vezet menedzserek részt vesznek – akár a központi vezetésben – az e-commerce tervezésben?
X
Az e-commerce tevékenységek a szervezet üzleti céljain alapul?
X
A szervezet vezetése mindent megtesz, hogy elkerülje a rendszerrel kapcsolatos üzleti célok stratégiáinak s r változtatását? A fels vezetés meggy z dött arról, hogy az üzleti folyamatok át lettek tervezve úgy, hogy ki lehessen használni az elektronikus kereskedelemb l származó költségmegtakarítást? Létezik az egész vállalatra vonatkozó, írásbeli stratégiai terv az e-commerce-szel kapcsolatban?
WP Ref
X
X
X
A terv tartalmaz prioritásokat az üzleti célokhoz és a hozzájuk tartozó e-commerce tevékenységekhez?
X
A tervben vannak mérhet eredmények és mérföldkövek?
X
Az e-commerce tevékenységeket ellen rzik a tervhez viszonyítva?
X
43
LG.2 A beruházás és a m ködtetés költségeit annak fényében kell megbecsülni, hogy a beruházó meggy z dött arról, hogy a rendszer tökéletesen meg van tervezve és valósítva, valamint életképes a további m ködésre.
LG.3 A rendszert úgy kell kifejleszteni, hogy azok különös tekintettel legyenek a hozzáférhet ségre, a meglev üzleti elvárásokra, az adatbirtoklásra és a helyes díjstruktúrára.
44
Az a személy, aki felel s az ellen rzésért, rendelkezik elég hatalommal és er forrással, hogy az eredmény alapján javításokat eszközöljön?
X
A jogszabálytól függ tevékenységeket ellen rzik, hogy azok megfeleljenek a törvényi feltételeknek?
X
A vezetés elvárja, hogy az elektronikus kereskedelmi rendszerrel kapcsolatban költség-haszon elemzést végezzenek?
X
Az e-commerce rendszerek aszerint vannak finanszírozva, hogy azok önfenntartók vagy nem?
X
A rendszerek több évre átnyúló természete figyelembe van véve a költségmodellnél? (A költségek nagyobbak, a bevételek kisebbek az els években)
X
Létezik olyan ellen rzés, amivel a kiadásokat megfelel en lehet követni?
X
Minden e-commerce rendszerre vannak hozzáférési és más üzleti megfontolások, amiket be kell tartani? A tervezési szempontok között elemeket kell a következ figyelembe venni: 1. Tartalom és struktúra, ebbe értve a felhasználó adatbevitelét, a frissítés gyakoriságát, az adat hitelesítését, id bélyegzést és a bevitt adat azonosítását? 2. Adatmegtartási megfontolások, figyelembe véve a jogi szabályozást és az adat-visszaállítást?
X
X
X
3. Elvárások az oldal rendelkezésre állására? 4. Adat és oldal visszaállítási terv valamint ennek rendszeres tesztelése?
X X
5. Az adatbeviteli mez k, interfészek és mennyiségek dokumentálása? 6. Az adatbevitel elvárásainak dokumentálása? 7. Az adatok pontosságának, érvényességének, teljességének és követhet ségének megvalósítása? A fels vezetés kijelölt olyan a személyt, aki felel s hozzáférési jogosultságokért, adat osztályozásért, a rendszer változásaiért? (A rendszertulajdonos általában továbbítja a rendszerellen rzést a rendszer m ködtet csoportnak, a biztonsági ellen rzést pedig a biztonsági adminisztrátornak. Ennek ellenére felel a rendszerért.) Olyan díjazási struktúra lett kialakítva, ami megfelel a törvényi elvárásoknak? Létezik olyan stratégia, amiben le van írva az oldal marketing politikája, a használat el nyei, ezzel segítve el egy széles vásárlói bázis felépítését?
X X X
X
X
Nincs díjazás
X
45
X X
Teljesen megoldott
Részben megoldott
Alapvet intézkedések történtek
Veszélyeztetettségi terület leírása Vezetés/Irányítás LG.1 – Tervezés, irányítás és ellen rzés LG.2 – Finanszírozás LG.3 – Használhatóság és üzleti igények
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
X
4.3.3.2 Személyes adatok védelme A keresked cég az internetes vásárlás során összegy jt bizonyos adatokat a vev ir l. Ezekre az adatokra nagyon kell vigyáznia, hiszen a kikerült személyes adatok miatt könnyen elveszítheti vev i bizalmát. Lehetséges veszélyek: • Az adatvédelmi szabályok/törvények nem egyértelm ek. • A szervezet nem tartja be az adatvédelmi el írásokat. • Visszaélések történhetnek a személyazonossággal. • Az adathozzáférés helytelenül van engedélyezve vagy tiltva. • Bizalmas adatok felhatalmazás nélkül kerülnek nyilvánosságra. • A jogi kötelezettségek mennyisége növekszik. ID P.1
46
Személyes adatok védelme
Vizsgálati szempont Következetes és törvényes személyes adatvédelmi szabályokat kell alkotni, és ezt nyilvánosságra kell hozni az ecommerce rendszer felhasználói számára.
Kérdések Igen Nem WP Ref Van a szervezetnek írásos adatvédelmi X szabályzata? A szabályzat tartalmazza a következ ket: 1. Gy jtenek X személyekhez köthet információkat, ha igen, hogyan? 2. A gy jtés célja és a megsemmisítés X módja?
3. Amennyiben az adatok kikerülnek harmadik félhez, kik azok a felek, milyen információt osztanak meg vele és mi a célja az információmegosztásnak? 4. A felhasználók választhatnak, hogy az adataik meg legyenek osztva más szervezetekkel? 5. Hogyan lehet kapcsolatba lépni a szervezettel? 6. A szervezet hogyan biztosítja a rendelkezésére álló személyhez köthet információk pontosságát és titkosságát? 7. Hogyan tudja a felhasználó ellen rizni és javítani az adatait? 8. Van olyan információ, ami a felhasználó tudtán kívül (egyszer en a hozzáféréssel) kerül az oldal tulajdonosához? Amennyiben az oldalnak van gyermekeknek szóló tartalma, az megfelel a Children’ s Online Privacy Protection Act feltételeinek? A szabályzat elérhet minden belép ponton és olyan helyen, ahol személyhez köthet információkat lehet elküldeni?
X
X
X
X
X
X
X
Nincs gyermekeknek szóló tartalom
X
47
P.2
Az információk osztályzásának és az érzékeny adatok védelmének olyan rendszerét kell kidolgozni, ami biztosítja, hogy adatok nem kerülhetnek illetéktelen helyekre.
Van olyan rendszer, amivel osztályozni lehet az információkat és olyan védelmi szintet lehet hozzájuk rendelni, ami megfelel a törvényi elvárásoknak?
X
A szervezet rendszeresen ellen rzi az osztályzási eljárását annak érdekében, hogy felismerje, ha valamilyen adat nem szükséges az elektronikus szolgáltatás nyújtásához? A dolgozóknak alá kell írnia egy titoktartási szerz dést, ami meghatározza, hogy milyen bizalmassági elvárások vannak velük szemben? A harmadik feleknek, akik hozzáférnek a bizalmas információkhoz, el kell fogadniuk az adatvédelmi elveket? Az adatbirtokos minden olyan esetben ismert, amikor harmadik félnek kiadnak vagy t le elfogadnak információt? Vannak büntetések az adatvédelmi elvek megsértésének szankcionálására? Léteznek olyan hozzáférési naplók, amikb l kiderülnek az illetéktelen adatkezelési tevékenységek?
48
X
X
X
X
X
X
A titkosítási technikák megfelelnek a piaci szabványoknak?
X
A személyhez köthet adatok megsemmisítésénél valamilyen biztonságos törlési eljárást használnak?
Nincs felhasznált titkosítási technológia
X
Teljesen megoldott
Részben megoldott
Veszélyeztetettségi terület leírása Személyes adatok védelme P.1 – Titokban tartás és közzététel X P.2 – Min sítés és bizalmasság X
Alapvet intézkedések történtek
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
4.3.3.3 Biztonság Minél több adatot közölnek a vásárlók a bolttal az Interneten keresztül, annál nagyobb a veszélye annak, hogy ezeket ellopják. A felhasználói azonosítókat, jelszavakat, hitelkártyaszámokat, bankszámlaszámokat mind elektronikus formában tárolják. Adatlopás vagy helytelen használat miatt a keresked peres ügyekbe keveredhet, nem is szólva a presztízsveszteségr l. Éppen ezért egy jól megtervezett biztonsági rendszer elengedhetetlenül fontos az elektronikus kereskedelemben. Lehetséges veszélyek: • Visszaélések történhetnek a személyazonossággal. • A felek nem tudják megfelel en azonosítani egymást. • Vírus- és hackertámadások fenyegetnek. • Az adathozzáférés helytelenül van engedélyezve vagy tiltva. • Felhatalmazás nélkül módosíthatnak, törölhetnek és hozhatnak létre adatokat és programokat. • Bizalmas adatok felhatalmazás nélkül kerülnek nyilvánosságra. • A rendszer rendelkezésre állását gátolhatják.
49
ID S.1
Vizsgálati szempont Az információkat védeni kell az illetéktelen felhasználástól, módosítástól, közzétételt l, rongálódástól és elt nést l.
Biztonság
Kérdések Igen Nem A biztonsági politikák és eljárások dokumentáltak és ismertek az alkalmazottak és a X harmadik fél számára is, akik hozzáférnek a rendszerekhez, adatokhoz és berendezésekhez? A biztonsági politikák és eljárások, amik az e-commerce rendszerhez kapcsolódnak, X tartalmazzák a következ ket: 1. A fontosabb berendezések és eljárások felsorolása? 2. A kulcsfontosságú partnerek általi X elfogadás? 3. Oktatás? X
4. Felhatalmazás a rendszer logikai és fizikai hozzáféréséhez és használatához? 5. Személyazonosítás? 6. Fizikai és logikai hozzáférés, csak bemutató szándékkal? 7. Távoli hozzáférés a rendszerhez? 8. Betárcsázós hozzáférés a rendszerhez? 9. Felhasználói profilok és azonosítás? 10. Titkosító kulcs kezelés? 11. Esemény kezelés, jelentés és követés?
50
X X X X X X X X
WP Ref
Nincsenek biztonsági politikák
S.2
12. Vírus megel zés és felderítés? 13. T zfallal szembeni elvárások? 14. A hátsó kapuk kiiktatása? Van biztonságtechnikai oktatás az új dolgozók és a partnerek részére? Minden dolgozó rendszeresen részesül a biztonsági frissítésekb l? A szervezet elvárja, hogy a vele kapcsolatban álló partnerek rendelkezzenek szabványos biztonsági politikával és eljárásokkal? (Minden hálózat annyira biztonságos, mint amennyire a leggyengébb pontja) A kockázatanalízis rendszeresen végre van hajtva, hogy biztosítsa a változások negatív hatásainak kisz rését? Az adatbázisok biztosítva vannak az illetéktelen hozzáférés ellen? Az illetéktelen tevékenységeket Léteznek biztonsági azonosítani és követni kell. naplók, azok rendszeresen ellen rzöttek és a hozzáférési szabályok megsértése esetén történik ellenintézkedés? Az egyént azonosító információk biztonságos csatornákon közlekednek
X X X
X
X
X
X
X
X
X
51
(titkosítottak)?
S.3
52
Az adatok hitelességét és bizalmasságát olyan titkosítási technikákkal kell védeni, amik megfelelnek az e-commerce rendszerrel szembeni követelményeknek.
A biztonsági naplók segítségével követhet k a behatoló tevékenységei az egész rendszerben (tranzakció azonosítók, felhasználó azonosítók, stb.)? A szervezet rendelkezik a biztonsági naplók tárolásáról szóló szabályzattal? A biztonsági szabályzat megsértésér l szóló beszámolókat rendszeresen ellen rzik és továbbítják az illetékes vezet nek? A szervezet keretein belül m ködik olyan csoport, akinek megvan a megfelel tudása, tapasztalata és képessége a biztonsági veszélyek elhárítására? Mind az adatátvitel, mind az adatbázisokban tárolt érzékeny információk titkosítva vannak? Történt költséghatékonysági elemzés, ami segít kiválasztani a titkosítási és elektronikus aláírási rendszer szintjét és er sségét?
X
X
X
X
X
X
S.4
S.5
S.6
A rendszert úgy kell megvalósítani, hogy a tranzakcióban részt vev egyik fél se tudja letagadni tevékenységeit.
A rendszernek hitelesítenie kell a vele kommunikáló felet.
A digitális aláírásokat/tanúsítványokat hatásosan és rendeltetésszer en kell használni.
A titkosítási eljárást rendszeresen ellen rzik az érvényesség szempontjából? A kulcsmenedzselési eljárások (kulcstitkosítás az átvitel alatt, a kulcsok biztonságos tárolása, kulcsszétosztás) úgy lettek kiválasztva, hogy azokat minden résztvev fél képes betartani? Használnak olyan technológiákat (digitális aláírás, id bélyegz , megbízható harmadik fél, üzenet jóváhagyás), melyek garantálják a forrás és a cél letagadhatatlanságát, a küldés és a vétel tényének bizonyítását? A rendszer szolgáltatása kiterjed az auditot segít nyomkövetésre, ebbe értve a tevékenység naplót a sikeres és sikertelen tranzakciókkal, hálózati és küld /fogadó visszaigazolásokat és a feldolgozási id ket? Használnak hitelesítést segít alkalmazásokat (SSO, tokenek, titkosító kulcsok)? Az elektronikus aláírásokat használó alkalmazások szabványosan vannak megvalósítva?
X
X
X
X
X
X
Nincsenek ilyen alkalmazások
53
A kulcs generálásával, szétosztásával, a tanúsítvány létrehozásával, tárolásával, használatával és archiválásával kapcsolatos eljárások és protokollok meg vannak határozva? Használnak Hitelesít Központot (CA)?
X
X
A CA auditált? Ha a CA-t már auditálták, találtak a biztonságot komolyan fenyeget veszélyeztetettséget? A rendszerben használt tanúsítványok megfelelnek a rendszer elvárásainak? A tanúsítványok érvényessége meghatározott ideig tart? Ha egy kulcs kompromittálódik, azt azonnal vissza lehet vonni?
X
Nincs CA
X
Nincs CA
X
Nem használ tanúsítványokat
X
Nem használ tanúsítványokat
X
Nem használ tanúsítványokat
54
Teljesen megoldott
Részben megoldott
Alapvet intézkedések történtek
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
Veszélyeztetettségi terület leírása Biztonság S.1 – Szabályzatok és eljárások X S.2 – Ellen rzés X
Nincsenek ilyen eljárások
X X X X
S.3 – Titkosítás S.4 – Letagadhatatlanság S.5 – Azonosítás és hitelesítés S.6 – Digitális aláírás
4.3.3.4 Jogi felkészültség Az elektronikus környezet bevezetéséhez olyan jogi keretet kell biztosítani, ami azonos módon tudja kezelni a hagyományos és az elektronikus folyamatokat. Csak egy ilyen kerettel lehet az elektronikus kereskedelem el tt álló akadályokat legy zni. Lehetséges veszélyek: • A peres eljárások és jogi kötelezettségek száma növekedhet. • A szabályozó nem tudja tartani a lépést a gyorsan változó környezettel. • A weboldalak domain nevei nem megfelel en védettek. • A tulajdonjogok sérülhetnek. • Az üzletfelek közötti megállapodások nem léteznek vagy nem megfelel ek. • Az adattárolás nem a törvényi el írásoknak megfelel . Jogi felkészültség
ID
Vizsgálati szempont
L.1
Az elektronikus kereskedelmi rendszernek összhangban kell lennie a meglev törvényi rendelkezésekkel.
Kérdések
Igen Nem
Az elektronikus kereskedelemmel kapcsolatos jogi akadályokról történt eszmecsere jogi tanácsadóval? Létezik olyan rendelet, vagy szervezet, ami az engedélyezést illetékhez köti? A szervezet bankkártyát?
el
tud
WP Ref
X
X
fogadni X
A kártyahasználati díjakat rendben kifizetik és elszámolnak vele?
X
Van lehet ség elektronikus szerz dések megkötésére? A rendszer eleget tesz a törvényhozó vagy szabályozó által el írt adattárolási kötelezettségének?
X
X
55
A nyilvántartások törlése megfelel a törvényi el írásoknak? L.2
A vezetésnek meg kell határoznia Az e-commerce rendszer az elektronikus kereskedelmi tartalmaz olyan nyilatkozatot, rendszer helyes használatát. amib l kiderülnek az alkalmazás felhasználási céljai és a jogos használat feltételei valamint ezek a felhasználók számára hozzáférhet ek? A nyilatkozat tartalmazza a helytelen használatból adódó jogi következményeket?
X
X
X
A nyilatkozatot jóváhagyta a jogi tanácsadó?
L.3
L.4
Az elektronikus kereskedelmi tranzakciókban részt vev felek számára biztosítani kell a letagadhatatlanságot.
Létezik olyan eljárás, ami lehet vé teszi a rendszer felhasználóinak azonosítását és ez összhangban áll a jogi tanácsadó vagy az illetékes hatóság ajánlásaival? A jogi felel sségeket világosan A weboldal tartalmaz olyan meg kell határozni és a nyilatkozatot, amiben fel vannak rendszerben megjelen összes sorolva a kommunikáló felek jogai és kötelezettségei? résztvev tudomására kell hozni.
X
X
X
Ez a nyilatkozat az összes fontos helyen elérhet ? X
A jogi tanácsadó kielemezte az összes e-commerce rendszerhez kapcsolódó felel sségi kört? Ezek közé tartozik: - A tranzakciók értékhatára - A személyes adatok biztonsága - Bizalmasság - A visszaigazoló e-mailben véletlenül elküldött vírus hatása - A rendszer rendelkezésre állása kritikus helyzetekben (például a teljesítés lezárásának pillanata)
56
X
A harmadik féllel kötött megállapodás tartalmazza a másik fél hibájából történt károk tisztázásának és helyrehozásának felel sségi rendszerét?
X
A harmadik féllel kötött megállapodás tartalmazza az adat tulajdonlás kérdését?
X
A szervezet részese függ ben lev vagy bírói szakaszban lev polgári pernek?
L.5
Az e-commerce rendszer helyét a törvények között meg kell találni, és fel kell készülni a vitás esetekre, valamint a félreértésekre.
A harmadik féllel kötött megállapodás tartalmazza, hogy a vitás eseteket hogyan és hol oldják meg a felek? Vannak vagy voltak már vitás esetek a felek között, különös tekintettel a tranzakció elismerésére, a pontosságra, az adatbirtoklásra, a személyes adatok védelmére, a bizalmasságra?
X
X
X
X
Teljesen megoldott
Részben megoldott
Alapvet intézkedések történtek
Veszélyeztetettségi terület leírása Jogi felkészültség L.1 – Jogi alap L.2 – Érvényesíthet ség L.3 – Letagadhatatlanság L.4 – Jogi kötelezettségek X L.5 – Törvénykezés
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
X X X
57
4.3.3.5 Vásárlói felkészültség és hozzáférés A tervez nek mindig azt kell szem el tt tartania, hogy a rendszere a társadalom minél szélesebb rétegeihez érjen el. Mindezt úgy kell elérni, hogy a közönség rendszerhez való hozzáférési lehet sége nem azonos. Ez a digitális szakadék több szempontból létezik – a cél az, hogy ezt a szakadékot sz kítsük. Gondolni kell azokra, akik anyagi helyzetüknél fogva nem férnek hozzá az Internethez, a csökkent látásúakra, a vidéki lakosokra, akiknél még nem építették ki az Internet elérést, akik nem tudják használni a számítógépet, akiknek nincs bankkártyájuk vagy bankszámlájuk. Ezeknek a problémáknak a megoldása f leg kormányzati feladat, de a rendszerfejleszt nek is lehet sége van segíteni. Lehetséges veszélyek: • Internettel nem vagy limitáltan rendelkez egyéneket nem vagy nem megfelel en szolgálnak ki. • A vásárlói igények meghaladják a lehet ségeket. • A vásárlók nem használják az új vásárlási módokat. • A felhasználók nem bíznak meg a keresked ben, mert nem találják meggy z nek a törvényi hátteret. Vásárlói felkészültség és hozzáférés
ID Vizsgálati szempont CR.1 A elektronikus kereskedelmi rendszert a megcélzandó vásárlói réteg legszélesebb körében elérhet vé kell tenni.
Kérdések Igen Nem WP Ref Léteznek olyan tanulmányok vagy más információk, ami alapján meg lehet gy z dni arról, X hogy a célfelhasználók az számára elérhet k internetes szolgáltatások? Azok számára, akiknek nincs személyes hozzáférésük, rendelkezésre állnak más internetes végpontok X (hozzáférési pontok az iskolákban, könyvtárakban, Internet kávézókban, áruházakban)? A fogyatékos emberek számára léteznek nyilvános hozzáférési pontok? X
CR.2 Érzékeny vagy bizalmas adatokat A nyilvános pontokról csak biztonságos módon lehet internetez felhasználók nyilvános pontokról elküldeni. számára rendelkezésre állnak olyan biztonsági megoldások, amik
58
X
CR.3 Az elektronikus kereskedelmi rendszerben a speciális igény felhasználóknak (fogyatékosok, kisebbségek, számítógépes analfabéták) is lehet vé kell tenni hozzáférést.
garantálják a személyes adatok védelmét (pl. képerny pajzs, ami csak a képerny vel szemben álló felhasználónak mutatja a grafikus felületet)? A szervezet rendelkezik írásos szabályzattal, ami garantálják, hogy a hátrányos helyzet ek igényeit is figyelembe vegyék a rendszerfejlesztésnél? A weboldal nyújt olyan szolgáltatást, ami segíti a vakok és gyengénlátók böngészését?
X
X
Az oldal lehet vé teszi nem magyar anyanyelv ek böngészését? A szervezet segíti azon felhasználóit, akik nem rendelkeznek megfelel számítógépes ismeretekkel? A weboldal eleget tesz a World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (AG) ajánlásának, ami segíti a hátrányos helyzet felhasználókat? Például, 1. Az oldal eleget tesz a W3C HTML szabványának? 2. A képek Alt tagja megfelel információt ad a képre vonatkozóan? 3. Az oldallal kapcsolatos információk vagy HTML vagy más formátumban (pl. és az PDF) elérhet olvasásukhoz szükséges eszközök letöltési linkje adott?
X
X
X
X
X
59
4. A hangfájlok és a videófájlok hangjai szöveges formátumban is elérhet k? 5. Amennyiben az oldal olyan beépül modulokat használ (pl. Java applet), amelyek nem feltétlenül állnak rendelkezésre, létezik olyan oldal, ami ezek nélkül is használható? 6. Amennyiben az oldal mozog, villog, vagy objektumok úsznak rajta, ezek leállíthatók?
X
X
X
CR.4 A felhasználóknak felszámított A szolgáltatás vagy áru használati díjak elfogadottságáról rendes árán kívül kell még meg kell gy z dni. fizetni más díjakat is? Van olyan jel, hogy a felhasználási díjak megfizethetetlenek vagy aránytalanul magasak a rendes árhoz képest? CR.5 A e-commerce rendszernek Vannak olyan eszközök, könnyen használhatónak kell amik könnyebbé teszik a lennie. felhasználó navigálását (pl. érint képerny , online segítség, közös interfész a különböz alrendszerek között)? A rendszer megvalósításánál elkerülték a használathoz szükséges speciális hardver vagy szoftver eszközök implementálását? A felhasználó úgy is meg tudja találni az t érdekl információkat és szolgáltatásokat, hogy korábban nem ismerte az adott szervezetet?
60
X
X
X
X
X
Nincsenek díjak
A rendszer lehet vé teszi a rendelést azok számára is, akik nem rendelkeznek bankszámlával és bankkártyával? CR.6 A rendszernek segítségnyújtást problémamegoldást biztosítania.
felhasználói Van valamilyen oktatás a és rendszer felhasználóinak? kell Van lehet ség segítségkérésre? A szolgáltatással kapcsolatos ügyek intézésére van ügyfélszolgálat? A segítségnyújtás olyan órákban üzemel, amik megfelelnek a vásárlók igényeinek?
X
X X
X
X
Teljesen megoldott
Részben megoldott
Veszélyeztetettségi terület leírása Vásárlói felkészültség és hozzáférés CR.1 – Rendelkezésre állás CR.2 – Bizalom X CR.3 – Hozzáférhet ség X CR.4 – Díjak X CR.5 – Könny használhatóság CR.6 – Támogatás
Alapvet intézkedések történtek
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
X
X
X
4.4 Javasolt architektúra A vizsgált öt terület közül a biztonság és az adatvédelem számunkra a legfontosabb. Anélkül, hogy levonnánk a következtetéseket a kockázatelemzésb l, látatlanban a PKI rendszer bevezetése mellett döntöttünk, mert úgy gondoljuk, hogy ez mindkét területen nagy el relépést jelentene. Emellett bevezettük a korábban elhatározott elektronikus kereskedelmi folyamatot is, ami a jelenlegi rendszerben nem jelent meg, valamint egy-két szemmel látható hiányosságot szüntettünk meg.
61
Ezt a felépítést el ször egy elméleti vizsgálatnak vetettük alá, ami egy újabb kockázatelemzést jelent, majd szimulálva a végs m ködést, megépítettük azt. Ezen szimuláció alapján tudtunk következtetéseket levonni a végleges összeállításhoz. DMZ
LAN
Adatbázis
Webszerver
Backup
Szerverfarm
Firewall
Internet
CA
… Kliensek
Router, fájl szerver, t zfal vásárlás SSL protokollon keresztül ellen rzés Jelmagyarázat 14. ábra: Javasolt infrastruktúra
62
Könyvelés Router, fájl szerver, t zfal Banki kliens
Az új rendszerben több új elem és folyamat jelenik meg. A webszerver átkerül a demilitarizált zónába, elé egy háromlábú t zfalat kell kialakítani. A védett zónába kerül az adatbázis-szerver és a biztonsági mentés. Új szerepl a hitelesít központ, ami a vállalattól független egység, de jelenléte elkerülhetetlen a tervezett kereskedelmi rendszerben. Két új folyamat jelenik meg: a klienseknek lehet sége van az on-line vásárlásra, a kereskedelmi rendszer pedig tanúsítványellen rzést hajt végre a hitelesít központban. A szerverfarmot szimuláló környezet a Budapesti M szaki és Gazdaságtudományi Egyetem Informatikai Központjának IL206-os laborjában lett megvalósítva. A szimulációhoz az alábbi hardver és szoftver eszközöket használtuk fel. 0. gép (t zfal) 1. gép (webserver): 2. gép (database + backup): 3. gép (kliens)
OpenBSD Windows XP Professional, Apache http Server 1.3.22, PHP 4 környezet, Utimaco SafeGuard Transaction Server RedHat Linux, PostgreSQL Windows XP, Office XP, Utimaco SafeGuard Transaction Client
4.5 Kockázatelemzés a javasolt környezetben 4.5.1 Módosított kockázatelemzési kérd ívek Az új rendszerrel a következ kérdésekre adott válaszok módosulnak: ID LG.3
S.2
Vizsgálati szempont A rendszert úgy kell kifejleszteni, hogy azok különös tekintettel legyenek a hozzáférhet ségre, a meglev üzleti elvárásokra, az adatbirtoklásra és a helyes díjstruktúrára. Az illetéktelen tevékenységeket
Kérdések Igen Nem WP Ref 7. Az adatok X Az elektronikus pontosságának, aláírás lehet séget érvényességének, ad erre. teljességének és követhet ségének megvalósítása? Az egyént azonosító X információk biztonságos
SSL protokollon keresztül történik 63
azonosítani és követni kell. S.3
Az adatok hitelességét és bizalmasságát olyan titkosítási technikákkal kell védeni, amik megfelelnek az e-commerce rendszerrel szembeni követelményeknek.
S.4
A rendszert úgy kell megvalósítani, hogy a tranzakcióban részt vev egyik fél se tudja letagadni tevékenységeit.
S.5
A rendszernek hitelesítenie kell a vele kommunikáló felet.
S.6
A digitális aláírásokat/tanúsítványokat hatásosan és rendeltetésszer en kell használni.
csatornákon közlekednek (titkosítottak)? A titkosítási eljárást rendszeresen ellen rzik az érvényesség szempontjából? A kulcsmenedzselési eljárások (kulcstitkosítás az átvitel alatt, a kulcsok biztonságos tárolása, kulcsszétosztás) úgy lettek kiválasztva, hogy azokat minden résztvev fél képes betartani? Használnak olyan technológiákat (digitális aláírás, id bélyegz , megbízható harmadik fél, üzenet jóváhagyás), melyek garantálják a forrás és a cél letagadhatatlanságát, a küldés és a vétel tényének bizonyítását? Használnak hitelesítést segít alkalmazásokat (SSO, tokenek, titkosító kulcsok)? Az elektronikus aláírásokat használó alkalmazások szabványosan vannak megvalósítva? A kulcs generálásával, szétosztásával, a tanúsítvány létrehozásával, tárolásával, használatával és archiválásával kapcsolatos eljárások és protokollok meg vannak határozva? Használnak Hitelesít Központot (CA)? A CA auditált? Ha a CA-t már auditálták, találtak a biztonságot komolyan fenyeget veszélyeztetettséget? A rendszerben használt
64
az adattovábbítás X
A hitelesít központ ellen rzi.
X
A hitelesít központ szabványos kulcsmenedzsment eljárásokat használ.
X
Az új rendszerben bevezetésre került.
X
Az elektronikus aláíráshoz szükséges ilyen eszköz. A CPS-ben leírtak szerint igen.
X
X
A CPS-ben le van írva.
X
Az új rendszer használ.
X
X
X
A CA min sített, ezért nincs komoly veszélyeztetettség. Szabványos
tanúsítványok megfelelnek a rendszer elvárásainak? A tanúsítványok érvényessége meghatározott ideig tart?
L.1
CR.5
Az elektronikus kereskedelmi rendszernek összhangban kell lennie a meglev törvényi rendelkezésekkel. A e-commerce rendszernek könnyen használhatónak kell lennie.
Ha egy kulcs kompromittálódik, azt azonnal vissza lehet vonni? Van lehet ség elektronikus szerz dések megkötésére? A rendszer megvalósításánál elkerülték a használathoz szükséges speciális hardver vagy szoftver eszközök implementálását? A rendszer lehet vé teszi a rendelést azok számára is, akik nem rendelkeznek bankszámlával és bankkártyával?
tanúsítványokat használunk. X
A tanúsítványok érvényessége CPS-ben meghatározott. A visszavonási eljárás CPS-ben meghatározott.
X
X
A XXXV/2001 törvény szerint erre lehet ség van. X
X
Az elektronikus aláíráshoz szükség van biztonságos aláíró eszközre.
Az elektronikusan aláírt szerz dés lehet séget nyújt átutalásos fizetésre, valamint az utánvét rendelésre is.
65
4.5.2 Veszélyforrás értelmez adatlap Felhasználva a javasolt architektúra kockázatelemzését, a következ értelmez adatlapot tudjuk el állítani:
veszélyforrás
Teljesen megoldott
Részben megoldott
Veszélyeztetettségi terület leírása Vezetés/irányítás LG.1 – Tervezés, irányítás és ellen rzés X LG.2 – Finanszírozás LG.3 – Használhatóság és üzleti igények X Személyes adatok védelme P.1 – Titokban tartás és közzététel X P.2 – Min sítés és bizalmasság X Biztonság S.1 – Szabályzatok és eljárások X S.2 – Ellen rzés X S.3 – Titkosítás S.4 – Letagadhatatlanság S.5 – Azonosítás és hitelesítés S.6 – Digitális aláírás Jogi felkészültség L.1 – Jogi alap L.2 – Érvényesíthet ség X L.3 – Letagadhatatlanság L.4 – Jogi kötelezettségek X Vásárlói felkészültség és hozzáférés CR.1 – Rendelkezésre állás CR.2 – Bizalom X CR.3 – Hozzáférhet ség X CR.4 – Díjak X CR.5 – Könny használhatóság CR.6 – Támogatás
Alapvet intézkedések történtek
Felismert, de nem történt intézkedés
Nem felismert
A felismerés mértéke
X
X X
X X
X X X
X
X
4.5.3 Kockázatelemzési grafikon A veszélyforrás értelmez adatlap adatai alapján a következ kockázatelemzési grafikon rajzolható meg: 66
5 4 3 2
L CR, LG P
1
A felismerés mértéke
S
Alacsony
Közepes
Magas
A rendszer veszélyeztetettségi foka A grafikonból látható, hogy a javasolt architektúra a biztonságot megnövelte, de az adatvédelmet nem befolyásolta. A többi területen az alapvet intézkedések megtörténtek, mivel ezek kevésbé fontosak, ezzel a szinttel megelégedhetünk. A védelmi intézkedések megtervezésénél tehát különös figyelemmel kell lenni arra, hogy az adatvédelmet a megfelel szintre hozzuk, valamint a biztonságot ésszer befektetéssel minél magasabb szintre hozzuk.
4.5.4 Védelmi intézkedések A védelmi intézkedéseket a kockázatelemzési kérd ív alapján lehet meghozni. Azokat a területeket, amelyek nem felismertek vagy felismertek, de nem történt intézkedés, mindenképp alaposan meg kell vizsgálni. A legfontosabb lépés egy adatvédelmi szabályzat elkészítése. Ennek tartalmaznia kell a személyes adatok gy jtésének módját, célját, a tárolás id tartamát, azon partnereknek a listáját, akik hozzáférnek az adatokhoz. Meg kell adni az adatkezel pontos adatait, elérhet ségét. Ha a kereskedelmi rendszer olyan adatokat is gy jt a felhasználóról, amiket nem kell külön beírni egy rlapba (pl. IP cím), akkor ezekr l is tájékoztatást adni. Ezt az adatvédelmi szabályzatot az összes fontos lapon elérhet vé kell tenni. Az adatvédelmi szabályzat kidolgozásánál segítséget nyújthat az Adatvédelmi Törvény és az Elektronikus Kereskedelmi Törvény valamint az adatvédelmi ombudsman Internetre vonatkozó ajánlásai. Ki kell alakítani az adatok osztályozásának rendszerét. Adott esetben kétféle adat képzelhet el: a titkos adat (ilyen a bankkártya szám) és a bizalmas adat (pl. a vásárló neve). A tranzakció során semmilyen nyilvános adat nem keletkezik. Egy listában kell összefoglalni a megkapott adatokat, és ezekhez meg kell határozni a titkosság fokát. Az
67
osztályozásnak összhangban kell lennie a jogszabályokkal és ajánlásokkal, ezért rendszeresen felül kell vizsgálni. Az adatbázisokban minden adatot titkosítva kell tárolni. A dolgozóknak és a partnereknek alá kell írnia egy szerz dést, amiben vállalják az általuk feldolgozott adatok titokban tartását, büntet jogi és munkajogi felel sség mellett. Az adatokhoz csak úgy lehessen hozzáférni, hogy arról bejegyzés marad valamilyen naplófájlban. El kell készíteni egy írásos biztonsági politikát, amit minden dolgozónak és partnernek el kell fogadnia. A biztonsági politikának tartalmaznia kell a legfontosabb berendezések és eljárások listáját, a biztonsági oktatás módját és rendszerességét, az adminisztrátorok hozzáférési felhatalmazásait, a távoli hozzáférés szabályait, a nem várt események kezelését, a vírusvédelmi kötelezettségeket, a t zfal szabályait, a behatolásdetektálás monitorozását. Rendszeresen végre kell hajtani a kockázatelemzést. Ezek a preventív eljárások. Minden fontos helyen biztonsági naplókat kell vezetni, ezeket védeni kell, és garantálni kell hitelességüket. A biztonsági naplókat úgy kell megszervezni, hogy azokból minden rosszindulatú tevékenység követhet legyen. A naplózási eljárásokat is dokumentálni kell. A logokat rendszeresen ellen rizni kell. Ezek a detektív eljárások. Létre kell hozni katasztrófa-elhárítási tervet. Rendelkezésre kell állnia azoknak a szakembereknek, akik képesek a nem várt eseményeket elhárítani. Biztonsági mentések kellenek, amikr l hamar vissza lehet állítani a rendszert. Tartalék hardver eszközök kellenek. A rendszer nem állhat tovább egy napnál, de ideális esetben rendszerleállásnál egy tükörszervernek kell m ködésbe lépni. Ezek a preventív lépések.
68
5 Az elektronikus kereskedelmi rendszer megvalósítása 5.1 Biztonságos elektronikus bolt létrehozása – Jegyz könyv Mérés ideje: 2003. április 14. – 2003. április 16. Mérés helye: IL 206-os labor Mérést végezte: Krasznay Csaba I.
feladat: Apache webszerver telepítése:
Az elektronikus kereskedelmi környezet létrehozásának els lépése a webszervernek kinevezett gép felkészítése az e-bolt fogadására. A gép operációs rendszere Windows XP Professional Edition Magyar verzió. Alkalmazkodva az elektronikus aláírás ellen rz szerver elvárásaihoz, az Apache Http Server 1.3.22 verzióját telepítettük fel. Ez az ellen rz szoftver CD-jén volt megtalálható, Windows Installer formátumban. A telepítés rendben lezajlott, az Apache service gond nélkül elindult. II.
feladat: PHP környezet telepítése:
A Transaction Server CD-n megtalálható a PHP 4-es fejleszt környezet ZIP-ben csomagolt változata. Ezt kitömörítettük a C:\PHP könyvtárba. A következ lépés a DLL könyvtárban található dinamikus könyvtárak és a php4ts.dll átmásolása a C:\WINDOWS\SYSTEM32 könyvtárba. A php.ini fájl a C:\WINDOWS könyvtárba került. Ezt követ en a php.ini fájlban az [Extension] részben kikommenteztük a php_pgsql.dll fájlt, ezzel lehet vé vált, hogy a PHP egység elérje a kés bb telepítend PostgreSQL adatbázist. Az utolsó lépés az Apache webszerver apache.conf fájljának szerkesztése. Mivel a PHP-t modulként szeretnénk használni, ezért be kell írni a LoadModule php4_module „ c:/php/sapi/php4apache.dll” és az AddType application/x-httpd-php .php sorokat. Ezek a lépések követik a PHP könyvtárban található Install fájl lépéseit. Egy tetsz legesen kiválasztott .php fájllal megtörtént a tesztelés, a környezet m köd képes. III.
feladat: Transaction Server telepítése:
A Utimaco Transaction Server 1.0 szerver telepítéséhez el ször le kell futtatni a create_archiving_dirs.bat fájlt. Ez hozza létre a m ködéshez szükséges könyvtárstruktúrát. Ezután a trans.zip fájlt kell kibontani a .bat fájl által létrehozott Trans könyvtárba. A php_sgsctrans.dll fájlt a c:\php\extensions könyvtárba kell tenni. Ezután a php.ini fájl [Extensions] szakaszát ki kell egészíteni az extension=php_sgsctrans.dll sorral. Végül az Apache könyvtárban lev htdocs.zip és cgi-bin.zip könyvtárakat ki kell bontani az Apache webszerver installálási könyvtárába. A CryptWare API dll fájlokat a Windows\System32 könyvtárba kell másolni. Ha mindezzel kész vagyunk, le lehet tesztelni a m ködést a Transaction Server index.htm fájljával, amit az imént bontottunk ki a htdocs könyvtárba. A tesztelés el tt azonban a
69
transaction.php fájlban az $ipadres változót át kell írni a webszerver IP címére. A teszteléshez szükséges a Transaction Client felinstallálása egy tetsz leges kliens gépen. A Transaction Server m ködéséhez szükséges az összes olyan hitelesít központ tanúsítványának beállítása, amelyek ügyfeleinek aláírásait az elektronikus bolt üzemeltet je el akarja fogadni. Ez a SafeGuard Transaction Server Configuration segédprogrammal történik. El ször a program Keys alkönyvtárába be kell másolni a szükséges tanúsítványt, majd azt importálni kell.
15. ábra: Tanúsítványok importálása
Ha az importálás sikerrel járt, akkor a kiválasztott CA tanúsítvány megjelenik a korábban telepítettek mellett.
70
16. ábra: SafeGuard Transaction Server konfigurációs ablak
Ha a trans.conf fájlban nem állítjuk be az OCSP-n keresztüli tanúsítványellen rzést, akkor az összes CA CRL-jének jelen kell lennie a szoftver CRL könyvtárában. Ezt a hitelesít központtól lehet megszerezni, és figyelni kell, hogy mindig érvényes legyen
71
.
17. ábra: CRL mappa
IV.
feladat: PostgreSQL adatbáziskezel telepítése:
Adatbázis-kezel nek a PostgreSQL 7.3.1 for Win32 verziót választottuk. Telepítés során minden kiegészít t feltelepítettünk. Ha rendben feltelepült a szerver és a gépet újraindítottuk, akkor a Programok -> PostgreSQL -> Command Shell parancsikonra kattintva lehet elindítani a szolgáltatást. Ehhez a postmaster –i parancsot kell beírni a parancssorba. A PostgreSQL-hez szükséges segédprogramok m ködéséhez szükséges az ODBC driver beállítása is. Ez Windows XP alatt a Vezérl pult -> Felügyeleti eszközök -> ODBC adatforrások menüb l érhet el. A Hozzáadás gombra kattintva lehet feltelepíteni a PostgreSQL vezérl t. Ha ez sikeres volt, akkor a Beállítás gomb segítségével lehet megadni, hogy az ODBC-n keresztüli elérés hogy történjen. Az adatbázis-kezeléshez két segédprogramot választottunk ki. Az egyik a pgAdmin II, a másik a phpPGAdmin nev program. A pgAdmin II segítségével könnyedén tudjuk kezelni a felhasználói beállításokat és az el re megírt szkripteket. A phpPGAdmin kiválóan alkalmas a mez k manuális feltöltésére és a PHP-n keresztüli adathozzáférés ellen rzésére. V.
feladat: A WeBolt elkészítése:
A rendelkezésre álló .zip fájl tartalmát az Apache htdocs könyvtárába kell kibontani. A mellékelt tables.sql fájlt a pgAdmin II-ben lehet lefuttatni. Ez létrehozza a futtatáshoz 72
szükséges táblákat. A nums táblában hiányzik egy baskets nev mez , ezt utólag kell létrehozni. Enélkül a rendelés nem tud lefutni. Küls böngész vel ki lehet próbálni, hogy rendben futnak–e szkriptek. Kés bbi PHP környezetekben gond lehet, hogy a futáshoz szükséges globális változókat a fájlok nem érik el közvetlenül, csak a $_HTTP_VARS tömbön keresztül. A jelenlegi bolt verzió kevésbé biztonságos, ezért közvetlen változó elérésre van szükséges. Ez a php.ini fájlban beállítható. A termékeket a phpPGAdmin-on keresztül lehet feltölteni. Ehhez viszont el bb létre kell hozni egy *** nev felhasználót *** jelszóval, aki képes elérni a *** adatbázis minden tábláját és képes bele adatokat írni. Az árukat a products táblába kell beírni. VI.
feladat: A Transaction Server integrálása a WeBoltba:
A rios_basket.php fájl form_on () függvényét a következ sorokkal kell kiegészíteni: $ipadres="152.66.243.249"; $htdocs="c:\\program files\\apache group\\apache\\htdocs\\"; $tmp="tmp\\"; $value="text/plain"; $browser=getenv("HTTP_USER_AGENT"); $netscape="YES"; if (stristr($browser,"compatible")){ $netscape="NO";} $embed_signature = "0"; engedélyezése $save_local_copy="0"; $spcsymb = "_";
//a Transaction Server IP címe //a .php fájlok helye a helyi winchesteren //az ideiglenes fájlok helye //a kiválasztott kódolási forma //böngész ellen rzés //beágyazott
aláírások
//a szerz dése mentésének engedélyezése kliens oldalon //a szerz déshez köt d egyedi fájl létrehozása
fwrite($fhandle,"Postázási név: $post_name Számlázási név: $pay_name\n"); fwrite($fhandle,"Postázási város: $post_town Számlázási város: $pay_town\n"); fwrite($fhandle,"Postázási cím: $post_street Számlázási cím: $pay_street\n"); fwrite($fhandle,"Postázási irányítószám: $post_zip Számlázási irányítószám: $pay_zip\n"); fwrite($fhandle,"\n"); fwrite($fhandle,"Vezetékes telefonszám: $user_tel1\n"); fwrite($fhandle,"Mobil telefonszám: $user_tel2\n"); fwrite($fhandle,"E-mail cím: $user_email\n"); fwrite($fhandle,"Megjegyzés: $user_other\n"); fwrite($fhandle,"\n"); fwrite($fhandle,"Végösszeg: $sum Ft\n"); fwrite($fhandle,"\n"); fwrite($fhandle,"Kedves Vásárlónk!\n"); fwrite($fhandle,"\n"); fwrite($fhandle,"A kiválasztott termék(ek) megrendelését most digitális aláírásával hitelesítenie kell!\n"); fwrite($fhandle,"FONTOS: Az aláírás után megrendelése egy óra múlva érvényessé válik, a szerz dés feltételeir l\n"); fwrite($fhandle,"(rövid id n belül) egy visszaigazolást fogunk küldeni megadott e-mail címére.\n"); fwrite($fhandle,"Üzletszabályzatunk alapján, a szerz dés a kézbesítését l számítva egy óra múlva lép érvénybe.\n"); fwrite($fhandle,"Ezen id ponton belül Önnek még van lehet sége a szerz dést érvényteleníteni (üzletszabályzatban leírtak szerint).\n"); fwrite($fhandle,"A szállítási és fizetési feltételek elérhet k a termék-ismertet knél, illetve a szerz dés is tartalmazza azt.\n"); fwrite($fhandle,"Kérjük, digitális aláírásával hitelesítse megrendelését!\n"); fwrite($fhandle,"\n"); fwrite($fhandle,"Köszönjük!\n"); fwrite($fhandle,"\n"); fclose($fhandle); $transaction_localfile="$basefile.txt"; $transaction_hostfile="$basefile.txt"; $save_file="$data.txt"; $mimetype_plugin="application/x-identrus-signing-plug-in"; $mimetype_transaction=$value; $verifier="SCOUTTXT"; echo("
A telepít CD-n megtalálható a Utimaco SafeGuard Transaction Client 3.1 verziójú szoftver. Ez tartalmaz egy Internet Explorerhez tartozó ActiveX plug-int és egy Netscapehez való Java beépül modult. Emellett egy LDAP böngész is található a csomagban. A telepítés során meg kell adni azt a nyilvános LDAP adatbázist, ahol a visszavonási listák elérhet k. A program azonban ezen beállítás nélkül is m ködik. Az els indításnál lehet beállítani a titkos kulcs elérési helyét. Ez lehet valamilyen hagyományos háttértár vagy biztonságos aláíró eszköz (smart card, USB token).
18. ábra: Kulcstároló eszköz kiválasztása
A kiválasztás után a képerny n megjelenik a kulcs(ok) és tanúsítvány(ok) neve és típusa.
75
19. ábra: A kiválasztott kulcsok típusa
Végül meg kell adnunk a kulcsokhoz tartozó jelszót.
20. ábra: Jelszó beállítása
76
5.2 Az aláíró modul m ködése: A vásárló a bolt elérésekor el ször a vásárolható áruk listájával találkozik. Több szempont szerint is kereshet az árukészletben, részleteket tudhat meg az eszközökr l. A kiválasztott termékre rákattintva jut el a vásárló a következ oldalra. .
21. ábra: Termék kiválasztása
A kiválasztás után megjelen ablakban lehet beállítani, hogy az adott termékb l hány darabot szeretne a vev rendelni.
22. ábra: Rendelend mennyiség kiválasztása
Ha a kívánt mennyiséget beírta, a következ menüben van lehet sége ellen rizni a rendelt áruk mennyiségét és árát, illetve módosítani a rendelést.
77
23. ábra: Rendelés összesítése
Ha minden adatot megfelel nek tart, be kell írnia az adatait a megadott kérd ívbe.
24. ábra: A megrendel adatainak megadása
78
Ha a rendel modul minden adatot rendben talál, a szerver meghívja a kliens oldalon telepített Transaction Client szoftvert. Ez a trans.cgi fájlon keresztül történik. A fájl változóként megkapja a szerz dés szövegét, a kódolás típusát, a helyi mentés és a beágyazás kiválasztását. Ezután el állítja a kliens böngész jében a kiválasztott szerz dési formát.
25. ábra: Aláíró modul
A felhasználó a Sign gombra kattintva tudja meghívni a saját aláíró modulját, ami a PIN kód beütése után el állítja szerz déshez tartozó elektronikus aláírást, majd elküldi ezt a szervernek.
26. ábra: Aláírás engedélyezése
79
A Transaction Server ellen rzi a tanúsítvány érvényességét és az adat eredetiségét, majd elmenti a szerz dés szövegét,
27. ábra: Megrendelés szövege a szerveren
az aláíró tanúsítványát
28. ábra: Aláíró tanúsítványa a szerveren
80
és egy bejegyzést, amib l kiderül, hogy a szerz dést rendben találta, vagy valamilyen gond volt vele.
29. ábra: Bejegyzés a tranzakció sikerességér l
A kliensnél ennek a döntésnek megfelel üzenet jelenik meg.
30. ábra: Értesítés a tranzakció eredményér l a kliens böngész jében
81
5.3 Tapasztalatok összefoglalása:
82
•
Annak ellenére, hogy a Transaction Client a dokumentáció szerint támogatja a Netscape böngész ket, a 7-es verzióval nem sikerült összepárosítani. Valószín leg csak a Netscape korábbi verzióit ismeri fel.
•
A Transaction Server egy szabványosnak t n plug-in-t hív meg a kliens böngész jében. Ez az application/x-identrus-signing-plugin. Többek között a SmartTrust ID2 Personal kliens szoftvere is képes támogatni ezt a plug-in-t. Csak valószín leg más változókkal m ködik, mint a Utimaco Transaction Client, ezért mégse lehet felhasználni. Meg kell állapítanunk, hogy a különböz gyártók szoftverei interoperabilitásból elégtelenre vizsgáztak.
•
A CRL-ek kezelésével mind szerver, mind kliens oldalon komoly gondok vannak. A kísérleti CA szolgáltató nem engedett hozzáférést a saját LDAP-jához, csak httpn keresztül lehet letölteni a visszavonási listájukat. A kliens szoftver csak LDAP-on keresztül hajlandó elfogadni a CRL-t, ezért kénytelenek voltunk ezt az ellen rzési lehet séget kikapcsolni. A szerver jobban teljesített, itt egy külön könyvtárba kellett bemásolni a CRL-t. Igen ám, de a szolgáltató 8 óránként frissíti az adatbázisát, ami miatt a Transaction Server 8 óra után nem fogad el semmilyen tanúsítványt. Mivel automatikus frissítési lehet ség nincs, ezért kénytelenek voltunk minden alkalommal manuálisan elvégezni a CRL frissítést. Lehet ség van még OCSP-n keresztüli frissítésre is, ezt azonban nem támogatja a szolgáltató, holott ezzel a módszerrel kényelmesen meg lehetne oldani a mindenkori tanúsítványellen rzést.
•
Az egységes szabvány hiánya leginkább a smart cardoknál jelentkezett. A kártyaolvasót minden gond nélkül sikerült felinstallálni. Három kártyatípus állt rendelkezésünkre: Oberthur, Setec és Schlumberger gyártmányúak. A szolgáltató honlapján lehet ség volt kártyán való kulcsgenerálásra. A három kártyatípus közül egyedül a Schlumberger kártyákat lehetett ilyen célra felhasználni. Illetve azt sem, hiszen a rendelkezésünkre álló CryptoFlex kártyát éppen nem támogatta a szoftver. Következ lehet ségünk az volt, hogy a merevlemezre generált kulcsot utólag másoljuk fel kártyára. Ehhez rendelkezésre állt a Oberthur AuthentIC szoftvere, ami természetesen csak az Oberthur kártyákkal m ködött együtt. Illetve azokkal sem. Hosszas próbálkozás után jöttünk rá arra, hogy a kártyát még azel tt az olvasóba kell helyezni, hogy az bekapcsolna. Így végül felismerte a kártyát, csak a szolgáltatótól kapott PIN kódot nem fogadta el. A kártya pozitívuma, hogy a harmadik próbálkozás után a kártya lezárt, így az Oberthur kártyával való próbálkozást a megfelel alacsonyszint szoftverek hiányában fel is adtuk.
•
A rendszert kipróbáltuk nem Utimaco által generált tanúsítvánnyal is. Miután a szerver oldalon megtettük a szükséges intézkedéseket, a rendszer ezzel a tanúsítvánnyal is rendben m ködött. A Transaction Server dokumentációjából nem derül ki, hogy a tanúsítvány mely mez it ellen rzi. Ez akkor lehet aggályos, ha a tanúsítvány nem rendelkezik olyan felhatalmazásokkal, amik lehet vé teszik a
távoli azonosítást. Például elképzelhet egy olyan elektronikusan aláírt dokumentum, amihez olyan tanúsítványt csatoltak, ami csak e-mail hitelesítésre alkalmas. •
A hitelesítés szolgáltatónak csak a tesztrendszerét tudtuk kipróbálni. Ha azonban erre is érvényesnek tekintjük a Hitelesítés Szolgáltatási Szabályzatot (CPS), akkor a szolgáltató sajnos nem teljesíti az abban leírtakat. A visszavonási listákat több alkalommal nem lehetett elérni. Emiatt a Transaction Server m ködése egy teljes napig szünetelt. A tesztrendszernél ez még kevésbé fontos, viszont az éles rendszer is néha elérhetetlen volt. A webes tanúsítványtárban nem lehet keresni, bár a CPS szerint erre is lehet séget biztosítanak. Ez az állapot biztosan meg fog változni, mindenesetre az ilyen jelleg hibák és hiányosságok jelenleg nem segítik el rendszerfejlesztést.
•
Bár a szolgáltató bejegyzett min sített hitelesítés szolgáltató, eddig még nem tette közzé az ehhez a szolgáltatáshoz tartozó tanúsítványát. A fokozott biztonságú tanúsítványáról azonban elmondható, hogy nagyon jó min ség , mentes a felesleges mez kt l, gyakorlatilag megfelel a min sített tanúsítványok számára el írt követelményeknek.
5.4 Javaslat egy m köd képes megoldásra: A tranzakcióban három résztvev van: a felhasználó, a keresked és a hitelesítés szolgáltató. Ha egy mindenki által használható megoldáshoz szeretnénk jutni, a következ ket kell tennünk: Felhasználó: ideális esetben a legtöbb felhasználó azonos kártyával rendelkezik. Ezzel elkerülhet k a különböz gyártók közötti inkompatibilitások. Minél több fajta kártya van forgalomban, annál reménytelenebb mindenki számára elérhet szolgáltatásokkal el állni. Viszont az sem megoldás, hogy a felhasználónak sok kártyát kelljen használni. Ezért az egy ember, egy kártya elvet csak úgy látjuk megvalósíthatónak, ha az a kártya alanyi jogon jár mindenkinek. Ilyen megoldás lehet egy kriptográfiai chippel szállított diákigazolvány vagy személyi igazolvány, esetleg munkakártya. A smart cardok szabványosítása után lenne csak lehet ség ezen téren az igazi piaci versenyre. Ez azonban még nem várható a közeli jöv ben. A PKI rendszerek elektronikus kereskedelemben való használatának másik kerékköt je a kliens alkalmazások inkompatibilitása. Nem várható el egyetlen keresked t l sem, hogy minden létez PKI rendszer kliensszoftverének megfelel szervert integráljon a webes boltjába. Ha már rendelkezésre áll egy piaci szabvány az internetes kérd ívek aláírására (application/x-identrus-signing-plugin), akkor minden kliensnek tudnia kéne kezelnie azt. Természetesen minden böngész vel, minden operációs rendszer alatt.
83
A kliens oldalhoz tartozik még a kártyaolvasó. Ezek már gyártótól függetlenül felismernek szinte minden kártyát. Gond azonban, hogy szinte csak Windows alá találhatók meghajtóprogramok. Kívánatos lenne a terjeszkedés más operációs rendszerek felé is. Keresked : az elmúlt években kialakultak azok a technikák, amik segítségével a cégek elektronikus boltjai hiba nélkül, megbízhatóan és automatikusan m ködjenek. Az elektronikus aláírás azonban szolgál néhány újdonsággal, ami miatt kicsit át kell szervezni a munkafolyamatokat. Amikor a keresked bels rendszere megkapja a rendelést, ellen rizni kell az aláírás megfelel ségét. Bár a kipróbált alkalmazás a sértetlenséget ellen rzi, a hitelesség biztosításához külön alkalmazás vagy manuális beavatkozás szükséges. Meg kell róla ugyanis gy z dni, hogy a tanúsítványban szerepl adatok azonosak–e a megrendel lapon szerepl kkel. Amennyiben azonosak, a megrendelés hitelesnek, sértetlennek és letagadhatatlannak bizonyult. A letagadhatatlanságot azonban a keresked nek is biztosítania kell. A következ lépés tehát egy visszaigazolás elküldése. Ez lehet például egy pro forma számla. Ez megfelel a kés bb küldend papírszámlának, el nye viszont, hogy azonnal megjelenik a vev nél, a számlázórendszerben felhasználható, elektronikusan alá van írva, tehát letagadhatatlan, és a rajta szerepl adatokkal a vev ellen rizheti, hogy tényleg azok az áruk szerepelnek, amiket megrendelt. Ennek megvalósítását viszont a kipróbált szoftver nem biztosítja, valószín leg egy ilyen szoftvert külön kellene kifejleszteni. Marad tehát a manuális válasz. A fizetés két módon történhet. A legkényelmesebb a bankkártyás fizetés. Ennek jól bejáratott módszerei vannak, így ezek részletezését l eltekintek. A másik megoldás az átutalás. Magyarországon a cégek nagy része nem rendelkezik bankkártyával, ezért számukra az átutalásos fizetés az ideális megoldás. Az elektronikus pro forma számlával ennek minden akadálya elhárul, hiszen az átutaláshoz szükséges minden adat rendelkezésre áll. Az elektronikus aláírás használatával tehát közelíthetünk a hétköznapi vásárlási módozatokhoz, amivel csökkenteni lehet a vev k bizalmatlanságát, ami az elektronikus kereskedelem legnagyobb problémája. Hitelesítés szolgáltató: ha a piacon nagy mennyiség aláíráshordozó eszköz van, akkor elkezd dhet az igazi verseny a szolgáltatók között. Az állampolgárok csak egy üres chipet kapnak, annak feltöltése az feladatuk. Választhatnak a piaci szerepl k közül, akik így rákényszerülnek, hogy egyre olcsóbban, egyre jobb min ség szolgáltatást nyújtsanak. De amellett, hogy egymással versenyeznek, együtt is kell m ködniük, hiszen a vonatkozó szabványok lehet séget nyújtanak többféle megvalósításra. Legfontosabb feladatuk a markáns jelenlét lenne. Jelenleg Magyarországon nem könny tanúsítványhoz jutni. Vidéken például egyik szolgáltatónak sincs kirendeltsége. Fontos tehát területi irodák megnyitása vagy valamilyen meglev , országos kiterjedés hálózattal megállapodni. Minél többet kell reklámozniuk szolgáltatásaikat, mert az elektronikus aláírás a legtöbb számára ismeretlen fogalom. Támogatniuk kell a keresked k fejlesztéseit, hiszen alkalmazás nélkül nincs kereslet a szolgáltatásukra.
84
Összefoglalva a tapasztalatokat, jelenleg egy PKI technológián alapuló elektronikus kereskedelmi rendszer kifejlesztése könny és mégis nehéz. Könny , hiszen az alapvet dolgokat 20 új sor programkódba való beillesztésével el lehet érni. De nehéz is, hiszen ezután szembesül a programozó az inkompatibilitási és interoperabilitási problémákkal. A legnehezebb mégis a felhasználók és az internetes boltok meggy zése a elektronikus aláírás használatának el nyeir l.
85
6 Rövidítések jegyzéke AES B2B B2C B2G CA CP CPS CRL DES EDI LDAP OCSP PKI RA RSA SET SSL TTP XML
86
Advanced Encryption System Business-to-Business Business-to-Costumer Business-to-Government Certification Authority Certificate Policy Certificate Practice Statement Certificate Revocation List Data Encryption Standard Electronic Data Interchange Lightweight Directory Access Protocol Online Certificate Status Protocol Public Key Infrastructure Registration Authority Rivest Shamir Adleman Secure Electronic Transaction Secure Socket Layer Trusted Third Party Extended Markup Language
Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, „ Handbook of Applied Cryptogaphy” , CRC Press, 1996 Ronald Grimm, „ Guide to Intelligence Operations” , http://www.geocities.com/grimm005/index.htm, 2001 Buttyán Levente: „ Brief Overview of Cryptography” , http://www.hit.bme.hu/~buttyan/courses/internetsecurity1/Cryptography_Overview.ppt , 2003 „ Public-key Infrastructure” , Certicom, 2001 Daniel Amor: „ Introduction to Internet Business” , Hewlett Packard, 2001 Szigeti Szabolcs: „ Az e-business” , IBM-BME E-business Akadémia, 2001 „ IT Security Audit” , Secaron AG, 2002 „ FIPS PUB 140-2” , National Institute of Standards and Technology, 2001 Lawrence M. Walsh: „ Security Standards” , Information Security Magazine, 2002 Kondorosi Károly, Molnár Imre: „ Számítástechnikai Audit” , BME jegyzet, 2002 Szabó Áron, Krasznay Csaba: „ A digitális aláírás elterjedésének lehet ségei és korlátai” , TDK dolgozat, 2001 „ Risk Assessment Guidebook For e-Commerce/e-Government” , The National Electronic Commerce Coordinating Council, 2000
