Systém pro správu bankovních účtů. Dominik Mervart

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Systém pro správu bankovních účtů Dominik Mervart Vedoucí práce: Ing. Jiří Chludil Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 8. června 2009

2 iv

3 v Poděkování Děkuji panu Ing. Jiřímu Chludilovi za vedení mé bakalářské práce. Dále bych chtěl poděkovat své rodině a přítelkyni Lídě za podporu a trpělivost. Děkuji také panu Lukovi Skywalkerovi za inspiraci a morální podporu.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract This bachelor thesis deals with analysis, design and implementation of the system for bank account management. This system provides effective management of statements and transactions, their import, export, filtering and searching. The objective of this thesis is to remove some of the shortcomings of internet banking systems in the field of passive account operations. Considering the data sensitivity, the security measures are taken into account in the design and implementation phases. In the first part of the thesis is an introduction to the history and principles of electronic banking. The second part describes features and requirements laid on the system. The third part deals with analysis and design of the system. The fourth part attends to its implementation and testing. Abstrakt Tato bakalářská práce se zabývá analýzou, návrhem a implementací systému pro správu bankovních účtů. Tento systém umožňuje efektivní správu výpisů a transakcí, jejich import, export, filtrování a prohledávání. Cílem této práce je odstranit některé nedostatky internetových bankovnictví v oblasti pasivních operací s účtem. Při návrhu a implementaci je vzhledem k citlivosti těchto dat dbáno na zabezpečení aplikace. V první části je uvedena historie a principy elektronického bankovnictví. Druhá část popisuje vlastnosti a požadavky kladené na systém. Třetí část se zabývá analýzou a návrhem systému. Čtvrtá část se věnuje jeho implementaci a testování. ix

8 x

9 Obsah 1 Úvod 1 2 Popis problému, cíle a požadavky Elektronické bankovnictví Bankovní operace Historie e-bankingu Formy elektronického bankovnictví Platební karty Telefonní bankovnictví (telebanking, phone banking) Home banking Internetové bankovnictví (internet banking) České banky a jejich elektronické služby Souhrn údajů o 9 největších českých bankách za rok Žebříček českých bank podle velikosti Popis systému a cíle bakalářské práce Co bude aplikace umožňovat Výhody oproti online systémům internetového bankovnictví Nevýhody oproti online systémům internetového bankovnictví Požadavky na systém Cíl bakalářské práce Struktura bakalářské práce Existující implementace obdobného systému Aconto Free DSMan POHODA 2009 START Další programy Zhodnocení existujících aplikací obdobného typu Analýza a návrh řešení Formáty bankovních výpisů Česká Spořitelna Komerční banka Československá obchodní banka mbank Důležitá informační pole společná pro všechny banky xi

10 xii OBSAH 3.2 Automatické stahování výpisů Programové ovládání prvků webové stránky Bezpečnostní riziko Výsledek rešerše o automatickém stahování výpisů Výběr technologií pro implementaci Výběr typu aplikace Výběr programovacího jazyka Výběr datového úložiště Zabezpečení uživatelských dat Bezpečnost databázových dat Oddělený přístup uživatelů do aplikace pomocí autentizace Softwarový návrh aplikace Katalog požadavků Uživatelé a jejich práva Diagramy aktivit Diagram komponent aplikace Návrh relační databáze Implementace GUI - grafické uživatelské rozhraní Struktura aplikace Ukládání dat do databáze Ukládání nastavení programu do databáze a XML Logování varování a chyb Import výpisů Verzování zdrojového kódu Dokumentace zdrojového kódu Testování Průběh a výsledky testování prototypu Závěr 43 Literatura 45 A Seznam použitých zkratek 47 B Slovník 49 C Formáty bankovních výpisů 51 C.1 Česká spořitelna C.2 Komerční banka C.3 Československá obchodní banka C.4 mbank

11 OBSAH xiii D UML diagramy 61 D.1 Vybrané diagramy aktivit D.2 Schéma relační databáze D.2.1 Systémová databáze D.2.2 Uživatelská databáze E Grafické uživatelské rozhraní 67 F Uživatelská příručka 71 G Obsah přiloženého CD 79

12 xiv OBSAH

13 Seznam obrázků 2.1 Co se klientům líbí na přímém bankovnictví Průzkum používanosti produktů přímého bankovnictví v ČR v roce Jednotlivci starší 16 let používající v ČR vybrané informační technologie Pohled na formulář pro import bankovních výpisů v programu Aconto Free Program DSMan s načtenými výpisy z GPC souboru Komerční banky Program Pohoda s načtenými výpisy z účtu Komerční banky Diagram komponent C.1 Vzorový datový výpis České spořitelny C.2 Vzorový výpis transakční historie České spořitelny C.3 Hierarchická struktura formátu KB Best C.4 Formát KB Best - hlavička (HO) a patička (TO) C.5 Formát KB Best - obratová věta 51 (obecné údaje výpisu) C.6 Formát KB Best - transakční věta 52 nebo 53 (transakce) C.7 Vzorový výpis KB Best Komerční banky C.8 Vzorový výpis transakční historie ČSOB C.9 Vzorový výpis transakční historie mbank D.1 Diagram aktivit - Přihlášení uživatele D.2 Diagram aktivit - Spuštění aplikace D.3 Diagram aktivit - Vytvoření uživatele D.4 Diagram aktivit - Import výpisů D.5 Diagram aktivit - Filtrování výpisů D.6 Schéma systémové databáze D.7 Schéma uživatelské databáze E.1 Přihlášení do aplikace E.2 Přehled účtů se zobrazeným oknem úprava účtu E.3 Přehled načtených výpisů a transakcí E.4 Filtrování výpisů E.5 Přehled typů transakcí se zobrazeným oknem úprava typu transakce E.6 Import výpisů xv

14 xvi SEZNAM OBRÁZKŮ

15 Seznam tabulek 2.1 Počty uživatelů přímého bankovnictví v ČR v letech 1999/ Údaje o Citibank, Commerzbank AG a České spořitelně za rok Údaje o ČSOB, GE Money Bank a Komerční bance za rok Údaje o mbank, Raiffeisenbank a UniCredit Bank za rok Žebříček českých bank podle velikosti Obecná informační pole výpisu Obecná informační pole transakcí C.1 Datový výpis České spořitelny - údaje o celém výpisu C.2 Datový výpis České spořitelny - transakce C.3 Výpis transakční historie České spořitelny C.4 Formát transakční historie ČSOB C.5 Formát transakční historie mbank - údaje o celém výpisu C.6 Formát transakční historie mbank - transakce xvii

16 xviii SEZNAM TABULEK

17 Kapitola 1 Úvod Nástup éry osobních počítačů a internetu poznamenal život člověka v mnoha směrech. Umožnil rychlý přístup k informacím, zábavě a poskytl pro mnoho lidí nástroj obživy. Dopad počítačů nebyl ale znát jen v oblasti pracovní, vzdělávací a zábavní, mnoha lidem doslova revolučně změnil jejich všednodenní život. Hlavně internet umožnil nejen pasivní příjem informací, ale také aktivní komunikaci a komunikace je to, co pohání celý dnešní svět. Činnosti jako odeslání dopisu na poště, zaplacení faktury či složenky v bance, objednání a zakoupení zboží v obchodě, komunikace s úřady, ty všechny a jiné už v posledních letech nepředstavují osobní návštěvu příslušné instituce a z toho často plynoucí ztrátu drahocenného času nebo zaplacení nemalých poplatků za vyřízení. Internet umožnil realizování těchto činností elektronickou podobou z pohodlí domova či zaměstnání a poskytl tak způsob jak ušetřit čas na straně klienta a jak snížit náklady, zrychlit vyřízení a poskytnout výhodnější cenové podmínky klientům na straně firem a úřadů. Jedná se ve své podstatě o další stádium evoluce v mezilidské komunikaci, jakých lidská populace za své existence zažila už několik. Toto stádium ale je výjimečné v tom, že jednotlivé dílčí změny se dějí velmi rychle, na čemž se velkou měrou podílí rychlý rozvoj vědy a techniky. Elektronické bankovnictví (2.1) je mezi uvedenými činnostmi specifické, protože v mnoha případech učinilo návštěvu pobočky banky zcela zbytečnou. Jeho jednoduchost navíc zvyšuje oblibu placení za zboží u obchodníka elektronickým převodem z účtu na účet a zákazník se tak úplně vyhne manipulaci s hotovostí. Elektronická správa financí se tak stala jednoduchou činností, kterou banky podporují kvůli rychlému automatizovanému zpracování a nabízejí svoje elektronické služby za nízké poplatky nebo případně úplně zdarma. Mezi další výhody pro klienty patří např. žádné čekání ve frontách na pobočce, stav účtu a pohyby peněz mají neustále k dispozici a mohou s nimi kdykoliv efektivně a snadno manipulovat. Přes všechny výhody s sebou nese e-banking jedno velké riziko - bezpečnost. Peníze odjakživa přitahovaly nekalé živly a i systémy elektronického bankovnictví a lidé je používající musejí neustále snášet útoky podvodníků a hackerů. Proto musí být na aplikace pracující s penězi a soukromými daty kladeny vysoké bezpečnostní požadavky s několika úrovněmi zabezpečení. Elektronické bankovnictví probíhá formou aktivní, které umožňuje manipulaci s penězi, a pasivní, které slouží ke kontrole účtu a sledování peněz. Nejrozšířenější je internetové bankovnictví, které vedle telefonického umožňuje mnohem větší rozsah služeb. Zatímco aktivní 1

18 2 KAPITOLA 1. ÚVOD operace jsou obvykle zpracovány na velmi vysoké úrovni, na pasivní operace není kladen tak velký důraz a často jsou obsaženy pouze v základní podobě - pohyby na účtu jsou archivovány pouze krátkou dobu, vyhledávání a filtrování je omezené, není možná správa více účtů v jednom bankovním systému a další. Mým cílem je navrhnout a vytvořit systém pro správu bankovních účtů, který odstraní některé z hlavních nedostatků pasivního internetového bankovnictví, přidá další funkce a umožní efektivní a rychlé získávání informací o stavu peněz na účtech v domácím nebo firemním prostředí. Aneb slovy klasika: Peníze jsou nenasytné, samotným se jim stejská, chtějí se rozmnožovat. Edward Albee

19 Kapitola 2 Popis problému, cíle a požadavky Tato kapitola popíše formy elektronického bankovnictví, jeho historii a jak elektronické bankovnictví vypadá v současnosti v České republice. Dále bude nastíněn popis implementovaného systému a cíle bakalářské práce. Kapitolu uzavře srovnání s konkurenčními produkty. 2.1 Elektronické bankovnictví Elektronické bankovnictví (také označováno jako e-banking nebo přímé bankovnictví) je způsob komunikace banky a klienta, kdy klient nemusí přijít osobně na pobočku banky a komunikuje s ní prostřednictvím elektronických zařízení - např. počítač, mobilní telefon, platební karta, bankomat. Obrázek 2.1: Co se klientům líbí na přímém bankovnictví Zdroj: Výzkum NFO AISA pro GE Capital Bank a [1] 3

20 4 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Bankovní operace Pasivní bankovní operace jsou činnosti, které nemanipulují, na rozdíl od aktivních operací, s vlastními finančními prostředky na účtu. Mezi aktivní bankovní operace patří: příkaz k úhradě na jiný účet v české nebo zahraniční měně zřízení, změna a zrušení inkasa nebo trvalého příkazu k úhradě Mezi pasivní bankovní operace patří: přehled informací o účtech zjištění zůstatku na účtu přehled transakční historie stažení účetních dat, výpisů nastavení bankovních služeb (např. frekvence zasílání výpisů, upozornění na změny zůstatku) informace o bankovních produktech, kurzu měn, úrokových sazbách Historie e-bankingu První formou elektronického bankovnictví byla debetní platební karta (2.2.1), kterou vydala v roce 1950 americká společnost Diners Club, Inc. První bankomat (zařízení pro výběr hotovosti pomocí elektronické karty) byl nainstalován v Londýně v roce Počátkem 80. let se začaly v obchodech objevovat první platební terminály, kde bylo možné platit kartou. S komercializací internetu na začátku 90. let se stalo běžným placení elektronickou kartou za zboží objednané na dálku přes internet. Současné bankomaty také umožňují další funkce vedle výběru hotovosti jako například dobíjení předplacených mobilních kupónů nebo podání jednorázového příkazu k úhradě. Nová generace bankomatů bude umožňovat i vklad hotovosti na účet. Velký rozvoj dalších forem elektronického bankovnictví nastal v 80. a 90. letech s rozvojem telekomunikačních technologií. Počátky home bankingu (2.2.3) se datují do 80. let, kdy vznikly systémy, které umožňovaly provádění transakcí na dálku pomocí počítače nebo klávesnice a televizoru připojených k telefonu. Mezi nejznámější home bankingový systém patřil britský systém Homelink, který byl vyvinut v roce V roce 1993 přestal být internet doménou univerzitních a vládních institucí a začaly na něj vstupovat velké komerční firmy a k prvnímu systému internetového bankovnictví (2.2.4) už zbýval jen malý krok. Celosvětově první institucí, která poskytla klientům internetové bankovní služby, byla banka Stanford Federal Credit Union v říjnu Prvním českým finančním ústavem, který zavedl internetové bankovnictví, byla v roce 1997 Rodinná družstevní záložna SFP, následovaná Fio, družstevní záložnou v roce 1998 a Expandia bankou (později ebanka, dnes Raiffeisenbank) v roce Telefonní bankovnictví (2.2.2) začalo v ČR po vzniku mobilních

21 2.2. FORMY ELEKTRONICKÉHO BANKOVNICTVÍ 5 Konec roku 1999 Konec roku 2000 Home Banking GSM Banking (pouze SIM Toolkit) Internet Phonebanking (pouze aktivní) Tabulka 2.1: Počty uživatelů přímého bankovnictví v ČR v letech 1999/2000 Zdroj: [2] sítí GSM v roce Nejdříve byly dostupné pouze pasivní operace, později přibyly i aktivní operace. Jak se internet po roce 2000 rychle rozšiřoval mezi obyvatele, rychle rostla i obliba přímého bankovnictví. To dokazuje nárůst počtu zákazníků českých bank za rok 2003, který např. u České spořitelny dosáhl 128 % z klientů na , Volksbank CZ vykázala meziroční růst 350 %, ČSOB 159 % a Raiffeisenbank 122 % [1]. V roce 2007 např. vzrostl počet uživatelů internetového bankovnictví Komerční banky o 25 % a jeho služeb využívalo klientů klientů z celkového počtu klientů Komerční banky využívalo některý z kanálů přímého bankovnictví [3]. V současné době (rok 2009) už všechny banky internetové a telefonní bankovnictví poskytují. Počet uživatelů využívajících některou z forem přímého bankovnictví neustále roste, přičemž zdaleka nejvíce používané jsou internetové bankovnictví a platební karty viz obrázek 2.2. S oblíbeností internetového bankovnictví začaly vznikat banky, které s klienty komunikovaly výhradně prostřednictvím internetu - tzv. internetové banky. První z nich byla na počátku 90. let americká Security First Network Bank. U nás se za první internetovou banku nechá považovat Expandia banka založená roku 1998 (od roku 2001 ebanka), která ale měla také několik kamenných poboček. První čistě internetovou bankou se stala mbanka, která do ČR přišla v roce 2007 a neprovozuje pobočky, pouze informační kiosky a finanční centra. Další informace o historii různých typů e-bankingu viz [5], [6]. 2.2 Formy elektronického bankovnictví Platební karty Platební karty patří do elektronického bankovnictví, ale jsou specifické svým úzkým zaměřením - používají se pouze k placení za služby a k výběru peněz z bankomatu (ATM). Dnes existují různé druhy platebních karet - např. tuzemské, mezinárodní, specializované (karty pouze pro internetové platby, platby za pohonné hmoty, předplatní karty). Karty vydávají různé nadnárodní společnosti jako je Visa International, MasterCard International, American Express a jiné Telefonní bankovnictví (telebanking, phone banking) Telefonní bankovnictví využívá pevnou telefonní linku nebo mobilní telefon ke zprostředkování bankovních operací. Poskytované služby se liší, některé banky umožňují plnohodnotné

22 6 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Obrázek 2.2: Průzkum používanosti produktů přímého bankovnictví v ČR v roce 2004 Zdroj: [4] ovládání účtu, jiné poskytují např. pouze informace o zůstatku peněz na účtu. Nevýhodou je přenos dat po telefonní lince nebo mobilní síti, který je zpoplatněný (některé banky používají telefonní čísla, u kterých klient neplatí poplatek za hovor). Do této kategorie patří: Použití SMS pro zasílání informativních zpráv (např. o stavu účtu). Využití služeb Call centra k uskutečnění operací prostřednictvím operátora/ky. IVR (Interactive Voice Response) - ovládání služby tónovou volbou telefonu, kdy je uživatel navigován lidským nebo elektronickým hlasem. Kombinace dvou výše uvedených, např. pro dodatečné ověření telefonním operátorem pro potvrzení aktivní operace. GSM bankovnictví - komunikace probíhá formou SMS zpráv, které obsahují text ve specifickém formátu. Kvůli vysoké obtížnosti existuje zjednodušení ve formě GSM SIM Toolkitu, kdy jsou bankovní služby dostupné jako součást menu mobilního telefonu. WAP bankovnictví - komunikace se speciálním internetovým bankovním rozhraním pomocí WAP protokolu. Wapové stránky jsou zjednodušenou podobou internetových stránek.

23 2.2. FORMY ELEKTRONICKÉHO BANKOVNICTVÍ 7 Java bankovnictví - použití bankovní aplikace pro mobilní telefony napsané v programovacím jazyce Java. Telefonní bankovnictví se k intenzivnější správě účtu nehodí, protože neposkytuje příliš velké pohodlí, např. vzhledem k malé velikosti obrazovky a klávesnice mobilního telefonu. Rozsah služeb také bývá omezený. V budoucnu se tato situace s příchodem chytrých komunikačních zařízení může změnit. V neposlední řadě je telefonní bankovnictví obvykle méně zabezpečené než např. internetové bankovnictví. Obvykle se používá pouze autentizace přístupovým jménem a heslem (hlasová komunikace, IVR), někdy také šifrovaná komunikace (GSM, WAP). V současnosti využívá telebanking méně lidí než internet banking viz graf Home banking Home banking umožňuje komunikaci s bankou prostřednictvím speciální aplikace, kterou má klient nainstalovanou na svém počítači. Služby, které home banking poskytuje se příliš neliší od internetového bankovnictví, včetně zabezpečení, kdy je obvykle použito ověření identity klienta jménem, heslem a osobním digitálním certifikátem nebo hardwarovým klíčem a komunikace je samozřejmě šifrována. Velkou výhodou home bankingu je, že je možné ho propojit s firemní aplikací a odesílat platby přímo z jejího účetního systému. Pro střední a velké firmy, které potřebují zadat velké množství transakcí denně, je tato forma bankovnictví nepostradatelná a nenahraditelná. Hlavně pro fyzickou osobu je nevýhodou, že banky poskytují home banking za výrazně vyšší měsíční poplatek než internetové bankovnictví. Další nevýhodou je nutnost instalace aplikace a to, že home bankingové aplikace jsou obvykle určeny pouze pro operační systém Microsoft Windows Internetové bankovnictví (internet banking) Internetové bankovnictví probíhá prostřednictvím webových stránek spuštěných v rámci internetového prohlížeče. Uživatel tedy nepotřebuje nic jiného než počítač s připojením k internetu. Internetové bankovnictví obvykle umožňuje největší rozsah aktivních a pasivních operací. Měsíční poplatky za provozování internetového bankovnictví jsou většinou nízké nebo je poskytováno úplně zdarma. Poplatky za aktivní operace vyjdou levněji než u telefonního bankovnictví, protože není potřeba platit za spojení. Některé banky rozlišují internetové bankovnictví pro různé cílové skupiny lidí, např. studenty, fyzické osoby, podnikatele, a podle toho jim zpřístupňují určitou podmnožinu bankovních služeb. Komunikace probíhá pomocí protokolu HTTPS a je šifrována digitálním certifikátem. Pro autentizaci je nutné zadat přihlašovací jména a heslo, často navíc banky nabízejí dodatečné zabezpečení ve formě osobního podpisového certifikátu nebo hardwarového klíče. Aktivní operace jsou v systémech internetového bankovnictví obvykle ještě více zabezpečeny než samotné prohlížení stránek bankovnictví a pasivní operace, takovou formou zabezpečení může být například autorizace transakce kódem zaslaným pomocí SMS na mobilní telefon uživatele nebo čipovou kartou. Tuto dodatečnou úroveň zabezpečení zavedly v uplynulých letech téměř všechny české banky. Obliba internetového bankovnictví každoročně vzrůstá, stejně jako obliba a rozšíření internetu mezi lidmi jako takového viz graf 2.3.

24 8 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Obrázek 2.3: Jednotlivci starší 16 let používající v ČR vybrané informační technologie Zdroj: [7] Podrobnější informace o jednotlivých formách přímého bankovnictví viz [8] a [9]. 2.3 České banky a jejich elektronické služby Souhrn údajů o 9 největších českých bankách za rok 2007 V tabulkách 2.2, 2.3, 2.4 je uveden přehled základních údajů o 9 největších českých bankách. Zbylé české banky tvoří poměrně zanedbatelnou část bankovního trhu a nebudou v této práci brány v potaz. Uvedené údaje jsou z roku 2007, případné výjimky jsou označeny. Zdroje se v některých údajích lehce rozcházely, takže jsem je zaokrouhlil, ale jejich vypovídající hodnota se tím nezmenšila Žebříček českých bank podle velikosti Z údajů v tabulkách 2.2, 2.3, 2.4 jsem sestavil žebříček bank podle velikosti viz tabulka 2.5. V úvahu byly vzaty počty klientů a celková aktiva za rok 2007, resp. celková aktiva za rok 2006 u Citibanky, počty klientů za rok 2008 u Komerční banky a za rok 2009 u mbanky.

25 2.3. ČESKÉ BANKY A JEJICH ELEKTRONICKÉ SLUŽBY 9 Název Citibank Commerzbank AG Česká spořitelna Kód banky www citibank.cz commerzbank.cz csas.cz Vznik v ČR Celková aktiva v mld. Kč 132 (2006) Počet klientů v tis. n/a n/a 5326 Počet klientů přímého bank. v tis. n/a n/a 994 Počet poboček Internet banking Citibank SERVIS 24, IBS Online BUSINESS 24 Home banking Ne MultiCash Gemini MultiCash Telebanking CitiPhone Ne Servis 24 Telebanking, Servis 24 GSM banking Tabulka 2.2: Údaje o Citibank, Commerzbank AG a České spořitelně za rok 2007 Zdroj: [10], [11] a domovské stránky bank Název Československá obchodní banka GE Money Bank Komerční banka Kód banky www csob.cz gemoney.cz kb.cz Vznik v ČR Celková aktiva v mld. Kč Počet klientů v tis (2008) Počet klientů přímého bank. v tis (2008) Počet poboček (2008) Internet banking InternetBanking 24, BussinessBanking 24 Internet Banka Mojebanka Home banking Homebanking 24 BankKlient Profibanka, Přímý kanál Telebanking Info 24, Linka 24, Telefon banka, Expresní linka, Mobil 24 Mobil banka Mobilní banka Tabulka 2.3: Údaje o ČSOB, GE Money Bank a Komerční bance za rok 2007 Zdroj: [10], [11] a domovské stránky bank

26 10 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Název mbank (BRE Bank S.A., o.s.p.) Raiffeisenbank UniCredit Bank Kód banky www mbank.cz rb.cz unicreditbank.cz Vznik v ČR Celková aktiva v mld. Kč 0,7 (2008) Počet klientů v tis. 200 (2009) Počet klientů přímého bank. v tis. 200 (2009) n/a n/a Počet poboček 9 finančních center, 17 mkiosků Internetové Internetové Online Banking, Internet banking bankovnictví bankovnictví Online Card, BusinessNet Home banking Ne MultiCash MultiCash, Eltrans 2000 Telefonní Telebanking, Telebanking mlinka bankovnictví, SmartBanking, GSM bankovnictví Business Linka Tabulka 2.4: Údaje o mbank, Raiffeisenbank a UniCredit Bank za rok 2007 Zdroj: [10], [11] a domovské stránky bank Pořadí Název Počet klientů Počet klientů přímého (v tis.) bankovnictví (v tis.) 1 Česká spořitelna Československá obchodní banka (ČSOB) Komerční banka GE Money Bank Raiffeisenbank 300 n/a 6 mbank UniCredit Bank 200 n/a 8 Citibank n/a n/a 9 Commerzbank AG n/a n/a Tabulka 2.5: Žebříček českých bank podle velikosti (Údaje jsou z let )

27 2.4. POPIS SYSTÉMU A CÍLE BAKALÁŘSKÉ PRÁCE Popis systému a cíle bakalářské práce Systém pro správu bankovních účtů je aplikace, která uživateli umožní mít přehled o svých bankovních účtech, transakcích na účtech a dalších informacích. Pracovní název aplikace je Bankovní účty. Protože aktivní bankovní operace podléhají vysoké úrovni zabezpečení a stávající elektronické systémy jednotlivých bank s nimi umožňují pracovat více než dostatečně, bude se systém Bankovní účty soustředit na pasivní operace, které nejsou v internetových bankovnictvích tak dobře propracovány, ale přesto tvoří významnou část práce s účtem. Internetová bankovnictví archivují pohyby na účtu obvykle pouze krátkou dobu (nejčastěji v řádu měsíců), neumožňují komplexní vyhledávání a filtrování v platbách. Dále neposkytují grafické znázornění pohybů na účtu a jiné statistické informace. Obvykle je podporován pouze export v několika málo formátech, obvykle buď TXT nebo CSV a kopie tištěných výpisů v PDF, takže není možné dělat reporty např. v HTML nebo XML. Protože každá banka má své vlastní proprietární bankovnictví, není možná správa více účtů v jednom bankovním systému. Protože existuje velké množství uživatelů, ať už jednotlivců nebo firem, které mají z různých důvodů několik účtů, nemožnost vytvářet přehledy, reporty a statistiky pro více účtů najednou může být velmi kontraproduktivní. Tyto nedostatky budou v systému Bankovní účty odstraněny a přibudou některé další užitečné funkce tak, aby systém jako celek zefektivnil správu pasivních operací s účty Co bude aplikace umožňovat se systémem bude moct pracovat více uživatelů (v různý čas) každý uživatel bude mít přístup pouze ke svým datům evidenci bankovních účtů uživatele import textových bankovních výpisů zobrazení importovaných výpisů a transakcí editaci importovaných výpisů a transakcí (např. přidání nebo změnu poznámky) filtrování a vyhledávání ve výpisech a transakcích export do různých formátů (např. HTML, CSV) statistické informace o zůstatku na účtu, přehledy o transakcích podle typu nebo data Výhody oproti online systémům internetového bankovnictví víceuživatelský přístup (např. členové rodiny, oddělení ve firmě) více bankovních účtů na jednom místě neomezená doba archivace výpisů a transakcí možnost editace a mazání výpisů a transakcí podle libosti uživatele

28 12 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY možnost vyhledávání a filtrování výpisů a transakcí podle různých údajů statistické informace, přehledy aplikace bude přenositelná - bude ji možné snadno přenášet z jednoho počítače na jiný aplikace bude fungovat i na operačních systémech a jejich konfiguracích, na kterých by některé online bankovnictví nefungovalo (např. Linux, Solaris) export do dalších formátů Nevýhody oproti online systémům internetového bankovnictví aplikace nebude umožňovat zadávání aktivních finančních operací k použití aplikace nebude stačit pouze webový prohlížeč aplikace bude náchylná na některé změny internetových bankovnictví (např. změna exportního formátu výpisů) Požadavky na systém Reálná využitelnost aplikace - chci, aby byla opravdu užitečná, dostala se do povědomí lidí a nezapadla prachem. Aplikace bude zdarma (bude šířena jako open source). Bezpečnost aplikace nade vše - šifrování dat, přístup chráněný heslem, bez bezpečnostních děr. Data jsou citlivá a musí být chráněna alespoň stejnou měrou, jakou jsou v internetovém bankovnictví. Možnost více účtů pro jednotlivé osoby - oddělené bankovnictví - uživatelé si navzájem nevidí do svých dat. Multiplatformnost - systém bude fungovat na operačních systémech Microsoft Windows a Linux Pokud to bude možné, aplikace bude co nejvíce nezávislá na internetu. Data budou snadno zálohovatelná. Aplikace bude co nejméně zasahovat do systému, na kterém běží. To umožní její snadné přemístění na jiný počítač. Automatické stahování výpisů z internetového bankovnictví, pokud se po provedení rešerše ukáže jako implementovatelné Cíl bakalářské práce Cílem této bakalářské práce je analyzovat, navrhnout a implementovat funkční systém, který co nejlépe splní uvedené vlastnosti a požadavky.

29 2.5. STRUKTURA BAKALÁŘSKÉ PRÁCE Struktura bakalářské práce Kapitola 2 se zabývá shrnutím základních faktů o elektronickém bankovnictví obecně a o tom, jak se vyvíjelo ve světě a v ČR. Jsou ukázány nedostatky, kterými trpí pasivní bankovní operace v internetových bankovnictvích a návrhy jak je řešit. Je uveden přehled vlastností a požadavků na navrhovanou aplikaci Systém pro správu bankovních účtů. V poslední části bude přehled a srovnání s již existujícími aplikacemi obdobného zaměření. Kapitola 3 se věnuje analýze projektu a softwarovému návrhu systému. Budou vybrány banky, jejichž výpisy bude možné v prototypu aplikace importovat. Proběhne rešerše, zda a jakým způsobem je možné implementovat do systému automatické stahování výpisů z webů internetových bankovnictví. Bude zvolena forma aplikace, programovací jazyk a datové úložiště. Bude provedena diskuze nad jednotlivými typy zabezpečení, které budou chránit data a uživatele systému. Kapitolu uzavře softwarový návrh systému včetně vybraných UML diagramů. V kapitole 4 budou zmíněna použitá řešení dílčích problémů. Kapitola 5 nastíní proces testování, předvede výsledky testování funkčního systému a navrhne případné změny v aplikaci. Kapitola 6 shrne splnění vytyčených cílů a načrtne možný budoucí vývoj aplikace. 2.6 Existující implementace obdobného systému Systému pro správu bankovních účtů mohou z uvedených forem přímého bankovnictví konkurovat pouze home banking a internet banking. Každá banka má své vlastní internetové bankovnictví, které neumožňuje práci s účty různých bank a má další již uvedené nedostatky. Home bankingové aplikace umožňují správu bankovnictví trochu jiným způsobem, např. dávkové zadávání transakcí nebo přímo propojení s firemním účetním systémem, obvykle ale pracují nad stejnými daty, která jsou dostupná v internetovém bankovnictví, takže jsou archivována jen určitou dobu. Pouze některé home bankingové systémy umožňují správu více účtů různých bank. Většina aplikací zabývajících se tímto segmentem softwaru je určena pro střední a velké firmy, takže je také patřičně zpoplatněna. To platí jak pro home bankingové aplikace, tak pro účetní systémy vybavené funkcemi pro práci s účtem. Mnou navrhovaná aplikace sice bude umět jen podmnožinu obvyklých funkcí těchto systémů (pasivní operace), ale zato bude zdarma. Srovnání s existujícími aplikacemi bude také užitečné v tom, že můžu objevit nedostatky nebo chyby, kterých se při návrhu a implementaci poté vyvaruji, a také mohu narazit na zajímavou nebo užitečnou funkci, která nebyla zatím uvedena a mohla by být v budoucnu implementována. Nyní uvedu některé příklady aplikací obdobného typu. Stručně budou uvedeny výhody a nevýhody daného řešení a jak se liší od mnou zamýšleného řešení systému. Protože bude systém primárně zaměřen na české banky, i v této rešerši se zaměřím na tuzemské produkty. Zde uvedené systémy jsou dostupné ke stažení v plné verzi nebo demo verzi a je možné je tedy otestovat. Existují další systémy pro správu bankovních účtů, ty ale nejsou veřejně dostupné ke stažení a vyzkoušení zdarma, jsou pouze prodávány za poměrně vysoké částky.

30 14 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Dále existují aplikace určené pro interní potřeby firem. Oba tyto druhy aplikací nejsou pro tuto rešerši podstatné, protože jsou určeny pro jiné cílové skupiny než volně a zdarma šiřitelný nástroj, jakým má Systém pro správu bankovních účtů být. V této části jsou zmíněny některé textové formáty používané českými bankami pro export výpisů a transakcí, např. univerzální GPC nebo CSV a BEST Komerční banky. Jejich bližší popis je v kapitole Aconto Free autor: PCS - Software, s.r.o. verze: 2.92 cena: omezená verze zdarma, plná verze stojí podle modulů a počtu licencí Kč forma: funkční verze s různými omezeními OS: Microsoft Windows odkaz: Aconto Free je program pro evidenci faktur, objednávek, bankovních výpisů, vedení pokladny a podvojného účetnictví a daňovou evidenci příjmů a výdajů. Program je určen pro živnostníky a menší společnosti a v této variantě je poskytován zdarma. Některé jeho funkce jsou ale omezeny, např. velikost databáze (max. 2 GB), počet daňových dokladů (max. 100), a neobsahuje moduly Sklad, Evidence majetku, Mzdy a Kasa. Funkce podobné Systému pro správu bankovních účtů: vedení účtů v tuzemské i zahraniční měně import bankovních výpisů pro banky: ČSOB, Komerční banka, Česká spořitelna, Raiffeisen bank a další přímé napojení na vybrané banky párování výpisů s odpovídajícími evidovanými položkami (faktury atp.) V programu je uvedeno, že umí importovat výpisu typu GPC z České spořitelny, ČSOB a Komerční banky, tyto formy výpisů ale nejsou u běžných účtů dostupné a běžné formáty transakční historie neumí. Formát BEST Komerční banky se mi nepodařilo naimportovat, ačkoli jsem postupoval přesně podle návodu, tak program vždy skončil s chybovou hláškou. Ovládání programu a taktéž importu výpisů je velmi složité, k čemuž přispívá i staromódní uživatelské prostředí. Několikrát mi program také spadl bez udání důvodu. Aconto Free je velmi rozsáhlý nástroj umožňující správu kompletního chodu firmy, bohužel jeho velikost jej činí příliš složitým a, troufnu si říct, nepoužitelným čistě pro správu účtů fyzických osob a malých podnikatelů. Mezi další nevýhody programu patří velikost zabraného místa na disku po instalaci, která je úctyhodných 130 MB, a program také není multiplatformní.

31 2.6. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU 15 Obrázek 2.4: Pohled na formulář pro import bankovních výpisů v programu Aconto Free DSMan autor: DAVID ŠAUER - DS-SOFT verze: 1.52 cena: základní verze zdarma, plná verze je placená podle počtu modulů a licencí, licence pro 1 uživatele s modulem základní fakturace stojí 582 Kč forma: funkční verze s několika omezeními OS: Microsoft Windows odkaz: DSMan je nástroj pro správu kontaktů, plánování a evidenci pro jednotlivce a malé firmy. Skládá se z různých modulů, které spolu funkčně příliš nesouvisí, např. kalendář, alarmy, číselníky, úkoly, fakturace, evidence zboží a modul pro práci s bankovními účty. Bankovní modul umožňuje tyto činnosti: evidence účtů import výpisů ve formátu GPC a ruční přidávání plateb párování výpisů s fakturami vyhledávání a filtrování v transakcích

32 16 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY Formát GPC ale poskytují jen některé české banky a význam některých polí se u jednotlivých bank liší. V DSMan se importují ze souboru výpisů pouze transakce, ke kterým se přidají informace o výpisu, nelze tedy zobrazit jen informaci o výpisu za dané období. Program umožňuje jednoduché vyhledávání a filtrování výpisů a plateb. Obrázek 2.5: Program DSMan s načtenými výpisy z GPC souboru Komerční banky Uživatelské rozhraní programu je jednoduché a přehledné, program je snadno ovladatelný. Bohužel neumí importovat jiné výpisy než GPC, takže jeho používání je omezeno jen na některé banky, které navíc export do formátu GPC nabízejí až u účtů pro podnikatele. Také není multiplatformní POHODA 2009 START autor: verze: cena: forma: OS: odkaz: STORMWARE s.r.o CZ verze na vyzkoušení je zdarma, plnohodnotné varianty stojí Kč tzv. startovací verze na vyzkoušení Microsoft Windows Ekonomický systém POHODA 2009 je jedním z největších účetních a ekonomických software produktů na českém trhu. Je určen pro malé, střední a větší firmy. Umožňuje vést účetnictví i daňovou evidenci a nabízí množství podpůrných nástrojů pro další ekonomické činnosti. Omezení verze START spočívá v limitovaném množství účetních operací, které je možné do systému zanést, jedná se např. o maximálně 200 položek účetního deníku, 100 bankovních položek, 100 faktur nebo 10 mezd.

33 2.6. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU 17 Součástí systému POHODA 2009 je sada funkcí Homebanking, která umožňuje pracovat se soubory pro komunikaci s bankou a to jak pro vytváření souborů se zadanými platbami pro banku, tak pro import bankovních výpisů. Podporovány jsou výpisy většiny českých bank, např. Komerční banka, ČSOB, Česká spořitelna, Citibank, Raiffeisenbank a další. Modul Homebanking umožňuje: import bankovních výpisů export transakcí, které je třeba odeslat bance, do příslušného exportního formátu ruční zadání transakcí načíst kurzy cizích měn z internetových stránek České národní banky POHODA 2009 Homebanking dokáže naimportovat téměř všechny druhy výpisů českých bank, hlavně těch, které banky umožňují stáhnout svým firemním klientům. Cílovou skupinou celého systému je firemní klientela a pro nepodnikatele by nenašel pravděpodobně uplatnění, protože nedokáže naimportovat výpisy ve formě transakční historie, které jsou jedinou možností exportu například u běžných účtů ČSOB, České spořitelny nebo mbank. Přestože je program velmi komplexní a umožňuje velké množství činností, na první pohled je vidět profesionální uživatelsky přívětivé prostředí s dobře rozvrženými ovládacími prvky a všudypřítomnou nápovědou po ruce. Obrázek 2.6: Program Pohoda s načtenými výpisy z účtu Komerční banky Účetní systém POHODA 2009 je velmi dobrý produkt, který je ale určen hlavně pro podnikatele. Pro běžného uživatele nebo menší firmu, která si chce sama vést přehled o bankovních platbách a účetní agendu nechává na jiné společnosti, je takto rozměrný produkt

34 18 KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY zbytečný a drahý. Navíc nepodporuje import formátů výpisů z běžných účtů některých bank, jak bylo zmíněno výše. Dalším aspektem je, že aplikace není multiplatformní Další programy Během hledání konkurenčních produktů jsem narazil na několik dalších, které jsou velmi podobné předchozím uvedeným nebo mi přijde zajímavé je zmínit. RQ Money odkaz: RQ Money je jednoduchý finanční program určený hlavně pro domácnosti. Pochází z dílny slovenského autora Slavomira Svetlika. Jeho hlavní funkcí je ruční přidávání příjmů a výdajů přiřazených do kategorií, k účtům a osobám. Program umí filtrovat transakce, hledat v nich, vykreslit graf příjmů a výdajů a zobrazit další statistické údaje. Je jednoduše ovladatelný, přehledný, využívá vestavěnou databázi SQLite a nemusí se instalovat, takže je snadno přenosný. Existuje pouze ve verzi pro Windows a je zdarma. Zaujal mě, protože se mi jeví jako vhodný doplněk k systému Bankovní účty, ve kterém by bylo možné evidovat hotovostní transakce domácností a malých firem. WinStrom 10 odkaz: WinStrom 10 je komplexní ekonomický balík, který je svou funkčností a cenou velmi podobný systému POHODA 2009 a je to vlastně jeho přímý konkurent. Část aplikace zabývající se bankovními účty a výpisy funguje téměř stejně jako POHODA 2009, je podporován import výpisů bank používajících formát GPC. Výhodou WinStromu 10 je jeho multiplatformnost, je napsán z většiny v programovacím jazyku Java a existují verze pro Windows, Linux a Mac OS X Zhodnocení existujících aplikací obdobného typu Z uvedených údajů je vidět, že pouze drahé komplexní účetní a ekonomické systémy dokáží importovat textové bankovní výpisy stažené z internetových bankovnictví různých českých bank. V těchto velkých systémech je správa bankovních operací pouze malou podmnožinou funkcí, kde zbytek tvoří nástroje pro účetní a daňové operace. Pro potřeby fyzických osob nebo podnikatelů, kterým účetnictví spravuje externí firma, jsou takové rozsáhlé a drahé programy obvykle zbytečné. Přesto tito lidé chtějí sledovat stav a pohyby peněz na svých účtech, které často mají u různých bank. V současnosti neexistuje v ČR program, který by to umožňoval a k tomu byl zdarma, uživatelsky přívětivý, nenáročný na ovládání a fungoval na různých operačních systémech. Zde vidím mezeru na trhu, kterou by mohl zaplnit Systém pro správu bankovních účtů.

35 Kapitola 3 Analýza a návrh řešení V této kapitole bude provedena analýza formátů výpisů používaných českými bankami. Následovat bude rešerše zabývající se možnostmi automatického stahování výpisů přímo z internetových bankovnictví. V další části části bude popsán výběr typu aplikace, programovacího jazyka, databáze a budou prozkoumány možnosti zabezpečení uživatelských dat. Poslední část této kapitoly se bude věnovat softwarovému návrhu aplikace. 3.1 Formáty bankovních výpisů Protože nemám přístup do všech internetových bankovnictví českých bank a ani do všech různých verzí poskytovaných jednou bankou, je potřeba vybrat banky a konkrétní formáty výpisů, které budou implementovány v prototypu aplikace. Z tabulky 2.5 vyplývá, že více jak 3,2 milionu uživatelů přímého bankovnictví, tedy asi 75% uživatelů této formy bankovnictví, je klienty tří největších českých bank - České spořitelny, Československé obchodní banky a Komerční banky. Za zmínku stojí také mbanka, která je nejnovější bankou v ČR a vykazuje za minulý rok největší nárůst počtu klientů ze všech českých bank. Z tohoto důvodu a protože mám k dispozici výpisy pouze těchto čtyř bank, bude provedena analýza a implementován import výpisů pouze těchto bank: Komerční banka, Česká spořitelna, ČSOB a mbank. Další banky mohou být přidány v budoucím vývoji systému. Aplikace internetového bankovnictví Komerční banky (Mojebanka), České spořitelny (Business 24 Internetbanking) a ČSOB (ČSOB BusinessBanking 24) umožňují export ve formátu ABO (GPC), některá pole ale u každé banky mají jiný význam a může dojít k případnému zkrácení textových informací v důsledku pevné délky textových polí, která není příliš velká. Formát ABO neboli GPC je standardní komunikační bankovní formát pro tuzemský trh, byl vytvořen Českou národní bankou (ČNB). Protože nemám zatím k dispozici internet bankingy určené pro podnikatele a kvůli omezením formátu GPC, budou implementovány dostupné alternativy k GPC, které jsou dostupné všem uživatelům (podnikatelských i nepodnikatelských internet bankingů). Nyní budou podrobněji popsány jednotlivé typy formátů výpisů, které tyto banky používají, a budou zvoleny vhodné formáty pro strojové zpracování. Protože každý typ výpisu obsahuje různý počet informačních polí, budou zvolena ta, která mohou být pro uživatele důležitá, a s těmi bude aplikace dále pracovat. 19

36 20 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Česká Spořitelna adresy internetových bankovnictví: K dispozici mám službu Servis 24 Internetbanking. Výpisy ze služby Business 24 Internetbanking nebudou zatím implementovány. Další informace se týkají služby Servis 24 Internetbanking. Česká spořitelna umožňuje export výpisů v textovém formátu ABO (GPC) a CSV. Export je dostupný v e-bankingu jako volba Export výpisů -> Datové výpisy. Bohužel tato možnost není k dispozici u běžných (nepodnikatelských) účtů. Export transakcí je dostupný také pod volbou Přehled účtů a zůstatků -> Transakční historie a jedná se o zjednodušený výpis ve formátu CSV. Tento typ výpisu ale neobsahuje některé údaje (např. období výpisu, zůstatek na účtu) a bylo by nutné tyto údaje případně zadat do aplikace ručně. Je to jediná možnost exportu u standardních účtů (nepočítáme-li klasický tištěný výpis v elektronické podobě ve formátu PDF) a tento typ účtu má pravděpodobně velká část klientů České spořitelny (fyzických osob). Jako typ výpisu jsem zvolil formát CSV (data oddělená středníkem nebo čárkou), protože není svázán pevnou délkou řádku jako formát ABO a nedochází tak u něj ke krácení informačních polí. Bude implementován import obou druhů CSV výpisů (Datový výpis i Výpis transakční historie). Struktura formátu CSV České spořitelny u Datového výpisu Podle informací České spořitelny tento typ výpisu není dostupný u nepodnikatelských účtů. Jedná se o netypický CSV formát. Údaje týkající se celého výpisu jsou na prvních 12 řádcích, poté následuje prázdný řádek, hlavičkový řádek a pak jednotlivé transakce v klasickém CSV formátu, kdy textová pole jsou uzavřená v uvozovkách a oddělená středníkem. Neobvyklé je formátování čísel, kde mezi řádem tisíců a stovek je mezera. Občas se objeví i netradičně mezera po znaménku (- 100,00). Popis polí tohoto formátu a příklad je v příloze C.1. Struktura formátu CSV České spořitelny u Výpisu transakční historie Výpis transakční historie je typický CSV formát, kdy textová pole jsou uzavřená v uvozovkách a oddělená středníkem nebo čárkou, podporovány budou oba druhy oddělovačů. Oproti kompletnímu datovému výpisu (viz výše) chybí úplně část týkající se obecných informací o výpisu. Počáteční zůstatek bude muset uživatel zadat při importu ručně, další údaje budou spočítány z transakcí (počáteční datum, koncové datum, debet, kredit a konečná balance). Popis polí a ukázka je v příloze C.1.

37 3.1. FORMÁTY BANKOVNÍCH VÝPISŮ Komerční banka adresa internetového bankovnictví: Komerční banka umožňuje export výpisů v textových formátech KB Best - OKM, Kompatibilní média - ABO (GPC) a CSV. Export je dostupný pod volbou Přehledy -> Přehled obratů nebo Přehledy -> Stažení účetních dat. Formát KB Best OKM je vlastní formát Komerční banky. U formát GPC dochází ke krácení informačních polí kvůli pevné délce řádku a neobsahuje textové informační AV pole (dodatečné informace). Rozdíl mezi informační hodnotou formátů KB Best a CSV není téměř žádný (KB Best má dostatečně velká pole, takže nedochází ke krácení textových informací), rozhodl jsem se tedy pro implementaci formátu KB Best, protože je lépe strojově zpracovatelný. Formát KB Best má pevnou délku řádku 475 bajtů a jednotlivá informační pole mají pevně stanovené umístění na řádku a délku. V tom je podobný formátu ABO, ale délka textových polí je větší, takže nedojde k oříznutí delšího textu. Popis polí a ukázka výpisu je v příloze C Československá obchodní banka adresy internetových bankovnictví: K dispozici mám službu ČSOB InternetBanking 24. ČSOB InternetBanking 24 umožňuje export výpisů v textovém formátu TXT a SLK (pro Microsoft Excel). U ČSOB BusinessBanking 24 je dostupný také formát ABO (GPC), ten nebude ale zatím implementován. Další informace se týkají služby ČSOB InternetBanking 24. Export je dostupný jako volba Informace o účtech -> Pohyby. Jako typ výpisu jsem zvolil formát transakční historie TXT, protože je snáze zpracovatelný než SLK a obsahuje stejné údaje. Obodobně jako u formátu transakční historie České spořitelny neobsahuje exportní formát TXT u ČSOB některé důležité údaje týkající se celého výpisu. Tyto údaje budou při importu spočítány z transakcí (počáteční a koncové datum, debet a kredit, počáteční a konečný zůstatek). Popis polí výpisu a jeho ukázka je v příloze C mbank adresa internetového bankovnictví: mbank je první internetová banka v ČR a poskytuje svoje finanční služby výhradně přes internet. Export výpisů je dostupný jako volba Moje účty -> Historie transakcí -> Uskutečněné transakce. Export je umožněn ve formátech CSV a PDF. Zvolil jsem formát CSV, protože je snadněji zpracovatelný. Výpis ve formátu CSV je typický CSV soubor, který je formátován tak, aby byl uživatelem snadno čitelný, což ztíží jeho strojové zpracování. Řád tisíců a stovek odděluje mezera.

38 22 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Formát má sice standardní strukturu, ale položky transakcí jsou zřetězeny v poli popis, což je nevýhodné pro počítačové zpracování. Popis polí a ukázka výpisu je v příloze C Důležitá informační pole společná pro všechny banky Ve výpisech (hlavně Best KB) existují pole, která nejsou pro tuzemské platby využívána nebo obsahují nepodstatnou informaci. S těmito poli se nebude pracovat a nebudou ukládána. Protože formát výpisu u každé banky obsahuje jiný počet položek, je třeba určit obecné položky, které jsou ve všech výpisech a/nebo mohou být pro uživatele důležité, a sjednotit tak návrh datového úložiště. Tyto položky bude aplikace uchovávat a pracovat s nimi. Obecná informační pole výpisu Název pole Datový typ [délka] Poznámka Číslo účtu String [20] Kód banky String [4] Název účtu String [50] Kód měny účtu String [3] Např. CZK, EUR Pořadové číslo výpisu Integer např. 1-12, 1-52, Počáteční datum výpisu Date Koncové datum výpisu Date Debet BigDecimal[15,2] Suma odchozích částek plateb Kredit BigDecimal[15,2] Suma příchozích částek plateb Počáteční zůstatek BigDecimal[15,2] Konečný zůstatek BigDecimal[15,2] Tabulka 3.1: Obecná informační pole výpisu

39 3.2. AUTOMATICKÉ STAHOVÁNÍ VÝPISŮ 23 Obecná informační pole transakcí Název pole Datový typ [délka] Poznámka Číslo protiúčtu String [20] Číslo protiúčtu Kód banky protiúčtu String [4] Kód banky protiúčtu Název protiúčtu String [50] Název protiúčtu Částka BigDecimal[15,2] Částka transakce v měně účtu Kód měny String [3] Kód měny účtu Originální částka BigDecimal[15,2] Originální částka v měně protiúčtu Kód měny protiúčtu String [3] Kód měny protiúčtu Variabilní symbol 1 Long Variabilní symbol Variabilní symbol 2 Long Variabilní symbol protiúčtu Konstantní symbol Integer Konstantní symbol Specifický symbol Long Specifický symbol Datum splatnosti (valuta) Date Datum splatnosti Datum zaúčtování Date Datum zpracování v bance Poznámka 1 String [100] Poznámka (např. dlouhý název protiúčtu, zpráva pro příkazce) Poznámka 2 String [100] Poznámka 2 (např. zpráva pro příjemce) Zpráva AV String [200] Doplňující text Systémový popis String [100] Systémový popis (např. typ platby) Storno String [20] Udává, jestli došlo ke stornování transakce Označení transakce String [30] Označení transakce v bankovním systému dané banky Tabulka 3.2: Obecná informační pole transakcí 3.2 Automatické stahování výpisů Hlavní idea za automatickým stahováním výpisů je tato: Do aplikace se budou importovat výpisy. Bylo by dobré, kdyby uživatel měl volbu naimportovat je ručně ze souborů stažených z online bankovnictví a nebo si aplikace sama požadované informace stáhla (ať už ve formě souboru nebo webové stránky). Možné překážky: Online bankovnictví používají komplexní webové stránky, které mají silné zabezpečení, tudíž není možné prosté stažení stránky pomocí HTTP protokolu a její zpracování. Je nutná interakce s webovou stránkou (vyplnění jména a hesla a případně zadání cesty k osobnímu certifikátu, výběr stránky v systému online bankovnictví).

40 24 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Použití maker nebo skriptů, které by simulovali činnost člověka sedícího u počítače by bylo velmi obtížné, protože v různých prohlížečích a jejich verzích, různých operačních systémech a na různých počítačích jsou ovládací prvky na webové stránce umístěny na různých místech a nebylo by možné k nim přistupovat pomocí absolutních souřadnic na obrazovce. Aby aplikace získala přístup do internetového bankovnictví, musel by do ní uživatel zadat svoje přihlašovací údaje do bankovnictví. Zde vidím velký problém s důvěrou k aplikaci Programové ovládání prvků webové stránky Řešením programového ovládání aplikace je použití prohlížeče integrovaného do aplikace. Takový prohlížeč by dokázal načíst danou webovou stránku, zadat do ní programově přihlašovací údaje a navigovat se na příslušnou stránku s výpisy. Při tomto procesu by se využívalo procházení stromu komponent, které tvoří webovou stránku, tzv. Document Object Model (DOM). Kvůli multiplatformnosti aplikace je vhodným kandidátem Mozilla Firefox, resp. jeho jádro Gecko (renderovací jádro používané produkty Mozilla pro vykreslování webových stránek). Mozilla poskytuje prostředky k integraci tohoto jádra do aplikací a vytvoření jednoduchého integrovaného (embedded) prohlížeče fungujícího v rámci aplikace. Tyto prostředky nejdou ale přímo zabudovat do aplikace, proto jsem se snažil najít už hotové komponenty embedded prohlížečů s jádrem Gecko, které by bylo možné použít v aplikaci napsané v programovacím jazyku Java, který je zamýšleným programovacím jazykem celého systému kvůli své multiplatformnosti a nenáročnosti aplikace napsané v Javě na správu uživatelem (není potřeba instalovat a složitě nastavovat). Velkou nevýhodou některých těchto embedded prohlížečů je, jak jsem zjistil, že nedokáží pracovat se stránkami, které obsahují Java applety, což by znemožnilo stahování výpisů např. z internetového bankovnictví Komerční banky, kde je přihlašování založeno na Java appletu. Problém s Java applety v embedded prohlížečích založených na Javě je v zásadě v tom, že není možné spustit pro applet nový Java Virtual Machine (JVM) uvnitř Java Virtual Machine, ve kterém běží vlastní aplikace s embedded prohlížečem. Existují komerční embedded prohlížeče, které problém s Java applety nemají. Jejich cena je bohužel vysoká a jsou určeny pro profesionální a rozsáhlé aplikace. Mezi tyto prohlížeče patří WebRenderer [12] a JxBrowser [13], oba jsou založeny na technologii od firmy Mozilla, jsou určené pro integraci do Java aplikací, jsou multiplatformní a plně podporují Java applety. Cena JxBrowseru začíná na 285 e, cena WebRenderu je ještě vyšší. Open source alternativy těchto embedded prohlížečů existují, ale nepodporují Java applety a mají další omezení nebo byl jejich vývoj před několika lety zastaven. Jediný open source embedded prohlížeč, který by podle tvůrců neměl mít problémy s Java applety, je JDic Browser [14]. JDic Browser funguje tak, že nalezne výchozí prohlížeč v systému a bude fungovat jako prostředník mezi ním a aplikací. V Microsoft Windows to může být buď Internet Explorer nebo Mozilla, pod Linux jen Mozilla. Bohužel projekt JDic byl opuštěn v polovině roku

41 3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI , poslední verze JDic podporuje Internet Explorer 5-6 a Mozilla Firefox 2. Se současnými verzemi těchto prohlížečů (Internet Explorer 8 a Mozilla Firefox 3) JDic nedokáže spolupracovat. Protože JDic pracuje pouze s výchozím prohlížečem nastaveným v operačním systému, bylo by na uživateli aplikace, aby měl jako výchozí prohlížeč nastavený např. multiplatformní prohlížeč Mozilla Firefox 2. Nezdá se mi ale rozumné nutit uživatele, aby kvůli automatickému stahování výpisů používal prohlížeč, který je už v současné době zastaralý a nahrazený novou verzí Bezpečnostní riziko Poskytnutí svých přihlašovacích údajů do internetového bankovnictví aplikaci, o které uživatel vlastně nic neví, je z jeho hlediska velké bezpečnostní riziko. Systém pro správu bankovních výpisů by tedy musel být opatřen digitálním certifikátem ověřeným důvěryhodnou certifikační autoritou, která by potvrdila bezpečnost uživatelem poskytnutých citlivých údajů a nemožnost jejich zneužití aplikací Výsledek rešerše o automatickém stahování výpisů V současné době neexistuje použitelné open source řešení integrovatelného prohlížeče, který by dokázal pracovat s Java applety, a komerční řešení jsou příliš drahá a v rozporu s požadavkem na dostupnost aplikace zdarma. Získání digitálního certifikátu, abych zaručil, že aplikace je bezpečná, by bylo také velmi složité a neobešlo se bez finančních nákladů. Z uvedených argumentů vyplývá, že implementovat automatické stahování výpisů z online systémů internetového bankovnictví, by byla nejistá a časově a finančně náročná záležitost, a vzhledem k cílové skupině uživatelů aplikace, kterou jsou fyzické osoby a malé firmy, by se to nevyplatilo. Automatické stahování výpisů tedy nebude v této fázi implementováno, může ale přijít ke slovu v budoucnosti, kdy bude lepší podpora Java appletů ze strany open source embedded prohlížečů nebo bude komponenta webového prohlížeče přímo integrována do budoucí edice platformy Java (v současnosti je ve vývoji, více [15]). 3.3 Výběr technologií pro implementaci Výběr typu aplikace Jakého typ aplikace bude, je velice důležitá otázka, protože zásadně ovlivní některá kritéria, která jsou na aplikaci kladeny. Internetová aplikace běžící kompletně na serveru (přístup pomocí webového prohlížeče) Výhody: Klient není závislý na použité technologii, používá k přístupu pouze svůj webový prohlížeč.

42 26 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Přístup z libovolného počítače vybaveného internetem. Zapouzdření - snadná správa a úpravy aplikace, které nemají žádný dopad na uživatele. Více uživatelů by mohlo pracovat najednou. Případně i jeden uživatel na více počítačích. Nevýhody: Výhradní závislost aplikace na internetu - v případě poruchy serverového stroje by aplikace nebyla vůbec dostupná (použitelná). Nekompatibilita různých prohlížečů a nových verzí podporovaných prohlížečů by mohla způsobit špatnou funkčnost aplikace. Velké přenosy dat, např. transakcí za delší období apod., by mohly být v řádu jednotek megabajtů i více, což by mohlo značně zpomalit práci s aplikací při pomalém připojení k internetu. Aplikace je zamýšlena jako volně šiřitelná a náklady na provoz serveru by nebyly nulové, obzvlášť při větším rozšíření aplikace mezi lidi, takže by aplikace nemohla být provozována zdarma. Potřeba správce serverového stroje. Data všech uživatelů by byla uložena na jednom centrálním místě, pokud by došlo k havárii serveru a ztrátě dat, následky by byly vážné. Desktopová aplikace s datovým úložištěm na serveru Desktopová aplikace je termín označující aplikaci, která je spuštěna a běží na PC uživatele. Není tedy na serveru a komunikace neprobíhá přes internet. Jsou možné tři varianty umístění databázového serveru. Centrální server pro všechny uživatele aplikace (podobně jako u celé internetové aplikace výše), jeden server pro celou lokální firemní síť nebo server nainstalovaný vždy lokálně na počítači, kde je aplikace. Výhody: Více uživatelů nebo jeden uživatel přihlášený na více počítačích by mohli pracovat najednou. Tento přístup by byl vhodný pro menší a střední firmy, kde by více lidí mohlo s aplikací pracovat najednou. Pokud by bylo datové úložiště v lokální síti, data by byla okamžitě k dispozici, nemuselo by se na ně čekat. Nevýhody: U centrálního serveru by byla opět závislost na funkčnosti internetového spojení.

43 3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI 27 Silná závislost aplikace na databázovém stroji - v případě poruchy by aplikace nebyla použitelná, data by nebyla k dispozici. Velké přenosy dat, např. transakcí za delší období apod., by mohly být v řádu jednotek megabajtů i více, což by mohlo zpomalit práci s aplikací, pokud by databázový server nebyl v lokální síti. Aplikace je zamýšlena jako volně šiřitelná a náklady na provoz centrálního databázového serveru by nebyly nulové. Při využití ve firmě, která má svůj vlastní databázový server v lokální síti, a pro lokální server na PC by to nebyl problém. Počáteční instalace by zahrnovala poměrně složitou konfiguraci databázového stroje, vytvoření databáze a nastavení přístupových práv uživatelů. Potřeba správce databázového stroje. Otázkou je, zda by bylo opodstatněné vícenásobné současné používání aplikace, protože v menších firmách má většinou na starosti tuto agendu jedna osoba. Desktopová aplikace Výhody: Data jsou okamžitě k dispozici, nemusí se na ně čekat. Nezávislost na internetu, internet by byl potřeba pouze pro stažení výpisů (čili menších objemů dat) a aplikace by byla plně funkční i bez dočasně nefunkčního internetu. Výpisy se nechají stáhnout a importovat i za několik dní zpětně, takže by bylo možné aplikaci plně používat. Dostupnost aplikace není omezená funkčností serveru. Aplikace může být naprogramována tak, aby nevyžadovala žádnou počáteční instalaci, ruční vytvoření databáze ani správce serveru. Byla by také možnost snadné přenositelnosti na jiný počítač bez nutnosti jakékoliv další konfigurace. Nevyskytovaly by se žádné dodatečné náklady spojené s provozem a správou aplikace, takže by mohla být šiřitelná plně zdarma. V menších firmách má většinou na starosti tuto agendu jedna osoba, takže požadavek vícenásobného současného přístupu k datům není potřeba. Je možné dodatečně v budoucnu implementovat možnost serverového datového úložiště (pro větší firmu). Nevýhody:

44 28 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Aktualizace a vylepšování aplikace by znamenalo pro uživatele vyměnit starou verzi za novou, což by s sebou také neslo riziko přesunu dat. Pokud by došlo pouze ke změně vlastní aplikace a ne databáze, nemusela by se data přesouvat do nové verze databáze, jinak by řešením byl kompletní export a import dat do nové verze. Případně by update na novou verzi vyřešil speciální program napsaný pro tuto příležitost. S aplikací by mohl najednou pracovat pouze jeden uživatel. Zlomyslný uživatel může smazat data ostatních uživatelů. Databázi ale navrhnu tak, aby nemohl získat data obsažená v databázových souborech. Po zvážení požadavků na aplikaci a výhod a nevýhod jednotlivých variant jsem se rozhodl pro desktopovou aplikaci. Mým cílem tedy bude implementovat Systém pro správu bankovních účtů jako desktopovou aplikaci, která nebude závislá na internetu, bude malá a přenositelná z počítače na počítač bez potřeby větších uživatelských zásahů, nebude ve velké míře závislá na hardwarovém vybavení počítače. Datové úložiště bude přímo součástí aplikace, takže nad daty budou moct operace probíhat rychle a uživatel bude svůj čas trávit efektivně a ne čekáním na odezvu serveru. Různé kopie aplikace budou moct používat nezávislí uživatelé bez jakýchkoliv omezení na funkčnosti. V případě potřeby, např. u střední firmy, může být v budoucnu přidána alternativa mít centralizované datové úložiště na lokálním databázovém serveru Výběr programovacího jazyka Protože jsem se rozhodl pro desktopovou aplikaci a jedním z požadavků je multiplatformnost, zvolil jsem jako programovací jazyk Javu. V současné době je Java rozšířený, oblíbený, podporovaný a rozvíjený jazyk, má velký potenciál a měl by umožnit implementaci všech funkčních prvků aplikace. Jistou nevýhodou Javy může být její závislost na Java Virtual Machine a verzi JRE (Java Runtime Environment) - prostředí umožňujícího běh Java aplikací. V současné době je aktuální verze Java 6 a verze JRE 6 Update 14. Na této verze bude aplikace vyvíjena a testována. Uživatel musí mít pro spuštění aplikace nainstalované na svém počítači Java Runtime Environment, které je možné stáhnout z [16] Výběr datového úložiště Protože jsem se rozhodl implementovat desktopovou aplikaci, která není závislá na internetu a současně je snadno přenositelná a klade co nejmenší nároky na znalosti uživatele, databáze bude součástí aplikace (tzv. embedded databáze). Embedded databáze je opakem architektury klient-server, aplikace pro přístup k datům nevyužívá databázový server, ale databázi, která je spuštěná v adresovém prostoru aplikace, která ji využívá. Aplikace přistupuje prostřednictvím databázové knihovny přímo k souborům s daty. Z toho plyne, že embedded databáze jsou primárně určeny pro práci v single-user režimu (současně obsluhují jen jednoho uživatele). Vlastní databáze je uživateli skrytá a nevyžaduje údržbu. Výhody embedded databází:

45 3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI 29 jednoduché API (aplikační programové rozhraní) - obvykle poskytují jen množinu funkcí, která aplikace potřebuje malá velikost snadná instalace - buď v operačním systému nebo přímo jako součást aplikace, uživatel nic neinstaluje a nekonfiguruje neprovádí se externí údržba databáze mimo aplikaci rychlost - při práci s menšími objemy dat jsou mnohonásobně rychlejší než databázové servery snadná záloha, přesun dat - databáze je obvykle tvořena složkou s několika soubory, takže stačí složku zkopírovat na jiné místo Nevýhody embedded databází: většinou neobsahují přístupová práva, systém přístupových práv k datům se řeší na aplikační úrovni transakční mechanismy nejsou většinou ve velké míře implementovány některé nepodporují dotazovací jazyk SQL (používají jiný, pro ně optimálnější, dotazovací jazyk) konzistence dat - z důvodu rychlosti jsou data kešována v paměti a bez korektního uzavření DB mohou být datové struktury na disku poškozeny Zdroj: [17], [18] Problémem by také mohla být multiplatformnost. Pokusím se tedy najít databázi, která podporuje dotazovací jazyk SQL, který ovládám, je multiplatformní, dokáže spolupracovat s Java aplikací a podporuje transakce a přístupová práva. Embedded databází je velké množství, zaměřil jsem se na tyto tři nejznámější: Oracle Berkeley DB Java Edition odkaz: Jedná se o embedded databázi od světového databázového lídra Oracle. Je open source a kompletně napsaná v Javě, takže je multiplatformní. Podporuje transakce. Nepodporuje ale SQL dotazovací jazyk. Používá dotazování na bázi B-stromu, které je údajně rychlejší než SQL. SQL je mi ale známější.

46 30 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ SQLite odkaz: SQLite je rychlá rozšířená relační embedded databáze. Je open source a podporuje transakční principy. Umí SQL dotazování. SQLite je napsaná v jazyce C a existují verze pro Microsoft Windows i Linux, to by ale znamenalo mít v aplikaci verze knihoven pro každý operační systém zvlášť. Existuje rozhraní pro práci s SQLite databází (JDBC). Apache Derby odkaz: Apache Derby je další open source relační databáze s SQL dotazováním. Derby je napsaná kompletně v Javě a je tak multiplatformní. Podporuje transakční zpracování a téměř úplně standard SQL99. Derby podporuje přístupová práva uživatelů a šifrování dat. Její velikost je velmi malá (knihovny mají velikost pouze 2,5 MB). Od roku 2006 je Derby standardně dodávána s Java Devolopment Kit 6 (balík vývojových nástrojů) pod názvem JavaDB (bez jakýchkoliv změn). SQLite a Derby jsou z pohledu mé aplikace podobné. Derby je napsaná v Javě a tudíž její knihovny jsou multiplatformní, takže nejsou potřeba knihovny pro každý operační systém zvlášť. Systém pro správu bankovních účtů bude tedy využívat jako embedded databázi Apache Derby (JavaDB). V případě potřeby, např. u menší firmy, je možné v budoucnu implementovat jako alternativu centralizované datové úložiště na lokálním databázovém serveru, se kterým by desktopová aplikace pracovala. To by ale vyžadovalo větší administrativní úkony ze strany správce aplikace. Výhodou by byla možnost používat několik kopií aplikace na různých místech v jednom okamžiku (stejný uživatel i různí uživatelé). 3.4 Zabezpečení uživatelských dat Bezpečnost aplikace bude rozdělena do dvou úrovní: bezpečnost dat (databáze) oddělený přístup uživatelů (uživatelských účtů) pomocí autentizace Programovací jazyk Java byl od začátku navržen jako bezpečný jazyk, obsahuje množství API, nástrojů a implementací běžně používaných bezpečnostních algoritmů a protokolů (včetně šifrování, zabezpečené komunikace, autentizace a autorizace.

47 3.4. ZABEZPEČENÍ UŽIVATELSKÝCH DAT Bezpečnost databázových dat Bezpečnost databázových dat spočívá ve 3 hlavních úkolech: zašifrování fyzických databázových souborů na pevném disku povolení přístupu do databáze pouze po autentizaci omezení práv uživatelů pouze na jejich data Všechny tyto prvky databáze Apache Derby umožňuje. Zašifrování fyzických databázových souborů na pevném disku Každý uživatel bude mít svoji databázi. Databáze je adresář se soubory, pro každou databázi je adresář unikátní. Pro připojení k databázi bude nutné bootovací heslo, které bude použito k fyzickému šifrování a dešifrování databázových souborů. Jako symetrický šifrovací algoritmus bude použito 128-bitové šifrování AES, které je považováno za jeden z nejbezpečnějších šifrovacích algoritmů současnosti. Povolení přístupu do databáze pouze po autentizaci Jako přihlašovací jméno do databáze bude sloužit uživatelovo přihlašovací jméno do aplikace a jako heslo bude použit SHA-1 otisk zřetězení přihlašovacího jména a hesla do aplikace zkrácený o minimum(délka přihlašovacího hesla uživatele, 24) znaků. Omezení práv uživatelů pouze na jejich data Protože každý uživatel bude mít svoji vlastní databázi, bude jejím výhradním vlastníkem a bude tak mít přístup ke svým datům pouze on sám. Pokud by byla jedna databáze společná pro všechny uživatele, představovalo by to problém, protože by celá databáze byla šifrovaná jedním klíčem, který by musel být uložen na bezpečném místě (tedy ne ve zdrojovém kódu nebo v souboru s nastavením). Při větším počtu uživatelů a dat by mohl být problém s rychlostí databáze. A co se mi jeví jako nejpodstatnější problém, uživatel by nemohl svá data zálohovat prostým zkopírováním složky s databází. Různá databázová schémata pro každého uživatele v rámci jedné databáze s příslušným nastavením přístupových práv by vyřešila otázku oddělení dat uživatelů, bohužel by musel existovat nějaký nadřazený uživatel (systém nebo administrátor), který by práva nastavoval. Role administrátora by byla vytvořena pouze pro tento účel a navíc by data uživatelů nebyla před ním chráněna (pokud by nebyla šifrována ještě uvnitř databáze, což je zbytečné). Pokud by se o přidělování práv staral systém (aplikace), byl by opět problém, kam uložit jeho heslo pro přístup do databáze. Uložení hesel a jiných citlivých údajů přímo do zdrojového kódu není vůbec bezpečné, protože řetězce jsou v Javě po zkompilování v *.class souborech snadno čitelné. Generování šifrovacího klíče podle nějakého pravidla by bylo odhalitelné pomocí reverzního inženýrství.

48 32 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Ochranou proti reveznímu inženýrství je metoda zvaná obfuskace [19]. Jde o tzv. matení kódu. Ve zdrojovém kódu jsou přejmenovány proměnné, metody a třídy na kombinaci (často nečitelných) znaků. Obfuskátory často umožňují také optimalizaci a kompresi kódu. Ne všechny obfuskátory ale dokáží zamaskovat (zašifrovat) konstantní řetězce znaků a i u těch, které to dokáží, není pro hackera velký problém získat informaci zpět, protože všechny obfuskační metody jsou ze své podstaty reverzibilní. Z uvedených důvodů není metoda obfuskace pro tuto aplikaci vhodná, protože její účinnost je omezená. Proto jsem se rozhodl, že každý uživatel bude mít svoji vlastní databázi chráněnou jeho přístupovým jménem a heslem a protože se tyto informace zadávají při přihlašování, nebudou uvedené ve zdrojovém kódu ani nikde jinde. Ve zdrojovém kódu bude uvedeno přihlašovací jméno a heslo do systémové databáze, ve které budou uvedeny pouze nezneužitelné informace jako je přihlašovací jméno uživatele a jednosměrně zašifrovaný otisk hesla (zahashovaný pomocí 160-bitového algoritmu SHA-1). Při přihlášení bude otisk zadaného hesla porovnán s otiskem v databázi, vlastní heslo nikde uloženo nebude. Tato metoda se pro autentizaci běžně používá. Jako bootovací heslo uživatelské databáze a heslo pro přístup do uživatelské databáze bude použit SHA-1 otisk zřetězeného přihlašovacího jména a hesla. To je vhodné kvůli tomu, aby byla splněna minimální délka hesla u 128-bitového šifrovacího algoritmu AES, která je 16 (128 bitů = 16 bajtů). Použití otisku samotného hesla by představovalo velké bezpečnostní riziko, protože tento otisk je uložen v systémové databázi. Aby délka tohoto hesla do databáze nebyla vždy 40 znaků, což je délka otisku SHA-1, a ztížilo se tak prolomení hesla, bude jako databázové heslo sloužit SHA-1 otisk zřetězeného přihlašovacího jména a hesla zkrácený o mininum(délka přihlašovacího hesla uživatele, 24) znaků. Tento způsob ochrany dat uživatelů se mi jeví jako neproniknutelný případným útočníkem, protože bez znalosti hesla nebude možné dostat se k uživatelovým datům a v důsledku také zjednoduší implementaci aplikace, návrh databáze a databázové dotazování. Nevýhodou oddělených databází pro každého uživatele je, že zlomyslný uživatel může smazat databáze ostatních uživatelů. Tento problém by nebyl odstraněn ani společným umístěním dat všech uživatelů v jedné databázi. Toto riziko bude ponecháno na uživatelích a jejich nastavení systémových přístupových práv Oddělený přístup uživatelů do aplikace pomocí autentizace Jelikož aplikace bude umožňovat správu bankovních účtů různých uživatelů, bude z důvodu bezpečnosti před začátkem práce s ní požadována autorizace přihlašovacím jménem a heslem. Tím bude zabezpečeno výhradní právo práce s daty pro vlastníka těchto dat. Při ověřování přihlašovacích údajů se aplikace dotáže své systémové databáze, kde bude uloženo uživatelské jméno a otisk jeho hesla (zahashovaný algoritmem SHA-1). Přihlašovací jméno a heslo do systémové databáze bude ve zdrojovém kódu programu, což nepředstavuje bezpečnostní riziko, protože systémová databáze nebude obsahovat žádné zneužitelné informace (místo hesla uživatele bude uložen pouze jeho otisk).

49 3.5. SOFTWAROVÝ NÁVRH APLIKACE Softwarový návrh aplikace V rámci analýzy jsem provedl softwarový návrh systému, který byl v některých částech zjednodušen, protože vlastní aplikace nebude natolik komplexní, aby vyžadovala podrobnou dokumentaci. Jako dostačující považuji katalog požadavků, uživatelské role, diagramy složitějších aktivit, diagram komponent aplikace a návrh relační databáze. Diagramy byly vytvořeny v programu Enterprise Architect od firmy Sparx Systems Katalog požadavků Katalog požadavků udává požadavky, které musí implementovaný systém splňovat. Funkční požadavky udávají, jakou funkčnost musí program mít. Nefunkční požadavky kladou omezení na vzhled a způsob fungování aplikace. Funkční požadavky F1. Systém bude umožňovat vytváření a správu více nezávislých uživatelských účtů. F1.1. Každý uživatel může změnit nebo smazat pouze svůj účet a má přístup pouze ke svým datům. F2. Uživatel bude moct evidovat své bankovní účty. F3. Uživatel bude moct importovat výpisy transakcí z internetových bankovnictví. F3.1. Import bude probíhat pomocí textového souboru F3.2. Budou podporovány výpisy těchto českých bank: Komerční banka, Česká spořitelna, ČSOB, mbank. F3.3. Uživatel bude moct importovat výpisy pouze k účtům, které vytvořil v systému. F4. Uživatel bude moct zobrazit, spravovat a filtrovat výpisy a transakce a vyhledávat v nich. F4.1. Bude možné spárovat transakci s předdefinovaným typem transakce, což umožní snadné odlišení transakcí. F5. Uživatel bude moct exportovat data do výstupního formátu HTML a CSV. F6. Systém bude umožňovat zobrazení statistických informací. F6.1. Bude možné zobrazit aktuální zůstatek na účtu. F6.2. Bude možné zobrazit počet výpisů a transakcí za určité období.

50 34 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Nefunkční požadavky N1. Aplikace musí být bezpečná - šifrování databázových souborů, autorizace uživatelů. N2. Aplikace bude multiplatformní - bude fungovat na operačních systémech Microsoft Windows a Linux. N3. Databáze bude integrovaná v programu - embedded databáze. N4. Aplikace bude desktopová a nebude vyžadovat připojení k internetu. N5. Aplikace bude snadno přenositelná Uživatelé a jejich práva V systému bude pouze jedna uživatelská role. Každý uživatel bude moct: spravovat své účty, výpisy, transakce a nastavení exportovat a importovat data upravit nebo smazat svůj uživatelský účet Uživatel bude mít přístup pouze ke svým datům Diagramy aktivit Diagramy aktivit se používají pro popis dynamických prvků systému. Ukazují, jak jdou po sobě jednotlivé dílčí aktivity od začátku činnosti do jejího konce. Vybrané diagramy aktivit jsou v příloze D Diagram komponent aplikace Diagram komponent 3.1 ukazuje komponenty použité v systému a jejich vztahy. Komponenta je modulární část systému, která zapouzdřuje svůj obsah a je vyměnitelná za jinou komponentu, která má stejnou funkčnost a používá stejná rozhraní. Aplikace bude využívat GUI knihovnu uživatelských prvků Swing jazyka Java. Popis komponent Java Virtual Machine (JVM) je virtuální stroj umožňující běh aplikace napsané v programovacím jazyce Java. Aplikační modul je modul využívající GUI knihovnu nástrojů Swing a umožňující vlastní funkčnost aplikace.

51 3.5. SOFTWAROVÝ NÁVRH APLIKACE 35 Obrázek 3.1: Diagram komponent Java Persistence API (JPA) je objektově-relační mapovací framework a zprostředkovává ukládání objektů do databáze. Java Database Connectivity (JDBC) je API poskytující základní rozhraní pro jednotný přístup k databázím. Database Management System (DBMS) - Apache Derby (JavaDB) (Systém řízení báze dat) je modul zapouzdřující ukládání dat a nabízející rozhraní pro další aplikace, které tato data mohou využívat Návrh relační databáze Databáze jsou dvojího typu - systémová databáze a uživatelské databáze. Systémová databáze Systémová databáze obsahuje pouze tabulku uzivatele, ve které jsou uchovávána přihlašovací jména a otisky hesel uživatelů. Systémová databáze se používá pouze při registraci a přihlašování uživatele. Její schéma je v příloze D.2.1. Poznámka: Globální nastavení aplikace bude uloženo v konfiguračním XML souboru.

52 36 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Uživatelská databáze Každý uživatel má svoji uživatelskou databázi obsahující informace o nastavení, účtech, výpisech a transakcích. Schéma uživatelské databáze je v příloze D.2.2. Tabulka udaje obsahuje údaje o uživateli. Tabulka nastaveni obsahuje nastavení uživatelského prostředí (každý uživatel má své vlastní nastavení). Ukládá se aktuální použitý Look & Feel (vzhled GUI), oddělovač v CSV při exportu, a naposledy použité cesty při importu a export dat. Tabulka ucty obsahuje uložené účty uživatele. Tabulka banky obsahuje předdefinované české banky a jejich údaje, uživatel má možnost tato data změnit a přidat nové banky. Tabulka vypisy obsahuje položky, které se týkají celých výpisů. Tabulka transakce obsahuje položky, které se týkají jednotlivých transakcí. Tabulka kategorie obsahuje typy transakcí nadefinované uživatelem.

53 Kapitola 4 Implementace V této kapitole bude přiblížena implementace Systému pro správu bankovních účtů. Budou zde uvedeny použité technologie a popsány jednotlivé dílčí celky aplikace. Pro usnadnění implementace aplikace jsem použil vývojové prostředí NetBeans IDE [20], které umožňuje velmi efektivní psaní zdrojového kódu programu a obsahuje i velmi dobře propracovaný designér grafického uživatelského rozhraní. Mezi další dovednosti NetBeans IDE patří spouštění a debuggování programu, podpora verzování kódu, kontrola syntaxe, obsahuje různé šablony a dokáže chytře doplňovat zdrojový kód či zobrazit dokumentaci. 4.1 GUI - grafické uživatelské rozhraní Grafické uživatelské rozhraní (GUI) je uživatelské rozhraní, které umožňuje ovládat aplikaci pomocí grafických prvků zobrazených na obrazovce monitoru. Vzhled GUI je obvykle jedním z nejdůležitějších aspektů aplikace, protože je to první věc, se kterou uživatel přijde po spuštění programu do styku. Pokud GUI nevypadá hezky a neovládá se dobře, může uživatele odradit od používání jinak velice dobře fungující aplikace. K tvorbě GUI jsem použil designér integrovaný v NetBeans IDE, protože ruční tvorba GUI by vzhledem k velkému množství ovládacích prvků zabrali výrazně více času. Designér například umožňuje dodržet pravidla v rozložení prvků v okně, která mohou být velmi komplexní a bylo by obtížné je popsat ručně zdrojovým kódem. Designér na základě vytvořené grafické podoby vygeneruje zdrojový kód sám. Při tvorbě GUI jsem se snažil dbát na správné rozmístění ovládacích prvků v okně a decentní používání barev. Okna neobsahují příliš velké množství ovládacích prvků, dělá je to nepřehlednými a složitými na orientaci. Část ovládacích prvků byla přesunuta kvůli zpřehlednění aplikace do menu. Ovládací prvky, které zobrazují text, nebo tabulky byly vybaveny kontextovým menu, které umožňuje například zkopírovat vybraný text do schránky nebo označit řádek nebo sloupec v tabulce. Tím se zvýšila interaktivnost aplikace. V aplikaci je možné vybrat jeden z předvolených vzhledů - Look & Feel, které jsou součástí platformy Java, některé jsou multiplatformní (Metal, Nimbus, Motif), další jsou pouze pro Microsoft Windows (standardní Windows vzhled) nebo Linux (GTK). 37

54 38 KAPITOLA 4. IMPLEMENTACE Pokud je nezbytné, aby v okně bylo větší množství ovládacích prvků, přidal jsem k nim popisné texty a nápovědu, která se zobrazí při najetí myší na prvek (tzv. tool-tip). Pokud je uživatel vyzván k zadání údajů, je mu přesně oznámeno co a v jakém tvaru má zadat a jaké jsou povolené hodnoty. Pokud zadá špatnou hodnotu, aplikace mu oznámí, kde udělal chybu. Pokud se provádí akce, která trvá delší dobu a program během ní nebude reagovat, aplikace o tom dá uživateli vědět změnou kurzoru z obyčejného na zaneprázdněný. Ke zvýšení dostupnosti ovládacích prvků (accessibility) a rychlosti práce s aplikací jsem využil přiřazení klávesových zkratek, ať už běžně používaných (např. Ctrl+F pro hledání v tabulce, F1 pro nápovědu atp.) nebo tzv. mnemoniky, která umožňuje rychlou navigaci pomocí klávesnice (označení komponenty nebo provedení akce po stisknutí Alt + podtržené písmeno v popisce komponenty). F. Do programu byla také integrována nápověda ve formě uživatelské příručky, viz příloha Dodržováním těchto pravidel jsem se snažil udělat program uživatelsky přívětivý. Jak grafické uživatelské rozhraní aplikace vypadá, je možné vidět z obrázků v příloze E. 4.2 Struktura aplikace Aplikace se skládá z několika dílčích částí: přihlášení uživatele registrace nového uživatele přehled účtů uživatele import bankovních výpisů přehled naimportovaných výpisů a transakcí přehled nadefinovaných typů transakcí a párování s transakcemi export dat v tabulkách do HTML a CSV změna nastavení a údajů uživatele nápověda (uživatelská příručka) a informace o autorovi Tyto části jsou v aplikaci buď reprezentovány plochou v hlavním okně (záložkou) nebo dialogovým oknem. 4.3 Ukládání dat do databáze Pro usnadnění práci s databází jsem použil objektově-relační mapovací framework Java Persistence API (JPA), který umožňuje jednoduchý přístup k persistování (ukládání) objektů do databáze a slouží jako nadstavba nad přímým psaním SQL dotazů.

55 4.4. UKLÁDÁNÍ NASTAVENÍ PROGRAMU DO DATABÁZE A XML 39 Mimo jiné není JPA závislé na jednom konkrétním typu databáze, takže přechod k jinému typu databáze by znamenal pouze jednoduchou úpravu konfigurace. JPA se může samo postarat o vytvoření tabulek, pokud neexistují. K relačně-objektovému mapování na databázi je použit jazyk anotací (meta informací) zavedený ve verzi Java 5, který zjednodušuje popis mapování a vztahů mezi objekty a není tak potřeba tyto informace definovat v konfiguračním XML, jako tomu bylo předtím. Dojde také ke zvýšení přehlednosti zdrojového kódu, protože anotace je uvedena přímo u kódu, který ovlivňuje. Při ukládání a změně dat v databázi byly důsledně používány databázové transakce, takže pokud by během práce s databází došlo k chybě, data, která jsou v databázi, budou vždy platná. Například není možné, aby se do databáze kvůli chybě uložila pouze polovina transakcí z výpisu, buď se uloží celý výpis nebo se vůbec neuloží. K propojení seznamu načtených objektů z databáze s tabulkou jsem s výhodou použil knihovnu Beans Binding [21], která je součástí NetBeans IDE. Tato knihovna slouží k synchronizaci vybraných vlastností dvou objektů (např. seznam objektů a datový model tabulky). Toto propojení může být jednosměrné (čtení - změna vlastnosti v jednom objektu se projeví v druhém, ale obráceně to neplatí) nebo obousměrné (čtení a zápis). 4.4 Ukládání nastavení programu do databáze a XML Uživatelské nastavení každého uživatele se ukládá do jeho databáze. Globální nastavení týkající se celé aplikace se ukládá do XML souboru. V prototypu aplikace se ukládá pouze jméno posledního přihlášeného uživatele, tento uživatel je pak automaticky přednastaven při dalším zobrazení přihlašovacího okna. 4.5 Logování varování a chyb Pokud vznikne nějaká výjimka v aplikaci, je zapsána (zalogována) do souboru. Uživatel tak má možnost zjistit podrobnější informace, proč k výjimce došlo a zabránit opakovanému vzniknutí takovéto situace. Uživateli je také oznámeno přímo v aplikaci, že k výjimce došlo a podle povahy výjimky se pokračuje v běhu programu (varování) nebo se program ukončí (chyba). Pokud vznikne neočekávaná běhová (run-time) výjimka neboli chyba v programu, není zalogována a je na uživateli, aby o ní dal vědět tvůrci aplikace, aby mohla být opravena. 4.6 Import výpisů V prototypu aplikace je podporován import 4 českých bank. Systém je navržen modulárně tak, aby přidání importu z další banky bylo co nejjednodušší. Každé bance odpovídá jedna metoda, která je zodpovědná za pársování souborů s výpisy a vytvoření a předání seznamu výpisů metodě, která je uloží do databáze. Při přidání importu výpisů nové banky tak stačí přidat pouze jednu odpovídající metodu.

56 40 KAPITOLA 4. IMPLEMENTACE 4.7 Verzování zdrojového kódu Zdrojový kód systému byl po celou dobu implementace verzován pomocí systému pro správu a verzování zdrojových kódů Subversion [22]. Díky tomu není problém podívat se kdykoliv na předchozí verzi zdrojového kódu, např. z důvodu opravení chyby v programu. 4.8 Dokumentace zdrojového kódu Zdrojový kód byl pečlivě komentován, tam kde si to situace žádala. Kromě toho byl využit standardní dokumentační nástroj jazyka Java - Javadoc, pomocí kterého je možné vytvořit dokumentaci aplikačního programového rozhraní celého systému ve formátu HTML. Vygenerovaná dokumentace Javadoc Systému pro správu bankovních účtů je umístěna na přiloženém CD.

57 Kapitola 5 Testování Tato kapitola se bude věnovat procesu testování aplikace a navrhne případné změny z něj plynoucí. Po celou dobu implementace byl systém neustále testován. Byly vyzkoušeny různé možnosti vstupů uživatele a práce s grafickým uživatelským rozhraním. Nalezené chyby byly odstraněny a předpokládám, že takto byla eliminována většina chyb. Nelze samozřejmě popřít Murphyho zákony, např. Software bugs are impossible to detect by anybody except the end user. Proto bude provedeno testování prototypu dvěma potenciálními uživateli, kteří se na vývoji systému nepodíleli. Jejich úkolem bude otestovat funkčnost programu, posoudit grafické uživatelské rozhraní a jeho ovládání a celkovou uživatelskou přívětivost aplikace. 5.1 Průběh a výsledky testování prototypu Dvěma testovacím uživatelům (muž, student, 22 let, operační systém Linux; žena, studentka, 22 let, operační systém Windows XP) byl předán archiv s aplikací Systém pro správu bankovních účtů bez bližších pokynů či vysvětlení, pouze s uživatelskou příručkou a běžnými soubory s výpisy staženými z internetového bankovnictví. Uživatelé měli za úkol vyzkoušet ovládání a běžnou práci s aplikací a všímat si případných obtížně řešitelných úkolů, vzhledu a ovládání uživatelského rozhraní a chybného chování aplikace. Po skončení práce s aplikací ohlásili uživatelé tyto výsledky: Oba: Uživatelské prostředí je přehledné a je jasné, kde kterou funkci hledat. Oba: Možnosti ovládání programu myší a klávesnicí jsou standardní. Muž: Je výhoda, že veškerá činnost se nechá provádět pouze pomocí klávesnice. Oba: Program reagoval rychle na všechny požadavky. 41

58 42 KAPITOLA 5. TESTOVÁNÍ Žena: Nezaznamenala žádné chyby. Muž si všiml varovných hlášení vypisovaných do konzole při spuštění na Linuxu a při použití vzhledu GTK. Oba: Aplikace reaguje přesně tak, jak očekávali, žádné nelogičnosti nebo chybné chování nebylo zaznamenáno. Po prozkoumání uvedených varovných hlášení na Linuxu při použití vzhledu GTK bylo zjištěno, že jde o chybu v Java platformě, která se vyskytovala u stylu GTK při vykreslování kombo boxu. Tato chyba byla opravena ve verzi JRE 6 Update 12. Z výsledků testování plyne, že dodržování zásad správného návrhu GUI (4.1) mělo svůj význam a uživatelé, kteří testovali aplikaci, s ní byli spokojení po stránce uživatelské přívětivosti i funkčnosti. Uživatelským testováním nebyly objeveny žádné chyby v programu. To může ale pouze znamenat, že se na tyto chyby nenarazilo. Potenciální problém vidím v importu výpisů, kdy stažený bankovní výpis může mít trochu odchylnou strukturu, což může být způsobeno jeho chybným vygenerováním v systému banky nebo neúplnou implementací pársování daného formátu, a aplikace ho poté ohlásí jako neplatný nebo dojde ke špatnému naimportování dat. Tento problém může nastat také, pokud banka změní strukturu exportního formátu. Aplikace nebyla testována na jiných operačních systémech než Microsoft Windows a Linux, ale vzhledem k tomu, že využívá komponenty napsané pouze v Javě, je pravděpodobné, že bude fungovat i na operačních systémech Solaris a Mac OS X.

59 Kapitola 6 Závěr Systém pro správu bankovních výpisů byl úspěšně implementován a otestován. Splněny byly všechny požadavky na něj kladené a aplikace je připravena na běžné používaní. Jestli se uchytí a najde své uživatele, ukáže až čas. Rešerše ukázala, že automatické načítání výpisů z online systémů internetového bankovnictví by v současné době bylo pouze velmi špatně implementovatelné, navíc problém důvěry zákazníka v to, že aplikace nezneužije jeho přihlašovací údaje do internetového bankovnictví, tu bude stále. Pro menší firmy není tato funkce prioritní, protože nemají tak velký objem transakcí, a větší firmy si mohou dovolit zaplatit přímý zabezpečený kanál do bankovního systému. Přesto může být tato funkce implementována v budoucnu za použití nových technologií. Analýzou byly určeny bezpečnostní prvky určené k ochraně dat uživatele a byly všechny implementovány v prototypu. S uživatelskými daty tedy nemůže pracovat nikdo jiný než jejich vlastník. V budoucnu by mohla být aplikace rozšířena o import dalších formátů výpisů u zatím nepodporovaných bank a přidání nových formátů ke stávajícím bankám. Mezi další možná rozšíření může patřit například vytváření grafů o stavu peněz na účtu nebo počtu transakcí za určité období. 43

60 44 KAPITOLA 6. ZÁVĚR

61 Literatura [1] Kristýna Havligerová. Peníze.cz Obliba e-bankingu v ČR, [2] Petr Vykoukal. Peníze.cz Přímé bankovnictví v ČR, [3] KB.cz Tiskové prohlášení: Internetové bankovnictví Mojebanka používá již 500 tisíc klientů Komerční banky, [4] Marek Lutonský a Jan Staněk. Mobilmania.cz, Měšec.cz Průzkum používanosti produktů přímého bankovnictví v ČR, sc-3-a [5] Wikipedia.org Historie platebních karet. [6] Wikipedia.org Internetové bankovnictví. [7] Český statistický úřad Kolik a kdo z nás používá Internet?, internet. [8] Měšec přímé bankovnictví. [9] Peníze.cz přímé bankovnictví. [10] Kniha Seznamů.cz Komerční banky. [11] Peníze.cz Banky. [12] WebRenderer Embedded Java browser. 45

62 46 LITERATURA [13] JxBrowser Embedded Java browser. [14] JDesktop Integration Components (JDIC) project. [15] Java and integrated web browser component, [16] Java SE Downloads Java Runtime Environment. [17] Radim Kolář. Root.cz Embedded databáze, [18] Wikipedia.org Embedded database. [19] Douglas Low. Protecting Java Code Via Code Obfuscation. obfuscation.html. [20] Vývojové prostředí Netbeans IDE. [21] Beans Binding Knihovna pro synchronizaci vlastností 2 objektů. [22] Subversion Systém pro správu a verzování zdrojových kódů.

63 Příloha A Seznam použitých zkratek AES Advanced Encryption Standard API Application Programming Interface ATM Automated Teller Machine CRC Cyclic Redundancy Check CSV Comma Separated Values DBMS Database Management System DES Data Encryption Standard DOM Document Object Model DSA Digital Signature Algorithm GUI Graphical User Interface GSM Global System for Mobile communications HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IVR Interactive Voice Response JDBC Java Database Connectivity JDK Java Development Kit JPA Java Persistence API JRE Java Runtime Environment JVM Java Virtual Machine 47

64 48 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK MD5 Message-Digest algorithm 5 n/a non-available (nedostupné) PDF Portable Document Format RSA Rivest, Shamir, & Adleman (autoři algoritmu) SHA-1 Secure Hash Algorithm 1 SIM Subscriber Identity Module SMS Short Message Service SSL Secure Sockets Layer TXT TeXT UML Unified Modeling Language WAP Wireless Aplication Protocol WWW World Wide Web XML extensible Markup Language

65 Příloha B Slovník Applet je softwarová komponenta, která běží v kontextu jiného programu, např. webového prohlížeče nebo v panelu pro přepínání oken v grafickém uživatelském prostředí. Bývá většinou orientován na plnění konkrétní funkce v daném kontextu a nepředpokládá se, že bude používán jako samostatná aplikace. Asymetrické šifrování používá volně dostupný veřejný klíč k zašifrování zprávy a soukromý (tajný) klíč pro dešifrování (tedy 2 různé klíče). Klíče jsou spolu matematicky svázány, ale nelze z jednoho vypočítat druhý. Soukromý klíč musí uživatel držet v tajnosti. Příkladem asymetrických šifrovacích algoritmů je RSA, DSA nebo Diffie- Hellman. Autentizace je proces ověření identity daného uživatele. Autorizace je činnost, při které se ověřuje, zda má uživatel dostatečná práva k provedení určité akce. Databázová transakce je operace nad databázovými daty, má tyto vlastnosti: provede se celá nebo vůbec (atomicita); po jejím provedení bude databáze obsahovat pouze platná data (konzistence); transakce o sobě navzájem nevědí a nevidí zpracovávaná data u jiné transakce (izolovanost); změny, které jsou v databázi provedeny, jsou trvalé a nemohou být ztraceny (trvalost). Digitální certifikát je veřejný šifrovací klíč elektronicky podepsaný certifikační autoritou a používá se v asymetrickém šifrování. Certifikační autorita je hodnověrná instituce, která ověří identitu osoby, které certifikát vydává. Součástí digitálního certifikátu je elektronický podpis, který slouží k ověření identity majitele. E-banking viz Elektronické bankovnictví. Elektronické bankovnictví je způsob komunikace banky a klienta, kdy klient nemusí přijít osobně na pobočku banky a komunikuje s ní prostřednictvím elektronických zařízení - počítač, mobilní telefon, platební karta. Elektronický podpis jsou elektronické identifikační údaje autora. Připojuje se k elektronickému dokumentu kvůli ověření identity dané osoby a zaručení integrity - neměnnosti dokumentu. 49

66 50 PŘÍLOHA B. SLOVNÍK Hacker je původně počítačový expert, dnes je toto označení používáno pro osobu nabourávající se do počítačových systémů nejčastěji za účelem poukázat na jejich špatné zabezpečení nebo získat tajné údaje či peníze. Hardwarový klíč je elektronické zařízení na ochranu programu proti nelegálnímu používání, bez něj nelze program spustit. Hashovací funkce je metoda pro převod libovolného množství dat do krátkého textového řetězce pevné délky (otisk či hash), který je pro stejná vstupní data stejný. Tento převod je jednosměrný a je velmi obtížné zjistit původní data. Hashování se využívá v šifrování, pro kontrolu a porovnávání, indexování a vyhledávání dat. Pravděpodobnost, že 2 vstupní řetězce se stejným otiskem jsou různé, je velmi malá. Příkladem hashovacích funkcí jsou CRC, MD5 nebo SHA-1. Java Virtual Machine (JVM) je sada počítačových programů a datových struktur, které využívají model virtuálního stroje pro vykonávání počítačových programů napsaných v jazyce Java. Look & Feel je termín používaný k popisu grafického uživatelského rozhraní (GUI). Look & Feel zahrnuje vzhled a rozmístění ovládacích prvků (look) a jejich chování vzhledem k činnosti uživatele (feel). Meta informace je termín pro tzv. informace o informacích. Jedná se o značky (nebo také tagy), které blíže určují některé vlastnosti daného cíle, ke kterému se vztahují. Příkladem mohou být anotace v jazyce Java (od verze 5), které umožňují blíže určit vlastnosti daného zdrojového kódu, např. že je daná metoda zastaralá a neměla by se používat (@Deprecated) nebo že se mají ignorovat varování (@SuppressWarnings). Open source je počítačový software s otevřeným zdrojovým kódem. Otevřenost znamená, že autor veřejně poskytuje zdrojový kód a licence softwaru při dodržení podmínek umožňuje uživatelům zdrojový kód využívat, například prohlížet a upravovat. Šifrování (kryptografie) je způsob (také vědní obor), jak utajit zprávu před přečtením neoprávněnou osobou. Základem šifrování je šifra, což je algoritmus, kterým se převede prostý text (nebo binární soubor) do nečitelné (zašifrované) podoby. Klíč je tajná informace, bez které není možné zašifrový text přečíst (dešifrovat). Existují různé způsoby šifrování, např. symetrické a asymetrické šifrování. Někdy se do šifrování řadí i hashovací funkce. Symetrické šifrování využívá pro šifrování i dešifrování zprávy stejný klíč. Oproti asymetrickému šifrování má výhodu ve značně menší výpočetní náročnosti. Jeho nevýhodou je nutnost sdílet stejný klíč, takže si odesílatel a příjemce zprávy musí nejdříve klíč vyměnit nějakou bezpečnou cestou. Příkladem asymetrických šifrovacích algoritmů je AES, DES a vylepšený Triple DES nebo Blowfish.

67 Příloha C Formáty bankovních výpisů V této příloze je podrobně rozebrána struktura výpisů bank, jejichž import bude implementován. C.1 Česká spořitelna Oba formáty České spořitelny jsou soubory typu CSV. Datový výpis České spořitelny Část týkající se celého výpisu: Řádek Název pole Typ Popis 1 Account number text Číslo účtu 2 Account currency text Měna účtu 3 Statement number číslo s 2 deset. místy Číslo výpisu 4 Statement date datum YYYY/MM/DD (Koncové) datum 5 Statement frequency text Frekvence vyhotovení 6 Account name text Jméno účtu 7 Number of transactions číslo Celkový počet transakcí 8 Pending transactions číslo s 2 deset. místy Suma neukončených transakcí 9 Debit (-) číslo s 2 deset. místy Suma odchozích plateb 10 Credit číslo s 2 deset. místy Suma příchozích plateb 11 Initial balance číslo s 2 deset. místy Počáteční zůstatek 12 Final balance číslo s 2 deset. místy Konečný zůstatek 13 [ prázdný řádek ] Tabulka C.1: Datový výpis České spořitelny - údaje o celém výpisu 51

68 52 PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ Následuje část týkající se transakcí - jedna transakce na řádek: Pořadí Název pole Typ Popis 1 Due date datum YYYY/MM/DD Datum splatnosti 2 Payment text Systémový popis platby 3 Counter-acc. no. text Číslo protiúčtu/kód banky 4 Transaction číslo s 2 deset. místy Částka v měně účtu 5 Currency text Měna 6 Depreciation date datum YYYY/MM/DD Datum zaúčtování 7 Info on Payment text Poznámka o platbě 8 Counter-acc. name text Název protiúčtu 9 Var.symb.1 číslo Variabilní symbol 10 Bank record text Označení transakce v bance 11 Constant symbol číslo Konstantní symbol 12 Specific symbol číslo Specifický symbol 13 Var.symb.2 číslo Variabilní symbol protiúčtu 14 ISO Amount číslo s 2 deset. místy Částka v měně protiúčtu 15 Currency text Měna protiúčtu 16 Transaction ex. Rate číslo s 2 deset. místy Směnný kurz transakce 17 Accounts ex. Rate číslo s 2 deset. místy Směnný kurz účtu 18 Payment reference text Poznámka 2 19 Payer code text Označení plátce 20 Payee code text Označení příjemce 21 Koncový znak - Tabulka C.2: Datový výpis České spořitelny - transakce Obrázek C.1: Vzorový datový výpis České spořitelny Zdroj: Česká spořitelna

69 C.2. KOMERČNÍ BANKA 53 Výpis transakční historie České spořitelny Jedné transakci odpovídá jeden řádek výpisu. Pořadí Název pole Typ Popis 1 Položka text Systémový popis 2 Valuta zaúčt. datum YYYY/MM/DD Datum splatnosti 3 Var.symb.2 číslo Variabilní symbol protiúčtu 4 Částka CZK číslo s 2 deset. místy Částka 5 Bankovní spojení text číslo protiúčtu/kód banky 6 Dat.zprac. datum YYYY/MM/DD Datum zaúčtování 7 Var.symb.1 číslo Variabilní symbol 8 Storno text Informace o stornu platby 9 Název protiúčtu text Název protiúčtu 10 Konst.symb. číslo Konstantní symbol 11 Spec.symb. číslo Specifický symbol 12 Zpráva pro příjemce text Zpráva pro příjemce 13 Referenční číslo číslo Označení v systému banky Tabulka C.3: Výpis transakční historie České spořitelny Obrázek C.2: Vzorový výpis transakční historie České spořitelny Zdroj: Česká spořitelna C.2 Komerční banka Komerční banka využívá pro export výpisů vlastní vytvořený formát KB Best. Formát KB Best

70 54 PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ Obrázek C.3: Hierarchická struktura formátu KB Best Zdroj: Komerční banka Obrázek C.4: Formát KB Best - hlavička (HO) a patička (TO) Zdroj: Komerční banka

71 C.2. KOMERČNÍ BANKA 55 Obrázek C.5: Formát KB Best - obratová věta 51 (obecné údaje výpisu) Zdroj: Komerční banka

72 56 PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ Obrázek C.6: Formát KB Best - transakční věta 52 nebo 53 (transakce) Zdroj: Komerční banka Věta 53 bude ignorována, protože neobsahuje účetní informace (pohyby na účtu).

73 C.3. ČESKOSLOVENSKÁ OBCHODNÍ BANKA 57 Obrázek C.7: Vzorový výpis KB Best Komerční banky Zdroj: Komerční banka C.3 Československá obchodní banka Formát transakční historie Obrázek C.8: Vzorový výpis transakční historie ČSOB Zdroj: ČSOB

74 58 PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ Číslo řádku Název pole Hodnota 1 Informační řádek Pohyby na účtu č.: {číslo}, ze o výpisu dne {čas DD.MM.YYYY H:MM} 2 [ prázdný řádek ] 3 Datum zaúčtování datum zaúčtování: {datum D.M.YYYY} 4 Částka částka: {číslo s 2 deset. místy} 5 Měna měna: {text} 6 Zůstatek na účtu zůstatek: {číslo s 2 deset. místy} 7 Konstantní symbol konstantní symbol: {číslo} 8 Variabilní symbol variabilní symbol: {číslo} 9 Specifický symbol specifický symbol: {číslo} 10 Systémový popis označení operace: {text} 11 Název protiúčtu název protiúčtu: {text} 12 Bankovní spojení protiúčet: {text} 13 Poznámka 1. řádek poznámka: {text} 14 Poznámka 2. řádek {text} 15 [ prázdný řádek ] 16 pro další transakce se opakují řádky 3-15 Tabulka C.4: Formát transakční historie ČSOB Pozn.: značky { typ } označují hodnotu typu typ. C.4 mbank Formát transakční historie Formát CSV má sice standardní strukturu, ale položky transakcí jsou zřetězeny v poli popis, což je nevýhodné pro počítačové zpracování.

75 C.4. MBANK 59 Část týkající se celého výpisu: Interval řádků Popis pole Řádek Hodnota Typ 1-6 Informace o bance [ nedůležitá ] 7-9 Informace o klientovi 8 {název klienta}; {text} Informace 13 {začátek};{konec}; 2x {datum} o období 15 {datum vyhotovení}; {datum} výpisu 17 {způsob zasílání}; {text} 20 {typ účtu}; {text} Informace o účtu 22 {měna účtu}; {text} 24 {číslo účtu}; {text} 26 {úroková sazba}%; {deset. číslo} Kred. položky;{počet}; {číslo}{deset. 29 {částka} {měna}; číslo}{text} Informace o částkách Debet. položky;{počet}; {číslo}{deset. 30 {částka} {měna}; číslo}{text} debetu, kreditu a Součet;{počet}; {číslo}{deset. 31 {částka} {měna}; číslo}{text} počátečním zůstatku ;;;#Počáteční zůstatek:; {deset. číslo} 33 {částka} {měna}; {text} 35 Hlavičkový řádek 36 - (35+n) 1 - n transakcí (35+n+1) (35+ ;;;#Konečný zůstatek:; {deset. číslo} Konečný zůstatek - (35+n+5) n+3) {částka} {měna}; {text} Tabulka C.5: Formát transakční historie mbank - údaje o celém výpisu Pozn.: značky { hodnota } označují název položky na řádku, značky { typ } označují hodnotu typu typ.

76 60 PŘÍLOHA C. FORMÁTY BANKOVNÍCH VÝPISŮ Následuje část týkající se transakcí - jedna transakce na řádek: Pořadí Název pole Typ Popis 1 Datum uskutečnění datum DD-MM-YYYY Datum splatnosti 2 Datum zaúčtování datum DD-MM-YYYY Datum zaúčtování 3 Popis transakce text (zřetězené položky) Systémový popis transakce Poznámka 1 Poznámka 2 Konstantní symbol Variabilní symbol Specifický symbol Název protiúčtu Číslo protiúčtu Kód banky protiúčtu 4 Částka transakce číslo s 2 deset. místy Částka transakce 5 Zůstatek číslo s 2 deset. místy Zůstatek po transakci Tabulka C.6: Formát transakční historie mbank - transakce Pozn.: Ne všechny položky se musí vždy v popisu transakce vyskytovat, jejich délka také není pevně daná. Obrázek C.9: Vzorový výpis transakční historie mbank Zdroj: mbank

77 Příloha D UML diagramy V této části jsou uvedeny vybrané UML diagramy, které nebyly zařazeny do hlavní části práce z důvodu přehlednosti. D.1 Vybrané diagramy aktivit Obrázek D.1: Diagram aktivit - Přihlášení uživatele 61

78 62 PŘÍLOHA D. UML DIAGRAMY Obrázek D.2: Diagram aktivit - Spuštění aplikace

79 D.1. VYBRANÉ DIAGRAMY AKTIVIT 63 Obrázek D.3: Diagram aktivit - Vytvoření uživatele

80 64 PŘÍLOHA D. UML DIAGRAMY Obrázek D.4: Diagram aktivit - Import výpisů

81 D.2. SCHÉMA RELAČNÍ DATABÁZE 65 Obrázek D.5: Diagram aktivit - Filtrování výpisů D.2 Schéma relační databáze D.2.1 Systémová databáze Obrázek D.6: Schéma systémové databáze

82 66 PŘÍLOHA D. UML DIAGRAMY D.2.2 Uživatelská databáze Obrázek D.7: Schéma uživatelské databáze

83 Příloha E Grafické uživatelské rozhraní Tato příloha obsahuje několik ukázek grafického uživatelského rozhraní implementované aplikace. Jsou ukázány příklady rozmístění prvků v okně a také jejich různý vzhled podle použitého Look & Feel. Obrázek E.1: Přihlášení do aplikace Vzhled: Windows 67

84 68 PŘÍLOHA E. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ Obrázek E.2: Přehled účtů se zobrazeným oknem úprava účtu Vzhled: Windows Obrázek E.3: Přehled načtených výpisů a transakcí Vzhled: Windows

85 Obrázek E.4: Filtrování výpisů Vzhled: Metal 69

86 70 PŘÍLOHA E. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ Obrázek E.5: Přehled typů transakcí se zobrazeným oknem úprava typu transakce Vzhled: Nimbus Obrázek E.6: Import výpisů Vzhled: Nimbus