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

BUDAPESTI ÜGYVÉDI KAMARA

1 / 17

RENDSZERKONCEPCIÓ

RENDSZERKONCEPCIÓ AZ ARHITEL PROJEKT MEGVALÓSÍTÁSI FÁZISÁNAK KERETÉ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


RENDSZERKONCEPCIÓ

Dokumentumkontroll

Projekt név:

Budapesti Ügyvédi Kamara Arhitel projekt

Dokumentum:

Rendszerk 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

#

Arhitel_rendszerkoncepcio_20140129_v1

02


3 / 17

RENDSZERKONCEPCIÓ

Tartalomjegyzék 1. BEVEZETÉS 1.1 Háttér 1.2 Terjedelem 2. AZ ARHITEL FELÉPÍTÉSE 2.1 Belső moduláris felépítés 2.2 Rendszerkapcsolatok 2.3 Technológiai alapvetések 3. FUNKCIONALITÁS FELSŐSZINTŰ BEMUTATÁSA 3.1 IDM modul 3.2 Riport modul 3.3 Logisztikai modul 3.4 Iratadat nyilvántartás 4. ADATMODELL 4.1 Entitások és relációik 5. INFRASTRUKTÚRÁLIS KONCEPCIÓ 5.1 Logikai infrastruktúra terv 5.2 Fizikai infrastruktúra terv MELLÉKLETEK „A” melléklet

4 4 4 5 5 6 6 8 8 8 9 10 11 11 13 14 16 17 17


02

4 / 17


RENDSZERKONCEPCIÓ

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 20112012 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.


02


5 / 17

RENDSZERKONCEPCIÓ

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 iratadat 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, kódszótár naplózás, munkafolyamat támogatás) támogatás egy erre a célra kialakított keretrendszernek szükséges biztosítania. keretrendszer 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 adatszinkronizáció 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ő belső riport modult. 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

RENDSZERKONCEPCIÓ

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.


02

7 / 17


7 / 17

RENDSZERKONCEPCIÓ

Ábra: Az ARHITEL rendszer moduláris felépítése

8 / 17


RENDSZERKONCEPCIÓ

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

Felhasználó, csoport, szerepkör, szolgáltatás menedzsment

Naplózás

Felhasználó és session információk lekérdezése

Bej elentkezés egyszer használatos Bej elentkezés kódszóv al felhasználónév v el, «extend» j elszóv al

Lekérdezés Authentikáció Ügyfélkapu authentikáció «include»

Felhasználó szerepkörök lekérdezése

IDM modul

Authorizáció

Tanúsítv ány alapú authentikáció

«include»

«include»

Szerepkör kij elölés

Idıbélyegzéssel kapcsolatos szolgáltatások

«include»

Session ID v alidálás

Session kezelés

«include»

«include»

Session ID generálás

«include»

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

Matrica lekérdezések Felhasználó által elv égzett események lekérdezése

Felhasználó, csoport, szerepkör, szolgáltatás relációv al kapcsolatos lekérdezések

Lekérdezés

Iroda adatokkal kapcsolatos lekérdezések

Nyilv ántartási adatok lekérdezése

Felhasználó adatokkal kapcsolatos lekérdezések

Ábra: Alapvető lekérdezés típusok


02

9 / 17


RENDSZERKONCEPCIÓ

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


02

10 / 17


RENDSZERKONCEPCIÓ

3.4 IRATADAT NYILVÁNTARTÁS

Ábra: Iratadat nyilvántartási modul legfontosabb funkcióinak bemutatása


02

11 / 17


RENDSZERKONCEPCIÓ

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 átadás 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.


02


12 / 17

RENDSZERKONCEPCIÓ

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.


02


13 / 17

RENDSZERKONCEPCIÓ

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 skálázhatósági ázhatóság é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é.


02


14 / 17

RENDSZERKONCEPCIÓ

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/IPS2 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:

2

•

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.

Intrusion Detection System / Intrusion Prevention System


02

15 / 17

HA-LB cluster

15 / 17


RENDSZERKONCEPCIÓ

HA-FO cluster

B

Authentikáció

C

Authorziáció

Tagn yilván tartás

Session kezelé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ó

Tagn yilván tartás

Session kezelés

Felhasználói nyilvántartás

F eLexiosz.hu / IDM Alkalmazás szerver

eLexiosz.hu / IDM Adatbázis szerver

HA-FO cluster

HA-LB cluster Állampolgár

B

B Pub likus alkalmazás

Publikus adatbázis

Belső hálózati felhasználók Publikus modul Alkalmazás szerver

Ügynökség

VPN tunnel

Publikus modul Adatbázis szerver

BGP

SQL cluster

SAN cluster Publikus adatbázis

Pub likus alkalmazás

E

E G Publikus modul Adatbázis szerver

Publikus modul Alkalmazás szerver

Ügyvéd / iroda

HA-FO cluster

HA-LB cluster

Storage

TÜK Letét ad atbázis

C

Letét alkalmazás

A

Irat adatbázis

Irat alkalmazás Lo gisztika alkalmaz ás

Lo gisztika adatbázis Törzsadat

Nyomda

H Logisztikai-, irat és letét modulok Adatbázis szerver

Logisztikai-, irat és letét modulok Alkalmazás szerver

Földhivatal BGP

Storage

SQL cluster Letét ad atbázis Letét alkalmazás

Irat adatbázis

Irat alkalmazás Lo gisztika alkalmaz ás

D

Lo gisztika adatbázis Törzsadat

F Logisztikai-, irat és letét modulok Adatbázis szerver

Logisztikai-, irat és letét modulok Alkalmazás szerver

Ripo rt felület Riport adatbáz is

D

Jelmagyarázat

Hálózati kapcso lat – Pub likus szolgáltatások Hálózati kapcso lat – Zártkörű szolgáltatások Hálózati kapcso lat – Ripo rt szolgáltatások Cluster tagok köz ötti kap csolat Internetes kapcsolat VPN csatorna

Riport modul Alkalmazás- és adatbázis szerver

Ábra: Az ARHITEL rendszer logikai infrastruktúrája koncepciója


02

16 / 17


RENDSZERKONCEPCIÓ

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ényeknek3. 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.


02

17 / 17


RENDSZERKONCEPCIÓ

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

Tier 1

Tier 2

Tier 3

Elvárások

Megbízhatóság

•

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

Tier 4 •

É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

Eléri a negyedik szint meghatározott minimális követelményeit Táblázat: Az adatközpontok besorolása az Uptime Institute szerint


02

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

Recommend Documents