1 / 17 RENDSZERKONCEPCIÓ AZ ARHITEL PROJEKT MEGVALÓSÍTÁSI FÁZISÁNAK KERE- TÉBEN TERVEZETT KOMPLEX JOGÜGYLET-BIZTONSÁGI SZOLGÁLTATÁSOK NYÚJTÁSÁHOZ a Budapesti Ügyvédi Kamara részére 2014. január 23.
2 / 17 Dokumentumkontroll Projekt név: Dokumentum: Budapesti Ügyvédi Kamara Arhitel projekt Rendszerkoncepció az Arhitel projekt keretében tervezett komplex jogügylet-biztonsági szolgáltatások nyújtásához Verziókövetés Ver. szám Ver. Dátum Módosította Leírás File név v_1.0 2013.12.17. Molnár Viktor A dokumentum átadása első körös véleményezésre # v_1.1 2014.01.23. Molnár Viktor A dokumentum módosítása és átadása második körös véleményezésre v_1.2 2014.01.XX. Molnár Viktor A dokumentum véglegesítése
3 / 17 Tartalomjegyzék 1. BEVEZETÉS 4 1.1 Háttér 4 1.2 Terjedelem 4 2. AZ ARHITEL FELÉPÍTÉSE 5 2.1 Belső moduláris felépítés 5 2.2 Rendszerkapcsolatok 6 2.3 Technológiai alapvetések 6 3. FUNKCIONALITÁS FELSŐSZINTŰ BEMUTATÁSA 8 3.1 IDM modul 8 3.2 Riport modul 8 3.3 Logisztikai modul 9 3.4 Iratadat nyilvántartás 10 4. ADATMODELL 11 4.1 Entitások és relációik 11 5. INFRASTRUKTÚRÁLIS KONCEPCIÓ 13 5.1 Logikai infrastruktúra terv 14 5.2 Fizikai infrastruktúra terv 16 MELLÉKLETEK 17 A melléklet 17
4 / 17 1. BEVEZETÉS 1.1 HÁTTÉR A Magyar Ügyvédi Kamara (továbbiakban: MÜK) 2011 őszén az ügyvédek közreműködésével készülő okiratok és az ügyvédek közreműködésével zajló jogügyletek biztonságának növelését, és ezzel együtt az ügyvédi szakma közbizalmi szerepének erősítését célzó projekt (továbbiakban: Arhitel projekt) indításáról döntött. A projekt előkészítését a Budapesti Ügyvédi Kamara (továbbiakban: BÜK) vállalta fel. A projekt előkészítése a megvalósítási lehetőségek jogi, műszaki, pénzügyi elemzését célzó megvalósíthatósági elemzésével 2011-2012 fordulóján elkezdődött. 2013 őszén döntés született arról, hogy a mező- és erdőgazdasági hasznosítású föld tulajdonjogát érintő, ügyvédi ellenjegyzéssel készülő okiratokat biztonsági jellel (biztonsági címkével) kell ellátni, és a biztonsági jellel ellátott okiratokat nyilvántartásba kell venni 2014. május 1-től kezdődően. Döntés született arról is, hogy 2015. január 1-től az összes ügyvédi ellenjegyzéssel készülő okiratot el kell látni biztonsági jellel. 1 A projekt keretében a kapcsolódó jogszabályok, szabályozói elvárások és szándékok figyelembevételével specifikálni kell és be kell szerezni a tervezetten alkalmazandó biztonsági címkét, ki kell alakítani a címke nyilvántartásba vételét biztosító informatikai rendszert (továbbiakban Arhitel), valamint meg kell határozni a címke logisztikáját, aktiválását és elszámolását biztosító szolgáltatást és annak működtetését. 1.2 TERJEDELEM Jelen dokumentumban definiáljuk az Arhitel rendszer koncepcióját. Ennek keretében definiáljuk az Arhitel rendszer belső moduláris felépítését és kapcsolódását a jelenlegi informatikai környezetbe, javaslatot teszünk az alkalmazás infrastruktúrájára, felső szinten meghatározzuk a rendszer által nyújtandó szolgáltatások és funkciók körét, felső szinten bemutatjuk a támogatandó folyamat lefutását, definiáljuk a legfontosabb entitásokat és azok relációit. Az elkészült dokumentum a rendszertervezési és fejlesztési feladatok bázisa. 1 # A komplex jogügylet-biztonsági szolgáltatáshoz és az Ügynökség működtetéséhez kapcsolódó folyamatok tervezéséhez a következő jogszabálytervezetek és döntések szolgáltattak alapot: Az ingatlan-nyilvántartásról szóló 1997. évi CXLI. törvény (Inytv.) módosításának tervezete (T/13140. sz. törvényjavaslat); Az ügyvédekről szóló 1998. évi XI. törvény (Ütv.) módosításának tervezete (T/12824. sz. törvényjavaslat és T/12824/13. számú módosító javaslat). A BÜK 2013. november 4-i elnökségi ülésének határozatai: 2013. Eln. 470./12/14. számú határozat és 2013. Eln. 470./12/15. számú határozat az Ügynökség felállításáról és a komplex jogügylet-biztonsági szolgáltatásból származó bevételek felhasználásáról.
5 / 17 2. AZ ARHITEL FELÉPÍTÉSE Az alábbiakban az Arhitel rendszer javasolt belső moduláris felépítését és külső rendszerkapcsolatait mutatjuk be. 2.1 BELSŐ MODULÁRIS FELÉPÍTÉS A logisztikai nyilvántartás feladata a matricák igénylés, gyártás, szállítás, átvétel, átadás, érvényesítés folyamatainak támogatása. Az iratadat adat nyilvántartás lehetőséget ad előre meghatározott irattípusokhoz (pl. ellenjegyzett okirat, meghatalmazás) kapcsolódó ellenjegyzési tranzakciók rögzítésére, módosítására, matrica összerendelések megadására, karbantartására. A nyilvántartási modult úgy szükséges megtervezni, hogy az a későbbiekben lehetőséget biztosítson további tranzakcióhoz kapcsolódó adatok (pl. irat adatok, iratkép) tárolására is. A letét nyilvántartás és mérlegbeszámoló rögzítési modul kialakítására későbbi fázisokban kerülhet sor, azok részletes tervezése nem képezi jelen logikai rendszerterv szkópját. Az Arhitelben a II. fázis bevezetése során elektronikus számlázási és fizetési megoldást is szükséges bevezetni. Az e-számlázás megvalósítása egy külső modul segítségével történik, ehhez az Arhitelnek integrálódnia szükséges. Az e-fizetés megvalósításához kártyás fizetési szolgáltatáshoz szükséges integrálódni (pl. banki megoldások), illetve egy a pénzügyi nyilvántartások segítségével kialakított virtuális egyenleg szolgáltatáshoz is kapcsolódni szükséges. A nyilvántartási funkciók egységes megvalósítását, működését, a modulok együttműködését, illetve a kapcsolódó egyéb szolgáltatások (pl. egységes kódszótár, naplózás, munkafolyamat támogatás) egy erre a célra kialakított keretrendszernek szükséges biztosítania. A keretrendszernek egységes törzsadatkezelést is biztosítania kell a modulok számára. Ehhez interfészeket szükséges kialakítani az IDM és azon keresztül az e-lexiosz alkalmazások fele, illetve a kapcsolódó adatszinkronizációs mechanizmusokat is biztosítani kell. A modulokban elvégzett műveletekről üzleti és technikai szintű naplóbejegyzéseket szükséges vezetni. Ezt a funkcionalitást egy a keretrendszer részét képező naplózási modul biztosítja a nyilvántartások számára. Az Arhitel tartalmaz egy publikus és egy belső riport modult. A publikus segítségével az internetes ügyfelek végezhetnek el publikus lekérdezéseket (pl. matrica státuszok, illetve nyilvántartási adatok lekérdezése meta adatok kombinációja alapján). A publikus lekérdező felületet elkülönítetten került kialakításra. A belső riport modul célja többrétű: lehetőséget biztosít aggregált információk (készletadatok, megrendelés státuszok, stb.) futtatására, illetve lekérdezhetők belőle az egyes nyilvántartások adatai, matricák státuszok, felhasználókkal, felhasználói adatokkal, aktivitással, általuk elvégzett műveletekkel kapcsolatos információk.
6 / 17 2.2 RENDSZERKAPCSOLATOK A rendszer alapján az elexios.hu nyilvántartás részét képező ügyvéd, ügyvédi iroda, ügyvédi asszisztens törzs adja. Az elexios.hu feladata ezen törzsadatok rögzítésének, módosításának, illetve az egyes entitások közötti relációk karbantartásának támogatása. Az Arhitel rendszer authentikációs, authorizációs, session kezelési szolgáltatásait egy külső Identity Management (IDM) modul biztosítja. Az IDM rendszert úgy szükséges kialakítani, hogy az lehetőséget biztosítson az Arhitel mellett más nyilvántartások IDM jellegű funkcióinak támogatására is. Az IDM modul feladata: a hagyományos felhasználó neves, jelszavas, kártyás-, illetve integrált ügyfélkapus authentikáció támogatása is. A beérkező adatok nyilvántartásakor ezenkívül időbélyegző, illetve elektronikus aláírási szolgáltatásokat (pl. elektronikusan aláírt kérelmek érkeztetése, aláírás ellenőrzés, stb.) is szükséges biztosítani, illetve a későbbiekben opcionális a nyilvántartási adatok elektronikus archiválása is felmerül igényként. Az ezekhez kapcsolódó támogató szolgáltatásokat egy speciálisan erre a célra kialakított modul végzi. Az IDM-hez hasonlóan ennél a modulnál is elvárás, hogy az Arhitelen kívül más nyilvántartások számára is biztosítani tudja ezeket a szolgáltatásokat. Az Arhitelnek a pénzügyi nyilvántartáshoz is kapcsolódnia szükséges. Ez az interfész szolgál a matricák átvételéhez kapcsolódó pénzügyi tranzakciók rögzítésére, követésére, illetve a későbbiekben az elektronikus számlázási és fizetési funkcionalitás megvalósítására. Egy archiváló modult is szükséges kialakítani, amelynek feladata a nyilvántartások adatainak, illetve a nyilvántartások használatával kapcsolatos naplóbejegyzéseknek az archiválása. Amennyiben a későbbiekben egy teljesen elektronikus archiválási megoldás kerül kialakításra, akkor ezt a szolgáltatást az archiváló modulnak az elektronikus aláíró modullal közösen szükséges biztosítania. Az Arhitelnek a fentieken túl további BÜK-ös nyilvántartásokhoz (pl. JogTudor, Kamarai Ügyintézés) is szükséges csatlakoznia. Ezeknek az interfészeknek a pontos célját és leírását a projekt későbbi fázisában szükséges meghatározni. 2.3 TECHNOLÓGIAI ALAPVETÉSEK Az Arhitel rendszer felhasználói oldalról egy klasszikus vékony klienses megoldás, a rendszert használó szereplők azt böngésző felületen keresztül érik el. Bizonyos technikai funkciók, támogató szolgáltatások megvalósításához (pl. offline riportok előállítása) vastag klienses megoldásokat (batch, service) is szükséges alkalmazni. A modulok fejlesztését klasszikus többrétegű architektúra szerint szükséges elvégezni, az adatkezelő, az üzleti logika és megjelenítési rétegeket egyértelműen külön kell választani.
7 / 17 7 / 17 Ábra: Az ARHITEL rendszer moduláris felépítése
8 / 17 3. FUNKCIONALITÁS FELSŐSZINTŰ BEMUTATÁSA 3.1 IDM MODUL Az alábbi ábra az IDM modul által megvalósítandó szolgáltatásokat, funkciókat mutatja be. uc IDM modul - Áttekintés Naplózás Felhasználó, csoport, szerepkör, szolgáltatás menedzsment Bej elentkezés Bejelentkezés egyszer használatos felhasználónév v el, «extend» kódszóval jelszóval Felhasználó és session információk lekérdezése «include» Lekérdezés Authentikáció Ügyfélkapu authentikáció Felhasználó szerepkörök lekérdezése «include» Authorizáció IDM modul Tanúsítv ány alapú authentikáció «include» «include» Szerepkör kijelölés Session ID v alidálás «include» Session kezelés Idıbélyegzéssel kapcsolatos szolgáltatások «include» «include» Session ID generálás Session, felhasználó, szerepkör, szolgáltatás összerendelés Ábra: IDM modul legfontosabb funkcióinak bemutatása 3.2 RIPORT MODUL cmp Lekérdezések Felhasználó által elv égzett események lekérdezése Matrica lekérdezések Felhasználó, csoport, szerepkör, szolgáltatás relációv al kapcsolatos lekérdezések Lekérdezés Nyilv ántartási adatok lekérdezése Iroda adatokkal kapcsolatos lekérdezések Felhasználó adatokkal kapcsolatos lekérdezések Ábra: Alapvető lekérdezés típusok
9 / 17 3.3 LOGISZTIKAI MODUL Az alábbi ábra az modul által megvalósítandó szolgáltatásokat, funkciókat mutatja be. Ábra: Logisztikai modul legfontosabb funkcióinak bemutatása
10 / 17 3.4 IRATADAT NYILVÁNTARTÁS Ábra: Iratadat nyilvántartási modul legfontosabb funkcióinak bemutatása
11 / 17 4. ADATMODELL 4.1 ENTITÁSOK ÉS RELÁCIÓIK Ábra: A legfontosabb entitások és relációik az ARHITEL rendszerben A logikai és fizikai szintű adatmodellezéshez azonosítani szükséges az Arhitel rendszer legfontosabb entitásait, illetve azok kapcsolódásait. A nyilvántartás egyik sarokpontját a matricák jelentik. Ezek a matricák íveken készülnek el, az ívek pedig matrica csomagokba kötegelve kerülnek legyártásra. Az Ügynökség küld el kontingens megrendeléseket a Nyomda számára. Egy megrendelés több kiszállítási csomagot is tartalmaz (pl. 1-1 csomagot mindegyik TÜK-nek és magának az Ügynökségnek). Minden ilyen kontinges megrendeléshez tartozó kiszállítási csomag egy vagy több matrica csomagot tartalmaz. A későbbiekben a TÜK-ök közötti, illetve Ügynökség TÜK, TÜK ügyvéd, ügyvéd ügyvéd közötti átadásoknál egy-egy ilyen egyedi kiszállítási csomag ennél kisebb egységeket is tartalmazhat, lehet benne egy kötegelt matrica csomag, de ív vagy akár egyedi matrica is.
12 / 17 A matricák életútja: a gyártás során, szállítás előtt a Nyomdához tartoznak, a nyomdai szállítást követően az Ügynökséghez vagy egy TÜK-höz kerül, onnan pedig ügyvédi irodákhoz (azon keresztül pedig ügyvédekhez) vagy egyéni ügyvédekhez jut. A matricák aktiválásukat követően iratok érvényesítéséhez használhatók fel. Minden matrica legfeljebb egy iratra kerülhet (a nem érvényesített matricákhoz pedig még nem tartozik irat). Az Ügynökséghez több TÜK hozzárendelhető (praktikusan az összes), a TÜK-ökhöz pedig ügyvédi irodák vagy egyéni ügyvédek rendelhetők. Az ügyvédi irodák egy vagy több ügyvédet alkalmaznak. Egy ügyvédhez (akár irodai, akár egyéni) tartozhatnak ügyvédaszisztensek.
13 / 17 5. INFRASTRUKTÚRÁLIS KONCEPCIÓ Az Arhitel rendszer infrastruktúra koncepció javaslat kidolgozása során négy meghatározó alapelvet azonosítottunk, mely a funkcionalitás megfelelő kiszolgálása mellett meghatározó: megfelelő szintű információ biztonság, megfelelően magas szintű rendelkezésre állás (üzembiztonság), megfelelő teljesítmény, skálázhatóság. Az információ biztonság kiemelten fontos az Arhitel rendszer esetében, ezért javasoljuk a publikus valamint a zártkörű igényeket kiszolgáló infrastruktúra fizikai szintű szétválasztását. Ezt az információ biztonságon felül skálázhatóság ázhatósági és teljesítménymenedzsment szempontok is indokolják. A megfelelően magas szintű rendelkezésre állás elérése érdekében a kritikus komponensek esetében publikus, logisztikai, letét és irat modulok redundáns architektúra kialakítására teszünk javaslatot (un. High-Availability (HA) Cluster ). A rendelkezésre állás szempontjából nem kritikus architektúra komponensekre (riport modul) költségtakarékosság okán nem redundáns kialakítást javasolunk. Természetesen mind a redundáns, mind az egyszeres architektúra komponensek esetben szükség a megfelelő mentési rendszer kialakítása is. A megfelelő teljesítmény érdekében a redundáns komponenseket alkalmazás szerver szintjén terheléselosztási képességekkel (un. Load-Balance (LB) Cluster vagy aktív-aktív cluster) javasolunk kialakítani a BGP (Border Gateway Protokoll) megfelelő alkalmazásával. Az adatbázis szerverek esetében első lépésben költségtakarékosság okán hibatűrő kialakítású (un. Fail-over (FO) Cluster vagy aktív-passzív cluster) kialakításra teszünk javaslatot, mely később licenc beszerzésekkel könnyen terheléselosztási képességekkel is felrusházható. Skálázhatóság és üzemeltetés szempontjából javasolt az egész infrastruktúra virtualizációja, azaz az egyes kiszolgáló komponensek virtuális szerver alapú kialakítását, mely a szervertakarékosság és jobb erőforrás kihasználása érdekében egy fizikai eszközön több virtuális szerver futtatását teszi lehetővé.
14 / 17 5.1 LOGIKAI INFRASTRUKTÚRA TERV A logikai infrastruktúra terv a virtuális szerver szintjén mutatja a be a javasolt infrastruktúrát, melyet a következő fejezetben bemutatott fizikai infrastruktúrán kerül kialakításra. A logikai infrastruktúra terv az alábbi fő komponenseket tartalmazza: 4 db dedikált webes alkalmazásszerver (az Arhitel kiszolgálására); 2 db dedikált webes alkalmazásszerver (az elexiosz.hu és az IDM kiszolgálására); 2 db dedikált adatbázisszerver (az Arhitel, az elexiosz.hu és az IDM kiszolgálására); 2 db összevont web- és alkalmazásszerver (a publikus modul kiszolgálására); 1 db összevont web- és alkalmazásszerver (a riport modul kiszolgálására); 2 db IDS/IPS 2 tűzfal és proxy; 2 db storage (az Arhitel megvalósításának első fázisában opcionális elem). A logikai infrastruktúra terv nem határoz meg konkrétan platformokat, illetve technológiákat, ugyanakkor a kiválasztott platformoknak, technológiáknak és ezek beszerzendő licenceinek az alábbi elvárásoknak minimálisan meg kell felelnie: Szerver operációs rendszer: virtualizálhatóság a kiválasztott virtualizációs technológiával; Alkalmazás (web) szerver: HA-LB (aktív-aktív) cluster kialakításának lehetősége; Adatbázis kezelő: HA-FO (aktív-passzív) cluster kialakításának lehetősége. 2 Intrusion Detection System / Intrusion Prevention System
15 / 17 HA-LB cluster HA-FO cluster 15 / 17 B Authentikáció Authorziáció Session kezelés C Tagnyilvántartás Felhasználói nyilvántartás elexiosz.hu / IDM Alkalmazás szerver elexiosz.hu / IDM Adatbázis szerver BGP SQL cluster Authentikáció E Authorziáció Session kezelés F Tagnyilvántartás Felhasználói nyilvántartás elexiosz.hu / IDM Alkalmazás szerver elexiosz.hu / IDM Adatbázis szerver HA-LB cluster HA-FO cluster Állampolgár B Publikus alkalmazás B Publikus adatbázis Belső hálózati felhasználók Publikus modul Alkalmazás szerver Publikus modul Adatbázis szerver Ügynökség VPN tunnel BGP SQL cluster SAN cluster Publikus alkalmazás Publikus adatbázis E E G Ügyvéd / iroda Publikus modul Alkalmazás szerver Publikus modul Adatbázis szerver HA-LB cluster HA-FO cluster Storage TÜK Nyomda A Letét alkalmazás Irat alkalmazás Logisztika alkalmazás C Letét adatbázis Irat adatbázis Logisztika adatbázis Törzsadat H Földhivatal Logisztikai-, irat és letét modulok Alkalmazás szerver Logisztikai-, irat és letét modulok Adatbázis szerver Storage BGP D Letét alkalmazás Irat alkalmazás Logisztika alkalmazás SQL cluster F Letét adatbázis Irat adatbázis Logisztika adatbázis Törzsadat Logisztikai-, irat és letét modulok Alkalmazás szerver Logisztikai-, irat és letét modulok Adatbázis szerver Hálózati kapcsolat Publikus szolgáltatások D Riport felület Riport adatbázis Jelmagyarázat Hálózati kapcsolat Zártkörű szolgáltatások Hálózati kapcsolat Riport szolgáltatások Cluster tagok közötti kapcsolat Internetes kapcsolat VPN csatorna Riport modul Alkalmazás- és adatbázis szerver Ábra: Az ARHITEL rendszer logikai infrastruktúrája koncepciója
16 / 17 5.2 FIZIKAI INFRASTRUKTÚRA TERV A fizikai infrastruktúra terv a fizikai eszközök szintjén mutatja a be a javasolt infrastruktúrát, melyet az előző fejezetben bemutatott logikai infrastruktúrát hivatott megvalósítani a skálázhatósági és üzembiztonsági elvárások megvalósításával. A javasolt architektúra egy virtualizált, teljes értékűen kettőzött (többszörözött) architektúra. A virtualizációs technológia kiválasztását a kiválasztandó rendszer igényeinek, valamint a beszerzésre kerül hardver eszközök lehetőségeinek megfelelően javasolt elvégezni. A szempontok alapján az alábbi fizikai infrastruktúra kialakítása javasolt: 6 db virtális hoszt szerver a megfelelő teljesítmény paraméterekkel; 2 db IDS/IPS tűzfal és proxy szerver; 2 db switch (FC/UTP) Az Arhitel II. fázisában a megnövekedett tárhely igény indokolja további architektúra elemek beiktatását: 2 db SAN switch (FC); 2 db storage (az Arhitel megvalósításának első fázisában opcionális elem); A fizikai infrastruktúra kialakítás során az üzembiztonsági elvárásoknak való megfelelés érdekében javasolt egy két szervertermes elhelyezés, melynél mindkét szerverterem minimálisan megfelel a Tier 3 követelményeknek 3. Ezzel az architektúra kialakítással infrastruktúra rendelkezésre állás oldaláról megfelelő üzemeltetés mellett 99.999% éves rendelkezésre állás garantálható azaz az éves kiesési idő várhatóan nem haladja meg az 1 órát. Ábra: Az ARHITEL rendszer fizikai infrastruktúra koncepciója 3 Lásd az A melléklet -ben.
17 / 17 MELLÉKLETEK A MELLÉKLET Az Uptime Institute (http://uptimeinstitute.com) által meghatározott iparági standardként elfogadott, rendelkezésre állás szempontjából meghatározott adatközpont osztályozása szerint az alábbi négy osztályba sorolhatóak az adatközpontok. A legegyszerűbb szint (Tier 1) tulajdonképpen egy egyszerű szerver szoba, amely a számítógépes rend-szerek telepítésének és üzemeltetésének alapvető irányelveit követi. A legszigorúbb elvárásokat a negyedik szintű (Tier 4) adatközpontok kritikus fontosságú számítógépes rendszereket zavartalan üzemeltetését redundáns alrendszerekkel, szeparált biztonsági zónákkal teszik lehetővé. Az Uptime Institute minden egyes osztályhoz megfogalmazott részletes ajánlásokat, illetve besorolási kritériumrendszert. Osztály Elvárások Megbízhatóság Tier 1 Tier 2 Tier 3 Tier 4 Alap infrastruktúra egyszeres energiaellátással, redundancia nélkül Nem redundáns kiszolgáló komponensek Egyszerű, nem redundáns hálózat Az infrastruktúra egyes kritikus elemei tartalékkal rendelkeznek Eléri a második szint meghatározott minimális követelményeit Az ICT rendszerek leállása nélkül karbantartható infrastruktúra Több független hálózati kapcsolattal rendelkezik Minden ICT eszköz két független áramforrásról üzemel Eléri a harmadik szint meghatározott minimális követelményeit Hibatűrő infrastruktúra, bármely elem hibája esetén is képes ellátni Minden berendezés két független áramforrásról működik, beleértve a hűtő berendezéseket, a ventilátorokat és a légkondicionálást is maximális teljesítményen Eléri a negyedik szint meghatározott minimális követelményeit Táblázat: Az adatközpontok besorolása az Uptime Institute szerint Éves rendelkezésre állás: 99.671% Éves kiesés: max. 22.8 óra Éves rendelkezésre állás: 99.741% Éves kiesés: max. 22 óra Éves rendelkezésre állás: 99.982% Éves kiesés: max. 1.6 óra Éves rendelkezésre állás: 99.999% Éves kiesés: max. 0.8 óra