Návrh systému pro bezpečné platby v prostředí Internetu

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Návrh systému pro bezpečné platby v prostředí Internetu Bakalářská práce

Autor:

David Kopřiva Informační technologie

Vedoucí práce:

Praha

Ing.Vít Fábera, Ph.D.

Duben 2010

Prohlášení: Prohlašuji, ţe jsem tuto bakalářskou práci zpracoval samostatně a s pouţitím uvedené literatury a informačních zdrojů.

V Praze dne 15. dubna 2010

David Kopřiva

Anotace Cílem této práce je navrhnout systém, který by zajišťoval provádění bezpečných plateb v prostředí Internetu. Nedílnou součástí je zmapování přehledu současných platebních metod v tomto prostředí, které je nutné pro výběr vhodného řešení. V teoretické části jsou popsány znalosti nutné pro správnou analýzu a návrh řešení. Modelování systému je provedeno za pouţití jazyka UML. Samostatná kapitola je věnována testování a bezpečnostním aspektům nutným pro návrh takovéhoto systému.

Annotation The aim of this work is to design a system that would ensure the implementation of secure payments in the Internet environment. Integral part is survey of current methods of payments in this environment, which is necessary for the selection of a suitable solution. The theoretical part describes the knowledge necessary for proper analysis and design solutions. System modeling is done by using UML language. A separate chapter is devoted to

testing

and

safety

aspects

needed

to

design

such

a

system.

Obsah ÚVOD.................................................................................................................................... 7 1

2

3

PLATBY V PROSTŘEDÍ INTERNETU ..................................................................... 9 1.1.1

Dobírka/platba při osobním odběru ................................................................. 9

1.1.2

Převody mezi bankovními účty ....................................................................... 9

1.1.3

Platební karty ................................................................................................... 9

1.1.4

Platba přes platební bránu ............................................................................... 9

1.1.5

Mobilní platby ............................................................................................... 10

1.1.6

Elektronické peněţenky................................................................................. 10

VÝBĚR ZPŮSOBU PLATEBNÍ METODY .............................................................. 11 2.1.1

3-D Secure ..................................................................................................... 11

2.1.2

Virtuální platební karta .................................................................................. 11

2.1.3

Volba způsobu plateb .................................................................................... 12

PROSTŘEDKY PRO REALIZACI ............................................................................ 13 3.1

Jazyk UML ........................................................................................................... 13

3.2

Popis třívrstvé architektury ................................................................................... 15

3.3

Architektura aplikací s vyuţitím návrhového vzoru MVC ................................... 16

3.4

Java EE5 ............................................................................................................... 17

3.4.1

Java Server Faces........................................................................................... 17

3.4.2

JSP/JSTL ....................................................................................................... 17

3.4.3

Spring Framework ......................................................................................... 17

3.4.4

Hibernate ....................................................................................................... 18

3.4.5

JDBC ............................................................................................................. 18

3.4.6

Databázový server ......................................................................................... 18

3.4.7

Klient ............................................................................................................. 18 4

4

ÚVODNÍ STUDIE ...................................................................................................... 19 4.1

5

Odborný článek ..................................................................................................... 19

ANALÝZA A NÁVRH ŘEŠENÍ ................................................................................ 22 5.1

Zvolený postup pro provedení analýzy pomocí jazyka UML .............................. 22

5.2

Katalog poţadavků ............................................................................................... 23

5.3

Vazba uţivatelských poţadavků na případy uţití ................................................. 26

5.4

Diagram případů uţití ........................................................................................... 27

5.5

Popis případu uţití „IS-aplikační logika pro klientskou zónu“ ............................ 28

5.6

Návrh uţivatelského rozhraní ............................................................................... 30

5.7

Sekvenční diagramy .............................................................................................. 31

5.7.1

Scénář otevření virtuální karty ...................................................................... 31

5.7.2

Scénář změny čísla mobilního telefonu ......................................................... 32

5.7.3

Scénář provedení transakce pro ověření platby ............................................. 33

5.8

Doménový model .................................................................................................. 34

5.8.1

Základní doménový model ............................................................................ 34

5.8.2

Vazba doménového modelu na případy uţití ................................................ 35

5.9

Diagram tříd .......................................................................................................... 36

5.10

Datový model .................................................................................................... 37

5.11

Diagram komponent .......................................................................................... 38

6

REALIZACE ............................................................................................................... 39

7

TESTOVÁNÍ ............................................................................................................... 40 7.1

Pojem testování ..................................................................................................... 40

7.2

Testování v rámci vývojové fáze .......................................................................... 40

7.3

Testování v rámci fáze předávání do provozu ...................................................... 41

7.3.1

User Acceptance Test (UAT) ........................................................................ 42

7.3.2

UAT - Platba virtuální kartou ........................................................................ 42 5

8

BEZPEČNOST NAVRHOVANÉHO ŘEŠENÍ .......................................................... 43 8.1

Bezpečnost při návrhu informačního systému ...................................................... 43

8.2

Návrh bezpečného řešení pro provádění plateb .................................................... 44

8.2.1

Bezpečnostní rámec Acegi Security .............................................................. 45

8.2.2

Autentizace .................................................................................................... 45

8.2.3

Autorizace...................................................................................................... 45

8.2.4

Systém logování ............................................................................................ 46

8.2.5

Auditní informace .......................................................................................... 46

8.2.6

Autorizace v aplikační vrstvě ........................................................................ 46

ZÁVĚRY A DOPORUČENÍ .............................................................................................. 47 SEZNAM POUŢITÉ LITERATURY ................................................................................. 48 SEZNAM PŘÍLOH ............................................................................................................. 49 SEZNAM OBRÁZKŮ ........................................................................................................ 49 SEZNAM TABULEK ......................................................................................................... 49

6

ÚVOD V současné době je placení kartou na Internetu stále oblíbenější a proto celá řada finančních společností hledá pro své stávající drţitele platebních karet (je v zásadě lhostejno, zdali se jedná o debetní či kreditní kartu) vhodný způsob řešení tohoto problému. Důkazem této obliby je fakt, ţe jiţ v roce 2008 bylo uskutečněno co do počtu transakcí více plateb u obchodníků neţ výběru z bankomatů. V porovnání s rokem 2007 se také téměř o třetinu (29 %) zvýšil počet obchodníků umoţňující zákazníkům za prodávané zboţí zaplatit kartou na Internetu. Mnoţství plateb přes Internet za stejné období stouplo dokonce o 50 procent.1 Takové řešení musí být jednoduché, rychlé, uţivatelsky příjemné a zároveň poskytovat vysoký stupeň zabezpečení. V této oblasti se nejčastěji setkáváme s těmito doporučeními: Nakupovat pouze v doporučených obchodech Nesdělovat své číslo karty e-mailem ani telefonem ţádné třetí straně Pro tyto platby mít separátní limit na kartě Vyuţívat moţnosti „uzamknout“ platební kartu po provedení nákupu Lze tedy konstatovat, ţe po několika letech, kdy dominantním způsobem platby za zboţí (zejména v prostředí českého Internetu) byla dobírka, následována převodem peněz na účet obchodníka nebo hotovostní platbou při osobním odběru zboţí, dochází k nárůstu plateb pomocí platebních karet. V této situaci se nachází i nejmenovaná finanční společnost, která hledá optimální řešení pro své klienty, drţitele revolvingových (kreditních) karet. Karty jsou vydávány ve spolupráci se společností Mastercard2. Informační systém společnosti, jiţ umoţňuje

1

Zdroj idnes.cz, finance 6. března 2009 Společnost MasterCard International spravuje komplexní portfolio známých a široce přijímaných značek platebních karet MasterCard, MasterCard Electronic a Maestro. Jako organizace sdruţující více neţ 15,000 finančních institucí poskytuje MasterCard sluţby zákazníkům ve více neţ 200 zemích světa. 2

7

provádět všechny standardní operace spojené s kreditními kartami, ale funkcionalita umoţňující realizovat bezpečné platby v prostředí internetu není dosud implementována. Přínos tohoto řešení je očekáván zejména v těchto oblastech: přidaná hodnota ke stávajícím sluţbám pro klienty zvýšení objemu transakcí další nástroj pro udrţení klienta a získání nového

Cílem této práce je návrh systému, který bude zajišťovat provádění bezpečných plateb v prostředí Internetu. Navrţené řešení musí vyhovovat jak z technického (pouţití standardních technologií, snadná implementace do stávajícího informačního systému společnosti atd.) a bezpečnostního pohledu, tak sledovat obchodní cíl společnosti v této oblasti. Volba vhodného způsobu řešení se neobejde jak bez zmapování současných způsobů placení v prostředí internetu, tak přesnou definicí poţadavků na tuto sluţbu. Následné vytvoření nového modulu informačního systému, který bude zajišťovat tuto funkcionalitu, není rovněţ snadnou záleţitostí. Je tedy nezbytné provést podrobnou analýzu, díky které můţeme předejít problémům při vývoji, sníţit čas potřebný k vytvoření systému a zvýšit pravděpodobnost úspěchu celého projektu. Před vlastním návrhem řešení jsou popsány teoretické předpoklady pro zvládnutí dané problematiky, zejména v oblasti architektury, bezpečnosti a testování softwarových aplikací. Samotný návrh je proveden za pomoci jazyka UML, který je vhodným nástrojem pro popis vyvíjeného systému ze všech hledisek důleţitých pro analýzu a návrh. V závěru je provedeno zhodnocení a popis poznatků získaných při všech fázích návrhu systému.

8

1 PLATBY V PROSTŘEDÍ INTERNETU Cílem této kapitoly není porovnávat jednotlivé způsoby plateb, ale zmapovat jejich funkčnost a těchto znalostí později vyuţít při návrhu systému.

1.1.1 Dobírka/platba při osobním odběru Jedná se o způsob platby, kdy zákazník platí za zboţí aţ v okamţiku převzetí zboţí nebo sluţby od doručovatelských sluţeb (Česká pošta, PPL, DHL, popř. vlastní doprava obchodníka). Z hlediska klienta se jedná asi o největší jistotu, ţe zaplatí to, co si objednal. Z pohledu prodejců se jedná spíše o riziko, ţe zákazník si objedná stejné zboţí v několika obchodech současně a zaplatí pouze za zásilku, která bude doručena jako první. Platba se odehrává v offline prostředí, je řazena do makroplateb a většinou nelze zaplatit za zboţí vysoké hodnoty.

1.1.2 Převody mezi bankovními účty Je běţná a velmi nenáročná forma bezhotovostních plateb. Nevýhodou můţe být čas nutný k připsání platby na účet obchodníka, který aţ poté pokračuje v dokončení objednávky. Tento způsob platby řadíme do makroplateb, charakterem se opět jedná o offline platbu.

1.1.3 Platební karty Zákazník vkládá údaje o platební kartě přímo do zabezpečeného formuláře platební brány systému, který provozují specializované společnosti, popř. přímo banky. Tato karta musí mít povolené platby na Internetu (VISA nebo MasterCard, kromě některých neembosovaných karet naopak nejde platit kartami American Express a JCB). Ze systémového pohledu je nejrozšířenější způsob typu 3D Secure nebo virtuální karta. Rozsah plateb je neomezen, v rámci karetních asociací jsou ale účtovány poplatky z kaţdé transakce (obvykle 1,5-3 procenta). Platby kartou řadíme do makroplateb a online plateb.

1.1.4 Platba přes platební bránu Tato platba je realizována prostřednictvím speciální brány propojené s internetovým bankovnictvím (v případě banky) nebo platebním systém nebankovní finanční společnosti. Zákazník je po výběru zboţí a zvolení tohoto způsobu platby přesměrován do platebního systému banky/společnosti, kde je transakce ihned realizována a zákazník je informován výsledku platby. Nevýhodou často bývá náročnost implementace tohoto řešení do systému 9

obchodníka, kterou musí banka/společnost realizovat vţdy s kaţdým obchodníkem zvlášť. Platbu pomocí platební brány řadíme do makroplateb, charakterem se jedná o online platbu

1.1.5 Mobilní platby Platby prostřednictvím mobilního telefonu (nejedná se ale o GSM banking – ovládání běţného účtu mobilem), kde jsou částky strhávány z kreditu zákazníka nebo připočítávány k pravidelnému vyúčtování. V ČR se jedná o Premium SMS (nabízejí všichni operátoři) a m-platbu (pouze T-Mobile). Mobilní platby řadíme do mikroplateb a online plateb.

1.1.6 Elektronické peněţenky Jedná se o typ virtuálního účtu, kam zákazník nejdříve převede peněţní prostředky (převodem z účtu nebo karty klienta), s nimiţ následně platí v e-shopech. Elektronické peněţenky řadíme do mikroplateb a online plateb. Nejrozšířenějším systémem je Paypal, který je v současné době asi nejznámějším nebankovním platebním systémem. Ten u nás není příliš známý, protoţe ještě relativně nedávno nebylo moţné si z České republiky účet otevřít, nicméně tato skutečnost se změnila a také z ČR je moţné PayPal vyuţívat. PayPal je z principu nebankovní systém zprostředkovávající platby mezi jednotlivými svými uţivateli. Těch je v současné době mnoho desítek milionů a jde tak o jeden z nejrozšířenějších platebních systémů (PayPal byl koupen společností eBay provozující jedno z největších stejnojmenných světových on-line trţišť). Pomocí systému PayPal se platí především v případech, kdy klient posílá peníze ze svého účtu, avšak příjemci nechce dát k dispozici údaje o své platební kartě. Nejznámější systémy, zaloţené na podobném principu jsou PaySec, PayPay, Money Bookers a BidPay.

10

2 VÝBĚR ZPŮSOBU PLATEBNÍ METODY Cílem této kapitoly je výběr vhodného způsobu platební metody. Z popsaných variant řešení plateb v předchozí kapitole je zřejmé, ţe preferovaným způsobem řešení bude způsob pomocí 3-D Secure nebo virtuální karty.

2.1.1 3-D Secure Jedná se o technologické řešení, které zajišťuje ověření (autentifikaci) drţitele karty jiţ v průběhu transakce (autorizace). Cílem řešení je poskytnout obchodníkovi i zákazníkovi stejnou míru bezpečnosti jako při placení v kamenném obchodě. Systém zabezpečených plateb 3-D Secure podporují obě největší kartové asociace VISA (Verified by VISA) a MasterCard (MasterCard SecureCode). Zákazník si nejdříve v internetovém obchodě vybere zboţí. Pokud se v té chvíli rozhodne pro úhradu platební kartou, je přesměrován na stránku banky obchodníka, kde vyplní a odešle platební údaje. Banka si nechá objednávku odsouhlasit obchodníkem a ověří si u karetní asociace, zda je karta zařazena do systému 3D-Secure. V případě, ţe dostane zápornou odpověď, pokračuje autorizací platby a oznámením výsledku transakce (proběhla úspěšně nebo platba nebyla autorizována). Je-li karta v 3D-Secure zapojena, zašle obchodníkova banka ţádost o autentizaci (ověření) karty přes prohlíţeč zákazníka do banky zákazníka. Zákazníkova banka poţádá svého klienta o zadání hesla (či jinou formou kartu autentizuje - ověří) a výsledek vrátí přes prohlíţeč klienta do obchodníkovy banky. Proběhne-li vše úspěšně, dokončí se běţné ověření transakce a blokace prostředků na účtu zákazníka.

2.1.2 Virtuální platební karta V tomto případě se opět jedná o řešení, které podporují obě největší kartové asociace (VISA, Mastercard). Virtuální v tomto případě znamená, ţe klient nevlastní klasickou plastikovou kartu, ale pouze 16-ti místné číslo, které je určené výhradně k provádění transakcí v internetovém prostředí (tzv. e-commerce transakcí). K provádění plateb je rovněţ nutné disponovat ještě tzv. expiration date (dobu platnosti) a kontrolním kódem, který je označován jako CVC nebo CVC2. Nutnou podmínkou pro pouţití tohoto řešení je existence „fyzické“ platební karty klienta, na základě které je tato karta vytvořena.

11

2.1.3 Volba způsobu plateb Vzhledem k tomu, ţe finanční společnost, pro kterou bude celý systém navrhován, vystupuje pouze v roli vydavatele karet (tzv. issuer), tak se řešení 3-D Secure jeví jako „zbytečně silné“. Dalším důleţitým faktem je vysoká cena tohoto řešení (detailní rozbor není součástí této práce), tak nutnost platit za kaţdou evidovanou kartu v tomto systému. Po prostudování podmínek asociace Mastercard a stávajících funkcionalit informačního systému finanční společnosti se virtuální platební karta jeví jako ideální řešení, zejména z následujících důvodů: Nízké náklady na pořízení systému vzhledem ke skutečnosti, ţe finanční společnost je schopna realizovat toto řešení ve vlastní reţii Karetní společnost, která pro finanční společnost zajišťuje zpracování transakcí na platebních kartách, je certifikována karetní asociací Mastercard pro poskytování tohoto řešení Expiration date a CVC2, který je pro kaţdou platbu unikátně generován, lze časově omezit Moţnost snadného ovládání plateb přímo klientem (drţitelem karty) z jiţ existujícího portálu, který má finanční společnost pro své klienty vybudován Moţnost zvolit přesnou částku platby Klient sám můţe uzamknout kartu v době, kdy není pouţita

12

3 PROSTŘEDKY PRO REALIZACI V této části práce jsou shrnuté teoretické předpoklady a proveden základní popis prostředků pouţitých při pozdější realizaci informačního systému. V průběhu jeho návrhu se budeme k jednotlivým částem vracet či se na ně přímo odvolávat.

3.1 Jazyk UML Jazyk UML (Unified Modeling Language) lze charakterizovat jako prostředek pro grafickou tvorbu objektových modelů. Jazyk jako takový se je znám od poloviny devadesátých let, kdy došlo ke sloučení do té doby dvou nejvíce pouţívaných metodik Booch3 a OMT4.

Nejdříve vznikla verze 1.0, která začala být konsorciem OMG5

doporučována jako standard, coţ umoţnilo její rozšíření. V současné době je UML k dispozici ve verzi 2.0, kde jsou k dispozici nové typy diagramů, zejména diagram přehledu interakcí, načasování a smíšené struktury.

Obrázek č. 1 - Unified Modeling Language Zdroj: http://upload.wikimedia.org/wikipedia/commons/d/d6/Uml_diagram2.png

3

Booch metodika zaměřená zejména na design a implementaci OMT: Object Modeling Technique 5 OMG: Object Management Group 4

13

Diagram balíčků (Package Diagram) Slouţí k dekompozici systému a seskupení souvisejících prvků v modelu. Jejich prostřednictvím je moţné znázornit závislosti mezi dílčími částmi systému Diagram aktivit (Activity Diagram) Modelují chování systému a znázorňují tok činností, tj. sled jejich provádění včetně větvení na základě splněných podmínek. Diagram případů užití (Use Case Diagram) Slouţí ke znázornění chování systému z pohledu uţivatele (actora), lze znázornit interakci systému a uţivatelů při vykonávání určité ohraničené jednotky činností. Diagram tříd (Class Diagram) Slouţí ke znázornění statické struktury modelovaného systému, znázorňuje typy objektů a vztahy mezi nimi. Jedná se patrně o nejznámější diagram. Stavový diagram (State Machine Diagram) Slouţí ke znázornění stavů a přechodů mezi nimi. Typicky se jedná o stavy jedné třídy nebo ţivotní cyklus entity. Diagram komunikace (Communication Diagram) Dokumentují spolupráci objektů při řešení úlohy a zobrazují toky událostí mezi třídami včetně jejich pořadí (dříve se nazývaly diagramy kolaborace) Diagram komponent (Component Diagram) Zobrazuje a popisuje jednotlivé komponenty, ze kterých se celý systém skládá. Diagram vnitřní struktury (Composite Structure Diagram) Jsou určeny pro vyjádření kolaborace instancí a instancí komunikačních struktur Diagram nasazení (Deployment Diagram) Popisují fyzické rozmístění jednotlivých komponent v rámci výpočetního systému. Diagram přehledu interakcí (Interaction Overview Diagram) Zachycuje tok řízení v rámci systému nebo procesu. Kaţdý uzel nebo aktivita v rámci diagramu můţe reprezentovat další diagram interakce. Objektový diagram (Object Diagram) Znázorňuje objekty a jejich vztahy na úrovni jejich konkrétních instancí. Sekvenční diagram (Sequence Diagram) Znázorňuje, jak se jednotlivé akce instancí tříd mění v čase včetně vzájemné komunikace mezi nimi. 14

3.2 Popis třívrstvé architektury Standardem při vývoji moderních webových aplikací je důsledné rozdělení architektury aplikace do tří vrstev. Kaţdá vrstva je zodpovědná za určitou funkcionalitu a je relativně nezávislá na ostatních vrstvách. To přináší mnoţství výhod, zejména zvýšení čitelnosti, správy a rozšiřitelnosti kódu, moţnost nahrazení či rozšíření jen některé vrstvy v případě nových poţadavků na aplikaci (bez nutnosti upravovat ostatní, nezávislé vrstvy), snadnější spolupráci vývojářů, kteří si mohou své činnosti rozdělit právě na úrovni jednotlivých vrstev, apod. Datová (nebo také perzistentní) vrstva obsahuje programový kód, který manipuluje s daty, uloţenými v nějakém persistentním úloţišti. Většinou jde o relační databázi, ale data mohou být uloţena i jinde, např. v LDAP či přímo v souborovém systému. Datová vrstva tedy obsahuje operace, které data z datového úloţiště získávají nebo vytváří, upravují či maţou. V případě objektových jazyků, jakým je i Java, má navíc datová vrstva na starosti převod dat z datového úloţiště (většinou relační záznamy v případě databází) na aplikační objekty. Těmto aplikačním objektům, které obsahují data z datového úloţiště, se říká entity či souhrnně model. Datová vrstva vytváří rozhraní, které pouţívá vrstva aplikační. Aplikační (nebo také servisní, střední či business) vrstva obsahuje programový kód, který vykonává samotnou procesní logiku systému. Získává tedy data z datové (tedy z perzistentního datového úloţiště) a/nebo prezentační vrstvy (data z externích zdrojů, většinou vkládaná do systému uţivatelem), tato data zpracovává a výsledky těchto kalkulací předává zpět do datové a/nebo prezentační vrstvy. Aplikační vrstva představuje jádro systému, které uchovává klíčové know-how o systémem modelovaných procesech a systémem prováděných výpočtech. Aplikační vrstva vytváří rozhraní, které pouţívá vrstva prezentační. Prezentační (nebo také UI) vrstva předkládá (prezentuje) data systému získaná z prezentační vrstvy, či naopak získává, validuje a zpracovává externí vstupní data a připravuje (transformuje) je pro předání aplikační vrstvě. Většinou jde o webové uţivatelské rozhraní, tedy o sadu HTML stránek, které lze prohlíţet internetovým prohlíţečem.

15

3.3 Architektura aplikací s vyuţitím návrhového vzoru MVC Vzhledem k tomu, ţe při návrhu tříd systému bude pouţita softwarová architektura známá pod názvem Model-view-controller (MVC), je nezbytné porozumět alespoň v obecné rovině co tento architektonický (návrhový) vzor popisuje a řeší. Návrhový vzor, který popisuje ověřená řešení určitých problémů při návrhu systému, napomáhá při tvorbě elegantního, jednoduchého a znovupouţitelného řešení. Cílem je zabránit opakovanému vytváření programů, které v zásadě dělají totéţ. Prvním krokem je nalezení vhodných objektů (domén) navrhovaného systému, abstrahovat od nich a zároveň nadefinovat třídy se správnou granularitou. Součástí této definice je zároveň tvorba rozhraní tříd, definice hierarchie dědičnosti a jednotlivých vztahů mezi třídami. Principem návrhového vzoru MVC je rozdělení systému do tří částí: View – slouţí k vytvoření grafického rozhraní pro interakci s uţivatelem. Tato vrstva je chápána jako prezentační a jejím cílem je ji oddělit od vrstvy věcné a datové. Model – představuje věcnou a datovou logiku systému, často nejkomplikovanější vrstva systému, kterou je vhodné rozdělit do samostatných komponent Controller – je vrstva mezi prezentační (View) a vrstvou aplikační (Model). Zpracovává události v prezentační vrstvě a vyvolává metody objektů tvořící model. Na níţe uvedeném schématu je znázorněna MVC architektura, která vychází z návrhového vzoru Observer6

Obrázek č. 2 - Návrhový vzor Observer Zdroj: http://en.wikipedia.org/wiki/Observer_pattern

6

Návrhový vzor Observer řeší závislost jednoho objektu k více objektům. Při změně stavu tohoto objektu je potřeba informovat ostatní objekty na něm závislé.

16

3.4 Java EE5 Java Enterprise Edition (Java EE) je komplexní platforma pro tvorbu pokročilých podnikových aplikací a systémů. Základem pro tuto platformu je Java SE7, nad kterou jsou definovány součásti tvořící Javu EE. Jedná se především o specifikace pro vývoj webových aplikací (Java Servlets,JSP8), pro vývoj obchodní logiky (EJB9,Spring), pro přístup k jiţ existujícím systémům (JCA10,Hibernate) a pro tvorbu webových sluţeb za pomoci JMS11.

3.4.1 Java Server Faces JavaServerFaces (JSF) je jednou z technologií JAVA EE slouţící ke strukturovanému vývoji webových aplikací. Při pouţití JSF se u webové aplikace oddělí grafické uţivatelské rozhraní (GUI) od aplikační logiky. Faces jsou ve skutečnosti soubory na bázi XML12, pomocí kterých se specifikují odkazy na Java Beany uloţené v aplikačním serveru.

3.4.2 JSP/JSTL Java Server Pages – skriptovací jazyk na bázi Javy. Jeho specifikace je součástí JEE. V aplikaci se pouţívá pro formátování výstupů aplikace pro zobrazení uţivateli. Java Standard Tag Library - knihovna často pouţívaných skriptovacích značek JSP

3.4.3 Spring Framework Aplikační vrstva bude v aplikaci realizována s vyuţitím rámce Spring, který se stará o inicializaci objektů aplikační vrstvy (tzv. servisních neboli business objektů), o autorizaci uţivatelů na úrovni této vrstvy, o správu transakčního chování aplikace a o logování akcí aplikační vrstvy (auditing). Správu autorizace, transakčního chování i auditing vykonává Spring prostřednictvím své AOP13 funkcionality.

7

JavaStandardEdition-základní platforma pro tvorbu Java aplikací, skládá se z JRE (Java Runtime Environment, běhové prostředí Javy) a JDK (Java Development Kit, soubor nástrojů pro vývoj aplikací v Javě) 8 Java Server Pages–skriptovací jazyk na bázi Javy. V aplikaci se pouţije pro formátování výstupů aplikace uţivateli. 9 Enterprise Java Beans 10 JCA-Java Connector Architecture 11 JMS-Java Messaging Services 12 XML–Extensible Markup Language 13 Aspect-Oriented Programming. V softwarovém inţenýrství se paradigma aspektově orientovaného programování pokouší pomoci programátorovi v oddělení koncernů, neboli rozbít program na jasné části, které se co nejméně překrývají různou funkcionalitu.

17

3.4.4 Hibernate Jedna z nejrozšířenějších ORM14 technologií. ORM vrstva bude v našem případě zajišťovat objektově relační mapování datových struktur v aplikaci. Pouţitím ORM nástroje se výrazně zjednodušuje návrh datové vrstvy aplikačním programátorem. Programátor definuje převod relačních dat z databáze do datových objektů (entit) v Javě prostřednictvím anotací, při čemţ anotace jsou součástí jazyka Java od verze 1.5.

3.4.5 JDBC Java DataBase Connectivity je standard, který je součástí JSE a který představuje obecné rozhraní pro práci s databázemi v Javě. Prostřednictvím tohoto rozhraní lze stejným (standardizovaným) způsobem pracovat s libovolnou databází, jejíţ výrobce poskytuje tzv. JDBC driver, tedy knihovnu, která implementuje standardní rozhraní a zabezpečuje tak spolupráci s danou databází. Součástí navrhované aplikace musí tedy být JDBC driver pro databázi Oracle.

3.4.6 Databázový server Pouţití JDBC driveru umoţňuje v obecné rovině připojení k libovolnému databázovému stroji.

3.4.7 Klient Na schématu komponent je zřejmé, ţe se jedná o aplikaci běţící na straně klienta, tj. obecný webový prohlíţeč. Jak jiţ bylo zmíněno, z pohledu prezentační vrstvy má aplikace charakter klasického webového rozhraní. Výstupem této vrstvy je tedy sada HTML stránek, které jsou prostřednictvím webového prohlíţeče prezentovány uţivateli. Základními technologiemi, které budou v prezentační vrstvě pouţity, jsou tedy HTML, CSS, JavaScript, AJAX. Pokud jde o serverové technologie pro generování HTML rozhraní, bude pouţita klasická Java kombinace JavaServlets+JSP.

14

Objektově-Relační Mapování – koncept převodu objektových datových struktur (objektů v Javě) na relační datové struktury (záznamy v tabulkách v relační databázi) a naopak, a to do značné míry automatizovaným způsobem.

18

4 ÚVODNÍ STUDIE 4.1 Odborný článek Cílem tohoto projektu je navrhnout systém pro řešení plateb prostřednictvím virtuálních platebních karet, které bude vydávat finanční společnost. Výchozím předpokladem je, ţe klient je jiţ drţitelem kreditní karty (MasterCard Electronic, MasterCard Unembossed nebo Cirrus), ke které bude vydávána karta virtuální15. Důleţitým aspektem při návrhu je rovněţ zohlednění poţadavků ze strany společnosti Mastercard, které musí jednotlivé části systému splňovat. Předpokladem je, ţe finanční společnost poskytne řešiteli všechny relevantní informace nutné pro návrh řešení. Pro provádění plateb v prostředí Internetu potřebuje klient tyto údaje: číslo virtuální karty- jedná se o 16-ti místné číslo, po vygenerování se jiţ nikdy nemění datum ukončení platnosti (expirace) karty a kód CVC2 – zaslat formou sms na mobilní telefon klienta. Tyto údaje jsou unikátní pro kaţdou prováděnou platbu Klient si můţe o virtuální kartu zaţádat prostřednictvím www portálu (dále jen klientská zóna), ke kterému má jiţ vytvořen přístup díky tomu, ţe je drţitelem fyzické karty. Druhou moţností je kontaktovat klientské centrum (dále je call centrum), kde otevření karty provede přímo operátor. Výchozím předpokladem je, ţe klient vlastní mobilní telefon a jeho číslo je jiţ zaregistrováno v informačním systému finanční společnosti. Tím se předpokládá, ţe klient jiţ byl prověřen a je důvěryhodný. Pokud číslo nesouhlasí, tak jediným moţným způsobem

15

Virtuální karta MasterCard vydaná k úvěrovému účtu klienta slouţí pouze pro provádění transakcí na dálku (např. pro platby přes

Internet – e-commerce, telefonické a mailové objednávky – MO/TO a transakce uskutečněné prostřednictvím mobilního telefonu – mcommerce)

19

vytvoření karty je kontaktování call centra společnosti, kde proběhne jeho ověření a případná aktualizace. Po přihlášení do klientské zóny vybere moţnost „Ţádost o virtuální kartu“ a poté vloţí číslo mobilního telefonu a seznámí se s Podmínkami pro pouţívání virtuálních karet. Pokud se číslo mobilního telefonu shoduje, tak systém vygeneruje číslo virtuální karty. Toto číslo bude po celou dobu zobrazené na klientské zóně a karta je okamţitě ve stavu aktivní – klient jí tedy můţe ihned pouţít. Pokud se telefonní číslo neshoduje s jiţ zaregistrovaným, tak klientovi musí být zobrazena informace, aby kontaktoval call centrum. I v tomto případě ale systém virtuální kartu “skrytě“ vygeneruje a nastaví její status do „blokováno“. V aplikaci call centrum jí poté můţe operátor vyhledat a kartu odblokovat. Tím ji uvedenu do aktivního stavu. V případě kontaktování call centra klient sdělí operátorovi navíc i číslo občanského průkazu (běţně sděluje číslo fyzické karty, číslo úvěrového případu, jméno a příjmení). Toto je ochranný mechanismus, resp. jediná dostupná moţnost ověřit existenci klienta. Souhlasí-li tyto údaje, tak ihned aktivuje kartu. Pokud číslo OP nesouhlasí (je lhostejno z jakého důvodu), tak si operátor vyţádá zaslání fotokopie OP s tím, ţe po jejím obdrţení bude klienta kontaktovat. Operátor na call centru musí mít k dispozici tyto operace: -

změna mobilního čísla zablokování virtuální karty odblokování virtuální karty přehled autorizací listování v historii provedených transakcí

Pro provádění vlastních plateb si klient vţdy sám generuje autorizační údaje (expirace karty+CVC2), které jsou unikátní pro kaţdou platbu prováděnou v prostředí internetu. Tyto údaje mají navíc omezenou časovou platnost. Klient se přihlásí do klientské zóny, kde na samostatné obrazovce s názvem „Platba virtuální kartou“ vloţí předpokládanou částku nákupu. Vzhledem k tomu, ţe se předpokládá nákup i cizí měně, tak aplikace musí zajistit automatický přepočet částky

20

nákupu na hodnotu lokální měny (v našem případě na české koruny). Toto je důleţitý moment, protoţe klient můţe chránit svojí platbu nastavením výše částky nákupu. Tato částka musí být poté porovnána s vlastní částkou, kterou autorizační systém obdrţí v online transakci z platební brány, kterou pouţívá internetový obchod. Klient dále pokračuje volbou „Vyţádat si platební údaje“ - ty mu budou zaslány prostřednictvím sms brány16. Klient si můţe vygenerovat nejvíce 5 aktivních autorizačních údajů. Tyto údaje mu musí být zobrazeny včetně moţnosti anulace jedné z nich nebo všech najednou. Klient musí mít obrazovku s přehledem provedených transakcí, ve kterém bude částka nákupu, status poslané sms zprávy, datum a čas provedení této události. Klient musí k dispozici funkci pro zablokování/odblokování karty. Navrhované řešení pro provádění bezpečných plateb z prostředí Internetu bude napojeno na autorizační systém finanční společnosti, který zpracovává on-line autorizace ve formátu ISO 8583 prostřednictvím karetního operátora, který je napojen na společnost Mastercard17

16

Dílčí část informačního systému finanční společnosti Technické řešení není součástí navrhovaného systému, k dispozici je pouze interface pro provádění těchto plateb 17

21

5 ANALÝZA A NÁVRH ŘEŠENÍ 5.1 Zvolený postup pro provedení analýzy pomocí jazyka UML Protoţe jazyk UML není metodika, ale pouze notace zápisu, existuje relativně nekonečné mnoţství způsobů, jak postupovat při samotné analýze. Při návrhu tohoto řešení byl zvolen následující postup činností: 1. Seznámení se s informačním systémem společnosti, studium uţivatelských poţadavků, interview se zadavatelem. Zaloţení úloţiště pro EA model18 2. Vytvoření katalogu uţivatelských poţadavků, validace, kategorizace poţadavků (funkční a nefunkční). 3. Propojení uţivatelských poţadavků (na základě katalogu) s jednotlivými případy uţití 4. Tvorba základního případu uţití (definice aktorů systému a jejich následná validace zadavatelem) 5. Vzorový popis základního případu uţití 6. Návrh uţivatelského rozhraní s vazbou na jednotlivé případy uţití 7. Sekvenční diagramy pro znázornění iterace mezi jednotlivými objekty 8. Tvorba doménového modelu, opět s vazbou na případy uţití 9. Tvorba modelu tříd dle návrhového vzoru MVC ve vazbě na doménový model a uţivatelské rozhraní. Definice atributů a operací tříd ve vazbě na Obrazovky. 10. Tvorba datového modelu v případné vazbě na stávající schémata aplikace. Vazba datového modelu na model tříd 11. Model komponent navrhovaného systému

18

UML modelování je provedeno pomocí nástroje Enterprise Architect 7.5 od firmy Sparx System

22

5.2 Katalog poţadavků Při tvorbě katalogu poţadavků, který byl vytvořen na základě odborného článku, je velice uţitečné znázornit, do které části budovaného informačního systému tyto poţadavky spadají.

req v card_pozadav ky KL.1_Přihlášení do klientské zóny

KL.6_Zobrazení podmínek užívání karty

KL.2_Žádost o otevření karty KL.7_Zobrazení historie transakcí

KL.3_Vytvoření autorizačních údajů pro provední platby na Internetu

KL.8_Klient-blokace karty

KL.4_Zobrazení autorizační údajů v klientské zóně

Klientská zóna (from Pripady uziti)

KL.5_Zrušení autorizačních údajů

CC.1_Transakce v rámci call centra

CC.2_Otevření karty po ověření identity klienta

CC.3_-zobrazení údajů o klientovi

Call Centrum (from Pripady uziti)

IS.3_SMS brána IS.1_Aplikační logika pro provádění transakcí

IS.2_Autorizační systém pro online transakce Informační systém (from Pripady uziti)

Obrázek č. 3 - Přehled uţivatelských poţadavků

23

CC.1_Transakce v rámci call centra Funkce pro operátora CC: - změna mobilního čísla - zablokování virtuální karty - odblokování virtuální karty - přehled autorizací - listování v historii provedených transakcí CC.2_Otevření karty po ověření identity klienta Pokud nesouhlasí číslo mobilního telefonu klienta (které uvedl v poţadavku KL.3 ) tak uloţit nové tel.číslo- po hovoru s klientem- do informačního systému tak, aby na něj byly zasílány autorizační údaje. CC.3_-zobrazení údajů o klientovi rozšířit stávající obrazovku pro operátory CC tak, aby zde byly zobrazeny základní údaje o virtuální kartě KL.1_Přihlášení do klientské zóny v rámci plateb virtuální kartou se vyuţije jiţ existující způsob přihlašování do klientské zóny KL.2_Žádost o otevření karty vloţení čísla mobilního telefonu a jeho porovnání s jiţ existujícím číslem v informačním systému společnosti KL.3_Vytvoření autorizačních údajů pro provedení platby na Internetu Klient vloţí předpokládanou částku nákupu v měně, ve které bude provádět platbu. Na stejné obrazovce mu bude zobrazen ekvivalent v CZK. KL.4_Zobrazení autorizační údajů v klientské zóně Zobrazit přehled údajů za posledních 45 dní Vlastní zobrazení údajů rozdělit do tří částí tak, aby bylo zřejmé, kdy byl autorizační údaj generován, autorizován a zaúčtován Zobrazit stav odesílání sms zprávy Datum a čas provedené operace KL.5_Zrušení autorizačních údajů Na základě zobrazených autorizačních údajů umoţnit: - zrušení kaţdého jednoho údaje separátně - všechny údaje najednou (celkem max. 5) KL.6_Zobrazení podmínek užívání karty Zobrazit text, za jakých podmínek lze kartu pouţít Součástí můţe být i stručný popis pouţití FAQ Zobrazení historie provedených transakcí provést na společné obrazovce s autorizačními údaji Do popisu transakce zobrazit její původ, resp. název obchodního místa kde byla provedena KL.7_Zobrazení historie transakcí Zobrazení historie provedených transakcí provést na společné obrazovce s autorizačními údaji 24

Do popisu transakce zobrazit její původ, resp. název obchodního místa kde byla provedena KL. 8_Klient-blokace karty Klient musí mít moţnost kdykoliv zablokovat virtuální kartu-tato akce ale nesmí ovlivnit kartu fyzickou. Odblokování můţe provést operátor call centra - na základě tel. hovoru s klientem IS.1_Aplikační logika pro provádění transakcí Zřízení virtuální karty (vygenerování čísla karty) Změna čísla mobilního telefonu (pouze z call centra) Zablokování virtuální karty (následně lze odblokovat pouze z call centra) Odblokování virtuální karty (pouze z call centra) Transakce na virtuální kartu (vygenerovaní CVC2 a ExpDat) Zrušení vygenerovaného CVC2 a ExpDat pro konkrétní číslo transakce IS.2_Autorizační systém pro online transakce on-line transakce Mastercard, formát zpráv dle ISO8583 provázání aplikační s logiky pro provádění transakcí s modulem, který zpracovává on-line transakce Mastercard Rozšířit clearingové zpracování o transakce prováděné virtuální kartou IS.3_SMS brána Vyuţít existující SMS bránu finanční společnosti Realizovat rozhraní, které musí umoţnit odesílání SMS zpráv s autorizačními údaji Kurzovní lístek slouţí pro přepočet částky nákup do lokální měny k dispozici je externí tabulka, ve které jsou na denní bázi aktualizovány kurzy dle kurzovního lístku ČNB Základní informace o kartě Příjmení, jméno číslo mobilního telefonu číslo fyzické karty + platnost stav karty Disponibilní částka

Tabulka č. 1 – Katalog poţadavků

25

5.3 Vazba uţivatelských poţadavků na případy uţití V tomto kroku je provedeno provázání jednotlivých uţivatelských poţadavků s případy uţití. Cílem je zajistit, aby ţádný poţadavek nezůstal nerealizován.

req v card_pozadav ky_mapov ani

Základní informace o kartě

KL.1_Přihlášení do klientské zóny

KL.6_Zobrazení podmínek užívání karty

KL.2_Žádost o otevření karty

KL.8_Klient-blokace karty

KL.3_Vytvoření autorizačních údajů pro provední platby na Internetu KL.5_Zrušení autorizačních údajů

KL-Zřízení v irtuální karty

KL-Přihlášení do klientské zóny

(from Pripady uziti)

(from Pripady uziti) CC.1_Transakce v rámci call centra

KL-Prov ádění transakcí KL-Pokyny pro užív ání v irtuální karty (from Pripady uziti) (from Pripady uziti)

KL.4_Zobrazení autorizační údajů v klientské zóně

CC.2_Otevření karty po ověření identity klienta

Kurzovní lístek

CC.3_-zobrazení údajů o klientovi

CC-transakce


KL.7_Zobrazení historie transakcí

CC-zobrazení údaj ů o klientov i


IS-autorizační centrum

IS.1_Aplikační logika pro provádění transakcí IS-aplikační logika pro klientskou zónu

(from Pripady uziti) IS-aplikační logika pro call centrum

(from Pripady uziti) IS.2_Autorizační systém pro online transakce


«extend»

IS.3_SMS brána IS- interface na SMS bránu


Obrázek č. 4 – Vazba uţivatelských poţadavků na případy uţití

26

5.4 Diagram případů uţití Celkový diagram uţití znázorňuje vztah mezi uţivateli systému a jednotlivými případy uţití. Zároveň je provedena dekompozice případů uţití do jednotlivých částí budovaného systému. Při návrhu informačního systému lze případy uţití také vyuţít v následujících oblastech: Tvorbu testovacích scénářů a dokumentace Řízení projektu na základě případů uţití ve vazbě na vhodnou projektovou metodiku19

Obrázek č. 5 - Přehled případů uţití

19

Např. metodika Select Perspective, která se vyuţívá při iterativním vývoji za pomoci případů uţití

27

5.5 Popis případu uţití „IS-aplikační logika pro klientskou zónu“ Vzhledem k tomu, ţe samotný jazyk UML nedefinuje ţádný standard pro popis případu uţití, je velice vhodné provést u klíčových případů uţití co je cílem jejich činnosti, jakou mají vazbu na okolí a co nabídnou uţivateli. Níţe uvedený popis, který je přímo vygenerovaný z nástroje Enterprise Architect, názorně demonstruje vhodnost popisu případu uţití přímo v samotném nástroji. Je zřejmé, ţe k popisu jako takovému se při tvorbě případů uţití budeme několikrát vracet – úměrně s tím, jak bude dokončována analýza celého systému. Type:

UseCase

Name:

Aplikační řešení transakcí z klientské zóny

Status:

Proposed. Version 1.0. Phase 1.0.

Popis UseCase: realizovat transakce z klientské zóny načíst informace o klientovi z informačního systému provázat tyto funkce s autorizačním centrem umět odeslat sms zprávu při určité operaci Popis interakce UseCase s okolím: UC představuje pro uţivatele skryté funkce prováděné na komunikační vrstvě webového serveru a aplikační logiky na úrovni informačního systému Pro správnou činnost je třeba nejdříve implementovat: UC KL_provádění transakcí UC IS_autorizační centrum Další informace a poznámky pro programátora: tbd. Popis Operací v rámci scénáře: Method

Notes zkontrolovat stav fyzické karty: musí být financovatelná a nesmí být

10_vygenerování

čísla zablokována

karty() void

porovnat číslo mobilního telefonu (které uvedl klient) s telefonem uloţeným

Public

v DB informačního systému Algoritmus generování 16-ti místného čísla virtuální karty: Struktura čísla: Bin (6) + Num (9) + Luhn (1) Bin(6) = 531100 Num(9) = předposledních 9 cifer z platného fyzického plastu Luhn(1) = dopočítané Luhnovo kontrolní číslo

28

Method

Notes provádí klient i operátor call centra

12_Zablokování virtuální kartu blokovat pokud klient při platbě na internetu zadá xx-krát chybně za karty() void

sebou autorizační údaje

Public můţe provést pouze operátor call centra 13_Odblokování virtuální karty() void Public CVC2-třímístné číslo, vypočítávané v návaznosti na číslo karty 14_vygenerování

ExpDate-datum platnosti karty vypočítat podle pravidel Mastercard

CV2+Expdat() void

Tyto údaje odeslat na SMS gateway

Public

Autorizační údaje musí mít omezenou časovou platnost Nejvíce můţe být vygenerováno xx nepouţitých údajů provádí klient, můţe zrušit všechny údaje najednou nebo i jednotlivě

15_zrušení vygenerovaných CV2+Expdat() void Public zobrazit transakci ve stavu: 17_Přehled autorizací a -autorizováno platných

platebních -generováno

údajů() void

-zaúčtováno

Public

u kaţdého údaje zobrazit datum+čas

Tabulka č. 2 – Popis případu uţití „Aplikační řešení transakcí z klientské zóny“

29

5.6 Návrh uţivatelského rozhraní V této fázi návrhu se jeví jako uţitečné provedení návrhu hlavních obrazovek systému jako dobrý předpoklad jak ke tvorbě doménového, tak později datového modelu. Další výhodou můţe být průběţná komunikace se zadavatelem, který jiţ v rané fázi návrhu systému dostává konkrétní představu o rozhraní, se kterým bude pracovat.

Obrázek č. 6 – Návrh uţivatelského rozhraní

30

Důleţitým krokem je provázání jednotlivých obrazovek jak s případy uţití, tak jednotlivými třídami. Toto je realizováno v iteracích tak, jak postupně dochází k vývoji systému. Detaily obrazovek jsou pro lepší přehlednost uvedeny v příloze č. 1.

5.7 Sekvenční diagramy V následující kapitole je uveden přehled hlavních sekvenčních diagramů, které znázorňují interakci mezi jednotlivými objekty. Opět jsou vyuţity případy uţití, pro které nyní hledáme realizaci a znázorňujeme jejich spolupráci z hlediska času. Při práci na projektu podobného rozsahu není prakticky moţné kreslit diagramy pro všechny případy uţití, proto je nutné vybrat pouze ty nejvíce přínosné a ostatní sjednotit do skupin reprezentující podobné vzory řešení.

5.7.1 Scénář otevření virtuální karty Krok

Role

Akce

1

Klient

přihlásí se do klientské zóny

2

KL-login

aplikace autorizuje klienta, zobrazí aktuální stav virtuální karty

3

KL-vcreate

vytvoří poţadavek na otevření karty formou vstupní transakce do IS

4

IS-apl_cl

zpracuje poţadavek a vygeneruje číslo karty

5

KL-vcreate

Přijímá odpověď a generuje stránku s informacemi

6

KL-login

Zobrazuje informace o vytvoření virtuální karty

7

Klient

Přijímá informaci o vytvoření a dalších moţnostech pouţití karty

8

Klient

Ihned přechází do generování platebních údajů

sd Scénář otev ření karty-tel OK KL-Přihlášení do klientské zóny

KL-Vytvoření virtuální karty

IS-aplikač ní logika pro klientskou zónu

KL-Provádění transakcí





Klient

přihlašuje se()

Požaduje vytvoření karty() akce vytvoř požadavek na novou kartu() OK Vrácení č ísla karty() OK-telefon se shoduje()

Klient informován()

ihned může generovat transakce()

(from Actori)

Obrázek č. 7 – Scénář otevření virtuální karty

31

Generuj č íslo karty()

5.7.2 Scénář změny čísla mobilního telefonu Krok

Role

Akce

1

Operátor

přijímá hovor/poţadavek od klienta na změnu čísla mobilního telefonu, ověřuje jeho identitu a zobrazuje si jeho základní údaje

2

CC-view

zadává nové číslo telefonu

3

CC-trans

vytvoří poţadavek na změnu telefonu formou vstupní transakce do IS

4

IS-apl_call

Zpracuje poţadavek, formálně kontroluje správnost údaje, vrací odpověď

5

CC-trans

Přijímá odpověď a zobrazuje číslo nového telefonu, který operátor přečte klientovi

6

CC-view

Operátor změní stav karty z „blokována“ na „k pouţití“

7

CC-trans

vytvoří poţadavek na změnu telefonu formou vstupní transakce do IS

8

IS-apl_call

Zpracuje poţadavek, zkontroluje podmínky, za kterých lze kartu odblokovat, vrací odpověď

9

CC-trans

Přijímá odpověď a zobrazuje stav karty

10

CC-view

Operátor na základě zobrazených informuje klienta o provedení změny

sd Scénář změna tel.čísla-CC CC-zobrazení údajů o klientovi

CC-transakce

IS-aplikační logika pro call centrum




Operátor

ověřuje klienta() mění číslo telefonu() akce změň číslo mobilu()

akce změň provedena()

přijímá odpověď() odblokuje kartu() akce odblokuj kartu() akce odblok provedena() zobrazení údajů() přečtě všechny klíčové údaje()

(from Actori)

Obrázek č. 8 – Scénář změny čísla mobilního telefonu

32

5.7.3 Scénář provedení transakce pro ověření platby Krok

Role

Akce

1

Klient

přihlásí se do klientské zóny

2

KL-login

aplikace autorizuje klienta a předá poţadavek na platební údaje

3

KL-vtrans

vytvoří poţadavek na otevření karty formou vstupní transakce do IS

4

IS-apl_cl

Interně generuje platební údaje CVC2 a update a čeká na příjem platby z obchodního místa

5

IS-auth

z autorizačního centra přichází transakce

6

IS-apl_cl

Spáruje platební údaje vygenerované klientem s údaji z transakce

7

KL-vtrans

Zobrazí informace o provedené transakci klientovi

8

Klient

Klient informaci pouţije při dalším postupu platby v obchodním místě

sd Scénář prov edení transakce KL-Přihlášení do klientské zóny

KL-Provádění transakcí

IS-aplikační logika pro klientskou zónu

IS-autorizační centrum





Klient

přihlašuje se() generuje si platební údaje() akce genereruj plat.údaje() čeká se na platbu z obchodu()

Předání odpovědi()

přijímá výsledek transakce()

zobraz stav transakce v přehledu()

(from Actori)

Obrázek č. 9 – Scénář provedení transakce pro ověření platby

33

přichází transakce z platební brány()

5.8 Doménový model Při tvorbě doménového modulu je vyţadována vysoká míra abstrakce od řešitele. Doménový model, který je navrţen v této fázi, slouţí později k vazbě na komponenty typu „model“ pouţité v architektuře MVC20.

5.8.1 Základní doménový model

Obrázek č.10 – Základní doménový model

20

Model-view-controller je softwarová architektura, která rozděluje datový model aplikace, uţivatelské rozhraní a řídicí logiku do tří nezávislých komponent tak, ţe modifikace některé z nich má minimální vliv na ostatní.

34

5.8.2 Vazba doménového modelu na případy uţití Aby bylo zajištěno, ţe kaţdý případ uţití je realizován pomocí třídy, je v této fázi návrhu nutné provést vazbu mezi doménovým modelem a jednotlivými případy uţití. Během dalšího návrhu systému se řešitel v několika iteracích vrací zpět k jednotlivým případům uţití a stále doplňuje nebo upravuje vazby na diagramy tříd.

Obrázek č.11 – Vazba doménového modelu na případy uţití

35

5.9 Diagram tříd Při návrhu diagramu tříd bylo vyuţito návrhového vzoru MVC (Model-view-controller), který se v současné době patří mezi nejpouţívanější vzory pro architekturu webových aplikací.

Obrázek č.12 – Vazba doménového modelu na případy uţití

36

5.10 Datový model Navrţený logický datový model znázorňuje strukturu relační databáze a její mapování na konsolidovaný diagram tříd.

Obrázek č. 13 – Datový model aplikace

37

5.11 Diagram komponent V rámci popisu diagramu komponent je také uveden stručný popis jednotlivých částí. Tento popis je velice uţitečný při samotné realizaci systému.

Obrázek č. 14 – Diagram komponent

Při návrhu systému byl kladen důraz na dodrţení principu třívrstvé architektury (datová, aplikační, prezentační), která musí korespondovat s návrhem tříd. Ten vycházel z návrhového vzoru MVC (Model-view-controller). Při porovnání těchto způsobů je nutné si uvědomit, co jednotlivé komponenty znamenají. Model je obvykle reprezentován entity beans, v našem případě frameworkem Spring. View je v aplikacích na platformě Java EE reprezentován JavaServerPages, nejčastěji při vyuţití technologie JSF. Controller je reprezentován servletem, pro jehoţ realizaci mohou být opět pouţity JSP. 38

6 REALIZACE Aplikace informačního systému pro virtuální kartu bude realizována s vyuţitím následujících technologií: Aplikační vrstva: Bude realizována na platformě Java EE5, jako webový kontejner bude zvolena implementace Apache Tomcat v. 5.521. Programovacím jazykem bude Java 5. Pouţité aplikační rámce: Spring – Aplikační rámec, který je v aplikaci pouţit pro správu aplikační (business, servisní) vrstvy. Skládá se z jednotlivých modulů, které mají na starost vţdy určitou omezenou funkcionalitu. Hibernate – ORM (objektově-relačně-mapovací) nástroj, pouţívá se pro převod databázových záznamů na Java objekty a naopak.

Databázová vrstva: Datové úloţiště aplikace bude tvořeno systémem Oracle Database 10g Enterprise Edition Prezentační vrstva: Vzhledem k tomu, ţe aplikace má webový charakter, tak pro její ovládání můţe být teoreticky pouţit libovolný internetový prohlíţeč. Pro korektní běh aplikace bude doporučován Microsoft Internet Explorer verze 8.0 nebo Mozilla Firefox verze 3.6

Obrázek č. 15 – Realizace systému 21

Tento kontejner je referenční implementací základních webových Java (JEE) technologií – JSP a JavaServlet.

39

7 TESTOVÁNÍ 7.1 Pojem testování Při návrhu informačního systému je nutné jiţ v jednotlivých vývojových fázích učinit nutné kroky pro správné fungování budoucích částí aplikace tak, aby bylo dosaţeno poţadované spolehlivosti celkového řešení. Jedním z těchto kroků je testování, které lze chápat jako provádění funkcí programu, jejímiţ výsledky se porovnávají s očekávanými. Z pohledu zajištění kvality je nutné vytvořit předpoklady pro odstranění chyb, které mohou být nalezeny v průběhu testování. Jednotlivé fáze jsou v tomto kontextu uspořádána následovně:

Obrázek č. 1 – Uţití testu Zdroj: http://home.zcu.cz/~kopecek/DBCsyl/sylaby/Spolehlivost.doc

7.2 Testování v rámci vývojové fáze Při testování v rámci vývojové fáze, která se zpravidla rozděluje na části Alfa a Beta, se provádí zejména jednotkové, funkční a simulační uţivatelské testy. Vzhledem k tomu, ţe v této fázi dochází ke změně funkcionalit, je důleţité téţ provádět regresní testování. Pro tento typ testů se pouţívají tzv. Black Box a White Box metody. V prvém případě je správná funkčnost aplikace kontrolována z vnějšího pohledu bez znalostí o vnitřním 40

uspořádání aplikace. Ve druhém případě se vyuţívá znalostí o vnitřní logice programů a celkovém uspořádání modulů. Zároveň je vytvořena dokumentace, kde výchozím zdrojem jsou jednotlivé případy uţití, ve kterých je jiţ proveden popis funkcionality na základě poţadavků zadavatele.

7.3 Testování v rámci fáze předávání do provozu V rámci fáze předávání do provozu, někdy téţ nazývané implementačním testováním, se rozumí tři hlavní oblasti: Hardwarové prostředí Softwarové a middleware prostředí Dokumentace k informačnímu systému (projektu) Proces implementačního testování, jehoţ účelem je potvrzení, ţe dodávané řešení odpovídá poţadavkům specifikovaným na začátku celého projektu, se dělí do několika fází: Fáze technických testů: Připravenost infrastruktury (OAT, Operational Acceptance Test) Ověření systému na cílové infrastruktuře (TAT, Technical Acceptance Test) Zátěţové testy (PT,Performance Test) Bezpečnostní testy (PET,Penetration Test) Fáze uţivatelských testů: Uţivatelský test (UAT,User Acceptance Test) Celkové testy funkce systému (E2E, End To End Test) Jedním z předpokladů úspěšného implementačního testování je téţ určení odpovědných rolí (osob) za průběh celého procesu jak za strany dodavatele (project test manager, acceptation test team leader), tak zákazníka (senior business user). Celý proces musí být zaštítěn osobou projektového manaţera, který je zodpovědný za dodávku kompletního systému.

41

7.3.1 User Acceptance Test (UAT) Jedním z nejznámějších a velmi často pouţívaných testů je UAT. Cílem je ověřit, ţe všechny poţadavky tak jak byly popsány v zadávací dokumentaci, jsou řádně realizovány a implementovány. Pro tuto fázi jsou nutné vstupy v podobě dokumentů (detailní specifikace, test scénáře), řádně nakonfigurovaného prostředí včetně propojení na okolní systémy a sadou testovacích dat. Výstupem je pak UAT report a issue&risk log22. Samotné provedení testu se provádí v návazných krocích: plánování, provádění a vyhodnocení UAT.

7.3.2 UAT - Platba virtuální kartou Jako příklad UAT je zde uveden krok platby virtuální kartou, který bude proveden následovně: Pro funkčnost „Platba virtuální kartou“ bude stanoven jednokolový test. Scénář tohoto testu bude vytvořen na základě případu uţití „Platba virtuální kartou“ a scénáře „Provedení transakce pro ověření platby“. Vlastní test bude rozdělen do oblastí: Přihlášení do klientské zóny Generování autorizačních údajů Platba z obchodu Zobrazení údajů v přehledu transakcí Ty budou dále členěny do jednotlivých kroků, kde musí být téţ popsán očekávaný výsledek včetně výsledného stavu. To umoţní vytvoření přehledů, na základě kterých lze stanovit akceptační kriteria pro jednotlivé UAT. V příloze č. 2 je popsán návrh tohoto testu ve větším detailu.

22

Anglický název nejlépe vystihuje stav, kdy byly nalezeny chyby, které mohou vést k opakování testů

42

8 BEZPEČNOST NAVRHOVANÉHO ŘEŠENÍ 8.1 Bezpečnost při návrhu informačního systému V průběhu návrhu informačního systému je nutné věnovat zvýšenou pozornost bezpečnostním aspektům navrhovaného řešení. V případě systému, který má zajišťovat bezpečné platby v prostředí Internetu a zároveň zpracovávat klientská data, to platí dvojnásobně. V první řadě je potřeba vytvořit přehled oblastí, které mohou být potencionálně rizikové. Dále je nutné zváţit, co a do jaké míry je těmito riziky ohroţeno a na základě těchto skutečností stanovit pravidla pro zajištění bezpečnosti informačního systému. Těmito pravidly se rozumí zejména oblasti, které jiţ ve fázi návrhu musí být navrţena tak, aby reflektovala vybrané zásady stanovené jak normami, tak obecnými doporučeními. Těmito doporučeními či zásadami se zejména rozumí: Sledování vývoje politiky bezpečnostních opatření Řízení změn a konfigurace navrhovaného systému Definice uţivatelských rolí a přístupových práv Poţadavky kladené na budoucí bezpečnostní audit Monitorování dostupnosti aplikace Nelze téţ opominout lidský faktor, tj. je nutné neupřednostňovat pouze aspekty technického zabezpečení proti útokům zvenčí, ale myslet i na skutečnost, ţe se systému budou pracovat lidé uvnitř společnosti. V rámci ţivotního cyklu informačního systému, jehoţ z jednou částí je také uplatňování organizačních pravidel pro práci se systémem, můţeme téţ na pohled systém řízení bezpečnosti rozdělit na dvě části: 1. Informovanost zaměstnanců v oblasti bezpečnosti informačních systémů – zejména práce s přístupovými jmény a hesly 2. Vhodná technická opatření – navrţení rolí a přístupových práv do systému podle skutečných potřeb a stupně důleţitosti zpracovávaných dat.

43

Pokud má společnost jiţ vypracovány zásady bezpečnostní politiky, tak lze z pohledu bezpečnosti získat komplexní pohled na organizaci jako takovou. Tento pohled si můţeme rozdělit na následující oblasti: Logická bezpečnost Fyzická bezpečnost Personální bezpečnost Bezpečnost ICT Vazba bezpečnosti na legislativu Velice vhodným výchozím bodem je téţ znalost standardů v oblasti bezpečnosti informací. Pro námi navrhovaný systém jsou to zejména: Mezinárodní standardy: ISO/IEC 2700123, ISO/IEC 2700224, ISO/IEC 2700525 Standardy pro posuzování bezpečnostních vlastností jednotlivých komponent informačního systému: zejména ISO/IEC 1540826 nebo standard ITSEC27

8.2 Návrh bezpečného řešení pro provádění plateb Na základě osvojení si znalostí v oblasti bezpečnosti, které byly popsány v předchozí kapitole, je nutné se při návrhu informačního systému zaměřit zejména na tyto části: Autentizace Autorizace Systém logování Auditní informace Autorizace v aplikační vrstvě V následující části jsou popsány základní kroky ve výše uvedených oblastech. Konkrétní řešení je do značné míry závislé na technologii, která je zvolena pro realizaci systému.

23

Information Security Management System, nahrazuje normu BS 7799-2 Code of Practice for Information Security Management, nahrazuje ISO/IEC 17799:2005 25 Information Security Risk Management, dříve ISO/IEC 13335 26 Standard je známý téţ pod názvem Common Criteria 27 Information Technology Security Evaluation Criteria 24

44

8.2.1 Bezpečnostní rámec Acegi Security Vzhledem k tomu, ţe pro aplikační vrstvu byl zvolen při návrhu systému aplikační rámec Spring, tak autentizace i autorizace uţivatelů bude realizována s vyuţitím bezpečnostního rámce (frameworku) Acegi Security28.

8.2.2 Autentizace V rámci autentizace se ověřuje, zda-li je uţivatel nebo entita opravdu ten, za koho se vydává. V aplikaci bude toto ověření realizováno na základě předloţení uţivatelského jména a hesla prostřednictvím přihlašovacího HTML formuláře. Uţivatelská hesla budou uloţena v databázi ve formě SHA1 heše. Pokud uţivatel zadá do formuláře své heslo, tak jej aplikace převede prostřednitvím SHA1 algoritmu29 do odlišného řetězce a tento porovná s hešem, který je pro dané uţivatelské jméno uloţen v databázi. Toto je z bezpečnostního pohledu důleţité, protoţe pokud by se potencionální útočík zmocnil hešů které jsou uloţení v databázi, tak z nich není schopen odvodit původní heslo a do aplikace se přihlásit. Integrace Acegi autentizace bude do aplikace realizována prostřednictvím klasického JavaServlets filtru. Kaţdý http poţadavek, který je na aplikaci směřován, bude prostřednictvím tohoto filtru prověřen. Pokud nebudu uţivatel autentizován, tak mu bude nabídnut přihlašovací formulář. V opačném případě bude poţadavek předán dále aplikaci.

8.2.3 Autorizace Autorizace představuje proces ověření, zda přihlášený (autentizovaný) uţivatel je oprávněn pouţívat určité části aplikace, popř. informace v ní uloţené. Autorizace bude a aplikaci zajišťována prostřednictvím přidělených uţivatelských rolí jednotlivým uţivatelům. Uţivatelským rolím jsou pak přidělena různá bezpečností oprávnění. V rámci návrhu systému byly identifikovány tyto role: Administrátor Správce dat Klient-externí Operátor-interní

28 Aplikační rámec, který

poskytuje aplikaci komplexní autentizační a autorizační sluţby jak

prezentační, tak aplikační vrstvě. Detailní popis je dostupný na http://www.acegisecurity.org 29

Popis algoritmu je obecně znám, např. http://www.faqs.org/rfcs/rfc3174.html

45

na

8.2.4 Systém logování Součástí navrhované aplikace bude také funkcionalita logování. Jde o debugovací výpisy, které aplikace bude produkovat během svého běhu. Tyto výpisy budou jednak směřovány do vývojového prostředí určeného programátorů (zejména pro usnadnění vývoje), tak do logovacích souborů. Toto je důleţité zejména pro zpětné sledování běhu aplikace a odhalení případného místa chyby.

8.2.5 Auditní informace Nedílnou součástí aplikace bude proces sledování a uchovávání informací o akcích, které uţivatelé v aplikaci provádějí a které mění stav systému. V databázi budou tyto informace uloţeny v separátní tabulce ve formě uţivatel/akce. Akce bude uchovávána jako název servisního objektu30, jeho metody a parametry, které byly pouţity při volání. Tato funkcionalita bude realizována na úrovni servisní vrstvy prostřednictvím AOP přístupu

8.2.6 Autorizace v aplikační vrstvě Autorizace v aplikační vrstvě je jednou úrovní, na kterých musí být aplikace zabezpečena. Přístup uţivatelských rolí k jednotlivým metodám aplikace lze definovat v servisních objektech pomocí anotace @secured. Jde o standardní JSE 1.5 anotaci definovanou bezpečnostním rámcem Acegi Security. Pokud není u metody servisního objektu tato anotace uvedena, pak není autorizace vůbec aplikována.

30

Servisní objekt lze chápat jako skupinu metod, které provádí obsahově podobné funkce, např. administraci, auditing nebo konkrétní aplikační záleţitosti

46

ZÁVĚRY A DOPORUČENÍ Cílem této práce bylo navrhnout systém pro provádění bezpečných plateb v prostředí Internetu tak, aby byl bez problémů implementovatelný do informačního systému finanční společnosti, která si vytvoření takového systému zadala. Přestoţe nebylo moţné v rámci rozsahu této práce popsat návrh a analýzu takového systému do kaţdého detailu, tak jsem se snaţil popsat důleţité momenty ţivotního cyklu při vzniku programového díla. V průběhu celého návrhu, který by se dal rozdělit zhruba do tří etap, jsem dospěl k následujícím zjištěním: 1. Etapa výběru vhodného řešení: Ukázalo se, ţe je zcela nezbytné se seznámit s různými způsoby plateb v prostředí Internetu a těchto znalostí později vyuţít při návrhu systému. Z pohledu analytika informačních systémů, která takový systém se zákazníkem navrhuje, se jedná zcela jednoznačně o výhodu. 2. Etapa způsobu provedení návrhu a analýzy: Po vypracování úvodní studie a katalogu poţadavků, které v zásadě jiţ dají představu o rozsahu systému, je klíčovým momentem zvolení vhodného modelovacího jazyka pro provedení analýzy. V tomto ohledu se jazyk UML 2.0 více neţ osvědčil. Jednou z důleţitých částí analýzy byla tvorba a popis případů uţití, ke kterým jsem se v průběhu návrhu několikrát vracel. Lze konstatovat, ţe např. oblast uţivatelských testů je celá zaloţena na případech uţití. 3. Etapa realizace, testování, bezpečnosti: Jiţ v průběhu analýzy, zejména ve fázi tvorby doménového modelu a modelu tříd, si jiţ bylo nutné osvojit základní znalosti v oblasti architektur aplikací s vyuţitím návrhových vzorů, JAVA technologií a bezpečnostních aspektů při návrhu aplikace v prostředí platebních karet. Navrţený datový model aplikace byl jiţ vyzkoušen v databázovém prostředí a fungoval bez problémů. Dá se předpokládat, ţe s vývojem platebních metod v prostředí Internetu bude nutné takto navrţený systém dále rozšiřovat. Proto byl v průběhu návrhu kladen důraz na jeho otevřenost a rozšiřitelnost, coţ se díky návrhu za pomoci UML podařilo.

47

SEZNAM POUŢITÉ LITERATURY [1] KANISOVÁ Hana;MULLER Miroslav. UML srozumitelně. 2.aktualizované vydání. Brno: Computer Press,2007. ISBN 80-251-1083-4. [2] PECINOVSKÝ Rudolf. Návrhové vzory-33 vzorových postupů pro objektové programování.Brno:Computer Press, 2007. ISBN 978-80-251-1582-4. [3] POKORNÝ Jaroslav. Databázové systémy a jejich použití v informačních systémech. Praha: Academia, 1992.ISBN 80-200-0177-8. [4] Unified Modeling Language In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, , [cit. 2010-01-26]. Dostupné z WWW: . [5]Objekty-Objektová analýza, návrh a programování [online]. 2008 [cit. 2010-02-25]. Návrhové vzory(Design Patterns). Dostupné z WWW.. [6] RAC-Nová řada ISO/IEC 27000 [online]. 2009 [cit. 2010-03-20]. Dostupné z WWW: . [7] KOPEČEK, P.; TOMÁŠEK, J. ZČU, Ověřování spolehlivosti softwaru [online]. 1997 [cit. 2010-04-26]. Katedra průmyslového inženýrství a managementu. Dostupné z WWW: . [8] PETRO, Lukáš. ICTM 2009: Řízení informačních a komunikačních technologií. Praha : ČVÚT, 2009. Testování jako předpoklad úspěšné implementace, s. 34-42. [9] Java EE at a Glance [online].2010 [cit. 2010-04-01]. Dostupné z WWW: .

48

SEZNAM PŘÍLOH Příloha č. 1 – Obrazovky uţivatelského rozhraní Příloha č. 2 – Uţivatelské testy

SEZNAM OBRÁZKŮ Obrázek č. 1 – Unified Modeling Language Obrázek č. 2 – Návrhový vzor Observer Obrázek č. 3 – Přehled uţivatelských poţadavků Obrázek č. 4 – Vazba uţivatelských poţadavků na případy uţití Obrázek č. 5 – Přehled případů uţití 1 Obrázek č. 6 – Návrh uţivatelského rozhraní Obrázek č. 7 – Scénář otevření virtuální karty Obrázek č. 8 – Scénář změny čísla mobilního telefonu Obrázek č. 9 – Scénář provedení transakce pro ověření platby Obrázek č. 10 – Základní doménový model Obrázek č. 12 – Vazba doménového modelu na případy uţití Obrázek č. 13 – Datový model aplikace Obrázek č. 14 – Diagram komponent Obrázek č. 15 – Realizace systému Obrázek č. 16 – Uţití testu

SEZNAM TABULEK Tabulka č.1 – Katalog poţadavků Tabulka č.2 – Popis případu uţití „Aplikační řešení transakcí z klientské zóny“

49

Příloha č. 1

Obrazovky uţivatelského rozhraní

50

Příloha č. 1


51

Příloha č. 1


52

Příloha č. 2

Uţivatelské testy UAT Platba virtuální kartou: stanovení oblastí testů

Testovací kolo 1 Zodpovědná osoba dne

Číslo Název

1. 2. 3. 4.

Přihlášení do klientské zóny Generování autorizačních údajů Platba z obchodu Zobrazení údajů v přehledu transakcí

D.Novák D.Novák D.Novák D.Novák

UAT Platba virtuální kartou: vyhodnocení testu

Kolo 1 9 2 2

Vyhověl Nevyhověl Nelze otestovat

Kolo 1 2; 15%

Vyhověl 2; 16%

Nevyhověl Nelze otestovat 9; 69%

53

2.1.2010 2.1.2010 2.1.2010 2.1.2010

výsledek

Příloha č. 2

Uţivatelské testy Obl ast Krok 1.

2.

Akce

1.1. Vložit uživatelské jméno a heslo Přejít v rámci hlavního menu portálu na 1.2. obrazovku "Platba virt. kartou" Zkontrolovat naplnění pole s číslem virtuální 2.1. karty Zkontrolovat naplnění pole "expiration date" a 2.2. "CVC2" 2.3. Vložit hodnotu do pole "částka nákupu" Vybrat hodnotu z předdefinovaného číselníku 2.4. měn

Data

CZK

4.

3.1. Spustit skript "simul_platba" Přejít v rámci hlavního menu portálu na 4.1. obrazovku "Zobrazení autorizačních údajů" 4.2. Zkontrolovat pole Generované údaje 4.3. Zkontrolovat pole Autorizováno

Vyhověl

Vyhověl

Otevření formuláře pro generování údajů

Vyhověl

Nevyhověl

Vyhověl

Nelze otestovat

zobrazeno "bude zasláno sms zprávou" 100 hodnota odpovídá údaji z pole data

Vyhověl Vyhověl

hodnota odpovídá údaji z pole data

Nelze otestovat

100 hodnota odpovídá údaji z pole data Uzavření formuláře zobrazeno "bude zasláno sms zprávou" simulace

Kolo 1

Korektní přihlášení

531311230001 hodnota odpovídá údaji z pole data

2.5. Zkontrolovat naplnění pole "hodnota v CZK Stisknutím tlačítka "Vyžádat si.." uzavřít 2.6. formulář 2.7. Ověřit statický text 3.

Očekávaný výsledek

return code musí být 0, hodnota autorizováno 100

Otevření formuláře s přehledem transakcí 100 shoda s krokem 2.5. 100 shoda s krokem 3.1.

54

Vyhověl Vyhověl Nelze otestovat Nevyhověl

Vyhověl Vyhověl Nevyhověl

Oficiální zadání bakalářské, resp. diplomové práce (vyplněný originál obdržíte na studijním oddělení)

55

Návrh systému pro bezpečné platby v prostředí Internetu

Recommend Documents