Irányelv elektronikus rendszerekhez való hozzáférés biztosításához
1 / 30
Tartalomjegyzék
1.
Irányelv célja és keretei..................................................................................................................... 4 1.1.
Irányelv koncepciója .................................................................................................................. 4
1.2.
Jogszabályi háttér ....................................................................................................................... 5
1.2.1.
Ket. (2004. évi CXL. törvény) ............................................................................................ 5
1.2.2.
83/2012. (IV. 21.) Korm. rendelet ....................................................................................... 6
1.2.3.
84/2012. (IV. 21.) Korm. rendelet ....................................................................................... 7
1.2.4.
Ibtv (2013. évi L. törvény) .................................................................................................. 7
1.3.
2.
3.
4.
5.
Alkalmazói kör ........................................................................................................................... 8
1.3.1.
A SZEÜSZ szolgáltatói ....................................................................................................... 8
1.3.2.
A SZEÜSZ igénybevevői .................................................................................................... 8
Mértékadó nemzetközi és hazai kezdeményezések ........................................................................ 10 2.1.
Európai interoperabilitási keretrendszer ................................................................................... 10
2.2.
CORDIS projekt ....................................................................................................................... 10
2.3.
E-Trustex .................................................................................................................................. 12
2.4.
E-CODEX ................................................................................................................................ 12
2.5.
KEK KH – összerendelési nyilvántartás .................................................................................. 13
Folyamatokhoz kapcsolódó szolgáltatási funkciók......................................................................... 15 3.1.
Elektronikus tájékoztatás az adatelérési felületről ................................................................... 15
3.2.
Azonosítás és jogosultság ellenőrzése ...................................................................................... 15
3.3.
Adatelérés teljesítése ................................................................................................................ 16
3.4.
A (válasz)üzenet hitelesítése és opcionális titkosítása ............................................................. 17
3.5.
Naplózás ................................................................................................................................... 18
3.6.
Hozzáférés biztosítása hatóságnak nem minősülő személyek számára ................................... 18
Információs rendszerre vonatkozó követelmények......................................................................... 19 4.1.
Megbízhatóság.......................................................................................................................... 19
4.2.
Biztonság .................................................................................................................................. 19
4.3.
Teljesítmény ............................................................................................................................. 20
4.4.
Együttműködő képesség ........................................................................................................... 20
Megvalósítási ajánlás, kommunikációs típusok .............................................................................. 22 5.1.
SOAP-alapú architektúra .......................................................................................................... 23
5.1.1.
Üzenetformátum................................................................................................................ 24 2 / 30
5.1.2.
Bináris (nem szöveges) adatok átvitele ............................................................................. 25
5.1.3.
Adatbiztonság.................................................................................................................... 26
5.2.
5.2.1.
Üzenetformátum................................................................................................................ 27
5.2.2.
Adatbiztonság.................................................................................................................... 28
5.3. 6.
RESTful architektúra ................................................................................................................ 26
Alkalmazás- és adatbázisszerverek .......................................................................................... 28
Felhasznált források, hivatkozások ................................................................................................. 30
3 / 30
1. Irányelv célja és keretei A jelen irányelv célja, hogy orientálja a szolgáltatókat az elektronikus hozzáférési szolgáltatások vonatkozásában tett útmutatásokkal, ugyanakkor egyúttal meghagyja számukra a meghatározott technikai keretek közötti megoldás megválasztásánál a megfelelő mozgásteret, hogy a szolgáltatás kialakítása során a lehető legjobban megfelelhessenek a támasztott funkcionális követelményeknek. A Közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény (továbbiakban: Ket.) 2011. évi módosítása jelentősen módosította az elektronikus ügyintézésre vonatkozó szabályokat, lehetővé téve és előírva az elektronikus megoldások minél szélesebb körű alkalmazását.
1.1. Irányelv koncepciója Az informatika gyors fejlődésére és sokszínűségére tekintettel olyan szabályozási környezetet célszerű kialakítani, ahol az egyes megoldások részletszabályai már csak a legszükségesebb mértékben, mintegy minimumkövetelményként kerülnek jogszabályban meghatározásra, így lehetőség van az ügyintézés kiszolgálásában közreműködő számára az innovatív megoldások folyamatos követésére és rendszerszintű alkalmazására, a technológia fejlődéséből adódó lehetőségek folyamatos kihasználására. Az egységesség, együttműködő képesség – mind a hazai rendszerek egymás közötti, mind az EU vonatkozó rendszereivel való jelenkori és esetleges jövőbeli integrációjának – megtartása és lehetővé tétele érdekében ugyanakkor a szabályozási modell útmutató jellegű irányelvek kibocsájtását rendelte el. Az elektronikus rendszerekhez való hozzáférés biztosítása, mint általános célú SZEÜSZ, kiemelt pontja az elektronikus interoperabilitási funkcionalitásoknak, így a szolgáltatás nyújtásakor kiemelt célkitűzésként kell kezelni a minél szélesebb körű kompatibilitást. Szabályozási területeik kapcsolódása miatt ez az irányelv az alábbi négy SZEÜSZ-re együttesen vonatkozik: A hatóság informatikai rendszeréhez automatikus adatelérési felület (hozzáférés)
biztosítása
Hozzáférés az elektronikus iratkezelő rendszerhez Hozzáférés biztosítása elektronikus nyilvántartások adataihoz Hozzáférés biztosítása az informatikai rendszer működésével kapcsolatos adatokhoz 4 / 30
Ez az irányelv a szabályozott elektronikus ügyintézési szolgáltatásokról és az állam által kötelezően nyújtandó szolgáltatásokról szóló kormányrendelet (a továbbiakban: SZEÜSZR.) 14. §-a alapján, a SZEÜSZ-ök egységes nyújtása és igénybevétele, az együttműködési képesség biztosítása érdekében kerül meghatározásra. Tekintettel arra, hogy jelen dokumentum best-practice alapon megfogalmazott szakmai ajánlást tartalmaz az érintett SZEÜSZ tárgykörében, de nem specifikál alacsony szintű implementációs szempontokat, a szerzőt a gyakorlati megvalósítások következményeivel kapcsolatban csak korlátozott felelősség terheli.
1.2. Jogszabályi háttér A fentebb felsorolt négy SZEÜSZ-re vonatkozó irányadó jogforrások: •
2004. évi CXL. Törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket.),
•
83/2012. (IV. 21.) Korm. rendelet a szabályozott elektronikus ügyintézési szolgáltatásokról és az állam által kötelezően nyújtandó szolgáltatásokról (SZEÜSZR.),
•
84/2012. (IV. 21.) Korm. rendelet egyes, az elektronikus ügyintézéshez kapcsolódó szervezetek kijelöléséről,
•
2013. évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról (Ibtv.),
Ket. (2004. évi CXL. törvény)
1.2.1.
172. § E törvény alkalmazásában: •
j) szabályozott elektronikus ügyintézési szolgáltatás: az alábbi elektronikus ügyintézéssel kapcsolatos szolgáltatások:
•
18. a hatóság informatikai rendszeréhez automatikus adatelérési felület (hozzáférés) biztosítása más hatóság számára
•
10. hozzáférés az elektronikus iratkezelő rendszerhez,
•
11. hozzáférés biztosítása elektronikus nyilvántartások adataihoz,
•
12. hozzáférés biztosítása az informatikai rendszer működésével kapcsolatos adatokhoz, 5 / 30
1.2.2.
83/2012. (IV. 21.) Korm. rendelet
A SZEÜSZR. 26. pontja rögzíti a hatóság informatikai rendszeréhez automatikus adatelérési felület (hozzáférés) biztosításának mint SZEÜSZ-nek a követelményeit. Ennek értelmében egy hatóság által birtokolt, illetve kezelt adatok bizonyos köréhez más hatóságok automatikus elérési lehetőséget kapnak (innen a SZEÜSZR.-ben használt rövid név: automatikus adatelérési szolgáltatás). Ez az elérési lehetőség szigorúan szabályozott: •
a SZEÜSZ engedélyhez kötött;
•
csak jogszabályban engedélyezhető;
•
csak jogszabályban meghatározott adatok elérésére engedélyezhető;
•
csak jogszabályban feljogosított más hatóság érheti el az adatokat, azok is kizárólag jogszabályban meghatározott célból és feltételekkel.
meghatározott
hatóság
informatikai
rendszerére
Ez az elérési lehetőség a jelenlegi szabályozás szerint három célra irányulhat, melyek a SZEÜSZR. 27., 28. és 29. pontja szerint, mint kapcsolódó, de külön SZEÜSZ-ként kerülnek meghatározásra: •
Hozzáférés az elektronikus iratkezelő rendszerhez: elektronikus iratkezelő rendszerekből lehet konkrét iratokat (vagy másolati példányokat) átkérni vagy átadni, illetve az ügyirat ügyintézési állapotával kapcsolatos státuszinformációkat lekérdezni;
•
Hozzáférés biztosítása elektronikus nyilvántartások adataihoz: elektronikus nyilvántartások adatait lehet lekérni, ahol az adatok elérhetővé tételénél gondoskodni kell arról, hogy illetéktelen személy az adatkapcsolatba ne léphessen be, az adatkapcsolatot ne zavarhassa meg, onnan adatot ne nyerhessen ki, ne juttathasson be, valamint az adatok elérhetővé tételénél az elérhetővé tett adatok hitelesítését illetően a szolgáltató:
a) legalább fokozott biztonságú elektronikus aláírással ellátott üzenetet, b) zárt rendszerek közti zárt, hitelesített kapcsolatot, vagy c) más, a közigazgatási informatika infrastrukturális megvalósíthatóságának biztosításáért felelős miniszter által meghatározott hitelesítési megoldást alkalmaz. •
Hozzáférés biztosítása az informatikai rendszer működésével kapcsolatos adatokhoz: elektronikus ügyintézést végző informatikai rendszerből lehet lekérdezni ügyfélforgalmi, ügyforgalmi, valamint az ügyintézéssel kapcsolatos teljesítményadatokat. 6 / 30
A három elérési lehetőség közös jellemzőit határozza meg a 26. pontban nevesített SZEÜSZ (A hatóság informatikai rendszeréhez automatikus adatelérési felület (hozzáférés) biztosítása):
1.2.3.
•
Olyan felület biztosítása, melyen keresztül – megfelelő azonosítási és jogosultságellenőrzés után – hatóságok kezelésében lévő adatok érhetőek el oly módon, hogy az adatátadás körülményei a későbbiekben visszakereshetőek;
•
Az adott felülethez való hozzáférési jogok engedélyezési eljárás után adhatóak meg más hatóságok számára. A SZEÜSZ szolgáltató feladata elektronikus formában az elektronikus tájékoztatás szabályai szerint adattípusonként közzétenni a szolgáltatott adatok megjelölését, a szolgáltatást igénybe venni jogosult hatóságok megnevezését, továbbá a szolgáltatáshoz kapcsolódó adatelérési feltételeket és célokat.
•
Olyan kommunikációs csatorna és kommunikációs felületek biztosítása, amelyeken a nyújtott szolgáltatás megfelel a bizalmasság, a sértetlenség és a letagadhatatlanság követelményeinek.
84/2012. (IV. 21.) Korm. rendelet
A Kormányrendelet a négy SZEÜSZ egyikét sem jelöli ki az állam által kötelezően nyújtandó szolgáltatásként. Ugyanakkor a Kormányrendelet az összerendelési nyilvántartást, mint szolgáltatást az állam által kötelezően nyújtandó szolgáltatásként nevezi meg, egyben a Közigazgatási és Elektronikus Közszolgáltatások Központi Hivatalát jelöli ki annak szolgáltatójaként. Az összerendelési nyilvántartás szolgáltatásához szükség van több nyilvántartáshoz való automatikus adatelérésre, következésképp az ezt biztosító SZEÜSZ-re is.
1.2.4.
Ibtv (2013. évi L. törvény)
Az állami és önkormányzati szervek elektronikus információbiztonságáról szóló 2013. évi L. törvény (a továbbiakban: Ibtv.) hatálya alá esik mind a négy SZEÜSZ-t megvalósító elektronikus információs rendszer, hiszen szolgáltatásaikat központi államigazgatási szervek, fővárosi és megyei kormányhivatalok, vagy önkormányzatok veszik igénybe (Ibtv. 2. § (1) a), j) és k)). Az Ibtv. szerint a SZEÜSZ-öket megvalósító elektronikus információs rendszert a bizalmasság, sértetlenség és rendelkezésre állás szempontjából külön-külön 1-5 biztonsági osztályba kell sorolni.
7 / 30
1.3. Alkalmazói kör A SZEÜSZ szolgáltatói
1.3.1.
A SZEÜSZR. 78. § (1) szerint: •
A hatóság informatikai rendszeréhez más hatóság részére automatikus adatelérési felületet, hozzáférést biztosító szolgáltatás (a továbbiakban: automatikus adatelérési szolgáltatás) keretében a SZEÜSZ szolgáltató valamely hatóság informatikai rendszerében kezelt adatokhoz biztosít közvetlen, az adatkezelő beavatkozását nem igénylő hozzáférést más hatóság számára.
Ezzel tehát a jogszabály nem határozza meg, hogy a hozzáférést biztosító szolgáltatást maga az érintett (adatkezelő) hatóság, vagy egy külső, a hatósággal kapcsolatban álló szolgáltató végezze. Ugyanakkor a szolgáltatás jogszabályi környezetéből és jellegéből az is következik, hogy amennyiben a SZEÜSZ szolgáltatója egy hatóságon kívüli szervezet, akkor a vonatkozó adatkezelési, adatvédelmi, információbiztonsági és jogosultsági körülményeket és feltételeket előíró jogszabályok indirekt módon a külső fél számára nyújtott adatszolgáltatás tekintetében a SZEÜSZ szolgáltatóra ugyanolyan feltételeket szabnak, mint az adatkezelő hatóságra. Ugyanakkor a külső SZEÜSZ szolgáltatóra – mint két hatóság kommunikációját biztosító harmadik félre – a jogszabályi környezetből következően az is érvényes, hogy a kezelt adatokba nem tekinthet be, azokat nem módosíthatja, nem tarthatja vissza, valamint továbbításukról haladéktalanul gondoskodni köteles. Ezzel egy esetleges külső SZEÜSZ szolgáltató a fénysebességű vak postás szerepét játssza folyamatban játszott szerepét tekintve pusztán transzparens adattovábbítási felelősségi körrel rendelkezne, azonban a vonatkozó szigorú jogi előírásokból és a feladat technikai jellegéből következően csak nehezen indokolható kockázati pont lenne a rendszerben. Ennélfogva jelen irányelv gyakorlatias módon abból indul ki, hogy ezen SZEÜSZ szolgáltatói maguk az adatkezelő hatóságok, ellenkező esetben a SZEÜSZ-t biztosító szerv és az adatok forrását jelentő hatóság között, ha ezek különbözők lennének, szigorú azonosításra, hitelesítésre, kommunikáció védelmére és együttműködő képességre vonatkozó elvárásokat kellene teljesíteni.
1.3.2.
A SZEÜSZ igénybevevői
A szolgáltatásokat közvetlen módon kizárólag hatóság veheti igénybe. A szolgáltatásokat igénybe veszi egy speciális hatóság is: az összerendelési nyilvántartást vezető szerv (KEK KH) csak akkor tudja ellátni feladatát, ha az érintett nyilvántartásokat (személyi szám, személyigazolvány szám, jogosítvány szám, útlevél szám, adóazonosító jel, TAJ szám, rendelkezési nyilvántartás, stb.) kezelő szervek biztosítják számára az automatikus adatelérési SZEÜSZ-t. 8 / 30
Hatóságnak nem minősülő személy számára csak közvetett módon biztosítható az automatikus adatelérés, ha az adatszolgáltatás az eredetitől elkülönített rendszert használ. Kapcsolódó SZEÜSZök: •
Azonosítási szolgáltatás
•
Biztonságos elektronikus igazolási szolgáltatás
•
Elektronikus dokumentumtárolási szolgáltatás (pl. az elektronikus iratkezelő rendszerben tárolt dokumentum tárolására)
•
Informatikai háttér szolgáltatása (amennyiben magát az elektronikus iratkezelő rendszert vagy nyilvántartás rendszert egy háttérszolgáltatás biztosítja)
9 / 30
2. Mértékadó nemzetközi és hazai kezdeményezések Az együttműködési képesség biztosításához elengedhetetlen olyan esettanulmányok vizsgálata, amelyek modellértékű karakteres leírásként kiindulópontját szolgáltatják az irányelvnek. Ezen kezdeményezések teljes körű vizsgálata kivitelezhetetlen, ugyanakkor alapelveik megegyezősége következtében, noha messzemenőleg a teljesség igénye nélkül, megalapozottan tekinthetők olyan hivatkozási alapnak, amellyel az irányelv által meghatározott követelmények indokolhatók.
2.1. Európai interoperabilitási keretrendszer Az Európai Interoperabilitási Keretrendszer (European Interoperability Framework, EIF) egy átfogó, általános kereteket meghatározó, egymással közszolgáltatások közös nyújtása érdekében együttműködni kívánó szervezetek egyeztetett interoperabilitási megközelítése. Alkalmazási körén belül közös elemként például meghatározza a szóhasználatot, a fogalmakat, az alapelveket, az irányvonalakat, az útmutatókat, az ajánlásokat, a szabványokat, az előírásokat és az eljárásokat. Az EIF az interoperabilitással egy bizonyos kontextusban – az európai közszolgáltatások nyújtása terén – foglalkozik. Noha az európai közszolgáltatások nyújtása szinten minden esetben IKT-rendszerek közötti adatcserével jár, az interoperabilitás tágabb fogalom, amely a szervezetek azon képességét is magában foglalja, hogy minden fél számára előnyös és közösen meghatározott célok érdekében együttműködjenek. Az EIF céljai a következők: •
az európai közszolgáltatások nyújtásának előmozdítása és támogatása a határokon átnyúló és ágazatközi interoperabilitás révén;
•
iránymutatás a közigazgatási szervek számára a vállalkozásoknak és a polgároknak nyújtott európai közszolgáltatások terén;
•
a különböző nemzeti interoperabilitási keretrendszerek (National Interoperability Framework, NIF) kiegészítése és összekapcsolása európai szinten.
2.2. CORDIS projekt A CORDIS (Community Research and Development Information Service – Közösségi Kutatási és Fejlesztési Információs Szolgáltatás) egy nagy mennyiségű adattal rendelkező információs felület, mely a kutatás és fejlesztés területén végzett közösségi tevékenységekről és az azokat támogató infrastruktúráról nyújt tájékoztatást. Az adatok közvetlenül az európai kutatás 10 / 30
területén dolgozó szakemberektől, illetve újságíróktól származnak. A projekt feladata, hogy az európai kutatás-fejlesztési projektben történő részvételt elősegítse, különösen a 7. keretprogram (FP7) célkitűzései szerint, mely alapján a célok: •
az EU által finanszírozott projektek eredményeinek közzététele;
•
új ismeretek elterjesztése a vállalkozások innovációs kapacitásának megnövelése érdekében;
•
hozzájárulás a civil társadalom és a tudományos világ közötti szakadék csökkentéséhez.
A CORDIS hozzáférést nyújt számos információhoz és szolgáltatáshoz az európai K+F területén, például: • elsődleges tára az EU által finanszírozott kutatási projekteknek és azok eredményeinek
1990 óta, beleértve az Európai Bizottság formális iratainak gyűjteményét is;
• napi híreket szolgáltat, tájékoztatást ad aktuális eseményekről, finanszírozási
lehetőségekről és kutatási esetekről, ezen információk forrása pedig mind az Európai Bizottság, mind külső hozzájárulók;
• interaktív környezetet nyújt, amely támogatja kutatási partnerek keresését és
üzemeltet vitafórumokat;
• biztosít
számos tematikus szolgáltatást, országokon belüli elérési pontokat, dokumentumkönyvtárat, felhasználói útmutatókat és széleskörű keresési lehetőségeket, valamint e-mailes értesítőszolgálatot és RSS hírforrást üzemeltet;
• egyéb adatbázisokat üzemeltet, amelyek az EU-n belüli K+F tevékenységet szolgálják.
A CORDIS havonta többszázezer felhasználót vonz elsősorban a K+F területéről, valamint a vállalkozók közül, de a politikai döntéshozók, a vállalatokat támogató szervezetek, újságírók stb. köréből is. Ezek a felhasználók havonta többmillió oldalt látogatnak meg, és dokumentumok százezreit töltik le. A CORDIS valamennyi látogatója saját céljainak megfelelő adatbázisban keres, a projekt feladata pedig annak biztosítása, hogy az információs felület folyamatosan naprakész adatokkal szolgáljon, és minden látogató a lehető legegyszerűbb módon találjon rá a keresett információra. A CORDIS elsődleges adattovábbítási technológiaként a webszolgáltatásokat (Web Services) használja. Esettanulmányra jó példa a DIP elnevezésű kezdeményezése, melynek célja az adat- és információszolgáltatás integrációja szemantikus webszolgáltatások használatával, ezen belül is nyílt forrású megvalósítással (WSMX). 11 / 30
2.3. E-Trustex A Megbízható Adatcserélési Platform (Trusted Exchange Platform) egy szektorokon átnyúló, nyílt forrású, ingyenes eszköz, amely abból a célból jött létre, hogy hozzáférést biztosítson strukturált és nem strukturált dokumentumokhoz, valamint költséghatékony kapcsolódási lehetőséget nyújtson a páneurópai elektronikus kézbesítési infrastruktúrákhoz. A kezdeményezés az e-PRIOR infrastruktúrára alapul, amelyet eredetileg az elektronikus közbeszerzési folyamatok támogatására dolgoztak ki. Főbb paraméterei: • J2EE alapú, skálázható architektúra; • nyílt forrású szoftveres környezet, Java alkalmazások; • webszolgáltatás-alapú kommunikáció, SOAP/XML; • nagyméretű bináris adatok továbbítására MTOM módszer; • platformfüggetlenség, többféle alkalmazásszerver lehetősége (pl. JBOSS, Apache
Tomcat);
• relációs adatbázisszerver implementációs megkötés nélkül; • megbízhatóság: szimmetrikus és nyilvános kulcsú titkosítások; • sérthetetlenség, letagadhatatlanság: digitális aláírás; • perzisztencia az adatbázis oldalán; • autentikációs mechanizmus.
A projekt célja továbbá az e-PRIOR olyan kiegészítése, amellyel lehetővé válik dokumentumok automatikus adattovábbítása XML-alapú metaadatok, valamint tetszőleges típusú csatolmányok (PDF, Word stb.) használatával elektronikus úton, megbízható és biztonságos platformokon és csatornán keresztül.
2.4. E-CODEX A funkcióját tekintve internetes adatcserén alapuló e-igazságügyi kommunikációt célzó projekt célja a határokon átnyúló igazságügyi együttműködés elősegítése. A projekt 14 tagállam és Törökország részvételével indult és a kezdetektől részt vesznek benne az európai közjegyzőket és ügyvédeket képviselő szervezetek, az Európai Ügyvédi Irodák Szövetsége (CCBE) és az Európai Közjegyzőségek Tanácsa (CNUE). Hazánk képviseletében a 12 / 30
Közigazgatási és Igazságügyi Minisztérium aktív megfigyelőként vesz részt. A cél az e-justice portálon kitöltött elektronikusan a megfelelő helyre továbbított nyomtatványokkal történő eljárás, ami egyben azt is jelenti, hogy az egyszerű polgárok számára a túl bonyolult nemzetközi eljárások a háttérben fognak zajlani. A folyamatok automatizálttá válnak és az együttműködés igénybevevőjének nem kell minden egyes további lépést saját magának kezdeményeznie, illetve figyelemmel kísérnie. Az e-CODEX projekt, ugyanúgy, mint a hozzá kapcsolódó e-law európai tanácsi munka, a jog és az informatika határán helyezkedik el. A projektben az azonosításra, elektronikus kézbesítésre, elektronikus formanyomtatványokra vonatkozó informatikai jellegű alcsoportok mellett a jogi alcsoport is kiemelkedő szerepet tölt be és minden tematikus találkozón részt vesznek a területeket ismerő jogi szakemberek is. Emellett az érintett szakmai hálózatokkal is kapcsolatot tartanak fenn a projekt szakértői. A projekt célkitűzései: •
jogi dokumentumok és eljárások könnyű és biztonságos elérése az EU tagállamai között is, cégek és állampolgárok számára;
•
jogi eljárások hatékony, határokon átnyúló lebonyolítása közös sztenderdek és az információs rendszerek hatékony együttműködése révén.
Az e-CODEX elektronikus kézbesítési infrastruktúrája a határokon átnyúló kommunikációt az OASIS intézet által szabványosított ebXML Messaging Service (ebMS 3.0) szabványú protokoll felhasználásával valósítja meg. Az ebXML alapú üzenetküldés: •
SOAP-ot használ csatolmányokkal;
•
támogatja a magas absztrakciós szintű szemantikákat, amelyek az üzleti tranzakciókhoz szükségesek (biztonság és megbízhatóság);
•
számos kommunikációs protokoll fölött implementálható (HTTP, SMTP, FTP).
2.5. KEK KH – összerendelési nyilvántartás Mind természetes, mind nem természetes személyek összerendelési nyilvántartása esetére a SZEÜSZR. részletes előírásokat tartalmaz. Az összerendelési nyilvántartás az állam által kötelezően nyújtandó szabályozott elektronikus ügyintézési szolgáltatás, amelynek így mindenben meg felelnie a vonatkozó jogszabályokban foglalt követelményeknek. Az összerendelési nyilvántartással kapcsolatos szabályozott elektronikus ügyintézési szolgáltatás adatkezelője a SZEÜSZ nyújtása során köteles teljesíteni a közigazgatási informatika infrastrukturális megvalósíthatóságának biztosításáért felelős miniszter rendeletében meghatározott követelményeket, ezek között: 13 / 30
•
Az összerendelési nyilvántartás alkalmazásának biztosítania kell, hogy az összerendelési bejegyzésekhez történő hozzáférésre csak megfelelő autentikáció után lehet lehetőség;
•
Az összerendelési nyilvántartásból csak előzetesen regisztrált szervezetek számára, automatizált interfész útján, a jogosultságuk ellenőrzését követően, a jogosultságuknak megfelelő adatokra vonatkozóan szolgáltatható adat. Ezen szervezetekről jogosultsági nyilvántartást kell vezetni;
•
Az összerendelési nyilvántartás informatikai rendszerében keletkezett minden adatkezelési műveletet naplózni kell, és biztosítani kell a naplózott adatok többféle szempont szerinti lekérdezési lehetőségét, a lekérdezett napló adatok felhasználóbarát módon történő kinyomtatását és exportálhatóságát is.
A KEK KH által kiépített rendszerben az alkalmazásszerverek szolgálják ki mind a HTTPS protokollon, mind pedig az üzenetkezelő rendszeren keresztül beérkező kéréseket. A biztonság fokozása céljából a végfelhasználók proxy szerveren keresztül érik az üzleti logikát futtató központi alkalmazásszervereket. Az architektúrában a különböző szolgáltatások alkalmazásba történő integrálására külön webservice réteg kialakítására is lehetőség van. Az alkalmazásszerver funkcionalitását Jboss Application Server vagy azzal egyenértékű szoftver biztosítja és az alkalmazásszerverek közötti terheléselosztás szoftveresen valósul meg. Az architektúrában a lekérdezések gyors kiszolgálását külön e célra kialakított JBoss Data Grid vagy azzal egyenértékű gyorsító tárak biztosítják, míg a karbantartást többrétegű alkalmazásfejlesztési modell alapján készült alkalmazás szolgálja ki.
14 / 30
3. Folyamatokhoz kapcsolódó szolgáltatási funkciók Az elektronikus rendszerekhez való hozzáférésekkel kapcsolatos SZEÜSZ-öknek biztosítaniuk kell a következő funkciókat: •
Elektronikus tájékoztatás az adatelérési felületről;
•
Az adatelérést kérő azonosítása és jogosultságának ellenőrzése;
•
Az adatelérés teljesítése (a kérésre adott megfelelő adat szerkezetű válasz megadásával) vagy visszautasítása;
•
A (válasz) üzenet hitelesítése;
•
Naplózás.
Az elektronikus rendszerekhez való hozzáférésekkel kapcsolatos SZEÜSZ-ök opcionális funkcióként biztosíthatják a hozzáférést hatóságnak nem minősülő személyek számára is.
3.1. Elektronikus tájékoztatás az adatelérési felületről A SZEÜSZR. 79 és 80. § által szabályozott folyamat résztvevői: •
a szolgáltató (adatkezelő) hatóság;
•
az adatkérő hatóság.
A tájékoztatás során közzéteendő információk: •
adatmegjelölés ;
•
kezelő hatóság megnevezése ;
•
szolgáltatást igénybe venni jogosult hatóság megnevezése ;
•
célok és feltételek ;
•
vonatkozó jogszabályok ;
•
elérés módja .
3.2. Azonosítás és jogosultság ellenőrzése Adatelérés csak sikeres azonosítás és jogosultság ellenőrzés után lehetséges. 15 / 30
Azonosítás: •
közhiteles nyilvántartások, illetve a nemzeti adatvagyon körbe tartozó nyilvántartások esetén a kormányzati hitelesítés-szolgáltatás szabályai szerint (SZEÜSZR. 80. § (3));
•
egyéb esetekben az ügyfél azonosítására vonatkozó rendelkezések alkalmazásával.
Jogosultságellenőrzés: •
saját nyilvántartás;
•
vagy biztonságos elektronikus elektronikus igazolás alapján.
igazolási
szolgáltatás
keretében
kiállított
3.3. Adatelérés teljesítése Az adatelérés teljesítésére a SZEÜSZR. 78. § (1) és (3) alapján három különböző lehetséges megoldás is van. Az első esetben a SZEÜSZ szolgáltatói felülete közvetlenül kapcsolódik az adatforráshoz. Ekkor az architektúra jóval egyszerűbb, viszont a közvetlen kapcsolat miatt az adatforrás védelme szerényebb, melynek magának kell a SZEÜSZ felülete számára értelmezhető formában szolgáltatnia adatait. Ez a választás akkor célszerű, ha az adatforrás nem biztonságkritikus adatokat tartalmaz, valamint nem várható az adatszolgáltató rendszer olyan fokú terhelése, amely redundancia kiépítését tenné szükségessé. A második esetben az adatforrásról másolat képződik, így az érhető el a SZEÜSZ szolgáltató felület részére, nem pedig az eredeti adattartalom. Előnye az őspéldányt tartalmazó rendszer magasabb fokú védelme, hátránya viszont a replikáció szinkronban tartásának követelménye. Ennek a megoldásnak a használata akkor javasolt, ha a szolgáltató fokozott védelmet kíván biztosítani a jellemzően biztonságkritikus adatoknak (a redundancia következtében az adatvesztés valószínűsége is kisebb). A harmadik esetben egy közbeékelődött rendszer által történik az adatszolgáltatás. Ekkor, ellentétben az egyszerű másolat esetével, lehetőség van a szabványos interfész biztosítására a kapcsolt rendszeren, az adatforrás kommunikálhat más módon is. A kapcsolt rendszer mint interpreter is szerepelhet, mely meglévő, más módon tervezett rendszerek illesztését könnyíti meg, az eredeti rendszer módosítása nélkül. Ez a megvalósítás akkor javasolt, ha a kiépítésre kerülő rendszer szempontjából kiemelt fontosságú a széleskörű kompatibilitás megteremtése, akár már meglévő rendszerhez való illesztés céljából, akár a későbbi könnyű bővíthetőség érdekében. Az adatelérés különböző SZEÜSZ-ökre mást jelent: 16 / 30
•
„Hozzáférés biztosítása elektronikus nyilvántartások adataihoz" SZEÜSZ esetén elektronikus nyilvántartási rendszerek adatait lehet elérni;
•
„Hozzáférés az elektronikus iratkezelő rendszerhez” SZEÜSZ esetén konkrét iratokat (vagy másolati példányokat) átkérni vagy átadni, illetve ügyirat ügyintézési állapotát lekérdezni;
•
„Hozzáférés biztosítása az informatikai rendszer működésével kapcsolatos adatokhoz” SZEÜSZ esetén ügyfélforgalmi, ügyforgalmi, valamint ügyintézéssel kapcsolatos teljesítményadatokat lehet lekérdezni.
3.4. A (válasz)üzenet hitelesítése és opcionális titkosítása A válaszüzenetet hitelesíteni kell a SZEÜSZR. 81. § (1) által meghatározott lehetőségek valamelyikével: •
legalább fokozott biztonságú elektronikus aláírással: fokozott biztonságúnak nem minősülőnél alapvetően szigorúbb, ugyanakkor a minősített elektronikus aláírásnál alapvetően enyhébb követelmények szerinti aláírással (kriptográfiai eszközök alkalmazása szükséges, ugyanakkor például nem előírás a személyes azonosítás, az intelligens kártya általi védelem vagy a hitelesítésszolgáltató felelősségvállalása a tanúsítványért);
•
zárt rendszerek közti zárt, hitelesített kapcsolattal: olyan bevett kriptográfiai módszerek alkalmazásával, amelyek mind a partnerhitelesítést, mind az adatok bizalmasságát biztosítják (pl. SSL/TLS, SSH);
vagy más jogszabályban meghatározott egyéb hitelesítési megoldással. A válaszüzenetet a SZEÜSZR. 81. § (2) által meghatározott esetekben titkosítani is kell (az ezt igénylő nyilvános kulcsának felhasználásával). A fentiekkel összhangban a szolgáltatás csatornára és adatokra vonatkozó elvárásai: •
a csatorna titkosítása minden esetben elvárt követelmény;
•
a forgalmazott adat jellegétől függően annak titkosítása opcionális, ajánlott;
•
Az átvitel folyamán az adatok integritásának védelme, illetve az integritás ellenőrzésének lehetősége elvárt követelmény.
Mindhárom esetben a rendszernek automatikusan érzékelnie kell, amennyiben a fenti követelmények sérülnek, erről értesítést kell küldenie a felhasználónak (felhasználói szinten), illetve a SZEÜSZ-t szolgáltató hatóságnak (üzemeltetői szinten). 17 / 30
3.5. Naplózás Naplózni kell a SZEÜSZR. 80. § (3) által meghatározottakat (kért és továbbított adat, azonosított adatkérő és jogosultsága, adatkezelés célja, időpont, elérési mód). A naplózás részletességének, megőrzési idejének, ellenőrzésének, sértetlenség biztosításának, archiválásának, megsemmisítésének követnie kell az adatforrás elektronikus információs rendszerére vonatkozó (annak biztonsági osztályba sorolásától függő, az Ibtv által meghatározott) elvárásokat.
3.6. Hozzáférés biztosítása hatóságnak nem minősülő személyek számára A SZEÜSZR. 82. § (1) szerint hatóságnak nem minősülő személy számára közvetlen, az adatkezelő beavatkozását nem igénylő hozzáférés általában tilos. Az egyetlen kivétel (SZEÜSZR . 82. § (2)) egyben egy opcionális funkció is: hatóságnak nem minősülő személy számára csak abban az esetben nyújtható közvetlen hozzáférés, amennyiben az adatszolgáltatás nem az eredeti, szülő rendszert használja, hanem egy nem integrált, az eredetitől elkülönítettet.
18 / 30
4. Információs rendszerre vonatkozó követelmények 4.1. Megbízhatóság A megbízhatóságra vonatkozó általános szempontokon kívül nincs kifejezetten az elektronikus rendszerekhez való hozzáférésekkel kapcsolatos SZEÜSZ-ökre jellemző elvárás.
4.2. Biztonság Az Ibtv. alapján a SZEÜSZ-t megvalósító elektronikus információs rendszert biztonsági osztályba kell sorolni. A besorolás az adatok biztonságáért felelős vezető feladata, azaz a SZEÜSZ szolgáltatást igénybe vevő közigazgatási hatóság vezetőjének a felelőssége. A biztonsági osztályba sorolást: •
már működő rendszer esetén 2014. július 1-ig el kell végezni
•
legalább háromévenként el kell végezni minden rendszer esetében;
•
soron kívül el kell végezni az alábbi esetekben: ◦ a rendszer biztonságát érintő jogszabályváltozás, ◦ új rendszer bevezetése, ◦ a szervezet státuszában, illetve az általa kezelt vagy feldolgozott adatok
vonatkozásában bekövetkező változás.
A biztonsági osztályba sorolást dokumentált módon kell végezni. A besorolást a szervezet vezetője hagyja jóvá, és a szervezet informatikai biztonsági szabályzatában kell rögzíteni. Az elektronikus rendszerekhez való hozzáférésekkel kapcsolatos SZEÜSZ-ök általános jellemzői alapján a biztonsági osztályba sorolásra az alábbi kiinduló javaslat adható: •
bizalmasság szempontjából: megegyezik a szolgáltatás alapját képező elektronikus iratkezelő rendszer vagy nyilvántartás „bizalmasság” biztonsági osztályának értékével
•
sértetlenség szempontjából: megegyezik a szolgáltatás alapját képező elektronikus iratkezelő rendszer vagy nyilvántartás „sértetlenség” biztonsági osztályának értékével
•
rendelkezésre állás szempontjából: legfeljebb a szolgáltatás alapját képező 19 / 30
elektronikus iratkezelő rendszer vagy nyilvántartás „rendelkezésre állás” biztonsági osztályának értéke
4.3. Teljesítmény A teljesítményre vonatkozó általános szempontokon kívül nincs kifejezetten az elektronikus rendszerekhez való hozzáférésekkel kapcsolatos SZEÜSZ-ökre jellemző elvárás. Mivel a szolgáltatás igénybevevője is jellemzően hatóság, az adathozzáférési igények az informatikai rendszer megvalósításának függvényében alakulnak. Ennek következtében a szolgáltatásnyújtás oldalán a teljesítményigény az átlagos (véletlenszerű) elérésnél szükség esetén jobban méretezhető és az igénybevevő oldaláról jobban elosztható, így a hatóság és hatóság közötti kommunikáció okozta, összességében mérsékeltebb terhelés a SZEÜSZ szolgáltatója irányába a robusztusság szempontjából is mérsékeltebb követelményeket támaszt.
4.4. Együttműködő képesség Az interoperabilitás kiemelkedően fontos kérdéskör az elektronikus rendszerekhez való hozzáféréseknél. Ha minden adataihoz automatikus elérést biztosító elektronikus iratkezelő rendszer és nyilvántartás különböző módon teszi lehetővé a hozzáférést, akkor ez nagyon megnehezíti a szolgáltatások igénybe vételét. Az alábbi javaslat egyaránt összhangban áll a jelen irányelv tárgyát képező szolgáltatásokra vonatkozóan a kommunikációs csatornára és adatokra vonatkozó jogszabályi elvárásokkal, illetve a KIB 28. számú ajánlásban megfogalmazott általános, együttműködő képességre irányuló koncepcióval. Különálló rendszerek egymás közötti hatékony interaktív kapcsolata alapvetően az alábbi két tényezőn múlik: •
szabványos kommunikációs csatornák;
•
szabványos vagy egyeztetett adatformátumok használata.
A kommunikációs (átviteli) csatornák kiválasztása esetében olyan standard (de-jure, de-facto) technikák alkalmazása javasolt, melyek hatékonyan – az adatmennyiségen felül kis mértékben terhelve a rendszert – és biztonságosan képesek a küldő féltől eljuttatni a fogadóhoz az adatcsomagot, úgy, hogy az harmadik, a kommunikációban jogosulatlan fél számára értelmezhetetlen legyen. Az adatok formátuma terén is követni kell olyan standardnak tekinthető megoldásokat, 20 / 30
melyek széles körben alkalmazhatóak, ez általbiztosítva az adatok (információk) értelmezhetőségét és feldolgozhatóságát, valamint a későbbi, adott esetben nemzetközi rendszerekhez történő illesztés technikai lehetőségét.
21 / 30
5. Megvalósítási ajánlás, kommunikációs típusok A röviden ismertetett esettanulmányokat és a mértékadó és elterjedt szabványokat figyelembe véve, valamint az együttműködési képességet kiemelten szem előtt tartva egyértelműen kijelenthető, hogy az automatikus adatelérési szolgáltatások technikai alapját célszerűségi okokból a webszolgáltatások (web services) képezik. A webszolgáltatások informatikai alkalmazások közötti adatcserére szolgáló protokollok és szabványok gyűjteménye. Különböző programnyelveken írt és különböző platformokon futó szoftveres alkalmazások számítógép-hálózatokon (mint az Internet) keresztül történő adatcseréjére szolgálnak, az egygépes folyamatközi kommunikációhoz (IPC) hasonlóan. Ezen interoperabilitási képesség (például Java és Python, illetve Windows és Linux között) a nyílt szabványok használatának eredménye. Az OASIS és a W3C a vezető bizottságok a webszolgáltatások szabványosításának terén. A különböző implementációk fejlesztésének együttműködése érdekében a WS-I szervezet több profilt fejlesztett ki a további szabványok támogatására. A webszolgáltatások előnyei: •
együttműködést biztosítanak a különböző platformokon futó szoftver alkalmazások között;
•
nyílt szabványokat és protokollokat használnak, a protokollok és adatok minden lehetséges helyen szöveg alapúak, így egyszerűsítve a fejlesztők feladatát;
•
HTTP használatával keresztüljutnak a legtöbb tűzfalon a tűzfal paramétereinek megváltoztatása nélkül;
•
egyszerű módon teszik lehetővé különböző gyártóktól származó szoftverek és szolgáltatások kombinálását új, integrált szolgáltatások létrehozására;
•
lehetővé teszik a szolgáltatások és komponensek újrafelhasználását egy infrastruktúrán belül.
A webszolgáltatások potenciális hátrányai: •
viszonylag nehézkes tranzakciókezelés
•
teljesítményben nem tartozik a leggyorsabbak közé;
•
az előnyként ismertetett HTTP tűzfalakon való átjárása hátrány is lehet adott követelményeket támasztó környezetben.
22 / 30
A fenti hátrányok azonban az automatikus adatelérési szolgáltatások esetében a rendszer viszonylagos zártsága és ellenőrzöttsége következtében nem jelentenek komolyabb kockázatot. A webszolgáltatások körébe tartozó szabványok és eljárások rendkívül kiterjedtek, számos kevésbé gyakran és néhány gyakrabban használt típussal rendelkeznek. Közülük elterjedtségük miatt kiemelkedik két koncepció, amelyek – bár nem teljesen alternatívái egymásnak, mert nem azonos absztrakciós szinten állnak – a szolgáltatások együttműködési képességének biztosítása szempontjából a legjobb választásnak tekinthetők. Ezek: •
SOAP architektúra és ráépülő rétegek: WSDL, UDDI
•
REST(ful) szolgáltatási architektúra
Jelen irányelv nem foglal egyértelműen állást ezen két lehetőség közül – tekintettel arra, hogy a technológiai világban is mindkettő nagy súllyal, párhuzamosan van jelen –, ezért a továbbiakban röviden ismertetésre kerülnek a technológiák, a feladathoz megfelelő típus kiválasztása pedig a hozzáférési SZEÜSZ-öket nyújtó szolgáltatók feladata.
5.1. SOAP-alapú architektúra A SOAP egy szabványos protokolldefiníció (szabályok gyűjteménye), amely XML-alapú üzenetküldést specifikál. A SOAP különböző adattovábbító protokollokat használhat, például HTTP/HTTPS, JMS vagy SMTP. A leggyakoribb a HTTP, amelyre épülve átjuthat a webes forgalmat áteresztő tűzfalakon és proxykon az üzenet bárminemű módosulása nélkül. A webszolgáltatásnak a protokoll jelenlegi állása szerint négy fő rétege van: •
szolgáltatásközvetítő réteg: ez a réteg felelős az alkalmazások közötti üzenettovábbításért. Jelenleg ez tipikusan HTTP/HTTPS, SMTP, FTP vagy újabban BEEP (Blocks Extensible Exchange Protocol);
•
XML-üzenetek: ez a réteg végzi az üzenetek leírását általános XML nyelven annak érdekében, hogy az üzenet tartalma a kommunikáció mindkét felén egyértelmű legyen. Jelenleg ebben a rétegben található az XML-RPC és a SOAP.
•
szolgáltatásleíró réteg: ez a réteg definiálja egy adott webszolgáltatás nyilvános felületét. Jelenleg ezt a WSDL (Web Service Description Language) segítségével végzi.
•
szolgáltatásfeltérképező réteg: ez a réteg felelős a a szolgáltatások egy közös jegyzékbe központosításáért, valamint könnyű közzétételi és keresési funkcionalitást biztosít. Jelenleg ezt a UDDI (Universal Description, Discovery, and Integration) végzi. 23 / 30
A SOAP •
alkalmazások közötti kommunikációs protokoll;
•
üzenetküldési formátum;
•
az Interneten zajló kommunikációra lett tervezve;
•
platformfüggetlen;
•
programnyelv-független;
•
egyszerű és bővíthető;
•
a W3C tartja karban.
A WSDL:
5.1.1.
•
XML-alapú formátum, útmutatójaként szolgál;
amely
webszolgáltatások
leírójaként
és
elérési
•
elosztott rendszerekre lett tervezve;
•
a szolgáltatásleírás de facto szabványa;
•
megadja a webszolgáltatás elérhetőségi módját és a szolgáltatás által nyújtott műveleteket;
•
a Microsoft és az IBM közös fejlesztésének eredménye.
Üzenetformátum
A SOAP leggyakoribb, és így ajánlott továbbítási protokollja a HTTP. Egy tipikus SOAP üzenet formátuma a következő: POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "http://www.w3.org/2003/05/soap-envelope" 24 / 30
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.example.org/stock"> <m:StockName>IBM
Az XML vált az üzenetformátum sztenderdjévé, mert széles körben használják nagyméretű cégeknél és számos nyílt forrású fejlesztési projektben is. Az XML bővíthető, ember számára is olvasható és érthető, és hatékonyan segíti az interoperabilitást technikai nehézségek (például a helyiértéki bytesorrend, az endianness) megkerülésével. Az XML formátum nagy relatív adathosszúsága miatt aránylag lassúvá válhat az adattovábbítás, viszont szöveges jellegéből adódóan sok benne a redundáns információ, amit protokollszintű vagy szállítási szintű tömörítéssel hatékonyan lehet kezelni. A tömörítés két lehetséges formája:
5.1.2.
•
HTTP-tömörítés: ha a kiszolgáló alkalmazás és a kliensek is implementálják, akkor protokollszintű tömörítés alkalmazható. A leggyakoribb tömörítési eljárás a gzip, amely az LZ77 algoritmuson alapul, így igen gyors, egymenetes lineáris tömörítést biztosít, amely ismétlődő karaktersorozatokat tartalmazó adatok esetében – amilyenek tipikusan a szövegek – átlagosan kb. 70-80% körüli adatmegtakarítást eredményez. A HTTP fejlécben a „Content-Encoding: gzip” megjelöléssel alkalmazható;
•
SSL/TLS tömörítése: a titkosított szállítási réteg tömörítése, szintén jellemzően gzip alapú, azonban reálisan csak akkor alkalmazható, ha a kommunikáció magasabb szinten (pl. protokoll) nem alkalmaz titkosítást, mert az adatfolyam kódoláskor a redundáns jellegét elveszti, így a tömörítés hatékonysága a nulla közelébe csökken.
Bináris (nem szöveges) adatok átvitele
Az adathozzáférési szolgáltatások során számos alkalommal lehet szükség nem-szöveges állományok (PDF, Word, digitalizált képek stb.) átvitelére. Ennek megvalósítására SOAP üzenetben a Message Transmission Optimization Mechanism (MTOM) és az XML-binary Optimized Packaging (XOP) párosítás alkalmazható. Az MTOM a W3C szabványa, amely a SOAP-üzenet bizonyos részeit kódolja, miközben továbbra is XML információs halmazt reprezentál a SOAP-alkalmazás számára. Az üzenetben a 25 / 30
bináris adat MIME-csatolmányként kerül továbbításra. Amennyiben a XOP eljárás nem kerül alkalmazásra, a bináris adat jellemzően base64 kódolással kerül bele a szöveges XML-be. XOP esetén az adatok közvetlenül bináris formában kerülnek a MIME-csatolmányba beágyazásra, ezzel azonban a teljeskörű XML-kompatibilitás elvész. Amennyiben az adattovábbításban a protokollszintű tömörítés megvalósítható, jelen irányelv a XOP kerülését javasolja.
Adatbiztonság
5.1.3.
A jogszabályi környezet által előírtaknak megfelelően az üzenetek titkosítására és aláírására, illetve a sínre való biztonságos kapcsolódás és csomagátvitel lehetővé tételére a WS-Security szabványkiegészítéseinek használata mindenképpen javasolt. A WS-Security három fő mechanizmust határoz meg: •
SOAP üzenetek digitális aláírása (sérthetetlenség, letagadhatatlanság)
•
SOAP üzenetek titkosítása (bizalmasság)
•
biztonsági tokenek csatolása (azonosítás)
Mivel a WS-Security az alkalmazási rétegben működik, az üzenetek végponttól végpontig titkosítva és hitelesítve vannak. Ezzel olyan körülmények között is biztonságosan alkalmazható, ahol nincs garantálva az üzenet megérkezése után a rétegek közötti bizalmas adatkezelés. Hátránya ugyanakkor, hogy jelentősen megnöveli az üzenetek méretét és a titkosítás és hitelesítés számításigényét, így teljesítménykritikus környezetben csak megfelelő körültekintéssel alkalmazható. Amennyiben a SZEÜSZ szolgáltató, illetve igénybevevő hatóságai saját infrastruktúrájukon belül garantálni tudják a bizalmas adatkezelést, a szállítási réteg titkosítása is elegendő lehet. Ezt SSL/TLS (HTTPS) igénybevételével kell megvalósítani, amely a megfelelő kulcsokkal a kommunikáló partnerek azonosítására is alkalmas.
5.2. RESTful architektúra A REST (Representational State Transfer) szerver-kliens alapú architekturális elvek halmaza, amelyek segítségével adatok továbbíthatók szabványosított interface-n (pl. HTTP) keresztül. A REST, ellentétben a SOAP-pal, nem definiál magasabb szintű kommunikációs rétegeket. Egy REST architektúrának a következő hat elvnek kell megfelelnie, miközben az egyes komponensek implementációit hagyja szabadon tervezni: •
kliens-szerver architektúra: kliensek el vannak különítve a szerverektől egy egységes interfész által, és amíg az illesztőfelület nem változik, a kliens és a szerver is fekete doboznak tekinthető; 26 / 30
•
állapotmentesség: a kliens-szerver kommunikáció során a szerveren nem tárolják a kliens állapotát a kérések között. A kliensek kérései mindig tartalmazzák az összes szükséges információt a kérés kiszolgálásához, és minden állapotot a kliens tárol. A szerver lehet állapottartó; ez a korlátozás csupán azt követeli meg, hogy a szerver oldali erőforrás-állapotok URL által címezhetőek legyenek.
•
gyorsítótárazhatóság: a kliensek itt képesek gyorsítótárazni a válaszokat. A válaszoknak ezért impliciten vagy expliciten tartalmazniuk kell, hogy gyorsítótárazhatóak-e vagy sem. Így elkerülhető, hogy a kliens téves vagy elavult adatokat használjon fel újra.
•
réteges felépítés: egy kliens általában nem tudja megmondani, hogy közvetlenül csatlakozott-e a végpont szerverhez, vagy közvetítő segítségével. A közvetítő szerverek megnövelhetik a rendszer skálázhatóságát a terhelések kiegyenlített elosztásával és megosztott gyorsítótárak használatával.
•
igényelt kód (opcionális): a szerverek képesek időlegesen kiterjeszteni vagy testre szabni egy kliens funkcionalitását programrészek átadásával, amelyeket a kliens futtatni képes. Ide tartoznak az előre fordított komponensek (pl. Java appletek) és a kliensoldali szkriptek (pl. JavaScript).
•
egységes kommunikációs felület: a kliens és a szerver között egyszerűsíti és kettéválasztja az architektúrát, és lehetővé teszi, hogy egymástól függetlenül fejlődjenek az egyes részek.
A REST a SOAP-hoz viszonyítva lényegesen egyszerűbb és kevésebb előírást tartalmaz, hiszen például nincs saját protokolldefiníciója, így rugalmasabb és könnyebben implementálható. Így akkor javasolt a használata, ha az adathozzáférési szolgáltatás funkcionálisan aránylag egyszerű.
5.2.1.
Üzenetformátum
A REST nem sztenderdizál üzenetformátumot, azonban a gyakorlatban az üzenetek szöveges reprezentálására az XML alternatívájaként is használható JSON az elterjedt. A JSON egyszerűbb az XML-nél és nélkülözi annak bonyolult sémadefinícióját, azonban amennyiben a kommunikáció bonyolultsága nem igényli, előnyösen alkalmazható kompakt mérete és könnyű olvashatósága miatt. Egy tipikus JSON üzenet formátuma a következő: {
"$schema": "http://json-schema.org/draft-04/schema#", "title": "Product", "description": "A product from Acme's catalog", "type": "object", 27 / 30
}
"properties": { "id": { "description": "The unique identifier for a product", "type": "integer" } }, "required": ["id"]
Adatbiztonság
5.2.2.
Mivel a REST a HTTP-re épül, a kézenfekvő és az elterjedt gyakorlatban is használt titkosítás az SSL/TLS (HTTPS), amely a megfelelő kulcsokkal a kommunikáló partnerek azonosítására is alkalmas. Ez viszont csak a szállítási réteg titkosítását és azonosítását végzi el, így alkalmazási végponttól végpontig nem garantálja a bizalmasságot és a sértetlenséget. A hitelesítésre használható még az Oauth1.0a protokoll is, azonban ez titkosítást nem biztosít, így bizalmasságot igénylő esetekben a HTTPS használata elengedhetetlen.
5.3. Alkalmazás- és adatbázisszerverek Az alkalmazás- és adatbázisszerverekre vonatkozóan nem szükséges különösebb előírásokat tenni, azonban mindenképpen érdemes szem előtt tartani a költséghatékonyságot, a platformfüggetlenséget és a kereskedelmi szolgáltatóktól való függetlenséget, így az infrastruktúrára vonatkozó általános jogi szabályozási környezettel összhangban az alkalmazásszerverek esetében is a nyílt forrású megoldások a támogatottak. Ez az ajánlás azonban nem zárja ki, hogy a SZEÜSZ szolgáltató indokolt esetben kereskedelmi alkalmazásszervert vegyen igénybe. Néhány példa a teljesség igénye nélkül: •
WildFly (korábban JBOSS AS), Java
•
Resin
•
IBM WebSphere
•
TomEE (Apache)
•
Geronimo (Apache)
Az alkalmazásszerverek tipikusan egy webszerver mögött futnak, amelyre vonatkozóan az alkalmazásszerverekre megadott ajánlás elvei az irányadóak. Adatbázisszerverek tekintetében szintén a bevett gyakorlatnak megfelelő szempontok az 28 / 30
irányadóak, az érintett szerver jellemzőinek figyelembe vételével. Példák: •
Oracle: kereskedelmi, nagy szakmai támogatottsággal rendelkező adatbázis-kezelő. Költséges, ugyanakkor nagy teljesítményű és megbízhatóságú kiszolgáló
•
MySQL: viszonylag kis mennyiségű, elsősorban szöveges tartalom tárolására alkalmas adatbázisszerver, megfelelően üzemeltetett környezetben és korlátozott terhelés mellett előnye a kiemelkedő gyorsasága, valamint nyílt forrású és ingyenes mivolta
•
PostgreSQL: szintén nyílt forrású és ingyenes, ugyanakkor széleskörű programnyelvi beágyazottsággal és támogatással rendelkezik, emellett teljesítménye nagy mennyiségű adat (bináris is) tárolására is alkalmassá teszi.
29 / 30
6. Felhasznált források, hivatkozások A hivatkozott jogszabályok mellett a következő forrásanyagok kerültek felhasználásra: •
A Közigazgatási és Igazságügyi Minisztérium ÁROP-1.2.10 projekt keretében készült vonatkozó munkaanyagai
•
Európai Interoperabilitási Keretrendszer (EIF) az európai közszolgálatok számára, v2.0
•
NFÜ, „Magyar e-közigazgatási architektúra”
•
E-CODEX D4.2, D6.3 „Concept of Implementation”, D6.1 „Requirements”
•
„Report on Web Service Interoperability problems found within EU-Project Akogrimo ”
•
E-TrustEx „Software Architecture Document” (Európai Bizottság)
•
CORDIS „Seventh Framework Programme (FP7)” dokumentumai
• Teljeskörű ügyfélazonosítás kiemelt projekt (KEK KH, EKOP 2.3.8), Összerendelési nyilvántartás , felsőszintű architektúra-terv
30 / 30
