}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Terénní aplikace pro správu Univerzitního kampusu Bohunice D IPLOMOVÁ PRÁCE
Bc. Jaromír Benda
Brno, Jaro 2015
Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Bc. Jaromír Benda
Vedoucí práce: doc. RNDr. Tomáš Pitner, Ph.D. iii
Podˇekování Dˇekuji vedoucímu diplomové práce panu docentu T. Pitnerovi za pˇripomínky a ochotu pˇri vedení práce, panu doktorovi A. Kuˇcerovi za postˇrehy ze strany Správy Univerzitního kampusu Bohunice, sestrám Denise a Kateˇrinˇe Gbelcovým za korekturu práce a svým blízkým za jejich velkorysou podporu.
v
Shrnutí Diplomová práce se zabývá analýzou, návrhem a realizací terénní Android aplikace pro SUKB (SUKB Archibus Asistent) a související integrované webové služby do systému Archibus (Archibus Web Service). Práce dále pˇrináší souhrn poznatku˚ z oblastí facility managementu, bezpeˇcnosti a webových služeb, které jsou taktéž v práci adekvátnˇe využity. V rámci práce došlo k poodkrytí vazeb a cˇ inností systému Archibus za úˇcelem efektivní implementace webových služeb. Opomenuta není ani analýza pracovního procesu a analýza bezpeˇcnostních rizik, které se staly pilíˇri této diplomové práce. Hlavním cílem práce je zjednodušení procesu údržby na Masarykovˇe univerzitˇe a zvýšení mobility a efektivity pracovníku˚ SUKB.
vii
Klíˇcová slova Správa Univerzitního kampusu Bohunice, Archibus, Android, bezpeˇcnost, facility management, údržba, webové služby, SUKB Archibus Asistent, Archibus Web Service
ix
Obsah 1 2
3
4
5
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Facility Management . . . . . . . . . . . . . . . . . . . . . . . ˇ 2.1 Norma CSN/EN 15 221 . . . . . . . . . . . . . . . . . . ˇ 2.2 Cinnosti a jejich zajištˇení v rámci FM . . . . . . . . . . . 2.3 Facility manažer . . . . . . . . . . . . . . . . . . . . . . . 2.4 Computer Aided Facility Management . . . . . . . . . . Bezpeˇcnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Základní pojmy bezpeˇcnosti . . . . . . . . . . . . . . . . 3.2 Bezpeˇcnostní politika . . . . . . . . . . . . . . . . . . . . 3.2.1 Proces rˇ ízení bezpeˇcnosti . . . . . . . . . . . . . 3.3 Analýza bezpeˇcnostních rizik . . . . . . . . . . . . . . . 3.4 Detekce bezpeˇcnostních incidentu˚ . . . . . . . . . . . . 3.4.1 Bezpeˇcnostní tým CSIRT . . . . . . . . . . . . . . 3.5 Identifikace, autentizace a autorizace . . . . . . . . . . . 3.5.1 Shibboleth . . . . . . . . . . . . . . . . . . . . . . 3.6 Pˇrenos informací po síti . . . . . . . . . . . . . . . . . . 3.7 Techniky zajištˇení ochrany duvˇ ˚ erných informací . . . . 3.7.1 Hašování . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Pokroˇcilé hašování . . . . . . . . . . . . . . . . . 3.8 Android a bezpeˇcnost . . . . . . . . . . . . . . . . . . . 3.8.1 Bezpeˇcnostní problémy platformy Android . . . 3.8.2 Bezpeˇcnostní doporuˇcení na platformˇe Android Servisnˇe orientovaná architektura a webové služby . . . . 4.1 Technologie webových služeb . . . . . . . . . . . . . . . 4.2 Bezpeˇcnost webových služeb . . . . . . . . . . . . . . . Analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Analýza požadavku˚ . . . . . . . . . . . . . . . . . . . . . 5.1.1 Funkˇcní požadavky . . . . . . . . . . . . . . . . 5.1.2 Nefunkˇcní požadavky . . . . . . . . . . . . . . . 5.2 Analýza procesu údržby . . . . . . . . . . . . . . . . . . 5.2.1 Proces údržby skrze systém Archibus . . . . . . 5.2.2 Životní cyklus požadavku . . . . . . . . . . . . . 5.2.3 Identifikaˇcní kódy zaˇrízení . . . . . . . . . . . . 5.3 Analýza bezpeˇcnosti . . . . . . . . . . . . . . . . . . . . 5.3.1 Identifikace stávajících opatˇrení . . . . . . . . .
1 3 4 4 5 7 9 9 10 11 12 13 13 14 16 16 17 17 19 19 20 21 23 24 25 27 27 27 28 30 30 32 33 34 34 xi
5.3.2 Identifikace a hodnocení aktiv . . . . . 5.3.3 Identifikace hrozeb a zranitelností . . . 5.3.4 Analýza rizik . . . . . . . . . . . . . . . 5.3.5 Pˇrijetí protiopatˇrení a zbytkových rizik 5.4 Výsledky analýzy . . . . . . . . . . . . . . . . . 6 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Návrh webových služeb . . . . . . . . . . . . . 6.2 Návrh serverové cˇ ásti . . . . . . . . . . . . . . . 6.2.1 Návrh zpracování požadavku . . . . . 6.3 Návrh klientské aplikace . . . . . . . . . . . . . 6.3.1 Základní informace . . . . . . . . . . . . 6.3.2 Návrh uživatelského rozhraní . . . . . 6.3.3 Návrh mobilní aplikace . . . . . . . . . 7 Implementace . . . . . . . . . . . . . . . . . . . . . . 7.1 Prostˇredí systému Archibus . . . . . . . . . . . 7.2 Implementace integrované webové služby . . 7.3 Vývojové prostˇredí platformy Android . . . . 7.4 Implementace Android aplikace . . . . . . . . 8 Testování, nasazení a evaluace . . . . . . . . . . . . 9 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Grafické podklady . . . . . . . . . . . . . . . . . . . 11 Pˇríloha . . . . . . . . . . . . . . . . . . . . . . . . . . A Specifikace pˇrípadu˚ užití . . . . . . . . . . . . . B Analýza rizik . . . . . . . . . . . . . . . . . . .
xii
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
35 36 36 37 39 41 41 43 43 45 45 45 46 49 49 50 53 55 59 61 63 79 81 87
Seznam obrázku˚ 2.1
Tabulka výhod a nevýhod outsourcingu
5.1
Diagram pˇrípadu˚ užití 28
10.1 10.2 10.3 10.4 10.5
Porteruv ˚ diagram hodnotového rˇ etˇezce 63 Facility management: PPP 64 Analýza nákladu˚ a pˇrínosu˚ bezpeˇcnosti 64 Procesy rˇ ízení bezpeˇcnosti 65 Identifikace bezpeˇcnostních rizik pro mobilní platformy 65 Schéma reakce na bezpeˇcnostní incident 66 Tabulka cˇ asové nároˇcnosti prolomení hesla 67 Princip webových služeb 67 Architektura webových služeb 68 Schéma vytvoˇrení požadavku údržby 69 Stavový digram požadavku údržby 70 Rozbor identifikaˇcního kódu zaˇrízení 70 Detail polohového kódu zaˇrízení 71 Ukázka QR kódu 71 Diagram datových toku˚ 72 Entitnˇe relaˇcní diagram 73 Návrhový diagram tˇríd integrované služby 74 Návrhový diagram tˇríd klientské aplikace „frontend“ 75 Návrhový diagram tˇríd klientské aplikace - „backend“ cˇ ásti 76 Abstraktní sekvenˇcní diagram zpracování požadavku 77 Logo SUKB Archibus Asistent 78 Prototyp SUKB Archibus Asistent 78
10.6 10.7 10.8 10.9 10.10 10.11 10.12 10.13 10.14 10.15 10.16 10.17 10.18 10.19 10.20 10.21 10.22
6
xiii
1 Úvod V dnešní dobˇe máme pomˇernˇe rychlé tempo života, které je podpoˇreno rychlým pˇripojením k internetu umožnujícím ˇ okamžité získání informací témˇerˇ o cˇ emkoliv a výrazným technologickým posunem ve všech vˇedních oborech. Technologie jsou dnes zabudovávány do všedních vˇecí, jako jsou bˇežecké boty, brýle apod. Tento fenomén je pouze odpovˇedí na pˇrirozený požadavek technologie využívat a používat ke zlepšení mnoha aspektu˚ bˇežného života. Jedním z tˇechto pˇríkladu˚ je i zabudování mnoha technologií do budov samotných s možností ovládání a rˇ ízení ruzných ˚ atributu˚ tˇechto budov, správy majetku a monitorování potˇreb budov od výmˇeny žárovky po opravu klimatizace. Provozem, údržbou a servisem obecnˇe libovolných zaˇrízení se zabývá disciplína pojmenovaná Facility management (FM). Popis a pˇriblížení této disciplíny tvoˇrí úvodní cˇ ást práce. Na Masarykovˇe univerzitˇe nalezneme podporu FM v podobˇe systému Archibus – jedná se o jeden z nejrozšíˇrenˇejších Computer-Aided Facility Management (CAFM)1 a Total Infrastructure and Facilities Management (TIFM)2 systému˚ na svˇetˇe. Na kapitolu seznamující s FM navazují kapitoly týkající se bezpeˇcnosti a webových služeb. Další kapitoly se vˇenují jednotlivým fázím vývoje, tyto kapitoly se zaobírají i dílˇcím cílem této práce, a to vytvoˇrením profesionální aplikace pro inteligentní budovy po stránce inženýrské a implementaˇcní. Cílem práce je využít zmínˇené provázanosti technologií a bˇežných vˇecí a vytvoˇrit administrativní aplikaci pro platformu Android ke snadné údržbˇe budov MU (konkrétnˇe pro SUKB3 ) spolupracující se systémem Archibus. Pro plynulé fungování nemovitostí je nutné efektivnˇe spravovat a rˇ ídit požadavky jejich údržby. Pomocí této aplikace je možné do systému Archibus, který automatizuje všechny kroky týkající se procesu vyžádané údržby, zadávat a plánovat jednotlivé úkony údržby a aktualizovat jejich stav. Ve svém dusledku ˚ napomáhá aplikace ke snížení provozních nákladu˚ díky podílení se na procesu rˇ ízení a udržováním informací v aktuálním a dostupném 1. 2. 3.
http://www.dynamiccafm.com/computer-aided-facility-management http://www.dynamiccafm.com/total-infrastructure-facilities-management SUKB = Správa Univerzitního kampusu Bohunice
1
1. Ú VOD stavu. Navíc umožnuje ˇ zlepšit plánování a optimalizaci provozu. Aplikace je urˇcena pro Správu Univerzitního kampusu Bohunice, terénní pracovníky údržby SUKB. Aplikace bude využívat QR kódu, ˚ které budou pˇridˇeleny veškerému majetku Univerzitního kampusu. Stˇežejní bod práce je integrace podpory této terénní aplikace do systému Archibus (pomocí vlastních webových služeb) a podpora bezpeˇcnosti. Pro dosažení profesionality na úrovni inženýrské bylo použito nˇekolika ovˇerˇ ených principu, ˚ které mají za cíl, aby byl vytvoˇren spolehlivý a efektivní software pro každodenní používání. Na bezpeˇcnost je v dnešní dobˇe kladen vysoký duraz, ˚ ochrana citlivých údaju, ˚ potažmo majetku a osob, by mˇela být základním kamenem každé aplikace, ovšem mnoho aplikací pro Android toto ignoruje. S tím je spjata identifikace rizik a jejich eliminace, kterou se tato práce taktéž zabývá. Aby bylo dosaženo profesionality na úrovni programátorské, jsou použity nejnovˇejší dostupné nástroje jako Gradle pro sestavení aplikace, knihovna ZXing pro cˇ tení cˇ árových kódu˚ nebo GenyMotion emulátor pro testování. Opomenuty nejsou ani programátorské a designérské techniky, které se rˇ ídí osvˇedˇceným Android Guideline4 .
4.
2
https://developer.android.com/index.html
2 Facility Management Facility management, volnˇe pˇreloženo do cˇ eštiny jako správa zaˇrízení a budov, se zabývá rˇ ízením podpurných ˚ cˇ inností firmy, konkrétnˇe zajištˇením cˇ inností nutných pro provoz nemovitostí, budov a objektu˚ dané spoleˇcnosti. Tyto cˇ innosti jsou vedle primárního zamˇerˇ ení firmy velmi duležité ˚ a mˇely by odpovídat její technicko-provozní úrovni. Koexistence FM [Obrázek 10.1], jakožto podpurného ˚ systému k základní cˇ innosti, pˇrináší mnohá pozitiva: snížení nákladu, ˚ zeštíhlení organizaˇcní struktury, redukce poˇctu pracovníku, ˚ zvýšení kontroly, zlepšení pracovního prostˇredí a zkvalitnˇení služeb. Facility management se podle klientské orientace a odborné zpu˚ sobilosti dˇelí na dvˇe hlavní skupiny podpurných ˚ procesu: ˚ 1. „prostor, technika a infrastruktura: komerˇcní služby – nájemné, správa objektu, ˚ využití vnitˇrních prostoru; ˚ technika – údržba, energetický management, montáž a infrastruktura - ostraha, úklid, catering“ [1, str. 14] 2. „lidé a organizace: centrální servis; IT a komunikaˇcní technologie; marketingové služby; finance a úˇcetnictví; controling a reporting; právo, danˇe, audit; logistika a personální management“ [1, str. 14] Jak je vidˇet, jedná se o disciplínu, která se zabývá rozsáhlým a komplexním problémem fungování nejen inteligentních budov po všech stránkách. Tyto služby zvyšují efektivitu a výkonnost jednotlivých pracovišt’ a pracovníku. ˚ Definic toho oboru je mnoho, ale vˇetšina vychází z puvodní ˚ definice od asociace IFMA1 : „Metoda, jak v organizacích vzájemnˇe sladit pracovníky, pracovní cˇ innosti a pracovní prostˇredí, která v sobˇe zahrnuje principy obchodní administrativy, architektury, humanitních a technický vˇed.“ [2, str. 92] Tuto definici lze vyjádˇrit schématem 3P: Pracovníci, Procesy a Prostory [Obrázek 10.2], kde pruseˇ ˚ cíkem tˇechto hodnot získáme základní cíl facility managementu, provozní efektivitu.
1.
http://www.ifma.cz/, http://www.ifma.org/
3
2. FACILITY M ANAGEMENT
2.1
ˇ Norma CSN/EN 15 221
Formální základy facility managementu v Evropˇe stanovuje evropská technická norma EN 15 221, která byla pˇrevzata a je u nás oznaˇ cˇ ována jako CSN 15 221. Tato norma, která byla pˇrijata v roce 2005, ˇ ˇ pˇredstavuje FM (CSN/EN 15 221-1 Facility management – Cást 1: Termíny a definice, která má za úkol sjednocení popisu, ˚ terminologie a definic) jako „integraci cˇ inností v rámci organizace k zajištˇení a rozvoji sjednaných služeb, které podporují a zvyšují efektivitu vlastní základní cˇ innosti.“ [3, str. 8, odstavec 2.5] Je s podivem, že tyto normy vznikly až v novém tisíciletí2 , což dokazuje, že tyto podpurné ˚ procesy (noncore business) byly donedávna znaˇcnˇe opomíjené. Domnívám se, že je tomu tak pˇredevším kvuli ˚ finanˇcním duvod ˚ um, ˚ pˇritom v koneˇcném dusledku ˚ si myslím, že mají pozitivní vliv na ekonomiku podniku. Množství podpurných ˚ služeb v rámci facility managementu muže ˚ být pomˇernˇe rozsáhlé, záleží na rozhodnutí spoleˇcnosti, jaké služby a kým budou v rámci FM zajištˇeny. Není možné dopˇredu urcˇ it formu a rozsah jednotlivých cˇ inností v FM, a proto je duležité ˚ ˇ plánovat. Norma CSN/EN 15 221 rozdˇeluje plánování do tˇrí úrovní: • Strategická úrovenˇ plánování si klade za cíl dosažení stˇrednˇedobých až dlouhodobých cílu˚ v horizontu 3-5 let: celková strategie a politika FM. • Taktická úrovenˇ plánování se zamˇerˇ uje na cíle krátkodobé, výhledovˇe do jednoho roku: optimalizace zdroju, ˚ pˇrenesení podnikatelských cílu. ˚ • Provozní úrovenˇ plánování se zabývá cíli, které jsou každodenní: monitoring a reporting.
2.2
ˇ Cinnosti a jejich zajištˇení v rámci FM
Mezi hlavní úkoly facility managementu patˇrí: • správa majetku a vybavení, • provoz budov a jejich údržba, • prostorové rˇ ízení a plánování jeho využití, 2. Disciplína FM se formuje od roku 1980, první svˇetovou normou zaobírající se cˇ ásteˇcnˇe FM byla norma ISO 15686: Stavební objekty – Plánování životnosti.
4
2. FACILITY M ANAGEMENT • • • •
rˇ ízení a plánování výstaveb, rekonstrukcí a stˇehování, stanovení a kontrola dodržování pravidel a postupu, ˚ stanovení a rˇ ízení kvality prostˇredí, ochrana zdraví, bezpeˇcnosti a majetku.
Stˇežejní otázkou pˇri zajištˇení služeb v rámci facility managementu je stanovení její formy. V tomto ohledu máme základní rozdˇelení: interní forma a externí forma. V interní podobˇe je FM postaven na vedení spoleˇcnosti, které je zodpovˇedné za rˇ ízení i kontrolu podpur˚ ných procesu. ˚ V externí formˇe hraje vedení spoleˇcnosti pouze kontrolní roli, samotné zajištˇení podpurných ˚ cˇ inností je delegováno na „jinou osobu“. Pokud se jedná o nákup tˇechto služeb u jiné spoleˇcnosti zabývající se FM a zajištˇení služeb jejími pracovníky mluvíme o tzv. plném outsourcingu. Tento dodavatelský princip je v dnešní dobˇe velmi oblíben, smlouva se vˇetšinou uzavírá s jednou spoleˇcností, která dodá komplexní rozsah služeb. Taková smlouva je pomˇernˇe komplikovaná a rozsáhlá, ale pˇri jejím návrhu je možné vyˇ ˇ užít normu CSN/EN 15 221-2 Facility management – Cást 2: Pruvodce ˚ pˇrípravou FM smluv. Opaˇcným smˇerem jde tzv. plný insourcing, který je postaven na vybudování týmu vlastních pracovníku, ˚ respektive dceˇriné spoleˇcnosti dodávající rˇ ešení a starající se o služby facility managementu. Tato varianta je pomˇernˇe oblíbená u velkých firem, insourcing v takovém pˇrípadˇe bývá zjednodušován tím, že dceˇriná spoleˇcnost nakoupí vˇetšinu služeb, a ty spravuje a poskytuje mateˇrské spoleˇcnosti. Poslední mutací je kombinované zajištˇení, tedy outsourcing doplnˇený o insourcing specifických služeb. Nejˇcastˇejší volbou bývá outsourcing, duvod ˚ u˚ pro jeho zvolení je mnoho: organizaˇcní, finanˇcní nebo zamˇestnanecké. Výhody a nevýhody jsou shrnuty v následující tabulce (vloženo jako obrázek) [Obrázek 2.1].
2.3
Facility manažer
Facility manažer (provozní vedoucí) je rˇ ídící pracovník, který hraje v FM klíˇcovou roli, provádí strategická rozhodnutí a soustˇredí se na taktickou úrovenˇ plánování. V minulosti si vˇetšina tˇechto manažeru˚ 5
2. FACILITY M ANAGEMENT
Obrázek 2.1: Pˇrehledné porovnání výhod a nevýhod outsourcingu; zdroj: [1, str. 63].
6
2. FACILITY M ANAGEMENT ani neuvˇedomovala svoji pˇríslušnost k této profesi. Obvykle se jednalo o správce majetku, správce budov nebo správce administrativy. S postupem cˇ asu a nástupem FM tato pozice nabývala na významu a dnes již nejde pouze o správce, ale i „politika“, který musí umˇet jednat s lidmi.
2.4
Computer Aided Facility Management
Computer Aided Facility Management (CAFM) je software pro podporu facility managementu. Moderní inteligentní budovy mají mnoho senzoru˚ a cˇ idel, které tvoˇrí komplexní technologický celek. Aby je bylo možno ovládat a efektivnˇe využít, existuje mnoho aplikací pro správu a provoz budov. Na naší univerzitˇe je to modulární software Archibus. Archibus je rozsáhlý program, který podporuje všechny cˇ innosti organizace spojené s rˇ ízením, plánováním, správou a údržbou veškerého majetku. Z pohledu této práce je klíˇcový modul pro údržbu budov a její plánování. Právˇe do tohoto modulu je integrována podpora pro naši terénní aplikaci v podobˇe webových služeb. Správa majetku vyžaduje v prubˇ ˚ ehu cˇ asu vysoké finanˇcní prostˇredky a je významnou souˇcástí životního cyklu budov. Bez koncepce údržby a aktuálních dat je zpravidla údržba provozu pˇredražená. Pro minimalizaci prostˇredku˚ je nutné zachytit souˇcasný stav objektu, k cˇ emuž dopomáhá naše aplikace, a na tomto základˇe stanovit a optimalizovat samotnou cˇ innost údržby.
7
3 Bezpeˇcnost Bezpeˇcnost je klíˇcový obor informatiky, který se prolíná všemi technologiemi a úrovnˇemi IT – od bezpeˇcného ukládání dat pˇres zabezpeˇcenou komunikaci po ovˇerˇ ené manipulování s daty. V dnešní dobˇe je kladen vysoký duraz ˚ na ochranu kritických dat a pravdou je, že míra bezpeˇcnosti, vynaložené úsilí a prostˇredky by mˇely odpovídat bezpeˇcnostní úrovni obsahu [Obrázek 10.3]. Je totiž reálné, že s vyšší úrovní bezpeˇcnosti se dostaneme do konfliktu s výkonností aplikace a jinými vlastnostmi. Duležité ˚ je správné vyhodnocení bezpeˇcnostních rizik a vyvážený návrh aplikace v jejích ruznorodých ˚ atributech. Pro úvodní vhled do problematiky bezpeˇcnosti bylo využito duvˇ ˚ eryhodného a ovˇerˇ eného webu [4]. Bezpeˇcnost aplikací lze vnímat z hlediska bezpeˇcí (safety) anebo zabezpeˇcení (security). Bezpeˇcí znamená, že aplikace bude zpusobilá ˚ k pˇredcházení nehodám a nezpusobí ˚ zranˇení lidem, zvíˇratum ˚ nebo škody na majetku a na životním prostˇredí. Zabezpeˇcení znamená, že aplikace bude odolná vuˇ ˚ ci kriminálním aktivitám, kdy dochází k útokum ˚ pasivním („pouze“ zjištˇení informací) a aktivním (zmˇena informací).
3.1
Základní pojmy bezpeˇcnosti
Pojmy jako kryptografie cˇ i kryptologie jsou velmi rozšíˇrené a používané. Kryptografie (z rˇ eckého kryptós = skrytý a gráph = psaní) neboli šifrování je všude okolo nás, aniž bychom si to uvˇedomovali. Jedná se o vˇedeckou disciplínu, která má za úkol pˇrevod zpráv do podoby, jež je cˇ itelná jen se speciální znalostí. Kryptografie nám dává prostˇredek k získání: a) duvˇ ˚ ernosti – pˇrístup k informacím nesmí mít nikdo, kdo nemá oprávnˇení, b) integrity – informace nesmí být upravena nˇekým, kdo nemá oprávnˇení, c) autentifikace – je jasnˇe patrné, kdo je autorem informace.
9
ˇ 3. B EZPE CNOST
Opakem je kryptoanalýza (z rˇ eckého kryptós = skrytý a analýein = uvolnit), také se jedná o vˇedeckou disciplínu, která se snaží získat obsah šifrovaných informací bez pˇrístupu k tajným informacím, jež jsou za normálních okolností potˇreba. Kryptologie je pak vˇední obor, který se zabývá studiem bezpeˇcnosti, integrity dat, jejich pˇrenosem, autentifikací, tvorbou a prolomením šifer ap. Pod kryptologii spadají zmínˇené disciplíny kryptografie a kryptoanalýza. Mezi další duležité ˚ pojmy kryptologie patˇrí: • šifrování (encryption) je proces pˇrevedení informace na její necˇ itelnou podobu, • klíˇc (key) je tajná informace, bez níž nelze šifrovanou informaci pˇreˇcíst, • symetrická šifra (symmetric cipher) je taková, která pro šifrování i dešifrování (decryption) používá stejný klíˇc (napˇr. AES nebo 3DES), • asymetrická šifra (asymmetric cipher) používá veˇrejný klíˇc (public key) pro šifrování a soukromý klíˇc (private key) pro dešifrování (napˇr. RSA), • hašovací funkce (hash function) je zpusob, ˚ jak z celého textu vytvoˇrit krátký rˇ etˇezec, který jednoznaˇcnˇe identifikuje puvodní ˚ text (napˇr. MD5 nebo SHA).
3.2
Bezpeˇcnostní politika
V oblasti bezpeˇcnosti je zavedeno mnoho norem pro vymezení a vyjasnˇení postupu˚ a používaných pojmu. ˚ Z hlediska bezpeˇcnosti je pro jakoukoliv organizaci nejduležitˇ ˚ ejší definice bezpeˇcnostní politiky, která standardy, postupy a principy pˇretváˇrí v reálný rámec informaˇcní bezpeˇcnosti organizace. Bezpeˇcnostní politika organizace tvoˇrí jeden z jejích základních pilíˇru, ˚ pokud není oficiálním zpuso˚ bem jednoznaˇcnˇe definována základní strategie a cíle bezpeˇcnosti, odpovˇednosti a postoje klíˇcových rolí a zamˇestnancu˚ organizace, muže ˚ být následnˇe celý systém chaotický, neefektivní a neúˇcelný. ˇ Technické normy (i bezpeˇcnostní) v prostˇredí Ceské republiky jsou v pusobnosti ˚ (tvorba, vydávání, distribuce) Úˇradu pro technickou normalizaci, metrologii a státní zkušebnictví (ÚNMZ). Tento ˇ úˇrad byl „zˇrízen zákonem Ceské národní rady cˇ . 20/1993 Sb. o zabezpeˇcení 10
ˇ 3. B EZPE CNOST
výkonu státní správy v oblasti technické normalizace, metrologie a státního zkušebnictví. ÚNMZ je organizaˇcní složkou státu v resortu Ministerstva ˇ Hlavním posláním ÚNMZ je zabezpeˇcovat úkoly prumyslu ˚ a obchodu CR. ˇ vyplývající ze zákonu˚ Ceské republiky upravujících technickou normalizaci, metrologii a státní zkušebnictví a úkoly v oblasti technických pˇredpisu˚ a noˇ v Evropské unii. Od roku 2009 zarem uplatnovaných ˇ v rámci cˇ lenství CR jišt’uje také tvorbu a vydávání cˇ eských technických norem.“. [5] Standardy, které se pˇrímo týkají bezpeˇcnosti, jsou vyjmenovány v rozšiˇrující literatuˇre: ˇ • „CSN ISO/IEC 27000:2010 Informaˇcní technologie Bezpeˇcnostní techniky - Systémy rˇízení bezpeˇcnosti informací Pˇrehled a slovník ˇ • CSN ISO/IEC 27001:2006 Informaˇcní technologie Bezpeˇcnostní techniky - Systémy managementu bezpeˇcnosti informací – Požadavky ˇ • CSN ISO/IEC 17799:2006 (oprava ISO/IEC 27002 vydána v roce 2008) Informaˇcní technologie - Bezpeˇcnostní techniky Soubor postupu˚ pro management bezpeˇcnosti informací ˇ • CSN ISO/IEC 27004:2011 Informaˇcní technologie ˇ Bezpeˇcnostní techniky - Rízení bezpeˇcnosti informací - Mˇerˇení ˇ • CSN ISO/IEC 27005:2009 Informaˇcní technologie ˇ Bezpeˇcnostní techniky - Rízení rizik bezpeˇcnosti informací ˇ • CSN ISO/IEC 27006:2008 Informaˇcní technologie Bezpeˇcnostní techniky - Požadavky na orgány provádˇející audit a certifikaci systému˚ rˇízení bezpeˇcnosti informací“ [6, str. 1]
3.2.1 Proces rˇízení bezpeˇcnosti Definice bezpeˇcnostní politiky, cílu˚ a požadavku˚ je hlavním, nikoˇ liv jediným, krokem k rˇ ízení bezpeˇcnosti informací v organizaci. Rízení bezpeˇcnosti se skládá z nˇekolika na sebe navazujících procesu˚ [Obrázek 10.4]. Pˇri implementaci bezpeˇcnosti je nutné brát zˇretel na prevenci, detekci a nápravu. Pˇri prevenci se analyzují a vyhodnocují možná bezpeˇcnostní rizika a následnˇe se eliminují, abychom snížili poˇcet hrozeb a pˇredcházeli jim. Detekce je další duležitou ˚ složkou, pokud již dojde k porušení bezpeˇcnosti, je nutné se o tom dozvˇedˇet a odhalit neoprávnˇené cˇ innosti a slabá místa, která následnˇe od11
ˇ 3. B EZPE CNOST
straníme (náprava). Událost detekce porušení bezpeˇcnosti se nazývá bezpeˇcnostní incident, a to z duvodu ˚ narušení duvˇ ˚ ernosti, integrity nebo dostupnosti informace v systému v dusledku ˚ selhání nebo nedostateˇcných bezpeˇcnostních opatˇrení.
3.3
Analýza bezpeˇcnostních rizik
Bezpeˇcnostní analýza rizik slouží k vˇcasné identifikaci vnˇejších hrozeb a rizik, zmenšení zranitelnosti a snížení možných negativních dopadu˚ útoku. Pokud se zaobíráme bezpeˇcnostní analýzou, je dobré pˇriblížit si používanou terminologii, která je také souˇcástí zmínˇených standardu: ˚ • Základní pˇrístup – neprovádí se analýza rizik, pouze dojde k implementaci základních opatˇrení a doporuˇcení. • Neformální pˇrístup – provádí se rychlá a „jednoduchá“ analýza rizik, velmi pragmatický pˇrístup vycházející z praxe. • Formální pˇrístup – provádí se základní cˇ innosti: urˇcení a ohodnocení prostˇredku˚ (aktiv), sovisejících hrozeb a zranitelností. Tato analýza rizik se vyznaˇcuje vyšší mírou detailnosti. • Kombinovaný pˇrístup – provádí se základní (u ménˇe kritických aktiv) i pokroˇcilá (u více duležitých ˚ aktiv) analýza rizik. Vzhledem k velikosti naší aplikace je postaˇcující a vhodný neformální pˇrístup, vytvoˇrení pˇrípadové studie a implementace základních opatˇrení. K identifikaci rizik je využit i široce uznávaný projekt Open Web Application Security Project (OWASP). Tento projekt vydává dokument OWASP Top 10, který poskytuje ucelené informace o aktuálních hrozbách a bezpeˇcnostních chybách pˇredevším v zabezpecˇ ení webových aplikací. [7] S technologickým posunem a rozšíˇrením chytrých mobilních zaˇrízení pˇrirozenˇe vzrostla potˇreba zabezpeˇcení mobilních aplikací. Na to zareagoval i OWASP a vytvoˇril pˇridružený projekt OWASP Mobile Security Project1 . Cílem projektu je klasifikovat bezpeˇcnostní rizika mobilních aplikací [Obrázek 10.5] a upozornit na jejich dopad. Výsledkem je zásadní dokument popisující tato rizika OWASP Top 10 Mobile Risks. Z uvedených hrozeb je vidˇet, že 1.
12
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
ˇ 3. B EZPE CNOST
problémy mohou být jak na stranˇe mobilní aplikace, tak na stranˇe serveru poskytujícího vˇetšinou podstatnou cˇ ást aplikaˇcní logiky.
3.4
Detekce bezpeˇcnostních incidentu˚
Detekce porušení bezpeˇcnostních opatˇrení muže ˚ být automatická pomocí monitorovacího systému nebo manuální. Pro rˇ ízení procesu bezpeˇcnostního incidentu2 by mˇela být urˇcena zodpovˇedná osoba cˇ i tým, který má na starosti pˇríjem, evidenci a rˇ ešení tˇechto událostí. Pro adekvátní a rychlou reakci na vzniklé problémy [Obrázek 10.6] by mˇely být tyto údaje souˇcástí bezpeˇcnostní politiky spoleˇcnosti. Na detekci pˇrirozenˇe navazuje náprava vzniklých škod a provedení opatˇrení k tomu aby se incident neopakoval. Pˇri rˇ ešení incidentu je dobré mít implementované autentizaˇcní a autorizaˇcní mechanismy, které jsou vhodnˇe doplnˇené logováním, aby bylo jasnˇe vidˇet kdo, kdy, kde, jak a co se pokoušel. 3.4.1 Bezpeˇcnostní tým CSIRT Právˇe pro tyto úˇcely byl na Masarykovˇe univerzitˇe, konkrétnˇe na Ústavu výpoˇcetní techniky, zˇrízen akademický bezpeˇcnostní tým CSIRT-MU3 , který se zabývá detekcí a rˇ ešením bezpeˇcnostních incidentu˚ v univerzitní poˇcítaˇcové síti, v níž je provoz aplikace provádˇen. Mimo svou primární cˇ innost se tým aktivnˇe podílí na prevenci a osvˇetˇe v oblasti bezpeˇcnosti a bezpeˇcnostních rizik. Tým provozuje pro veˇrejnost informaˇcnˇe-nauˇcný web4 , je souˇcástí mnoha výzkumných projektu˚ a spolupracuje napˇríklad s Národním bezpeˇcnostním úˇradem5 . Nemalé úsilí tento bezpeˇcnostní tým vkládá do vytváˇrení vlastních bezpeˇcnostních nástroju˚ a modulu˚ pro monitorování a detekci rˇ ady hrozeb. Z hlediska našeho projektu je postaˇcující fakt kontroly cˇ innosti v síti MU a pˇrípadné hlášení narušení bezpeˇcnosti pracovníkem SUKB. 2. Proces rˇ ízení bezpeˇcnostních incidentu˚ je popsán v mezinárodní normˇe ISO/IEC TR 18044. 3. http://www.muni.cz/ics/services/csirt?lang=cs 4. https://security.ics.muni.cz/ 5. http://www.nbu.cz/cs/
13
ˇ 3. B EZPE CNOST
3.5
Identifikace, autentizace a autorizace
Text související s technikami stanovení identifikace, pˇrenosu informací a zajištˇení ochrany duvˇ ˚ erných informací vychází, pokud není uvedeno jinak, z knihy [8] a absolvovaných pˇredmˇetu˚ u p. profesora V. Matyáše ([9] a [10]). Identifikace (též vyhledávání) a autentizace (též verifikace) slouží k jednoznaˇcnému stanovení identity uživatele. Cílem tˇechto metod je zajistit, aby systém vˇedˇel, s kým komunikuje. Rozdíl je v tom, že: • „identifikace uživatele je proces urˇcení identity (totožnosti) uživatele. . . “ [8, str. 9], kdy systém sám urˇcuje a zjišt’uje, kdo je onou osobou (prochází všechny záznamy) a zda má povolení k pˇrístupu a • „autentizace uživatele je proces ovˇerˇování identity. . . “ [8, str. 9], kdy uživatel pˇredkládá svou identitu, kterou doplnuje ˇ informací, cˇ ímž umožní ovˇerˇ ení. Autentizovat však mužeme ˚ i data – ovˇerˇ ení jejich puvodu. ˚ V tomto pˇrípadˇe ovˇerˇujeme, že data jsou autentická, tj. že známe autora cˇ i odesílatele daných dat. Autentizace dat do znaˇcné míry souvisí s ovˇerˇením integrity.“ [8, str. 9] Dalším duležitým ˚ pojmem je autorizace. „Autorizace uživatele je proces pˇriˇrazení oprávnˇení (na základˇe identity a bezpeˇcnostní politiky) pro práci v systému a specifikuje, co daný uživatel muže, ˚ pˇríp. nemuže. ˚ Jedná se o proces, který obvykle následuje po autentizaci.“ [8, str. 9] Implementace autentizaˇcních a autorizaˇcních mechanismu˚ je nezbytná pro potˇreby sledování zmˇen a rˇ ešení pˇrípadných bezpeˇcnostních incidentu. ˚ Používají se tyto základní metody pro provedení autentizace: • podle toho, co uživatel zná (heslo. . . ), • podle toho, co uživatel má (klíˇcenka. . . ), • podle toho, cˇ ím uživatel je (otisk prstu. . . ). V souˇcasné dobˇe je nejjednodušší a nejpoužívanˇejší autentizace pomocí kombinace jméno a heslo. Heslo typicky bývá rˇ etˇezec dlouhý 6-10 znaku, ˚ v ideálním pˇrípadˇe netriviální. Existuje nˇekolik rozšírˇ ených útoku˚ na získání duvˇ ˚ erných informací, jako je heslo: útok 14
ˇ 3. B EZPE CNOST
hrubou silou (brute force attack), slovníkový útok (dictionary attack), rainbow table attack (rainbow table je oznaˇcení pro rozsáhlou tabulku s pˇredem vypoˇcítanými hodnotami hašovací funkce, tato tabulka dále slouží jako zdroj útoku hrubou silou), phishing (velmi jednoduchý založený na vylákání duvˇ ˚ erných informací pˇrímo od uživatele vˇetšinou ve formˇe emailu, jenž se tváˇrí jako seriózní od služby, kterou uživatel aktivnˇe využívá) a sociální útok (social-knowledge attack; hesla bývají založena na vˇecech okolo nás - jména dˇetí, datum narození, SPZ auta). Základní obrana je podobnˇe jako útoky jednoduchá, hesla by nemˇela vycházet z vašich osobních údaju, ˚ dále by mˇelo být samozˇrejmostí nesdˇelovat osobní informace nepovolaným lidem. Z technického hlediska prodlužovat cˇ asové odezvy mezi pokusy cˇ i zablokovat úˇcet po nˇekolika nepovedených pokusech. Aˇc si to mnozí uživatelé neuvˇedomují, používání autentizace a autorizace má významné dusledky. ˚ Identita, kterou pˇredkládáme, je použita pro identifikaci manipulace s daty a akcemi provádˇenými v systému. Pokud dojde k zneužití tˇechto dat, právˇe uživatel, který je urˇcen jako (spolu)pachatel, nese odpovˇednost a spoluvinu za zpuso˚ bené škody. Dusledky ˚ narušení bezpeˇcnosti, pˇrípadnˇe integrity, mohou mít i osobní dopad, napˇr. vykradení bankovního úˇctu. Jak ukázal velký únik uživatelských dat spoleˇcnosti Adobe v roce 20136 , mnoho uživatelu˚ používalo triviální hesla typu „654321“ cˇ i „12“ a dokonce 1,9 milionu uživatelu˚ heslo „123456“. Nejradˇeji bychom vyžadovali silná neuhodnutelná hesla [Obrázek 10.7], která jsou jednoduše zapamatovatelná. Tuto možnost nám dává metoda ulehˇcující zapamatování tzv. mnemotechnika, konkrétnˇe mnemotechnická pomucka ˚ napˇríklad ve formˇe fráze cˇ i rˇ íkanky7 . Nutno podotknout, že na Masarykovˇe univerzitˇe je úrovenˇ hesel peˇclivˇe hlídaná.
6. Dostupné online www.theguardian.com/technology/2013/nov/07/adobe-password-leak-cancheck. 7. Pˇríklad mnemotechnické fráze pro vytvoˇrení silného hesla - Máma mele maso, maso je z Míly, Míla mokvá v míse, Ema Mílu solí: MmmmjMMmmEMs.
15
ˇ 3. B EZPE CNOST
3.5.1 Shibboleth Masarykova univerzita provozuje rozsáhlou organizaˇcní vnitˇrní sít’ pro studenty a své zamˇestnance, která obsahuje bezpoˇcet fakultních a univerzitních systému. ˚ Pro úˇcely autentizace a sjednocení autentizaˇcního schématu do tˇechto systému˚ používá Masarykova univerzita open-source softwarový modul Shibboleth8 . Dle dostupných informací je Shibboleth založen na standardu OASIS Security Assertion Markup Language9 (SAML). Samotný modul poskytuje jednoduché webové rozhraní pro pˇrihlášení do organizaˇcní sítˇe tzv. Single Sign-on (SSO) a podporuje pouˇ žití univerzitních pˇrihlašovacích údaju, ˚ tedy kombinace UCO a sekundární heslo. Tyto informace jsou pak vázány k provádˇené cˇ innosti. V kontextu facility managementu a softwaru Archibus ovšem Shibboleth nalezneme pouze okrajovˇe, jedná se totiž o samostatný systém v rámci SUKB zakoupený Masarykovou univerzitou s vlastním autentizaˇcním schématem, které je reflektováno pˇri autentizaci v terénní aplikaci - Shibboleth se v systému Archibus používá pˇri práci z poˇcítaˇce. Toto schéma obsahuje následující body: a) Zobrazení pˇrihlašovacího dialogu. b) Zadání pˇrihlašovacích údaju˚ (jméno/heslo). Tyto údaje ˇ implicitnˇe nejsou shodné s informacemi jako UCO, primární a sekundární heslo. c) Naˇctení UserAccount objektu z databáze (tabulka afm_users) pro zadané jméno. d) Porovnání zadaného hesla s uloženým heslem a pˇrípadnˇe provedení autentizace. e) Použití tˇechto informací pro autorizaci operací.
3.6
Pˇrenos informací po síti
Vˇetšina dnešních mobilních aplikací komunikuje pˇres sít’ a i autentizace do systému bývá provádˇena mimo mobilní telefon, ovšem tento pˇrenos citlivých informací tvoˇrí základní problém komunikace. V podstatˇe nelze poslat heslo nešifrované – lze ho jednoduše odpo8. 9.
16
https://shibboleth.net/ https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
ˇ 3. B EZPE CNOST
slechnout, proto je využito šifrovaného pˇrenosu, kde existuje rˇ ada algoritmu˚ pro jeho provedení. V naší aplikaci využíváme šifrovaný protokol HTTP, tedy HTTPS, kdy samotná komunikace je pomocí HTTP, ale pˇrenášené informace jsou šifrovány protokolem TLS/SSL. Protokol HTTPS využívá asymetrické šifrování. Pˇred zahájením komunikace dochází k vygenerování klíˇcu˚ (privátní a veˇrejný). Pˇri inicializaci komunikace dojde k výmˇenˇe veˇrejných klíˇcu, ˚ tento verˇ ejný klíˇc by mˇel být ovˇerˇ en u certifikaˇcní autority, abychom vˇedˇeli, že protistranˇe mužeme ˚ duvˇ ˚ erˇ ovat. Po této zahajovací proceduˇre dochází k samotnému pˇrenosu informací. Takto šifrované informace jsou ochránˇeny pˇred odposloucháváním, bez ovˇerˇ ení autenticity verˇ ejných klíˇcu˚ jsou komunikující strany vystaveny riziku útoku Man in the middle10 .
3.7
Techniky zajištˇení ochrany duvˇ ˚ erných informací
Mimo zabezpeˇcenou komunikaci je duležitou ˚ souˇcástí zpracování duvˇ ˚ erných informací i správné ukládání se zajištˇením dostateˇcné ochrany, tato cˇ ást opˇet tˇeží z informací z knihy [8] a absolvovaných pˇredmˇetu˚ u p. profesora V. Matyáše ([9] a [10]). Perzistence dat je klíˇcová složka každého systému, tajné informace, jako je heslo, principiálnˇe nelze ukládat v cˇ itelném tvaru. Jen pˇri dodržení urˇcité úrovnˇe kryptografie máme zaruˇceno, že pˇri pru˚ niku do našeho systému a ztrátˇe záznamu cˇ i souboru nemá útoˇcník šanci informace použít – k dané informaci má pˇrístup pouze oprávnˇená osoba s potˇrebnou informací. 3.7.1 Hašování Z praktického hlediska se šifrování používá pˇrevážnˇe pro ucelené kusy dat, jako je soubor nebo celý pevný disk. Pokud chceme napˇríklad do databáze uložit hodnotu v neˇcitelném tvaru, jako je heslo, použijeme techniku hašování (hashing). Tato technika je založena na kryptografické hašovací funkci (hash function), výsledkem této funkce je otisk (hash; haš), který je jednoznaˇcným identifikátorem libovolnˇe dlouhého vstupu této funkce. V koneˇcném dusledku ˚ prove10. https://www.owasp.org/index.php/Man-in-the-middle_attack
17
ˇ 3. B EZPE CNOST
deme uložení vzniklého otisku namísto puvodní ˚ hodnoty. Pro bezpeˇcné použití vyžadujeme následující vlastnosti hašovací funkce: a) jednosmˇernost je definovaná jako odolnost vuˇ ˚ ci získání puvodního ˚ textu tj. neexistuje inverzní algoritmus, b) bezkoliznost se vyznaˇcuje tím, že nepopíráme existenci kolizní dvojice ruzných ˚ vstupných dat, které mají stejný otisk, ale je velmi komplikované je najít. Zpusob ˚ u˚ hašování je mnoho, mezi nejˇcastˇejší patˇrí použití ovˇerˇ ených hašovacích funkcí MD5 nebo SHA. MD5 (Message-Digest algorithm 5) je jednou z nejznámˇejších hašovacích funkcí vubec, ˚ má 128 bitový otisk a i pˇres odhalení chyb (již není považovaná za bezpeˇcnou) je široce používaná, a to pˇredevším ke kontrolním souˇctum ˚ (checksum), tj. pˇrenášená data byla doruˇcena neporušena. [11] SHA (Secure Hash Algorithm) je sumární oznaˇcení pro rodinu pˇeti hašovacích funkcí: SHA-1, SHA-224, SHA-256, SHA-384 a SHA-512 (poslední cˇ tyˇri jsou oznaˇcovány jako SHA-2). SHA-1 vytváˇrí 160 bitový otisk, u ostatních je poˇcet bitu˚ výsledného otisku udán v názvu. Algoritmus SHA-1 je dnes již prolomen a nepoužíván, zato SHA-2 definované ve standardu FIPS 180-211 doposud nebyly kompromitovány a jsou vhodnou volbou pro použití. Ovšem použití pouze hašovací funkce se nedoporuˇcuje už jen z duvodu ˚ existence útoku rainbow table attack. Zmínˇená norma FIPS 140 definuje cˇ tyˇri úrovnˇe zabezpeˇcení a zárovenˇ pokrývá široké spektrum použitelných kryptografických algoritmu. ˚ Výhodou FIPS standardu je specifikování schválených, tudíž i bezpeˇcných algoritmu˚ a urˇcuje jistou úrovenˇ zabezpeˇcení podle Common Criteria (CC). „Common Criteria – mezinárodní kritéria ohodnocení IT bezpeˇcnosti. Standard FIPS se opírá o CC všude tam, kde je vyžadována validace funkˇcních vlastností.“ [8, str. 41] Zvýšení bezpeˇcnosti generovaných otisku˚ pˇrináší technika známá jako solení (salting). Vzniklý haš není pouze otiskem hesla, ale i dodateˇcné náhodné informace nazývané sul ˚ (salt). Zpusob ˚ vytvorˇ ení soli je cˇ istˇe v pravomoci programátora, typicky se jedná o soubor náhodných znaku, ˚ které se ukládají spolu s otiskem (napˇr. ve tvaru 11. Dostupné online: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf.
18
ˇ 3. B EZPE CNOST
$1$sul$otisk). ˚ Pˇridanou hodnotou této techniky je fakt, že pˇri použití ruzné ˚ soli na stejná hesla získáme ruzné ˚ otisky. Další zpusobem, ˚ jak ztížit pokus o prolomení hašování, je použití pomalé hašovací funkce. V kombinaci soli s robustní hašovací funkcí získáme rozmˇerný, ne však nekoneˇcný poˇcet kombinací, pˇri použití pomalé hašovací funkce dojde k výraznému nárustu ˚ cˇ asu potˇrebnému k vyzkoušení tˇechto kombinací, napˇr. pro vygenerování rainbow table. Pro další zvýšení bezpeˇcnosti je možné použít kombinaci nˇekolika hašovacích funkcí dohromady, s použitím soli vznikne tak pomˇernˇe složitý otisk k inverznímu zpracování. Systém Archibus umožnuje ˇ pro ukládání hesel využití právˇe zmínˇených principu˚ nebo použití interního objektu PasswordEncoderVersion2Impl urˇceného k šifrování hesel. 3.7.2 Pokroˇcilé hašování Pokud bychom se nespokojili s dosavadním rˇ ešením, je možné využít pokroˇcilých kryptografických funkcí, jako je PBKDF2, BCRYPT a další. Napˇríklad kryptografická funkce PBKDF2 (Password Based Key Derivation Function) použitím soli zabranuje ˇ slovníkovému útoku a tzv. stretching (natažení délky hesla) útoku hrubou silou. Tím se stává vhodným prostˇredkem pro použití v autentizaˇcním schématu. PBKDF212 funguje tak, že generuje klíˇc (derived key, DK) o požadované délce (derived key length, dkLen) z hesla (P) zadaného uživatelem a soli (S) libovolné délky, a to opakovaným voláním (iteration count, c) pseudonáhodné funkce (PRF), jejímž výstupem je haš o urcˇ ité délce (hash length, hLen). Velikost používané soli a poˇcet iterací závisí na programátorovi a mˇela by odpovídat složitosti zadávaných hesel a výkonnostním možnostem HW, protože výpoˇcet klíˇce trvá urˇcitou dobu a zatˇežuje procesor.
3.8
Android a bezpeˇcnost
Informace použité v této cˇ ásti vychází z [12]. Android je velice oblíbená a známá znaˇcka operaˇcního systému, kterou podle dat z polo12. Vzorec pro generování klíˇce pomocí PBKDF2: DK = PBKDF2 (PRF, P, S, c, dkLen); RFC2898 - http://tools.ietf.org/html/rfc2898.
19
ˇ 3. B EZPE CNOST
viny roku 2014 aktivnˇe využívá jedna miliarda uživatelu˚ 13 . Své uživatele láká na vzhled, jednoduché ovládání, velkou škálu levných cˇ i bezplatných aplikací, hudbu, filmy a knihy, které nalezneme v obchodˇe Google Play. Z hlediska marketingového se jedná o systém volnˇe šiˇritelný, který není striktnˇe vázán na urˇcitou znaˇcku cˇ i výrobce mobilních zaˇrízení. Tyto aspekty dˇelají z platformy Android nejmasovˇejší operaˇcní systém vubec. ˚ Vlastní Android je postaven na linuxovém jádˇre, je pomˇernˇe nenároˇcný, a proto jej nalezneme i na low-end zaˇrízeních. Pokud Android srovnáme s platformou iOS, kde existuje jediný subjekt vystupující jako centrální autorita, spoleˇcnost Apple, zjistíme propastný rozdíl. Tato firma jasnˇe stanovuje a hlavnˇe vyžaduje plnˇení kvalitativních standardu˚ v rámci bezpeˇcnosti, vzhledu, ovládání a chování mobilních zaˇrízení a aplikací. Spoleˇcnost Google, která stojí za vývojem platformy Android je v tomto ohledu daleko benevolentnˇejší a pˇres jistá naˇrízení, pˇredevším ohlednˇe obsahu aplikace, rˇ eší tuto situaci sérií doporuˇcení ve formˇe Developer’s Guidelines. Na mobilní zaˇrízení jsou pak kladeny pouze minimální požadavky. 3.8.1 Bezpeˇcnostní problémy platformy Android Absence exekutivního vyžadování doporuˇcení a roztˇríštˇení zodpovˇednosti vede k tomu, že platforma Android muže ˚ být považována za nebezpeˇcnou. Toto potvrzují i ruzné ˚ studie a výzkumy zabývající se touto problematikou. V roce 2012 byl proveden spoleˇcností Bit914 výzkum bezpeˇcnosti aplikací vystavených na Google Play. Analyzováno bylo tehdy více než 400 000 aplikací, výsledky byly pozoruhodnˇe špatné [13], 25% (více než 100 000) aplikací bylo klasifikováno jako neduvˇ ˚ eryhodných nebo problematických. Tyto aplikace pˇredstavovaly bezpeˇcnostní riziko pro uživatele, nejednalo se však o pˇrímé nebezpeˇcí (škodlivý kód). Hodnocen byl potenciál nebezpeˇcí: vyžadovaná oprávnˇení pˇri instalaci, stahovaný objem dat z internetu pˇri používání, zpusob ˚ nakládání s informacemi atd. Zavádˇející je zjištˇení, že 42 procent aplikací využívá pˇrístup k aktuální poloze uživatele vˇcetnˇe takových jako spoˇriˇc obrazovky, 31 procent 13. http://www.engadget.com/2014/06/25/google-io-2014-by-the-numbers/ 14. https://www.bit9.com/
20
ˇ 3. B EZPE CNOST
aplikací pˇristupuje k telefonnímu adresáˇri nebo výpisu hovoru˚ a 26 procent k osobním údajum, ˚ jako je e-mail. [13] Slabá úrovenˇ bezpeˇcnosti a kvality aplikací má dopad na renomé platformy Android. Odborníci se shodují, že aktuální nejvˇetší slabina systému Android tkví ve schvalování požadovaných oprávnˇení pˇri instalaci aplikace. Uživatel je postaven pˇred jasnou volbu „ber nebo nech být“. Není pochyb, že urˇcitá oprávnˇení jsou potˇrebná pro správný provoz aplikace, ovšem v mnoha pˇrípadech tomu tak není a lidé, kteˇrí dlouhý seznam ani neˇctou, ho bezmyšlenkovitˇe odsouhlasí. Tím poskytují pˇrístup ke svým soukromým údajum ˚ a vystavují se bezpeˇcnostnímu riziku. To potvrzuje i výzkum Bit9 [13], kdy plných 72 procent aplikací pro Android (cca 290 000) požadovalo nejménˇe jedno nebezpeˇcné oprávnˇení (high-risk permisssion). Samotná spoleˇcnost Google si toto uvˇedomuje a od verze 4.3 zkouší v rámci nového správce oprávnˇení umožnit uživatelum ˚ tzv. selective permission, tj. umožnit dodateˇcnˇe omezit udˇelená práva. Nevýhodou omezování pˇrístupových práv jsou možné pády aplikací.
3.8.2 Bezpeˇcnostní doporuˇcení na platformˇe Android Standardní bezpeˇcnostní protokol na platformˇe Android je tvoˇren sadou doporuˇcení a nástrojem ProGuard. Navíc je instalaˇcní balíˇcek (.apk) podepsán privátním klíˇcem vývojáˇre, který je kontrolován spoleˇcností Google pˇri vložení aplikace do oficiálního obchodu Google Play. Pˇri aktualizaci aplikace je nutné, aby se podpis shodoval s podpisem dˇríve vloženého balíˇcku. Naše aplikace bude používána výluˇcnˇe na akademické pudˇ ˚ e a nebude umístˇena v tomto obchodˇe. Doporuˇcení se vážou pˇredevším k uchovávání citlivých dat. Za velké riziko se považuje ukládání tˇechto dat na SD kartu. Tˇemto pˇrípadum ˚ by se mˇelo pˇredcházet, a pokud je potˇreba použít interní úložištˇe, tak použít privátní mód (Context.MODE_PRIVATE). Pro pˇrenos citlivých údaju˚ v rámci systému by se nemˇel používat Broadcast ani Intent. Citlivé informace by se mˇely zašifrovat a nemˇely by se logovat. Pro jejich pˇrenos po síti by mˇelo být využito TLS nebo SSL, tedy HTTPS spojení. Služby (Service) by mˇely být ošetˇreny pomocí oprávnˇení a veškeré služby/aktivity, které jsou pouze pro vnitˇrní využití, by mˇely mít nastaven pˇríznak vystavení (exposed flag) na „false“. 21
ˇ 3. B EZPE CNOST
ProGuard15 je nástroj, který slouží k zmenšení, optimalizaci a odstranˇení nepoužitého kódu. Výsledkem je menší velikost finálního souboru (.apk), který je obtížnˇeji analyzovatelný reverzním inženýrstvím. Je duležité, ˚ aby byl použit, pokud aplikace využívá funkce, které jsou citlivé na bezpeˇcnost. Provádí proceduru obfuskace (obfuscate), tedy „zaˇcernˇení“ zdrojového kódu tím, že odstraní komentáˇre, mezery a formátování kódu. Dále pˇrejmenuje promˇenné, metody, tˇrídy, pˇrípadnˇe provede jejich rozdˇelení tak, aby se zdrojový kód stal neˇcitelný, literatura uvádí, že tato procedura odradí 99% útoˇcníku. ˚
15. http://developer.android.com/tools/help/proguard.html
22
4 Servisnˇe orientovaná architektura a webové služby Text v této sekci vˇenované servisnˇe orientované architektuˇre a webovým službám vychází z knih [15], [14] a specifikace webových služeb od konsorcia W3C – Web Services Architecture [18]. Servisnˇe orientovaná architektura (Service-Oriented Architecture; SOA) pˇredstavuje architektonický pˇrístup k vývoji softwaru. Toto paradigma nemá pˇresnou definici, je však striktnˇe založeno na konceptu poskytování služeb (services). [16] Služba je pˇresnˇe specifikována v kontraktu a prezentuje jakoukoliv duležitou ˚ funkcionalitu, kterou poskytujeme a jiné subjekty ji mohou využívat. K tomu, aby se mohl zákazník (subjekt) k službˇe pˇripojit (bind), je nutné kontrakt služby vystavit (publish) a pˇred pˇripojením vyhledat (find). Tento princip se nazývá „Bind-Publish-Find“ [Obrázek 10.8] a je typický pro SOA. SOA se vyznaˇcuje mimo jiné jednou zásadní vlastností1 , slabými vazbami mezi komponenty, to zjednodušuje management distribuovaných zdroju˚ a pˇrispívá k vývoji dynamických aplikací. Realizací SOA jsou webové služby. Webové služby (Web Services; WS) jsou implementaˇcní prostˇredek a slouží jako zpusob ˚ komunikace v prostˇredí internetu a zásadnˇe zjednodušují interoperabilitu komunikujících stran. Jedná se o užiteˇcnou, platformˇe nezávislou a jednoduchou technologii vytvárˇ ející komunikaˇcní infrastrukturu založenou na standardech konsorcia W3C (World Wide Web Concorsium). Samo spoleˇcenství definuje webové služby takto: „Webová služba je softwarový systém zkonstruovaný k podpoˇre interakce mezi stroji pˇres sít’. Má rozhraní popsané ve strojovˇe zpracovatelném formátu (specificky WSDL). Ostatní systémy interagují s webovou službou zpusobem ˚ pˇredepsaným jejím popisem za pomoci SOAP zpráv, typicky dopravovaných použitím HTTP s XML serializací v souˇcinnosti s ostatními webovými standardy.“ [17] Webové služby tedy vnímáme jako zpusob ˚ volání vzdálených funkcí v distribuovaných systémech, podobnˇe jako starší CORBA. [19] Infrastrukturu webových služeb tvoˇrí tˇri základní pilíˇre [Obrá1. Pˇrehled hlavních principu˚ a vlastností architektury SOA http://serviceorientation.com/static/pdf/SOA_Principles_Poster.pdf.
online:
23
4. S ERVISN Eˇ ORIENTOVANÁ ARCHITEKTURA A WEBOVÉ SLUŽBY zek 10.9]: a) protokol pro vzdálené volání procedur SOAP, b) jazyk pro popis poskytovaných služeb WSDL, c) mechanismus pro nalezení služeb, kde jsou dostupné standardy UDDI a WSIL. Samotná data jsou ve formátu XML, pro jejich pˇrenos webové služby využívají protokol HTTP, pro definici typu˚ dat standard XML Schema a pro identifikaci objektu˚ standard XML Namespaces. Právˇe pro použití všeobecnˇe uznávaných standardu, ˚ malé nároky a pˇredpoklady na komunikující strany a jednoduchost se jedná o vhodnou volbu pro náš projekt.
4.1
Technologie webových služeb
Volání webových služeb je provádˇeno pomocí protokolu SOAP (Simple Object Access Protocol). Aplikace si mezi sebou posílají XML zprávy, které pˇredstavují dotazy a odpovˇedi a jsou pˇrenášeny nejˇcastˇeji pomocí protokolu HTTP, metody POST. SOAP zpráva je tvoˇrena XML znaˇckou Envelope, jež obsahuje nepovinnou hlaviˇcku (Header) a tˇelo (Body). Vše v pˇríslušném jmenném prostoru. Tˇelo zprávy obsahuje hlavní znaˇcku pojmenovanou stejnˇe jako metoda, která je volána. Vnoˇrené znaˇcky pak pˇredstavují parametry volání. SOAP zpráva reprezentující odpovˇed’ ze serveru podle konvence obsahuje v tˇele opˇet jednu hlavní znaˇcku, jejíž název je složen z názvu vyvolané metody a rˇ etˇezce Response, vnoˇrené znaˇcky pak pˇredstavují návratové hodnoty. Další nedílnou souˇcást webových služeb tvoˇrí technologie WSDL (Web Services Description Language). Jedná se o jazyk k popisu rozhraní webových služeb, který popisuje jména dostupných operací, typy parametru˚ a návratových hodnot, zpusob, ˚ jak se k službˇe pˇripojit a kde je dostupná (port, stroj, URL). Jinými slovy tento XML dokument popisuje sadu pˇredávaných zpráv SOAP a zpusob, ˚ jakým se zprávy vymˇenují, ˇ tedy syntaxi volání vzdálených operací, ale nepopisuje sémantiku operací. Vztah mezi SOAP službou a dokumentem WSDL je velmi tˇesný, cˇ ím je IDL pro CORBA, tím je WSDL pro SOAP a SOAP v podstatˇe nemuže ˚ bez WSDL existovat. WSDL doku24
4. S ERVISN Eˇ ORIENTOVANÁ ARCHITEKTURA A WEBOVÉ SLUŽBY ment lze vytvoˇrit i ruˇcnˇe, ovšem bˇežnou praxí je vygenerování pomocí specializovaných platformních nástroju, ˚ jako je JAX-WS (pˇríkaz wsgen) u jazyka Java. Tyto nástroje lze využít i opaˇcnˇe, tj. pro vytváˇrení tzv. stub, tedy zástupného kódu pro volání webových služeb, pˇríkaz wsimport u JAX-WS, tím znaˇcnˇe zjednodušují práci s WS. Tˇretí entitou kompletující webové služby je standard UDDI (Universal Description, Discovery, and Integration). Tato technologie je cˇ asto pˇrirovnávána ke Zlatým stránkám, protože podobnˇe jako ony pˇredstavují velký adresáˇr informací o subjektech a jimi poskytovaných službách. UDDI nabízí možnost pˇridávání nových webových služeb, filtrování a dohledávání již vystavených webových služeb. Toto skladištˇe pracuje taktéž na principu WS využívající SOAP. Zápis do adresáˇre UDDI má tˇri cˇ ásti: • Bílé stránky (white pages) popisují subjekt jako takový, který nabízí službu: název, adresu, struˇcný popis atd. • Žluté stránky (yellow pages) obsahují detailní informace o subjektu. • Zelené stránky (green pages) popisují detailnˇe rozhraní služby. Popis této definice je uveden v souboru UDDI - Type Model (také tModel). Obvykle tModel obsahuje soubor WSDL, jak již bylo uvedeno, tento artefakt je nezbytný k pˇripojení webové službˇe. tModel je však univerzální a muže ˚ sloužit k popisu rozlišných služeb. Obecné informace o službˇe jsou uloženy v datové struktuˇre Business Service a údaje týkající se toho, jak a kde je služba dostupná, nalezneme v Binding Template. Typická práce s UDDI probíhá tak, že vývojáˇr prohledá registr a najde si služby, které potˇrebuje. Získá pro nˇe popis WSDL a muže ˚ je zaˇcít rovnou používat. Vzhledem k tomu, že náš projekt není tak rozsáhlý a neobsahuje nijak velké množství služeb, nebudeme UDDI potˇrebovat a používat.
4.2
Bezpeˇcnost webových služeb
Bezpeˇcnost webových služeb se dá rˇ ešit dvˇema zpusoby. ˚ První zpu˚ sob je založen na ochranˇe samotné SOAP zprávy (end-to-end message content security) pomocí kryptografických metod vycházejících 25
4. S ERVISN Eˇ ORIENTOVANÁ ARCHITEKTURA A WEBOVÉ SLUŽBY ze standardu˚ XML Signature a XML Encryption, kdy dochází k podepisování celé nebo cˇ ásti zprávy. Na tomto principu vznikla specifikace WS-Security (WSS). Jedná se o zpusob ˚ používající sofistikované bezpeˇcnostní mechanismy jako Kerberos nebo PKI, který poskytuje nepopiratelnost puvodu ˚ zprávy (non-repudiation). Nevýhodou je cˇ asová a výpoˇcetní nároˇcnost a chybˇející ochrana pˇred odposloucháváním. Druhým rˇ ešením je použití SSL/TLS protokolu (HTTPS), kde dochází k ochranˇe na úrovni transportní vrstvy (transport-level security). Ochrana je urˇcena proti odposlechu a zmˇenˇe dat po cestˇe, ale neposkytuje nepopiratelnost puvodu. ˚ Znaˇcnou výhodou proti prvnímu rˇ ešení je rychlost, robustnost a fakt, že se jedná o léty provˇerˇ enou technologii. Jak již bylo v cˇ ásti Bezpeˇcnost uvedeno, v našem projektu je použita druhá varianta.
26
5 Analýza Cílem práce je vytvoˇrení aplikace, která umožní pracovníkum ˚ SUKB jednodušší a rychlejší kooperaci se systémem Archibus v reálném cˇ ase pˇrímo v terénu pˇri procesu údržby. Tento produkt ve formˇe aplikace by mˇel být schopen pro tuto agendu poskytnout takové prostˇredí, které bude nativní, dobˇre ovladatelné a pˇritom bezpeˇcné. Analýza zahrnuje mimo analýzu požadavku˚ také analýzu procesu údržby a pˇrípadovou studii bezpeˇcnosti. Souhrn tˇechto poznatku˚ je uplatnˇen ve výsledných analytických konceptuálních modelech. Tvorba tˇechto modelu˚ je klíˇcová a tvoˇrí duležitou ˚ souˇcást komunikace se zákazníkem (SUKB). Pro potˇreby zaˇrízení pˇrístupu k mobilní aplikaci se separátním autentizaˇcním schématem je nutné doplnit aplikaci o pomocné funkce pro tyto úˇcely. Tyto funkce nejsou pˇrímou souˇcástí diplomové práce a pˇredpokládá se, že budou k dispozici pro vybrané vedoucí pracovníky z SUKB.
5.1
Analýza požadavku˚
Analýza požadavku˚ je založena na identifikaci požadovaných funkcí, vlastností a omezení celé práce. Textová specifikace je doplnˇena diagramem pˇrípadu˚ užití (Use case diagram) [Obrázek 5.1] vˇcetnˇe specifikace pˇrípadu˚ užití, tento dokument je k práci pˇriložen v podobˇe pˇrílohy A. 5.1.1 Funkˇcní požadavky Funkˇcní požadavky se zamˇerˇ ují na vlastní funkcionalitu aplikace. Mezi funkˇcní požadavky1 patˇrí: • A00, 1: Pˇrihlášení uživatele do terénní aplikace (jméno, heslo). • A01, 1: Zakládání nových požadavku˚ údržby (jméno, kód zarˇ ízení, oblast, budova, poschodí, místnost, typ problému, priorita, kontakt, poznámka). 1. Požadavek je formátu:
, <priorita>: (). Priorita nabývá hodnot: 1 – povinné, 2 – žádoucí, 3 – volitelné.
27
5. A NALÝZA • A02, 1: Dokonˇcení otevˇreného požadavku na údržbu (jméno, kód zaˇrízení, kód požadavku, pˇríˇcina, zpusob ˚ opravy, poznámka). • A03, 1: Prohlížení seznamu aktivních požadavku˚ na údržbu u zaˇrízení (kód zaˇrízení). • A04, 2: Prohlížení seznamu aktivních požadavku˚ na údržbu u pracovníka údržby (jméno). • A05, 2: Prohlížení seznamu provedených požadavku˚ na údržbu u zaˇrízení (kód zaˇrízení). • B00, 1: Naˇctení QR kódu zaˇrízení pomocí zadní kamery mobilního zaˇrízení. • B01, 2: Poskytnutí zpˇetné vazby pˇri provedení jakékoliv akce. Omezení: u všech požadavku˚ A0x se pˇredpokládá, že pro úspˇešné dokonˇcení úlohy bude dostupné pˇripojení k internetu.
Obrázek 5.1: Diagram pˇrípadu˚ užití v rámci této práce; zdroj: autor, použit nástroj Visual Paradigm.
5.1.2 Nefunkˇcní požadavky Další skupinu požadavku˚ nazýváme tzv. nefunkˇcní a vyznaˇcují se tím, že se jedná o vlastnosti a omezení na systém a uživatele/mobilní zaˇrízení. Mezi nefunkˇcní požadavky patˇrí: 28
5. A NALÝZA • Aplikace bude mít pouze jediný pracovní mód, tj. rozhraní nebude rozlišovat pracovní hierarchii. • Aplikace bude lokalizovaná do cˇ eského jazyka. • Aplikace bude urˇcena pro operaˇcní systém Android od verze 4.0.3 tj. API úrovnˇe 15. • Aplikace bude urˇcena pro mobilní zaˇrízení s následující minimální konfigurací: – RAM pamˇet’ 512MB, – zadní kamera s min. rozlišením 2 Mpix a vestavˇeným bleskem (pro práci pˇri zhoršené viditelnosti), – dostupné datové funkce (WiFi, 3G, LTE, 4G). • Aplikace bude využívaná pouze na akademické pudˇ ˚ e Masarykovy univerzity a pro správné fungování musí být zaˇrízení pˇrihlášené do vnitˇrní sítˇe MU (vˇcetnˇe VPN tunelu). • Aplikace nebude vystavena na Google Play. • Oznaˇcení majetku MU vyhovujícími QR kódy ze strany SUKB. • Aplikace se bude vyznaˇcovat integrovatelností, tj. bude integrovaná do systému Archibus. • Aplikace se bude vyznaˇcovat bezpeˇcností, tj. budou implementovány standardní bezpeˇcnostní mechanismy (autentizace, autorizace, integrita), bude probíhat zabezpeˇcená komunikace pomocí HTTPS, bude provedena bezpeˇcnostní analýza rizik a minimalizována možná nebezpeˇcí. • Aplikace se bude vyznaˇcovat použitelností, tj. uživatelské rozhraní bude uživatelsky pˇrívˇetivé, intuitivní, bude se rˇ ídit doporuˇceními Android Guidelines a principem KISS (Keep It Simple, Stupid!). Upozornˇení: Požadavky bezpeˇcnosti a použitelnosti jdou v jistých situacích proti sobˇe. V pˇrípadˇe konfliktu bude muset použitelnost mírnˇe ustoupit zvýšeným bezpeˇcnostním opatˇrením vyplývajícím z bezpeˇcnostní analýzy.
29
5. A NALÝZA
5.2
Analýza procesu údržby
Ke zhotovení analýzy bezpeˇcnostních rizik a správnému návrhu aplikace je nutná znalost pracovního procesu. Tato znalost prostˇredí nám dává pˇredstavu o tom, jakým zpusobem ˚ bude s aplikací zacházeno a jakým nebezpeˇcím bude z hlediska reálného používání vystavena. Z hlediska údržby se rozlišuje preventivní plánovaná údržba a vyžádaná neplánovaná údržba. Vyžádaná údržba (On Demand work) se vztahuje k nenadále vzniklým situacím, které si vyžadují brzký zásah ze strany Správy budov pro znovuzprovoznˇení dané funkcionality. Tyto poruchy se vyskytují zcela bˇežnˇe a oprava typicky spoˇcívá ve výmˇenˇe poškozených souˇcástí, v pˇridání nových souˇcástí nebo v obnovení soucˇ ástí (lepení, svaˇrení, . . . ). Typickým pˇríkladem vyžádané údržby je prasklá žárovka a potˇreba její výmˇeny. Preventivní údržba (Preventive Maintenance) je na rozdíl od vyžádané údržby kompletnˇe systematická periodická plánovaná cˇ innost za úˇcelem vˇcasného odhalení a eliminaci potenciálních výpadku˚ a poruch. Tato kontrola, revize cˇ i preventivní výmˇena namáhaných cˇ ástí zaˇrízení, která primárnˇe slouží k pˇredcházení výpadku, ˚ má i svá další pozitiva. Prodlužuje životnost zaˇrízení, zlepšuje provozní bezpeˇcnost a optimalizuje provozní proces budov. Zlepšuje také plánování nákladu˚ na provoz a údržbu. Zaˇrízení, o které je pravidelnˇe pecˇ ováno, je také lépe pˇripraveno plnit procesní povinnosti. Správná koncepce údržby má za dusledek ˚ snížení její výsledné ceny a minimalizaci pro ni vyhrazeného cˇ asu. Výsledkem preventivní údržby muže ˚ také být vytvoˇrení požadavku vyžádané údržby. Typickým pˇríkladem plánované údržby je výmˇena filtru˚ vzduchotechniky cˇ i revize výtahu. 5.2.1 Proces údržby skrze systém Archibus Podporu a sjednocení provádˇení údržby v prostˇredí univerzitního kampusu a Masarykovy univerzity pˇredstavuje systém Archibus [Obrázek 10.10]. Tento systém rozlišuje nˇekolik uživatelských rolí, kde jeden uživatel muže ˚ participovat ve více uživatelských skupinách: • Vedoucí údržby – stanovuje pravidla pro provádˇení údržby, 30
5. A NALÝZA na MU odpovídá vedoucím provozních oddˇelení nebo vedoucím správy budov. • Vedoucí pracovní skupiny – pˇrijímá požadavky od systému a rozdˇeluje je mezi pracovníky údržby. Na MU odpovídá vedoucím provozních oddˇelení. • Pracovník údržby – elementární pracovní jednotka, která vykonává samotnou údržbu. Pracovníci jsou shlukováni do pracovních skupin pro jednotlivá provozní oddˇelení. • Manažer správy budov – vedoucí pracovník, který zodpovídá za proces údržby. Má pˇrístup k ruzným ˚ statistikám. Základním stavebním prvkem údržby je pracovní požadavek, který pˇredstavuje konkrétní pokyn k provedení údržby. Tento pokyn vzniká bud’ vyžádanou údržbou pˇri poruše, nebo provedením plánované údržby ve chvíli potˇreby. Pracovní požadavek je pˇridˇelen vedoucímu údržby pˇríslušného oddˇelení a ten jej deleguje konkrétnímu pracovníkovi údržby, který jej vykoná. Pokud se jedná o úkon plánované pravidelné údržby, je pracovní požadavek tzv. krokem v rámci šablony plánování údržby. Šablony se skládají z minimálnˇe jednoho kroku. Krok pˇredkládá detailnˇejší popis cˇ innosti a má smysl napˇríklad, pokud chceme rozlišit profese a úkony potˇrebné k provedení. Vzhledem k tomu, že každý krok muže ˚ provádˇet jiná osoba, je pro každý z kroku˚ šablony vytvoˇren samostatný pracovní požadavek. Šablony definuje vedoucí údržby na základˇe povinných, zákonných revizí a pravidelných interních kontrol. Obsahují veškeré cˇ innosti údržby, které musí být provedeny, vˇcetnˇe intervalu˚ a pˇribližných dat provedení. Tím pˇredstavují protokol, kterým se plánovaná kontrola musí rˇ ídit. Šablony mohou být dvou typu: ˚ • Šablona pro celou budovu – dojde ke zkontrolování všech zaˇrízení daného typu v budovˇe. • Šablona pro zaˇrízení – dojde ke zkontrolování daného zaˇrízení. U pracovního požadavku vzniklého z vyžadované údržby je tedy ten rozdíl, že není krokem nˇejaké šablony. Duležitou ˚ souˇcástí údržby je Service Level Agreement (SLA), kde snadno definujete služby, které poskytujete, a vyˇrídíte i složité úkoly a jejich rˇ ešení podle daných pro31
5. A NALÝZA cesu. ˚ SLA jasnˇe urˇcuje, kdo za požadavky zodpovídá, jak jsou prioritní a jak rychle musí být vyˇrešeny. K SLA se také váže Service Desk. Service Desk pˇredstavuje podsystém systému Archibus pro spolehlivé rˇ ízení vyžádaných oprav. Pracovní požadavky jsou k jednotlivým vedoucím pracovních skupin delegovány skrze SLA a posléze pˇriˇrazeny k jednotlivým terénním pracovníkum. ˚ Pokud nebudeme u požadavku jakožto elementárního prvku údržby rozlišovat puvod, ˚ je typický zjednodušený scénáˇr jeho provedení následující: 1. Zamˇestnanec údržby v systému Archibus vyhledá, že mu byl pˇriˇrazen urˇcitý pracovní požadavek a zjistí si o nˇem detailnˇejší informace. 2. Pracovník údržby zajistí prostˇredky pro provedení úlohy a obstará její prubˇ ˚ eh. Pˇri této pˇrípravˇe a prubˇ ˚ ehu si musí zaznamenávat, jak a s kterým zaˇrízením manipuloval. 3. Po dokonˇcení úlohy dojde v systému Archibus k vykázání provedení dané cˇ innosti tímto pracovníkem. Ze scénáˇre jasnˇe vyplývá, že dochází ke zpoždˇení informací o pohybu materiálu a výkonu cˇ innosti. Pracovník údržby je zpomalován administrací, nehledˇe na to, že pracovník údržby je nucen informace uchovávat a muže ˚ dojít k chybˇe. Následné informace jsou v systému Archibus zpracovávány a transformovány do ruzných ˚ analytických pohledu˚ pro analýzu údržby Univerzitního kampusu Bohunice. Naším cílem je eliminovat možné chyby a zefektivnit tento proces. Aplikace by mˇela být zcela kompatibilní pro hlášení a rˇ ešení událostí vyžádané údržby a rˇ ešení požadavku˚ vzniklých údržbou plánovanou. Pro lepší a rychlejší kooperaci s uživatelem mu bude umožnˇeno naˇctení identifikaˇcního kódu zaˇrízení. 5.2.2 Životní cyklus požadavku Další duležitou ˚ souˇcástí analýzy pracovního procesu je pochopení životního cyklu daného požadavku a identifikace stavu, ˚ kterými pracovní požadavek vytvoˇrený v rámci systému Archibus prochází. Na zjednodušeném stavovém diagramu [Obrázek 10.11] je zobrazen prubˇ ˚ eh tohoto životního cyklu. Požadavek je po vložení do systému 32
5. A NALÝZA ve stavu Vytvoˇren (Created) a bývá automaticky, pomocí SLA, zpracován a pˇredán do stavu Odmítnut (Rejected) nebo Vyžadován (Requested). Pokud SLA má tu pravomoc, je požadavek pˇrímo Potvrzen (Approved), v opaˇcném pˇrípadˇe je kompetencí vedoucího oddˇelení pˇrevést požadavek do tohoto stavu. Požadavek muže ˚ být taktéž Zrušen (Cancelled), napˇríklad pokud není oprávnˇený. Pˇriˇrazení požadavku do tohoto stavu je nutné pro možnost jeho plánování a delegaci pracovníkovi údržby a je pˇredpoklad, že tento stav by mˇel být cílem pro vkládání požadavku skrze mobilní aplikaci. Pokud je pracovní požadavek Potvrzen, je nutné, aby byl vedoucím oddˇelení pˇriˇrazen a pˇredevším vystaven, a tím mohl být zpracováván. Tento stav, Vystaven a probíhá (In progress), je klíˇcový a indikuje, že na požadavku bude v dohledné dobˇe pracováno. V mobilní aplikaci je tento stav brán jako aktivní, a tudíž v tomto stavu budou uživateli zobrazeny aktivní požadavky zaˇrízení a aktivní požadavky uživatele. V pˇrípadˇe, že probíhá zpracování požadavku, je možné provést jeho dokonˇcení – Dokonˇcen (Completed). Pokud není z nˇejakého du˚ vodu možné ho dokonˇcit, napˇríklad chybí materiál na opravu, muže ˚ být požadavek Pozastaven (Stopped). Právˇe tuto možnost by aplikace mˇela též poskytovat v rámci dokonˇcení požadavku. Z tˇechto dvou stavu˚ je možné vrátit požadavek do stavu Vystaven a probíhá, pokud však není shledán duvod ˚ k opˇetovnému vystavení, je na privilegované osobˇe, aby požadavek pˇrevedla do stavu Uzavˇren (Closed). V tomto stavu je požadavek brán ze strany aplikace jako zcela dokonˇcený a zobrazen v historii zaˇrízení. Mimo uzavˇrení je jako finální, koneˇcný stav považováno odmítnutí nebo zrušení požadavku. 5.2.3 Identifikaˇcní kódy zaˇrízení Ruznými ˚ kódy jsou dnes vybavena témˇerˇ všechna zaˇrízení a prostory MU. Jedná se o nˇekolik typu˚ identifikaˇcních znaˇcek. Mezi nejcˇ astˇejší patˇrí technologické a polohové kódy [Obrázek 10.12 a 10.13]. Další identifikaˇcní kódy, které lze nalézt na majetku MU, jsou tzv. kódy DHM (dlouhodobého hmotného majetku). Tyto cˇ árové kódy slouží pˇredevším k inventarizaci majetku a podobnˇe jako pˇredešlé kódy se nehodí k identifikaci zaˇrízení. Další problém tkví v tom, že vˇetšina není celek. Napˇríklad u Univerzitního kampusu, jakožto no33
5. A NALÝZA vého univerzitního celku, dodaného od stavební firmy, nejsou technická zaˇrízení tˇemito kódy oznaˇcena. Absence tˇechto kódu˚ je znaˇcná, jelikož technická zaˇrízení jsou souˇcástí dodané stavby, proto jsme dospˇeli k návrhu použití vlastních identifikaˇcních QR kódu. ˚ Výhodou tohoto rˇ ešení je unifikované oznaˇcení zaˇrízení, které obstará SUKB. QR kód bude v sobˇe nést identifikaˇcní rˇ etˇezec odpovídající položce eq_id v tabulce afm.eq v systému Archibus. Tato infrastruktura identifikaˇcních kódu˚ poslouží k jednoznaˇcné identifikaci zaˇrízení a dohledání souvisejících informací. QR kódy jsou pomˇernˇe populární a rozšíˇrené, poskytují ruznorodé ˚ informace, napˇríklad klasický text jako v našem pˇrípadˇe, vizitku, cˇ i rozsáhlý internetový odkaz. Pro potˇreby testování bylo použito nástroje pro generování dávky QR kódu˚ z Excel souboru2 . Doporuˇcení pro SUKB je generovat kódy s titulkem [Obrázek 10.14] odpovídajícím vnitˇrní informaci pro možnost kontroly správnosti naˇctené informace pracovníkem údržby. Klasická pracovní schémata budou vyžadovat naˇctení tohoto kódu pro pokraˇcování v práci s aplikací.
5.3
Analýza bezpeˇcnosti
Souˇcástí pˇrípadové studie rizik je analýza rizik, která nám poodhaluje, co všechno se muže ˚ stát, jaká a kde na nás cˇ íhají bezpeˇcnostní rizika, a umožnuje ˇ vytvoˇrit opatˇrení pro jejich minimalizaci a prevenci. Tato analýza je klíˇcová, jelikož aplikace bude manipulovat s daty o majetku Masarykovy univerzity a pokud by došlo k narušení integrity, duvˇ ˚ ernosti a dostupnosti pˇri používání této aplikace, mˇelo by to závažné dusledky. ˚ Abychom mohli hodnotit, analyzovat a dˇelat závˇery, je nutné provést identifikaci a ohodnocení stávajících opatˇrení, aktiv a hrozeb. 5.3.1 Identifikace stávajících opatˇrení Mezi stávající opatˇrení budov a zaˇrízení patˇrí: • interní smˇernice a postupy, • pravidelné audity hospodaˇrení a majetku, 2.
34
http://blog.qr4.nl/Batch-QR-Code.aspx
5. A NALÝZA • fyzické (zámek + klíˇc) a elektronické zabezpeˇcení objektu (pˇrístupový systém, zabezpeˇcovací systém, kamerový systém, . . . ), • požární zabezpeˇcení, • bezpeˇcnostní agentura, • zabezpeˇcení kabeláže a zaˇrízení ve stˇenách a krytech. Mezi stávající opatˇrení systému Archibus patˇrí: • • • • •
nastavení uživatelských rolí, ˇ pˇrihlášení do systému skrze UCO/sekundární heslo, AAA – autorizace, autentizace a audit provedených operací, pˇrístup pouze ze sítˇe MU (nutné použití VPN), zálohování DB.
Dalším faktorem snižujícím pravdˇepodobnost incidentu je fakt, že systém Archibus je zakoupený a certifikovaný, tudíž prošel ruz˚ nými druhy testu˚ a je doladˇený. Druhým faktorem snižujícím pravdˇepodobnost incidentu je již nˇekolikaleté používání, což zvyšuje porozumˇení a ovladatelnost systému a snižuje riziko chyby. 5.3.2 Identifikace a hodnocení aktiv Základním krokem pˇred analýzou rizik je identifikace a ocenˇení aktiv (hodnocení 1-5, kde hodnota 5 je nejvyšší duležitost), ˚ vˇcetnˇe urcˇ ení vlastníka. Aktivum je cˇ ást systému, která má pro nás konkrétní hodnotu – udání významu v kontextu projektu. V projektu byly identifikovány následující aktiva: Typ aktiva
Konkrétní aktiva
Hodnocení
Vlastník aktiva
Informace
Databáze saerveru QR kód Mobilní zaˇrízení Technické zaˇrízení Server Aplikace Archibus Webové služby
5 2 3 3 4 4 4 5
MU MU Pracovník MU MU Autor MU Autor
HW
SW Služby
35
5. A NALÝZA 5.3.3 Identifikace hrozeb a zranitelností Následujícím krokem, stále pˇred analýzou, je identifikace konkrétních hrozeb a zranitelností našeho projektu u definovaných aktiv a stanovení pravdˇepodobnosti hrozeb (P) s hodnocením opˇet 1-5, kde hodnota 5 je nejpravdˇepodobnˇejší hrozba. Hrozba pˇredstavuje možnost poškození toho, co jsme vytvoˇrili. K uvedeným aktivum ˚ byly identifikovány následující hrozby a zranitelnosti: Hrozba
P
Související zranitelnost
Selhání komunikaˇcních služeb
5 5 3 3 3 3 3 4 4 3 2 1 4
Odposlechnutí komunikace Narušení komunikace Neoprávnˇené použití aplikace Ztráta provedených akcí Zasílání nevalidních dat Špatné zpracování dat Chyba zpracování Nedostateˇcná ochrana zaˇrízení Podvrhnutí QR kódu Nedostateˇcné školení Selhání zálohování Požár Zneužití aplikace duvˇ ˚ eryhodným zdrojem Mobilní zaˇrízení s malware Slabá úrovenˇ zabezpeˇcení Selhání zabezpeˇcení
Odcizení zaˇrízení Porucha hardware Selhání software
Zpronˇevˇerˇ ení aktiv Neúmyslná modifikace Ztráta dat Živelná pohroma Interní hrozba Škodlivý kód Cílený útok
3 3 3
5.3.4 Analýza rizik Pˇrímo navazující cˇ inností na identifikaci a ohodnocení aktiv, hrozeb a zranitelností je analýza rizik (AR). Jak již bylo rˇ eˇceno, tato analýza je provádˇena na úrovni neformální, tj. pragmatická AR. Úˇcelem této analýzy je: • snížení rizik na pˇrijatelnou úrovenˇ formou opatˇrení, • popis existujících a plánovaných bezpeˇcnostních opatˇrení, 36
5. A NALÝZA • odhad míry rizik, • pˇrípadné pˇrijetí zbytkových rizik, tj. která jsou akceptovatelná, ale i pˇresto by mˇela být monitorována. Normativní podporu pro provedení analýzy rizik nám poskytuje ˇ již zmínˇena cˇ eská technická norma CSN ISO/IEC 27005: Informaˇcní ˇ technologie - Bezpeˇcnostní techniky: Rízení rizik bezpeˇcnosti informací. Základní dˇelení analýzy je dle poˇctu použitých parametru. ˚ Mezi nejoblíbenˇejší patˇrí analýza rizik s dvˇema a tˇremi parametry. Zpusob ˚ výpoˇctu je rozdílný, ale výsledek stejný, a to výpoˇcet míry rizika (R). Pˇri použití metody se dvˇema parametry je nutné urˇcit pravdˇepodobnost incidentu (PI) a jeho dopad (D). Tato analýza rizik vyhodnocující pravdˇepodobnost incidentu a jeho dopad je více popisná, je nutné k jednotlivým aktivum ˚ a identifikovaným hrozbám/zranitelnostem odhadnout pravdˇepodobnost incidentu. Pravdˇepodobnost incidentu udává, že daná hrozba využije zranitelnosti a ohrozí tím dané aktivum. U provedené analýzy rizik, která je k nalezení ve formˇe pˇrílohy B, pravdˇepodobnost incidentu byla urˇcena na základˇe dostupných statistických údaju˚ a interních informací, samozˇrejmˇe nelze hrozbu incidentu nikdy 100% vylouˇcit, u tˇechto pˇrípadu˚ bylo použito 5% pravdˇepodobnosti incidentu (hodnocení 0-100, kde 100 dává 100% jistotu využití zranitelnosti). Pravdˇepodobnost incidentu je snižována existujícími opatˇreními. Dopad, jako další parametr, muže ˚ být zvolen shodný s hodnotou aktiva, pokud by pˇri incidentu došlo pouze k cˇ ásteˇcnému poškození aktiva, lze zvolit nižší hodnotu. Míra rizika je následnˇe vypoˇctena podle vztahu R = PI x D. 5.3.5 Pˇrijetí protiopatˇrení a zbytkových rizik Dle analýzy rizik bylo zjištˇeno, že díky aplikovaným opatˇrením v doposud používaném schématu bylo dosaženo výrazného snížení pravdˇepodobnosti incidentu – hladina se pohybuje mezi 5-15%. K vyhodnocení analýzy byla definována následující stupnice hranic rizik: • 0-29 = akceptovatelné riziko, vˇetšinou již existují opatˇrení, která minimalizují hrozbu. 37
5. A NALÝZA • 30-59 = mírné riziko, které muže ˚ zpusobit ˚ potíže. • 60-99 = nežádoucí riziko, které muže ˚ zpusobit ˚ vážné potíže. • 100+ = nepˇrijatelné riziko, které muže ˚ zpusobit ˚ existenˇcní potíže. Po této kategorizaci rizik vyplývá, že byla identifikována 3 nepˇrijatelná rizika, 2 nežádoucí rizika a 4 mírná rizika. Zbytková rizika, tj. do výsledku 29, jsou považována za akceptovatelná a nebudou se jich následující protiopatˇrení pˇrímo týkat. Z výsledku je zˇrejmé, že kritickou hrozbou projektu jsou komunikace, cílený útok a selhání samotného procesu zpracování dat v aplikaci. Doporuˇcená protiopatˇrení: • Použití zabezpeˇcené HTTPS komunikace (uvedeno již ve specifikaci). Související zranitelnosti: odposlechnutí komunikace, narušení komunikace, slabá úrovenˇ zabezpeˇcení, selhání zabezpeˇcení. • Implementace standardních bezpeˇcnostních opatˇrení jako AAA a VPN. Související zranitelnosti: odposlechnutí komunikace, narušení komunikace, slabá úrovenˇ zabezpeˇcení, selhání zabezpeˇcení. • Po odejití z aplikace nebude možno se vrátit, tj. je nutné vytvorˇ it nové sezení s novým pˇrihlášením. Související zranitelnosti: neoprávnˇené použití aplikace. • Vytvoˇrené sezení bude mít cˇ asový timeout 30 minut, tj. pokud uživatel neprovede žádnou akci bˇehem tohoto cˇ asového úseku, bude muset opakovat pˇrihlášení. Související zranitelnosti: neoprávnˇené použití aplikace. • Validace dat na úrovní klienta i serveru. Související zranitelnosti: zasílání nevalidních dat, podvržení QR kódu, nedostateˇcné školení. • Provedení testování a testovacího provozu aplikace. Související zranitelnosti: zasílání nevalidních dat, podvržení QR kódu, nedostateˇcné školení, slabá úrovenˇ zabezpeˇcení. • Doporuˇcení SUKB pro pravidelnou kontrolu a audit. Související zranitelnosti: zneužití aplikace duvˇ ˚ eryhodným zdrojem, neoprávnˇené použití aplikace. • Aplikaci nelze použít bez pˇripojení k internetu. 38
5. A NALÝZA
5.4
Výsledky analýzy
Na základˇe provedené analýzy požadavku, ˚ procesu údržby a analýzy rizik byl vytvoˇren funkˇcnˇe orientovaný model této práce – diagram datových toku˚ (Data flow diagram, DFD) a datovˇe orientovaný model – entitnˇe relaˇcní diagram (Entity relationship diagram, ERD). Tyto konceptuální modely strukturované analýzy projektu pˇredstavují výchozí bod návrhu integrace nového modulu do systému Archibus, schématu webových služeb a samotné aplikace. Zárovenˇ svou jednoduchostí poskytují snadnˇejší pochopení systému. V DFD je na systém nahlíženo jako na množinu funkcí a procesu˚ transformující data. Nˇekdy je diagram datových toku˚ také nazvaný jako procesní model a slouží právˇe k popisu systému z funkˇcního hlediska. Systém je zobrazen jako sít’ procesu, ˚ které plní, modifikují, zpracovávají a hlavnˇe si mezi sebou vymˇenují ˇ data. DFD obsahuje následující cˇ tyˇri komponenty: • terminátor je externí entita, kde data vznikají a kde se také konzumují, • proces je místo, kde jsou data transformována, • datový tok vyjadˇruje pohyb dat a jejich pˇresun mezi systémem, • pamˇet’ slouží k doˇcasnému ukládání dat pro další zpracování. Náš výsledný model [Obrázek 10.15] má dva terminátory, a to uživatele a systém Archibus. Mezi tˇemito entitami se vyskytuje nˇekolik procesu˚ a toku, ˚ kterými prochází data a pomáhají k interoperabilitˇe aplikace. V modelu se vyskytuje jedna pamˇet’, a to v systému Archibus. Druhým výstupem analýzy je entitnˇe relaˇcní diagram, který vyjadˇruje model dat. ERD definuje jednotlivé datové objekty – entity a vztahy mezi nimi a tím vytváˇrí pˇríhodný doplnˇek k DFD, který specifikuje funkce, ale ne model dat. ERD obsahuje následující komponenty: • entita je datový objekt, který je typicky ukládán do relaˇcní db, • atribut je souˇcástí entity a vyjadˇruje charakteristiku entity, • vztah, který vyjadˇruje formu spojení mezi entitami. 39
5. A NALÝZA ERD [Obrázek 10.16] vytvoˇrený pro potˇreby analýzy obsahuje 5 základních entit: uživatel systému Archibus (tabulka afm.afm_users), zaˇrízení (tabulka afm.eq), uživatel mobilní aplikace (tabulka afm.mobile_users), požadavek na údržbu (tabulka afm.wr) a zamˇestnance (uživatel musí být veden jako zamˇestnanec SUKB tabulka afm.em). Nutno uvést, že tento zjednodušený diagram uvádí pouze prioritní atributy a tabulky, kterých se projekt pˇrímo týká a pracuje s nimi. Pouze tabulka afm.mobile_users je novˇe pˇridána pro úˇcely projektu. Systém Archibus se vyznaˇcuje velkým množstvím entit a dat s neménˇe rozšíˇrenými schématy. Zobrazené vztahy mezi entitami jsou taktéž zjednodušeny.
40
6 Návrh Kontinuálním pokraˇcováním analýzy je návrh samotné integrované služby a terénní aplikace pro pracovníky SUKB. Hlavním úˇcelem je zamyšlení nad tím, jak bude vše implementováno s ohledem na pˇredešlou analýzu a dostupné technické prostˇredky. Jasným prioritním cílem tohoto návrhu je minimalizace složitosti aplikace a souvisejících komponent. Návrh je interpretován a dokládán na doplnkových ˇ UML diagramech a grafických schématech. Tato prezentace myšlenek podobnˇe jako u analýzy pomáhá k lepšímu pochopení myšlenkových pochodu˚ a vyjasnˇení textu.
6.1
Návrh webových služeb
Webové služby v našem projektu slouží jako spojnice mezi integrovanou službou v systému Archibus a klientskou aplikací pro platformu Android. Zárovenˇ se jedná o kritické aktivum, jež je bráno jako chránˇené tajemství (soubor WSDL není vystaven mimo MU a veˇrejnˇe dostupný). Pro poskytnutí požadované funkcionality a maximální klientské podpory byly navrženy následující metody webové služby: • boolean echo() – Metoda pro zjištˇení stavu dostupnosti WS služby, návratová hodnota indikuje, zda bˇeží databáze. Pro vyvolání metody není potˇreba autentizace. • String registerUser(String user, String simpleHash) – Metoda pro vytvoˇrení uživatele (tabulka afm.mobile_users), který je doposud registrován v systému Archibus (tabulka afm.users) a bude mu umožnˇen pˇrístup do mobilní aplikace (musí být veden jako zamˇestnanec SUKB - tabulka afm.em). Pro vyvolání metody není potˇreba autentizace, metoda je urˇcena pro administrátorskou nadstavbu. Odpovˇed’ ve formátu JSON. • String deleteUser(String userId) – Metoda pro smazání uživatele z afm.mobile_users, kterému bude odebrán pˇrístup do mobilní aplikace. Pro volání metody není potˇreba autentizace, metoda bude využívána administrátorem, odpovˇed’ ve formátu JSON. 41
6. N ÁVRH • String changeUserPassword(String user, String sHash) – Metoda pro zmˇenu hesla uživatele používajícího mobilní aplikaci. Pro vyvolání metody není potˇreba autentizace, metoda je urˇcena administrátorovi, odpovˇed’ ve formátu JSON. • String login() – Metoda pro pˇrihlášení uživatele do klientské aplikace. Odpovˇed’ ve formátu JSON obsahuje technické informace potˇrebné pro další bˇeh aplikace, jakými jsou: seznam dostupných typu˚ problému pˇri otevˇrení požadavku (prob_type), seznam dostupných typu˚ pˇríˇcin vzniku problému pˇri uzavírání požadavku (cause_type) a seznam dostupných typu˚ oprav pˇri uzavírání požadavku (repair_type). • String getEquipmentDetail(String eqId) – Metoda pro získání informací o zaˇrízení. Vstupem je identifikaˇcní kód zaˇrízení, výstupem odpovˇed’ ve formátu JSON nesoucí umístˇení zaˇrízení (site_id, bl_id, fl_id, rm_id). • String getHistory(String eqId) – Metoda pro získání 20 nejnovˇejších provedených požadavku˚ na daném zaˇrízení z tabulky afm.hwr. Vstupem je identifikátor zaˇrízení, výstupem odpovˇed’ ve formátu JSON. • String getActiveTasks(String eqId) – Metoda pro získání 20 nejnovˇejších aktivních požadavku˚ u daného zaˇrízení z tabulky afm.wr. Vstupem je identifikátor zaˇrízení, výstupem odpovˇed’ ve formátu JSON. • String getUserTasks(String userId) – Metoda pro získání 20 nejnovˇejších požadavku˚ konkrétního pˇrihlášeného uživatele z tabulky afm.wrcf. Vstupem je jméno uživatele, výstupem odpovˇed’ ve formátu JSON. • String getTaskDetail(String taskId) – Metoda pro získání informací o daném požadavku. Vstupem je identifikátor požadavku, výstupem odpovˇed’ ve formátu JSON. • String openTask(String json) – Metoda pro zadání požadavku do systému. Vstup i výstup je ve formátu JSON. • String resolveTask(String json) – Metoda pro dokonˇcení požadavku v systému. Vstup i výstup je ve formátu JSON.
42
6. N ÁVRH
6.2
Návrh serverové cˇ ásti
Serverová cˇ ást projektu slouží k pˇrijímání požadavku, ˚ jejich zpracování a komunikaci s databází [Obrázek 10.20]. Jeho souˇcástí jsou integrované webové služby. Pro implementaci konkrétního rˇ ešení je nezbytné nastudování a pochopení implementace systému Archibus. Toto zkoumání je znepˇríjemnˇeno faktem, že jádro aplikace je obchodním tajemstvím majitele a vydavatele spoleˇcnosti ARCHIBUS, Inc. Implementace by mˇela být schopna využít maximum ze stávajících prostˇredku. ˚ Zásadním principem tohoto návrhu v souˇcinnosti s bázovým principem je praktická a dusledná ˚ dekompozice a maximální oddˇelení zodpovˇednosti. 6.2.1 Návrh zpracování požadavku Výsledkem této sekce návrhu je pˇriložený diagram tˇríd [Obrázek 10.17]. Práci s aplikací by mˇela pˇredcházet autentizace uživatele pomocí metody login, po pˇrijetí jakéhokoliv následujícího zainteresovaného požadavku bude samotnému zpracování pˇredcházet ovˇerˇ ení ˇ této autentizace. Casový limit pro automatické odhlášení kvuli ˚ neaktivitˇe byl urˇcen na 30 minut. Metoda login vytváˇrí sezení mezi systémem Archibus a klientem a zárovenˇ aplikaci poskytuje technické informace pro další použití. Tato sezení jsou doˇcasnˇe ukládána lokálnˇe do objektu SessionManager, tento manažer je tzv. jedináˇcek (Singleton) a slouží k administraci sezení. Aby se záznamy (SessionItem) nehromadily, bude v cˇ asových intervalech 16 minut spouštˇeno uklízecí vlákno CleanUpThread pro odstranˇení neaktivních sezení. Tento podpurný ˚ nástroj bude aktivní pouze v pˇrítomnosti nˇejakého záznamu. SessionManager slouží pˇredevším jako kontrolní prvek pˇri kontrole autentizace, k tomuto úˇcelu slouží metoda SessionManager.updateSession. Po provedení ovˇerˇ ení aktivního pˇrístupu je rˇ ízení požadavku pˇredáno objektu TransactionManager, který podobnˇe jako SessionManager je jedináˇcek. Tento manažer provede primární kontrolu vstupních dat a delegaci provedení požadavku. Pro delegaci provedení urˇcitého požadavku je využito konkrétní instance rozhraní Handler. Zavoláním metody Handler.handle dojde již k provedení požadavku. Aktuální „manipulátoˇri“ (handlers) jsou sdruženi v ob43
6. N ÁVRH jektu HandlerFactory, kde pomocí HandlerFactory.getHandler dojde k navrácení odpovídajícího manipulátora na základˇe požadovaného typu. Mimo to, že všichni manipulátoˇri jsou implementací rozhraní Handler, nejsou to oni, kteˇrí ji implementují, nýbrž dˇedí abstraktní tˇrídu TransactionHandler. Tato tˇrída zaobaluje metody Handler.handle, Handler.getName a vytváˇrí abstraktní metody: • protected abstract void preHandle(. . . ), která slouží ke kontrole vstupních dat, • protected abstract String handleSpecific(. . . ) pro konkrétní zpracování požadavku. Primární funkce této tˇrídy kromˇe zaobalení metody handle a definici toku transakce tkví v tom, že je to místo pro pomocné metody urˇcené pro více podtˇríd. Tyto metody musí být oznaˇceny viditelností v signatuˇre protected, tím dochází k zpˇrehlednˇení a minimalizaci duplikace kódu. Klasickým pˇríkladem je transformace dat do formátu JSON, který je posílán zpˇet jako datový typ String. Faktická instance manipulátoru, která musí dˇedit TransactionHandler, provádí ovˇerˇ ení vstupních dat, provedení požadavku, pˇrípadné ovˇerˇ ení dat výstupních a transformaci do formátu JSON. Jádro provedení požadavku je ve všech pˇrípadech spojeno s komunikací s databází, tj. provedení nˇejakého SQL dotazu a jeho zpracování. Právˇe pro tyto potˇreby je urˇcen DatabaseManager, který je podobnˇe jako jeho kolegové jedináˇcek. Aby se dosáhlo dobrého uspoˇrádání a pˇrehlednosti, je databázovým manažerem využívána tˇrída DatabaseHelper, která poskytuje pomocné konstanty a databázové zdroje (DataSource) k pˇrístupu k jednotlivým databázovým objektum. ˚ Po složení a provedení dotazu je výsledek vrácen manipulátoru pro jeho další zpracování a vrácení odpovˇedi. Duležitým ˚ aspektem zpracování je, že server musí v každém pˇrípadˇe odpovˇedˇet na požadavek v žádaném tvaru. Je tím podpoˇrena zpˇetná vazba a lépe se identifikuje, kde vznikla pˇrípadná chyba, nedostupnost serveru vs. chyba pˇri zpracování.
44
6. N ÁVRH
6.3
Návrh klientské aplikace
Klientská aplikace by mˇela reflektovat základní uživatelské návyky tzv. „user experience“ a vývojáˇrské zásady. Duležitou ˚ souˇcástí je komunikace s uživatelem, který by mˇel mít pˇrehled o tom, co aplikace dˇelá s kvalitní zpˇetnou vazbou. Moderní a dynamický vzhled je samozˇrejmostí. 6.3.1 Základní informace • • • •
Název aplikace byl urˇcen SUKB Archibus Asistent. Hlavní barvou aplikace byla urˇcena svˇetle zelená (#669900). Styl písma bude reflektovat nastavení zaˇrízení. Unikátní grafický symbol aplikace [Obrázek 10.21].
6.3.2 Návrh uživatelského rozhraní Hlavním cílem tohoto návrhu je poskytnout funkˇcní a dynamický layout pro potˇreby aplikace. Aplikace by mˇela být portabilní na ruz˚ norodá pˇrenosná zaˇrízení s operaˇcním systémem Android, která budou splnovat ˇ minimální požadavky definované v analýze. Toho lze dosáhnout použitím specializovaných vývojáˇrských prvku, ˚ fragmentu. ˚ Pro lepší pˇredstavu bylo provedeno prototypování [Obrázek 10.22] jednotlivých obrazovek poskytující navíc vhled do logického cˇ lenˇení pruchodu ˚ aplikací. První obrazovka se skládá z jednoduchého pˇrihlašovacího formuláˇre pro zadání pˇrihlašovacího jména, hesla a potvrzovacího tlacˇ ítka. Pokud dojde k úspˇešnému pˇrihlášení, bude uživateli zobrazeno pracovní menu s možnostmi použití aplikace. Pˇred samotným zvolením akce lze naˇcíst QR kód zaˇrízení. Toto naˇctení kódu je vyžadováno u vˇetšiny pracovních požadavku, ˚ pokud je pˇred zvolením akce kód naˇcten, je uživatel dotázán, zdali ho chce dále použít. Pokud není naˇcten nebo uživatel odmítne jej využít, bude nutné jej nacˇ íst. Po této inicializaci dle zvolené akce muže ˚ bud’to být zobrazen seznam otevˇrených/provedených požadavku˚ na údržbu nebo formuláˇr pro zavedení požadavku do systému s tlaˇcítkem Odeslat. Po stisku na položku seznamu bude otevˇrena informaˇcní obrazovka 45
6. N ÁVRH s detailními informacemi o požadavku. Pokud se jedná o požadavek otevˇrený, bude zobrazeno tlaˇcítko Dokonˇcit. Po jeho stisknutí bude zobrazen formuláˇr pro dokonˇcení požadavku s tlaˇcítkem odeslat. Po dokonˇcení nebo otevˇrení požadavku se aplikace vrátí do hlavní nabídky. 6.3.3 Návrh mobilní aplikace Aplikace pro zaˇrízení s dotykovou obrazovkou jsou specifické množstvím interakce s uživatelem. V hlavní roli vystupuje aktivita. Aktivita prochází ruznými ˚ stádii svého životního cyklu a umožnuje ˇ na sebe navázat a mˇenit ruzné ˚ fragmenty. Fragment je položka aktivity, zapouzdˇrující cˇ ást funkcionality, vˇetšinou je to právˇe fragment, který nese layout. Fragmenty se používají, protože vytváˇrení a destrukce aktivit je z hlediska systému drahá záležitost, navíc umožnují vytvárˇ et flexibilní portabilní design a vedou k znovupoužitelnosti. Výsledkem návrhu je pˇriložený diagram tˇríd [Obrázek 10.18 a 10.19]. Úvodní aktivita naší aplikace bude LoginActivity, která neponese žádný fragment a obstará vše potˇrebné k autentizaci uživatele. Po úspˇešném pˇrihlášení bude aplikace pˇresmˇerována na MainActivity, tato aktivita tvoˇrí hlavní pilíˇr aplikace, jelikož jsou k ní pˇridruženy témˇerˇ všechny fragmenty. Tato aktivita se stará o jejich výmˇenu (refresh) dle potˇreb a aktuálního stavu aplikace, navíc jen aktivita je privilegována ke komunikaci s webovými službami, tj. fragmenty nemohou vyvolat WS, ale výsledek z volání WS je jim pˇredán pro zpracování. Mezi další výsady této aktivity patˇrí vyvolání cˇ teˇcky cˇ árových kódu˚ – ScannerActivity. Aktivita ScannerActivity obsahuje logiku naˇcítání cˇ árových kódu˚ a rˇ ízení souvisejících cˇ inností. Mezi nimi nalezneme i možnost rozsvícení blesku zadní kamery pro potˇreby zlepšení svˇetelných podmínek pˇri naˇctení QR kódu zaˇrízení. Výsledek naˇctení je nutné pˇredat zpˇet aktivitˇe MainActivity pro jeho další zpracování. Pro pˇríjem požadavku˚ na odeslání pomocí WS slouží objekt ServiceCaller, konkrétnˇe metoda ServiceCaller.call ta má za úkol na základˇe pˇrijatých informací pˇripravit zprávu (tˇrída MessageToSend) pro zaslání skrze WS a její pˇredání instanci HttpsSender. Každý objekt, který chce být zpracován, musí implementovat rozhraní 46
6. N ÁVRH ObjectToSend – AWSRequest, LoginRequest, StringRequest. HttpsSender již provede sestavení spojení a komunikaci se serverem. Komunikace probíhá šifrovanˇe, k podpoˇre této funkcionality jsou urˇceny objekty EasySSLSocketFactory a EasyX509TrustManager. Jak již bylo zmínˇeno u serverové cˇ ásti, pˇri pˇrihlášení dochází k sestavení sezení, jeho uchování pro potˇreby aplikace je v kompetenci jedináˇcka CookieManager. Pˇri pˇrihlášení jsou také do aplikace pˇrenášeny administrativní informace jako aktuální podporované zpusoby ˚ oprav nebo problémy pˇri zakládání požadavku, k uchování tˇechto informací slouží další jedináˇcci: CauseTypeHolder, ProbTypeHolder, RepairTypeHolder. Pokud se nejedná o pˇrihlášení, je odpovˇed’ ve formátu JSON rozˇclenˇena do objektu˚ Equipment cˇ i WorkRequest dle typu inicializované akce, toto parsování mají na starosti jednotlivé fragmenty.
47
7 Implementace Implementace, jak již vychází z návrhu, se skládá ze dvou oddˇelených cˇ ástí – integrovaný modul WS v systému Archibus a klientské aplikace SUKB Archibus Asistent pro platformu Android. Pro realizaci bylo použito tˇríd z návrhových diagramu˚ tˇríd logicky zasazených do balíˇcku, ˚ tak jak to vyžaduje konvence jazyka Java. Uskuteˇcnˇení vize pˇredcházelo nastudování prostˇredí Archibus a bohužel jej provázely ruzné ˚ pˇrekážky ve formˇe vysoké provázanosti a neˇcitelnosti kódu systému Archibus zpusobeného ˚ bud’ jeho nedostupností (obchodní tajemství) cˇ i mohutnou reflexí. I pˇresto výsledný produkt odpovídá specifikaci a požadavkum ˚ kladeným na tento projekt.
7.1
Prostˇredí systému Archibus
Systém Archibus je multiplatformní business aplikace založená na jazyce Java. Jedná se o jeden z nejpoužívanˇejších systému˚ pro podporu facility managementu, který je rozšíˇren po celém svˇetˇe. Na Masarykovˇe univerzitˇe je používán od roku 2011. Jádro aplikace je postaveno na aplikaˇcním rámci Spring a technicky bˇeží v kontejneru Tomcat. Apache Tomcat je open-source webový kontejner používaný pro referenˇcní implementace Java Servlet a Java Server Page (JSP) technologie. Právˇe tyto technologie tvoˇrí podstatnou cˇ ást systému Archibus. Kontejner Tomcat je známý pro svou nenároˇcnost a praktiˇcnost. Dále zde nalezneme Apache HTTP server (HTTPD), což je plnohodnotný nejrozšíˇrenˇejší aplikaˇcní server s kolekcí rozšiˇrujících modulu˚ pro podporu protokolu˚ HTTP, HTTPS, FTP a dalších. Právˇe pˇrínos v podobˇe podpory HTTPS v serveru Apache je klíˇcový pro náš projekt a umožnuje ˇ zabezpeˇcenou komunikaci. S použitím serveru Apache souvisí velké množství konfiguraˇcních souboru, ˚ kterými jasnˇe definujeme chování a vlastnosti, ovšem získaným pˇrínosem je efektivní produkˇcní prostˇredí. Pro spojení kontejneru Tomcat se serverem Apache se používá konektor mod_jk a komunikace probíhá na základˇe protokolu AJP13. Jedná se o optimalizovanou verzi http protokolu. Spring je nedílnou souˇcástí systému Archibus. Jedná se 49
7. I MPLEMENTACE o primární technologii, na které je postaven, která jej tvoˇrí. Spring je aplikaˇcní rámec, tedy framwork, pro vývoj J2EE aplikací. Lze o nˇem mluvit jako o technologii, která pˇrináší znaˇcné usnadnˇení vývoje v oblasti podnikových aplikací, jako je právˇe systém Archibus. Mezi nejduležitˇ ˚ ejší konfiguraˇcní XML soubor rámce Spring patˇrí appContext.xml, kterým rˇ ekneme aplikaˇcnímu rámci, jaké objekty má pˇripravit a jak je nastavit pro použití v aplikaci. Pˇri použití Spring dochází k odstranˇení tˇesných programových vazeb objektu˚ a vrstev za pomoci návrhového vzoru Inversion of Control (IoC) a Dependency Injection (DI). Apache CXF je technologie pro podporu vzdáleného volání a webových služeb od spoleˇcnosti Apache vhodnˇe doplnující ˇ použití kontejneru Tomcat, serveru Apache a aplikaˇcního rámce Spring. Jedná se o open-source framework k vytváˇrení kooperativních služeb. Jeho devizou je podpora mnoha protokolu, ˚ jako jsou XML/HTTP, SOAP, RESTful HTTP, nebo CORBA, které fungují nad HTTP, JMS cˇ i JBI. Z pohledu projektu a systému Archibus je nejduležitˇ ˚ ejší složkou podpora standardu webových služeb obsahující protokol SOAP a WSDL. CXF implementují JAX-WS API webových služeb. Tato podpora CXF JAX-WS vkládá mnohá pozitiva do vývoje webových služeb, ulehˇcují jejich použití a navíc jsou plnˇe kompatibilní s tˇrídami aplikaˇcního rámce Spring (bean classes) a jeho nastavení. Další výhodou CXF na rozdíl od konkurence je podpora kongruence, tj. podpora vícevláknového zpracování. Jinými slovy jsou webové služby CXF od základu vláknovˇe bezpeˇcné (thread-safe) a jsou pˇredurˇceny ke zpracování ve více vláknech na serveru, to je dáno tím, že jsou pˇrímo od výrobce tohoto serveru a plnˇe reflektují jeho nastavení.
7.2
Implementace integrované webové služby
Celkovou snahou implementace webových služeb bylo maximální využití dostupných možností. Proto byly implementovány webové služby Apache CXF s vlastním autentizaˇcním schématem. Základ naší webové služby definuje rozhraní ArchibusWebService. Toto rozhraní nese anotace @WebService a @SOAPBinding definující, že se jedná o webovou službu. Každá metoda této webové služby je pak povinnˇe oznaˇcena anotací @WebMethod. Realizací této webové služby 50
7. I MPLEMENTACE je implementace ve tˇrídˇe ArchibusWebServiceImpl. Tento vstup do WS je k nalezení v balíˇcku com.archibus.common.webservice v modulu abproducts/bldgops/common a je zaveden taktéž do konfiguraˇcních souboru, ˚ tak aby bylo možno službu automaticky vystavit pˇri zapnutí systému. Tento modul a balíˇcek je koˇrenovou lokací veškeré implementace integrovaného modulu a byl vybrán s ohledem na stávající rozložení, tak aby zapadal do aplikace Archibus. Konfigurace config/context/remoting/examples/webservice-cxf/webservices.xml je konfiguraˇcním nastavením Spring rámce a slouží k nastavení webové služby AWS. Vlastní autentizaˇcní schéma se mimo jiné skládá z dvojitého hašování. Primární otisk hesla je vytvoˇren v klientské aplikaci pˇred jeho odesláním WS, jelikož odesílat heslo v otevˇreném tvaru i pˇres zabezpeˇcenou komunikaci muže ˚ být považovano za potencionálnˇe nebezpeˇcné. Pro tyto potˇreby slouží hašovací funkce MD5. Tento jednoduchý haš je po pˇrijetí zpracován implementovaným PBKDF2 algoritmem s použitím soli a nˇekolika sty iteracemi. Poté dojde k samotné akci, tj. porovnání cˇ i uložení záznamu uživatele v tabulce afm.mobile_users. ArchibusWebServiceImpl nese veškeré metody definované v návrhu. Metoda echo provede jednoduchý dotaz do databáze, aby zjistila, jestli bˇeží a podle toho vrátí výsledek, neprovádí se žádná autentizace. Metoda login provádí pˇrihlášení uživatele, internˇe se volá metoda processAuth, kde se pˇri shodˇe vytvoˇrí sezení – zavedení záznamu pro uživatele do SessionManager s cˇ asovou známkou vytvorˇ ení a posledního pˇrístupu sezení (SessionManager.createSession). Pokud je vytvoˇreno sezení, jsou dále naˇcteny provozní informace pro klientskou aplikaci a zaobaleny do formátu JSON. V pˇrípadˇe jakékoliv chyby nebo nenalezení shody s uživatelem je vrácena chybová hláška taktéž ve formátu JSON. Pˇrihlašovací vstupní údaje pro metodu login jsou pˇrenášeny v HTTP hlaviˇcce pod klíˇcem „userid“ a „password“, taktéž informace o sezení jsou klientovi vráceny v hlaviˇcce. Používá se HttpSession sezení, kdy dochází k sestavení sezení klienta s aplikaˇcním serverem, toto sezení pak pouze z hlediska aplikace „moderujeme“ a kontrolujeme dle potˇreb. Díky této technice a použití Apache CXF a Apache HTTPD serveru je zajištˇena plná kompatibilita. K doˇcasnému uchování a kontrole tˇechto sezení slouží SessionManager. Duležitým ˚ po51
7. I MPLEMENTACE mocníkem jedináˇcka SessionManager je uklízecí vlákno CleanUpThread, které v cˇ asových intervalech kontroluje a pˇrípadnˇe maže (SessionManager.deleteSession) neaktivní sezení. Další metody WS: openTask, resolveTask, getHistory, getActiveTasks, getUserTasks, getTaskDetail, getEquipmentDetail mají velice podobný prubˇ ˚ eh. V první rˇ adˇe je provedeno ovˇerˇ ení aktivního sezení, interní metodou checkAuth, kde dochází k dohledání, kontrole a pˇrípadné aktualizaci záznamu sezení (SessionManager.updateSession). Pokud není potvrzen pˇrístup, dojde k vyhození výjimky AuthFailedException a odeslání chybové hlášky klientovi ve formátu JSON. V opaˇcném pˇrípadˇe dojde k delegování rˇ ízení dalšího bˇehu dle vstupních údaju˚ skrze TransactionManager.processTransaction. TransactionManager.processTransaction provede nejprve prvotní kontrolu vstupních údaju˚ a následuje výbˇer konkrétní instance rozhraní Handler a abstraktní tˇrídy TransactionHandler pomocí HandlerFactory.getHandler. Následující zpracování transakce je uˇcinˇeno zavoláním metody Handler.handle. Jak již bylo uvedeno, tuto metodu absorbuje abstraktní tˇrída TransactionHandler a pokraˇcování je závislé na konkrétních implementacích abstraktních metod preHandle a handleSpecific. Metoda preHandle slouží k dusledné ˚ kontrole vstupních parametru, ˚ pokud nelze pokraˇcovat z duvodu ˚ nevalidnosti dat, je vyhozena výjimka TransactionException. Klíˇcovou fází je volání metody handleSpecific, kde dochází ke zpracování vstupních údaju˚ a konkrétnímu dotazu do DB. Výsledek je pˇreveden do formátu JSON, k tomuto nabízí tˇrída TransactionHandler svým potomkum ˚ metody: getDataRecordJSON, getDataRecordsJSON a createFaultJSON. Tyto metody provádˇejí vytvoˇrení JSON objektu dle dostupných informací a vrací jej jako objekt typu String. OpenTaskHandler slouží k otevˇrení požadavku v systému Archibus. Pˇrijímá objekt AWSRequest, který je vytvoˇren na základˇe pˇrijatých informací ve formátu JSON: kód zaˇrízení, kód budovy, typ chyby atd. Kontrola se provádí na základˇe detekce atributu, ˚ bez kterých nelze požadavek zpracovat. Metoda handleSpecific využívá DatabaseManager.createWorkRequest pro komunikaci s databází. Na základˇe obdržených informací provede vytvoˇrení odpovˇedi a její vrácení. ResolveTaskHandler je pomˇernˇe podobná pˇredchozímu pˇrípadu 52
7. I MPLEMENTACE a slouží k dokonˇcení požadavku. Opˇet pˇrijímá objekt AWSRequest, ale využívá atributy potˇrebné pro svou cˇ innost: zpusob ˚ opravy, zjištˇená pˇríˇcina selhání atd. Tyto atributy jsou zkontrolovány v metodˇe preHandle a využity pro dotaz do DB v metodˇe handleSpecific. Tato metoda využívá DatabaseManager.resolveWorkRequest a poté stejným zpusobem ˚ vytváˇrí a vrací odpovˇed’ pro klienta. ListTaskHandler je souhrnná tˇrída pro dotazy, které chtˇejí seznam požadavku. ˚ Pˇrijímán je objekt AWSListExtension, kde se podle atributu Boolean close specifikuje, jaký seznam je požadován. Pokud je hodnota null, jedná se o požadavek na seznam požadavku˚ uživatele (DatabaseManager.getTasksByUser). Pokud je hodnota true, jedná se o požadavek na seznam zavˇrených požadavku˚ zaˇrízení (DatabaseManager.getClosedTasksByEquipment) a pokud false, tak seznam požadavku˚ otevˇrených pro dané zaˇrízení (DatabaseManager.getActiveTasksByEquipment). Navrácený seznam je pˇreveden na JSON a poslán zpˇet. DetailTaskHandler je podobnˇe jako pˇredchozí pˇrípad souhrnná tˇrída pro požadavky na detailní informace o zaˇrízení nebo požadavku. Pˇrijímán je objekt AWSDetailExtension a dle hodnoty atributu boolean equipment jsou navráceny informace o konkrétním zaˇrízení (equipment = true; DatabaseManager.getEquipmentDetail) nebo o konkrétním požadavku (equipment = false; DatabaseManager.getTaskDetail). Poslední duležitou ˚ komponentou implementace je DatabaseManager, který obsahuje zmínˇené metody u konkrétních zpusob ˚ u˚ použití. Konkrétní metoda pro svou cˇ innost použije adekvátní databázový zdroj (DataSource) a poté provede požadavek do databáze. Zde dochází také k pˇrísnému dodržení pravidla ACID (atomicita, konzistence, izolovanost, trvalost), proto pokud dojde k výpadku cˇ i chybˇe pˇredevším pˇri vkládání nebo úpravˇe, je proveden rollback operace. Výsledky jsou nazpˇet vráceny ke zhodnocení a zpracování, zdroje jsou získávány z DatabaseHelper.
7.3
Vývojové prostˇredí platformy Android
Mezi primární programátorský prostˇredek vývoje bezpochyby patˇrí vývojové prostˇredí (IDE). Koncem roku 2014 bylo vydáno oficiální 53
7. I MPLEMENTACE vývojáˇrské prostˇredí pro OS Android – Android Studio od spoleˇcnosti Google. S Android Studiem a projekty v nˇem je spjat nový sestavovací (build) nástroj Gradle. Hlavní výhodou Gradle je to, že je postaven na jazyce Groovy tedy principu DSL - Domain Specific Language - specializovaný skriptovací jazyk. Skript tedy není oproti tradiˇcnímu Ant nebo Maven cˇ istˇe deklarativní, ale tvoˇrí kombinaci deklarativních a imperativních konstrukcí. Tyto soubory se oznaˇcují postfixem *.gradle a umožnují ˇ tvoˇrit funkˇcní projektovou hierarchii pro zjednodušení a jasnou pˇrehlednost. Gradle je stejnˇe mocný nástroj jako Ant nebo Maven, ale jeho použití je jednodušší a pˇrehlednˇejší, což pˇridává dodateˇcnou hodnotu aplikacím vytváˇreným v prostˇredí Android Studio. První velmi duležitou ˚ knihovnou použitou v aplikaci je ZXing („zebra crossing“). Jedná se o open-source cˇ teˇcku cˇ árových kódu, ˚ která zvládá velké množství existujících formátu˚ cˇ árových kódu˚ vˇcetnˇe QR kódu. ˚ Naˇctení a zpracování kódu je implementováno v jazyce Java a je poskytnuto jako API pro další jazyky. V souˇcasné dobˇe je využití ZXing podmínˇeno instalací aplikace do zaˇrízení poskytujícího funkcionalitu fotoaparátu a souˇcinných procesu. ˚ To je nevhodné, jelikož chceme mít samostatnou a nezávislou aplikaci, proto je použito rozšíˇrení ZXing od dm77 (konfigurace: me.dm7.barcodescanner:zxing:1.6.3), umožnující ˇ oproštˇení od této závislosti. Druhou neménˇe duležitou ˚ použitou knihovnou je kSoap2 (konfigurace: com.google.code.ksoap2-android:ksoap2-android:3.3.0). Jedná se o specializovanou knihovnu od spoleˇcnosti Google, která pˇrináší podporu webových služeb (SOAP) v prostˇredí Android. Bez této knihovny nelze konceptuálnˇe naplnit požadavek používání webových služeb v aplikaci SUKB Archibus Asistent, a proto je její použití nezbytné. Emulátory jsou duležité ˚ pro první fázi testování bˇehem vývoje pro zjištˇení nejzávažnˇejších chyb a nedostatku˚ pˇred instalací aplikace do reálných zaˇrízení. V projektu byl použit profesionální emulátor - GenyMotion. Tento emulátor zaˇrízení s OS Android je vytvárˇ en jako virtuální stroj. Emulátor využívá x86 virtualizaci, takže je mnohem efektivnˇejší a s využitím hardwarové akcelerace OpenGL lze testovat i 3D aplikace s dostateˇcným výkonem. Dále GenyMotion vyˇcnívá svou jednoduchostí a pˇrívˇetivým uživatelským rozhraním, u vytvoˇreného emulátoru lze simulovat ruzné ˚ senzory, stav baterie, 54
7. I MPLEMENTACE GPS a další parametry, navíc lze jej používat zdarma.
7.4
Implementace Android aplikace
Ihned po vytvoˇrení projektu v Android Studiu bylo základní povinností nastavit sestavovací konfiguraˇcní soubor Gradle build.gradle, kterým jasnˇe definujeme závislosti a základní nastavení aplikace. Opomenut není ani nástroj ProGuard pro zvýšení bezpeˇcnosti. Mimo zmínˇené knihovny jsou do projektu injektovany také pomocné knihovny pro zjednodušení vývoje. Dále bylo nutné nastavit primární soubor aplikace AndroidManifest.xml, kde se definují požadovaná povolení, nastavení ikonky aplikace, názvu aplikace, celkového vzhledu a pˇredevším definice aktivit povolených v aplikaci s urˇcením té vstupní. Koˇrenový balíˇcek pro implementaci této aplikace je cz.muni.fi.jb.sukbaa. Tento balíˇcek se dále dˇelí na cz.muni.fi.jb.sukbaa.frontend, kde nalezneme prvky týkající se obsluhy aktivit a fragmentu, ˚ a cz.muni.fi.jb.sukbaa.backend, kde najdeme vše potˇrebné k webovým službám od vytváˇrení požadavku po jeho odeslání. Vstupní aktivitou aplikace je LoginActivity, na kterou nejsou vázané žádné fragmenty. Související layout zobrazuje jednoduchý pˇrihlašovací formuláˇr. Pro odeslání požadavku je využita tˇrída ServiceCaller s argumentem LoginRequest. Podle zpusobu ˚ odpovˇedi je uživatel informován o chybˇe nebo dojde k naˇctení iniciálních informací a uživatel je smˇerován na MainActivity. MainActivity je páteˇrí aplikace využívající velké množství fragmentu. ˚ Pokud uživatel pracuje na pˇrístroji s menším rozlišením, aplikace na displeji stˇrídá pouze jeden fragment (poˇcáteˇcní je MainFragment). Pokud je rozlišení vˇetší, dojde k rozdˇelení obrazovky na dvˇe cˇ ásti v pomˇeru 1:2, kde levá cˇ ást (1 díl) je urˇcena menu aplikace (MainFragment) a zbylé 2 díly odpovídajícímu aplikaˇcnímu rˇ azení obrazovek dle zvolené akce. MainActivity aplikuje následující fragmenty: • BlankFragment – „Prázdný“ fragment urˇcený k vyplnˇení prostoru pˇri startu aplikace, pokud dojde k rozdˇelení 1:2 a dokud uživatel nezvolí nˇejakou akci. 55
7. I MPLEMENTACE • MainFragment – Hlavní menu aplikace tvoˇreno cˇ tyˇrmi tlacˇ ítky pro volbu akce, tato tlaˇcítka definují naši vlastní metodu android:onClick = onClickButton, kterou zaštit’uje MainActivity. MainFragment definuje rozhraní OnScannerInvoke, které musí MainActivity implementovat a slouží k upozornˇení, že došlo v MainFragment k akci, která má vyvolat ScannerActivity. Po naˇctení kódu následuje komunikace se serverem pomocí ServiceCaller s objektem StringRequest, pokud není uvedeno jinak. • OpenFragment – Jedná se o fragment, který nese logiku otevˇrení požadavku v systému Archibus. Po zadání vstupních údaju˚ a jejich kontrole dochází k upozornˇení MainActivity za pomoci OnItemOpen rozhraní, které musí opˇet MainActivity implementovat. V této implementaci dochází k zavolání ServiceCaller s objektem AWSRequest. • TaskListFragment - Slouží k zobrazení seznamu požadavku˚ pˇrijatých ze serveru. Zde se zpracují a pˇrehlednˇe zobrazí. Po stisknutí na požadavek je opˇet informován o této skuteˇcnosti MainActivity za pomoci implementování rozhraní OnItemClicked a pˇrepnutí do DetailFragment. • DetailFragment – Zapouzdˇruje zobrazení detailních informací o požadavku s tím, že pokud je požadavek otevˇrený, umožní jeho uzavˇrení. Pokud dojde k požadavku na uzavˇrení, je opˇet informován MainActivity za pomocí implementování rozhraní OnItemClickedForResolve a dojde k zobrazení ResolveFragment. • ResolveFragment – Obstarává formuláˇr a logiku pro dokoncˇ ení otevˇreného požadavku. Po vyplnˇení potˇrebných údaju˚ je tento požadavek opˇet pˇredán MainActivity za pomoci implementování rozhraní OnItemResolve. K odeslání dochází za pomoci ServiceCaller a objektu AWSRequest.
MainActivity jako jediná má privilegium umožnit pˇrístup k cˇ teˇcce cˇ árových kódu˚ – pˇresun na ScannerActivity. ScannerActivity je urˇcena k obsluze cˇ innosti pˇri pˇrechodu na cˇ ekání a zpracování naˇctení QR kódu. Tato aktivita umožnuje ˇ zapnutí/vypnutí blesku pro osvˇetlení, 56
7. I MPLEMENTACE zapnutí/vypnutí automatické pˇriblížení a nastavení pˇrijímaných kódu. ˚ Právˇe pro zobrazení možnosti výbˇeru podporovaných kódu˚ je na tuto aktivitu navˇešen FormatSelectorDialogFragment. Do cˇ ásti „backend“ dá se za vstup považovat ServiceCaller. Tato tˇrída má duležitý ˚ úkol zpracovat konkrétní požadavek a pˇripravit zprávu webových služeb (objekt SoapObject), pro zjednodušení pˇrijímá typ požadavku, ˚ které jsou definovány ve výˇctovém typu AWSMethod, dále pak konkrétní implementaci ObjectToSend rozhraní. Tˇemi jsou LoginRequest pro pˇrihlášení (metoda login), AWSRequest pro otevˇrení cˇ i dokonˇcení požadavku (metoda openTask/resolveTask) a StringRequest pro ostatní jednoduché metody webové služby. Posledním vstupním argumentem metody ServiceCaller.call je vstupní aktivita, která oˇcekává pˇríjem odpovˇedi a implementuje rozhraní OnTaskCompleted. Zpracované informace jsou zapouzdˇreny do objektu MessageToSend a pˇredány HttpsSender. Objekt HttpsSender rozšiˇruje tˇrídu AsyncTask, tj. jedná se o asynchronní neblokující vlákno v systému. Komunikace webových služeb je blokující, a pokud by byla provádˇena v hlavním vláknˇe, systém by naši aplikaci oznaˇcil jako nežádoucí a násilnˇe ukonˇcil. HttpsSender provádí sestavení spojení a odeslání konkrétní zprávy. Jelikož je akce provádˇena asynchronnˇe, je dotyˇcná aktivita informována o výsledku komunikace díky implementaci rozhraní OnTaskCompleted definující HttpsSender po jejím dokonˇcení. Pokud se provádí pˇrihlášení, je nutné uložit do CookieManager identifikátor vytvoˇreného sezení HttpsSession pro další použití. Informace jsou dále zpracovávány a vˇetšinou vedou ke zmˇenˇe fragmentu. Pˇri rozdˇelení tˇechto informací se používá pomocných tˇríd: Equipment, WorkRequest, CauseTypeHolder, ProbTypeHolder, RepairTypeHolder.
57
8 Testování, nasazení a evaluace Po provedení implementaˇcní cˇ ásti pˇrichází pro každou aplikaci fáze evoluce, kdy probíhá její testování, nasazení do ostrého provozu a údržba. Bˇehem dubna 2015 bylo provedeno testování aplikace SUKB Archibus Asistent na reálných zaˇrízeních a následnˇe k zahájení testovacího provozu ze strany SUKB za úˇcelem doladˇení nežádoucích chyb a technických detailu. ˚ Tím také zaˇcal proces uˇcení z hlediska používání aplikace pracovníky SUKB a pˇríprava na nasazení systému do bˇežného provozu. Tento pˇrechod ovšem není okamžitý a jednoduchý. Mimo potˇreby testování a doladˇení je nutné, aby Správa Univerzitního kampusu Bohunice zajistila potˇrebnou infrastrukturu v podobˇe zavedení QR kódu˚ na všechna zaˇrízení a plnou integraci potˇrebných informací do systému Archibus. Uvedení aplikace do standardního režimu je naplánováno na konec léta tohoto roku (2015) a je plnˇe na rozhodnutí pˇríslušného vedení. Z hlediska hodnocení krátkodobých výsledku˚ byla užiteˇcná zpˇetná vazba v podobˇe informací o efektech používání aplikace. Testovací provoz dosud odhalil nˇekolik drobných nedostatku, ˚ které byly dodateˇcnˇe opraveny. Testování také ukázalo pomˇernˇe vysokou odolnost aplikace a spolehlivost. Ovšem je pˇredbˇežné hovoˇrit o úspˇechu, jelikož stále nedošlo k ukonˇcení testovacího provozu a nelze pˇredstavit stˇrednˇedobou cˇ i dlouhodobou evaluaci. Faktem zustává, ˚ že již dostupná evaluace poskytuje znaˇcný vhled do programu a jeho kontrolu pro zajištˇení legitimity a dalšího rozvoje na pudˇ ˚ e Masarykovy univerzity.
59
9 Závˇer Práce pˇrináší souhrn informací z oblastí facility managementu, bezpeˇcnosti a webových služeb. Požadovaných cílu˚ bylo dosaženo kvalitní pˇrípravou a nastudováním souvisejících témat. Práce se opírá o hodnotnou a detailnˇe zpracovanou analýzu – analýza požadavku, ˚ analýza bezpeˇcnostních rizik a analýza pracovního procesu. Toho bylo dosaženo komunikací a vzájemnou spoluprací se zákazníkem, bˇehem které došlo k vyjasnˇení pˇredstav a synchronizaci vzájemných myšlenek, tak aby byly naplnˇeny pˇredstavy SUKB. Provedená analýza požadavku, ˚ analýza procesu údržby a bezpeˇcnostní analýza pˇrispˇela k jednoduššímu a efektivnˇejšímu návrhu webových služeb a aplikace pro operaˇcní systém Android. Z návrhových diagramu˚ tˇríd byla zhotovena implementaˇcní cˇ ást této práce. V té dále bylo využito všech dostupných technologií a programátorských technik pro naplnˇení celkových (funkˇcních i nefunkˇcních) požadavku˚ a splnˇení zadání této diplomové práce. Podporu v realizaci stanovených cílu˚ shledávám v použití nadstandardních nástroju˚ v podobˇe emulátoru GenyMotion, knihoven kSoap2 a ZXing a technik, napˇríklad použitím neblokujícího asynchronního vlákna pro blokující synchronní komunikaci. Na stranˇe webových služeb došlo k využití stávajících prostˇredku˚ systému Archibus, jakou jsou webové služby Apache CXF. Zárovenˇ byla provedena implementace vlastního autentizaˇcního schématu, založeného na dvojitém hašování s pokroˇcilou hašovací funkcí PBKDF2. Po dokonˇcení testovacího provozu by mˇel být benefit terénní aplikace pro SUKB okamžitý a trvalý. Primární praktický pˇrínos projektu tkví ve zvýšení mobility pracovníka údržby a snížení jeho administrativy. Dále aplikace umožnuje ˇ eliminovat možné chyby a pˇredevším zefektivnit proces údržby. Proto vˇerˇ ím, že se aplikace stane nedílnou souˇcástí procesu údržby a facility managementu na Masarykovˇe univerzitˇe. Aplikace umožnuje ˇ lepší a rychlejší kooperaci, naˇcítání identifikaˇcních QR kódu˚ zaˇrízení a je zcela kompatibilní pro hlášení a rˇ ešení událostí vyžádané údržby, potažmo rˇ ešení požadavku˚ vzniklých údržbou plánovanou. I pˇres splnˇení všech bodu˚ zadání a definovaných požadavku˚ má projekt další potenciál k rozšíˇrení svých poskytovaných služeb a roz61
ˇ 9. Z ÁV ER
voji stávající funkcionality. Mezi vize dalšího ubírání aplikace by bylo možné zaˇradit pˇridání funkcí, jakými jsou poskytnutí a zobrazení aktivních požadavku˚ pro konkrétní lokaci nebo pˇresun majetku po areálu Univerzitního kampusu. Výsledkem této práce je funkˇcní terénní aplikace pro pracovníky Správy Univerzitního kampusu s vlastními integrovanými webovými službami v systému Archibus a velkými ambicemi.
62
10 Grafické podklady
Obrázek 10.1: Porteruv ˚ diagram hodnotového rˇ etˇezce, upravený pro FM; zdroj: [1, str. 28].
63
10. G RAFICKÉ PODKLADY
Obrázek 10.2: Sladˇení oblastí FM - synergie 3P (Pracovníci, Procesy, Prostory); zdroj: [1, str. 15].
Obrázek 10.3: Cost-Benefit Analysis (CBA): Analýza nákladu˚ a pˇrínosu˚ bezpeˇcnosti; zdroj: [6, str. 4].
64
10. G RAFICKÉ PODKLADY
Obrázek 10.4: Procesy rˇ ízení bezpeˇcnosti dle Information Technology Infrastructure Library (ITIL); zdroj: [6, str. 4].
Obrázek 10.5: Top 10 rizik pro mobilní aplikace dle OWASP; zdroj: Jason Haddix, [7]. 65
10. G RAFICKÉ PODKLADY
Obrázek 10.6: Zjednodušené schéma reakce na bezpeˇcnostní incident; zdroj: autor.
66
10. G RAFICKÉ PODKLADY
Obrázek 10.7: Tabulka cˇ asové nároˇcnosti prolomení hesla na bˇežném poˇcítaˇci na základˇe délky hesla (n) a velikosti vstupní abecedy (c); zdroj: uˇcební materiály prof. RNDr. Vaška Matyáše [10].
Obrázek 10.8: Grafické znázornˇení principu „Bind-Publish-Find“; zdroj: [14, str. 18].
67
10. G RAFICKÉ PODKLADY
Obrázek 10.9: Architektura webových služeb (Web Service Architecture; WSA) zasazená do kontextu komunikaˇcního schématu; zdroj: [14, str. 34].
68
10. G RAFICKÉ PODKLADY
Obrázek 10.10: Schéma vytváˇrení požadavku˚ údržby v souˇcinnosti se systémem Archibus; zdroj: interní dokument MU.
69
10. G RAFICKÉ PODKLADY
Obrázek 10.11: Stavový diagram životního cyklu požadavku v systému Archibus; zdroj: autor, použit nástroj Creately.com.
Obrázek 10.12: Rozbor identifikaˇcního kódu zaˇrízení MU; autor: Adam Kuˇcera.
70
10. G RAFICKÉ PODKLADY
Obrázek 10.13: Detail polohového kódu zaˇrízení MU; autor: Adam Kuˇcera.
Obrázek 10.14: Ukázka nového QR identifikaˇcního kódu s titulkem; zdroj: autor, použit nástroj http://blog.qr4.nl/Batch-QR-Code.aspx.
71
10. G RAFICKÉ PODKLADY
Obrázek 10.15: Diagram datových toku; ˚ zdroj: autor, použit nástroj Creately.com.
72
10. G RAFICKÉ PODKLADY
Obrázek 10.16: Entitnˇe relaˇcní diagram; zdroj: autor, použit nástroj Creately.com. 73
10. G RAFICKÉ PODKLADY
Obrázek 10.17: Diagram tˇríd integrované služby v systému Archibus; zdroj: autor, použit nástroj Visual Paradigm.
74
10. G RAFICKÉ PODKLADY
Obrázek 10.18: Diagram tˇríd mobilní aplikace, cˇ ást 1 - „frontend“; zdroj: autor, použit nástroj Visual Paradigm.
75
10. G RAFICKÉ PODKLADY
Obrázek 10.19: Diagram tˇríd mobilní aplikace, cˇ ást 2 - „backend“; zdroj: autor, použit nástroj Visual Paradigm. 76
10. G RAFICKÉ PODKLADY
Obrázek 10.20: Obecný sekvenˇcní diagram zpracování požadavku údržby integrovanou webovou službou; zdroj: autor, použit nástroj Visual Paradigm. 77
10. G RAFICKÉ PODKLADY
Obrázek 10.21: Logo Android aplikace Archibus Asistent; zdroj: autor, použit http://romannurik.github.io/AndroidAssetStudio/iconslauncher.html.
SUKB nástroj
Obrázek 10.22: Prototyp obrazovek aplikace SUKB AA; zdroj: autor, použit nástroj Balsamiq Mockups. 78
11 Pˇríloha Souˇcástí této diplomové práce je taktéž vyvinutý zdrojový kód. Tento zdrojový kód je dostupný v Informaˇcním systému MU, kam byl vložen pˇri odevzdání této práce.
A
Specifikace pˇrípadu˚ užití
Specifikace případů užití projektu SUKB AA Příloha A, součást diplomové práce
Diagram případů užití
Název
Hodnota
Název
Diagram případů užití
Autor
Jaromír Benda
Vytvořil - období
Březen 2015
Poslední upravené
Duben 2015
Specifikace Název Uživatel
Popis Pracovník údržby SUKB, který má k dispozici mobilní zařízení s aplikací, internet a zařízený přístup do aplikace.
Systém Archibus
Podpůrný systém Facility managementu s integrovanými webovými službami.
UC08 B01: Zobrazit výsledek
Krátký popis Use case umožňuje zpětnou vazbu uživateli po provedení jakékoliv akce. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace a je připojen k internetu. Základní tok 1.
Uživatel provede některou z akcí.
2.
Aplikace odešle požadavek do systému Archibus.
3.
Systém Archibus zašle odpověď s výsledkem operace.
4.
Tyto informace jsou zobrazeny uživateli.
Podmínky pro dokončení Přijmutí odpovědi ze systému Archibus. UC07 B00: Použít čtečku čár. kódů
Krátký popis Use case umožňuje načtení QR kódu zařízení pomocí zadní kamery mobilního zařízení. Aktéři
Uživatel
Aplikace
Podmínky pro spuštění Uživatel je přihlášen do aplikace a mobil má zadní kameru. Základní tok 1.
Uživatel zvolí některou z akcí (UC02, UC04, UC06).
2.
Uživateli se zobrazí prostředí pro načtení identifikačního kódu.
3.
Po načtení kódu, dojde k dotazu na potvrzení správného načtení.
4.
Po stisku OK dojde k navrácení k akci s načteným kódem.
Alternativní tok 1 1.1 Načtení kódu může předcházet jakékoliv akci. Alternativní tok 2 4.1 Po stisku Storno dojde k možnosti opětovného načtení kódu. Podmínky pro dokončení Načtení QR identifikačního kódu zařízení. UC06 A05: Zobrazit historii požadavků
Krátký popis Use case umožňuje prohlížení provedených požadavků u daného zařízení. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace a je připojen k internetu. Základní tok
1.
Uživatel klikne na Zobrazit historii.
2.
Uživatel pomocí čtečky čárových kódů dle UC07 načte kód zařízení.
3.
Po načtení kódu, dojde k zobrazení provedených požadavků.
4.
Po stisku se objeví detailní informace o požadavku.
Alternativní tok 1 2.1 Pokud uživatel načetl kód ještě před zvolením akce, bude dotázán, zdali ho chce využít. 2.2 Pokud uživatel neodmítne použít kód, tak se přejde na bod 3. Podmínky pro dokončení Provedení UC08. UC05 A04: Zobrazit otevřené požadavky uživatele
Krátký popis Use case umožňuje prohlížení otevřených požadavků u přihlášeného uživatele. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace a je připojen k internetu. Základní tok 1.
Uživatel klikne na Zobrazit aktivní požadavky uživatele.
2.
Dojde k zobrazení aktivních požadavků.
3.
Po stisku se objeví detailní informace o požadavku.
Alternativní tok 1 3.1 Uživatel může aktivní požadavek uzavřít dle UC03. Podmínky pro dokončení Provedení UC08. UC04 A03: Zobrazit otevřené požadavky zařízení
Krátký popis Use case umožňuje prohlížení otevřených požadavků u daného zařízení. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace a je připojen k internetu. Základní tok 1.
Uživatel klikne na Zobrazit aktivní požadavky.
2.
Uživatel pomocí čtečky čárových kódů dle UC07 načte kód zařízení.
3.
Po načtení kódu, dojde k zobrazení aktivních požadavků.
4.
Po stisku se objeví detailní informace o požadavku.
Alternativní tok 1 2.1 Pokud uživatel načetl kód ještě před zvolením akce, bude dotázán, zdali ho chce využít. 2.2 Pokud uživatel neodmítne použít kód, tak se přejde na bod 3. Alternativní tok 2 4.1 Uživatel může aktivní požadavek uzavřít dle UC03. Podmínky pro dokončení Provedení UC08. UC03 A02: Uzavřít požadavek
Krátký popis Use case umožňuje uzavření otevřených požadavků na údržbu. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace, je připojen k internetu a došlo k iniciaci UC04 nebo UC05. Základní tok 1.
Uživatel vybere ze seznamu požadavek, který chce uzavřít a klikne na Uzavření otevřeného požadavku.
2.
Uživatel vyplní odpovídající formulář a jeho potvrdí jeho zpracování.
3.
Aplikace přijme požadavek a přepošle na systém Archibus, který zvaliduje data od uživatele.
4.
Archibus odpoví v rámci UC08 a uživatel je obeznámen s výsledkem akce.
Podmínky pro dokončení Provedení UC08. UC02 A01: Zadat požadavek
Krátký popis Use case umožňuje zadávání nových požadavků na údržbu. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel je přihlášen do aplikace a je připojen k internetu. Základní tok 1.
Uživatel klikne na Vytvoření nového požadavku.
2.
Uživatel pomocí čtečky čárových kódů dle UC07.
3.
Po načtení kódu, uživatel vyplní odpovídající formulář a jeho potvrdí
jeho zpracování. 4.
Aplikace přijme požadavek a přepošle na systém Archibus, který provede validaci dat od uživatele.
5.
Archibus odpoví v rámci UC08 a uživatel je obeznámen s výsledkem akce.
Alternativní tok 1 2.1 Pokud uživatel načetl kód ještě před zvolením akce, bude dotázán, zdali ho chce využít. 2.2 Pokud uživatel neodmítne použít kód, tak se přejde na bod 3. Podmínky pro dokončení Provedení UC08. UC01 A00: Přihlásit uživatele
Krátký popis Use case umožňuje přihlášení uživatele do systému. Aktéři
Uživatel
Aplikace
Systém Archibus
Podmínky pro spuštění Uživatel má nainstalovanou aplikaci, je připojen k internetu a zná své přístupové údaje. Základní tok 1.
Uživatel zapne aplikaci a zobrazí se stránka pro zadání přihlašovacích údajů.
2.
Uživatel vyplní své uživatelské údaje a formulář odešle.
3.
Aplikace přijme požadavek a přepošle na systém Archibus, který zvaliduje data od uživatele.
4.
Archibus odpoví v rámci UC08, dojde k sestavení Session a uživatel je přihlášen do aplikace.
Alternativní tok 1 4.1 - Archibus odpoví v rámci UC08. Pokud uživatel zadá špatné přístupové údaje nebo nemá oprávnění vstoupit do aplikace je odmítnut vstup do aplikace. Podmínky pro dokončení Provedení UC08. Aplikace
Aplikace SUKB Archibus Asistent pro Správu Univerzitního kampusu Bohunice.
B
Analýza rizik
Analýza rizik projektu SUKB AA
Technické zařízení
Server
Aplikace
3
3
4
4
Zpronevěření aktiv Neúmyslná modifikace Porucha hardware Odcizení zařízení Škodlivý kód Živelná pohroma Zpronevěření aktiv Živelná pohroma Porucha hardware Zpronevěření aktiv Živelná pohroma Cílený útok Interní hrozba
Existující opatření
Riziko
Mobilní zařízení
2
Dopad
QR kód
Selhání software Neúmyslná modifikace Ztráta dat Cílený útok
Pravděpodobnost incidentu
5
Chyba v DB
5
5
25
Nedostatečné školení
5
3
15
Selhání zálohování Selhání / Slabá úroveň zabezpečení
5 5
5 5
25 25
Podvržení QR kódu
18
2
36
Dvojité zálohování VPN, standardní bezpečnostní protokol X
Nedostatečné školení
16
2
32
X
Ztráta provedených akcí Neoprávněné použití aplikace Zařízení s malware Požár
7
3
21
Online záloha
20
3
60
X
9 2
3 1
27 2
Nedostatečná ochrana aktiv
9
3
27
Požár
2
1
2
Ztráta provedených akcí Nedostatečná ochrana aktiv
8
3
24
Antivirus Hasicí zařízení ve stropech Kamery, vstupní ověření identity, audit Hasicí zařízení ve stropech Online záloha
7
4
28
Požár
2
4
8
Selhání / Slabá úroveň zabezpečení Zneužití aplikace důvěryhodným zdrojem
25
4
100
Kamery, vstupní ověření identity, audit Hasicí zařízení ve stropech X
13
4
52
X
Zranitelnost
Hodnota
Databáze serveru
Hrozba
Aktivum
Příloha B, součást diplomové práce
Používaní prověřené DB Testovací provoz
Archibus
4
Selhání software Neúmyslná modifikace Cílený útok
Interní hrozba
Webové služby
5
Selhání software Neúmyslná modifikace Selhání komunikačních služeb
Zasílání nevalidních dat Nedostatečné školení
20
4
80
X
12
3
36
X
Selhání / Slabá úroveň zabezpečení
5
4
20
Zneužití aplikace důvěryhodným zdrojem Špatné zpracování dat
5
4
20
VPN, standardní bezpečnostní protokol AAA
5
2
10
Nedostatečné školení
5
2
10
Testovací provoz a certifikace Testovací provoz
Odposlechnutí komunikace
40
5
200
X
Narušení komunikace
30
4
120
X
Kategorizace rizik Hodnota 0-29 určuje akceptovatelné riziko, většinou již existují opatření, která minimalizují hrozbu. Hodnota 30-59 určuje mírné riziko, které může způsobit potíže. Hodnota 60-99 určuje nežádoucí riziko, které může způsobit vážné potíže. Hodnota větší než 100 určuje nepřijatelné riziko, které může způsobit existenční potíže.
Literatura ˇ [1] VYSKOCIL, Vlastimil K. Management podpurných ˚ procesu: ˚ facility management. 1. vyd. Praha: Professional publishing, 2010, 415 s. ISBN 978-807-4310-225. ˇ [2] VYSKOCIL, Vlastimil K. Facility management a Public private partnership. 1. vyd. Praha: Professional Publishing, 2007, 262 s. ISBN 978-80-86946-34-4. ˇ ˇ 1: Termíny a definice. [3] CSN/EN 15 221-1. Facility management - Cást ˇ Praha: Ceský normalizaˇcní institut, 2007. ˇ [4] CERMÁK, Miroslav. SmartAndClever: ment [online]. 2015 [cit. 2015-04-25]. <www.cleverandsmart.cz/>.
ICT manageDostupné z:
[5] O Úˇradu. ÚNMZ. Úˇrad pro technickou normalizaci, metrologii a státní zkušebnictví [online]. [cit. 2015-04-25]. Dostupné z: <www.unmz.cz/urad/o-uradu>. [6] GOGELA, Robert. Standardy a definice pojmu˚ ISMS. In: ISMS (ISO 2700x): sborník pˇríspˇevku˚ z bezpeˇcnostního semináˇre Policejní akademie a evropského vedení AFCEA konaˇ ného dne 22. záˇrí 2011 na Policejní akademii Ceské repubˇ liky v Praze. Vyd. 1. Praha: Policejní akademie Ceské republiky, 2011, s. 5. ISBN 978-80-7251-356-7. Dostupné z: <www.cybersecurity.cz/data/Gogela.pdf>. [7] OWASP. The Open Web Application Security Project [online]. 2015 [cit. 2015-04-25]. Dostupné z: <www.owasp.org> [8] MATYÁŠ, Vašek a Jan KRHOVJÁK. Autorizace elektronických transakcí a autentizace dat i uživatelu. ˚ Brno: Masarykova univerzita, 2008, 125 s. ISBN 978-802-1045-569. [9] MATYÁŠ, Václav. MASARYKOVA UNIVERZITA, Fakulta informatiky. Studijní materiály k pˇredmˇetu PV080: Ochrana dat a informaˇcního soukromí. Brno, 2012.
[10] MATYÁŠ, Václav. MASARYKOVA UNIVERZITA, Fakulta informatiky. Studijní materiály k pˇredmˇetu PV157: Autentizace a rˇízení pˇrístupu. Brno, 2013. [11] RFC 1321. The MD5 Message-Digest Algorithm. Cambridge, MA, USA: MIT Laboratory for Computer Science and RSA Data Security, Inc., 1992. Dostupné z: <www.ietf.org/rfc/rfc1321.txt>. [12] GOOGLE, Inc. Android Developers [online]. 2015 [cit. 2015-04-25]. Dostupné z: <www.developer.android.com>. [13] Pausing Google Play: More Than 100,000 Android Apps May Pose Security Risks: With Mobile Security Survey. BIT9. Bit9 bitten by hackers [online]. 2012 [cit. 2015-04-25]. Dostupné z: <www.bit9.com/research/pausing-google-play/>. [14] WEERAWARANA, Sanjiva. Web services platform architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and more. Upper Saddle River, NJ: Prentice Hall PTR, c2005, xxxix, 416 p. ISBN 01-314-8874-0. [15] BELL, Michael. Service-oriented modeling: service analysis, design, and architecture. Hoboken: Wiley, 2008, xvi, 366 s. ISBN 978-0-470-14111-3. [16] What Is SOA?. THE OPEN GROUP. The Open Group SOA Working Group [online]. [cit. 2015-04-25]. Dostupné z: <www.opengroup.org/soa/source-book/soa/soa.htm>. [17] W3C Web Service Glossary. WORLD WIDE WEB CONCORSIUM. WS Terms and Definitions [online]. 2004 [cit. 2015-04-25]. Dostupné z: <www.w3.org/TR/ws-gloss/>. [18] W3C Web Services Architecture. WORLD WIDE WEB CONCORSIUM. WSA Technical Standard [online]. 2004 [cit. 2015-04-25]. Dostupné z: <www.w3.org/TR/ws-arch/>. [19] CORBA Spec 3.3. OBJECT MANAGEMENT GROUP, Inc. Documents Associated with CORBA, 3.3 [online]. 2015 [cit. 2015-04-25]. Dostupné z: <www.omg.org/spec/CORBA/3.3/>.
