Aláírás használati rend

Átírás

1 Aláírás használati rend A hibrid kézbesítési és konverziós rendszer szabályozott és központi elektronikus ügyintézési szolgáltatásaiban használt elektronikus aláírásokhoz és bélyegzőkhöz Verzió Kiadás dátuma

2 2 Aláírás használati rend

3 Tartalom 1 Bevezetés Áttekintés Az aláírás használati rend alkalmazási területe Az aláírási használati rend hatóköre és határai Alkalmazási terület Biztonságos kézbesítési szolgáltatás SZEÜSZ Kézbesítési szolgáltatás SZEÜSZ Papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ, Elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ Tranzakciós környezet, az aláírásra vonatkozó szabályok Az eidas rendeletből származó követelmények A hazai törvényi szabályozás Az e-aláírási rendelet követelményei A fenti szabályok hatása a kezelhető és alkalmazott tanúsítványokra A HKKR által előállított elektronikus bélyegzők típusai Az aláírás érvényesítésével kapcsolatos jogi előírások Az aláírás érvényességével kapcsolatos vizsgálatok esetei a HKKR-ben Az aláírás használati rend elérhetősége Az aláírás használati rend kibocsátója Az aláírás használati rend gondozása Az aláírás használati rendet gondozó szervezet Kapcsolattartó Az aláírási rend frissítése Fogalmak, rövidítések és hivatkozások A szövegben használt fogalmak értelmezése A szövegben használt rövidítések (angol-magyar) értelmezése Szabályozási dokumentumok Jogszabályi hivatkozások Szabványok, műszaki előírások Szolgáltatói dokumentumok Aláírás készítéssel, kiterjesztéssel és ellenőrzéssel kapcsolatos követelmények Általános követelmények Felhasználói interfész Általános biztonsági intézkedések

4 Az elektronikus bélyegzők bizalmi szintje Az aláíró, aláírás ellenőrző alkalmazások A rendszer egészének külső védelme Papíralapú eredetiről hiteles elektronikus másolat készítése KEÜSZ bélyegzőinek védelme Elektronikus eredetiről hiteles papíralapú másolatkészítés KEÜSZ bélyegzőinek védelme Biztonságos kézbesítési szolgáltatási, illetve kézbesítési szolgáltatás SZEÜSZ bélyegzőinek védelme A rendszer teljessége A jogi követelmények kielégítését szolgáló eljárási szabályok Személyes adatok feldolgozása Akadálymentesség a fogyatékkal élők számára Információbiztonsági követelmények Hálózati biztonsági intézkedések Információs rendszer védelmi intézkedések Vírusvédelem Hozzáférés-védelem Biztonsági patch-ek menedzsmentje Az alkalmazói szoftverek integritásának védelme Az adattárolás biztonsága Az események naplózása Feldolgozási követelmények az aláírás készítési, kiterjesztési és hitelesítési folyamatban Aláírás készítési folyamatok és rendszerek Fő funkciók A különböző adattartalom típusok menedzselése Az aláírás attribútumai Az időzítés és a sorrend kikényszerítése Az aláírás kiváltása Kriptográfiai algoritmus választása Az aláíró azonosítása és a hozzáférés ellenőrzése Az aláírandó adatok összeállítása Az aláírandó adatok megjelenítése Az aláíró eszköz menedzsmentje Az aláíró eszköz és az aláíró alkalmazás közötti kommunikáció védelme 113 4

5 Tömeges aláírási műveletek Aláírás érvényesítési folyamatok és rendszerek A fő érvényesítési folyamatok Az érvényesítési eljárási szabályok végrehajtatása Az érvényesítési szabályzat Az érvényesítés felhasználói interfésze Az érvényesítés be-, illetve kimenetének megfelelősége Aláírás kiterjesztési folyamatok és rendszerek A fő kiterjesztési folyamatok A kiterjesztési eljárási szabályok végrehajtatása Adatok bevonása a kiterjesztési folyamat során A bementő aláírás érvényesítése Fejlesztési és a kódolással kapcsolatos követelmények Biztonságos fejlesztési módszerek A megfelelés tesztelése sz. melléklet: A KEAASZ szoftver alkalmazása sz. melléklet: Az e-személyi alkalmazása elektronikus aláíráshoz Az elektronikus aláírás alkalmazásának lehetőségei és korlátjai A tanúsítványok igénylésének és kibocsátásának körülményei Az elektronikus időbélyegzés szolgáltatás Az aláírás-létrehozó adat használata és védelme Az aláírást ellenőrizni kívánó felek felelőssége, kötelezettsége A bizalmi szolgáltatási szabályzatok és az ellenőrzéshez szükséges adatok elérhetősége A panaszok benyújtása, a jogviták rendezésére vonatkozó szabályok sz. melléklet: A DSS programcsomag áttekintése, alkalmazási lehetősége aláírás és aláírás ellenőrzés során sz. melléklet: Az elektronikusan hitelesített dokumentumok ellenőrzése KEAESZ KEÜSZ segítségével Bevezetés A Kormányzati Elektronikus Aláírás Ellenőrzési Szolgáltatás A webes aláírás-ellenőrző szolgáltatás Ellenőrizhető dokumentum- és aláírástípusok PDF dokumentumok XML elektronikus aláírások ASiC formátum

6 4.3.2 Az ellenőrzés folyamata A három információs állomány szerkezete Az egyszerű riport XML állomány szerkezete A részletes riport XML állomány szerkezete Diagnosztikai adatok sz. melléklet: A PDF igazolások manuális ellenőrzésének gyakorlati lebonyolítása Beállítások A hiteles másolatok ellenőrzése sz. melléklet: A csatolt metaadatok elérése, megjelenítése

7 1 Bevezetés Az államnak kiemelkedő lehetősége és felelőssége van abban, hogy példát mutasson az elektronikus kommunikációs technológiák terjesztésében annak érdekében, hogy az állampolgárok és vállalkozások adminisztratív terhei csökkenjenek. Ugyanakkor kiemelkedő a felelőssége abban is, hogy egyrészt ezekkel az alkalmazásokkal tényleges biztonságot szolgáltasson az új, ismeretlen technológiát alkalmazó felhasználóknak, és segítsen az új technológia használatához szükséges új technológiák elterjesztésében is. Ebben a küldetésben egy hangsúlyos elem a hibrid kézbesítési és konverziós rendszer, amely a hagyományos és elektronikus technológiák közötti határok átlépését teszi mindkét irányban elehetővé a hitelesség megőrzése, biztosítása mellett, és a biztonságot kiterjeszti a kizárólagosan elektronikus térben történő közlésekre is. A hitelesség biztosításának jelenleg leginkább elfogadott, bár még nem elég széles körben használt eszköze az aszimmetrikus kulcsú titkosítási megoldásokra épülő technológia, a nyilvános kulcsú infrastruktúra. A jelen dokumentum a hibrid kézbesítési és konverziós rendszerben alkalmazott erre épülő megoldások, és az azok biztonságos használatát lehetővé tevő megoldások használatával kívánja segíteni e folyamat gyorsítását mindannyiunk hasznára. 1.1 Áttekintés A Magyar Posta Zrt. (a továbbiakban: Szolgáltató) az elektronikus ügyintézés terjesztését célul kitűző Elektronikus Közigazgatás Operatív Program keretében valósította meg a Hibrid Kézbesítési és Konverziós Rendszert (a továbbiakban HKKR). Az aláírás használati rend a HKKR-ben bármilyen összefüggésben használt, érintett elektronikus aláírások, elektronikus bélyegzők, időbélyegzők értelmezéséhez, megbízható használatához kíván támpontot adni. A továbbiakban az egyszerűbb kezelhetőség miatt azokban az esetekben, ahol az aláírások, bélyegzők és időbélyegzések megkülönböztetése nem szükséges, ott egységesen az aláírás fogalmát használjuk e dokumentumban. A széles körű használhatóság követelményéből adódik a szabályozás különleges felelőssége is, hiszen nem abszolutizálhatja a biztonságra törekvést, mivel ezzel a potenciális felhasználók körét szűkítené, hiszen akár a hatóságok, akár a magánszemélyek jelenleg még nem rendelkeznek elégséges felkészültséggel és technikai háttérrel e technológiák használatához. Ugyanezen okból ugyanakkor nem köthet a biztonságot veszélyeztető (vagy éppen csak nagyobb odafigyelést kívánó) kompromisszumokat az egyszerűbb használat érdekében, hiszen ezzel kiszolgáltatottá tenné a még nem kellően felkészült potenciális felhasználókat. Mindezen korlátok mellet is fontos cél az elektronikus hitelesítési technológiák terjesztése, evangelizációja. 7

8 Az aláírás használatának szabályozása Magyarországon, és különösen az itt elsődlegesen érintett közigazgatásban egyértelműen jogilag meghatározott, ettől a szolgáltató nem térhet el, tehát nem határozhat meg önálló aláírás szabályzatot. Valamennyi olyan aláírás-használónak, aki jogérvényesítéshez felhasználható, értelmezhető elektronikus dokumentumokat akar előállítani, meg kell felelnie egyrészt az elektronikus ügyintézés és bizalmi szolgáltatások általános szabályairól szóló évi CCXXII. törvény (a továbbiakban: E-ügyintézési törvény) és az annak végrehajtását szolgáló előírásoknak. Ugyanakkor, és ez már elsődlegesen az ezzel kapcsolatos szolgáltatásokat nyújtókra érvényes, mivel ezen szolgáltatásokat az Európai Unió összes állampolgára számára elérhetővé kell tenni, eleget kell tenniük a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról, valamint az 1999/93/EK irányelv hatályon kívül helyezéséről szóló az Európai Parlament és a Tanács 910/2014/EU rendelet (2014. július 23.) előírásainak. (a továbbiakban: eidas rendelet). Az e-ügyintézésben használható aláírásokkal kapcsolatos speciális követelményeket az elektronikus ügyintézési szolgáltatások nyújtására felhasználható elektronikus aláíráshoz és bélyegzőhöz kapcsolódó követelményekről szóló 137/2016. (VI. 13.) Korm. rendelet (a továbbiakban: e-aláírási rendelet) rendezi. Ez egyben rögzíti a felhasználható aláírásokkal, illetve azok használatával, ellenőrzésével kapcsolatos követelményeket is. Ennek megfelelően külön aláírási szabályzatot nem indokolt, de nem is lenne helyes egy szolgáltatónak használni. A jogi dokumentumokban explicit módon rögzítetteken túlterjeszkedő követelmények támasztása, mivel állam által kijelölt, kizárólagos szolgáltatóról van szó nem megengedett, csak az ott rögzített határokon belül lehet pontosítani, segíteni a hatékony megvalósítást, alkalmazást. A további, az aláírások használatára vonatkozó, az ügyfelek felé érvényesülő követelményt csak nyilvános jogszabályban lehetne előírni. Emellett van egy sor már előzetesen jogszabályban rögzített tilalom, mint például a minősített aláírásokkal (bélyegzőkkel) kapcsolatos követelményeken is túlmutató megkötések tilalma. Az ezen bármilyen értelemben túlterjeszkedő szabályozás sértené az eidas rendelet 27. cikk (1) és (3) bekezdésében, illetve a 37. cikk (2) és (3) bekezdésében rögzített, eltérést nem engedő követelményeket, de van még néhány hasonló szabály az eidas rendeletben, illetve a hazai jogszabályokban. Fontos figyelembe venni azt is, hogy a szolgáltató kizárólag az általános szerződési feltételekben (illetve bizonyos pontokon az egyedi szerződésekben) rögzíthet a szolgáltatást igénybe vevőkkel szembeni követelményeket, viszont az általános szerződési feltételek az e-ügyintézési Vhr. 64. (3) bekezdésében jelzett elvárt tartalma, illetve a BKSZ-re a 74. -ban leírtak is egyértelműen jelzik, hogy műszaki, informatikai jellegű követelményeket ez a dokumentum sem támaszthat. Cél volt, hogy aláírás használati rend melynek célja alapvetően annak igazolása, hogy az aláírással kapcsolatosa feladatok a jogszabályokkal és a biztonsági követelményekkel összhangban, célszerűen történnek szerkezetében, 8

9 gondolatmenetében kövesse az erre vonatkozó, az EU szabványosító szervezete által az aláírás alkalmazási gyakorlat elemeire kiadott műszaki előírást (ETSI TS A melléklete) (Signature application practice statement SAPS). Ezzel az is a célunk, hogy ez a dokumentum a későbbiekben összevethető legyen az elvileg ugyanebben a szerkezetben közzéteendő más aláírás-használati rendekkel, segítse azok megfogalmazását. Azt természetesen csak a jövő dönti majd el, hogy sikerült-e ezeknek a kihívásoknak eleget tenni és a jelen használati rend készítőinek és alkalmazóinak nyitottnak kell lenniük a változásokra, hiszen ilyen széles érintetti kört átfogóan kiszolgáló elektronikus aláírásokat közvetlenül alkalmazó rendszer nincs hazánkban, így az összegyűlő tapasztalatok alapján minden bizonnyal szükség lesz pontosításokra, kiegészítésekre. 1.2 Az aláírás használati rend alkalmazási területe A HKKR két értelemben is határfelületen működik, egyrészt biztosítani hivatott a közigazgatás és felhasználói közötti gyors és hatékony kommunikációt, másrészt biztosítani kell a kommunikáció hitelességét azokban az esetekben, ahol a kommunikáció átkerül a hagyományos térből az elektronikusba, illetve fordítva. Ebből a határfelületi jellegéből következően igen széles az a kör és az a felkészültségi tartomány, akik számára támpontot kell biztosítania az elektronikus hitelesség témakörében. Ugyanakkor van egy jól körülhatárolható, közvetlen felhasználója is az aláírás használati rendnek, ez Posta Közigazgatási Levelezési Központja (a továbbiakban: PKLK), amely a Magyar Posta Zrt. szervezeti egységeként felelős a hibrid kézbesítési és konverziós szolgáltatások nyújtásáért. Ez a szervezet, illetve az ott dolgozó munkavállalók használják és kezelik a rendszerben felhasznált elektronikus aláírások és bélyegzők szinte mindegyikét, ennek megfelelően a jelen aláírás használati rend fontos feladata az is, hogy meghatározza az ő feladataikat annak érdekében, hogy a sikeresnek minősített tranzakciók valóban biztosítsák a közlések hitelességét és a hitelesség bizonyíthatóságát, ugyanakkor ne kerüljön sor téves vagy indokolatlan elutasításokra, nehezítve, lassítva a kommunikációt Az aláírási használati rend hatóköre és határai A fentiekből következően a jelen aláírás használati rend potenciális hatóköre az E- ügyintézési törvény alanyi és tárgyi hatályával egyezik meg. Ennek megfelelően a következő, a törvény pontjában elektronikus ügyintézést biztosító szervezetként megjelölt szervezeti kör, valamint a velük ezen ügyek intézése során kapcsolatban álló természetes személyek és gazdálkodó szervezetek minősülhetnek első sorban felhasználónak: Elektronikus ügyintézést biztosító szerv: a) az államigazgatási szervek, 9

10 b) a helyi önkormányzat, c) a törvény vagy kormányrendelet által közigazgatási hatósági jogkör gyakorlására feljogosított egyéb jogalanyok, d) az Országos Bírósági Hivatal és a bíróságok, e) az alapvető jogok biztosa, f) az ügyészség, g) a közjegyzők, h) a bírósági végrehajtók, i) a hegyközségek kivételével a köztestületek, j) a közüzemi szolgáltatók, k) a törvényben vagy kormányrendeletben elektronikus ügyintézésre kötelezett közfeladatot ellátó vagy közszolgáltatást nyújtó jogalanyok A törvény alapján ugyanakkor van lehetőség arra is, hogy valamely, a fenti felsorolásban nem említett piaci szereplő is igénybe vegye, illetve nyújtsa ezeket a szolgáltatásokat és ezekhez kapcsolódva használja az itt felvázolt szabályozási környezetet. Ezt akkor teheti, ha szándékát bejelenti az Elektronikus Ügyintézési Felügyeletnek és a szolgáltatás igénybe vételéről megállapodik a Szolgáltatóval. Ez a szabályozási logika a gyakorlatban azt jelenti, hogy az elektronikus ügyintézést biztosító szerveknek, amennyiben a HKKR által biztosított szolgáltatásokat, vagy azok egyikét igénybe kívánják venni, figyelembe kell venniük az ezen aláírás használati rendben leírt követelményeket, megfontolásokat, mivel a Szolgáltató e keretek között képes a közvetített dokumentumok legyen az papír alapú vagy elektronikus hitelességet alátámasztani. Ugyanígy célszerű a potenciális ügyfeleknek megismerkedni a használati rendben szereplő eljárási és hitelességhez kapcsolódó követelményekkel a saját jól felfogott érdekükben, mivel ők a rendszer szolgáltatásain keresztül fognak kapcsolatot tartani a szélesen értelmezett közigazgatással. Természetesen ez csak abban a körben jelent tényleges kötelezettséget, ahol ezek a kapcsolati formák kötelezőek, a többieknél ez a saját döntésük kérdése. Nem tartoznak ugyanakkor a szabályzat hatókörében olyan, egyébként az állam, államigazgatás tevékenységével szorosan összefüggő területek, mint például az e- egészségügy, a közbeszerzés, számlázás annak ellenére, hogy az elektronikus aláírás használata ezeken a területeken is viszonylag kiterjedt. Az aláírás használati rend hatóköre alapvetően az ügyintézéssel kapcsolatos kommunikációra vonatkozik. Az aláírás használati rend személyi-szervezeti hatálya mindazokra kiterjed, akik megvalósítják, módosítják, üzemeltetik, ellenőrzik a Hibrid kézbesítési és konverziós rendszert megvalósító informatikai eszközöket és perifériákat, illetve akik a Szolgáltatással kapcsolatos tevékenységükkel összefüggésben jogviszonyban állnak a Szolgáltatóval. Az aláírás használati rend tárgyi hatálya kiterjed a szolgáltatáscsomagot megvalósító teljes informatikai rendszerre, ezen belül: 10

11 számítástechnikai berendezésekre és eszközökre (számítógépek, szkennerek, nyomtatók, hálózati eszközök), szoftverekre (operációs rendszerek, adatbázis kezelők, adatbázisok, alkalmazások), adattárolókra és adathordozókra, az informatikai rendszerben használt dokumentációkra, az informatikai rendszer biztonságos fizikai környezetére. Az aláírás-használati rend területi hatálya a Szolgáltatást biztosító telephely: 1117 Budapest, Budafoki út szám alatti telephely, A Szolgáltató informatikai szolgáltató központja, 1087 Budapest, Asztalos Sándor u. 13, A biztonsági másolatok biztonsági tárolási helye Alkalmazási terület A Magyar Posta a Hibrid kézbesítési és konverziós rendszer részeként négy, az elektronikus aláírás, elektronikus bélyegző és elektronikus időbélyegzés kiterjedt használatára épülő szolgáltatást valósított meg. Az alábbiakban az előbb említett technikák használata szempontjából mutatjuk be e szolgáltatások fő folyamatait, jelezve azokban e technikák használati eseteit, az alkalmazás céljait és korlátait. Ennek megfelelően a leírások is a hitelesség biztosításával kapcsolatos kérdésekre koncentrálnak, az ehhez szükséges lépéseket mutatják be. Az elektronikus szolgáltatásokról itt bemutatott a fő folyamatokra koncentráló folyamatábrákon egységesen piros színnel jelöltük azokat az folyamatokat, amelyek részeként hiteles elektronikus dokumentumok keletkeznek (legyen ez akár aláírás, akár bélyegző, akár időbélyegzés elhelyezése), és zöld színnel azokat, ahol a z elektronikus dokumentumok hitelességének ellenőrzése történik. Már itt jelezni kell, hogy a folyamatoknak nem része a dokumentumok hitelességének tanúsítása, illetve a hitelesség kiterjesztése. A következőkben az egyes szolgáltatásokat mutatjuk be főbb vonalaikban, ami értelemszerűen nem helyettesíti az általános szerződési feltételekben és az egyedi szerződésben szereplő részletes leírásokat. A folyamatok logikájukat tekintve egymásra épülnek a biztonságos kézbesítési szolgáltatás (esetenként ahol a biztonságos kézbesítési szolgáltatás nyújtotta többletbiztonság nem áll arányban az adminisztratív terhek növekedésével kézbesítési szolgáltatás) adja a hiteles kommunikációs csatornát, míg a két konverziós szolgáltatás hozza létre magát a továbbítandó tartalmat. 11

12 1. ábra: Az egyes szolgáltatások egymásra épülése A Magyar Posta egyetemes szolgáltatói feladatköréből adódóan külön szerződés alapján biztosítja mind a konverzióra érkező papíralapú küldemények, mind a beérkezett elektronikus dokumentumokról készített papíralapú hiteles másolatok logisztikai feladatainak ellátását is Biztonságos kézbesítési szolgáltatás SZEÜSZ A biztonságos kézbesítési szolgáltatás intézményét törvényi szinten az elektronikus ügyintézés és bizalmi szolgáltatások általános szabályairól szóló évi CCXXII. törvény szabályozza: A szolgáltatással szembeni követelményeket a törvény pontja határozza meg. E szerint: 11. biztonságos kézbesítési szolgáltatás: olyan kézbesítési szolgáltatás, amely az elektronikus küldemény kézbesítésével kapcsolatosan az alábbi feltételek mindegyikének teljesülését biztosítja: a) ha a küldőtől átvett üzenetet változatlan formában a címzett rendelkezésére bocsátották, akkor erről a küldő számára legalább fokozott biztonságú elektronikus aláírással ellátott elektronikus dokumentumba foglalt igazolás álljon rendelkezésre, b) az üzenet és a kézbesítést igazoló okirat észrevétlenül nem megváltoztatható sem a kézbesítés során, sem a kézbesítést követően, 12

13 c) az üzenet átvevője csak a címzett vagy a feljogosított helyettes átvevő lehet, és a tényleges átvevő személyét az átvétellel kapcsolatos okirat igazolja, d) a feladónak okirati bizonyíték áll rendelkezésére (tértivevény) arról az esetről is, ha a kézbesítés a megadott időn belül sikertelen; az igazolás a meghiúsulás időpontját és - ha azonosítható - okát tartalmazza; A szolgáltatás részletkérdéseit az elektronikus ügyintézés részletszabályairól szóló 451/2016 (XII.19.) Korm. rendelet (a továbbiakban: e-ügyintézési Vhr.) ai rögzítik: 73. (1) A biztonságos kézbesítési szolgáltatás olyan kézbesítési szolgáltatás, amely az elektronikus üzenet kézbesítésével kapcsolatban biztosítja az alábbi feltételek mindegyikének teljesülését: a) az üzenet fogadásának igazolása: ha a küldőtől átvett üzenetet a kézbesítési rendszer átvette, akkor erről a feladó számára feladást igazoló elektronikus okirat (e alkalmazásában a továbbiakban: okirat) áll rendelkezésre; b) sértetlenség: az üzenet és a kézbesítést igazoló okirat észrevétlenül nem változtatható meg sem a kézbesítés során, sem a kézbesítést követően; c) az átvevő igazolása: az üzenet átvevője csak a címzett vagy a feljogosított helyettes átvevő lehet, és a feladó számára a tényleges átvevőt az átvétellel kapcsolatos okirat igazolja; d) sikertelen kézbesítés igazolása: a feladónak okirat áll rendelkezésére (tértivevény) arról az esetről is, ha a kézbesítés a megadott határidőn belül sikertelen; az igazolás a meghiúsulás időpontját és - ha azonosítható - okát tartalmazza. (2) A biztonságos kézbesítési szolgáltatásnak továbbá biztosítania kell, hogy a címzett számára az üzenet elkülönített, a szolgáltató felügyelete alatt álló informatikai rendszerben legalább az (1) bekezdés d) pontja szerinti okirat kiállításáig hozzáférhető. (3) A biztonságos kézbesítési szolgáltatás alapjául szolgáló informatikai rendszernek biztosítania kell a rendszer zártságát, a jogosulatlan változtatások kizárását. A szolgáltató köteles e követelményeknek való megfelelést a felügyelet részére tanúsítvánnyal igazolni, majd a szolgáltatás nyújtása során a tanúsítványt annak lejárta előtt folyamatosan megújítani, az új tanúsítványt a felügyeletnek benyújtani. 74. A biztonságos kézbesítési szolgáltató köteles általános szerződési feltételeiben szabályozni az üzenet feladásának és fogadásának feltételeit, így különösen, hogy a) a feladó mely címzettnek küldhet üzenetet, b) a feladó milyen formátumú üzeneteket küldhet (különösen mellékletek csatolhatósága, méret- és formátummegkötések), c) a feladó az üzenetet hol és milyen módon adhatja fel, d) a szolgáltató az üzenetet mikor és milyen módon bocsátja a címzett rendelkezésére, 13

14 e) a címzett miként rendelkezhet a nevében az üzenet fogadására jogosult helyettes átvevőről, f) a címzett miként rendelkezhet arról, hogy a meghatározott időtartam alatt vagy a jövőben részére érkező üzeneteket másik biztonságos kézbesítési szolgáltatáshoz tartozó címre továbbítsák, az üzenet fogadását visszautasítsák, g) a szolgáltatás során a címzettet vagy a feladót a másik fél, illetve a szolgáltató milyen módon azonosíthatja, h) az üzenet feladása és fogadása milyen esetben és milyen módon igényli a szolgáltató közreműködését, i) az üzenet feladását, illetve az átvételt igazoló igazolást ki állítja ki, és ahhoz milyen módon jut hozzá a feladó, illetve a címzett, j) melyek a kézbesítéssel, illetve a kézbesítéssel kapcsolatos egyes tevékenységek elvégzésével kapcsolatos időbeli korlátok, és ezek túllépésének mi a következménye, k) a szolgáltató az általa továbbított üzenet tartalmát megismerheti-e, helyre tudja-e állítani, és ha igen, milyen esetben, l) mi az át nem vett üzenet sorsa, megsemmisítésének vagy visszaküldésének módja és ütemezése, m) milyen informatikai és nem informatikai eszközökkel biztosítja a szolgáltató a levéltitok megőrzését, valamint n) a szolgáltatón, a feladón és a címzetten kívül ki és milyen esetben ismerheti meg az üzenet tartalmát. 75. (1) A 73. (1) bekezdése szerinti kézbesítéssel kapcsolatos események tekintetében a szolgáltató haladéktalanul olyan igazolást köteles kiállítani a feladónak az általa megadott elektronikus elérhetőségére, amely a kézbesítési események adatait megfelelően igazolja. A szolgáltató a kézbesítési események adatait kiállított igazolásonként vagy együttesen tárolja. (2) A szolgáltató az igazolásokat alapvetően elektronikus formában biztosítja, de - ha a vonatkozó KEÜSZ nyújtására jogosult - a kézbesítést kérő vagy címzett kérésére a rájuk vonatkozó igazolásról hiteles papíralapú másolatot készít. (3) Az (1) bekezdés szerinti igazolás a szolgáltató részéről legalább fokozott biztonságú elektronikus bélyegzővel hitelesített és időbélyegzővel ellátott, valamint tartalmazza a feladó megnevezését, az üzenet lenyomatát és az érkeztető számot. 76. A biztonságos kézbesítési szolgáltatás igénybevételével kézbesített iratnál az átvételre jogszabály eltérő rendelkezése hiányában 5 napot kell biztosítani. Ha a címzett a küldeményt a határidőn belül nem veszi át, és az átvételt nem tagadja meg, akkor a kézbesítésről - az első kézbesítési kísérletre vonatkozó szabályok megfelelő alkalmazásával - az 5. nap elteltét követő első munkanapon másodszor is értesítést kap. 14

15 2. ábra: Biztonságos kézbesítési szolgáltatás SZEÜSZ alapvető folyamatlépései 15

16 A biztonságos kézbesítési folyamat főbb lépései ennek megfelelően a következők: A Feladó átadja a Címzett számára megcímzett küldeményét a rendszernek kézbesítésre. A rendszer megvizsgálja a küldeményt a rosszindulatú kódok szempontjából, ha nem talál ilyet, feladási igazolást (feladóvevényt) készít. mely egy általa elektronikus bélyegzővel és független időbélyegzéssel ellátott PDF dokumentum. Ez a dokumentum tartalmazza a Feladó és Címzett adatai mellett az eredeti küldemény lenyomatát. Az időbélyeget minősített időbélyeg szolgáltató készíti. A szolgáltató visszaküldi a feladási igazolást (tanúsítványt), mely a feladás okirati bizonyítéka. A rendszer egy értesítést hoz létre a Címzett számára a küldemény érkezéséről, illetve az átvétellel kapcsolatos feladatáról, és a kommunikáció módjától függően a tárhelyén elhelyezi vagy elérhetővé teszi az aláírandó átvételi elismervényt. A Címzett az előzetesen regisztrált elektronikus aláírásával, bélyegzőjével vagy AVDH szolgáltatással aláírja a rendszer által készített átvételi elismervényt, amivel igazolja az átvételt. Az aláírt elismervényt a visszaküldi a rendszernek. A rendszer ellenőrzi az aláírás érvényességét. A megfelelően aláírt átvételi elismervényt a rendszer tárolja. Ha nem telt le a kézbesítésre biztosított időablak, a rendszer hozzáférhetővé (letölthetővé) teszi a Címzett számára a korábban tárolt kézbesítendő üzenetet. A kézbesítésről a rendszer letöltési igazolást készít bélyegzővel és időbélyegzéssel ellátott PDF dokumentumként, melynek adattartalma megegyezik a feladóvevényével és beágyazottan tartalmazza és az aláírt átvételi elismervényt is. Ezt a BKSZ elküldi a Feladó és a Címzett részére is. A Címzett visszautasíthatja a neki címzett küldeményt, illetve lejárhat a nyitva álló kézbesítési ablak. Ezekben az esetekben a Szolgáltató kizárólag általa bélyegzővel és független szolgáltató által készített időbélyegzéssel ellátott PDF formátumú igazolást ad ki a kézbesítés meghiúsulásának körülményeiről és időpontjáról. Azt elküldi a feladónak és a küldeményt megsemmisíti E szolgáltatás részeként a Szolgáltató a különböző PDF formátumú igazolásokon helyez el minősített tanúsítványon alapuló PAdES formátumú (ETSI TS v műszaki előírásnak megfelelő) elektronikus bélyegzőt, illetve minősített időbélyegzést (EN V1.1.1 és EN V1.1.1 szabványok szerint). Ezen túlmenően időbélyegzést használ a tárolt loginformációk védelméhez. Aláírásellenőrzést pedig a Címzett által visszaadott PDF formátumú átvételi elismervényen végez Kézbesítési szolgáltatás SZEÜSZ A kézbesítési szolgáltatással kapcsolatos követelményeket összefogottan nem határozza meg jogszabály. Az e-ügyintézési Vhr ai egy étlapot adnak, amelyből a Szolgáltató által nyújtott szolgáltatás a következőket biztosítja: 16

17 82. (1) A kézbesítési szolgáltatás keretében a SZEÜSZ szolgáltató közreműködik valamely elektronikus nyilatkozat (jelen alcím alkalmazásában a továbbiakban: üzenet) kézbesítésével összefüggő egy vagy több alábbi tevékenységben, illetve ezen tevékenységek bizonyításában: a) az üzenet átvétele a feladótól, b) az üzenet továbbítása a címzettnek vagy a kézbesítésben közreműködő köztes harmadik személynek, c) az üzenetnek a címzett rendelkezésére bocsátása olyan módon, hogy a címzett a kézbesített üzenet tartalmát értelmezhető módon megismerhesse, és így az üzenetről tudomást szerezhessen (jelen alcím alkalmazásában a továbbiakban: az üzenet fogadása), d) az üzenet tárolása a címzett számára legfeljebb az általános szerződési feltételekben meghatározott időpontig, f) a feladó vagy a címzett értesítése a kézbesítéssel kapcsolatos egyes tényekről, (2) Kézbesítési szolgáltatásnak minősül [...] az internetes felületen biztosított dokumentum le-, illetve feltöltés biztosítása is, ha a) feltöltés esetén a címzett elektronikus ügyintézést biztosító szerv a felületen egyértelműen azonosított, illetve b) letöltés esetén a letöltést csak azonosítás mellett, kizárólag a címzettnek teszik lehetővé. (4) A SZEÜSZ szolgáltató a kézbesítési szolgáltatáshoz külön szolgáltatásokat biztosíthat, így különösen c) időponthoz kötött kézbesítést. 83. (4) Arról az üzenetről, amelyet a SZEÜSZ szolgáltatón kívül álló okból a címzettnek vagy az átvételre jogosult más személynek nem lehet kézbesíteni, a feladó részére igazolást szükséges kiállítani, és számára elérhetővé tenni. A Szolgáltató e feltételek teljesítését a biztonságos kézbesítési szolgáltatással közös infrastruktúrán biztosítja, a szolgáltatási szerződéssel rendelkező Igénybe vevő esetileg dönthet, hogy melyik szolgáltatást vesz igénybe, a közlés jellegével összhangban. Ennek megfelelően a folyamat elemeinek jelentős része közös, a különbség abban rejlik, hogy itt az igazolás kiadására nem az átvételről, hanem a küldemény rendelkezésre bocsátásáról történik. 17

18 3. ábra: A kézbesítési szolgáltatás SZEÜSZ alapvető folyamatlépései A Feladó átadja a Címzett számára megcímzett küldeményét a rendszernek kézbesítésre. A rendszer megvizsgálja a küldeményt a rosszindulatú kódok szempontjából, ha nem talál ilyet, feladási igazolást (feladóvevényt) készít. mely egy általa elektronikus bélyegzővel és független időbélyegzéssel ellátott PDF dokumentum. Ez a dokumentum tartalmazza a Feladó és Címzett adatai mellett az eredeti küldemény lenyomatát. Az időbélyeget minősített időbélyeg szolgáltató készíti. A szolgáltató visszaküldi a feladási igazolást (tanúsítványt), mely a feladás okirati bizonyítéka. A rendszer egy értesítést hoz létre a Címzett számára a küldemény érkezéséről, és a kommunikáció módjától függően a tárhelyén elhelyezi vagy elérhetővé teszi a küldött dokumentumot. Az elérhetővé tételről a rendszer igazolást készít elektronikus bélyegzővel és független szolgáltató által biztosított időbélyegzéssel PDF dokumentumként, mely az elérhető üzenet lenyomatát tartalmazza. Végül a KSZ az elérhetővé tételt tanúsító igazolást visszaküldi a Feladó és a Címzett részére is. E szolgáltatás részeként a Szolgáltató a különböző PDF formátumú igazolásokon helyez el minősített tanúsítványon alapuló PAdES formátumú (ETSI TS v műszaki előírásnak megfelelő) elektronikus bélyegzőt, illetve minősített időbélyegzést (EN és EN szabványok szerint). Ezen túlmenően időbélyegzést használ a tárolt loginformációk védelméhez. Aláírás-ellenőrzést ebben a szolgáltatásban nem végez. 18

19 Papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ, A Szolgáltató Hibrid kézbesítési és konverziós rendszerben megvalósított papíralapú iratról hiteles elektronikus másolatkészítést központi elektronikus ügyintézési szolgáltatásként, az E-ügyintézési tv. 38. (1) bekezdés h) pontja szerint központi elektronikus ügyintézési szolgáltatásként, az e-ügyintézési Vhr. III. fejezete és a szabályai szerint nyújtja. Az E-ügyintézési tv a szerint az iratról a papír alapú irat átalakítása hiteles elektronikus irattá szolgáltatás szabályai szerint a Kormány által kijelölt szerv által készített okirat bizonyító ereje megegyezik az eredeti okiratéval. A fenti kormányrendeletben rögzített, a feladat szempontjából releváns követelmények a következők: 55. (1) A papíralapú dokumentumról történő digitalizálás során a másolatkészítő biztosítja a papíralapú dokumentum és az elektronikus másolat képi vagy tartalmi megfelelését, és azt, hogy minden - az aláírás vagy bélyegző elhelyezését követően az elektronikus másolaton tett - módosítás érzékelhető legyen. A Szolgáltató adatfeldolgozói feladatköréből adódóan kizárólag képi megfelelést képes ebből biztosítani, ugyanis nem hozhat döntést a tartalmi megfelelésről, mert azzal adatfeldolgozói pozícióját zárná ki. (2) Papíralapú dokumentumról történő digitalizálás során a másolat készítője elkészíti az elektronikus másolatot, megállapítja a papíralapú dokumentum és az elektronikus másolat képi vagy tartalmi megfelelését, majd ellátja az elektronikus másolatot hitelesítési záradékkal Az eredeti papíralapú dokumentummal egyező és a (4) bekezdésben meghatározott követelményeknek megfelelő elektronikus aláírással vagy bélyegzővel, és ha az időpont feltüntetése szükséges, elektronikus időbélyegzővel látja el. (4) A másolaton minősített vagy minősített tanúsítványon alapuló fokozott biztonságú elektronikus bélyegzőt [...] kell elhelyezni, [...]. (5) Több dokumentumon is elhelyezhető egy elektronikus aláírás vagy bélyegző, illetve egy időbélyegző, valamint a (2) bekezdés szerinti megjelölések több dokumentumon együttesen is elhelyezhetőek. Ez esetben a dokumentumok a továbbiakban csak együtt kezelhetőek. A Szolgáltató a több oldalas küldeményekről oldalanként készít képeket és azokat a szerződés eltérő rendelkezése hiányában egy PDF dokumentummá fűzi össze a boríték képét is beleértve. (6) A másolatkészítéssel megbízott vagy arra feljogosított személyek körét belső szabályzatban kell meghatározni. (7) A másolatkészítőnek rendelkeznie kell a másolatkészítő rendszer olyan részletességű dokumentációjával, amelyből a rendszerrel szemben e rendeletben megállapított követelmények teljesülése megállapítható, vagy a rendszer gyártója/forgalmazója által kiállított, a megfelelésre vonatkozó igazolással. 19

20 (8) A másolatkészítőnek rendelkeznie kell a másolatkészítés eljárási és műszaki feltételeit, valamint a kapcsolódó felelősségi kérdéseket tartalmazó másolatkészítési szabályzattal. A másolatkészítő a másolatkészítési szabályzatot nyilvánosan, elektronikus úton közzéteszi. 57. (1) Papíralapú közokiratról vagy papíralapú magánokiratról történő elektronikus másolat készítése során a közokirat vagy arról hiteles másolat kiállítására jogosult az 55. és 56. rendelkezéseit azzal az eltéréssel alkalmazza, hogy az elektronikus másolatot a) olyan elektronikus [...] bélyegzővel látja el, amely megfelel az e rendeletben és az elektronikus ügyintézési szolgáltatások nyújtására felhasználható elektronikus aláíráshoz és bélyegzőhöz kapcsolódó követelményekről szóló 137/2016. (VI. 13.) Korm. rendeletben az elektronikus ügyintézést biztosító szerv nevében dokumentum hitelesítésére alkalmazható elektronikus aláírással vagy bélyegzővel szemben meghatározott követelményeknek, (2) Ha a közokirat vagy arról hiteles másolat kiállítására jogosult az 56. szerinti automatikus másolatkészítési eljárást ügyfelek vagy más szervek számára megküldendő iratok esetében alkalmazza, köteles egyedileg ellenőrizni a másolatok egyezőségét. A fenti jogszabályi követelményeknek megfelelően Szolgáltató vállalt feladata az Igénybe vevő részére postafiókra vagy más előzetesen leválogatható címre érkező papíralapú küldemények vagy a Szolgáltató telephelyére beszállított, és ott megfelelő bizonyítékok mellett átadott papíralapú dokumentumok átalakítása hiteles elektronikus irattá, majd az elkészült hiteles elektronikus másolat, szükség esetén az annak feldolgozását segítő további információk hiteles, dokumentált továbbítása, valamint az eredeti papíralapú dokumentumok átadása az Igénybe vevő számára. A Szolgáltatás hatóköre ennek megfelelően az alábbi feladatok ellátására terjed ki: előkészítés, az alábbi folyamatok megvalósításával: o postai előkészítés, illetve az Igénybe vevő által a Szolgáltató telephelyére szállított papíralapú dokumentumok hiteles átvétele, az átvett dokumentumok összevetése a kísérő elektronikus (esetleg hagyományos, papíralapú) dokumentummal. o a papíralapú dokumentumok (küldemények) fogadása, kezelése, egyedi azonosítóval történő ellátása, o a küldemények osztályozása (szortírozása), az ablakos borítékban érkezett küldemények esetén zárt állapotban kép készítése a küldeményről, majd azok bontása, o dokumentumok előfeldolgozása (szkennelésre alkalmassá tétel), másolatkészítés (digitalizálás), a másolatkészítés teljességének biztosítása az előzetes borítékképpel történő összerendelés, hitelesítés, az alábbi folyamatok megvalósításával: 20

21 o az elkészült másolat a vonatkozó jogszabályi előírások alapján történő képi, tartalmi megfelelőségének ellenőrzése, o az elkészült másolat hitelességének (képi megfelelőségének) igazolása hitelesítési záradékkal, minősített elektronikus bélyegzővel és független minősített szolgáltató által nyújtott időbélyegzéssel, 4. ábra: A papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ alapvető folyamatlépései erre vonatkozó szerződés alapján egyes metaadatok rögzítése az eredeti papíralapú dokumentumokról készült (metaadatokkal kiegészített, hitelesítési záradékkal, elektronikus ügyintézésre alkalmas, minősített tanúsítványon alapuló fokozott biztonságú elektronikus bélyegzővel és független minősített időbélyeg-szolgáltató által adott időbélyeggel ellátott) hiteles elektronikus másolatok eljuttatása elsődlegesen a BKSZ útján, valamint időszakonként a papíralapú eredeti küldemények dobozolt átadása az Igénybe vevőnek. A Szolgáltató az ismertetett feladatok ellátásához biztosítja a személyi és tárgyi feltételeket. Szolgáltatás hatóköre az elkészült másolatok Szolgáltató általi megőrzésének kizártsága miatt nem terjed ki az alábbi feladatok ellátására: az elektronikus másolatok és ezek sértetlenségének hosszú távú megőrzése, az elektronikus másolatok hosszú távú rendelkezésre állásának és olvashatóságának biztosítása, 21

22 az elektronikus másolatok hitelességét (az eredeti papíralapú dokumentumnak való képi megfelelőségét) és sértetlenségét (minden későbbi módosítás kizárását) garantáló a Szolgáltató által elhelyezett elektronikus aláírás és időbélyegzés érvényességének érvényességi időn belüli és szükség esetén azon túli folyamatos fenntartása, illetve ennek felhasználásával a változatlanság megállapítása. E feladatok az átvett elektronikus irat birtokában az Igénybe vevőre hárulnak, a Szolgáltató az elektronikus irat átvételének igazolása után az átalakítás során keletkezett elektronikus dokumentumot (másolatot) haladéktalanul törli, kizárólag az átadás bizonyítékait és a másolat leíró adatait őrzi meg. E szolgáltatás részeként a Szolgáltató az elkészített, alapesetben PDF formátumú hiteles másolatokon helyez el minősített tanúsítványon alapuló PAdES formátumú (ETSI TS v műszaki előírásnak megfelelő) elektronikus bélyegzőt, valamint független szolgáltató által biztosított minősített időbélyegzést (EN V1.1.1 és EN V1.1.1 szabványok szerint). Ezen túlmenően időbélyegzést használ a tárolt loginformációk védelméhez. Aláírás-ellenőrzést ebben a szolgáltatásban annyiban végez, hogy meggyőződik az aláírandó dokumentumok megfelelő összeállításáról és az elektronikus bélyegzés és időbélyegzés sikeres elhelyezéséről Elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ A Szolgáltató Hibrid kézbesítési és konverziós rendszerben megvalósított elektronikus irat hiteles papíralapú irattá alakítását az E-ügyintézési tv. 38. (1) bekezdés i) pontja szerint központi elektronikus ügyintézési szolgáltatásként, az E- ügyintézési tv. és az e-ügyintézési Vhr aiban rögzített szabályok szerint nyújtja. Az E-ügyintézési tv a szerint az elektronikus iratról az elektronikus irat hiteles papír alapú irattá alakítása szolgáltatás szabályai szerint a Kormány által kijelölt szerv által készített okirat bizonyító ereje megegyezik az eredeti okiratéval. A fenti kormányrendeletben rögzített, a feladat szempontjából releváns követelmények a következők: 122. (1) Az elektronikus irat hiteles papíralapú irattá alakítását az elektronikus ügyintézést biztosító szerv, valamint a Kormány által kijelölt szervezet jelen alcím rendelkezései szerint végezheti. (2) Ha az elektronikus dokumentum papír alapon történő hiteles megjelenítésének műszaki feltételei adottak, a másolatban rögzíteni kell: a) az elektronikus dokumentum szöveges és ábrázolt tartalmát, b) kiadmányozott dokumentum esetén záradékban az eredeti iratot kiadmányozó személy, valamint az elektronikus ügyintézést biztosító szerv nevének és az aláírás időpontjának szöveges megjelenítését, elektronikus bélyegzővel ellátott 22

23 elektronikus dokumentum esetén a bélyegzőhöz tartozó tanúsítvány szerint a bélyegző létrehozóját meghatározó adatokat, c) záradékban az elektronikus dokumentum azonosítására vagy a másolat készítésére vonatkozó azon adatokat, amelyek az a) pont szerinti tartalomból nem állapíthatóak meg, de a másolatot kérő erre vonatkozóan megfelelő adatot szolgáltatott, d) az elektronikus dokumentumban foglaltakkal egyező tartalmú irat záradékszöveget, e) a papíralapú másolat keltezését, f) a másolat hitelesítésének módja szerint a másolatkészítő szervezet elnevezését és a másolatkészítésért felelős, a másolat hitelesítésére jogosult személy aláírását és bélyegzőlenyomatát, az iratérvényességi nyilvántartás szabályai szerinti hitelesítését vagy a (4) bekezdés szerinti hitelesítésre történő utalást. (4) A papíralapú másolat úgy is elkészíthető, hogy a szolgáltató a teljes, hitelesített elektronikus dokumentumot elhelyezi a papíralapú másolaton, az adatok elektronikus leolvashatóságát biztosító kód formájában. A papíralapú másolat e kód alapján hiteles, ha a kód alapján visszaállított eredeti elektronikus dokumentum megegyezik a papíralapú másolattal. (5) A másolatkészítő a másolat elkészítését megelőzően köteles ellenőrizni azt, hogy az eredeti elektronikus irat az aláírás és a másolatkészítés időpontja között megváltozott-e, továbbá, hogy az aláírás időpontjában az azt hitelessé tevő tanúsítvány érvényes volt-e. A (2) bekezdés c) pontja szerinti adatok tartalmazzák a sértetlenség ellenőrzését igazoló, valamint a hitelesség ellenőrzését lehetővé tevő információkat Elektronikus irat hiteles papíralapú irattá alakítása szolgáltatást olyan szervezet végezhet, amely teljesíti az alábbi személyi követelményeket: a) a másolatkészítésért felelős személy büntetlen előéletű, és b) a szolgáltató által bevezetett ellenőrzési rendszerben a szolgáltató szabályzata szerint független ellenőr végzi a másolatkészítés szabályszerűségének ellenőrzését (1) A másolat automatikusan is elkészíthető, ha a) a másolatkészítés zárt rendszerben történik, amelynek külső beavatkozástól mentes, az eredeti és a másolat összerendelését tekintve garantáltan hibamentes működését auditálás igazolja, b) a másolatkészítő rendszer megfelelő műszaki és szervezési megoldással biztosítja a másolat olvashatóságát és a mintavételezésen alapuló minőségbiztosítást. (2) Automatikus másolatkészítés esetén a dokumentumonkénti tartalmi ellenőrzés helyett véletlenszerű mintavételezésen alapuló ellenőrzés is alkalmazható. 23

24 (3) Automatikus másolatkészítés esetén a záradék tartalmazza az automatikus másolatkészítés tényét Az egységes kormányzati ügyiratkezelő rendszerből történő irattovábbítás során az elektronikus irat hiteles papíralapú irattá alakítása esetén a szolgáltató a NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. részére is biztosítja a másolatkészítés során a technikai ellenőrzés lehetőségét (1) A szolgáltató általános szerződési feltételeiben vagy szolgáltatási szabályzatában köteles rögzíteni az elektronikus dokumentum átvételének, a másolatkészítésnek a rendjét, valamint a másolatkészítés teljesítésének feltételeit. A másolatkészítés vállalt határideje legfeljebb 1 munkanap lehet, és - ha az elektronikus irat hiteles papíralapú irattá alakítását megrendelő elektronikus ügyintézést biztosító szerv vagy ügyfél a papíralapú másolat postai küldeményként való feladását igényli - a szolgáltatónak a papíralapú másolatot az elkészítését követő munkanapon postára kell adnia. (2) A szolgáltató általános szerződési feltételeiben, illetve a hatósággal kötött megállapodásában köteles szabályozni a másolatkészítésre átvett elektronikus dokumentumokkal kapcsolatos teendőit. (3) A szolgáltató a szolgáltatás során az igénybe vevő elektronikus ügyintézést biztosító szerv adatfeldolgozójaként jár el. A fenti jogszabályi követelményeknek megfelelően Szolgáltató vállalt feladata az Igénybe vevő által elsődlegesen biztonságos kézbesítési szolgáltatás igénybe vételével megküldött, esetleg közvetlenül, dokumentáltan eljuttatott, és ott megfelelő bizonyítékok mellett átadott elektronikus dokumentumok hiteles átalakítása papíralapú dokumentumokká, majd az elkészült hiteles papíralapú másolatok eljuttatása a címzettekhez külön egyetemes postai szolgáltatási szerződés alapján. A Szolgáltatás hatóköre ennek megfelelően az alábbi feladatok ellátására terjed ki: érkeztetés: Elektronikus dokumentumok (küldemények és adatállományok), valamint az átalakításhoz és postai továbbításhoz szükséges információt tartalmazó kézbesítési utasítások (a továbbiakban kézbesítési utasításként hivatkozzuk) fogadása elsődlegesen a Magyar Posta Zrt által a 84/2012 (IV. 21.) Korm. rendelet 4. c) pontjában kapott felhatalmazás alapján nyújtott BKSZ útján, a Szolgáltató a fenti rendeletben kapott kijelölés alapján nyújtott szolgáltatásokat nyújtó portálfelületén és webszolgáltatáson keresztül történik. A Magyar Posta a Hivatali kapun keresztüli biztonságos kézbesítést használó közigazgatási szervek konverziós igényeinek kiszolgálása érdekében együttműködik az ezt szolgáltatást a 84/2012 (IV.21.) Korm. rendelet 4. c) pontjában kapott felhatalmazás alapján nyújtó NISZ Zrt.- vel. 24

25 Lehetőség van arra is, hogy kizárólag a kézbesítési utasítás kerüljön biztonságos csatornán továbbításra, ebben az esetben a küldemények nagyobb átbocsátó képességű csatornán (pl. SFTP-n vagy adathordozón) is eljuttathatók, mivel az integritás ellenőrzéséhez szükséges információt a kézbesítési utasítás tartalmazza. A visszaigazolások ebben az esetben a kézbesítési utasítás továbbítására használt csatornán jutnak vissza az Igénybe vevőhöz. Amennyiben az elektronikus dokumentum és a kézbesítési utasítás nem biztonságos csatornán (pl. adathordozón, helyszíni, az üzemben történő átadással) érkezik, akkor a Szolgáltató lehetőség szerint az eredeti adathordozón elektronikusan aláírja és időbélyeggel látja el a kapott dokumentumcsomag egészét (több dokumentumot egyben), majd az aláírt csomagról a maga számára másolatot készít. Amennyiben az eredeti adathordozó tulajdonságai miatt az aláírás az eredetin nem lehetséges, akkor az aláírásra a másolaton kerül sor és akkor ez, az átadó jelenlétében, felügyeletével készült másolat veszi át az eredeti szerepét. Az eredetit (illetve a másolatot) aláírva, időbélyegzéssel ellátva a Szolgáltató az Igénybe vevőnek visszaadja. A további munka alapját az így elkészített elektronikus másolat képezi és vita esetén csak erre lehet hivatkozni. A Szolgáltató az elektronikus dokumentumok és kézbesítési utasítások együttesét két formátumban fogadja: a) Az átalakítandó elektronikus dokumentumok (állományok) és a kézbesítési utasítás együttese, melyet a másolatkészítési rendben együttesen küldeményként jelölünk. A kézbesítési utasítás a küldemény első eleme és ez tartalmazza az átalakítandó (papíralapon megjelenítendő) állományok felsorolását is. Ebben az esetben a küldő feladata, hogy az egyes küldemények egymástól történő egyértelmű elválasztását, illetve a benne szereplő egyes csatolmányok egyértelmű azonosíthatóságát (különböző nevekkel) biztosítsa. Egy küldemény összesen maximum 10 állományt tartalmazhat, melyek közül az első a kézbesítési utasítás. b) Az Európai Unió SPOCS projektje részeként kidolgozott OCD konténer hazai megvalósításaként kialakított KRX állományba csomagolva az a) pontban leírt tartalmak (valamint esetleg más leíró adatok is, amelyek azonban nem kerülnek felhasználásra az átalakítás során). Ebben az esetben a KRX csomag szerkezete lehetővé teszi azonos nevű csatolmányok feldolgozását is, mivel a belső könyvtárszerkezet önmagában is egyértelmű azonosítást biztosít. A beérkezett elektronikus dokumentumok előkészítése (kicsomagolása) ellenőrzése (az adatállományok ellenőrzése a vírusmentesség vizsgálata és az Általános Szerződési Feltételekben, illetve az Egyedi szerződésben foglalt formátumnak való megfelelés ellenőrzése). Az beküldött állományok elnevezése során figyelni kell arra, 25

26 hogy bár a kézbesítési utasítás az UTF-8-as kódolást használja, így az NTFS szabvány által megengedett összes karakter használata megengedett lenne, a különböző operációs rendszerek alapértelmezésben eltérő kódtáblákat használhatnak, tehát a biztonságos beküldéshez célszerűbb az ékezetek nélküli ANSI 7 bites karakterekből (az állománynévben általánosan tiltottak kivételével) álló neveket használni. Kerülendő az állománynéven belül a pont használata, azt csak a kiterjesztés elválasztásához használjuk. Az ellenőrzés sikeres lezárását követően a dokumentum fogadásának visszaigazolása (Átvételi igazolás Dispatch receipt) a BKSZ eljárásrendjével megegyezően. Ilyen pozitív visszaigazolás birtokában tekinthető a küldemény feladottnak, ugyanis amennyiben nem felet meg, akkor a befogadást megakadályozó hibáról tartalmaz az igazolás információt. Az átvételi igazolás hiánya a kommunikáció meg nem történtét, a szolgáltatás meghiúsulását jelzi. Ha az Igénybe vevő nem kapott Átvételi igazolást, ez azt jelenti, hogy a Szolgáltató nem fogadta a küldeményt, tehát a feladás nem történt meg. Ilyen esetben célszerű egyrészt ellenőrizni, hogy a kapcsolat a biztonságos kézbesítési szolgáltatóval rendben van-e, másrészt megfelelő várakozás után ismételten megkísérelni az elküldést. Amennyiben a Szolgáltatótól független BKSZ-en keresztül történik a feladás, akkor az ő visszaigazolása csak az általa történt átvételt igazolja, nem jelenti azt, hogy a küldemény ténylegesen eljutott a Szolgáltatóhoz, csak ha az Átvételi igazolás megérkezett. Ez egyes esetekben akár több órát is igénybe vehet. Ezt követi a másolatkészítés előkészítése A kézbesítési utasítás elemzése, a benne szereplő adatok ellentmondásmentességének ellenőrzése, a szerződésben esetleg rögzített további szabályok alkalmazása, nem megfelelés esetén visszajelzés az Igénybe vevőnek. A dokumentumon szereplő elektronikus aláírás vagy bélyegző érvényességének ellenőrzése, annak eredménytelensége esetén visszajelzés az Igénybe vevőnek az átalakítás meghiúsulásáról. Ahol az elektronikus ügyintézésre vonatkozó jogszabályok lehetővé teszik a bélyegzők használatát, ott a hibrid kézbesítési és konverziós rendszer nem akadályozza ezek használatát. Mivel a szolgáltató az egyes küldemények tartalmát nem ismerheti meg, nincs abban a helyzetben, hogy az aláírások és bélyegzők funkcionális megfelelőségét megítélje, kizárólag formai megfelelőséget ellenőriz. Az Egyedi szerződésben rögzített, az elkészülő hiteles másolat hitelességének ellenőrizhetőségét lehetővé tevő eljárásnak megfelelő előkészítés. Egy szerződésben csak egy ellenőrzési módszer alkalmazható. (Értelemszerűen kiegészítve az ellenőrzés nem alkalmazásának lehetőségével, amire a kézbesítési utasítás <IsAuthenticCopy>= N értékének beállítása ad módot): 26

27 a) Az eredeti aláírt elektronikus dokumentum QR kódok formájában történő kinyomtatása az olvasható megjelenítést követően. Az ehhez szükséges adatok előkészítése, azzal a nyomtatandó állomány kiegészítése; b) lenyomaton alapuló iratérvényességi nyilvántartás bejegyzés: az elektronikus irat lenyomatának és a belőle készített szövegkivonat lenyomatának elkészítése; aláírt bejegyzési kérelem összeállítása és elküldése az iratérvényességi nyilvántartás KEÜSZ számára; az iratérvényességi nyilvántartás KEÜSZ a bejegyzésről szóló visszaigazolásának rögzítése (naplózása); Másolatkészítés: az elektronikus dokumentumok csoportokba, gyártási egységekbe rendezése elsődlegesen a termelés-optimalizálás szempontjai szerint. Ezt követően a postai szállítás optimalizálása érdekében a címadatok alapján kerülhet sor újabb rendezésre. amennyiben a kézbesítési utasítás alapján szükséges, a postai azonosító (ajánlási, nyilvántartási ragszám) kiosztása; az elektronikus iratból nyomtatási kép készítése az adott feladatra kiválasztott nyomtató(k) számára alkalmas formátumban; a kézbesítési utasítás ilyen rendelkezése esetén a Magyar Posta előírásainak megfelelő (formátum, betűtípus és méret) címzőlap előkészítése, azzal a nyomtatandó állomány kiegészítése; a záradékok előkészítése a kézbesítési utasítás, illetve az Egyedi szerződésben meghatározott, a dokumentum hitelességének ellenőrzését lehetővé tevő eljárás követelményeivel összhangban, azzal a nyomtatandó állomány kiegészítése; a gépi nyomtatást és borítékolást támogató küldeményazonosító vezérlő jelek előkészítése, azzal a nyomtatandó állomány kiegészítése; a nyomtató, esetenként nyomtatók meghajtására alkalmas állomány(ok) generálására az elektronikus dokumentum és a szerződésből. illetve a gyártásszervezésből származó kiegészítő információk alapján; digitális nyomtatás a kiválasztott nyomtatón (nyomtatókon) a nagy teljesítményű nyomtatókon a megjelenítés automatizált ellenőrzésével, a vágott lapos nyomtatókon a teljességellenőrzés manuális; 27

28 5. ábra: Az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ alapvető folyamatlépései Méretre vágás, hajtogatás, borítékolás (a kézbesítési utasítás tartalmától függően); Amennyiben a kézbesítési utasítás előírja, a borítékon a címzettre, illetve feladóra vonatkozó információ elhelyezése; Amennyiben a kézbesítési utasítás előírja, a tértivevény elkészítése és rögzítése a küldeményen; Amennyiben a kézbesítési utasítás postai feladást ír elő, az elkészült küldeményekről elektronikus feladójegyzék készítése a postai szabályoknak megfelelően; Az elkészült küldemények feladása a küldő nevében a Magyar Posta Országos Logisztikai Központjában (a továbbiakban rövidítve: OLK); 28

29 A visszaigazolt feladójegyzék és a gyártási információk összevetése nyomán szükséges esetleges javítások végig vitele; A felvett küldeményekről visszakapott elektronikus átvételi igazolás megküldése az Igénybe vevőnek; Amennyiben nem postai továbbítás szerepelt a megrendelésben, az elkészült hiteles másolatok átadása az Igénybe vevőnek. A Szolgáltató az ismertetett feladatok ellátásához biztosítja a személyi és tárgyi feltételeket. A Szolgáltatás, a feladat jellegéből következően, nem terjed ki a Szolgáltatónak megküldött elektronikus dokumentumok a feladás visszaigazolását követő megőrzésére, mivel az elektronikus eredetiket (a küldemények tartalmát) a sikeres feladás, átadás visszaigazolását követően a Szolgáltató haladéktalanul megsemmisíti. Az elektronikus eredeti megőrzésével kapcsolatos teendők az Igénybe vevő feladatát képezik a levéltári törvény szabályai szerint. A Szolgáltató kizárólag a kézbesítési utasítást, a feladat végrehajtása során keletkezett naplózási adatokat és a küldemény egyértelmű azonosítására alkalmas lenyomatot (hash) őrzi meg, amennyiben a szerződésben más nem szerepel, 5 éves időtartamra. A tárolt adatokból a küldemény tartalma nem ismerhető meg, viszont azonosítható, hogy egy adott elektronikus dokumentum szerepel-e benne. E szolgáltatás részeként a Szolgáltató a különböző PDF formátumú igazolásokon helyez el minősített tanúsítványon alapuló PAdES formátumú (ETSI TS v műszaki előírásnak megfelelő) elektronikus bélyegzőt, illetve minősített időbélyegzést (EN és EN szabványok szerint). Az iratérvényességi nyilvántartással folytatott kommunikációban XAdES (ETSI TS műszaki előírásnak megfelelő) formátumú aláírást használ. Ezen túlmenően időbélyegzést használ a tárolt loginformációk védelméhez. Aláírás-ellenőrzést végez első lépésben a XAdES formátumú kézbesítési utasításokon, majd pedig a hiteles másolatokon elhelyezendő záradékok tartalmának meghatározásához. Itt van lehetőség mind PAdES, mind az egyébként konverzió szempontjából megengedett formátumok esetében XAdES formátumú aláírások ellenőrzésére Tranzakciós környezet, az aláírásra vonatkozó szabályok Amint az Az aláírási használati rend hatóköre és határai c. fejezetből és az előbbi rövid ismertetésből is látható, a HKKR kiterjedten használ első sorban elektronikus bélyegzőket az általa kiadott elektronikus igazolások hitelesítésére, de fontos a hitelesség biztosításához a benyújtott elektronikus aláírások érvényességének ellenőrzése is. Az az e-aláírási rendelet az E-ügyintézési tv-ben kapott felhatalmazás alapján, az eidas rendeletben meghatározott követelményekre támaszkodva részletesen meghatározza, hogy milyen aláírások, illetve bélyegzők használhatók az elektronikus 29

30 ügyintézésben, és ez értelemszerűen vonatkozik minden elektronikus ügyintézést biztosító rendszerre is, mint minimumkövetelmény. Bár az E-ügyintézési törvény egyáltalán nem említi, és az e-ügyintézési Vhr. is csak az AVDH-val kapcsolatban írja elő, az eidas rendelet szabályozási logikájából egyértelműen következik, hogy kizárólag minősített időbélyeg szolgáltatás alkalmazható valamennyi a rendszerben felhasznált esetben, hiszen az eidas rendelet 41. cikk (2) bekezdése kizárólag a minősített időbélyegző használata esetére írja elő a feltüntetett dátum és időpont pontosságnak, valamint az adott dátumhoz és időponthoz kapcsolt adatok sértetlenségének vélelmét. E vélelem hiányában viszont maga a szolgáltatási logika nem építhető fel. Mivel a szabályozás további követelményt nem állapít meg, minden a bizalmi listán szereplő minősített időbélyeg-szolgáltató szolgáltatását el kell fogadni. Önálló aláírási szabályzatban további követelmények megállapítása nem lenne kezelhető, hiszen e szabályzat felhatalmazás hiányában a fenti jogszabályokhoz képest már nem határozhat meg többletkövetelményeket. Ennek oka, hogy a Szolgáltató ebben az esetben a kormány által kijelölten látja el a szolgáltatást, tehát csak azt szabályozhatja, amire kifejezetten jogszabályi felhatalmazást kapott. Az aláírás-használatra vonatkozóan azonban egyik jogszabályban sem szerepel szabályozási lehetőség. Ennek megfelelően a Szolgáltató kizárólag saját dolgozói számára állapíthat meg, a jogszabályi környezettel összhangban álló feldolgozási, eljárási szabályokat. Adatfeldolgozói pozíciójából következően alvállalkozóira sem állapíthat meg önállóan követelményeket, csak azt érvényesítheti, amit már jogszabály számára előír Az eidas rendeletből származó követelmények Eddig lényegében anélkül használtuk az elektronikus aláírás és az elektronikus bélyegző fogalmát, hogy annak a tartalmát tisztáztuk volna. Ezt itt pótoljuk. Az eidas rendelet (az Európai Parlament és a Tanács 910/2014/EU rendelete (2014. július 23.) a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról, valamint az 1999/93/EK irányelv hatályon kívül helyezéséről) szabályozási logikája három csoportra osztja az elektronikus aláírásokat. Az első maga a gyűjtőfogalom, az elektronikus aláírás, amelyet a rendelet 3. cikk 10. pontja a következőképpen határoz meg: Elektronikus aláírás : olyan elektronikus adat, amelyet más elektronikus adatokhoz csatolnak, illetve logikailag hozzárendelnek, és amelyet az aláíró aláírásra használ. Itt kell tisztázni az aláíró definícióját is, aki a 3. cikk 9. pontja szerint az elektronikus aláírást létrehozó természetese személy. Ezzel párhuzamosan hozza létre a szabályozás az elektronikus bélyegző fogalmát is, hogy válaszolni tudjon arra a kérdésre, hogy mi van abban az esetben, amikor az aláírást létrehozó (erre a fentiek szerint nem használhatjuk az aláíró fogalmát) nem természetes személy. Ezt a 3. cikk 25. pontja definiálja: Elektronikus bélyegző : olyan elektronikus adatok, amelyeket más elektronikus adatokhoz csatolnak, illetve 30

31 logikailag hozzárendelnek, hogy biztosítsák a kapcsolt adatok eredetét és sértetlenségét. A fentiekkel összhangban a 3. cikk 24. pontja szerint a bélyegző létrehozója az elektronikus bélyegzőt létrehozó jogi személy. Mind a két definíciónál jól látszik, hogy tulajdonképpen az elektronikus aláírásnak, illetve bélyegzőnek egy lényegi tulajdonsága van, hogy egy már létező elektronikus állományhoz fizikailag vagy logikailag kapcsolják, és valamilyen szinten hivatott arra, hogy a dokumentum eredetét és sértetlenségét alátámassza. Nincs azonban megkötés ennek a bizonyító képességnek a mértékére. Ennek a követelményrendszernek akár egy aláírás vagy bélyegző képe, akár egy levelező rendszerben előállított aláírás is megfelel. Ezekre az aláírásokhoz és bélyegzőkhöz ennek megfelelően az eidas rendelet csak minimalista jogi következményeket kapcsol. Pusztán azt rögzíti a 25. illetve 35. cikkekben, hogy az elektronikus aláírás, illetve elektronikus bélyegző joghatása és bírósági eljárásokban bizonyítékként való elfogadhatósága nem tagadható meg kizárólag amiatt, hogy az elektronikus formátumú, illetve nem felel meg a minősített elektronikus aláírásra, illetve minősített elektronikus bélyegzőre vonatkozó követelményeknek. Ez azt jelenti, hogy itt a bizonyító erő szabad bírói mérlegelés kérdése, pusztán azt tiltja meg, hogy azért, mert csak elektronikusan létezik, ezért ne legyen bizonyítékként felhasználható. Ugyanakkor nem ír elő semmit arra vonatkozóan, hogy ezeket az aláírásokat, illetve bélyegzőket a közigazgatásnak (ahol nem lehet egyedi mérlegelést végezni minden egyes elektronikus dokumentumra vonatkozóan) hitelesítő eszközként figyelembe kellene vennie. A rendelet létrehoz egy aláírás, illetve bélyegző kategóriát, amelyhez szigorú teljesítmény követelményeket kapcsol. Ez az fejlett, vagy ahogy Magyarországon inkább elterjedt, a fokozott biztonságú elektronikus aláírások, illetve bélyegzők kategóriája. Négy lényegi követelményt állapít meg a 26. illetve 36. cikkekben Aláírás 31 Bélyegző a) kizárólag az aláíróhoz köthető; a) kizárólag a bélyegző létrehozójához kötött; b) alkalmas az aláíró azonosítására; b) alkalmas a bélyegző létrehozójának azonosítására; c) olyan, elektronikus aláírás létrehozásához használt adatok felhasználásával hozzák létre, amelyeket az aláíró nagy megbízhatósággal kizárólag saját maga használhat; d) olyan módon kapcsolódik azokhoz az adatokhoz, amelyeket aláírtak vele, hogy az adatok minden későbbi változása nyomon követhető. c) olyan, elektronikus bélyegző létrehozásához használt adatok felhasználásával hozzák létre, amelyeket a bélyegző létrehozója nagy megbízhatósággal kizárólag saját maga elektronikus bélyegző létrehozására használhat; d) olyan módon kapcsolódik azokhoz az adatokhoz, amelyekre vonatkozik, hogy az adatok minden későbbi változása nyomon követhető; 1. táblázat: A fokozott biztonságú aláírással, illetve bélyegzővel szembeni követelmények az eidas rendelet alapján A fokozott biztonságú aláírásokra, illetve bélyegzők jogi bizonyító erejére vonatkozóan nem tartalmaz külön kötelező érvényű szabályt a rendelet, a fenti követelmények teljesülése esetén azonban szabad mérlegeléssel is komoly bizonyító erő kapcsolódik ezekhez a formákhoz.

32 A rendelet erre a kategóriára sem írja elő, hogy az egyes tagállamok közigazgatásainak ezt az aláírási, illetve bélyegző kategóriát el kellene fogadnia. A fordított szabályozási logikát követi. Ahol a közigazgatás egy adott ügytípusban elfogadja a fenti követelményeket teljesítő elektronikus aláírásokat, illetve bélyegzőket, ott ezt az ügyfelek oldaláról nemzeti megkülönböztetés nélkül meg kell tenni. A fokozott biztonságú elektronikus aláírás kategóriája már a rendelet megszületése előtt is létezett, és annak ellenére, hogy korábban is voltak bizonyos minimális műszaki jellegű követelmények ezen aláírás-kategóriával szemben különböző műszaki előírások és munkacsoport megállapodások formájában, az interoperabilitás hiánya komoly zavarokat okozott. Ezért az eidas rendelet felhatalmazta a Bizottságot, hogy végrehajtási határozatban rögzítse azokat a követelményeket, amelyeknek a közigazgatási szervek által elismert fokozott biztonságú elektronikus aláírások és fokozott biztonságú bélyegzők formátumainak meg kell felelniük. Ezt a felhatalmazást a Bizottság szeptember 8-i (EU) 2015/1506 Végrehajtási Határozata a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló 910/2014/EU európai parlamenti és tanácsi rendelet 27. cikkének (5) bekezdése és 37. cikkének (5) bekezdése szerint a közigazgatási szervek által elismert fokozott biztonságú elektronikus aláírások és fokozott biztonságú bélyegzők formátumaira vonatkozó specifikációk meghatározásáról töltötte ki tartalommal. Mind az elektronikus aláírásokra, mind az elektronikus bélyegzőkre vonatkozóan meghatározott olyan, az Európai Unió Távközlési Szabványosítási Intézete (ETSI) által kiadott műszaki előírásokat, amelyeknek megfelelő fokozott biztonságú aláírásokat a tagállamok közigazgatásainak kezelniük kell, amennyiben az adott ügytípusban egyébként megengedték az elektronikus ügyintézését fokozott biztonságú aláírással. Végül a teljes rendelet szabályozási logikájával összhangban létrehozták erre a szolgáltatásra vonatkozóan is a minősített szolgáltatási kategóriát a minősített elektronikus aláírás, illetve minősített elektronikus bélyegző formájában. A minősítettséghez kapcsolódó többletkövetelmény ebben az esetben is két irányban jelentkeznek, egyrészt magának a szolgáltatásnak az adminisztratív minőségében (adatkezelés, ellenőrzés minősége, megbízhatósága), másrészt az aláíró eszköz technikai biztonsága szintjén jelenik meg. Ennek megfelelően a két definíció: Aláírás 3. cikk 12. pont 3. cikk 27. pont minősített elektronikus aláírás : olyan, fokozott biztonságú elektronikus aláírás, amelyet minősített elektronikus aláírást létrehozó eszközzel állítottak elő, és amely elektronikus aláírás minősített tanúsítványán alapul; Bélyegző minősített elektronikus bélyegző : olyan, fokozott biztonságú elektronikus bélyegző, amelyet minősített elektronikus bélyegzőt létrehozó eszközzel állítottak elő, és amely elektronikus bélyegző minősített tanúsítványán alapul; 2. táblázat: a minősített aláírás, illetve bélyegző meghatározása az eidas rendelet alapján 32

33 Az elektronikus aláírások minősített tanúsítványra vonatkozó követelményeket a rendelet I. melléklete tartalmazza, a minősített aláíró eszköz esetében a II. melléklet követelményeit kell érvényesíteni. Ezek a követelmények lényegében azonosak a korábbi minősített aláírásra vonatkozó követelményekkel és alapvetően arra épülnek, hogy az aláírási folyamatban az aláíró személyes közreműködésére, ellenőrzésére minden lépésben lehetőséget kell adni, a nélkül a folyamat nem mehet végbe. A minősített elektronikus bélyegzők tanúsítványával szemben i követelményeket a III. melléklet határozza meg, ez a tartalmában megfelel a minősített aláírás tanúsítványára vonatkozó előírásnak két különbséggel. Az első különbség, hogy értelemszerűen az aláíró helyett a bélyegző létrehozója szerepel az adatokban. A második a fontosabb, a bélyegző esetében mindig legalább a bélyegző létrehozójának a hivatalos nyilvántartásban szereplő neve és adott esetben (amikor van ilyen a nyilvántartásban) nyilvántartási száma kell szerepeljen a tanúsítványban. A bélyegző létrehozására, és az eszközök tanúsítására vonatkozóan a 39 cikk csak annyit mond, hogy értelemszerűen alkalmazni kell a 29., 30. és 31. cikkek rendelkezéseit. Ez az értelemszerűen és vele a teljes eidas rendelet sajnos nem tisztáz egy sor kérdést, ami az elektronikus bélyegzők gépesített, automatizált használatával kapcsolatban felmerül, holott a kategória létrehozásával az erre vonatkozó lehetőség megteremtése is cél volt. Mivel az értelemszerű határai nem rögzítettek, tehát jogilag kötelező érvényű előírás nem létezik erre vonatkozóan, ilyen tehát számon se kérhető. A rendelet (56) preambulum bekezdése minősített aláíró eszközök tanúsításának kereteire vonatkozóan a következőket rögzít: Nem célszerű, hogy e rendelet kiterjedjen annak a rendszerkörnyezetnek az egészére, amelyben az ilyen eszközök üzemelnek. Ezért a minősített aláírást létrehozó eszközök tanúsítását azon hardver-eszközökre és rendszerszoftverekre kell korlátozni, amelyek az aláírást létrehozó eszközzel létrehozott, tárolt, illetve feldolgozott, aláírás létrehozásához használatos adatok kezelésére és védelmére szolgálnak. A vonatkozó szabványokban részletesen meghatározottak szerint a tanúsítási kötelezettség köréből ki kell zárni az aláírást létrehozó alkalmazásokat. A rendelet 25. cikke a minősített elektronikus aláírásokra vonatkozóan két irányú egyenértékűséget rendel el, és a közigazgatási felhasználásra vonatkozóan a 27 rögzít egy fontos korlátot: A minősített elektronikus aláírás a saját kezű aláírással azonos joghatású. A valamely tagállamban kibocsátott minősített tanúsítványon alapuló minősített elektronikus aláírást az összes többi tagállamban el kell ismerni minősített elektronikus aláírásként. A közigazgatási szervek által nyújtott online szolgáltatások határokon átnyúló igénybevétele tekintetében a tagállamok nem követelhetnek meg a minősített elektronikus aláírásnál magasabb biztonsági szintű elektronikus aláírást. 33

34 A párhuzamos szabályok az elektronikus bélyegzőkre kissé másképp jelennek meg. A 35. cikk szerinti szabályok itt csak a határon átnyúló szolgáltatások esetében párhuzamosak, itt a vélelem a változatlanságra áll fenn a rendelet alapján. Ebből következően az egyes tagállamoknak joguk van meghatározni, mikor és milyen célra használhatók az elektronikus bélyegzők. Ugyanakkor itt is érvényes a közigazgatásra vonatkozó korlátozás a 37. cikk alapján. A minősített elektronikus bélyegzők esetében vélelmezni kell a hozzájuk kapcsolódó adatok sértetlenségét és a bélyegzőnek megfelelő eredetét. A valamely tagállamban kibocsátott minősített tanúsítványon alapuló minősített elektronikus bélyegzőt valamennyi tagállamban el kell ismerni minősített elektronikus bélyegzőként. A közigazgatási szervek által nyújtott online szolgáltatások határokon átnyúló igénybevétele tekintetében a tagállamok nem követelhetnek meg a minősített elektronikus bélyegzőnél magasabb biztonsági szintű elektronikus bélyegzőt. A korábbi tapasztalatok alapján a bizottság felhatalmazást kapott egy második végrehajtási határozat kiadására is az egyes tagállamok közötti együttműködés feltételeinek biztosítása érdekében. A korábbi elektronikus aláírási szabályozás a vállalkozás szabadságát tekintette alapelvnek, az új szabályozás azonban felismerte, hogy az aláírók (és ebbe is bele kell érteni a bélyegzőket használó jogi személyeket is) személyének azonosítása csak akkor alkalmas arra, hogy más, az adott tagállamtól független hatóságok is elfogadják a tanúsítványban szereplő azonosító adatokat, ha azért az adott tagállam felelősséget vállal. A szolgáltatási irányelv kapcsán ez a kérdés már szabályozásra került a Bizottság 2009/767/EK határozatával, amely kötelezően előírta a tagállamok számára, hogy hozzanak létre, tartsanak fenn és tegyenek közzé olyan bizalmi listát, amelyben szerepelnek az elektronikus aláírás irányelvvel összhangban a nyilvánosság számára minősített tanúsítványt kiállító, a tagállamok által felügyelt és akkreditált hitelesítés-szolgáltatókra vonatkozó adatok. Ezen bizalmi szolgáltatók tanúsítványaiban szereplő azonosító adatok az adott állam nyilvántartási adatinak való megfelelésért és az eljárás megbízhatóságáért végső soron az adott tagállam vállal felelősséget. Erre építve az eidas rendelet 22. cikke kötelezően előírja a tagállamok számára, hogy biztonságos módon és automatizált feldolgozásra alkalmas formában tegyék közzé ezt a bizalmi listát. Ehhez a végrehajtási rendelet rögzíti a bizalmi listák formátumát, szerkezetét meghatározó ETSI műszaki előírást (a hivatalos magyar fordítás tévesen szabványnak minősíti) Ugyanakkor megfordították a szabályozás logikáját az eidas rendelet hatályosulása óta egy bizalmi szolgáltató és az általa nyújtott bizalmi szolgáltatás akkor tekintendő minősítettnek, ha a bizalmi listában minősített státus van a szolgáltatóhoz, illetve szolgáltatáshoz. Ugyanakkor a tagállamok jogosultak arra, hogy önkéntes alapon és nemzeti szinten a minősített szolgáltatásoktól eltérő bizalmi szolgáltatásokat is 34

35 felvehessenek a bizalmi listára, feltéve, hogy világosan jelezve van, hogy ezek a szolgáltatások nincsenek az eidas rendelet értelmében minősítve. Ugyanakkor csak a bizalmi listán szereplő szolgáltatások esetében értelmezhető a határon átnyúló szolgáltatási képesség. 6. ábra: Az elektronikus aláírások egyes halmazainak viszonya egymáshoz (az ábra értelemszerűen vonatkozik a bélyegzőkre is) A hazai törvényi szabályozás Mivel az eidas rendelet közvetlenül alkalmazandó, így a hazai szabályozás értelemszerűen csak azokra a kérdésekre tér ki, amelyek szabályozását a rendelet a nemzeti jogokra bízta. Így a rendelet (49) preambulum bekezdésével összhangban az elektronikus aláírások joghatásának kérdését a nemzeti jogoknak kell meghatároznia azon kívül, hogy a minősített elektronikus aláírásnak a saját kezű aláírással egyenértékű joghatással kell bírnia. Ezt a feladatot a magyar jogban már több mint 15 éve a Polgári perrendtartás (Pp), jelenleg a évi CXXX. törvény látja el az okiratok fajtáinak szabályozásáról szóló 94. fejezetével. Az elektronikus közokiratra vonatkozó követelményeket a 323. tartalmazza: 323. [A közokirat] (1) A közokirat olyan papír alapú vagy elektronikus okirat, amelyet bíróság, közjegyző vagy más hatóság, illetve közigazgatási szerv ügykörén belül, a jogszabályi rendelkezéseknek megfelelő módon állított ki. 35

36 (4) Elektronikus közokirat kiállításához az is szükséges, hogy a közokirat kiállítására jogosult az elektronikus okiraton ha jogszabály eltérően nem rendelkezik minősített vagy minősített tanúsítványon alapuló fokozott biztonságú elektronikus aláírást vagy bélyegzőt, és amennyiben jogszabály így rendelkezik időbélyegzőt helyezzen el. (6) Közokirattal szemben is van helye ellenbizonyításnak, kivéve, ha azt törvény kizárja vagy korlátozza. Esetünkben ennek a szabályozásnak annyiban van jelentősége, hogy a közigazgatási szervek által kiállított elektronikus közokiratokkal szemben ezeknek a követelményeknek az érvényesülését kell vizsgálni ahhoz, hogy eldönthető legyen, közokiratról készült-e a másolat. Fontos tudni, hogy nincs olyan jogszabály, amely általános érvénnyel előírná az időbélyegzés használatát, azt egyes speciális esetekre követeli meg csak a magyar jog, tehát időbélyeg nélkül is teljes értékű közokiratot lehet készíteni, annak ellenére, hogy ilyen esetben a hitelesség bizonyítása gyengébb lábakon áll, szélesebb lehetőség kínálkozik az ellenbizonyításra. Olyan törvényi szabály pedig nem ismert, amely az elektronikus közokiratok esetében kizárná dokumentummal szemben az ellenbizonyítás lehetőségét. Hasonlóképpen épül fel a teljes bizonyító erejű magánokirat szabályozása is a ban 325. [A teljes bizonyító erejű magánokirat] (1) Teljes bizonyító erejű a magánokirat, ha f) az elektronikus okiraton az aláíró a minősített vagy minősített tanúsítványon alapuló fokozott biztonságú elektronikus aláírását vagy bélyegzőjét helyezte el, és amennyiben jogszabály úgy rendelkezik azon időbélyegzőt helyez el, g) az elektronikus okiratot az aláíró a Kormány rendeletében meghatározott azonosításra visszavezetett dokumentumhitelesítés szolgáltatással hitelesíti, vagy (3) A teljes bizonyító erejű magánokirat az ellenkező bizonyításáig teljes bizonyító erővel bizonyítja, hogy az okirat aláírója az abban foglalt nyilatkozatot megtette, illetve elfogadta vagy magára kötelezőnek ismerte el. (4) A teljes bizonyító erejű magánokirat valódiságát csak akkor kell bizonyítani, ha azt az ellenfél kétségbe vonja, vagy a valódiság bizonyítását a bíróság szükségesnek találja. (5) Ha a teljes bizonyító erejű magánokiraton szereplő aláírás valódisága nem vitás vagy bizonyított, illetve a legalább fokozott biztonságú elektronikus aláírás vagy bélyegző vagy zárt rendszerben alkalmazott bizalmi szolgáltatás keretében a kiállító saját kezű aláírására egyértelműen visszavezethető adatok ellenőrzésének eredményéből más nem következik, az aláírást vagy a bélyegzőt megelőző szöveget elektronikus okirat esetén az aláírt vagy bélyegzővel ellátott adatokat az 36

37 ellenkező bizonyításáig meg nem hamisítottnak kell tekinteni, kivéve, ha az okiratnak olyan rendellenességei vagy hiányai vannak, amelyek e vélelmet megdöntik. (7) Ha a legalább fokozott biztonságú elektronikus aláírással vagy bélyegzővel ellátott elektronikus okirat aláírójának vagy bélyegző létrehozójának azonossága, illetve az okirat hamisítatlansága kétséges, ezek megállapítása érdekében a bíróság elsősorban az elektronikus aláíráshoz vagy bélyegzőhöz tartozó tanúsítványt kibocsátó bizalmi szolgáltatót keresi meg. Az elektronikus okirathoz kapcsolt időbélyegző által igazolt adatokkal kapcsolatos kétség esetén a bíróság elsősorban az időbélyegzést végző bizalmi szolgáltatót keresi meg. A fentiekből látható, hogy a magyar jog az eidas rendelettel összhangban azon az alapon áll, hogy egy elektronikus dokumentum hitelességét az elektronikus aláíráshoz vagy bélyegzőhöz tartozó tanúsítványt kibocsátó bizalmi szolgáltató kell első sorban garantálja, az aláírás készítése során maga az algoritmus olyan mértékben zárt, hogy vagy az egyszerű ellenőrzés kimutatja az eltérést vagy pedig azt változatlannak kell tekinteni, ha maga az algoritmus megfelelt a követelményeknek. Itt is érvényes az időbélyegző használatára vonatkozóan az elektronikus közokiratoknál tett megjegyzés. Az E-ügyintézési törvény csak kiegészítő szabályokat állapít meg magára az aláírásra vonatkozóan, a szabályozási tárgya a bizalmi szolgáltatások szempontjából mint az elektronikus aláírás és az elektronikus bélyegző, illetve időbélyegzés az érintett bizalmi szolgáltatásokkal, szolgáltatókkal szembeni követelmények rögzítése. Ezzel együtt van néhány olyan szabály, amelyet fontos figyelembe venni: A 25. alapján az elektronikus ügyintézést biztosító szerv köteles olyan, elektronikus ügyintézést biztosító információs rendszer működtetésére, amely biztosítja legalább a legalább fokozott biztonságú és közigazgatási követelményeknek megfelelő elektronikus aláírással, illetve elektronikus bélyegzővel ellátott elektronikus dokumentumok feldolgozását és e törvény előírásainak megfelelően hitelesített dokumentumok előállítását. Az elektronikus ügyintézést biztosító szervek körét az fejezetben már bemutattuk. Aláíráshoz a törvény 92. (1) bekezdés b) pontja szerinti mindenkori hatósági határozat szerint biztonságosnak minősített kriptográfiai algoritmusok használhatók. Ezen határozatok a Nemzeti Média- és Hírközlési Hatóság honlapján érhetők el. A 97.szakasz a minősített aláírásokra és bélyegzőkre rögzíti a változatlanság vélelmét (bár ezt az eidas rendelet is megetette) de rögzít mellette két fontos korlátozást, amely az eidas rendeletben nem szerepel. (2) A tanúsítvány alanya az elektronikus aláírás vagy bélyegző létrehozásához használt adatot kizárólag elektronikus aláírás, illetve bélyegző létrehozására használhatja, betartva a tanúsítványban jelzett esetleges egyéb korlátozásokat is. 37

38 (3) A minősített elektronikus aláírási vagy bélyegző tanúsítvány felhasználható fokozott biztonságú elektronikus aláírás, illetve bélyegző létrehozására is. Ezzel bizonyos hibás gyakorlatok veszélyét kívánja korlátozni. Ugyanakkor a 99. szakasz megállapít egy olyan egyenértékűségi szabályt, amelyet elsődlegesen a folyamatok automatizálást kívánja segíteni (2) Ahol valamely jogszabály elektronikus aláírást vagy elektronikusan aláírt dokumentumot említ, azon kifejezett eltérő rendelkezés hiányában elektronikus bélyegzőt vagy elektronikus bélyegzővel ellátott dokumentumot is érteni kell. Végül a törvény 105. szakasza felhatalmazza a kormányt, hogy rendeletben állapítsa meg az elektronikus ügyintézés céljaira felhasználható elektronikus aláírásokra, az elektronikus aláíráshoz tartozó tanúsítványokra, illetve az azokkal összefüggésben nyújtott elektronikus aláírással kapcsolatos szolgáltatásokra vonatkozó sajátos követelményeket. E felhatalmazás alapján született a 137/2016. (VI. 13.) Korm. rendelet az elektronikus ügyintézési szolgáltatások nyújtására felhasználható elektronikus aláíráshoz és bélyegzőhöz kapcsolódó követelményekről (a továbbiakban: e-aláírási rendelet) Az e-aláírási rendelet követelményei Az e-aláírási rendelet a következő követelményeket rögzíti minden elektronikus ügyintézésre felhasznált aláírással, illetve bélyegzővel szemben: 5. (1) Ha törvény eltérően nem rendelkezik, az E-ügyintézési tv. szerinti ügyekben az elektronikus ügyintézést biztosító szerv olyan elektronikus aláírást vagy bélyegzőt használhat, amely megfelel az e rendeletben meghatározott követelményeknek. (2) Az elektronikus ügyintézést biztosító szerv a funkcionális működésével összefüggő ügyekben ha azokkal kapcsolatban az E-ügyintézési tv. alkalmazását vállalta olyan elektronikus aláírást vagy bélyegzőt használhat, amely megfelel az e rendeletben meghatározott követelményeknek. 6. Elektronikus ügyintézési célra olyan elektronikus aláírás, elektronikus bélyegző vagy tanúsítvány használható, amely a) az ügyintézésben közreműködő, kiadmányozásra nem jogosult személy (a továbbiakban: ügyintéző) által használt aláírás esetén a 13. -ban meghatározott követelményeknek, b) az ügyintézést biztosító szerv nevében kiadmányozásra feljogosított természetes személy által használt aláírás esetén a 14. -ban meghatározott követelményeknek, c) az ügyintézést biztosító szerv számítógépes rendszere által dokumentum- vagy kommunikációhitelesítésre használt bélyegző esetén a 15. -ban meghatározott követelményeknek megfelel. 38

39 7. Az elektronikus aláírást vagy bélyegzőt az elektronikus ügyintézést biztosító szerv az 5. szerinti ügyekben akkor használhatja, ha az legalább fokozott biztonságú, és a) elektronikus ügyintézést biztosító állami szerv esetén a tanúsítványát olyan bizalmi szolgáltató bocsátotta ki, amelynek nyilvános kulcsát a közigazgatási gyökér-hitelesítésszolgáltató felülhitelesítette, b) a bizalmi szolgáltató hitelesítési rendje szerint a tanúsítvány kibocsátását megelőző személyazonosítás (a továbbiakban: regisztráció) során - ha e rendelet eltérően nem rendelkezik - a 9. és 10. -ban foglaltak szerint jár el, és c) az aláírás vagy bélyegző megfelel a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló, július 23-i 910/2014/EU európai parlamenti és tanácsi rendelet 27. cikkének (5) bekezdése és 37. cikkének (5) bekezdése szerint a közigazgatási szervek által elismert fokozott biztonságú elektronikus aláírások és fokozott biztonságú bélyegzők formátumaira vonatkozó specifikációk meghatározásáról szóló, szeptember 8-ai (EU) 2015/1506 bizottsági végrehajtási határozatban foglalt követelményeknek. Értelemszerűen itt nem vizsgáljuk azokat az eljárási, nyilvántartási követelményeket, amelyeket a tanúsítványokat kiállító hitelesítés-szolgáltatóknak kell teljesíteniük, hiszen a Szolgáltatónak fel kell tételeznie, hogy szabályszerűen működő hitelesítésszolgáltatók adják ki a tanúsítványokat, amennyiben maguk a tanúsítványok tartalmukat tekintve megfelelnek a fentiekben bemutatott követelményeknek A fenti szabályok hatása a kezelhető és alkalmazott tanúsítványokra Az előbbiekben dokumentált követelmények kihatnak mind a Szolgáltató, mind az Igénybe vevők által alkalmazható tanúsítványokra. A Szolgáltató mivel az e-aláírási rendelet 5. szakaszában szereplő elvi lehetőséggel szemben nincs olyan törvény, amely eltérési lehetőséget biztosítana és az ezen aláírás-használati rendben szereplő szolgáltatások vonatkozásában (kivéve a kézbesítési szolgáltatást, de az nem elválasztható) jogszabály útján kijelölt szolgáltató kizárólag az e rendeletben rögzített követelményeknek megfelelő aláírást, illetve bélyegzőt használhat. Ennek megfelelően szolgáltató a NISZ által kibocsátott minősített bélyegző tanúsítványokat használ, a bizonyítékok előállításához, így az általa készített bélyegzők megfelelnek a rendelet előírásainak. (a 6. ábra legbelső halmazába tartoznak) A küldemények átvételére alkalmas aláírások, illetve bélyegzők megfelelőségére két féle követelmény érvényesítendő. Ezek teljesülését a regisztráció során kell ellenőrizni. Amennyiben az Igénybe vevő elektronikus ügyintézést biztosító szerv, úgy az átvételre jogosító tanúsítványnak szintén a legszűkebb halmazba, a közigazgatási 39

40 gyökér-hitelesítésszolgáltató által felülhitelesített aláírási, illetve bélyegző tanúsítványok közé kell tartoznia. Ez egyben garancia a tanúsítványt kibocsátó hitelesítés-szolgáltató regisztrációs és adatkezelési eljárásrendjének megfelelőségére is. Amennyiben az Igénybe vevő nem elektronikus ügyintézést biztosító szerv, úgy a tanúsítványnak csak az általános feltételnek kell megfelelnie, a kibocsátójának szerepelnie kell a bizalmi listán, így biztosított, hogy a tanúsítvány ügyfél oldalon alkalmas elektronikus ügyintézésre, biztosított mögötte a megfelelő állami hitelességi háttér. A fenti elvi követelményt két szempontból érdemes kiegészíteni. Mivel sokan nem rendelkeznek saját elektronikus aláírással a biztonságos kézbesítési szolgáltatás útján érkező dokumentumok átvételéhez, a szolgáltató az AVDH szolgáltatást is alkalmassá kívánja tenni erre a célra. Ennek jelenleg pdf formátumú dokumentumok esetében, amit a szolgáltatás használ, az AVDH tanúsítvány megoldásából adódó korlátja van, nem egyértelmű, hogy mire vonatkozna az aláírás. A fejlesztési célok között szerepel ezen nehézség áthidalása. A fenti a szabályokból következik az is, hogy a 2015/1505 és vagy 2015/1506 bizottsági végrehajtási határozatban foglalt követelményeket ki nem elégítő elektronikus aláírások, illetve bélyegzők kezelésére ott, ahol a Szolgáltatónak egyáltalán feladata az aláírások ellenőrzése nem kell felkészülni, azokat, mint nem megfelelőket el kell utasítania. Értelemszerűen az elektronikus kézbesítési szolgáltatások útján, illetve másolatok formájában azokat is továbbítani kell. Mivel a hibrid konverziós szolgáltatás igénybe vevője a jelenleg hatályos ÁSZF szerint kizárólag elektronikus ügyintézést biztosító szerv lehet, a kézbesítési utasítás aláírása (bélyegzése) céljára használt tanúsítványnak, mindenképpen a KGYHSZ által felülhitelesített tanúsítványnak kell lennie. Hiteles másolat a beküldött elektronikus dokumentumról abban az értelemben, hogy a hiteles másolat törvény előtti bizonyító ereje az eredetivel azonos, elvileg minden elektronikus dokumentumról készíthető. Természetesen a másolat bizonyító erejére ebben az esetben is érvényes az e-ügyintézési törvény 42. szabálya: Az elektronikus iratról az elektronikus irat hiteles papír alapú irattá alakítása szolgáltatás szabályai szerint a Kormány által kijelölt szerv által készített okirat bizonyító ereje megegyezik az eredeti okiratéval. Azaz lehet, és értelmezett a hiteles másolat akkor is, ha az eredetire hitelességi követelmény nem volt, azonban utóbb a másolattal szemben csak a másolatkészítés értelmében támasztható ilyen követelmény, ez az eredeti hitelességére vonatkozóan nem keletkeztet semmiféle vélelmet. Ez az adott eljárásrend mellett azért megvalósítható, mert az iratérvényességi nyilvántartásban való elhelyezés önmagában (természetesen az eredeti ellenőrizhetősége mellett) lehetővé teszi a másolat hitelességének igazolását. (Ha csak a QR kódban kerülne rányomtatásra a tartalom, akkor ez egy alá nem írt dokumentum esetében nem alkalmas megoldás) Azonban a záradékban azokban 40

41 az esetekben, ha a dokumentumon olyan aláírás (bélyegző) szerepel, amely tanúsítványának kibocsátója nem szerepel a bizalmi listán az szerepel, hogy az aláírás hitelessége nem ellenőrizhető. Az e-aláírási rendelet kiadmányozókra vonatkozó speciális követelményeket rögzítő 14. -a nem tartalmaz követelményt elkülönítő információ feltüntetésére vonatkozóan a tanúsítvány tartalmában, nem biztosítja a kiadmányozásra jogosult személyek (illetve egyes esetekben bélyegzők, ahol ezt az adott szervezet saját szabályozása lehetővé teszi) pusztán tanúsítványban rögzített információk alapján történő megkülönböztetésének lehetőségét. Ezért a Szolgáltató az Igénybe vevők bejelentésére van utalva ebben a kérdésben. Egyes foglalkozási csoportoknál, az aláírói minőség feltüntetése követelmény (bírók, ügyészek, ügyvédek, közjegyzők, jogtanácsosok), azonban mivel ez nem általános erre nem lehet rendszert építeni. Az ÁSZF-nek megfelelően a kiadmányozásra jogosult elektronikus aláírások, illetve bélyegzők tanúsítványainak SHA-1 lenyomatait meg kell adniuk a kiadmányozásra való jogosultság ellenőrizhetősége érdekében. A fentiekből következően pusztán az Igénybe vevő hiányos adatszolgáltatása miatt nem lehet visszautasítani a másolat elkészítését egy a kézbesítési utasításban kiadmányozottnak jelölt, de kiadmányozásra jogosultként nem regisztrált aláírással (bélyegzővel) ellátott dokumentum esetén. A kiadmányozási jogosultság utólag is igazolható, ellenőrizhető az e-aláírási rendelet 14. (5) és (6) bekezdése alapján, a záradékban szereplő információtól függetlenül is. Maga a hiba feltüntetésre kerül a gyártási információk között, így az Igénybe vevő a visszaküldött hibrid gyártási igazolás alapján szükség esetén még tud intézkedni is a postai továbbítás előtt is A HKKR által előállított elektronikus bélyegzők típusai A HKKR által előállított elektronikus bélyegzővel hitelesített dokumentumok közös tulajdonsága, hogy valamennyi a NISZ Zrt. által kibocsátott minősített, elektronikus ügyintézésre alkalmas tanúsítványok használatára épül, mindegyik teljesíti legalább a minősített tanúsítványon alapuló fokozott biztonságú aláírások az eidas rendelet szerinti követelményrendszerét. A dokumentumok négy csoportba oszthatók (a továbbiakban, ahol ezt a továbbiakban szükséges külön tárgyalni, ezek szerint a csoportok szerint tárgyaljuk az eseteket): a) A legnagyobb számossággal a hitelesen továbbított, illetve átalakított dokumentumokkal kapcsolatos PDF formátumú elektronikus igazolások készülnek mind a négy korábban tárgyalt folyamatban, amelyeken fentiekben leírt elektronikus bélyegzőt helyez el a rendszer, és erre szintén a NISZ által kibocsátott minősített időbélyegzés kerül. Ezek az igazolások teljes egészében automatizáltan, zárt folyamatban, emberi beavatkozás nélkül készülnek. Az egyes folyamatokhoz kapcsolódóan kibocsátott igazolások számát és folyamat béli helyét az előző fejezet mutatja be. A bélyegzőre vonatkozó információk: formátum: PAdES-T az ETSI TS V2.2.2 ( ) előírás szerint, összhangban a Bizottság szeptember 8-i (EU) 2015/1506 végrehajtási 41

42 határozatával (ez egyben független szolgáltató által elhelyezett minősített időbélyegzést is jelent), típus: minősített tanúsítványon alapuló fokozott biztonságú bélyegző, a bélyegző tanúsítvány szabványa: X509v3, bélyegző tanúsítvány célja: dokumentum hitelesítése, bélyegző tanúsítvány típusa: minősített, elektronikus ügyintézési felhasználásra alkalmas, bélyegző létrehozója: Magyar Posta Zrt., algoritmus: RSA, magánkulcs hossza: 2048 bit, magánkulcs tároló: biztonságos hardveres tároló eszköz (HSM), az eszköz EAL 4+ minősítéssel rendelkezik (TÜV Rheinland) bélyegző elhelyezkedése: egyszeres, a PDF dokumentumba beágyazott nincs többszörös aláírás (bélyegzés), a tanúsítvány kibocsátója: NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. által működtetett Kormányzati Hitelesítés Szolgáltató, b) A szolgáltatás alapértelmezett és minden felhasználó számára érzékelhető hitelességének biztosítása szempontjából a papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ részeként az átalakítással nyert elektronikus dokumentum hitelességének biztosítására szolgáló elektronikus bélyegző bír kiemelt jelentőséggel, mivel az adott esetben ez a dokumentum hitelességének biztosításában a kiindulópont. Miután a másolatot készítő operátor minden egyes oldalt egyenként megvizsgált az olvashatóság és teljesség szempontjából és a supervisor is véletlenszerű mintavétellel ellenőrizte a másolatok megfelelőségét, ezeken az ebben az esetben is PDF formátumú dokumentumokon a fentiekben leírt jellemzőkkel bíró elektronikus bélyegző, és erre szintén a NISZ által kibocsátott minősített időbélyegzés kerül. A bélyegző jellemzői ebben az esetben az előzőekkel megegyezően a következők: formátum: PAdES-T az ETSI TS V2.2.2 ( ) műszaki előírás szerint, összhangban a Bizottság szeptember 8-i (EU) 2015/1506 végrehajtási határozatával (ez egyben független szolgáltató által elhelyezett minősített időbélyegzést is jelent), típus: minősített tanúsítványon alapuló fokozott biztonságú bélyegző, a bélyegző tanúsítvány szabványa: X509v3, bélyegző tanúsítvány célja: dokumentum hitelesítése, bélyegző tanúsítvány típusa: minősített, elektronikus ügyintézési felhasználásra alkalmas, bélyegző létrehozója: Magyar Posta Zrt., algoritmus: RSA, magánkulcs hossza: 2048 bit, magánkulcs tároló: biztonságos hardveres tároló eszköz (HSM), az eszköz EAL 4+ minősítéssel rendelkezik (TÜV Rheinland) 42

43 bélyegző elhelyezkedése: egyszeres, a PDF dokumentumba beágyazott nincs többszörös aláírás (bélyegzés), a tanúsítvány kibocsátója: NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. által működtetett Kormányzati Hitelesítés Szolgáltató, E két bélyegzési és időbélyegzés elhelyezési megoldás jogszabályi követelmények teljesítése, harmadik személyek felé megfelelő bizonyító erő biztosítása érdekében, a változatlanság és hiteles forrás azonosíthatósága céljából jellemzően, de nem kizárólagosan közhatalmi, közigazgatási eljárásokban és dokumentumokon kerül alkalmazásra. A másik két esetben a kommunikáció hitelességének technikai biztosítása indokolja a bélyegző, illetve időbélyegzés elhelyezését. c) Az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ megvalósítása során az elektronikus eredeti változatlanságának ellenőrzésére és az összevethetőség biztosítására általában az iratérvényességi nyilvántartás KEÜSZ kerül alkalmazásra. Annak érdekében, hogy a nyilvántartásnak átadott információk hitelessége utólag is igazolható legyen az átadott információcsomagon is elektronikus bélyegző és időbélyegzés kerül elhelyezésre, és a HKKR naplózó rendszere is eltárolja ezeket az üzeneteket. Itt, mivel az adatcsomag egy XML állomány, az alkalmazott formátum XAdES, szintén a fentieknek megfelelő aláírás-létrehozó adatot, valamint a NISZ minősített időbélyegzési szolgáltatását használva. formátum: XAdES-T az ETSI TS v ( ) műszaki előírás szerint, összhangban a Bizottság szeptember 8-i (EU) 2015/1506 végrehajtási határozatával (ez egyben független szolgáltató által elhelyezett minősített időbélyegzést is jelent), típus: minősített tanúsítványon alapuló fokozott biztonságú bélyegző, a bélyegző tanúsítvány szabványa: X509v3, bélyegző tanúsítvány célja: dokumentum hitelesítése, bélyegző tanúsítvány típusa: minősített, elektronikus ügyintézési felhasználásra alkalmas, bélyegző létrehozója: Magyar Posta Zrt., algoritmus: RSA, magánkulcs hossza: 2048 bit, magánkulcs tároló: biztonságos hardveres tároló eszköz (HSM), az eszköz EAL 4+ minősítéssel rendelkezik (TÜV Rheinland) bélyegző elhelyezkedése: egyszeres, befoglaló nincs többszörös bélyegzés a tanúsítvány kibocsátója: NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. által működtetett Kormányzati Hitelesítés Szolgáltató, d) A naplóállományok időbeli hitelességének és változatlanságának igazolására szintén a NISZ által kibocsátott minősített időbélyegzés kerül elhelyezésre a megőrzendő naplóállományokon. 43

44 Az aláírás érvényesítésével kapcsolatos jogi előírások A jogi szabályozás lényegesen kevesebbet foglalkozik az aláírások érvényesítésével, mint létrehozásával. Már az a tény is jól jelzi, hogy mennyivel kialakulatlanabb a terület, hogy az eidas rendelet a fokozott biztonságú aláírások érvényességével kapcsolatban csak az érvényesítés, mint fogalom szintjén tartalmaz rendelkezést. E meghatározás szerint érvényesítés : olyan folyamat, amelynek keretében ellenőrzik és igazolják, hogy az elektronikus aláírás vagy bélyegző érvényes. (ennek a feltételrendszerét azonban nem tisztázza). Ezzel együtt tárgyalja az érvényesítő adatot, amelyet az elektronikus aláírás vagy bélyegző érvényesítéséhez használt adatként jelöl meg. A nyilvános kulcsú infrastruktúra terminológiájában ez a nyilvános kulcsnak felel, meg szemben a magánkulccsal, amit a jogszabály aláírás, illetve bélyegző létrehozó adatként jelöl. Csak a minősített aláírások érvényesítésére határoz meg egy követelménysort. Az eidas rendelet 32. cikke szerint a minősített elektronikus aláírás érvényesítésére szolgáló eljárás megállapítja a minősített elektronikus aláírás érvényességét, amennyiben: a) az aláírást igazoló tanúsítvány az aláírás időpontjában elektronikus aláírás olyan minősített tanúsítványa volt, amely megfelel az I. mellékletnek; b) a minősített tanúsítványt minősített bizalmi szolgáltató bocsátotta ki, és az az aláírás időpontjában érvényes volt; c) az aláírás-érvényesítési adatok megfelelnek a szolgáltatást igénybe vevő fél számára megadott adatoknak; d) a szolgáltatást igénybe vevő fél pontosan megkapja a tanúsítványban az aláírót azonosító egyedi adatokat; e) amennyiben az aláírás időpontjában álnév használatára került sor, az álnév használatának tényét egyértelműen feltüntették a szolgáltatást igénybe vevő fél számára; f) az elektronikus aláírást minősített elektronikus aláírást létrehozó eszközzel állították elő; g) az aláírt adatok sértetlensége nem került veszélybe; h) az aláírás időpontjában teljesültek a fokozott biztonságú aláírásra megfogalmazott a rendelet 26. cikkében foglalt követelmények; A Bizottság ezen túlmenően kapott egy felhatalmazást végrehajtási jogi aktusban a minősített elektronikus aláírások érvényesítésére vonatkozó szabványok hivatkozási számai listáját kiadására, azt a felhatalmazás azonban még nem töltötte ki. A rendelkezés ugyanakkor hiányos abból a szempontból, hogy hogyan kell értelmezni az eidas rendelet előtt készült aláírások, illetve az átmeneti időszakban készült aláírások és bélyegzők helyzetét. Lehet ezekkel kapcsolatban is megállapításokat tenni a szöveg alapján, de itt hiányzik a teljes értékű jogi alap. Így például a korábban kibocsátott tanúsítványok és időbélyegek, illetve a korábban készült aláírások tekintetében a korábban elfogadott, azonban jelenleg már 44

45 kockázatosnak minősülő szerinti algoritmusokkal készült aláírásokat is el kell fogadni, nincs ugyanis olyan jogszabály, ami ezt kizárná. Ez a megközelítés komoly kockázatot hordoz és csak a megtámadhatóság lehetőségével együtt kezelhető. A fokozott biztonságú aláírások érvényesítésére vonatkozóan a fent leírtakból csak következtetések vonhatók le. Értelemszerűen a követelmények nem lehetnek szigorúbban a fent leírtaknál és az is egyértelmű, hogy a minősített aláírásokra vonatkozó speciális követelményeket (a, b, f) pontokat nem lehet érvényesíteni. A többi viszont értelmezhető egy fokozott biztonságú aláírás érvényesítése esetén is, és minden bizonnyal célszerű is a fennmaradó követelményeket figyelembe venni. Nincs azonban rá jogi kötelezettség, csak magára az érvényesítési folyamat megvalósítására. Itt is látszik, hogy önmagukban a szabványok vagy műszaki irányelvek, bár hatékonyan tudják segíteni egy műszaki tevékenység megvalósulását nem alkalmasak harmadik személyek felé kötelezettség rögzítésére külön megállapodás nélkül. Itt azonban ilyen nincs. Sem az e-ügyintézési törvény sem az e-aláírási rendelet nem tartalmaz az érvényesítésre vonatkozóan semmiféle előírást. Az e-ügyintézési Vhr. sem tartalmaz általános érvényű rendelkezést, az ellenőrzés céljára és a megvalósításával kapcsolatos követelményekre vonatkozóan, de több szolgáltatás vonatkozásában beszél az érvényesség vizsgálatának szükségességéről, sőt bizonyos követelményeket is megállapít. Ezek közül a legrészletesebb a kormányzati elektronikusaláírás-ellenőrzési szolgáltatás feladatainak meghatározása. Látni kell azonban, hogy a feladatmeghatározás kizárólag magát a szolgáltatást írja le, nem határozza meg általános érvénnyel, hogy hogyan kell az elektronikus aláírásokat érvényesíteni. A rendelet 81. szakasza alapján e szolgáltatás keretében a szolgáltató biztosítja az elektronikus dokumentumon elhelyezett elektronikus aláírás, elektronikus bélyegző érvényességének ellenőrzését az elektronikus dokumentum alapján, függetlenül attól, hogy az elektronikus aláírás, elektronikus bélyegző a dokumentumhoz kapcsolt, vagy külön adatszerkezetként kezelendő. Az ellenőrzés e szakasz előírása szerint három részből áll, a szolgáltató a) ellenőrzi az elektronikus aláírás, elektronikus bélyegző érvényességét, valamint b) a dokumentum ellenőrizhetősége esetén ellenőrzi a dokumentum sértetlenségét, c) az ellenőrzés eredményéről igazolást állít ki. A tanúsítvány érvényességének ellenőrzésére két módszert ad meg a rendelet: a) ha az rendelkezésre áll és ingyenes, azonnali tanúsítványállapot-igazoló szolgáltatással (OCSP), vagy b) ha az azonnali tanúsítványállapot-igazoló szolgáltatás nem érhető el, a visszavonási állapotinformációk (CRL)segítségével 45

46 Jól láthatóan ez a szabályozás sem tér ki a részletekre, széles teret hagy a különböző értelmezéseknek, nem tisztázza, mit milyen időpontra vonatkozóan kell vizsgálni, ami az adott esetben nem segíti a jogbiztonságot, széles teret hagy a bírói jogértelmezésnek. (természetesen az eidas rendeletben rögzítettek ettől függetlenül is érvényesek.) 7. ábra: A Kormányzati elektronikus aláírás ellenőrzési szolgáltatás folyamata a felhasználói kézikönyv verziója szerint 46

47 Az e-ügyintézési Vhr. a fenti szolgáltatáson kívül három szolgáltatásnál említi, mint a szolgáltatás feladatát az elektronikus aláírás érvényességének ellenőrzését (azonban sajnos minden tartalmi támasz nélkül): 117. (1) A központi érkeztetési ügynök KEÜSZ szolgáltatója biztosítja az elektronikus ügyintézést biztosító szerv által egyenként is igénybe vehető alábbi részszolgáltatásokat: f) elektronikus aláírással vagy bélyegzővel ellátott küldemény esetén az elektronikus aláírás vagy bélyegző érvényességének ellenőrzése, valamint jogszabály rendelkezése vagy a közfeladatot ellátó szervvel kötött megállapodás alapján a hosszú távú letagadhatatlansághoz szükséges kellékek biztosítása; 129. Az elektronikus dokumentumtárolási szolgáltatás KEÜSZ az elektronikus dokumentum tartós tárolásra történő átvételekor ellenőrzi az elektronikus dokumentum hitelesítésének érvényességét. Az elektronikus okirat kiadásakor a szolgáltató elektronikus bélyegzővel hitelesíti az elektronikus dokumentumot. Az így hitelesített elektronikus dokumentum változatlanságát - ha az elektronikus bélyegző ellenőrzésének eredményéből más nem következik - vélelmezni kell (1) A központi dokumentumhitelesítési ügynök KEÜSZ keretében a szolgáltató az ügyfél és az elektronikus ügyintézést biztosító szerv számára elérhetővé c) az igénybe vevő által megjelölt adaton vagy dokumentumon elhelyezett elektronikus aláírás vagy bélyegző érvényességének ellenőrzését, Ami viszont a hibrid szolgáltatás szempontjából közvetlen jelentőségű, és itt a jogszabály a több helytől eltérően de értelemszerűen csak erre a szolgáltatásra érvényesen rögzíti az ellenőrzés során megvizsgálandó tulajdonságokat 122. (1) Az elektronikus irat hiteles papíralapú irattá alakítását az elektronikus ügyintézést biztosító szerv, valamint a Kormány által kijelölt szervezet jelen alcím rendelkezései szerint végezheti. (5) A másolatkészítő a másolat elkészítését megelőzően köteles ellenőrizni azt, hogy az eredeti elektronikus irat az aláírás és a másolatkészítés időpontja között megváltozott-e, továbbá, hogy az aláírás időpontjában az azt hitelessé tevő tanúsítvány érvényes volt-e. A (2) bekezdés c) pontja szerinti adatok tartalmazzák a sértetlenség ellenőrzését igazoló, valamint a hitelesség ellenőrzését lehetővé tevő információkat. E rendelkezésnek megfelelően kell az elektronikus irat hiteles papíralapú irattá alakítása során eljárni, és ezeket az adatokat kell feltüntetni a záradékban. A jogszabály nem ad lehetőséget a másolatkészítés megtagadására ebben az esetben sem. A biztonság javára az ÁSZF alapján itt annyiban eltérünk, hogy amennyiben az ellenőrzés eredményeként az derül ki, hogy a dokumentum megsérült, vagy az aláírás vélelmezett időpontjában sem érvényes tanúsítvánnyal írták alá az elektronikus dokumentumot, akkor inkább visszautasítjuk a másolatkészítést és az 47

48 Igénybe vevőnek van lehetősége korrekcióra. A kézbesítési utasítás adattartalmát nem látszott indokoltnak további, igen ritkán előforduló kivételek kezelésével bonyolítani. A minősített tanúsítványok ellenőrzésére a fenti eset kivételével érvényes az eidas rendelet szabálya. A fokozott biztonságú tanúsítványok esetében azonban más esetekben a jogszabály a megvalósításra bízza az aláírás (bélyegző) érvényességének ellenőrzési módját. Természetesen indokolt figyelembe venni a vonatkozó szabványokat, műszaki előírásokat, de azok harmadik személyek és az adott esetben ilyen helyzetben vannak a különböző hibrid szolgáltatások címzettjei számára sem jogokat sem kötelezettségeket nem állapíthatnak meg Az aláírás érvényességével kapcsolatos vizsgálatok esetei a HKKR-ben Az aláírások, illetve bélyegzők ellenőrzését a rendszer szintén négy logikailag elkülönülő esetben végzi. A) Mivel a megvalósított biztonságos kézbesítési szolgáltatásban követelmény, hogy a címzett, annak meghatalmazottja vagy az arra megbízott helyettes átvevő azonosítottan aláírásával igazoltan vegye át beleértve az AVDH használatával történő dokumentumhitelesítést is a neki címzett küldeményt, az aláírt átvételi elismervényen szereplő aláírás ellenőrzése elengedhetetlen. Ebben az esetben egy PDF formátumú megszemélyesített átvételi elismervény dokumentum aláírása a feladat, amit értelemszerűen PAdES formátumú, legalább fokozott biztonságú aláírással vagy bélyegzővel kell megvalósítani, ennek érvényességét és az átvevő jogosultságát ellenőrzi a rendszer. Amennyiben az aláírás, illetve a bélyegző önmagáról azt állítja (QC statement szerepel az aláírásban) hogy minősített, akkor el kell végezni rajta az eidas rendelet 32. cikke szerinti teljes ellenőrzési folyamatot. Ugyanakkor ezekkel az aláírásokkal szemben csak akkor lehet érvényesíteni az az e-aláírási rendeletben rögzített követelményt, ha az átvevő elektronikus ügyintézési szolgáltató. Ebben az esetben az átvételre jogosító aláírás regisztrációja során kell ellenőrizni, hogy az aláírás tanúsítványa felülhitelesített-e a KGYHSZ által. Más Igénybe vevők esetében csak a 2015/1505 és 2015/1506 bizottsági végrehajtási határozatokban foglaltakat lehet megkövetelni, hiszen a gyakorlatban azt lehet ellenőrizni, hogy szerepel-e az aláírás, illetve bélyegző kibocsátó CA-ja a bizalmi listán, hiszen a címzettek jellemzően nem elektronikus ügyintézési szolgáltatók. Értelemszerűen vizsgálni kell azt is, hogy az aláírás időpontjában érvényes volt-e a tanúsítvány. Mivel az aláírandó dokumentumot a rendszer állította elő és az ellenőrzés az aláírás után ismét a rendszerben történik, csekély lehetőség van az aláírás időpontjának manipulálására. 48

49 Ha nem jogosulttól származik az aláírás, illetve nem regisztrálták előzetesen, akkor a rendszer csak kiküldi ismételten az értesítést a küldemény érkezéséről. Csak abban az esetben biztosít a rendszer hozzáférést az érkezett küldeményhez, ha érvényes és a követelményeknek megfelelő aláírással igazolták az átvételt. B) Az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ megvalósításában kulcsfontosságú a küldő fél az átalakítással kapcsolatos információinak pontossága. Az átalakítás végrehajtását megalapozó információt az úgynevezett kézbesítési utasítás hordozza, amelyet minden esetben legalább fokozott biztonságú, elektronikus ügyintézésre alkalmas, az e-aláírási rendelet követelményeinek megfelelő aláírással vagy bélyegzővel ellátva kell eljuttatni, a feldolgozó hibrid konverziós rendszerhez. Az e-aláírási rendelet követelménye miatt itt a bizalmi listával nem kell foglalkozni, de amennyiben az aláírás tartalmaz a minősítettséget jelző QC statement-et, akkor az ellenőrzést itt is az eidas rendelet alapján kell elvégezni. Értelemszerűen itt is ellenőrizni kell mind az aláírás meglétét, mind a megfelelő minőségét, mind az érvényességét. A kézbesítési utasítás beküldésénél nem követelmény az időbélyegzéssel való ellátás, hiszen itt az általános gyakorlat szerint a kézbesítési utasításon elhelyezett aláírás elkészültétől számított igen rövid idő alatt feldolgozásra kerül a kézbesítési utasítás. Így egyrészt csekély a valószínűsége az időközbeni visszavonásnak, másrészt az újabb visszavonási lista vagy akárcsak az OCSP ciklus késleltetésének bevárása a jogszabályi határidőn belül megvalósíthatatlanná tenné a másolatkészítési folyamatot. Itt tehát van bizonyos maradvány kockázat, de ennek valószínűsége nem nagyobb, mint az általános ügyintézői tévedésé, amit viszont a szolgáltató amúgy is kezel. A feladó a visszakapott feladási és gyártási igazolások nyomán amúgy is ellenőrizni köteles, hogy olyan küldeményt küldött ki, amilyet szándékozott, és végső esetben a postai kézbesítési folyamat során is van lehetőség a kiemelésre, bár ez igen komoly erőforrás-igényű, de nem példa nélküli. Ebben a folyamatban az aláírásra való jogosultság vizsgálata nem követelmény, mivel nem rögzített előzetesen, hogy kinek az aláírásával érkezhet a kézbesítési utasítás, csak a jogszabályi követelmények teljesülése, illetve a KGYHSZ általi felültanúsítás ellenőrizhető. Érvénytelen vagy hiányzó, illetve elektronikus ügyintézés biztosítására nem alkalmas aláírás, illetve bélyegző esetén maga a konverzió kerül visszautasításra. A megrendelőnek ismételten, már megfelelő aláírással ellátva kell elküldenie az átalakítandó dokumentumokat és a kézbesítési utasítást. A kézbesítési utasítás az aláírással együtt archiválásra kerül, azaz utóbb a feladóvevényen amúgy is elhelyezett időbélyegzéssel szükség esetén bizonyítható a keletkezés hozzávetőleges időpontja. 49

50 Mivel a kézbesítési utasítás maga egy XML állomány, ennek megfelelően a kézbesítési utasítást aláírásának formátuma XAdES kell legyen. A rendszer mind az embedded, mind az enveloped formátumú XML aláírásokat kezeli, alkalmas a MELASZ 2.0 formátumú aláírások (lásd {Sz35}) és az es3 formátumú dossziék (lásd {Sz34}) értelmezésére. Ugyanakkor a teljes rendszerben értelmezhetetlen a detached formátumú aláírás, hiszen az azt jelentené, hogy valahol külön kellene az aláírás és az aláírt dokumentum összekapcsolási információját a rendszerben kezelni. C) Amennyiben az Igénybe vevő az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ használatával kíván hiteles konverziót végrehajtani, és ennek megfelelően hiteles, azaz legalább fokozott biztonságú elektronikus aláírással vagy bélyegzővel ellátott elektronikus dokumentum hiteles papíralapú irattá alakítását igényli, akkor a Szolgáltató feladata a hitelesség szempontjából lényeges körülményeket rögzítő záradék előállítása. Ennek során a szolgáltatónak ez e-ügyintézési Vhr (5) bekezdésének megfelelően ellenőriznie kell a dokumentum változatlanságát, a tanúsítvány megfelelőségét és az aláírás időpontjára vonatkozó érvényességét, beleértve a teljes bizalmi láncot. (és csak ezt) Ebben az esetben számolni kell egyrészt különböző lehetséges formátumokkal, hiszen itt valamennyi másolatkészítésre egyébként befogadott aláírt dokumentumformátumot kezelni kell. Ennek megfelelően itt mind PAdES, mind XAdES formátumú aláírások ellenőrzése támogatott, és itt elvileg nem csak a hazai szolgáltatók által kiadott tanúsítványok támogatását kell biztosítani, a rendszer felkészült az EU bizalmi listán (lásd {J5, J6}) szereplő szolgáltatók tanúsítványainak kezelésére. Tekintve, hogy a bizalmi listák történeti adatokat is tartalmaznak, a már nem működő, illetve már nem felügyelt hitelesítés-szolgáltatók tanúsítványait szintén el kell fogadni, amennyiben egy aláírást olyan múltbeli időpontra nézve ellenőriz a Szolgáltató, amely időpontban a kérdéses szolgáltató még működött, illetve felügyelet alatt állt. A magyar közigazgatás gyakorlatával összhangban ugyanakkor a CAdES (EN ) aláírások kezelése itt sem követelmény, az ASiC (EN ) formátum támogatása pedig csak tervezett, mivel ahhoz külön feldolgozási folyamatot kell kialakítani. Amennyiben a kézbesítési utasítás a dokumentumot aláírtnak jelezte és az aláírás ellenőrzésnél az derül ki, hogy a dokumentum megváltozott az aláírás óta vagy a tanúsítvány az aláírás időpontjában érvénytelen volt, a folyamat megszakad és az Igénybe vevő az elutasítás okát jelző hibaüzenettel egy nemleges hibrid igazolást kap vissza. Mivel a jogszabályok (az eidas rendelet és az e-ügyintézési Vhr. egyaránt) eltérést nem engedően az aláírás időpontjában való vizsgálatot írnak elő, ugyanakkor egyik sem írja elő az időbélyegzés kötelező voltát, így, amennyiben nincs időbélyegzés, az aláírásban szereplő nem hiteles dátumot kell alapnak tekinteni. 50

51 Amennyiben az Igénybe vevő nem aláírtnak jelezte a küldeményt a kézbesítési utasításban, arról a fenti ellenőrzés nélkül is elkészülhet a hiteles másolat az iratérvényességi nyilvántartásba való elhelyezéssel, mivel az önmagában, az aláírás nélkül is igazolhatóvá teszi a hitelességet, a küldemény rendszeren belüli változatlanságát pedig a lenyomatok igazolják. Külön ellenőrzési elem, amennyiben a kézbesítési utasítás a dokumentumot kiadmányozottként jelöli, az aláírás (bélyegző) tanúsítványának lenyomatát is össze szükséges vetni az Igénybe vevő által előzetesen megadott kiadmányozásra jogosultak listájával. Ennek sikertelensége esetén azonban csak a záradék fog tartalmazni a kiadmányozásra való jogosultság hiányát jelző információt, hiszen ettől még a dokumentum hiteles, arról hiteles másolat készíthető (csak nem kiadmányozásra jogosulttól származik vagy a szervezet elmulasztotta bejelenteni) Szerencsére ezekben az esetekben az e-aláírási rendeletben szereplő, a kiadmányozásra jogosultakra vonatkozó publikációs követelmények utólag is bizonyíthatóvá teszik a kiadmányozási jogosultságot. D) A negyedik aláírás-ellenőrzési típus akkor fordul elő, ha az Igénybe vevő és a HKKR közötti kommunikáció a HKKR webautomata szolgáltatásával, webszervizek igénybe vételével történik. Ekkor ugyanis minden egyes, az igénybe vevőtől a rendszer felé küldött SOAP üzenetet alá kell írni. Ez az aláírás biztosítja egyrészt az üzenet sértetlenségét, másrészt magának a küldő rendszernek a nagy megbízhatóságú azonosítását. Ez a megoldás a WS- SecurityPolicy ( specifikáció egyik lehetséges megvalósítása. Ebben az esetben is elektronikus ügyintézésre alkalmas alapesetben értelemszerűen bélyegző előzetes regisztrálása a követelmény. Itt a sikertelen ellenőrzés magának a kommunikációnak a létrejöttét akadályozza meg. 1.3 Az aláírás használati rend elérhetősége A jelen aláírás használati rend elérhető a Magyar Posta Zrt. és az Elektronikus Ügyintézési Felügyelet honlapján elektronikus formában. 1.4 Az aláírás használati rend kibocsátója A jelen aláírás használati rend kibocsátója a Magyar Posta Zrt. Az aláírás használati rend jelen példányát ennek megfelelően a Magyar Posta Zrt. elektronikus bélyegzőjével hitelesítettük. 51

52 1.5 Az aláírás használati rend gondozása Az aláírás használati rendet gondozó szervezet Az aláírás használati rend rendszeres karbantartását, aktualizálását a Magyar Posta Közigazgatási Levelezési Központja (PKLK) biztosítja Kapcsolattartó Kapcsolattartó: PKLK központvezetője Jáki Tamás cím: pklk.support@posta.hu Telefonszám: Az aláírási rend frissítése Az aláírás használati rendben rögzített elvárások a hatályos jogszabályokra, az Általános Szolgáltatási feltételekben és az egyedi szerződésekben rögzített követelményekre, valamint a Magyar Posta Zrt. eljárásrendjét szabályozó dokumentumokra épülnek. Tekintettel arra, hogy a Szolgáltató más szereplőkkel folytatott elektronikus kommunikációját meghatározó jogszabályok, illetve a technológia folyamatos fejlődésével az elektronikus aláírási megoldásokat biztosító eljárások folyamatosan változhatnak, így a Szabályzat rendszeres felülvizsgálatát a kihirdetést követően évente, az egyéb jogszabályok által előírt felülvizsgálatokkal összhangban el kell végezni. Amennyiben a jogszabályi vagy technológiai változások indokolják, úgy a Szolgáltató a módosításokat haladéktalanul, de legkésőbb 30 napon belül átvezeti és az új (egységes szerkezetbe foglalt) verzió kihirdetésével a korábbi verzió automatikusan hatályát veszti. Az aláírás használati rend változása (fejlesztése) nem jelenti szükségszerűen a szerződés, illetve az Általános szerződési feltételek változását. Amennyiben azt teszi szükségessé, úgy a Szolgáltató az E-ügyintézési törvény 25. (10) bekezdésének és 28. -ának megfelelően jár el. 1.6 Fogalmak, rövidítések és hivatkozások A szövegben használt fogalmak értelmezése Aláírandó adat leképezése: (data to be signed representation) A megformázott aláírandó adat lenyomata, amelyet a digitális aláírás értékének kiszámításához használnak. Aláírás alkalmazási gyakorlat elemei: (signature application practice statement) Azon szabályok gyűjteménye, amelyek a digitális aláírások létrehozására, kiterjesztésére vagy érvényesítéséra szolgáló alkalmazások, illetve azok környezetének meghatározásakor alkalmazhatóak. 52

53 Aláírás ellenőrzés: (signature verification) Az aláírás kriptográfiai értékének vizsgálata az aláírás ellenőrzési adatok felhasználásával. Aláírás ellenőrzési adatok: (signature verification data) adatok, mint például kódsorozat, vagy nyilvános kriptográfiai kulcs, amelyet az aláírás ellenőrzéséhez használnak fel. Aláírás érvényesítése: (signature validation) Annak az ellenőrzési és igazolási folyamata, hogy egy aláírás érvényes. 8. ábra: Aláírás érvényesítés fogalmi összefüggései az ETSI TS alapján Aláírás kiterjesztése: (signature augmentation) Olyan információk beépítése egy digitális aláírásba, amelyek hosszabb időtávon is lehetővé teszik az érvényességének kezelését. Aláírás létrehozó adat: (signature creation data) Olyan egyedi adat, mint például kódsorozat vagy kriptográfiai magán kulcs, amelyet az aláíró a digitális aláírás értékének előállításához használ. Aláírás létrehozó alkalmazás: (signature creation application) Az aláírás létrehozó rendszeren belül az az alkalmazás, amely kiegészíti az aláírás létrehozó eszközt és előállítja az aláírandó adat objektumot. Aláírás létrehozó eszköz: (signature creation device) Megfelelően konfigurált hardver vagy szoftver eszköz, amelyet a az aláírás létrehozó adat implementálására és a digitális álírás értékének létrehozására használnak. Aláírás létrehozó rendszer: (signature creation system) A teljes rendszer, amely létrehozza a digitális aláírást és magában foglalja az aláírás létrehozó alkalmazást és az aláírás létrehozó eszközt. Aláíró: (signatory) elektronikus aláírást létrehozó természetes személy; 53

54 9. ábra: Aláírás készítés fogalmi összefüggései az ETSI TS alapján Aláírt adat objektum: (signed data object) Olyan adatszerkezet, amely tartalmazza az aláírás értékét, az aláírás attribútumait és egyéb információkat. Átvételi elismervény (Acceptance Receipt vagy Acceptance Certificate): A címzett által elektronikusan aláírt (bélyegzővel ellátott), a küldemény fogadását elismerő PDF formátumú dokumentum, melyet a biztonságos kézbesítési szolgáltató állít elő és a címzett rendelkezésére bocsát. A címzett az igazolást aláírva visszaküldi a szolgáltatónak, aki azt beépíti (beágyazza) csatolt állományként a szolgáltató minősített bélyegzőjével és időbélyegzővel hitelesített Letöltési igazolásba és a feladó rendelkezésére bocsátja. Az Átvételi elismervény aláírása a feltétele a tértivevényes (BKSZ) küldemény a címzett számára történő hozzáférhetővé tételének. Azonosításra Visszavezetett Dokumentumhitelesítés (AVDH): Olyan KEÜSZ, amelynek keretében a jogszabályban kijelölt központi szolgáltató az ügyfél által rendelkezésre bocsátott dokumentumot az általa igazolt személyhez rendeli, majd a személyhez rendelésről kiállított igazolást elektronikus dokumentumba vagy az elektronikus dokumentumhoz kapcsolt záradékba foglalja, és azt - a hitelesítendő nyilatkozattal együtt - minősített vagy minősített tanúsítványon alapuló fokozott biztonságú elektronikus bélyegzővel, valamint minősített időbélyegzővel hitelesíti. Bélyegző létrehozója: (creator of a seal) elektronikus bélyegzőt létrehozó jogi személy; Bizalmi szolgáltatás: (trust service) rendszerint díjazás ellenében nyújtott, az alábbiakból álló elektronikus szolgáltatások: a) elektronikus aláírások, elektronikus bélyegzők vagy elektronikus időbélyegzők, ajánlott elektronikus kézbesítési szolgáltatások, valamint az ilyen 54

55 szolgáltatásokhoz kapcsolódó tanúsítványok létrehozása, ellenőrzése és érvényesítése; vagy b) weboldal-hitelesítő tanúsítványok létrehozása, ellenőrzése és érvényesítése; vagy c) elektronikus aláírások, bélyegzők vagy az ilyen szolgáltatásokhoz kapcsolódó tanúsítványok megőrzése. Bizalmi szolgáltató: (trust service provider) Egy vagy több bizalmi szolgáltatást nyújtó természetes vagy jogi személy. A bizalmi szolgáltató lehet minősített vagy nem minősített bizalmi szolgáltató. Biztonságos Kézbesítési Szolgáltatás (BKSZ): A szolgáltatás a Hivatalos irat tértivevényes levél kézbesítésének megfelelő zártságú elektronikus kézbesítési szolgáltatás (a vonatkozó követelmények összefoglalása a bevezetésben). Ezen szolgáltatás során a Feladóvevény mellett a címzett értesítése és az átvétel elektronikus aláírással történő igazolása után a címzett számára letölthetővé teszi a küldött dokumentumot, és a feladó számára a címzett által aláírt átvételi igazolást biztosítja (Tértivevény). Az átvétel megtagadható, illetve az értesítéstől számított 5 munkanap elteltével újabb értesítés történik, amely után 5 munkanappal a hagyományos esettel azonos tartalmú ( címzett nem kereste ) igazolás kerül kiállításra. Digitális aláírás: (digital signature) Olyan hozzákapcsolt adat vagy egy adat-egység kriptográfiai transzformációja, mely biztosítja az adat-egység fogadója számára, hogy bizonyíthassa az adat-egység eredetét és integritását, és védi azt többek között a címzett általi a meghamisítás ellen. Az elektronikus aláírás egy lehetséges megvalósítási technikája, módja. Digitális aláírás értéke: (digital signature value) Egy adatösszesség (az aláírandó adatcsomag) kriptográfiai transzformációjának eredménye, amely lehetővé teszi az adatösszesség fogadója számára, hogy bizonyíthassa a kapott adatösszesség eredetét és integritását, és védi azt többek között a címzett általi a meghamisítás ellen. eidas rendelet: Az Európai Parlament és a Tanács 910/2014/EU rendelete (2014. július 23.) a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról, valamint az 1999/93/EK irányelv hatályon kívül helyezéséről. Elektronikus aláírás: (electronic signature) Olyan elektronikus adat, amelyet más elektronikus adatokhoz csatolnak, illetve logikailag hozzárendelnek, és amelyet az aláíró aláírásra használ. Elektronikus aláírás létrehozásához használt adat: (electronic signature creation data) Olyan egyedi adat, amelyet az aláíró elektronikus aláírás létrehozásához használ. 55

56 Elektronikus aláírás tanúsítványa: (certificate for electronic signature) Olyan elektronikus igazolás, amely az elektronikus aláírást érvényesítő adatokat egy természetes személyhez kapcsolja, és igazolja legalább az érintett személy nevét vagy álnevét. Elektronikus aláírás minősített tanúsítványa: (qualified certificate for electronic signature) Olyan, elektronikus aláírás céljára használt tanúsítvány, amelyet minősített bizalmi szolgáltató bocsát ki; és amely megfelel az eidas rendelet I. mellékletben megállapított követelményeknek. Elektronikus bélyegző: (electronic seal) olyan elektronikus adatok, amelyeket más elektronikus adatokhoz csatolnak, illetve logikailag hozzárendelnek, hogy biztosítsák a kapcsolt adatok eredetét és sértetlenségét. Elektronikus bélyegző tanúsítványa: (certificate for electronic seal) olyan elektronikus tanúsítvány, amely az elektronikus bélyegzőt érvényesítő adatokat egy jogi személyhez kapcsolja, és igazolja az érintett jogi személy nevét; Elektronikus időbélyegző: (electronic timestamp) olyan elektronikus adatok, amelyek más elektronikus adatokat egy adott időponthoz kötnek, amivel igazolják, hogy utóbbi adatok léteztek az adott időpontban; Elektronikus kézbesítési szolgáltatás: A kézbesítési és biztonságos kézbesítési szolgáltatás együttes megnevezéseként használt fogalom. Elektronikus ügyintézési törvény (E-ügyintézési tv.): Az elektronikus ügyintézés és bizalmi szolgáltatások általános szabályairól szóló évi CCXXII. törvény. Entitás: Elektronikus ügyintézést biztosító szervezet (E-ügyintézési tv pont) és a gazdálkodó szervezet (E-ügyintézési tv pont), mint logikai kategóriák együttes jelölése (minden olyan szervezeti forma együttese, amelyhez természetes személy képviselők kapcsolódnak). Amennyiben egy Szerződés (Contract) Entitáshoz kapcsolódik, akkor ennek a Szerződésnek a tranzakciói a Hatóságok és szervezetek kezelőfelületén érhetők el. Entitáshoz nem kötött Szerződésekhez a Magánszemélyek kezelőfelületén lehet hozzáférni. Értesítés (notification): A rendszer a feladó számára különböző figyelmeztetéseket küld az előzetesen beregisztrált címre, illetve a szolgáltatás külön megfizetése esetén SMS üzenetben is. A címzett szintén értesítés útján kap tájékoztatást arról, hogy számára a biztonságos kézbesítési szolgáltatás használatával átvehető elektronikus üzenet érkezett. Érvényesítés: (validation) olyan folyamat, amelynek keretében ellenőrzik és igazolják, hogy az elektronikus aláírás vagy bélyegző érvényes; Érvényesítési adatok: (validation data) elektronikus aláírás vagy elektronikus bélyegző érvényesítéséhez használt adatok; Érvényességi lánc: az elektronikus dokumentum vagy annak lenyomata és azon egymáshoz rendelhető információk (így különösen azon tanúsítványok, a 56

57 tanúsítványokkal kapcsolatos információk, az aláírás vagy bélyegző létrehozásához használt adatok, a tanúsítvány aktuális állapotára, visszavonására vonatkozó információk, valamint a tanúsítványt kibocsátó szolgáltató érvényességi adatára és annak visszavonására vonatkozó információk) sorozata, amelyek segítségével megállapítható, hogy az elektronikus dokumentumon elhelyezett fokozott biztonságú vagy minősített elektronikus aláírás, bélyegző vagy időbélyegző, az aláírás, bélyegző vagy időbélyegző elhelyezésének időpontjában érvényes volt-e. Feladási igazolás (Dispatch Receipt vagy Dispatch Certificate): A biztonságos kézbesítési szolgáltató által készített és elektronikusan aláírt (bélyegzővel ellátott), PDF formátumú, beágyazott XML állományt tartalmazó igazolás a feladó által küldött üzenet a szolgáltató általi átvételéről. Az igazolást a rendszer elektronikus üzenet formájában visszaküldi a feladónak. A feladás folyamat csak a feladási igazolás átvételével fejeződik be, addig a küldemény nem számít feladottnak. Fokozott biztonságú elektronikus aláírás: (advanced electronic signature) Olyan elektronikus aláírás, amely megfelel az eidas rendelet 26. cikkében meghatározott követelményeknek. A fokozott biztonságú elektronikus aláírásnak az alábbi követelményeknek kell megfelelnie: a) kizárólag az aláíróhoz köthető; b) alkalmas az aláíró azonosítására; c) olyan, elektronikus aláírás létrehozásához használt adatok felhasználásával hozzák létre, amelyeket az aláíró nagy megbízhatósággal kizárólag saját maga használhat; d) olyan módon kapcsolódik azokhoz az adatokhoz, amelyeket aláírtak vele, hogy az adatok minden későbbi változása nyomon követhető; Fokozott biztonságú elektronikus bélyegző: (advanced electronic seal) Olyan elektronikus bélyegző, amely megfelel az eidas rendelet 36. cikkében meghatározott, következő követelményeknek. a) kizárólag a bélyegző létrehozójához kötött; b) alkalmas a bélyegző létrehozójának azonosítására; c) olyan, elektronikus bélyegző létrehozásához használt adatok felhasználásával hozzák létre, amelyeket a bélyegző létrehozója nagy megbízhatósággal kizárólag saját maga elektronikus bélyegző létrehozására használhat; d) olyan módon kapcsolódik azokhoz az adatokhoz, amelyekre vonatkozik, hogy az adatok minden későbbi változása nyomon követhető; Hibrid igazolás: (Hybrid receipt, Hybrid certificate) Az átalakítási folyamat eredményét vagy eredménytelenségét tartalmazó igazolás, amely az átalakítás sikeres lezárultát, illetve a feldolgozás során feltárt esetleges hibákat, feldolgozási akadályokat jelzi, valamint az Igénybe vevőt segítő információt tartalmazhat. Az átvételi igazoláshoz hasonló szerkezetű és tartalmú, de a küldemény feladásánál használt adatokat is rögzítő, a Szolgáltató elektronikus bélyegzőjével és a független 57

58 minősített szolgáltató által kibocsátott időbélyeggel ellátott, szintén PDF formátumú, beágyazott XML formátumú információt tartalmazó elektronikus dokumentum. Hibrid küldemény: Olyan küldemény mely elektronikusan, biztonságos kézbesítési szolgáltatás vagy kézbesítési szolgáltatás igénybe vételével kerül feladásra, de hagyományos postai úton kerül kézbesítésre. Ennek lehetővé tétele érdekében a Magyar Posta, mint kijelölt KEÜSZ szolgáltató hiteles átalakítást végez, az elektronikus dokumentumot papíralapú dokumentummá alakítja át. Hitelesítés: (authentication) olyan elektronikus folyamat, amely lehetővé teszi a természetes vagy jogi személy elektronikus azonosításának vagy az elektronikus adatok eredetének és sértetlenségének az igazolását; Hitelesítési rend: olyan bizalmi szolgáltatási rend, amely bizalmi szolgáltatás keretében kibocsátott tanúsítványra vonatkozik; Igénybe vevő fél: (relying party) olyan természetes vagy jogi személy, aki vagy amely bizalmi szolgáltatást vesz igénybe; Időbélyegzés szolgáltató: (time-stamping authority) Olyan bizalmi szolgáltató, aki egy vagy több időbélyegző egységet felhasználva időbélyegeket bocsát ki. Kézbesítési igazolás (Delivery Receipt vagy Delivery Certificate): A kézbesítési szolgáltató által készített és elektronikusan aláírt (bélyegzővel ellátott), PDF formátumú, beágyazott XML állományt tartalmazó igazolás a feladó által küldött üzenet elhelyezéséről a címzett postafiókjába. Az igazolást a rendszer elektronikus üzenet formájában visszaküldi a feladónak. Kézbesítési Szolgáltatás (KSZ): A szolgáltatás a postai gyakorlat szerinti ajánlott (könyvelt) küldemények kézbesítésének megfelelő elektronikus szolgáltatás. Az igazolások a szolgáltató által a befogadásról (Feladóvevény feladási igazolás), illetve a címzett kézbesítési tárhelyére történő elhelyezéséről (Kézbesítési igazolás) készülnek. Központi Azonosítási Ügynök (KAÜ): Az E-ügyintézési tv. 38. (1) bekezdés j) pontjában központi biztosításra kijelöl szolgáltatás, mely keretében a szolgáltató az elektronikus ügyintézést biztosító szerv számára elérhetővé teszi a vele együttműködő azonosítási szolgáltatásokat, ideértve az azonosítási mód az azonosítandó személy általi megválasztásának lehetővé tételét, és az így kiválasztott azonosítási szolgáltatónál az azonosítás végrehajtását, illetve az információ közlését az azonosítást kérő szervvel. Központi Elektronikus Ügyintézési Szolgáltatások (KEÜSZ): Az E-ügyintézési tv. VII. fejezetében leírt szolgáltatások, melyeket az elektronikus ügyintézés hozzáférhetősége érdekében a kormány biztosít jogszabályban kijelölt szolgáltató útján. Küldemény: A KSZ és BKSZ alapvetően komplett dokumentumok hiteles továbbítását biztosító elsődlegesen gép-gép közötti szolgáltatás, ennek megfelelően csak speciális formában képes a csatolt dokumentumok mellett külön üzeneteket 58

59 vagy egyéb leíró adatokat továbbítani. A portálon ezek megnehezítenék a küldemények hitelességére vonatkozó bizonyítékok létrehozását és kezelését. Lenyomat: (hash) olyan meghatározott hosszúságú, az elektronikus dokumentumhoz rendelt bitsorozat, amelynek képzése során a használt eljárás (lenyomatképző eljárás) a képzés időpontjában elégséges biztonságot nyújt egy nem azonos dokumentumból előállítható azonos lenyomat képzésével szemben. Letöltési igazolás (Download Receipt vagy Download Certificate): A biztonságos kézbesítési szolgáltató által készített és elektronikusan aláírt (bélyegzővel ellátott), PDF formátumú, beágyazott XML állományt és sikeres kézbesítés esetén az aláírt átvételi elismervényt is beágyazva tartalmazó igazolás, mely tanúsítja, hogy a címzett aláírta az átvételi elismervényt és a küldemény a szolgáltató a címzett rendelkezésére bocsátotta. Megformázott aláírandó adat: (data to be signed formatted) Az aláírandó objektumok adataiból azok formázásával és megfelelő sorrendbe állításával létrehozott adat, melyet az aláírt adat leképezésének számításához használnak fel. Meghajtó alkalmazás: (driving application), Az az alkalmazás, amely az aláírás létrehozó alkalmazást digitális aláírás létrehozására, az aláírás érvényesítési alkalmazást a digitális aláírás érvényesítésére, illetve az aláírás kiterjesztési alkalmazást a digitális aláírás kiterjesztésére használja. Minősített bizalmi szolgáltatás: (qualified trust service) Olyan bizalmi szolgáltatás, amely megfelel az eidas rendeletben foglalt a minősített szolgáltatásokra alkalmazandó követelményeknek. Minősített elektronikus aláírás: Olyan, fokozott biztonságú elektronikus aláírás, amelyet minősített elektronikus aláírást létrehozó eszközzel állítottak elő, és amely elektronikus aláírás minősített tanúsítványán alapul; Minősített elektronikus aláírást létrehozó eszköz: (qualified electronic signature creation device) Olyan, elektronikus aláírást létrehozó eszköz, amely megfelel az eidas rendelet II. mellékletben megállapított követelményeknek; Minősített elektronikus időbélyegző: (qualified electronic time stamp) Olyan elektronikus időbélyegző, amely megfelel az eidas rendelet 42. cikkében megállapított alábbi követelményeknek: a) az adatokat oly módon kell a dátumhoz és az időponthoz kapcsolnia, hogy az ésszerű mértékben kizárja az adatok észrevétlen megváltoztatásának lehetőségét; b) az egyezményes koordinált világidőhöz kötött pontos időforráson kell alapulnia; és c) a minősített bizalmi szolgáltató fokozott biztonságú elektronikus aláírásával vagy fokozott biztonságú elektronikus bélyegzőjével, vagy más egyenértékű módszerrel kell ellenjegyezni. 59

60 SMTP: Elektronikus levelek továbbításának kommunikációs protokollja (az RFC 5321 írja le) Szabályozott elektronikus ügyintézési szolgáltatások (SZEÜSZ): Az E- ügyintézési törvény VI. fejezetében szereplő olyan szolgáltatások, amelyek felett az állam közvetlen felügyeletet gyakorol, és ezen keresztül felelősséget vállal az elektronikus ügyintézés biztonsága érdekében Személyes adat: (personal data) Egy azonosított vagy azonosítható természetes személlyel (az érintettel, adatalannyal) kapcsolatba hozható bármely információ. Szerződés (Contract): A hibrid kézbesítési és konverziós rendszerben létrehozott a termelés szervezését támogató egység, amely min. 4 számjegyű azonosítóval rendelkezik. Az azonos feltételek mellett biztosítandó szolgáltatásra vonatkozó megállapodást jelenti. A Contract tulajdonságai, beállítandó paraméterei a Szerződés Kezelés (Contract Management) felületen érhetők el. A Contract nem azonos a papír alapú szerződéssel, amely a szolgáltatás igénybevételének szerződéses feltételeit jogilag megalapozza. Egy természetes vagy jogi személynek több Contract-ja is lehet, és kivételesen az is előfordulhat, hogy egy Contract mögött több természetes vagy jogi személy áll. A Contract a Hibrid kézbesítési és konverziós rendszerben a szerződés dokumentumnak az üzenetek technikai kezelése szempontjából lényeges elemeit rögzíti, és a rendszer ezek figyelembe vételével és a szerződésazonosító használatával biztosítja a szolgáltatásokat. Szerződés aláírója: Ez a regisztrációs adat a rendszerben a küldemények átvételre használt aláírások, illetve bélyegzők lenyomatait hordozza. Azon felhasználók esetén szükséges kitölteni, akik olyan saját aláírással, illetve jogi személy nevében bélyegzővel rendelkeznek, amelyet a részükre továbbított BKSZ (tértivevényes) küldemények átvételi igazolására használnak. Ezt az aláírást a rendszer érvényesség szempontjából ellenőrzi. Szerződés címe: Egy szerződéshez egy vagy több cím rendelhető. Ezek a címek használhatók a biztonságos kézbesítési szolgáltatás során, az átvételre alapesetben jogosult címzett megjelölésére. Szerződés felhasználója: A szerződéshez korábban már a rendszerben regisztrált felhasználók kapcsolhatók. A web-szervizen keresztül megvalósított kapcsolatnál technikai felhasználóként a kapcsolat azonosítása szolgálja ezt a célt, a portálos hozzáférés esetén viszont több felhasználó is hozzárendelhető. Tanúsítvány: (certificate) Egy entitás nyilvános kulcsa néhány kiegészítő adattal együtt, melyet a kibocsátó hitelesítés-szolgáltató magánkulcsával írtak alá annak érdekében, hogy meghamisíthatatlan legyen. Tanúsítvány érvényesítése: (certificate validation) Annak az ellenőrzési és igazolási folyamata, hogy egy tanúsítvány érvényes. Tértivevény: Biztonságos kézbesítési szolgáltatás során a címzett csak akkor kaphatja meg a küldeményt, ha aláírta az átvételi elismervényt. Az átvételről (át nem 60

61 vételről) és annak körülményeiről a feladó letöltési igazolás formájában értesül A letöltési igazolás tölti be a tértivevény szerepét, és ez beágyazott dokumentumként tartalmazza magát az aláírt átvételi elismervényt. Ügyfél: az elektronikus ügyintézést biztosító szerv feladat- és hatáskörébe tartozó ügyben ügyfélként, félként vagy az eljárás alanyaként, az eljárás egyéb résztvevőjeként, a szolgáltatás igénybe vevőjeként vagy ezek képviselőjeként részt vevő olyan személy vagy egyéb jogalany, aki vagy amely elektronikus ügyintézést biztosító szervnek nem minősül és az ügyben eljáró elektronikus ügyintézést biztosító szervnek nem tagja vagy alkalmazottja. Ügyfélkapu (ÜK): A kormány által kötelezően biztosított elektronikus azonosítási szolgáltatás. (KEÜSZ) A szövegben használt rövidítések (angol-magyar) értelmezése Rövidítés Angol eredeti Magyar megfelelő AC Attribute Certificate Szereptanúsítvány ASiC Associated Signature Container Kapcsolódó aláírás-konténer AVDH 61 Azonosításra visszavezetett dokumentumhitelesítési szolgáltatás ÁSZF General Terms and Conditions Általános Szerződési Feltételek BKSZ Trusted Electronic Delivery Biztonságos kézbesítési szolgáltatás CA Certification Authority hitelesítő központ CAdES CMS Advanced Electronic Signatures CMS alapú fokozott biztonságú elektronikus aláírás CEF Connecting Europe Facility Európai Hálózatfinanszírozási Eszköz CEN European Committee for Standardization Európai Szabványosítási Bizottság CMS Cryptographic Message Syntax RFC 5652 Kriptográfiai üzenet szintaxis CRL Certificate Revocation List Tanúsítvány visszavonási lista DA Driving Application Meghajtó alkalmazás DN Distinguished Name Megkülönböztetett név DSI Digital Services Infrastructure Digitális szolgáltatási Infrastruktúra DSS Digital Signature Service Digitális aláírás szolgáltatás DTBS Data to be Signed Aláírandó adat DTBSR Data To Be Signed Representation Aláírandó adat leképezése EC European Commission Európai Bizottság eidas Electronic Identification and Authentication services EN European Norms, European Standards Európai szabvány Elektronikus azonosítási és hitelesítési szolgáltatások ERS Evidence Record Syntax Bizonyíték állomány szintaxisa (RFC 4998) ETSI European Telecommunications Standards Institute Európai Távközlési Szabványosító Intézet GDPR General Data Protection Regulation Általános adatvédelmi rendelet HKKR HMDACS Hybrid Mailing, Delivery and Conversion System Hibrid kézbesítési és konverziós rendszer HTML HyperText Markup Language Hiperszöveges jelölőnyelv HTTPS HyperText Transfer Protocol Secure Biztonságos hipertext átviteli protokoll ICS Implementation Conformance Statement Megvalósítás-megfelelőségi nyilatkozat

62 Rövidítés Angol eredeti Magyar megfelelő IETF Internet Engineering Task Force Internet vezető testületének mérnököket tömörítő szervezete ISMS ISO Controls (Information Security Management System) International Organization for Standardisation 62 Információ biztonság irányítási rendszer kontrollok Nemzetközi Szabványügyi Szervezet JCA Java Cryptography Architecture Java kriptográfiai architektúra JCE Java Cryptography Extension Java kriptográfia kiterjesztés (JRE 1.4 előtt) KEÜSZ KGYHSZ Központi elektronikus ügyintézési szolgáltatás Közigazgatási Gyökér-hitelesítésszolgáltató KSZ Delivery Service Kézbesítési szolgáltatás LTV Long Term Validation Hosszú távú érvényesítés MP NISZ Magyar Posta Zrt. Nemzeti Infokommunikációs Szolgáltató Zrt. OCSP Online Certificate Status Protocol Valós idejű tanúsítvány-állapot protokoll OID Object Identifier Objektumazonosító (egyezményes azonosító) OTP One Time Password Egyszer használatos jelszó PAdES PDF Advanced Electronic Signatures PDF alapú fokozott biztonságú elektronikus aláírás PDF Portable Document Format Átvihető dokumentum formátum (ISO szabvány) PIN Personal Identification Number Személyi azonosító szám PKC Public Key Certificate Nyilvános kulcsú tanúsítvány PKI Public Key Infrastructure Nyilvános kulcsú infrastruktúra PKIX Public Key Infrastructure X. 509 X.509 szabványon alapuló nyilvános kulcsú infrastruktúra PKLK Posta Közigazgatási Levelezési Központ POE Proof of existence Létezés bizonyítéka (bizonyíték) PUK Personal Unblocking Key Személyes feloldó kulcs PW Password Jelszó QCP Qualified Certificate Policy Minősített tanúsítási szabályzat QSCD Qualified electronic Signature/Seal Creation Device Minősített elektronikus aláírás/bélyegző készítő eszköz RFC Request for Comments IETF internet szabványok megnevezése SAA Signature Augmentation Application Aláírás kiterjesztési alkalmazás SAPS Signature Application Practice Statement Aláírás alkalmazási gyakorlat elemei SAV Signature acceptance validation Aláírás elfogadhatóságának érvényesítése SCA Signature Creation Application Aláírás készítő alkalmazás SCD Signature Creation Data Aláírás létrehozó adat SCDev Signature Creation Device Aláírás létrehozó eszköz SCE Signature Creation Environment Aláírási létrehozási környezet SCS Signature Creation System Aláírás készítő rendszer SD Signer's Document Aláírandó dokumentum SDO Signed Data Object Aláírt adat-objektum SDR Signer's Document Representation Az aláíró dokumentumának leképezése SMTP Simple Mail Transfer Protocol Egyszerű levél-továbbítási protokoll (RFC

63 Rövidítés Angol eredeti Magyar megfelelő szabvány) SSI SCDev/SCA interface Aláírás létrehozó eszköz v. aláírás létrehozó alkalmazás interfésze SVA Signature Validation Application Aláírás érvényesítő (ellenőrző) alkalmazás SZEÜSZ ToC Table of Content Tartalomjegyzék Szabályozott elektronikus ügyintézési szolgáltatás TSA Time-Stamping Authority Időbélyegzés szolgáltató TSL Trust-service Status List Bizalmi szolgáltatások állapot-listája TSP Trust Service Provider Bizalmi szolgáltató UTC Coordinated Universal Time Egyezményes koordinált világidő ÜK Ügyfélkapu URI Uniform Resource Identifier Egységes erőforrás-azonosító VCI Validation Context Initialization Érvényesítési környezet inicializálása W3C World Wide Web Consortium World Wide Web Konzorcium (világméretű web konzorcium) XAdES XML Advanced Electronic Signatures XML alapú fokozott biztonságú elektronikus aláírás XML extensible Markup Language Kiterjeszthető jelölő nyelv 3. táblázat: Rövidítések értelmezése Szabályozási dokumentumok Jogszabályi hivatkozások {J1} {J2} {J3} {J4} {J5} {J6} Az Európai Parlament és a Tanács (EU) 2016/679 rendelete a természetes személyeknek a személyes adatok kezelése tekintetében történő védelméről és az ilyen adatok szabad áramlásáról, valamint a 95/46/EK rendelet hatályon kívül helyezéséről (általános adatvédelmi rendelet, GDPR) 910/2014/EU Európai Parlament és a Tanács rendelete a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról, valamint az 1999/93/EK irányelv hatályon kívül helyezéséről (eidas rendelet) A Bizottság (EU) 2016/650 végrehajtási határozata a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló 910/2014/EU európai parlamenti és tanácsi rendelet 30. cikkének (3) bekezdése és 39. cikkének (2) bekezdése alapján a minősített aláírást és bélyegzőt létrehozó eszközök biztonsági értékelésére vonatkozó szabványok megállapításáról A Bizottság (EU) 2015/1506 végrehajtási határozata a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló 910/2014/EU európai parlamenti és tanácsi rendelet 27. cikkének (5) bekezdése és 37. cikkének (5) bekezdése szerint a közigazgatási szervek által elismert fokozott biztonságú elektronikus aláírások és fokozott biztonságú bélyegzők formátumaira vonatkozó specifikációk meghatározásáról A Bizottság (EU) 2015/1505 végrehajtási határozata a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló 910/2014/EU európai parlamenti és tanácsi rendelet 22. cikkének (5) bekezdése szerinti bizalmi listákhoz kapcsolódó technikai specifikációk és formátumok meghatározásáról A Bizottság (EU) október 16-i 2009/767/EK határozata az eljárásoknak a belső piaci szolgáltatásokról szóló 2006/123/EK európai parlamenti és tanácsi irányelv szerinti egyablakos ügyintézési pontokon keresztül elektronikus eszközökkel történő teljesítését lehetővé tevő rendelkezések meghatározásáról 63

64 {J7} {J8} {J9} {J10} {J11} {J12} {J13} {J14} {J15} {J16} {J17} {J18} {J19} {J20} {J21} évi CL. törvény az általános közigazgatási rendtartásról (Ákr.) évi CXXX. törvény a polgári perrendtartásról (Pp.) évi CCXXII. törvény az elektronikus ügyintézés és a bizalmi szolgáltatások általános szabályairól (E-ügyintézési tv.) évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról (Ibtv.) évi V. törvény a Polgári Törvénykönyvről (Ptk.) évi CLIX. törvény a postai szolgáltatásokról évi CXII. törvény az információs önrendelkezési jogról és az információszabadságról 466/2017. (XII. 28.) Korm. rendelet az elektronikus ügyintézéssel összefüggő adatok biztonságát szolgáló Kormányzati Adattrezorról 451/2016. (XII. 19.) Korm. rendelet az elektronikus ügyintézés részletszabályairól (eügyintézési Vhr.) 137/2016 (VI. 13.) Korm. rendelet az elektronikus ügyintézés céljára felhasználható elektronikus aláíráshoz és bélyegzőhöz kapcsolódó követelményekről (e-aláírási rendelet) 335/2012. (XII. 4.) Korm. rendelet a postai szolgáltatások nyújtásának és a hivatalos iratokkal kapcsolatos postai szolgáltatás részletes szabályairól, valamint a postai szolgáltatók általános szerződési feltételeiről és a postai szolgáltatásból kizárt vagy feltételesen szállítható küldeményekről 84/2012. (IV. 21.) Korm. rendelet egyes, az elektronikus ügyintézéshez kapcsolódó szervezetek kijelöléséről 335/2005. (XII. 29.) Korm. rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeiről 41/2015. (VII. 15.) BM rendelet az állami és önkormányzati szervek elektronikus információbiztonságáról szóló évi L. törvényben meghatározott technológiai biztonsági, valamint a biztonságos információs eszközökre, termékekre, továbbá a biztonsági osztályba és biztonsági szintbe sorolásra vonatkozó követelményekről Az Európai Parlament és a Tanács (EU) 2016/2102 irányelve a közszféra béli szervezetek honlapjainak és mobilalkalmazásainak akadálymentesítéséről Szabványok, műszaki előírások 4. táblázat: Fontosabb jogszabályok {Sz1} RFC 2616 Hypertext Transfer Protocol HTTP/1.1 {Sz2} RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) {Sz3} RFC 3647 Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework {Sz4} RFC 5280 Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile {Sz5} RFC 5816 ESSCertIDv2 Update for RFC 3161 {Sz6} RFC 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP {Sz7} ETSI TR Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures: overview {Sz8} ETSI TR Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures; Definitions and abbreviations {Sz9} ETSI TR Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for signature creation and validation {Sz10} ETSI TR Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for cryptographic suites {Sz11} ETSI TR Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for trust service providers supporting digital signatures 64

65 and related services {Sz12} ETSI TR Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for trust service status lists providers {Sz13} ETSI TS Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile {Sz14} ETSI TS Electronic Signatures and Infrastructures (ESI); PAdES Baseline Profile {Sz15} ETSI TS Policy and security requirements for applications for signature creation and signature validation {Sz16} ETSI TS Electronic Signatures and Infrastructures (ESI); Cryptographic Suites {Sz17} ETSI TS Electronic Signatures and Infrastructures (ESI); Trusted Lists {Sz18} EN Accessibility requirements suitable for public procurement of ICT products and services in Europe. {Sz19} EN Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures {Sz20} {Sz21} {Sz22} EN (all parts) EN (all parts) EN (all parts) Electronic Signatures and Infrastructures (ESI); XAdES digital Electronic Signatures and Infrastructures (ESI); PAdES digital signatures Electronic Signatures and Infrastructures (ESI); Certificate Profiles {Sz23} EN Time-Stamping protocol and time-stamp token profiles {Sz24} EN Protection Profiles for Signature Creation & Validation Applications. {Sz25} ITU-T X.509 Information technology Open Systems Interconnection The Directory: Public-key and attribute certificate framework {Sz26} ISO/IEC :2009 {Sz27} ISO :2005 {Sz28} ISO/IEC 26300: 2006 {Sz29} ISO/IEC (all parts):2015 {Sz30} ISO/IEC (all parts) {Sz31} ISO :2008 Information technology -- Security techniques -- Evaluation criteria for IT security Document management Electronic document file format for longterm preservation Part 1: Use of PDF 1.4 (PDF/A-1) Information technology -- Open Document Format for Office Applications (OpenDocument) v1.0 Information technology Open Document Format for Office Applications (OpenDocument) v1.2 Information technology -- Document description and processing languages -- Office Open XML File Formats Document management -- Portable document format -- Part 1: PDF 1.7 {Sz32} FIPS FIPS PUB (2001): Security Requirements for Cryptographic Modules {Sz33} {Sz34} {Sz35} W3C recommendation W3C recommendation e-akta specifikáció v1.5 Extensible Markup Language (XML) 1.0 (Fifth Edition) 26 November 2008 XML Signature Syntax and Processing Version April 2013 Az e-akta formátum specifikációja {Sz36} MELASZ 2.0 Egységes Melasz formátum elektronikus aláírásokra verzió: 2.0 Melasz Munkacsoport Megállapodás, MMM {Sz37} NMHH határozat EF/ /2011 számú határozat a felhasználható biztonságos kriptográfiai algoritmusokról, valamint a hozzájuk tartozó paraméterekről 2011 december táblázat: Hivatkozott szabványok, műszaki előírások 65

66 Szolgáltatói dokumentumok {D1} Hibrid kézbesítési és konverziós szolgáltatások Általános Szerződési Feltételei 2.0 {D2} Másolatkészítési rend Elektronikus irat hiteles papíralapú irattá alakítása központi 2.23 elektronikus ügyintézési szolgáltatáshoz {D3} Másolatkészítési rend Papíralapú irat átalakítása hiteles elektronikus irattá Központi 2.1 elektronikus ügyintézési szolgáltatás {D4} Általános Szerződési Feltételek a NISZ Zrt. kormányzati hitelesítés szolgáltatásaihoz 3.1 {D5} Adatkezelési tájékoztató kormányzati hitelesítés szolgáltatásokhoz 1.2 {D6} Bizalmi Szolgáltatási Szabályzat minősített elektronikus aláírás és elektronikus 1.2 bélyegzés célú tanúsítványokhoz (BSZ-MTT) {D7} Bizalmi Szolgáltatási Rend minősített elektronikus aláírás és elektronikus bélyegzés 1.2 célú tanúsítványokhoz (BR-MTT) {D8} Szolgáltatási szabályzat minősített elektronikus aláírással kapcsolatos 1.1 szolgáltatásokhoz (HSZSZ-M) {D9} Időbélyegzés Bizalmi Szolgáltatási Szabályzat (IBSZ) 1.2 {D10} Időbélyegzés Bizalmi Szolgáltatási Rend (IBR) 1.2 {D11} Iratérvényességi Nyilvántartás Szolgáltatás (IÉNY) Általános Szerződési Feltételek 1.00 {D12} Iratérvényességi Nyilvántartás Szolgáltatás (IÉNY) Szolgáltatás leíró lap 1.00 {D13} Iratérvényességi Nyilvántartás Szolgáltatás (IÉNY) Csatlakozási szabályzat 1.00 {D14} Teljeskörű Ügyfélazonosítási Szolgáltatások Általános Szerződési Feltételek Központi Azonosítási Ügynök (KAÜ) szolgáltatásra és Teljeskörű azonosítási szolgáltatásra (TASZ) {D15} Központi Azonosítási Ügynök (KAÜ) szolgáltatás leíró lap 5 {D16} Központi Azonosítási Ügynök csatlakozási kérdőív 2.1 {D17} Internetes Bankkártyás Fizetőfelület - Rendszerdokumentáció 5.x 6. táblázat: Az igénybe vett külső szolgáltatások leíró dokumentumai 66

67 2 Aláírás készítéssel, kiterjesztéssel és ellenőrzéssel kapcsolatos követelmények 2.1 Általános követelmények Az aláírás használati rend ezen fejezete a dokumentum céljával összhangban nem foglalkozik azon SZEÜSZ-ök, illetve KEÜSZ-ök funkcionális feladataival, követelményeivel, amelyek szükségessé teszik az elektronikus aláírások, illetve bélyegzők használatát. Kizárólag abból a szempontból vizsgálja ezeket, hogy mennyiben befolyásolják az elektronikus aláírások, bélyegzők kezelésével kapcsolatos követelményeket, tevékenységeket. A rendszer alapfunkcióival kapcsolatos követelmények érvényesítését a felhasználói leírásokban, illetve másolatkészítési rendekben lehet követni. Ebben a fejezetben kizárólagosan az elektronikus aláírások, bélyegzők kezelése szempontjából releváns tevékenységeket, szempontokat tárgyaljuk, különös figyelemmel az ETSI TS műszaki előírás A mellékletében rögzített szempontrendszerre, illetve az EN szabványban rögzített követelményekre Felhasználói interfész A megvalósított rendszerben nincsen általános célú aláíró vagy bélyegző elhelyezését szolgáló alkalmazás. Ahol aláírások még pontosabban kizárólag bélyegzők készítése történik a HKKR-ben (ennek ellenére a teljes fejezetben jellemzően az aláírás megnevezést használjuk a hatályos jogszabályokban is alkalmazott megoldással élve az egyszerűbb érthetőség érdekében a korábbi gyakorlat alapján), az minden esetben valamely technológiai folyamat kiszolgáló eleme, hitelességének biztosítására szolgál. Látni kell ugyanakkor azt is, hogy bizonyos összefüggésekben az aláírások és bélyegzők használati feltételrendszerében jelentős különbségek vannak, és ezeket az első sorban műszaki szempontú szabványosítás (ahol ezek a követelmények nem játszanak érdemi szerepet) nem veszi figyelembe. Ez a helyzet néhány helyen komoly értelmezési, alkalmazhatósági problémákhoz vezet. Az általános célú aláírás, illetve bélyegző alkalmazás hiánya ebben az esetben azt jelenti, hogy minden esetben előzetesen pontosan meghatározott folyamat eredményeként áll elő meghatározott szerkezettel az aláírandó, hitelesítendő adategyüttes. A folyamat a szerkezet és az aláírás körülményei szempontjából szigorúan determinisztikus, az alkalmazási esetek jelentős hányadában nem reális és nem indokolt a hagyományos aláírási folyamatban értelemszerűen szükséges ellenőrzési folyamatok alkalmazása. Nincs mit és mihez képest ellenőrizni, az ellenőrzés semmivel nem növeli az eljárás megbízhatóságát, hiszen a folyamatok eredménye csak a rendszer által bemutatottan áll rendelkezésre. A manuális ellenőrzési folyamatok nem eredményeznének biztonságnövekedést, hiszen a hitelesítendő adatok is logikailag zárt, determinisztikus technológiai 67

68 folyamatok eredményei. Ezekben az esetekben az ellenőrzés lehetőségének biztosítása kizárólag a kapacitást szűkítené. Természetesen van eszközrendszer maguknak a termelési (üzleti) folyamatok megfelelő ellenőrzésére, monitoringjára, de az ebben az értelemben független tevékenység az aláírások készítésétől. Csak eltérés esetén kapcsolódnak össze. Eltérés esetén nem elégséges csak az aláírási folyamatot megállítani, a teljes folyamat megállítása elengedhetetlen. A fentieknek megfelelően a különböző a küldemények továbbításával kapcsolatban igazolások előállítása, az iratérvényességi nyilvántartással való kapcsolat és a logok hiteles tárolása, illetve az aláírások érvényességének ellenőrzése teljesen automatizáltan történik, itt operátori közbeavatkozásra csak más, az aláírási folyamatok feletti irányítási szinten biztosít lehetőséget a rendszer. Egy olyan folyamat működik a teljes HKKR-ben a Szolgáltató oldalán, ahol supervisori döntésre van szükség az elektronikus bélyegző elhelyezéséhez. A döntés szabadságfoka ez esetben is annyi, hogy jóváhagyja vagy elutasítja a bélyegző elhelyezését az adott dokumentumon. Ez a papíralapú eredetiről hiteles elektronikus másolat készítés folyamata, az inverz hibrid szolgáltatás. Ez esetben is csak egy olyan tényező van, amit a jogszabályok alapján minden esetben manuálisan ellenőrizni szükséges az aláírás előtt. Az ellenőrzés tárgya ebben az esetben, hogy megfelelően képezte-e le az elkészült másolat (a metaadatokat is beleértve, ellenőrizve) a papíralapú eredetit. Ebben az esetben is a technológia által pontosan meghatározott szerkezetű, adattartalmú, aláírandó adategyüttes kerül az operátor előzetes munkájának eredményeként a supervisor elé döntésre. Az adategyüttes szerkezetén, összetételén neki sincs lehetősége módosítani, ha módosíthatna, azzal éppen a folyamat zártságát tenné kétségessé. Ha az ellenőrzés eredményeként amihez a másolatkészítő rendszer biztosítja az elektronikus példány megismerhetőségét, az eredeti papíralapú dokumentum pedig csak e folyamatlépés után kerül kötegelésre megállapítható, hogy a másolat elégséges pontossággal (nem indokolt a folyamat megismétlése) képezi le az eredetit, akkor az operátornak csak arra van lehetősége, hogy elindítsa a folyamatot hitelesítő Magyar Posta Zrt elektronikus bélyegzőjét elhelyező folyamatot. Ha az elektronikus leképezés bármilyen okból nem megfelelő, nem teljes, akkor a supervisor visszaküldi az adategyüttest az előző munkafázisba, ismételt feldolgozásra, javításra. Ha esetleg az derül ki ebben a fázisban aminek egyébként korábban ki kellett volna derülnie, hogy az eredeti egyáltalán alkalmatlan a hiteles másolatkészítésre, akkor a supervisor visszautasítja az aláírást és vele együtt a teljes másolatkészítést, és a visszautasításnak megfelelően kell kezelni az eredetit a továbbiakban. Tehát ebben a folyamatban sincsenek olyan eljárási kérdések, melyekben az supervisornak további ellenőrzést kellene végeznie a bélyegző elhelyezéséhez, nincs, amihez a felhasználói felületnek további támogatást kellene nyújtania. 68

69 Ugyanígy szigorúan előzetesen rögzített, hogy az elhelyezésre kerülő bélyegző a Magyar Posta Zrt. e célra készíttetett bélyegzője, nincs a supervisornak semmiféle döntési lehetősége. A rendszer üzemeltetőinek felelőssége, hogy azon az eljárási ponton az ide alkalmas bélyegző kerüljön alkalmazásra, a felelősségek ilyen szétválasztása fontos garancia az eljárás zártsága szempontjából. A hiteles másolat tartalmát létrehozó a folyamatok mind a rendszerben már korábban az adott folyamatlépés elégséges ellenőrzése mellett történtek és a folyamat elfogadható termelékenysége érdekében indokolatlan, és nem eredményez nagyobb megbízhatóságot, ha a supervisornak további kérdéseket kell vizsgálnia, értékelnie. Az Igénybe vevők oldalán több folyamatelem is van, ahol aláírási folyamat elengedhetetlen a sikeres megvalósításhoz, ezek azonban kívül esnek a HKKR által jelenleg megvalósított, támogatott folyamatsoron. Aláírás kell a biztonságos kézbesítési szolgáltatással érkező küldemények átvételéhez. Ez egyben korlátozza használható csatornák típusát, hiszen a NISZ által szolgáltatott BKSZ nem támogatja ezt a kommunikációs folyamatot, így a két szolgáltatás jelenleg nem tud BKSZ szolgáltatás érdekében kooperálni. Aláírásra van szükség a kézbesítési utasításokon a hibrid konverzió végrehajtásához, Az elektronikus eredetiről készülő hiteles papíralapú másolat esetén az eredeti hitelességéről elsődlegesen azokban az esetekben szoktunk beszélni, ha maga az elektronikus dokumentum legalább fokozott biztonságú elektronikus aláírással vagy bélyegzővel van ellátva, (a másolat azokban az esetekben is hiteles lehet, ha ez nem biztosított, de akkor az eredeti bizonyító ereje meghatározatlan). Ennek biztosítása értelemszerűen a küldő feladata Elektronikus aláírás hitelesít minden egyes SOAP üzenetet, amennyiben a HKKR szolgáltatásainak igénybe vétele webszerviz használatával történik. Az átvétel elismervények jogosult általi aláírásának ellenőrzéséhez a potenciális címzettnek (esetleges megbízottjának, helyettesének) előre regisztrálnia kell a használni kívánt aláírást. A gyakorlatban ez azt jelenti, hogy alá kell írnia vagy az egyszerűsített szerződést tartalmazó vagy egy az itt szükséges adatok kezelését lehetővé tevő elektronikus dokumentumot az átvételi elismervény aláírására felhasználni kívánt elektronikus aláírással vagy jogi személyek esetében bélyegzővel. A szolgáltató ebből a dokumentumból emeli ki és rögzíti a tanúsítvány SHA-1 lenyomatát. Így alapesetben a tanúsítvány lenyomatának rögzítése automatizáltan történik, nem kíván külön tevékenységet az Igénybe vevő részéről, mivel ez a szerződés távolról történő megkötéséhez amúgy is elengedhetetlen. Az űrlap aláírása ebben az esetben is a rendszeren kívül történik, a HKKR ehhez nem biztosít támogatást. Elvileg bármely PAdES formátumú aláírást létrehozni képes aláíró alkalmazás használata elfogadott, ha a létrehozott aláírás megfelel legalább az eidas rendeletben és a Bizottság (EU) 2015/1506 végrehajtási határozatában 69

70 rögzített követelményeknek. Erre például a KEÜSZ-ök között megvalósított KEAASZ is lehetőséget biztosít. (lásd 1. számú melléklet) A potenciális használók körének bővítése érdekében tervezett az AVDH KEÜSZ használatának lehetővé tétele, illetve közvetlenül a rendszerbe integrálása a saját aláírás kiváltására a szerződéskötéskor, illetve az átvételi elismervény aláírására, elsődlegesen magánszemély ügyfelek számára. Ez a változás azonban egyéb módosításokat is elkerülhetetlenné tesz, ezért a változtatás ütemezése még nem ismert. A kézbesítési utasítás XML adattartalmának összeállítása megfelelő háttér informatikai rendszert feltételez. A kézbesítési utasítások XML állományainak egyenkénti manuális létrehozása nem tekinthető gazdaságos megoldásnak. A HKKR portáljáról egyébként van lehetőség ennek összeállítására és elküldésére ekkor azonban éppen a használhatóság érdekében nem követelmény az aláírás. Az üzenet integritását ebben az esetben magának a tranzakciónak a kontrolljával biztosítja a rendszer. Ha viszont egy kapcsolódó rendszer a kézbesítési utasítás elkészítéséhez biztosítja a szükségszerűen mögöttes adatbázisra és kriptográfiai alapműveletekre épülő eljáráscsomagot, ahhoz már különösebb erőfeszítés nélkül kapcsolható aláíró alkalmazás is. A kézbesítési utasításhoz szükséges információk nyilvántartása és összerendezése minden esetben feltételezi a kapcsolatot valamely iratkezelő rendszerrel. Egy erre a célra alkalmazható nyílt forráskódú, beépíthető, az EU által támogatott alkalmazásra vonatkozóan a 3. sz. melléklet tartalmaz információt Általános biztonsági intézkedések Egy elektronikus közigazgatási rendszerrel, vagy annak egy alrendszerével, mint az elektronikus aláírást vagy bélyegzőt készítő, illetve hitelesítő alrendszerrel szembeni bizalom alapja egyértelműen az, ha az megfelelő gondossággal, szervezettséggel készült és ezt a fejlesztő megfelelően igazolni is tudja. Ennek megfelelően az eredeti közbeszerzési dokumentáció is részletes követelményrendszert határozott meg az alkalmazható fejlesztési módszertannal kapcsolatban és az ajánlat is részletesen kitért erre a témakörre. A HKKR fejlesztését a Selex ES Leonardo S.p.A végezte, és ők részletesen dokumentálták az alkalmazott fejlesztési módszertant a teljes fejlesztés dokumentációs módszertanával együtt. Az igen nagy terjedelmű, összetettségű rendszer így az általuk fejlesztett szoftverelemekkel együtt megfelelően dokumentáltnak tekinthető. A konfigurációmenedzsment szabályzatuk az IEE Std 828 szabvány 2005-ös verziójára épült. A rendszert túlnyomó részt Java nyelven írták és az egyes funkciókra széles körűen alkalmazott, nyílt forráskódú szoftvercsomagokat használtak el ennek a fejlesztési modellnek minden előnyével és hátrányával. A 70

71 szoftverfejlesztést értelemszerűen belső verziókövető rendszer felügyelete alatt végezték, a build-eket pedig a MAVEN támogatásával készítették. Az elkészült szoftver-verziók életciklusának felügyeletére pedig a Siemens által a nagyméretű projektek támogatására kialakított Polarion ALM szoftvert használták (nem kizárólag ehhez a projekthez), amely kiterjedt a teljes rendszer életciklusának menedzselésére a követelmények definiálási fázisától a tesztelés fázisáig. A szoftver alkalmas az ISO szabványnak megfelelő (az önvezető autókban használható) szoftverelemek fejlesztésének támogatására is. A szoftver biztosítja elvileg az összes szabványos fejlesztési és tesztelési módszertan támogatását. A követelményeket, hibákat, változtatási igényeket, tesztkapcsolatokat és a projekt pillanatnyi állapotát is a Polarion-ban dokumentálták. A szoftver szigorúan megkövetelte a módszeres fejlesztést és dokumentálását. Ezen az úton a nagy terjedelmű projekt egységes menedzsmentje biztosítható volt. E támogatás ellenére a fejlesztési ciklus lényegesen elhúzódott a szerződötthöz képest, és még ma sem mondhatjuk, hogy a rendszer minden elemében képes biztosítani azt az összetett funkcionalitást, amit az eredeti ajánlattételi felhívás megfogalmazott. Az alapvető funkciókat viszont már megbízhatóan szolgálja ki. Ezt a tényt több száz dokumentált teszteset is bizonyítja Az elektronikus bélyegzők bizalmi szintje A rendszer szolgáltatásai igénybe vevőinek biztonsága érdekében elektronikus ügyintézésre alkalmas, eidas rendelet szerinti minősített tanúsítványon alapuló fokozott biztonságú aláírás követelményeinek megfelelő elektronikus bélyegzőket használ a rendszer, amelyek ennek megfelelően minden esetben megfelelnek a jogszabályi előírásban rögzített fokozott biztonságú aláírásokra, illetve bélyegzőkre meghatározott eidas rendeleti követelményeknek. Az eidas rendelet 36. cikke szerint a fokozott biztonságú elektronikus bélyegzőnek az alábbi követelményeknek kell megfelelnie: a) kizárólag a bélyegző létrehozójához kötött; b) alkalmas a bélyegző létrehozójának azonosítására; c) olyan, elektronikus bélyegző létrehozásához használt adatok felhasználásával hozzák létre, amelyeket a bélyegző létrehozója nagy megbízhatósággal kizárólag saját maga elektronikus bélyegző létrehozására használhat; d) olyan módon kapcsolódik azokhoz az adatokhoz, amelyekre vonatkozik, hogy az adatok minden későbbi változása nyomon követhető; Az eidas rendelet 3. cikk 27. pontja szerint a minősített elektronikus bélyegző olyan, fokozott biztonságú elektronikus bélyegző, amelyet minősített elektronikus bélyegzőt létrehozó eszközzel állítottak elő, és amely elektronikus bélyegző minősített tanúsítványán alapul. Esetünkben ezek a feltételek is teljesülnek, mivel a HKKR az általa generált bélyegzők készítésére kizárólag a NISZ Zrt. által elektronikus ügyintézési felhasználásra kibocsátott minősített tanúsítványokat használja, tehát a minősített tanúsítvány követelménye definíciószerűen teljesül. 71

72 A bélyegzőt létrehozó eszköz pedig a nagy megbízhatóság érdekében párba kapcsolt két a Safenet által gyártott LUNA SA 1700 hálózati hardveres biztonsági eszköz, amely CC szerinti EAL 4+ minősítéssel rendelkezik, amelyet a TÜV adott ki legutóbb június 30-án, de rendelkezik más minősítők tanúsítványaival is. Mivel az aláírás jelenleg nem tartalmazza az aláírás minősített voltát jelző QC statement-et, így jelenleg az aláírás nem minősül minősítettnek. Az ennek eléréséhez szükséges lépések tervezettek, de pontos időpontjuk még nem ismert Az aláíró, aláírás ellenőrző alkalmazások A rendelet követelményeivel összhangban a Magyar Posta célja, hogy a lehető legteljesebb biztonságot szolgáltassa az ügyfelei számára. Annak érdekében, hogy a biztonság azonos legyen a teljes rendszerben, az aláírások (bélyegzők) generálása minden esetben a teljes rendszerben egységes alkalmazáscsomagok használatával történik az aláírás típusától függően. Így két megbízható, széles körben alkalmazott, megfelelő referenciákkal rendelkező szoftver végzi jelenleg a bélyegzők készítését. A bizonyítékokat előállító modulban, ahol a PDF formátumú igazolások előállításra kerülnek, az itext PDF állománykezelő alkalmazást építették be és ennek az aláíró alkalmazását használják. Az itext egy Java könyvtár, amely kettős licencelésű. A nyílt forráskódú változatát GNU AGPL licenc alatt lehet használni. Maga a teljes bizonyíték-generátor alkalmazás, mint szoftver-egység, web-szerviz hívásokkal kommunikál a szoftver többi részével, külső interfésze egyáltalán nincs kivéve az igénybe vett időbélyeg szolgáltatást, amely azonban egy szigorúan meghatározott tartalmú szabványos protokollal kommunikál kizárólag a NISZ Zrt számára azonosító tanúsítvánnyal azonosított csatornáján, tehát nem jelenthet biztonsági kockázatot. Ugyanezt az aláírás készítő rutint használja a papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ is a hiteles másolatok előállításához. A használt aláíró alkalmazás azért lehet közös, mert az aláírandó dokumentum formátuma és szerkezete megegyezik a bizonyítékokéval. Ugyanúgy PDF formátumú az alapdokumentum, amelybe egy vagy több XML formátumú állomány kerül beágyazásra az aláírás előtt. Ezek megfelelőségéről tud meggyőződni a supervisor, és ha ez az ellenőrzés sikeres volt, már nincs olyan tényező, amely befolyásolhatná az egységes formátumú és tartalmú a PAdES specifikációnak megfelelő bélyegző elkészítését. Az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ megvalósítása során az elektronikus eredeti változatlanságának ellenőrzésére és az összevethetőség biztosítására az esetek túlnyomó többségében az iratérvényességi nyilvántartás KEÜSZ kerül alkalmazásra. Annak érdekében, hogy a nyilvántartásnak átadott információk hitelessége utólag is igazolható legyen az átadott információcsomagon is elektronikus bélyegző és időbélyegzés kerül elhelyezésre, és a HKKR naplózó rendszere is eltárolja ezeket az üzeneteket. Itt, mivel az adatcsomag egy XML 72

73 állomány, az alkalmazott formátum XAdES. Ennek az aláírásnak a generálásához az Európai Parlament és a Tanács 1316/2013/EU (2013. december 11.) rendeletével létrehozott Európai Hálózatfinanszírozási Eszköz finanszírozásával az elektronikus aláírások elterjedésének támogatására fejlesztett és a tagállamoknak széleskörű felhasználásra ajánlott nyílt forráskódú LGPL 2.1 licencelésű DSS (Digital Signature Services) alkalmazás XAdES aláíró modulját használja a rendszer az ott megvalósított időbélyegzéssel és bizalmi lista kezeléssel együtt. (részletesebb leírása a 3. sz. mellékletben) Mivel ez a szoftvercsomag szándéka szerint átfogóan képes kezelni valamennyi, az eidas szabályozásban szereplő elektronikus aláírást, és az Európai Unió támogatását bírja, a tervek szerint a szolgáltatások továbbfejlesztése során a biztonság és a kezelés egységességének növelése érdekében tervezett az áttérés ennek egységes alkalmazására valamennyi aláírásnál és aláírás-ellenőrzésnél. A munkamegosztás jelenleg az aláírások ellenőrzése, érvényesítése esetében is azonos, ennek megfelelően itt azt külön nem részletezzük. Aláírás kiterjesztést a rendszer folyamatként nem alkalmaz A rendszer egészének külső védelme A rendszer egésze minden oldalról tűzfalakkal védett hálózati szegmensben helyezkedik el, és valamennyi beérkező üzenetcsomag vírus- és más káros kódokkal szembeni ellenőrzésére a Symantec folyamatosan frissített Symantec Protection Engine 7.5 verzióját használja. Az igénybe vett külső rendszerekkel VPN-es vagy TLS alapú kommunikációval érintkezik, ennek megfelelően nincs olyan szolgáltatás, illetve felület, ahol nem azonosított igénybe vevővel kerülne kapcsolatba. A szállító a szoftver általános leírásában rögzített nyilatkozata (HMDACS DESIGN SPECIFICATION_EN_2.0.pdf 6.2 fejezet Code signing) szerint valamennyi kódot aláírva szállította. A Magyar Posta Zrt. ehhez külön a NISZ Zrt. által kibocsátott kód aláíró tanúsítványt is biztosított. 73

74 10. ábra: A rendszer logikai szerkezete egy webautomatán beérkező küldemény adatfolyamával Papíralapú eredetiről hiteles elektronikus másolat készítése KEÜSZ bélyegzőinek védelme Mivel az inverz hibrid (papíralapú eredetiről hiteles elektronikus másolat készítése KEÜSZ) szolgáltatás során a bélyegzési folyamatot felügyelő supervisornak az előzetes bejelentkezésből származó a rendszer által egyébként is kezelt azonosítójától eltekintve kizárólag a jóváhagyását kell megadnia a bélyegző elhelyezéséhez, ezért az aláírási folyamatra az információ integritásának és bizalmasságának védelme közvetlenül nem alkalmazható. A tanúsítványban szereplő adatokat a hardveres biztonsági modul (HSM) védi. A rendszer, a benne létrejött a másolatra vonatkozó információk védelméhez zártsága, és a bélyegzők készítésére szolgáló részének az internettől való leválasztottsága révén elégséges védelmet biztosít, és ezzel lehetővé teszi az biztonságos aláírás-kezelést. A rendszer a szigorúan védett fizikai környezete igen kockázatossá (illetve a jogtalan használatot jól bizonyíthatóvá) teszi a nem jogosult általi másolatkészítést, így ebből a szempontból a rendszer zártsága megfelelően biztosított. E szolgáltatás esetén, annak jellegéből következően a nyilvános használat nem értelmezhető, a másolatkészítés csak a szigorúan védett környezetben valósítható meg, tehát erre vonatkozó további informatikai jellegű biztonsági intézkedések nem indokoltak. 74

75 Elektronikus eredetiről hiteles papíralapú másolatkészítés KEÜSZ bélyegzőinek védelme Ugyanezen környezeti feltételek biztosítottak a hibrid (elektronikus eredetiről hiteles papíralapú másolatkészítés KEÜSZ) szolgáltatás folyamatai során azzal az eltéréssel, hogy itt a minőségbiztosítás is teljesen automatizált. Emberi beavatkozásra az egyedi dokumentumok tartalmának ismerete nélkül, kizárólag a termelés szervezése, optimalizálása érdekében kerül sor. Ez a tény egyben az operátori minőségellenőrzés objektív korlátját is jelenti, hiszen az elektronikus eredeti ismerete nélkül kizárólag a nyomat alapján van lehetőség minőségellenőrzésre, az operátorok az elektronikus eredetiket nem ismerik meg a rendszerben. (Az alkalmazott ellenőrzési technológiai megoldás ugyanakkor az elektronikus eredeti megjelenített képe és a nyomtatott példány közötti azonosságot beleértve a nyomat minőségét ellenőrzi.) Ez a megoldás egyik oldalról biztosítja a lehetséges maximális bizalmasságot, ugyanakkor értelemszerűen korlátozza a kontroll lehetőségét is. Amennyiben az ügyfél arra igényt tart, két szinten is van lehetőség mintavételes ellenőrzésre. Első lépcsőként megvalósítható, hogy egyes, egyébként a rendszer által sikeresen legyártottnak minősített példányokat kiemeljenek a gyártási folyamatból, és azokat felbontva győződjenek meg a nyomat minőségéről. Ebben az esetben még az elektronikus eredeti megismerésére nem kerül sor. Utána ezeket jegyzőkönyvezetten megsemmisítik és újra gyártják. Ha azonban ennél is alaposabb ellenőrzést tart valamiért a megrendelő szükségesnek, akkor a hiteles másolatokon elhelyezett záradékban szereplő információk alapján van lehetőség az elektronikus eredetivel való egybevetésre is, feltételezve, hogy a megrendelő előzetesen az általa kiadott GUID használatával az elektronikus eredeti elérhetőségét az e-ügyintézési Vhr. 98. (1) bekezdése szerint biztosítja. Ekkor lehetőség van az elektronikus eredetivel történő összehasonlításra is. Ha azonban a küldő fél nem adja meg előzetesen a GUID-ot, illetve a gyártás periódusában még nem teszi elérhetővé az elektronikus eredetit, akkor ez a lehetőség elesik. Ekkor csak arra nyílik lehetőség, hogy ellenőrzés céljából egyes példányok visszairányításra kerüljenek a feladóhoz. Tudni kell azonban, hogy ezek az intézkedések jelentős erőforrás igényűek és ennek megfelelő költségűek, így alkalmazásukat alapos megfontolás kell megelőzze. A szolgáltató egyébként a gyártás ellenőrzésére és fejlesztésére rendszeresen futtat teszteket saját maga által előállított mintákkal, tesztállományokkal, és ellenőrzi az előállatott tesztpéldányok teljességét, megfelelő minőségét az előzőekben leírt elsődlegesen elvi minőségellenőrzési lehetőségektől függetlenül is. Mivel a folyamatok determinisztikusak, ez általános esetben elégséges biztonságot nyújt. Az hibrid gyártási igazolásokon elhelyezett elektronikus bélyegzők és a rajtuk elhelyezkedő időbélyegek elkészítés utáni ellenőrzése az előzőekben már leírt okokból elsődlegesen a gyártó saját tesztjei által biztosított. Egyébként a folyamat 75

76 determinisztikus, magában az aláírási folyamatban csak olyan hiba következhet be, amely magának a bizonyítéknak a létrejöttét is meghiúsítja. A nem megfelelő tartalmú vagy értelmezhetőségű esetleges hibaüzenetekkel szemben a védelmet nem az aláírási folyamat biztosítja, azzal a nem kellően informatív hibaüzenetek számának csökkentését nem lehet megvalósítani Biztonságos kézbesítési szolgáltatási, illetve kézbesítési szolgáltatás SZEÜSZ bélyegzőinek védelme A biztonságos kézbesítési szolgáltatás során elektronikus bélyegző használatára két folyamatelemben kerül sor A biztonságos kézbesítési folyamat során a Szolgáltató által kiállított igazolások készítése teljes automatizáltságú folyamat, a korábban már leírt bizonyítékgenerátor alkalmazás (webszerviz) használatával. A folyamat determinisztikus, jellegére vonatkozó megállapítás itt is érvényes. A másik elektronikus aláírást igénylő folyamat a rendszer által készített (jelenleg alá is írt) átvételi elismervények előállítását és eljuttatását követően az átvételi elismervény aláírása. Ennek megvalósítása azonban a rendszer keretein kívül, a rendszer által nem ellenőrzötten történik. Az átvételi elismervények aláírása a címzett által birtokolt aláíró eszközzel történik, ennek az elégséges biztonságáról az ő feladata gondoskodni. A rendszer ebben az esetben a visszaküldést követően az aláírás érvényességét ellenőrzi, illetve ellenőrzi, hogy a korábban bejelentett átvételre jogosultak egyikének aláírásával vagy bélyegzőjével történt-e az aláírás. Itt az esetleges téves értékelés kockázata csekély, a dokumentum mindenképpen megfelelően azonosított személy, illetve szervezet számára kerül kiszolgáltatásra, mivel hozzáférési jogosultság az aláírástól, bélyegzőtől függetlenül is ellenőrzött. Csak a feladó és címzett számára egyaránt rendelkezésre bocsátott, az aláírt átvételi elismervényt tartalmazó letöltési bizonyíték minősége körül keletkezhet a legrosszabb esetben vita, az ilyen vita azonban abszolút módon amúgy sem kiküszöbölhető. Tervezett az Azonosításra visszavezetett dokumentumhitelesítés KEÜSZ közvetlen beépítése a rendszerbe annak érdekében, hogy az ügyfeleknek ne is kelljen saját elektronikus aláírással rendelkezni a szolgáltatáscsomag használatához, és ne kelljen az átvételi elismervényt a rendszeren kívül aláírni. Ez azonban több ponton is szükségessé teszi a rendszer átalakítását, ezért megvalósítása csak hosszabb távon valósítható meg. Kézbesítési szolgáltatás esetében a második folyamatelem nem szerepel, ott kizárólag a Szolgáltató által kiadott igazolások bélyegzése és időbélyeggel történő ellátása történik, a már jelzett biztonsági feltételrendszerben. 76

77 2.1.3 A rendszer teljessége A rendszer egésze azzal az igénnyel került megvalósításra, hogy a folyamat minden lehetséges módon biztosítsa a nyújtott szolgáltatások zártságát, a bizalmasság, sértetlenség és magas rendelkezésre állás megvalósítását. A tervezés során a biztonsági és hitelességi megfontolások képezték az elsődleges prioritást. A másolatkészítésben részt vevő operátorok és supervisorok előzetes felkészítésük során részletes tájékoztatást kapnak egyrészt a teljes másolatkészítési munkafolyamatról, és ennek részeként az elektronikus bélyegzők készítéséről, az azzal járó felelősségről, a másolatkészítési folyamatban, illetve az elkészült dokumentumokban kezelt személyes adataikról és a másolatkészítő helyiség speciális biztonsági felügyeleti rendjéről. Ezen ismeretek birtokában végzik folyamatosan munkájukat, és tudják, hogy indokolt esetben bármely munkaműveletük visszaellenőrizhető. A fizikai és szervezési környezet biztonsága eredményesen egészíti ki az elektronikus eszközrendszer által amúgy is elért biztonságot. 2.2 A jogi követelmények kielégítését szolgáló eljárási szabályok A rendszer kialakítása során adatvédelmi és adatbiztonsági szakértők bevonásával a Magyar Posta kiemelt figyelmet fordított a rendszer jogi megfelelőségére. Ez igaz mind az elektronikus ügyintézés szempontjainak való megfelelés, mind az adatvédelmi, adattakarékossági követelmények teljesítése szempontjából. A tervezési folyamatról egyértelműen állítható, hogy az adatvédelmi szempontoknak alárendelve történt Személyes adatok feldolgozása A személyes adatok védelmének általános eljárási, garanciális kérdéseit az Általános szerződési feltételek 9. fejezete tárgyalja részletesen. Általánosságban szükséges jelezni, hogy a rendszerben, a küldemények tartalmából következően, nagy mennyiségű személyes adat és ezen belül különleges személyes adat is kezelésre kerül, és az ezzel kapcsolatos adatvédelmi tervezés, a feladat ellátásához szükséges személyes adatok mennyiségének minimalizálása nem csekély kihívást jelentett, de ebben a fejezetben csak kifejezetten az aláírásra vonatkozó szempontokat tárgyaljuk. Mivel a Magyar Posta az általa készített dokumentumokban kizárólag elektronikus bélyegzőt használ, ezek adattartalmával kapcsolatban személyes adatkezelési kérdés nem merülhet fel, hiszen itt a tanúsítvány maga nem tartalmaz személyes adatokat. A bélyegzőt megrendelő személy adataival kizárólag bélyegző tanúsítványát kibocsátó és hitelesítő NISZ CA rendelkezik. A beérkezett akár továbbítani, akár átalakítani kívánt dokumentumokban szereplő elektronikus aláírásokban rögzített személyes adatok a feldolgozás folyamatából 77

78 következően az operátorok számára nem válnak ismertté. Magukat az elektronikus dokumentumokat mindkét irányú konverzió esetében a konverziós folyamat sikeres lezárását követően haladéktalanul megsemmisíti a rendszer, és így a véletlen adatszivárgás lehetősége erősen korlátozott. A feladott, illetve átvett küldemények tárhelye az Igénybe vevők (feladók, illetve címzettek és mindkét oldal megbízottai, képviselői) kizárólagos felügyelete alatt áll, a szolgáltató ezen tárhelyek esetében csak a rendelkezésre állásért vállal felelősséget. Az elektronikus aláírással ellátott, hiteles másolat készítésre megküldött elektronikus dokumentumok aláírásainak ellenőrzése is teljesen zárt rendszerben történik, az aláíró személyét az operátorok normál, gépesített feldolgozás esetén nem ismerhetik meg. Ahogy az a jogi környezet ismertetésénél ( és fejezetek) részletesen bemutatásra került, ennek az ellenőrzésnek az eredménye az esetek túlnyomó többségében csak információ, hiszen az egyéb feltételek fennállása esetén az elkészült másolat teljes mértékben hiteles lehet, azt bíróságnak is el kell fogadnia. Csak abban az esetben vezet az automatizált ellenőrzés a másolatkészítés visszautasításához, ha az derül ki, hogy a dokumentum nem azonos (bármilyen okból) azzal, mint ami alapján az aláírás készítésekor elvégezték az aláírás részét képező kriptográfiai műveletsort, illetve az aláíró tanúsítvány az aláírás készítésének időpontjában nem volt érvényes. Amennyiben akár egy feldolgozási egység kis mérete (darabszáma), akár az esetleges gyártási hibák kezelése miatt a papír alapú hiteles másolatok nyomtatása, illetve borítékolása operátorok által kézzel történik, az így készített másolatok tartalma, illetve az aláíróval kapcsolatos néhány személyes adat elvileg megismerhető számukra. A munkavégzés tempója azonban nem teszi lehetővé a kíváncsiskodást a tartalomban, a teljes terület videokamerákkal ellenőrzött, és a titoktartási kötelezettségük is köti őket. Így a zártság itt is biztosított. A Magyar Posta kizárólag a kiadmányozásra jogosultak nevét és a tanúsítványukhoz tartozó adatokat tartja nyilván, ezeket a személyes adatokat kezeli, de ezek az adatok egyébként is közérdekből nyilvános adatok az e-aláírási rendelet 13. (5) bekezdésében leírtakkal összhangban. Az egyes szervezetekre vonatkozóan még a kapcsolattartók nyilvántartása érint személyes adatokat, erre az E-ügyintézési törvény 36. (2)-(4) bekezdései adnak felhatalmazást. A jelenleg a rendszertől el nem választottan, biztonsági környezetben kezelt biztonsági másolatok telephelyen kívüli kezelésével kapcsolatos feladatrend kialakítása az erre vonatkozó jogszabály megjelenését követően sürgős feladat Egyéb úton az elektronikusan tárolt információ nem hagyhatja jelenleg el a Posta által felügyelt területet, kizárólag, ha a címzett vagy a feladó osztja meg az adatokat másokkal, ez azonban kívül esik a szolgáltató felelősségi körén és lehetőségein. 78

79 2.2.2 Akadálymentesség a fogyatékkal élők számára A Magyar Posta Zrt. által nyújtott SZEÜSZ-ök és KEÜSZ-ök esetében hangsúlyos szempont, hogy mindazokban az esetekben, ahol a szolgáltatások használata fogyatékkal élők számára is értelmezhető, lehetőség szerint biztosított legyen számukra az akadálymentes hozzáférés. Ez igaz a hibrid szolgáltatásokra is, azonban ezt a követelményt csak ott indokolt érvényesíteni, ahol ennek van tényleges tatalma is. A hibrid folyamat aláíró környezetében jelenleg túlnyomó részt automatizált folyamatok történnek, ezért azokra az akadálymentességi feltételek nem értelmezhetőek. Az egyetlen olyan folyamat, ahol a bélyegző elhelyezéséhez személyes beavatkozásra van lehetőség és szükség, a papíralapú eredetiről történő hiteles elektronikus másolat készítése. Ebben a folyamatban viszont az optikai megfelelőségnek kizárólagos jelentősége van, az mással nem helyettesíthető, tehát ebben a munkakörben olyan dolgozó, aki látásában korlátozott nem foglalkoztatható. Ezen a ponton tehát a papíralapú eredetiről történő hiteles elektronikus másolat készítése KEÜSZ a feladat definíciójából következően nem tudja biztosítani az esélyegyenlőséget. Egyéb folyamatokban és a más fogyatékkal élők számára akár a másolatkészítés, akár a rendszer támogatásában való részvétel lehetősége biztosított, az üzem belső területe a technológiából következően jelenleg is akadálymentes kialakítású. A portálfelület akadálymentesítése folyamatban van, ez azonban az aláírások kezelésén túlmutató feladat. 2.3 Információbiztonsági követelmények A Magyar Posta Zrt. mint kijelölt egyetemes postai szolgáltató, országos lefedettségű hálózatával és logisztikai rendszerével, valamint a legnagyobb hazai foglalkoztatóként rendelkezésre álló munkaerő-kapacitásával az ország legjelentősebb gazdasági szervezeteinek egyike. Szolgáltatásainak mennyisége és minősége meghatározó nemcsak a lakosság ellátása, hanem az ország működőképességének fenntartása szempontjából is, így fokozottan védendő kritikus infrastruktúrának minősül. A Szolgáltató alapvető üzleti érdeke, hogy a biztonsági előírások és intézkedések a normál üzleti folyamatok szerves részét képezzék, lefedjék a postai szolgáltatások és az egyéb tevékenységek, így pl. az általa nyújtott SZEÜSZ-ök és KEÜSZ-ök teljes területét. A Magyar Posta Zrt. működésével összefüggésben jelentkező kockázatok megelőzése és minimalizálása, a stratégiai célkitűzések megvalósításának támogatása érdekében a társaság tevékenységének biztonsági vetületeit egységes biztonsági kódex foglalja össze, amely kitér a biztonság számba vehető megvalósítási és fenntartási szempontjaira, eljárásrendjére, így leginkább a szervezeti és humán biztonsági tényezőkre, a tűzvédelemre, 79

80 az adatvédelemre és adatbiztonságra, az informatikai biztonságra, a környezetvédelemre, a munkavédelemre, a veszélyhelyzetek integrált kezelésére, a pénzmosás megelőzésére. Ahogy azt a pontban már jeleztük, a HKKR egésze azzal az igénnyel került megtervezésre és megvalósításra, hogy a folyamat minden lehetséges módon biztosítsa a nyújtott szolgáltatások zártságát, a bizalmasság, sértetlenség és magas rendelkezésre állás megvalósítását. A tervezés során a biztonsági és hitelességi megfontolások képezték az elsődleges prioritást. Éppen ezért a rendszerhez fűződő speciális követelmények megfogalmazása és érvényesítése céljával külön, a Magyar Posta általános a biztonsági kódex egyes fejezeteiben rögzített szabályozásán túlmenő követelményeket rögzítő Üzemeltetési biztonsági utasítás került elfogadásra. Az általános biztonsági követelmények és az Üzemeltetési biztonsági utasítás együttes követelményeinek teljesítését mutatjuk a be a következőkben. Értelemszerűen itt nem kizárólag az aláírásokkal, bélyegzőkkel, hanem a biztonságra, mint egységes, oszthatatlan folyamatra kiható tényezőkkel foglalkozunk Hálózati biztonsági intézkedések A teljes HKKR a Magyar Posta hálózati rendszerén belül egy önálló szegmenset képez, bár a be és kijárat értelemszerűen közös a Magyar Postáéval, a kialakítása során az alapvető szempont a lehetséges maximális biztonság elérése volt. Ezt tükrözi a teljes architektúra, de ezen belül a hálózati kialakítás is. Annak érdekében, hogy a rendszer működési biztonságát a lehető legmagasabb szinten valósítsuk meg, lényegében a teljes rendszer megkettőzött kialakítású, ugyanakkor nem volt lehetőség arra, hogy a két, egymás tartalékát is adó rendszert fizikailag elkülönítetten (georedundáns módon) valósítsuk meg, ez egy lehetséges továbbfejlesztési irány. A rendszer magas védettséget igénylő, nagy számítási és tárolási kapacitást biztosító elemei egy ennek megfelelő védelmet adó adatközpontban kerültek elhelyezésre. A fizikai átalakítást, az anyagi, fizikai termelést megvalósító üzemi területre csak azok az eszközök kerültek kihelyezésre, ahol a kommunikáció intenzitása nem tette volna célszerűvé a központban történő megvalósítást. Ennek megfelelően legmagasabb szinten a 11. ábran látható logikai struktúra jött létre. A hálózat a következő egységek között biztosítja az összeköttetést: központi virtualizációs rendszer (virtualizációs kernel) felé az üzemi terület irányában (helyszínek közötti S2S VPN-t használ az üzemi terület az adatközponti infrastruktúrához kapcsolására) az összes alkalmazáskomponens felé Magyar Posta intranet felől és felé (amit a backend tűzfalak menedzselnek) 80

81 az internet felől és felé (amit a frontend tűzfalak menedzselnek) A külső rendszerek felől és felé (az Internet és/vagy MP intranet kapcsolat irányában) 11. ábra: A hibrid kézbesítési és konverziós rendszer alapvető logikai szerkezete Ott, ahol szükséges (és nem történt meg alkalmazás szinten), az adatok hálózati továbbításának védelme titkosított (ESP) IPsec virtuális magánhálózati kapcsolat használatával történik. Az összes Internet kapcsolatot a fürtbe szervezett Check Point tűzfalak kezelik annak érdekében, hogy magas szintű rendelkezésre állást és optimális teljesítményt biztosítsanak a frontend zóna és a DMZ/karantén terület számára. A DMZ/karantén terület a backend helyi hálózatoktól fürtözött Cisco ASA 5555 tűzfalakkal van leválasztva. Az alkalmazás backend helyi hálózatok és backend terheléselosztó hálózat útválasztását összekapcsolt (stack-elt) L3 Cisco 3850 switchek biztosítják. Egy Cisco ASA 5555 pár menedzseli a következő helyi hálózatok kapcsolódását: Cisco 3850 helyi hálózatok (alkalmazás backend helyi hálózatok és backend terheléselosztó hálózat); a központi (core) alkalmazás és infrastruktúra réteg helyi hálózatai, adat réteg helyi hálózata, menedzsment helyi hálózat, a Magyar Posta intranet felé menő és felől jövő forgalom az Üzemi terület felé menő és felől jövő forgalom; 81

82 A behatolás-érzékelő és megelőző funkciók megvalósítását A hálózati szinten a frontend Checkpoint tűzfalakkal A hálózat/alkalmazás szinten ASM-et (Application Security Module Alkalmazás szintű biztonsági modul tűzfal) biztosító F5 hálózati eszközökkel látja el a rendszer. A Hibrid Kézbesítési és Konverziós Rendszer adatközponti infrastruktúrája és a külső rendszerek között a következő hálózati összeköttetéseket kell biztosítani. Külső rendszer Központi Azonosítási Ügynök (KAÜ) KWR (postai azonosítási rendszer) MWTAT (SAP) jelenleg nem működik Magyar Posta ESB (SMS és SMTP üzenetek) OLK (Magyar Posta Országos Logisztikai központ) Iratérvényességi nyilvántartás (IÉNY) Azonosításra visszavezetett dokumentumhitelesítés (AVDH) Hivatali kapu (HK) Időbélyeg (TSA) Fizetés (OTP VPOS) Bizalmi listák, CRL-ek, OCSP Vírus- és spamszűrük frissítései Kapcsolódás módja: intranet intranet intranet intranet intranet intranet intranet intranet intranet internet internet 7. táblázat: A hibrid kézbesítési és konverziós rendszer rendszerkapcsolatai 12. ábra: A hibrid kézbesítési és konverziós rendszer logikai hálózati architektúrája 82

83 Az adatközpontban az alapfunkciók elkülönítésére a következő virtuális helyi hálózatok kerültek kialakításra (ezek csak tűzfalon keresztül kommunikálnak egymással). Virtuális helyi hálózat neve INTERNET LB_FE FE DMZ MGMT INFRA_CORE TRANSIT_BE APPL_MSG APPL_HM APPL_IHM LB-BE DB TRANSIT_INTRANET Leírás Ez biztosítja a kapcsolatot az internet felé a rendszer Checkpoint tűzfalaitól Logikai (terheléselosztott) portál frontend Portál frontend DMZ és karantén Menedzsment hálózat Központi (core) alkalmazás és infrastruktúra réteg Kapcsolat a tűzfalak backend-je és az L3 switch-ek között Üzenetkezelés alkalmazás réteg Hibrid alkalmazás réteg Inverz Hibrid alkalmazás réteg Logikai (terheléselosztott) backend szerverek Adat réteg Kapcsolódás a Magyar Posta intranet-hez 8. táblázat: Az adatközponti infrastruktúra virtuális helyi hálózatai Az üzemi terület hálózati sémája az egyszerűbb feladatból következően lényegesen egyszerűbb. 13. ábra: Az üzemi terület logikai hálózati infrastruktúrája 83

84 Az üzemi területen a funkciók elkülönítésére a következő virtuális helyi hálózatok kerültek kialakításra: Virtuális helyi hálózat neve OPE_APPL_HM OPE_APPL_IHM OPE_INFRA OPE_WIFI WIFI_OFFICE OPE_MGMT NET_MGMT Leírás Üzemi terület Hibrid alkalmazás virtuális helyi hálózat Üzemi terület Inverz Hibrid virtuális helyi hálózat Üzemi terület Infrastruktúra virtuális helyi hálózat Üzemi terület vezeték nélküli hálózat Üzemi terület- postai belső hálózatra kapcsolódó gépei Menedzsment hálózat WiFi hálózat menedzsment 9. táblázat: Az üzemi terület hálózatainak logikai rendszere A vezeték nélküli (WiFi) hálózatot az üzemi területen 6 db Cisco Aironet 1600 Access Point biztosítja. Az Aironet 1600 eszközök tanúsítványalapú hitelesítést támogatnak (EAP/TLS). A használó PDA-k jelenleg Motorola MC9500-K eszközök; ezek X509.V3 tanúsítvány alapú azonosítást támogatnak. Lecserélésük nagyobb teljesítményű eszközökre folyamatban van Információs rendszer védelmi intézkedések A hibrid kézbesítési és konverziós rendszer működése során megfelelő védelmet igyekszik biztosítani a különböző informatikai kockázati tényezőkkel szemben. Az egyes védelmi elemeket a következőkben mutatjuk be: Vírusvédelem Az antivírus alrendszer a Red Hat linuxos szervereken futó virtuális géppár, amelyeken Symantec Protection Engine termékeke fut annak folyamatos frissítésével. A vírus definíciók naponta kerülnek letöltésre. Az antivírus szerverek a terheléselosztók mögött az elosztott virtuális hálózaton helyezkednek el, nem használnak speciális hardver erőforrásokat. Proxy szervert és közvetve a frontend tűzfalat használja, hogy biztosítsa az antivírus alrendszer hozzáférését az Internethez frissítés céljából. A terheléselosztókon és közvetve a backend tűzfalakon keresztül biztosítja az alkalmazások számára a hálózati kapcsolatokat az Antivirus alrendszerhez. Az antivírus szerverek a TCP portot figyelik ICAP protokollt (RFC 3507) használva. Az alkalmazások amennyiben vírusellenőrzési tevékenységre van szükségük a megfelelő (front- illetve backend) terheléselosztó szerver címére küldenek egy ICAP protokollnak megfelelő üzenetet. A terheléselosztó az adatfolyamot az rendelkezésre álló egyik antivírus szkennerhez fogja továbbítani. A folyamat mind a front-, mind backend oldalról érkező objektumok vírusellenőrzését hivatott biztosítani, ennek megfelelően a két folyamatot együttesen mutatjuk be. A folyamat főbb szereplői és elemei a következők, ahogy azt a 14. ábra is mutatja: 84

85 A frontend (1a) vagy a backend (1b) folyamatban részt vevő alkalmazások kérik egy objektum antivírus átvizsgálását. Ehhez egy ICAP protokoll szerinti üzenetet küldenek a terheléselosztó szerver 1344-es portjára. (hmpavsc00 a backend alkalmazásokban és hmpavscv00-1 a frontend alkalmazásokban). Az üzenet keresztülfut a tűzfalakon és eléri a terheléselosztót (frontend vagy backend terheléselosztó). 2a, 2b a terheléselosztó kiválasztja, hogy melyik szerveren indít egy újabb vírusellenőrzési (szkennelési) folyamatot 3a, 3b az antivírus szkenner feldolgozza az adat-objektumot és ellenőrzi, hogy van-e vírusfertőzés 4a, 4b az antivírus szkenner válaszol a hívó alkalmazásnak és visszaküldi a szkennelési folyamat eredményét. 14. ábra: A vírusvédelem főbb szereplői és folyamatai Vírus észlelés esetén az antivírus alrendszer vírust észlelt eredményt küld az alkalmazásnak és az ennek megfelelően fog működni. Az alkalmazás nem dolgozza fel a küldeményt, hanem egy negatív értesítés elkészítését indítja el annak az ügyfélnek, melytől az üzenet származik. Minden az antivírus alrendszer által kezelt 85

86 információ, amely hamisan vagy ténylegesen kártevő jelenlétét jelzi, megsemmisítésre kerül az antivírus alrendszerben, nem történik tárolás. Az antivírus alrendszer magas rendelkezésre állását a VMware HA (high availability) funkciói, valamint az antivírus gazdagépek terheléselosztói biztosítják. (kettőzött virtuális gépek). Szükség esetén az antivírus alrendszer teljesítményét új virtuális gépek hozzáadásával lehet emelni, miáltal növekszik a párhuzamosan feldolgozható adatok mennyisége. Az antivírus alrendszer kapcsolatban van a Nagios, illetve a Splunk naplózási alrendszerekkel, a terheléskiegyenlítőkkel, a frontend proxyval és tűzfallal a vírusdefiníciós frissítések letöltése és a Pulp rendszerrel a rendszerfrissítések kezelése miatt Hozzáférés-védelem A hibrid kézbesítési és konverziós rendszer hozzáférés-védelme szempontjából három érintett csoportot indokolt megkülönböztetni: a) ügyfelek és ügyfél rendszerek hozzáférése. b) postai dolgozók hozzáférése c) rendszerben ügyfélként nem regisztrált, a postával szerződéses kapcsolatban álló személyek hozzáférése a) HKKR Igénybe vevőinek hozzáférése Az Igénybe vevők regisztrációja és azonosítása során követendő szabályokat az E- ügyintézési tv. 25. (3) bekezdés c) pontja figyelembe vételével a Magyar Posta Zrt. úgy határozta meg, hogy mivel a Központi Azonosítási Ügynök szolgáltatáson keresztüli regisztrációt és azonosítás igénybe vételét biztosítani kell, és jelenleg a Posta nem rendelkezik olyan saját azonosítási szolgáltatással, amely olyan biztonsággal azonosítaná az Igénybe vevőket, hogy ahhoz jogkövetkezményeket lehessen kapcsolni, jelenleg a KAÜ-n kívül más azonosítási szolgáltatással nem lehet a szolgáltatás igénybe vételére regisztrálni. Tervezett a Posta saját azonosítási szolgáltatásának a KWR-nek (Központi Webes Regisztrációs rendszer) egy kellő biztonságú azonosítási szintre történő felfejlesztése, de ennek megvalósítási időpontja még nem ismert. Az Igénybe vevő természetes személyek ennek megfelelően jelenleg kizárólag KAÜ azonosítást követően vehetik igénybe a HKKR portálfelületen át elérhető szolgáltatásait. A rendszerbe önmagukat a KAÜ használatával személyesen regisztrálniuk kell, és ezt követően köthetnek saját maguk számára szolgáltatási szerződést, vagy válhatnak egy vagy több jogi személy különböző jogosultságú megbízottjává, képviselőjévé. A regisztráció során a HKKR-t használni kívánó Igénybe vevők nem kapnak általuk is ismert felhasználó nevet és jelszót a HKKR-ben, azonosításukra egy úgynevezett 86

87 biztonságos kézbesítési cím szolgál, amely a rendszeren belül unikális, a rendszer megakadályozza az ismétlődést. Az azonosítást és hitelesítést a KAÜ külső rendszerként végzi, kizárólag egy, csak ezen rendszer irányában értelmezett állandó azonosítót ad át, amelyet sem az Igénybe vevő, sem a rendszer üzemeltetője nem ismer. A rendszer ezt az azonosítót titkosítva tárolja. Így az érzékeny személyes adatok kezelése minimalizált. Nem természetes személy Igénybe vevők esetében a jogi személy azonosítása és regisztrálása a szolgáltatási szerződés megkötése részeként történik, az elektronikusan előzetesen regisztrált képviseleti jogú személy hozzárendelése a szerződéshez az szerződést megkötő ügyintéző által a kézbesítési cím segítségével történik. Utóbb a képviseleti jogú személy hasonló módon további megbízottakat kapcsolhat a nem természetes személyhez, de első lépésként minden esetben szükség van a KAÜ-n keresztül egyértelmű azonosításra és regisztrációra. Egy természetes személy értelemszerűen nem csak egy nem természetes személy különböző megbízotti szerepeiben járhat el. A rendszer emellett minden szerződéshez az E-ügyintézési tv. 36. (2) bekezdése alapján a szerződés létrehozása, tartalmának meghatározása, módosítása, teljesítésének figyelemmel kísérése az abból származó díjak számlázása, valamint az azzal kapcsolatos követelések érvényesítése és a hatékony kapcsolattartás céljából kezeli az Igénybe vevő, illetve képviselője ilyen azonosításához szükséges természetes személyazonosító adatait és címét. Amennyiben a jogi személy jellemzően közigazgatási szerv Igénybe vevő a küldeményeit a Hivatali kapun keresztül küldi meg a HKKR-be, úgy a rendszer szempontjából csak a Hivatali kapu kerül szerződés megkötésekor azonosításra, a Szolgáltató elfogadja a Hivatali kapu által azonosított szervezetet és az E-ügyintézési törvény 3. (3) bekezdésének megfelelően vélelmezi, hogy a beadvány elektronikus benyújtására szolgáló, jogszabályban meghatározott elektronikus kapcsolattartási módokat és technikai eszközöket jogszerűen alkalmazzák. Ebből a vélelemből és az e-ügyintézési Vhr. 85. (1), (2) és (4) bekezdéseinek megfelelően valamennyi az adott Hivatali kapu felől érkező küldeményt az Igénybe vevőtől érkezőnek tekint és feldolgoz. Amennyiben az Igénybe vevő webszolgáltatás (a rendszer leírásaiban leggyakrabban webautomataként jelzett szolgáltatás) igénybe vételével kíván kommunikálni a HKKR-rel, úgy a kapcsolat létrehozásához előzetesen regisztrálnia kell egy az EU bizalmi listáján szereplő szolgáltató által kibocsátott, a 137/2016 (VI. 13.) Korm. rendelet 4. alcímében szereplő előírásoknak megfelelő aláírási célú tanúsítványt az adott szerződéshez. Emellett biztosítania kell egy a kommunikációs csatorna biztonságát szolgáló, a TLS kapcsolat kiépítéséhez alkalmas tanúsítványt is. A webautomata használatával történő kommunikáció szabályait részletesen a felhasználói kézikönyv II. kötetet tartalmazza. b) postai dolgozók hozzáférése 87

88 Az Magyar Posta Biztonsági kódexe VI. mellékletét képező Informatikai Biztonsági Szabályzat 7.1. e pontja alapján, a rendszerekhez történő hozzáférés az erre a célra kialakított hozzáférés igénylés útján történhet meg, ahol az adott szervezeti egység vezetője igazolja az hozzáférés szükségességét, amelyet az adatgazda vagy a belső szabályzatban/eljárásrendekben meghatározott személy engedélyez. A belső felhasználók (a rendszerben feladatokat végző postai munkavállalók) jelszavainak kiosztása egységes csoportházirend segítségével történik, amely megkapott jelszó azonnali megváltoztatásának kötelezettségét is előírja. A felhasználói azonosítókat nyilván kell tartani és mindennemű változást (az ellenőrizhetőség érdekében) naplózni kell. A jelszónak minden felhasználó számára szabadon megváltoztathatónak kell lennie. A felhasználói jelszavakkal kapcsolatban biztosítani kell a következő követelmények teljesülését: minimális jelszóhossz megkövetelése; a jelszó egyedisége (történeti tárolás) adott időszakon belül; a központi jelszó megadása utáni első bejelentkezéskor a kötelező jelszó cseréje; a jelszó maximális élettartama; a jelszó zárolhatóságának biztosítása; a jelszó képzési szabályainak bonyolultsági kritériumnak meghatározása. Az informatikai rendszerekbe való bejelentkezés során, továbbá a jelszó megváltoztatásakor gondoskodni kell arról, hogy a jelszavak alapállapotban azonosíthatatlanul jelenjenek meg a képernyőn és csakis a felhasználó által a megfelelő billentyű megnyomása mellett legyenek láthatóak. A jelszavakat vagy a jelszóállományokat a hálózaton nyílt, értelmezhető formában továbbítani tilos. A jelszavak újra felhasználásának engedélyezését minimum legutóbbi 5 jelszó esetében meg kell tagadni. A HKKR-ben alkalmazott hitelesítésre szolgáló eszközök hibás azonosító vagy jelszó megadása esetén csak olyan hibaüzenetet adnak vissza, melyből nem szerezhető további információ sem az azonosító, sem a jelszó megtöréséhez. Ahol a rendszer adottságai megengedik, felhasználói szerepköröket, csoportokat kell képezni, és az egyes jogosultságokat a szerepkörhöz, csoportokhoz kell rendelni. A hozzáférési szerepkörök kialakításában együttműködik az adatgazda, az érintett szervezeti egység vezetője, indokolt esetben az informatikai alkalmazás rendszergazdája. A technikai felhasználók jelszavait külön jelszószéfben tárolja a Szolgáltató, ahol a hozzáférés külön naplózott és a jogosultságokat a feladat ellátásához szükséges minimum elve alapján állapítják meg. 88

89 A HKKR kizárólag a HSM-ben tárolt kriptográfiai kulcsokat használ elektronikus bélyegző előállításához. Egyéb kriptográfiai kulcsok (SSL tanúsítványok) vonatkozásában a szoftveres kulcstárolás is megengedett szabványos kulcstároló állományokkal (jellemzően JKS állományok). A dolgozóknál semmiféle kriptográfiai eszköz nem található, a kulcstároló állományok jelszavait nem kezelik. Az egyetlen olyan folyamatban, ahol elektronikus bélyegző létrehozásáról döntenek, a hiteles elektronikus másolatok készítésekor a supervisoroknak kizárólag jóvá kell hagyniuk a másolat megfelelő voltát, (nem kell sem jelszót, más azonosítási módszert alkalmazni) ez azonban szigorúan ellenőrzött területen (belépéskor azonosítva), és képileg folyamatosan rögzített környezetben történik. A HSM-ben tárolt kriptográfiai kulcsok cseréjét az Informatikai üzemeltetési igazgatóság és az IBO erre feljogosított munkatársai a négyszem elv szerint együttesen végzik el. A kulcsok transzportálására szolgáló eszközöket az IBO adatszéfjében kell tárolni. c) a postával szerződése viszonyban álló, de a rendszerben felhasználóként nem regisztráltak hozzáférése A Magyar Posta az Ibtv. 11. (1) bekezdés k) és l) pontjaival összhangban biztosítja, hogy az Ibtv-ben számára előírt követelmények a HKKR működtetésével kapcsolatban szerződött partnerei felé szerződéses követelményként érvényesüljenek. Így a HKKR üzemi területére csak olyan dolgozók léphetnek, megfelelő nyilvántartás mellett, akik megfelelnek az e-ügyintézési Vhr a) pontjában meghatározott követelménynek. Azok a nem a szolgáltatást igénybe vevő harmadik személyek, akik valamilyen okból (pl.: fejlesztés, tesztelés, hibajavítás stb.) kapcsolatba kerülnek a HKKR bármelyik alrendszerével, csak meghatározott időre, és korlátozott lehetőségeket biztosító (pl. az adott projekt, feladat keretein belül érvényes) felhasználói azonosítót kaphatnak. Ilyen jogosultságot csak különösen indokolt esetben, vezetői kérésre, HPSM engedélyezési folyamat szerint az IBO jóváhagyásával lehet számukra biztosítani. A Magyar Posta gondoskodik arról, hogy az egyes szerződések lejáratakor a hozzáférést lehetővé tevő eszközök visszaadásra, a jelszavak megváltoztatásra kerüljenek Biztonsági patch-ek menedzsmentje A sérülékenység és patch menedzsment célja, hogy a HKKR IT infrastruktúrájának megfelelő elemeit (hardver, szoftver és szolgáltatások) naprakészen tartsa, figyelembe véve a legfrissebb a legfrissebb patch-eket és javításokat. A Magyar Posta teljes üzemeltető stábja tisztában kell legyen azzal, hogy az infrastruktúra sérülékenységeinek minimalizálása és naprakészen tartása az ő feladatuk és felelősségük. A szállító a következő sérülékenység és patch menedzsment feladatokat határozta meg (lásd RJ4A jelű dokumentum) a HKKR fenntarthatósága érdekében: 89

90 1. A HKKR antivírus és antispam szervereit úgy kell konfigurálni, hogy azok automatikusan töltsék le és érvényesítsék a legfrissebb vírus- és spamdefiníciós állományokat 2. A Windows patch menedzsment eszközöket kell használni a legfrissebb Microsoft biztonsági patch-ek letöltésére. A patch-eket ezután elemezni és szükség szerint használni kell. 3. Az alkalmazás és adatbázis szállítók jelzéseit a patch-ekre vonatkozóan figyelemmel kell kísérni, azokat meg kell vizsgálni, és szükség esetén alkalmazni kell. Amennyiben a szállítók nem küldenek automatikusan jelzést a frissítésekről a szállítók weblapjait kell rendszeresen figyelemmel kísérni. 4. A szerverek, munkaállomások, nyomtatók, routerek, switchek, hálózati eszközök és perifériák szállítóinak webhelyeit rendszeresen figyelni szükséges a firmware patchek elérésének biztosítása érdekében. 5. Az azonosított hiányzó patch-eket telepíteni kell, amennyiben szükségesek. Minden fennálló sérülékenységet kezelni szükséges. 6. A Linux operációs rendszereken minden frissítést/patch-et a megfelelő szolgáltatás szállítója útján kell tesztelni és végrehajtani 7. A Linux operációs rendszerek minden frissítése során a változás-kezelési folyamatot kell követni, hogy biztosítsuk a frissítések sikeres végrehajtását és minimalizáljuk az esetlegesen fellépő problémákat. A Magyar Posta IT üzemeltetési részlege felelős azon alkalmazói rendszerek patcheinek azonosításáért és telepítéséért, amelyeket ők gondoznak. Ugyancsak ők felelősek az összes patch-ek jóváhagyásáért és a technikai frissítések lebonyolításáért beleértve az operációs rendszereket, a szervereket, a munkaállomásokat, az antivírus és antispam rendszereket. Az IT üzemeltetésnek kell visszaállítási pontokat kialakítani, ahol ez szükséges, hogy biztosítani tudják az esetleg szükséges visszaállásokat Az alkalmazói szoftverek integritásának védelme Ha leszűkítjük az alkalmazói szoftverek biztonságának kérdéskörét az aláírás során használt folyamatelemekre és eszközökre, akkor ezek biztonsága, védelme azáltal is teljes mértékben biztosított, hogy ezek az alkalmazások a bélyegzők előállítása során nem érintkeznek külső forrásból beérkező információval, tehát a vírusfertőzés vagy bármilyen más funkcionális módosulás lehetősége a rendszer egészének sérülése és komoly üzemzavara nélkül nem lehetséges. Ennek megfelelően ebben a fejezetben is általánosabban vizsgáljuk a szoftver-integritás kérdéskörét. Ahogy azt a fejezetben már jeleztük, a szállító a szoftver általános leírásában rögzített nyilatkozata (HMDACS DESIGN SPECIFICATION_EN_2.0.pdf 6.2 fejezet Code signing) szerint valamennyi általa fejlesztett kódot aláírva szállított. A Magyar 90

91 Posta Zrt. ehhez külön a NISZ Zrt. által kibocsátott kód aláíró tanúsítványt is biztosított. A szoftverek ennek megfelelően saját indulásukkor minden esetben összevetik az önmagukról képzett lenyomatot az aláírásban szereplővel és csak akkor indulnak el, ha ez a két érték megegyezik, egyébként hibajelzéssel a rendszer leáll. (Azt természetesen tudni kell, hogy ez a védelem nem korlátlan, a memóriában levő végrehajtható program is módosulhat bizonyos nem kívánt esetekben.) Alapfeladatként éppen ezért architekturálisan a rendszer vírusvédelme került úgy kialakításra, ahogy ez a fejezetben már bemutatásra került, hogy addig egyetlen érdemi feldolgozó rendszer sem foglalkozik a bekerült állományokkal, amíg azok spam- és vírusellenőrzése meg nem történt. Ennek megfelelően csekély annak valószínűsége, hogy vírusfertőzött dokumentumok kerüljenek a belső feldolgozási folyamatba. (mint már bemutattuk, az elektronikus aláírási folyamatot közvetlenül semmilyen esetben nem érik el a beküldött elektronikus állományok) A szoftverek konfigurációs állományainak védelme a fejezetben bemutatott szigorú hozzáférés-védelmi szabályok által biztosított. Csak az erre fejjogosított néhány üzemeltető képes ezeket az állományokat elérni, illetve szükség esetén módosítani Az adattárolás biztonsága Az adatok biztonságos kezelése a teljes rendszer megbízhatóságának egyik kulcseleme, ennek megfelelően az adatbiztonságot sokrétű intézkedéscsomag támogatja. a kezelt adatok jellegének a különböző fázisoknak megfelelően leginkább alkalmas tároló mechanizmusok biztosításán túlmenően hardveresen teljesen megkettőzött megoldásokkal képes gyakorlatilag a folyamatos rendelkezésre állást biztosítani. A beérkező, illetve kiküldendő adatok integritását a teljes adatfolyam folyamán ellenőrzi és fenntartja, illetve jogi szempontból bizonyítéknak számító objektumokat olyan nagy megbízhatóságú tároló rendszerben őrzi meg, amelynél az utólagos módosítás lehetősége a megőrzési időn belül kizárt. 15. ábra: A rendszerben megvalósított különböző logikai tárolási funkciók 91

92 A kezelt adatok sokrétű használatának megfelelően a tárolásukat is differenciált módokon valósítja meg a rendszer. Minden funkcióhoz igyekeztek a célnak megfelelő tárolási technológiát, technológiák kombinációját alkalmazni mind a hardver, mind a szoftver/szolgáltatás szempontjából. Az operatív tároló a folyamatok által használt küldeményeket, kézbesítési utasításokat, metaadatokat, nyomkövetési adatokat és bizonyítékokat tartalmaz. Ez a terület használatos a különböző folyamatok közötti információ-cserére is. Az operatív tároló a feladat elemzése nyomán MongoDB adatbázissal került megvalósításra, ideértve a küldemények dokumentumait, metaadatokat, bizonyítékokat és nyomkövetési információt. A MongoDB egy NOSQL típusú adatbázis, ahol a fizikai adatmodellezés eltér az RDBMS-hez használatos hagyományos megközelítéstől mivel a kezelt alapegység nem az adatbázis sor, hanem a BSON dokumentum. A BSON a webes kommunikációban széles körben használt JSON (JavaScript Object Notation RFC 7159) formátum bináris változata, amely önmaga is tartalmazhat strukturált adatokat, míg az RDBMS-ben lévő sor nem. A műveleti tárterületen tárolt objektumok életciklusa a feldolgozási folyamathoz igazodik. Egy ütemezett folyamat periodikusan eltávolítja az operatív adattárból az összes régi adatot és bizonyítékot. A bizonyítékokat a rendszerből ugyanazon időben írják át a felhasználói megőrzési területre és a bizonyíték archiváló rendszerterületre, ahol a megőrzés az adatok által megalapozható polgári jogi elévülési idő alapján számított időpontig biztosított. A felhasználó megőrzési terület azokat a rendeltetésük szerint az Igénybe vevő felügyelete alatt álló objektumokat tartalmazza, amelyek már befejezték feldolgozási ciklusukat. Ilyen objektumok lehetnek a küldemények, a hozzájuk tartozó bizonyítékok és a feldolgozáshoz kapcsolódó metaadatok. Ez utóbbiak tartalmaznak minden olyan hivatkozást is, amelyek a nyomkövetési, elszámolási adatok stb. kezeléséhez szükségesek. A gép-gép kommunikáció megőrzési területe azokat az objektumokat tartalmazza, amelyek gép-gép kommunikációval (webszerviz) jöttek létre és a feldolgozási ciklusa már befejeződött. Ilyen objektumok lehetnek a küldemények, a bizonyítékok, a záradékok, illetve metaadatok A felhasználóknak küldött értesítő üzenetek tárterülete az a terület, amely a HKKR belső szolgáltatásai által a kézbesítésben érintett felhasználóknak küldött üzeneteket tartalmazza. Ezeket az üzeneteket például a küldemények és bizonyítékok előállításához és rendelkezése állásához kapcsolódó események váltják ki. Egy üzenet általában valamely szöveges leírásból, valamint az értesítés tárgyául szolgáló eseményhez kapcsolódó küldeményekre és bizonyítékokra mutató hivatkozásokból tevődik össze. A hivatkozás lehetővé teszi a küldemény vagy a bizonyíték megtekintését a webes portálon. A biztonságos kézbesítés során küldött vagy kapott összes felhasználói üzenet és értesítés (bizonyítékra mutató linket tartalmazó üzenetek) Oracle adatbázisban kerül rögzítésre. 92

93 A bizonyíték archiváló rendszerterület mindazokat a bizonyítékokat tartalmazza, amelyeket a feldolgozó folyamatok állítanak elő. Ez a terület garantálja, hogy az összes bizonyíték a törvényi előírásoknak és a szabványoknak megfelelően legyen archiválva. Emellett az információt specializált hardveres/szoftveres megoldások is védik. A portál és adat-hozzáférési réteg specializált interfészt biztosít ezen információk kiolvasásához. A hozzáférési réteg tervezése során különös figyelmet szenteltek a biztonságnak. E réteg biztosít hozzáférést a megőrzött objektumokhoz az adott tárterület és fizikai tároló infrastruktúra jellegéhez igazodva. Az alkalmazott főbb védelmi megoldások a következők: A hozzáférő irányok hálózati IP szűrése A hozzáférés engedélyezése csak azonosított alkalmazásoknak, specializált szolgáltatások révén lehetséges. Az adathozzáférési réteg felhasználó-hitelesítést követel meg Az hozzáférés engedélyezését a küldemények, bizonyítékok stb. metaadataiban tárolt információk alapján valósítja meg. A legkritikusabb információk titkosítottan kerülnek tárolásra, amely csak az adott alkalmazással visszafejthető. A titkosítási és visszafejtési tevékenység is naplózásra kerül. A rendszer biztonságát a fizikai megvalósítás is jelentős mértékben alátámasztja. Az adatközponti infrastruktúrája magas rendelkezésre állás és nagy kapacitás szolgáltatására képes, a nagysebességű alacsony latenciájú és nagy tárolóképességű lemezek kombinációjával. Ezek FC tárolóhálózatként (SAN) vannak telepítve. A rendszer magja egy tárolótömb pár, aktív - aktív redundáns és replikált konfigurációban. A SAN kezdeti tároló képességét 36 db SAS 600 GB 15 K RPM nagyteljesítményű lemez, valamint 48 db NL-SAS 4 TB, 7.2K RPM nagykapacitású lemez kombinációjával biztosítja. Minden alkalmazás, amely a rendszerhez fordul, a leggyorsabb tárolók előnyeit élvezheti. A rendszer automatizáltan tölti át az adatokat a leggyorsabb tárolókról nagy tároló képességűekre a nagyteljesítményű hardveres algoritmus alapján. A technológia mély integrációt tesz lehetővé a VMware virtualizációs platformmal egy különleges plugin használatával. A tárolási infrastruktúra 2 lemezes alrendszert tartalmaz (mindegyik 2 db SAN vezérlővel). Ezek aktív - aktív rendszerek a szerver infrastruktúra felé és szinkronizáltan replikálják az adataikat egymás között. Minden tranzakció csak akkor tekintendő lezártnak, amikor a fő rendszer veszi a másolási nyugtázást a (relatív) másodlagos rendszer felől. 93

94 16. ábra: Az adatfeldolgozás biztonságát szolgáló rendszerkialakítás Az események naplózása A hibrid kézbesítési és konverziós rendszer alapfunkcióját tekintve a bizonyítékokat a rendszerben keletkező aláírt (a posta bélyegzőjével és független szolgáltató minősített időbélyegzőjével ellátott, az érdemi kézbesítési eseményeket önállóan tanúsító elektronikus dokumentumok jelentik. Ezek alátámasztását szolgálja, hogy minden a rendszerben történt, a küldemény életútját befolyásoló eseményről megfelelő bizonyító erejű naplóbejegyzés álljon rendelkezésre. A naplózó rendszer a szolgáltatások összetettsége miatt tartalmaz egy sor a rendszer állapotára vonatkozó információt is, sőt külön monitoring alrendszer biztosítja a rendszer felügyeletéhez szükséges adatokat, információkat, itt azonban hangsúlyosan a naplózó alrendszerrel foglalkozunk. A naplózási alrendszer a Splunk Enterprise verzióján alapul, amely az egyik piacvezető szoftvercsomag a naplózási adatgyűjtés és vizualizáció terén. Ez a megoldás gyűjti, rendszerezi (indexeli) az információt HKKR összetevőiről (alkalmazások és IT infrastruktúra). Az adatokat szűri, összesíti és tömöríti, és az így előkészített információt juttatja el a logok tárolására szolgáló alrendszerbe, illetve a rendszer felügyeletét biztosítókhoz. A naplózott információk könnyebb áttekintése 94

95 érdekében a Splunk rendelkezik egy testre szabható konzolfelülettel, amelyről keresési műveleteket lehet végezni a naplózott eseményeken és statisztikán készíthetők. A HKKR rendszer biztonsági filozófiájának megfelelően a Splunk naplózási rendszer kimenete a Magyar Posta információbiztonsági rendszerei felé úgy lett konfigurálva, hogy "küldje" az összegyűjtött naplózási információkat a postai rendszerbe, azaz nincs kívülről bejövő információ ezen funkcióban sem, nem sérti a rendszer zártságát. A Splunk megoldás a következő főbb elemekből áll: Továbbító ügynökök: begyűjtik a naplózott adatokat a különböző forrásokból és továbbítják azokat az indexáló szerverekhez. Indexáló szerverek: fogadják a naplózásokat a továbbító ügynököktől és egyéb bemeneti forrásokból és eltárolják azokat a különböző indexelt állományokban a forrásuknak és típusuknak megfelelően. Két indexáló van használatban a magas szintű rendelkezésre állás biztosítására és a terhelés-kiegyenlítés érdekében. Kereső szerver: Az operátorok web böngésző használatával kapcsolódhatnak a kereső szerverhez a rendszer konfigurálása és naplóadatok keresése céljából. A naplózási alrendszer alapszolgáltatása két indexáló szerveren fut. Az indexáló szerverek a különböző szervereken keletkező naplózási adatokat a továbbító ügynököktől kapják, és helyileg tárolják azokat. A továbbító ügynökök és indexáló szerverek közti protokoll, a Splunk tulajdona, amely TCP alapú, kódolt és megbízható. Az indexelőn szerverek terhelés kiegyenlítő üzemmódban dolgoznak: a továbbító ügynökök terhelés kiegyenlítő üzemmódban küldik el a napló-adatokat minden indexáló szerverhez, meghatározott időközönként váltogatva a megcélzott Indexálókat. Amennyiben egy indexáló szerver nem üzemel, a továbbítók azt nem használják, és a napló-adatokat csak a működő indexáló szervernek küldik el. Ez lehetővé teszi a horizontális bővítést (indexáló szerverek hozzáadását) és a magas szintű rendelkezésre állást Azon hálózati elemek (kapcsolók, útválasztók, tűzfalak stb.), melyek nem tudják használni a Splunk protokollt, hanem csak syslog protokoll használatával tudják az állapotukra vonatkozó információt közölni, a naplózás információt a hálózati terheléselosztókon keresztül küldik az indexáló szervereknek syslog protokoll használatával. A napló adatok kereséséhez, az operátorok a webböngészővel csatlakoznak a kereső szerverre. A kereső szerver a keresést az összes indexáló szervernek továbbítja. A keresések az összes indexáló szerveren végrehajtódnak. Az indexáló szerverek a keresést a saját lokális tárolóikban hajtják végre. A kapott keresési eredményt visszaküldik a kereső szerverhez, amely integrálja azokat és elküldi a web kliensnek. Az architektúra vertikálisan bővíthető, virtuális erőforrások bevonásával (vram és vcpu) és horizontálisan újabb indexelő szerverhozzáadásával. A napi kezelhető adatmennyiséget azonban a licenc is korlátozza. 95

96 17. ábra: A naplógyűjtő rendszer logikai sémája A következő esemény-kategóriák kerülnek eltárolásra és indexelésre a naplózási alrendszerben: Kategória Operációs Rendszerek Hálózati elemek Leírás Napló-információk a Linux operációs rendszerből és a Microsoft rendszer esemény-naplózásból. Az operációs rendszerbe telepített ügynökön keresztül begyűjti a figyelmeztetéseket, hibákat és kritikus információt A következő aktív hálózati elemekről gyűjt be információt: Hálózati switch-ek FC switch-ek Hálózati terhelés-elosztók 96

97 Tároló eszközök Virtualizációs környezet Hálózati tűzfalak Web alkalmazás tűzfalak Minden információt syslog protokollon keresztül gyűjt be a naplózási alrendszerbe Naplózás információk a tároló készülékekről: SAN tároló tömbök DAS (közvetlenül elérhető) tároló eszközök NAS eszközök CAS alrendszer A naplózási információt a syslog protokollon keresztül gyűjti be a naplózás alrendszerbe A virtualizációs környezetből (VMware infrastruktúra) a naplózási információ a Syslog protokollon keresztül érkezik 10. táblázat: A naplózási információ forrás típusai A rendszer a tervek szerint 126 különböző alrendszer eseményeit naplózza. A naplózás menedzsmentje során meghatározható: A naplózás szintje, milyen mélységű és részletezettségű információt jelenítsen meg, (normál, nyomkövető stb.); Milyen naplófájlba kerüljön kiírásra a naplóinformáció; Meg lehet határozni a napló forgási sebességét. A naplóbejegyzések a következő szerkezeti sémán alapulnak: <TIME>-<SYSTEM COMPONENT>.<SUBSYSTEM COMPONENT>-<LEVEL>- <INFORMATION RELATED TO SUBSYSTEM>: <MESSAGE> Az egyes mezők jelentése a következő: TIME Az esemény ideje (azaz, [10/10/2014:13:55:36: ]) SYSTEM COMPONENT a különböző rendszerelemeket rögzítő táblázat alapján az egyes rendszerekhez megadott CODE mező értéke SUBSYSTEM COMPONENT a különböző rendszerelemeket rögzítő táblázat alapján az egyes alrendszerekhez megadott CODE mező értéke LEVEL Trace, Normal, Warning, Minor, Major, Critical a bejegyzés szintje az előbbi értékekkel INFORMATION RELATED TO SUBSYSTEM ezt az információt az üzenetek hozzárendeléséhez lehet használni (a hivatkozott táblázat jelzi, hogy az egyes naplóbejegyzéseket mi alapján lehet akár küldeménnyel, akár a rendszer egyes állapotaival összekapcsolni) MESSAGE a tényleges üzenet, ami a legrészletesebb információt hordozza az eseményről Egyes információkat alfanumerikus kódokkal lehet azonosítani. A rendszer ezeket a naplózási információkat egyrészt biztosítja az üzemeltetők számára, akik azokat a rendszer állapotának nyomon követésére használják fel, másrészt egy szűkített részhalmazát az elvégzett műveletek bizonyítékaként áthelyeznek az előző fejezetben már bemutatott tartós tároló, archiváló rendszerbe, amely a bizonyítékokat az ÁSZF I pontjával összhangban azokat az általános elévülési határidővel összhangban 5 évig megőrzi. Ezt követően az információk a rendszerbe előre beállítottan törlésre kerülnek. 97

98 A megőrzési időszak alatt az érintettek az érintettségük igazolása mellett érhetnek információt, amely bizonyítja egy adott küldemény vagy dokumentum életútját. A tárolt információ elérésére egy önálló alkalmazás szolgál, amely kizárólag meghatározott belső hálózati végpontról érhető el. Ezzel az alkalmazással vissza lehet keresni az egy küldeményhez (a küldeményazonosító megadásával) tartozó bizonyítékokat, az egy szerződéshez és egy időponthoz tartozó küldeményeket, az egy szerződéshez és egy időponthoz tartozó naplózott információkat. A hozzáféréseket, a lekért információt a rendszer a többi naplózási adattól függetlenül naplózza. 2.4 Feldolgozási követelmények az aláírás készítési, kiterjesztési és hitelesítési folyamatban A hibrid kézbesítési és konverziós rendszerben a nyilvános kulcsú infrastruktúra és az alapját adó aszimmetrikus kulcsú titkosítás széles körben alkalmazott, azonban az ott alkalmazott szoftvercsomagot annak ellenére nem lehet mindennapi gyakorlatban aláíró és aláírás ellenőrző szoftvernek tekinteni, mivel a különböző, a rendszer által előállított elektronikus dokumentumok hitelesítésére az elektronikus bélyegzők használata az esetek túlnyomó többségében emberi beavatkozást kizárva történik. Ennek megfelelően bár természetesen fontos vizsgálni az aláírás-készítő és érvényesítő szoftvereknél alkalmazott értékelési szempontokat, azok nem mindegyike alkalmazható e szolgáltatás vonatkozásában. Ahol egyáltalán lehetőség van emberi beavatkozásra, a papíralapú dokumentumról hiteles elektronikus másolat készítése KEÜSZ során, ott is csak arról dönthet az operátor, illetve a supervisor, hogy kezdeményezi-e az aláírás-készítés folyamatát, miután meggyőződött az egyes komponensek tartalmáról, vagy sem. Itt sincs tehát lehetőség sem az aláírás formájának, sem a dokumentum összetételének, sem egyéb körülményeinek meghatározására, ami az általános célú aláíró szoftvereknél a normális működés elengedhetetlen része. Itt a PKI technológia alkalmazása a termelési folyamat fontos hitelesítő eszköze, de ami történik, az csak eredményét tekintve aláírás, az aláírandó dokumentum összeállítása és a választott hitelesítési megoldás előre teljes mértékben determinált. E szigorú folyamati meghatározottságból következően egy sor, egyébként részletesen vizsgálandó kockázati tényező, hibázási vagy hamisítási lehetőség eleve kiesik és ezért a folyamat lényegesen egyszerűbb az általános gyakorlatnál Aláírás készítési folyamatok és rendszerek Ahogy azt az fejezetben már részletesen tárgyaltuk a rendszer szigorúan meghatározott formátumú és szerkezetű dokumentumokat ír alá az esetek túlnyomó többségében automatizáltan, ahol igen korlátozottak a lehetőségek a humán 98

99 beavatkozásra mind a korrekció, (kontroll) mind a hibázás lehetősége szempontjából és ebből következően az aláírási, bélyegzőkészítési folyamatok is túlnyomó részt emberi beavatkozás nélkül, automatizáltan mennek végbe. A következő fejezetekben bemutatjuk, hogy az aláírások készítése során az általánosan érvényes szempontokat hogyan alkalmazzuk a rendszerben előforduló esetekre, hogyan biztosítjuk, a bélyegzők készítése során az elégséges biztonságot Fő funkciók A rendszer logikájából következően szigorúan meghatározott, hogy mely folyamatban milyen aláírási (bélyegző) formát támogat a rendszer, és ebből a szempontból nincs is választásra jelenleg lehetőség, a folyamat csak egy módon képes végig futni. A rendszer kizárólag fokozott biztonság követelményrendszerének megfelelő, valamilyen AdES típusú bélyegzőt alkalmaz, tehát egyszerű elektronikus aláírások egyáltalán nem fordulnak elő. A rendszer felépítésénél, eszközkészleténél fogva alkalmas minősített elektronikus aláírások készítésére, azonban ehhez még a biztonsági házirendekben és az üzemeltetők felkészítésében fejlesztésre van szükség, ez még a jövő feladata. A rendszer így is maradéktalanul teljesíti az e- ügyintézési Vhr. 75. (3) bekezdésének előírását, mely szerint legalább fokozott biztonságú elektronikus bélyegzővel kell ellátni a kiadott igazolásokat. A következőkben ennek megfelelően kizárólag a fokozott biztonsági szintet elérő aláírásokkal és bélyegzőkkel foglalkozunk. 18. ábra: A fokozott biztonságú aláírások készítésének elvi blokksémája az EN szabvány alapján (a rövidítések a rövidítés-listában) 99

100 A rendszer által kiadott igazolások minden esetben PDF dokumentumok, így azok elektronikus bélyegzővel történő ellátását értelemszerűen PAdES formátumban (EN szabvány, illetve ETSI TS műszaki előírás szerint) biztosítja. Az elkészült aláírásokra azonnal független minősített időbélyeg szolgáltató által (esetünkben a NISZ Zrt kormányzati időbélyeg-szolgáltatása) biztosított időbélyegzés kerül, így az aláírás keletkezési időpontja is egyértelmű, és a dokumentum megfelel a PAdES-T aláírási szintnek. Ennél magasabb szintű aláírást a rendszer nem biztosít. (nem feladata archiválás). Az bélyegzőket a széles körben alkalmazott, nyílt forráskódú itext szoftver helyezi el az automatikusan, zárt folyamatban készített igazolásokon, cserére, tévesztésre a rendszer nem ad lehetőséget. Az igazolásokkal kapcsolatos követelményeket és azok szerkezetét a másolatkészítési szabályzatok is részletesen tárgyalják. Az igazolások eltárolásra kerülnek a nagy megbízhatóságú és rendelkezésre állású CAS (Caringo) tároló rendszerben. Hasonló a helyzet a helyzet az iratérvényességi nyilvántartás számára átadott tárolási kérésekkel kapcsolatban is. Ebben az esetben az átadandó információ egy XML állomány, ennek megfelelően a rendszer XAdES formátumú (EN szabvány, illetve ETSI TS műszaki előírás szerint) elektronikus bélyegzőket helyez el az átadandó üzenetekre. Ezt a feladatot az EU CEF forrásaiból fejlesztett nyílt forráskódú DSS szoftver látja el. Ezekre a bélyegzőkre is az előzőekben említett időbélyegzés kerül és így itt XAdES-T formátumúak az Iratérvényességi nyilvántartásnak átadott üzenetek. Maguk az átadott üzenetek kerülnek megőrzésre a korábban már ismertetett magas biztonságú CAS tároló rendszerben a megőrzési idő lejártáig. Bár az eredeti elképzelésekben két dokumentum formátum szerepelt, jelenleg kizárólag PAdES formátumú hiteles elektronikus másolatokat állít elő a papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ során a rendszer. Itt is teljesen zárt a folyamat abban az értelemben, hogy már az adott csomagra vonatkozó feldolgozási folyamat megkezdésekor pontosan meg kell határozni a feldolgozási folyamattípus kiválasztásával, hogy milyen dokumentum-komponensek, milyen feldolgozási folyamat-lépések eredményeként kerülnek majd a kibocsátandó elektronikus másolatba. Ezen a folyamat közben már változtatni nem lehet. Ebben az értelemben itt is teljesül tehát a kiinduló adatok és a feldolgozási eljárás teljes összhangja, hiszen a folyamat előre teljes egészében rögzített, csak a már rögzített eljárásrendek közül lehet kiválasztani az alkalmazni kívántat és az minden folyamatlépést előre meghatároz. A folyamatvezérlés szigorúan ellenőrzi, hogy ne kerülhessen az előzetesen rögzítettektől eltérő a dokumentumok közé, és a folyamat során a zárt rendszerből következően más információ sem kerülhet be. Miután a másolatot készítő operátor minden egyes oldalt egyenként megvizsgált azonosság, olvashatóság és teljesség szempontjából, a tovább küldéssel naplózottan igazolja az elkészült elektronikus másolat megfelelő voltát. A supervisor ezek után is véletlenszerű mintavétellel 100

101 ellenőrizheti a másolatok megfelelőségét, és utána megalapozottan dönthet, hogy a másolat elektronikus bélyegzésre vagy visszaküldésre kerül. Egyéb döntési lehetőséget adni indokolatlan lenne, semmivel sem növelné a folyamat biztonságát. E folyamat végén PDF formátumú dokumentumokon az igazolás-készítési folyamatoknál már leírt jellemzőkkel bíró PAdES-T bélyegző készül. Az adatvédelmi követelmények miatt azonban ebben az esetben az átalakított dokumentum kizárólag addig kerül megőrzésre a szolgáltatónál, amíg az Igénybe vevő vissza nem igazolta az átalakított dokumentum átvételét. Utána csak az elküldésre vonatkozó adatok bizonyítják a másolatkészítés tényét. Összességében tehát megállapítható, hogy az aláírás-készítés folyamatai során egyértelműen, eltérést meg nem engedően meghatározottak az alkalmazott aláírási formátumok és folyamatok, a rendszer ezektől eltérő lépéseket, másformátumok alkalmazását nem tesz lehetővé. A folyamatokat, amelyek eredményeként létrejönnek az elektronikus bélyegzővel ellátott elektronikus dokumentumok, a három szolgáltatás folyamatszabályozási dokumentumai egyértelműen rögzítik A különböző adattartalom típusok menedzselése Az előző fejezetben leírtaknak megfelelően a különböző aláírandó dokumentumok előzetesen teljes mértékben meghatározott folyamatok eredményeként, minden esetben pontosan meghatározott formátumban jönnek létre. Nem fordulhat elő, hogy egy aláíró alkalmazás nem olyan dokumentumtípust kap, mint amelynek a kezelésére szolgál. Itt tehát nem lehet értelmezni azt a hagyományos aláíró rendszerekben fontos biztonsági követelményt, hogy egy aláíró alkalmazás vizsgálja meg, hogy olyan dokumentumot kívánnak-e vele aláírni, amelynek a kezelésére fel van készítve. Itt ezt a feltételt már a rendszer tervezése során teljesíteni kellett. Ennyiben lényegileg eltérő a jelen alkalmazásrendszer egy általános célú aláíró alkalmazástól, hiszen itt a rendszer működtetőjének (nem csak az Igénybe vevőknek) nincs lehetősége sem arra, hogy eltérő adattípusok feldolgozását kísérelje meg a rendszer keretein belül. Ehhez a teljes folyamatvezérlést kellene átalakítani, ami egyrészt igen nagy munkaigényű, másrészt a rendszer sokszoros, nem minden esetben teljes mértékben dokumentált összefüggései miatt igen komoly kockázatú lépés lenne. Nem véletlen, hogy ennél kisebb léptékű változások végig vitele a rendszeren is igen komoly felkészülést igényel. A bélyegzők készítése minden esetben kifejezetten az adott célra, az adott folyamat eredményének fogadására készült cél-alkalmazásokban történik, és az aláírás kiváltását megelőzően ahogy azt már korábban jeleztük sehol nincs közbeavatkozási, módosítási lehetőség. Így az összes, a hagyományos aláíráskészítési alkalmazásoknál szükséges biztonsági elem, amelyek az aláírandó dokumentum és az aláíró alkalmazás közötti képesség béli összhangot hivatott biztosítani itt szükségtelen, hiszen ez nem egy általános célú alkalmazás, és a hagyományos értelemben vett felhasználói felület sem értelmezhető. 101

102 A rendszer által a folyamategyes állomásairól kiadott igazolások és az iratérvényességi nyilvántartással való kapcsolat esetében nem szükséges foglalkozni a megjelenítés során esetlegesen fellépő torzulásokkal sem, hiszen csak a papíralapú dokumentumról hiteles elektronikus másolatkészítés KEÜSZ esetében kerül megjelenítésre az aláírandó dokumentum. Ebben az esetben a rendszer üzemszerű működése során kizárólag az adott folyamatláncba beépített állományformátumokat képes előállítani, ennek megfelelően a megjelenítéssel, hozzáféréssel itt is csak a rendszer üzemképtelensége esetén lehet gond, ami viszont kívül esik az üzemszerű működés állapotán. Azaz a rendszernek magának kell garantálnia, hogy az összes aláírandó információ rendelkezésre álljon, a másolatkészítésért felelős személy csak ellenőrizni köteles, hogy minden ténylegesen rendelkezésre áll-e és ha nem, akkor csak megismételheti a másolatkészítés folyamatát. Ugyanezt teheti a supervisor is, ha valamiért eltér a megítélése a másolatkészítőétől. Maga a megtekintés, vizuális ellenőrzés az alapfolyamat jogszabályok által is megkövetelt eleme, ennek megfelelően elmaradását a rendszer kizárja, mindenképpen megmutatja az aláírandó adatokat. (A figyelmetlen munkavégzést azonban ez a rendszer sem tudja sem kiszűrni, sem kompenzálni, de rossz esetben a felvételek alapján utólag is igazolható). Valamennyi a rendszer által utóbb elektronikus bélyegzővel ellátott dokumentum a rendszeren belül keletkezik, így nem fordul elő olyan eset, hogy előzetesen elhelyezett aláírást, bélyegzőt vagy időbélyegzőt kellene az aláírást megelőzően vizsgálni az aláírás-készítés folyamatában, így erre a rendszert nem szükséges felkészíteni. A rendszeren belül az aláíró alkalmazás és az aláírandó dokumentum összhangja minden üzemszerű alkalmazási esetben biztosított Az aláírás attribútumai Egy elektronikusa aláírási folyamat során természetes elvárás, hogy miután kiválasztotta és leellenőrizte az aláírandó dokumentumot, az aláíró arról is meg tudjon győződni arról, mely adattartalmú tanúsítvány alapján milyen adatai jelennek meg az aláírásban. E szolgáltatás vonatkozásában azonban ez a megközelítés nem szükséges és nem is működőképes. Nem szükséges, mivel minden elektronikus bélyegzőt generáló rendszer a saját hatókörében egy és csak egy tanúsítvánnyal ír alá az adott folyamatban, azt nem indokolt az eredeti beállításon túlmentően kiválasztani. Természetesen arra vonatkozóan szükségesek garanciák, hogy egyrészt arra nem jogosult ne tudja megváltoztatni ezt a bélyegzőt, másrészt az arra jogosultak is csak megfelelő kontroll mellett tehessék ezt, hogy kizárható legyen egy nem megfelelő tanúsítvánnyal történő aláírás. Ezzel együtt a rendszer azt is automatikusan biztosítja, hogy lejárt tanúsítvánnyal ne lehessen bélyegzőt elhelyezni. 102

103 A rendszerben az aláíró tanúsítványok biztonságos kezelésére a magas sebesség és rendelkezésre állás érdekében egy kettős hardveres biztonsági modul szolgál az elektronikus bélyegzők generálására. Ebben aláírást elhelyezni, illetve az aláíró egység és az azt meghívó rendszer kapcsolatát megváltoztatni csak speciális biztonsági intézkedések mellett lehet, ezért nagy biztonsággal kijelenthető, hogy a kezdeti helyes beállítást követően kizárólag a tanúsítvány lejáratakor kell újra odafigyelni a rendszerre (illetve, ha magában a rendszerben történik hiba, de azt meg a monitoring és naplózó rendszerek fogják nagy biztonsággal jelezni). Az előző fejezetben is már említett módon a rendszer megkívánt teljesítménye teljesen illuzórikussá tenné az egyenkénti ellenőrzést, hiszen a rendszer jelenleg nem teljes kihasználtság mellett több száz bélyegzőt helyez el percenként. A bélyegző tanúsítványokban feltüntetett attribútumok forrása kettős. Az eidas rendelet a nemzeti jogszabályokra bízza, hogy az azonosítást, illetve az egyes egyedi jellemzők ellenőrzését hogyan kell végezni és az E-ügyintézési törvény is csak azon a szinten kezeli a kérdést, hogy az adatokat közhiteles nyilvántartások vagy közokiratok alapján kell rögzíteni. A regisztrációval, a rögzített adatokkal kapcsolatos szabályokat az e-aláírási kormányrendelet tartalmazza, mely rögzíti a regisztrálandó adatokat az e-ügyintézésre felhasználható tanúsítványoknál. A hitelesítés-szolgáltatók esetünkben a NISZ Zrt. a fenti rendelettel és a vonatkozó szabványokban megfogalmazott legjobb gyakorlattal összhangban Általános szerződési feltételeikben és az adott tanúsítványtípushoz kiadott bizalmi szolgáltatási rendben rögzítik, hogy milyen adatokat rögzítenek a tanúsítvány egyes mezőiben. Mivel bélyegzőket elhelyező szolgáltató maga is elektronikus ügyintézési szolgáltató, így a fenti követelményeknek megfelelő tanúsítványt kell használnia, annak adattartalmára nincs ráhatása, azt tényként kell kezelnie. A jogszabályokon túlmutató követelményt az általa használt tanúsítvánnyal szemben nem támaszthat. A szabványok és a korábbi gyakorlat is az aláírásban feltüntetett attribútumok meghatározására vonatkozóan tartalmaz még egy elvi lehetőséget, az aláírásokkal alkalmazott aláírási rend is tartalmazhatna olyan, az aláírásba foglalható attribútumokat, amelyek bizonyos feltételek mellett még géppel is értelmezhetőek lennének. Ez a megoldás a gyakorlatban okozhat nehézséget az aláírások értelmezésénél, az adott esetben azonban van súlyosabb problémája is. Felhatalmazás hiányában a Szolgáltató nem jogosult semmiféle további korlátozás előírására. Egyes országok egyébként tételesen is tiltják az ilyen adatok rögzítését az aláírásban, ezért interoperabilitási okokból sem támogatott ez a megoldás. Ennek a megoldásnak kisebb méretű, magánjogi megállapodáson épülő elfogadói közösségekben van létjogosultsága. Ezzel összhangban a szabvány is csak opcionális lehetőségként kezeli. A rendszerben nem kerül alkalmazásra saját aláírási rend, implicit a jogszabályokban meghatározott aláírási rend érvényes, ez kerül feltüntetésre is. 103

104 Az időzítés és a sorrend kikényszerítése Alapvető biztonsági követelmény a hagyományos aláíró alkalmazások esetén, hogy az aláírási folyamat csak akkor indulhat, ha az aláíró már döntött az aláírás létrehozásáról. Nem fordulhat elő, hogy az azonosított aláíró döntése nélkül történjen aláírás. E rendszer esetén a helyzet lényegileg más, hiszen a rendszer a feladatából következően automatizáltan generálja a bizonyítékokat és az iratérvényességi nyilvántartásba elhelyezendő adatcsomagokat, azaz magukat az aláírandó tartalmakat. Ha azok tartalmát nem képes ember érdemben befolyásolni, márpedig ezt a rendszer zártságából következő alapvető követelmény, akkor azokat automatizáltan kell aláírni is, minél kevesebb idővel az után, hogy az adattartalom előállt. A rendszer annyiban specializált, hogy a bizonyítékok adattartalmát, a küldemények és másolatkészítés folyamatai alapján, elkülönült alkalmazások állítják elő. Egy külön alkalmazás hivatott a bizonyítékok generálására az előállított adatokból, illetve egy másik tartja a kapcsolatot az iratérvényességi nyilvántartással. Mind a két folyamat indítása csak akkor tud megtörténni, amikor a szükséges adatok már maradéktalanul rendelkezésre állnak. Hiányos adatcsomag generálását a rendszer nem teszi lehetővé. Hasonló a helyzet a papíralapú eredetiről hiteles elektronikus másolatkészítés KEÜSZ esetében is, azzal a különbséggel, hogy itt is a rendszer ellenőrzi, hogy valamennyi a másolathoz csatolandó adat előállt- e már, és csak ez után jelenik meg a teljes csomag mind a másolatkészítő operátor, mind a supervisor előtt jóváhagyásra. Itt azonban van egy olyan ellenőrzési szempont, amit nem lehet automatizálni egyrészt technológia oldalról, másrészt a jogszabályi előírás is kizárja. Ebben az esetben a döntés tehát nem automatikus, a supervisornak egyedileg kell döntenie minden egyes küldemény elektronikus bélyegzővel történő ellátásáról. Ez a döntése sem terjed, terjedhet ki a rendszer szabályaiból következően arra, hogy milyen bélyegzővel történik a dokumentum hitelesítése, a jogszabály és az ÁSZF is rögzíti, hogy a Szolgáltató bélyegzőjével kell ellátni a másolatot. A bélyegző készítéséhez szükséges tanúsítványt az üzemeltetőknek kell a supervisortól, illetve operátortól függetlenül beállítaniuk. A rendszer zártságát sértené, ha a supervisornak itt döntési lehetősége lenne. A rendszer minden esetben független minősített szolgáltató által kibocsátott időbélyeget is elhelyez az elkészült bélyegzőkön. Ezek készítésének indítása is zárt folyamatban, automatizáltan történik, amint az aláírás elkészült, még ugyanaz az alkalmazás feladja az időbélyeg kérést, és addig nem is lép ki a dokumentum az alkalmazásból, amíg az időbélyegző rá nem került a dokumentumra vagy adatcsomagra. Ez esetenként az időbélyeg szolgáltatás rendelkezésre állása, vagy a hálózati kapcsolat miatt fennakadást is okozhat, azonban az időbélyeg elhelyezésének 104

105 késése a hitelességet semmilyen esetben nem érinti. Addig az igazolás vagy a bejegyzési kérelem, illetve a másolat nem kerül ki a rendszerből, amíg az időbélyeg el nem készült. Ez csak annyit jelenthet, hogy az aláírásban elhelyezkedő, a belső órán alapuló időadat korábbi lesz, mint az időbélyeg. (a bizonyító erő ebben az esetben is az időbélyegben rögzített időponttal kezdődik) Az aláírás kiváltása Ahogy azt már korábban jeleztük, az esetek túlnyomó részében automatizáltan történik a bélyegző készítés kiváltása. Az igazolások elkészítésénél és az iratérvényességi nyilvántartással történő kommunikációnál ugyanis emberi beavatkozással az itt megkövetelt teljesítményszint már nem biztosítható, ilyen mennyiségű dokumentum adatfeldolgozását csak automatizáltan lehet biztosítani. 19. ábra: Az aláírási folyamat az EN szabvány alapján Ennek megfelelően arra kellett törekedni, hogy maga a bélyegzőkkel tanúsítandó adattartalom meghatározása történjen megfelelő biztonsággal és ebben az esetben 105

106 a bélyegzők automatizált elhelyezése nem hordoz érdemi kockázatot, illetve a jogszabály is egyértelműen a Szolgáltató, és nem a szolgáltatásban esetleg közreműködő személy felelősségéről beszél. E követelmény teljesítését szolgálja az igazolásokat előállító alrendszer zártsága, emberi befolyás lehetőségétől való mentessége. Az egyetlen olyan folyamatban, ahol az elektronikus bélyegző létrehozásáról érdemben az operátor, illetve a supervisor dönt a papíralapú eredetiről hiteles elektronikus másolatok készítésekor -, kizárólag egy igen-nem döntéssel, egyetlen művelettel jóvá kell hagyniuk a másolat megfelelő voltát. Itt sem alkalmazza a rendszer hagyományos aláírásoknál megkövetelt aláíró azonosítását, hiszen nincs aláíró, a bélyegző létrehozója a rendszer és a mögöttes felelősség e Szolgáltatóé (a feladatot végző munkavállaló ugyan azonosítható, azonban az ő felelőssége munkajogi nem ő az aláíró). Ha itt további manuális műveletet követelnénk meg, az tovább lassítaná az amúgy is rendkívül humánerőforrás-igényes folyamatot, anélkül, hogy a biztonságon, hitelességen bármit javítana. A bélyegző elhelyezését követően is van ugyanakkor lehetőség arra, hogy a kiküldés előtt a supervisor megállítsa a folyamatot, és azt, akár teljes egészében, megismételjék. A teljes folyamat szigorúan ellenőrzött (folyamatos video felügyelet, képrögzítés alatt álló) területen, a területre történő belépést azonosítva, naplózva történik, így szükség esetén a felvétel alapján utólag is kontrollálható bármely téves lépés. Ehhez képest további egy olyan azonosítási művelet megkövetelése, amely nem is a bélyegző létrehozójára vonatkozik, már nem növelné a biztonságot Kriptográfiai algoritmus választása Sem jogszabály sem az ÁSZF nem tartalmaz az általános gyakorlattól eltérő követelményeket az alkalmazandó kriptográfiai algoritmusra vonatkozóan. Így a korlátot szabályozási oldalról a Nemzeti Média és Hírközlési hatóság mindenkori határozata jelenti a használható algoritmusokra, illetve azon belül a használható minimális kulcshosszakra vonatkozóan. A gyakorlati korlát pedig az, hogy a jogszabály szerint a Szolgáltató a NISZ által kibocsátott tanúsítványok felhasználására kötelezett. A előbb említett határozatnak értelemszerűen a NISZ-nek is meg kell felelnie. Ennek megfelelően a gyakorlati korlát a NISZ szolgáltatásának technikai szintje. A rendszer a saját maga által előállított dokumentumok bélyegzésére kizárólag az SHA256 RSA2048 algoritmus párt használja. A két elem meghatározottsága különböző. A hitelesítés-szolgáltató, a NISZ GOV CA-ja kizárólag RSA 2048 algoritmusú kulcsokat bocsát ki, így aláírásra mást, mint az RSA 2048-at algoritmust értelemszerűen nem használhat a rendszer. A lenyomatképző függvény esetében pedig a legáltalánosabb gyakorlatot követi a rendszer. Az általánosan elfogadott értékelés szerint az SHA 256 lenyomatok megtörésének lehetősége még kellően távol van, ugyanakkor nincs indokoltsága a 106

107 hosszabb lenyomatok használatának, mivel az a termelést és a kommunikációt is szükségtelenül lassítaná. Így ez az algoritmus jelenleg optimálisnak látszik. A lenyomatképzés oldalán rendszer ugyanakkor fel van készítve az SHA 2 függvénycsalád más elemeinek alkalmazására is, amennyiben akár aláírásban, akár a kézbesítési utasításban használni kívánja valamely Igénybe vevő. (A nemrég bevezetett SHA-3 algoritmuscsalád használata még nem biztosított) A rendszer a szerződés szerint az ETSI TS V1.2.1 ( ) műszaki előírásban alkalmazhatónak jelölt összes aláírási algoritmus érvényességének vizsgálatát el tudja végezni, amennyiben az azokat kibocsátó CA szerepel az ETSI TS V2.2.1 ( ) műszaki előírásban meghatározott valamelyik nemzeti bizalmi listán. Ennek ellenőrzése megfelelő teszt-aláírások hiányában lényegében csak a hazai CA-k vonatkozásában történt meg, itt valamennyi elektronikus ügyintézésre felhasználható aláírást korrekten kezel a rendszer. Ebbe a felsorolásba értelemszerűen bele tartozik a hazai e-személyivel készített aláírás is, mivel annak paraméterei megegyeznek a NISZ többi minősített CA-ja által kiadott aláíráséval Az aláíró azonosítása és a hozzáférés ellenőrzése Amint azt korábban már részletesen bemutattuk, a rendszer az automatikus bélyegző elhelyezés során önmagában nem használ kifejezetten a tanúsítványhoz, illetve a bélyegző elhelyezési folyamathoz kapcsolt azonosítást, hiszen az nem is lenne értelmezhető az alapvető feltételek hiányában. Az alapvető különbség a bélyegző és az elektronikus aláírás vonatkozásában éppen ebben nyilvánul meg. Míg az aláírás esetében az biztonságos vagy az újabb, pontosabb terminológia szerint minősített aláíró eszköz aktivitásának kiváltásához elengedhetetlen az aláíró személyének közreműködése, addig ez a folyamat a bélyegző elhelyezése során nem értelmezhető. Az eidas szabályozás ennek megfelelően külön fogalmat vezet be, a bélyegző létrehozóját, amivel (hiszen ez definíciószerűen egy jogi személy nem természetes személy) értelemszerűen sehol nem kapcsol össze azonosítási kötelezettséget, hiszen az már a tanúsítvány létrehozása során megtörtént. Az eidas rendelet ezt a fokozott biztonságú bélyegző definíciójában is rögzíti, (36. cikk a) pont) ahogy az kizárólag a bélyegző létrehozójához kötött. Ennek tükrében jogi szempontból teljesen irreleváns lenne a bélyegző elhelyezését esetleg felügyelő személy azonosításának a megkövetelése. Az már a jogi személy saját, az elektronikus bélyegző elhelyezési folyamatától független feladata, jól felfogott érdeke, hogy a saját eszközeivel biztosítsa, hogy a képviseletében kik, milyen eljárási és egyéb biztosítékok alapján járhatnak el az elektronikus bélyegzőt használva. Természetesen a szolgáltató itt is a jó gazda gondosságával jár el, a rendszerhez és annak részeként a bélyegzőket elhelyező folyamatokhoz is kizárólag azonosított felhasználók férhetnek hozzá, amelynek feltételrendszerét a fejezetben a hozzáférés-védelem kérdéseinél tárgyaltuk. 107

108 A rendszer kialakítása során az aláíró tanúsítványok magas biztonságú hardveres biztonsági modulban kerülnek elhelyezésre, ahol magának a kulcsnak az elhelyezése két személy együttműködését követeli meg, tehát a bélyegzők manipulálásának lehetősége ebből a szempontból gyakorlatilag kizárt. A rendszer működtetésében részt vevő operátorok pedig egyáltalán nem férnek hozzá ezekhez a beálltásokhoz. A papíralapú eredetiről hiteles elektronikus másolat készítése (inverz hibrid) KEÜSZ esetében, ahol a másolat elkészítését és operátor általi ellenőrzését követően a supervisornak az egyetértése is szükséges a bélyegző elhelyezéséhez, a teljes folyamat szigorúan ellenőrzött körülmények között történik. Magába a feldolgozó helységbe csak kártyás, személyre szóló azonosítással lehet belépni, amelyet a rendszer naplóz. Az alkalmazásba külön be kell jelentkezni és a teljes helyiség folyamatos video-megfigyelés alatt áll. Így szükség esetén bármely operátori cselekvés utólag is kontrollálható a jogszabályok által lehetővé tett eléggé szűkös megőrzési időn belül. A felvételek adatvédelmi okokból a személy- és vagyonvédelmi, valamint a magánnyomozói tevékenység szabályairól szóló évi CXXXIII. törvény 31. (2) bekezdésével összhangban csak 3 munkanapig kezelhetők, amennyiben nincs olyan esemény, amely a bíróság, vagy más erre jogosult hatóság intézkedését teszi szükségessé. Ezt követően azokat törölni kell. A felvételekhez kizárólag a Posta biztonságáért felelős szakterületének erre feljogosított munkatársai férhetnek hozzá. Amennyiben az Igénybe vevő vélelmezi, hogy olyan esemény történt, amelynek bíróság vagy más erre jogosult hatóság általi elbírálásához a felvételek megőrzése szükséges, a fenti törvény 31. (6) bekezdése alapján értelemszerűen ezen időn belül kérheti a megsemmisítés mellőzését 30 napra. Ez alatt meg kell szereznie az erre jogosult szerv döntését a felvételek további sorsáról. Ennek hiányában a törlést a határidő lejártakor meg kell valósítani Az aláírandó adatok összeállítása Az alap aláírások szerkezetének vannak közös vonásai. Ezeket minden aláírásnál érvényesíteni kell. Egy legalább fokozott biztonságú alap szintű aláírás szerkezetét az alábbi elemek jellemzik sematikusan az EN szabvány alapján. 20. ábra: legalább fokozott biztonságú aláírás szerkezete az EN szabvány alapján 108

109 Egy aláírás elkészítéséhez a következő bementő adattípusokra lehet szükség A bemenő adattípus Az aláírandó dokumentum vagy az aláírandó dokumentum leképezése Aláíró tanúsítvány Egyéb aláírás tulajdonságok Aláírási szabályzat Az aláírás időpontja Jellege Kötelező Kötelező Opcionális Opcionális 11. táblázat: Egy legalább fokozott biztonságú aláírás bemenő adatai az EN szabvány szerint Az aláírási időponttal kapcsolatban fontos tudni, hogy azt szokás szerint feltüntetik a az aláírásban, azonban ennek az a feltétele, hogy elégséges pontossággal álljon rendelkezésre. Nem lehet valódi bementő adatként kezelni, hiszen nem adhatja meg az aláíró tetszőlegesen. A bemenő adatokból az aláírás előkészítése során a fentieknek megfelelően három adatcsoport áll össze ebben a lépésben. A ténylegesen az aláíráshoz tartozó elemeket az ábrán kék szín jelöli. Az első maga az aláírandó dokumentum vagy annak a megfelelő leképezése. A leképezés itt jelenthet különböző szabványos kanonizációs módszereket és lenyomatképzést. Az aláírt tulajdonságok között egy elem alapvető fontosságú, ez az aláíró tanúsítvány, mivel, ha ez nem kerül be az aláírt attribútumok közé, akkor a tanúsítvány kicserélése, illetve a tanúsítvány újrakiadása elleni védelem hiányozna, ez pedig az alap aláírás követelménye. Az aláírás időpontja is, amennyiben feltüntetésre kerül, mindenképpen csak az aláírt attribútumok között szerepelhet. Esetünkben a teljes rendszeren belül az egységes, NTP alapú időszinkronizálás biztosított, így a rendszerek összehangolása teljes értékű. Ugyanakkor magának az NTP hálózatnak a szokásos (legjobb gyakorlat szerinti) pontossága elegendő, hiszen minden aláírást független minősített időbélyeg-szolgáltató lát el időbélyeggel még az aláírási folyamat részeként, tehát az aláírás mindenképpen fog tartalmazni egy hiteles időpontot. Az aláírt attribútumok között kell szerepeltetni az aláírási szabályzat azonosítóját is, amennyiben ilyen van. Esetünkben azonban aláírási szabályzat kiadására nincs lehetőség, de szükség sem. Az aláírással kapcsolatos követelményeket teljes körűen jogszabályok rendezik. (az eidas rendelettől az e-aláírási rendeletig bezárólag) Ennek megfelelően a Szolgáltató az e-ügyintézési Vhr.-ben az aláírásokkal, bélyegzőkkel kapcsolatos kérdések szabályozására nem kapott lehetőséget az Általános szerződési feltételek részeként. Egy ilyen szabályozás csak abban az esetben rendelkezik létjogosultsággal, de ott igen hasznos és célszerű ha a használói kör önkéntesen fogadta el az adott szabályokat, vagy pedig jogszabály hatalmazta fel a szabályzat kibocsátóját a kérdés 109

110 szabályozására. Ez utóbbi egyébként elvileg erősen aggályos lenne, hiszen jogszabálynál alacsonyabb szinten nem lehet állampolgárok jogait és kötelezettségeit átfogóan szabályozni. Ez a szolgáltatás elfogadása viszont általánosan kötelező. Ennek megfelelően az aláírási szabályzatra vonatkozóan valamennyi a Szolgáltató által kiadott elektronikus bélyegzőben indirekt aláírási szabályzatot tüntet fel. Ez azt jelenti, hogy az aláírási szabályzaton kívül szabályok határozzák meg az aláírás jogi kezelésével kapcsolatos lehetőségeket és feladatokat. Ezekről részletesen a fejezetben található részletesebb leírás. Az alá nem írt attribútumok használatára a leginkább ismert példa az 1.7 verziójú PDF (az ISO szabvány szerinti) állományokban általánosan alkalmazott korrektúrázási és kommentelési lehetőség. Itt az állományok annak ellenére is megőrzik aláírt voltukat, ha azokat az olvasójuk kommentekkel, korrektúrákkal, kiemelésekkel láthatja el. Ezek az információk kerülnek az alá nem írt attribútumok közé. Ezzel szemben az 1.4 verziójú archiválásra szánt PDF/A (ISO szabvány szerinti) állományokban nincs ilyen lehetőség. Az itt szereplő adatok kezeléséhez alkalmazott lenyomatképzési és aláírási algoritmusok köréről a fejezet ad tájékoztatást Az aláírandó adatok megjelenítése Egy elektronikus aláírás elkészítése során fontos garanciális elem, hogy az aláíró az adott rendszerben választható vagy érvényes aláírási szabályokkal összhangban meghatározhassa, hogy mit kíván aláírni, és az aláíró rendszer mutassa is be számára, hogy mit fog aláírni. Ahogy azt az előző fejezetben már levezettük, a rendszer minden esetben implicit, jogszabályok által meghatározott aláírási szabályzattal dolgozik, ennek megfelelően magába a folyamatba kellett beépíteni mindazokat az elemeket, amelyeket az aktuális jogszabályok megkövetelnek. Ez egyben kockázatot is jelent, hiszen jogszabályi változások esetén nincs lehetőség arra, hogy egyszerűen, a szabályzati paraméterek megváltoztatásával lehessen alkalmazkodni a változó követelményekhez. Azokban az esetekben, ahol az elektronikus dokumentumok (a rendszer által kibocsátott igazolások, az iratérvényességi nyilvántartásnak átadott adatcsomagok) előállítására automatikusan kerül sor, ott ezt a megfelelő szerkezetű, adattartalmú aláírandó dokumentum előállításának feladatát teljes mértékben be kellett programozni a rendszerbe. Ezt követően igen nagy számú teszttel kellett meggyőződni arról, hogy a rendszer valóban az elvárt módon viselkedik, megbízhatóan állítja elő az igazolásokat és tárolja el azokat, illetve az egyéb jogi szempontból lényeges naplózási adatokat a nagy megbízhatóság tároló rendszerbe. Ez a rendszer létrehozása és tesztüzeme során meg is valósult, ma már kellő biztonsággal állíthatjuk, hogy a rendszer az emberi teljesítménynél nagyobb 110

111 megbízhatósággal és nagyságrendekkel nagyobb teljesítménnyel képes előállítani az igazolásokat. Mivel a dokumentumokon elektronikus bélyegző kerül elhelyezésre, itt az aláíró amúgy sem értelmezhető, tehát az aláírói ellenőrzésre vonatkozó igény sem. Természetesen itt is törekedni kell a lehető legnagyobb megbízhatóságra, azonban az igazolásokat előállító feldolgozási folyamatban a hagyományos kiválasztás és ellenőrzés nem megvalósítható, hiszen maguk az igazolásokban megjelenítendő adatok is elektronikus folyamat során jönnek létre, azok tartalmát sem tudja önmagában az operátor érdemben ellenőrizni, és az előállítás üzeme sem teszi lehetővé a manuális beavatkozást. Az igazolások előállítása során éppen a biztonság érdekében minden érdemi adat kettősen kerül az aláírt dokumentumba, Egyrészt szerepel a szokásos olvasható formában egy PDF formátumú elektronikus űrlapon, másrészt egy beágyazott és a dokumentum többi részével együtt aláírt XML dokumentumban elsődlegesen gépi feldolgozás céljára, de kellő gyakorlattal ebből is lehet utólag ellenőrizni a megjelenített adatokat. Az egyetlen olyan folyamat, ahol az aláírandó dokumentum megjelenítése jogszabályi követelmény, a papíralapú dokumentumról elektronikus hiteles másolat készítése (inverz hibrid) KEÜSZ. Ebben az esetben a rendszer értelemszerűen biztosítja mind az elkészült szkennelt állományok, mind a hozzá csatolt XML állományok megtekintésének lehetőségét, ami alapján akár az operátor, akár az ő munkájának felülvizsgálatára jogosult supervisor dönthet úgy, hogy az elkészült másolat ne kerüljön aláírásra. Ha a hiba javítható, akkor ismételten elő lehet állítani az elektronikus másolatot, illetve a hozzá kapcsolódó leíró állományokat, ha viszont az előzetes vizsgálat ellenére itt derül ki, hogy nem lehet bármilyen okból hiteles másolatot készíteni az adott papíralapú dokumentum-együttesről, akkor még ebben a fázisban is meg lehet állítani a másolatkészítést és az eredetit eljuttatni az Igénybe vevőhöz. Ugyanakkor ebben a folyamatban is teljes értékben előzetesen az adott feldolgozási folyamat megindításakor már meghatározott, hogy mely adattípusokból, illetve adatelemekből fog állani az adott aláírandó állomány, tehát itt is lényegében beégetett aláírási szabályzattal dolgozik a rendszer. Ha egy új másolattípust kell megvalósítani, akkor a folyamattal együtt kerül rögzítésre az is mely adatok, hogyan kerülnek majd az aláírandó állományba. Itt különösen kell figyelni arra, hogy maguk az elektronikus másolatok adatvédelmi okból megsemmisítésre kerülnek, amikor az Igénybe vevő visszajelezte az általakított állomány vételét, ezért különösen fontos, hogy megfelelő adatok maradjanak a Szolgáltató birtokában egy vita kezeléséhez Az aláíró eszköz menedzsmentje Egy általános célú aláíró alkalmazásnál értelemszerűen követelmény, hogy az alkalmazás legyen képes értelmezni amennyiben ilyen létezik az aláírási szabályzat követelményeit, és annak megfelelően válassza meg, hogy milyen 111

112 aláírást hoz létre. Ennek része például az is, hogy csak minősített aláíró eszköz esetén megengedett, hogy az egy minősített tanúsítvány használatával minősített aláírást készítsen. Azaz mind az aláíró eszközre, mind a tanúsítványra vonatkozóan magának az aláírást készítő eszköznek kell tudnia ellenőrizni a megfelelő minősítési attribútumokat. A mi esetünkben azonban a helyzet lényegileg más. Itt ugyanis kifejezetten adott funkciók megvalósítására szolgáló célalkalmazásokról van szó, amelyek nem általánosan hivatottak aláírások készítésére, hanem meghatározott automatizált folyamat végtermékét (és csak azt) látják el elektronikus bélyegzővel. Külön célalkalmazás szolgálja a szolgáltató által a kézbesítési eseményekről kiadott igazolások bélyegzővel történő ellátását, külön alkalmazás szolgál az iratérvényességi nyilvántartásba küldendő adatcsomagok bélyegzésére, és külön alkalmazás szolgálja a hiteles elektronikus másolatok lebélyegzését. Minden esetben pontosan előzetesen meghatározott feltételrendszert kel az adott célalkalmazásnak kiszolgálnia. Itt tehát a megfelelőség annyiban merül fel, hogy a rendszert eredetileg az elvárt követelményeknek megfelelően kell beállítani és garantálni, hogy nem jogosult személyek ne legyenek képesek ezeket a beállításokat megváltoztatni. Esetünkben ez több oldalról is biztosított. A munkamegosztás szempontjából alapként biztosított, hogy az operátorok ezen szolgáltatások beállításaihoz egyáltalán nem férnek hozzá, tehát számukra a beállítás egy adottság. A rendszer beállításait csak kis számú és pontosan meghatározott szerepkörű üzemeltető lehet képes módosítani, de itt alapkövetelmény, hogy egy személy önmagában ne tudjon a beállításokon változtatni. Maga a bélyegző alkalmazás, az bélyegző tanúsítványokat tárolni és a bélyegzőket elkészíteni hivatott párba kapcsolt két LUNA 1700 SA hardveres biztonsági modul rendelkezik a minősített aláírások készítéséhez szükséges CC szerinti EAL 4+ tanúsítvánnyal (Certification Report number NSCIB-CC CR a CR-3524 REV 18, MAY 30TH 2017 azonosítójú security target figyelembe vételével). A bélyegzőket készítő hardveres biztonsági modulok (HSM) megfelelően védett környezetben vannak elhelyezve, azokhoz kizárólag az egyébként is védett környezetbe belépő és megfelelő azonosító elemekkel ellátott üzemeltetők férhetnek hozzá. A HSM úgy van konfigurálva, hogy azon csak kiolvasási műveleteket lessen távolról végrehajtani, a bélyegzők készítésére szolgáló tanúsítványok telepítése csak a helyszínen történhet. Erről az oldalról tehát elvileg egy minősített bélyegző készítésének feltételrendszere is biztosítható. A másik oldalról a bélyegzők készítésére használt tanúsítványok minősített a Magyar Posta Zrt. mint jogi személy számára kiadott tanúsítványok, amelyeket a NISZ GOV CA-ja adott ki elektronikus ügyintézési célú felhasználásra. Így tehát a minősített bélyegző készítésének feltételét erről az oldalról is teljesíti a rendszer. 112

113 Mivel azonban a szabályozási és ellenőrzési környezet még nem érte el azt a szintet, amely alapján a Szolgáltató ma biztonsággal vállalhatónak látná a minősített bélyegzők tömeges kiadását, így az e-ügyintézési VHR követelményrendszerével összhangban jelenleg minősített tanúsítványon alapuló, fokozott biztonságú elektronikus bélyegzőket helyezünk el mind a kiadott igazolásokon, mind a papíralapú eredetikről készített hiteles elektronikus másolatokon, illetve az iratérvényességi nyilvántartás felé indított bejegyzési kéréseken. Valamennyi bélyegző ezen túlmenően a NISZ minősített időbélyegével is ellátásra kerül, így a dokumentumok változatlansága végül is ebben az esetben is minősített szinten igazolt. A következő időszak fontos fejlesztési célkitűzése annak biztosítása, hogy az eszköz oldali feltételek teljesítésén túlmenően szervezeti, adminisztratív biztonsági oldalról is garantálni lehessen a minősített bélyegzők üzemszerű kiadásához elvárt feltételrendszert Az aláíró eszköz és az aláíró alkalmazás közötti kommunikáció védelme Az általános célú aláíró alkalmazások esetében fontos követelmény, hogy az aláíró alkalmazás (környezet) és magát az aláírás készítését végző aláíró eszköz között a kommunikáció megfelelően védett legyen. Ez a szempont játszik szerepet abban is, hogy a komolyabb biztonsági igényű alkalmazásokban a kártyaolvasó eszközön magán helyeznek el klaviatúrát az azonosító kód közvetlen megadhatósága érdekében. A HKKR rendszerben előállított bélyegzők esetében a helyzet ettől annyiban tér el, hogy azok a választási lehetőségek, amelyek korrekt megválaszolása követelmény az aláíró interfésszel szemben, előzetesen a felhasználói programban rögzítettek, változtatásuk kizárólag a programozás, illetve a konfiguráció előzetes módosítása útján lehetséges. Mint azt az előző fejezetben már jeleztük a munkamegosztás az operátorok és az üzemeltetők között ilyen lépéséket az operátorok számára nem tesz lehetővé, és az üzemeltetőknél is követelmény a négy szem elv érvényesítése. A HSM ennek megfelelően különböző szerepkörű bejelentkezésekre fel van készítve. Mivel az aláírandó adatok előállítása és az elektronikus bélyegzők elhelyezése az esetek többségében a védett adatközpontot el nem hagyva történik, ezekben az esetekben elégséges védelmet biztosít a LUNA HSM modulok speciális Java alkalmazáskönyvtára, amely a Java nyelv már az 1.4 verziója óta beépített JCA/JCE kriptográfiai architektúráját terjeszti ki, hogy a programok a HSM-et úgy tudják használni, mint a JAVA kulcstároló állományát (JKS). Ez a LUNA JSP, amely az eszközökkel együtt került leszállításra. Két fontos kiterjesztő osztály implementál: com.safenetinc.luna.lunaslotmanager com.safenetinc.luna.provider.key.lunakey Ezek is úgy vannak azonban implementálva, hogy olyan érzékeny adatokat, amelyeket egy minősített aláíró alkalmazás nem tehet hozzáférhetővé, annak 113

114 ellenére sem engednek ki, hogy a JCA tartalmaz elvileg ezt lehetővé tevő parancsot. Ilyen esetben a rendszer kivételt dob. Ahol az aláírandó adatok előállításában az adatközpont mellett az üzemi területnek is szerepe van, ilyen az iratérvényességi nyilvántartás számára összeállított adatcsomag és a papír alapú eredetiről hiteles elektronikus másolat készítése (inverz hibrid) KEÜSZ ott a rendszer elemei közötti kommunikációt külön VPN-en biztosított TLS kapcsolat is védi. Ezzel biztosítható, hogy az aláírandó adatok változás nélkül kerüljenek a bélyegzőket elhelyező HSM modulokhoz, illetve az aláírt dokumentumok változatlanul kerülhessenek továbbításra a termelési folyamat következő állomására, illetve a kapcsolódó szolgáltatóhoz Tömeges aláírási műveletek Tömeges aláírás az általánosan elfogadott értelmében amely szerint egy iratkötegre generálnak egyetlen aláírást vagy bélyegzőt nincs használatban a rendszerben. Minden egyes dokumentum vagy egyenként, vagy előzetesen egy meghatározott hordozó dokumentumba beágyazva kerül aláírásra. A több oldalas papíralapú eredetikről először elkészül az egyesített dokumentum és a dokumentumba beágyazzák a leíró adatokat tartalmazó XML dokumentumot. Ezt követően az operátor tételes, illetve a supervisor szúrópróbaszerű ellenőrzése után kerül a teljes dokumentumcsomag egyben aláírásra. Az ÁSZF szerint részleges másolat készítése nem megengedett, így az operátoroknak csak abban lehet választásuk, hogy az egész dokumentum bélyegzővel való ellátását engedélyezik-e vagy sem, nem merülhet fel, hogy olyan dokumentum kerül a csomagba, amit a bélyegzési folyamatot elindító nem ismerhetett volna meg Aláírás érvényesítési folyamatok és rendszerek Amikor valaki döntést hoz egy elektronikusan aláírt dokumentum alapján, előtte ellenőriznie kell a dokumentumon az aláírást, illetve bélyegzőt. Az aláírás ellenőrzése, ha azt valaki megfelelő informatikai támogatás nélkül próbálja meg végig vinni, komoly kihívás, azonban az érvényesítési lépések többségét, illetve egyértelmű esetekben teljességét megfelelő számítógépes program támogatásával is el lehet végezni. A jelen dokumentum 1. sz. és 4. sz. melléklete bemutat két ilyen hazai elektronikus ügyintézési felhasználásra szánt ingyenes programot, de a hazai kereskedelmi hitelesítésszolgáltatók is rendelkeznek olyan díjtalanul hozzáférhető programokkal, amelyekkel ezt a feladatot meg lehet oldani. Az ezen eljárások hátterét adó, a 3. sz. mellékletben bemutatott DSS keretrendszer is tartalmaz aláírás-érvényesítést szolgáló programelemeket, amelyből az ebben érdekelt felhasználó felépítheti saját érvényesítő alkalmazását. Az 5. sz. mellékletben bemutatunk egy informatikai oldalról kevésbé támogatott, viszont széles ismeretek megszerzését lehetővé tevő 114

115 megoldást PDF formátumú dokumentumok érvényességének vizsgálatához az Acrobat Reader DC program támogatásával. Az aláírás érvényesítése egy több szempontot figyelembe vevő értékelési folyamat és egy aláírás csak akkor tekinthető érvényesnek, ha az ellenőrizendő szempontok összességének megfelelt. Mint azt a bevezetőben kifejtettük, az elektronikus ügyintézés követelményei miatt csak azokkal az aláírásokkal foglalkozunk ebben a részben is, amelyek a fokozott biztonságú aláírás követelményeinek megfelelnek és teljesítik a 2015/150 és 2015/1506 EU Bizottsági Végrehajtási határozatokban foglalt feltételrendszert. A magyar közigazgatás gyakorlatával összhangban A fenti feltételeknek eleget tevő aláírások, illetve bélyegzők közül a rendszer nem használja, és ennek megfelelően ellenőrizni sem képes a CAdES formátumú aláírásokat, illetve bélyegzőket és a feldolgozás problémái miatt jelenleg nem kezeli az ASiC formátumú konténereket sem. Ezek esetében tehát attól függetlenül, hogy egyébként egy formális ellenőrzés szerint megfelelnének, az aláíró értelmezhetetlen dokumentumra vonatkozó hibajelzést kap. A feldolgozható dokumentumformátumokat a fenti követelményekkel összhangban az ÁSZF is rögzítette. 21. ábra: Az aláírás érvényesítési folyamat az EN szabvány alapján Az aláírások és bélyegzők érvényesítésére vonatkozó jogi környezetet részletesebben az fejezetben tárgyaltuk, az ott levont következtetések és korlátok figyelembe vételével kell kezelni ezt a folyamatot, amely formailag komoly bizonytalanságokat hordozhat. 115

116 A feladat természetéből adódóan ezek a kockázatok szerencsére a valóságban kisebbek, hiszen az ellenérdekelt fél az esetek túlnyomó részében azonnal jelentkezik a panaszával, hogy miért nem fogadtunk el érvényesnek egy szerinte megfelelő aláírást, és akkor a panaszkezelésen keresztül ki lehet küszöbölni az ilyen problémákat, illetve ahol ilyen probléma nem áll fenn ott később is ugyanolyan biztonsággal el lehet végezni az aláírás ismételt vizsgálatát, érvényesítését A fő érvényesítési folyamatok Az aláírások, illetve bélyegzők ellenőrzését a rendszer a következő, logikailag elkülönülő esetekben végzi. 1) A megvalósított biztonságos kézbesítési szolgáltatás során követelmény, hogy a címzett, annak meghatalmazottja vagy az arra megbízott helyettes átvevő azonosítottan aláírásával igazoltan vegye át beleértve az AVDH használatával történő dokumentumhitelesítést is a neki címzett küldeményt. E feltétel teljesülésének ellenőrzéséhez az aláírt átvételi elismervényen szereplő aláírás érvényesítése elengedhetetlen. Ebben az esetben egy PDF formátumú megszemélyesített átvételi elismervény dokumentum aláírása az átvevő feladata. Ezt értelemszerűen PAdES formátumú, legalább fokozott biztonságú aláírással vagy bélyegzővel kell megvalósítani. Ennek érvényességét és annak alapján az átvevő jogosultságát ellenőrzi a rendszer. Amennyiben az aláírás, illetve a bélyegző önmagáról azt állítja (QC statement szerepel az aláírásban) hogy minősített, akkor el kell végezni rajta az eidas rendelet 32. cikke szerinti teljes ellenőrzési folyamatot. Az e célra használt aláírásokkal szemben csak akkor lehet érvényesíteni az az e- aláírási rendeletben rögzített követelményt, ha az átvevő elektronikus ügyintézési szolgáltató. Ebben az esetben az átvételre jogosító aláírás regisztrációja során kell ellenőrizni, hogy az aláírás tanúsítványa felülhitelesített-e a KGYHSZ által. (Ez tehát még az érvényesítést megelőzően meg kell történjen.) Más Igénybe vevők esetében a 2015/1505 és 2015/1506 EU Bizottsági végrehajtási határozatokban foglaltakat kell megkövetelni, azt kell ellenőrizni, hogy szerepel-e az aláírás, illetve bélyegző kibocsátó CA-ja a bizalmi listán, hiszen a címzettek jellemzően nem elektronikus ügyintézési szolgáltatók. Értelemszerűen vizsgálni kell azt is, hogy az aláírás időpontjában érvényes volt-e a tanúsítvány. Mivel az aláírandó dokumentumot a rendszer állította elő és az ellenőrzés az aláírás után ismét a rendszerben történik, csekély lehetőség van az aláírás időpontjának manipulálására, annak ellenére, hogy a jogszabályi követelményekkel összhangban nem követelmény időbélyeg használata. Értelemszerűen itt korábbi, már visszavont aláírások érvényességének vizsgálata nem kerülhet szóba Csak abban az esetben biztosít a rendszer hozzáférést az érkezett küldeményhez, ha érvényes és a követelményeknek megfelelő aláírással igazolták az átvételt. Ha nem átvételre jogosulttól származik az aláírás, illetve az aláírást vagy bélyegzőt nem 116

117 regisztrálták előzetesen, akkor a rendszer ismételten kiküldi az értesítést a küldemény érkezéséről. 2) Az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ megvalósítása során az átalakítás végrehajtását megalapozó információt az úgynevezett kézbesítési utasítás hordozza. Ezt minden esetben legalább fokozott biztonságú, elektronikus ügyintézésre alkalmas, az e-aláírási rendelet követelményeinek megfelelő aláírással vagy bélyegzővel ellátva kell eljuttatni, a feldolgozó hibrid konverziós rendszerhez. Az e-aláírási rendelet követelménye miatt itt a bizalmi listával nem kell foglalkozni, de amennyiben az aláírás tartalmaz a minősítettséget jelző QC statement-et, akkor az ellenőrzést itt is az eidas rendelet 32. cikke alapján kell elvégezni. Értelemszerűen itt is ellenőrizni kell mind az aláírás meglétét, mind a megfelelő minőségét, mind az érvényességét. A kézbesítési utasítás beküldésénél szintén nem követelmény az időbélyegzéssel való ellátás, hiszen itt az általános gyakorlat szerint a kézbesítési utasításon elhelyezett aláírás elkészültétől számított igen rövid idő alatt feldolgozásra kerül a kézbesítési utasítás. Így egyrészt csekély a valószínűsége az időközbeni visszavonásnak, másrészt az újabb visszavonási lista vagy akárcsak az OCSP ciklus késleltetésének bevárása a jogszabályi határidőn belül megvalósíthatatlanná tenné a másolatkészítési folyamatot. Itt tehát van bizonyos maradvány kockázat, de ennek valószínűsége nem nagyobb, mint az általános ügyintézői tévedésé, amit viszont a szolgáltató amúgy is kezel. A feladó a visszakapott feladási és gyártási igazolások nyomán az iratkezelés általános szabályai szerint amúgy is ellenőrizni köteles, hogy azt a küldeményt küldte-e ki, amit szándékozott. Végső esetben a postai kézbesítési folyamat során is van lehetőség a küldemény kiemelésére. Ebben a folyamatban az aláírásra való jogosultság vizsgálata nem szempont, mivel nem rögzített a szerződésekben, hogy kinek az aláírásával érkezhet a kézbesítési utasítás, csak a jogszabályi követelmények teljesülése, és ennek részeként a KGYHSZ általi felültanúsítás ellenőrizhető. Értelemszerűen ez esetben sem kell korábban érvényes, de már visszavont aláírások érvényességét vizsgálni. Érvénytelen vagy hiányzó, illetve elektronikus ügyintézés biztosítására nem alkalmas aláírás, illetve bélyegző esetén a konverzió kerül visszautasításra. A megrendelőnek ismételten, már megfelelő aláírással ellátva kell elküldenie az a kézbesítési utasítást és vele az átalakítandó dokumentumokat. Az aláírt kézbesítési utasítás archiválásra kerül, így utóbb a feladóvevényen amúgy is elhelyezett időbélyegzéssel szükség esetén bizonyítható a keletkezés hozzávetőleges időpontja. Mivel a kézbesítési utasítás egy XML állomány, az azon elhelyezett aláírás vagy bélyegző formátuma XAdES kell legyen. A rendszer mind az embedded, mind az enveloped formátumú XML aláírásokat kezeli, alkalmas a MELASZ 2.0 formátumú aláírások (lásd {Sz35}) és az es3 formátumú dossziék (lásd {Sz34}) értelmezésére is. 117

118 Ugyanakkor értelmezhetetlen a detached szerkezetű aláírás, hiszen az azt jelentené, hogy valahol külön kellene az összekapcsolási információt kezelni. 3) Amennyiben az Igénybe vevő az elektronikus irat hiteles papíralapú irattá alakítása KEÜSZ használatával kíván hiteles konverziót végrehajtani, és ennek megfelelően hiteles, azaz legalább fokozott biztonságú elektronikus aláírással vagy bélyegzővel ellátott elektronikus dokumentum hiteles papíralapú irattá alakítását igényli, akkor a Szolgáltató feladata a hitelesség szempontjából lényeges körülményeket rögzítő záradék előállítása. Ennek során a szolgáltatónak ez e-ügyintézési Vhr (5) bekezdésének megfelelően ellenőriznie kell a dokumentum változatlanságát, a tanúsítvány megfelelőségét és az aláírás időpontjára vonatkozó érvényességét, beleértve a teljes bizalmi láncot. Ebben az esetben valamennyi másolatkészítésre egyébként befogadott aláírt dokumentumformátumot kezelni kell. Itt mind PAdES, mind XAdES formátumú aláírások ellenőrzése támogatott, és nem csak a hazai szolgáltatók által kiadott tanúsítványok támogatását kell biztosítani, hanem az EU bizalmi listán szereplő szolgáltatók tanúsítványainak kezelését. Tekintve, hogy a bizalmi listák történeti adatokat is tartalmaznak, a már nem működő, illetve már nem felügyelt hitelesítés-szolgáltatók tanúsítványait szintén el kell fogadni, amennyiben egy aláírást olyan múltbeli időpontra nézve ellenőriz a Szolgáltató, amely időpontban a kérdéses szolgáltató még működött, illetve a lista alapján a tagállam felelősséget vállalt érte. Amennyiben a kézbesítési utasítás a dokumentumot aláírtnak jelezte és az aláírás ellenőrzésnél az derül ki, hogy a dokumentum megváltozott az aláírás óta vagy a tanúsítvány az aláírás időpontjában érvénytelen volt, a folyamat megszakad és az Igénybe vevő az elutasítás okát jelző hibaüzenettel egy nemleges hibrid igazolást kap vissza. Mivel a jogszabályok (az eidas rendelet és az e-ügyintézési Vhr. egyaránt) eltérést nem engedően az aláírás időpontjában való vizsgálatot írnak elő, ugyanakkor egyik sem írja elő az időbélyegzés kötelező voltát, így, amennyiben nincs időbélyegzés, az aláírásban jellemzően szereplő nem hiteles dátumot kell alapnak tekinteni. Ez természetesen hordoz bizonyos hibalehetőséget, de ezzel számolni kell Amennyiben az Igénybe vevő nem aláírtnak jelezte a küldeményt a kézbesítési utasításban, arról a fenti ellenőrzés nélkül is elkészülhet a hiteles másolat az iratérvényességi nyilvántartásba való elhelyezéssel, mivel az önmagában, az aláírás nélkül is igazolhatóvá teszi a hitelességet, a küldemény rendszeren belüli változatlanságát pedig a lenyomatok igazolják. 4) Ha az Igénybe vevő és a HKKR közötti kommunikáció a HKKR webautomata szolgáltatásával, webszervizek igénybe vételével történik, akkor minden az igénybe vevőtől a rendszer felé küldött SOAP üzenetet alá kell írni. Ez az aláírás biztosítja egyrészt az üzenet sértetlenségét, másrészt magának a küldő rendszernek a nagy megbízhatóságú azonosítását. Ez a megoldás a WS-SecurityPolicy 118

119 ( specifikáció egyik lehetséges megvalósítása. Ebben az esetben is elektronikus ügyintézésre alkalmas alapesetben értelemszerűen bélyegző előzetes regisztrálása a követelmény. Itt a sikertelen érvényesítés magának a kommunikációnak a létrejöttét akadályozza meg. Itt, mivel valós idejű kommunikációról van szó időbeliséget nem indokolt vizsgálni, de a tanúsítvány adott időpont béli érvényessége természetesen itt is követelmény Az érvényesítési eljárási szabályok végrehajtatása A HKKR-ben az elektronikus aláírások érvényesítése során használt szabályrendszer alapjaiban megfelel az EN szabványban leírt gyakorlatnak azzal, hogy a hatályos magyar szabályozás nem követeli meg egyetlen itt leírt használati esetben sem az időbélyegzés használatát. Ugyanakkor mind az eidas rendelet, mind az e-ügyintézési Vhr. azokban az esetekben, ahol egyáltalán foglalkozik a tanúsítványok időbeli érvényességének kérdésével, kizárólag az aláírás időpontjában való érvényességet követeli meg. Nem ad olyan értelmezésre lehetőséget, hogy pusztán az időbélyegzés hiánya vagy az időpont bizonytalansága miatt érvénytelennek lehessen tekinteni egy aláírást, vagy más időpontban kelljen a tanúsítvány érvényességét vizsgálni. Ennek megfelelően az érvényesség vizsgálata ebben az esetben az aláírásban általában rögzített időadatra (claimed time) támaszkodik. A HKKR, ahogy azt már a bélyegzők készítésére vonatkozó fejezetekben leírtuk, két széles körben alkalmazott szoftvercsomagot használ az aláírások, bélyegzők érvényesítése során is. A PAdES formátumú aláírásokat az itext szoftver használatával vizsgálja, míg a XAdES formátumú aláírások ellenőrzése sorén a DSS szoftver keretrendszer megfelelő elemeit veszi igénybe. amennyiben az érvényesítési folyamat nem meghatározható eredményt hoz, akkor ezeket a rendszer automatikusan a nem megfeleltek közé sorolja. A webszerviz útján történő kommunikációnál értelemszerűen egy, az előbbiektől eltérő célszoftver vizsgálja a küldött üzenetek megfelelő aláírását. ezt a feladatot az ORACLE IAG szoftvere végzi a megfelelő teljesítmény biztosíthatósága érdekében Az érvényesítési szabályzat Az aláírás érvényesítési feltételrendszerét az adott szolgáltatások vonatkozásában jogszabályok rögzítik, azoktól a Szolgáltató nem térhet el, ennek megfelelően önálló aláírás-érvényesítési szabályzatot sem jogosul készíteni, kizárólag azt rögzítheti, például ebben a dokumentumban is, hogy milyen eljárásokat követ az aláírások érvényesítése során a legjobb gyakorlatok alapján, összhangban a jogszabályokkal. Ez azonban nem érinthet semmiféle olyan felhasználói jogosultságot, amelyet jogszabályok kijelöltek. 119

120 Mint a dokumentum egésze, ez is csak tájékoztatás, amennyiben kiderülne, hogy a jogszabályoknak más, autentikus értelmezése létezik, a Szolgáltató ahhoz köteles alkalmazkodni, mint jogalkalmazó, nem alkothat önálló eljárásrendet. Ugyanezen okból a Szolgáltató nem vizsgálja az aláírásokban foglalt aláírási szabályzatokban foglalt korlátozásokat sem, hiszen a tagállamok azzal, hogy ezeket a szolgáltatókat az EU bizalmi listáján közzétették, jogi kötelezettséget vállaltak arra, hogy az általuk kibocsátott aláírások az eidas rendeletben foglalt követelményeknek megfelelően elektronikus ügyintézésre felhasználhatók. Ehhez képest a szolgáltatók ebben a vonatkozásban nem jogosultak korlátozásokat érvényesíteni az aláírásuk felhasználhatósága vonatkozásában. Ez természetesen nem érinti például az anyagi felelősség aláírási szabályzatban történő korlátozásának lehetőségét, de az ebben az összefüggésrendszerben nem játszhat szerepet Az érvényesítés felhasználói interfésze Az érvényesítés során nincs lehetőség felhasználói beavatkozásra. Az érvényesítést a rendszer teljes mértékben automatizáltan, zárt folyamatban végzi. Kizárólag az ellenőrzés eredményéről készült esetleges bizonyítékok, figyelmeztetések megismerhetők az operátorok által, de mivel azok a megismerés időpontjában már elektronikus bélyegzővel és időbélyeggel ellátott dokumentumok, amelyek akkor már nem változtathatók meg, az esetek túlnyomó részében már kiküldésre is kerültek. Ezzel a megközelítéssel a rendszer kizárja a szubjektív befolyásolás, az emberi tévedés lehetőségét. Természetesen ez a megoldás veszélyt is hordoz, elvileg nem zárható ki, hogy a rendszer hibás működése miatt téves információk kerüljenek az Igénybe vevőkhöz (akár címzetti, akár feladói oldalon). Ezeknek a kockázatoknak a csökkentésére a rendszer folyamatos felügyeletének kötelezettsége került beépítésre, operátori döntés nélkül a két konverziós szolgáltatásnál elkészült eredménytermékek nem kerülhetnek továbbításra, ezzel a kockázat mérsékelhető, de nem szüntethető meg. A biztonságos kézbesítési szolgáltatásnál az ügyfél érdekeltsége teremti meg a biztonsági kontrollt, hiszen, ha megalapozatlanul nem adja ki a küldeményt a rendszer, az minden bizonnyal reklamációt vált ki, és ha esetleg nem megfelelő aláírásra kerül kiadásra a küldemény, akkor a feladó fogja ezt kifogásolni, tehát a hibák nem maradhatnak fedettek, a rendszer működésével folyamatosan javítható a szolgáltatás minősége. Ugyanakkor egyéb ellenőrzés sértené a személyes adatok védelmének általános követelményét Az érvényesítés be-, illetve kimenetének megfelelősége Az aláírások érvényesítése, illetve ellenőrzése során a HKKR minden esetben automatizáltan jár el, nincs olyan eset, ahol operátori beavatkozásra, a konfigurációs paraméterek egyedi változtatására lenne szükség, avagy lehetőség. Mivel a tesztelés előzetesen, illetve a szolgáltatás működése során már igen nagy számú esetre szisztematikusan kialakított tesztesetekkel lezajlott, kellően nagy 120

121 bizonyossággal állítható, hogy az aláírások, illetve bélyegzők érvényesítéséhez a rendszer megfelelő adatokat bocsát rendelkezésre. Az ellenőrzés terjedelmére vonatkozóan két esetet kell megkülönböztetni: Teljes körű végleges értékelést adó aláírás-érvényesítést a rendszer két folyamatban végez. Az átvételi elismervények esetében az aláírás érvényestés eredményétől függ a rendszer döntése, hogy rendelkezésre bocsátja-e a biztonságos kézbesítési szolgáltatással továbbított küldeményt vagy sem. A másik eset a kézbesítési utasítások aláírásainak érvényesítése. Itt a konverziós folyamat elindításának feltétele a kézbesítési utasításon elhelyezett aláírás érvényessége. Ezekben az esetekben a rendszer a biztonsági követelmények szempontjából maximalista módon értékel, ha az érvényesítés során bármely érvényességi kelléknél a rendelkezésre álló információk alapján kétség merül fel, akkor inkább elutasítja az aláírást, mivel az aláírást készítőnek ez legfeljebb időbeli kényelmetlenséget okozhat, viszont nem kerül sor a valóságnak ne megfelelő információ továbbítására. Ugyanakkor látni kell azt is, hogy ez a megoldás is hordoz bizonytalansági elemet, hiszen a feldolgozási modellből következően nincs lehetőség a kivárási ciklus érvényesítésére egyetlen vizsgálat alapján kell a döntést meghozni. Ettől lényegesen eltérő a helyzet az elektronikus eredetiről történő hiteles másolatkészítés vonatkozásában. Ott ugyanis maga a dokumentum aláírt volta, illetve az aláírás megfelelősége a másolatkészítés hitelességét csak egészen kivételes esetben érintheti, ha akár a kézbesítési utasításban szereplő lenyomattal, akár az adott dokumentum aláírásában szereplő lenyomattal összevetve a dokumentum azonosságával, változatlanságával kapcsolatos kérdés merül fel. Ekkor ugyanis nem biztosított, hogy az eredeti megrendelői szándék érvényesüljön, tehát a konverziót el kell utasítani. Minden más esetben azonban figyelembe kell venni, hogy a másolatkészítés hitelessége az aláírástól függetlenül akár az iratérvényességi nyilvántartás, akár a bithelyes kinyomtatás útján biztosított, és itt az e-ügyintézési Vhr (5) bekezdése kizárólag két szempont alapján (változatlanság és tanúsítvány érvényessége) szempontjából történő ellenőrzést és ennek az információnak a feltüntetését teszi feladattá és lehetővé, mivel maga az aláírás érvényessége az adott esetben a másolatkészítés hiteles voltát nem érinti. Ennek megfelelően, bár az aláírás egyes elemeinek érvényességét a rendszer a DSS és az itext szoftver segítségével itt is az általános gyakorlatnak megfelelően ellenőrzi, és a szoftverek az egyes ellenőrzési lépésekről adnak információt, az értékelés kizárólag az e-ügyintézési Vhr (5) bekezdése által lehetővé tett vizsgálati szempontokat értékeljük a záradék szövegének kialakítása során. Ennek megfelelően itt csak akkor kerül elutasításra a másolatkészítés, ha kiderül, hogy maga a dokumentum változott meg az ellenőrzés szerint vagy egyértelműen az aláírás időpontjában nem volt érvényes a tanúsítvány. (mivel az időbélyegzés nincs 121

122 jogszabályban előírva a kizárásnál az aláírásban rögzített nem hiteles időpontot is figyelembe kell venni egyéb lehetőség hiányában Aláírás kiterjesztési folyamatok és rendszerek A hibrid kézbesítési és konverziós rendszerben generált dokumentumok esetében mindenkor időbélyegzéssel ellátott, azaz PAdES-T, illetve XAdES-T formátumú bélyegzők kerülnek generálására. Ebből következően az aláírás készítéskori állapota, érvényessége minden esetben aggálytalanul ellenőrizhető, és ez a formátum alkalmas a tartós megőrzésre is. Kívülről érkező dokumentumok a rendszer felelőssége alatti tárolására pedig nem kerül sor. Az aláírás kiterjesztése az előbbi aláíráshoz további adatok kapcsolásával arra hivatott lehetőséget adni, hogy az adott dokumentumhitelessége az eredeti algoritmus biztonságos használati, illetve a tanúsítvány alkalmassági idején túlterjeszkedő időtartamban és kellő biztonsággal igazolható lehessen. Az erre a célra szolgáló logikai szerkezetet az EN szabvány a következőképpen mutatja be: 22. ábra: egy hossz távú megőrzésre alkalmassá tett aláírás szerkezete az EN szabvány alapján A HKKR a készített igazolásokat (bizonyítékokat) és a tranzakciókhoz kapcsolódó, az események megtörténtét igazoló naplóbejegyzéseket egy olyan tároló rendszerben Caringo Swarm objektum orientált tároló szoftver kezeli, amely az egyszer írható tárolókkal azonos megbízhatóságot ígér elosztott architektúrája eredményeként, és garantálja, hogy a bekerült bizonyítékokat utólag nem lehet manipulálni. E két tény együttesen, figyelembe véve, hogy az általános szabályok szerint egy aláíró algoritmust a hatóságok akkor tekintenek alkalmazhatónak, ha annak a ma belátható élettartama nem rövidebb három évnél. Ezt figyelembe véve az 5 éves élettartam alatt legfeljebb egyszer kell majd újabb, fejlettebb időbélyegekkel ellátni a tárolt dokumentumokat, erre a funkcióra elég lesz a későbbiekben a sürgősebb feladatok megoldása után felkészülni. Éppen ezért jelenleg aláírás kiterjesztési folyamatok nincsenek a rendszerben implementálva. 122

123 A fő kiterjesztési folyamatok Nem értelmezhető a fentiekből következően A kiterjesztési eljárási szabályok végrehajtatása Nem értelmezhető a fentiekből következően Adatok bevonása a kiterjesztési folyamat során Nem értelmezhető a fentiekből következően A bementő aláírás érvényesítése Nem értelmezhető a fentiekből következően. 2.5 Fejlesztési és a kódolással kapcsolatos követelmények A Magyar Postán belül nem folyik a Hibrid kézbesítési és konverziós rendszerre, és különösen az aláírások kezelésében érintett szoftverekre vonatkozó fejlesztési tevékenység. Kifejezetten az aláírásokra vonatkozóan ilyen a jövőben sem tervezett. A rendszer fejlesztését és integrálását közbeszerzés eredményeként külső szállító végezte, amely a szerződésében komoly garanciákat vállalt az általa használt fejlesztési metodika megfelelőségére vonatkozóan és jelezte, hogy komoly gyakorlata van az ISO szabványcsalád követelményeinek kezelésében. A következő időszak szükséges fejlesztéseire vonatkozóan is követelmény a megfelelő fejlesztési metodika előzetes dokumentálása és elfogadtatása Biztonságos fejlesztési módszerek A Magyar Posta Biztonsági kódexe és ennek részeként az Információ biztonsági szabályzat részletes követelményrendszert határoz meg a külső fejlesztések biztonságára vonatkozóan. Biztosítani kell a szerződő felekkel szolgáltatásnyújtására kötött megállapodásokban az Információbiztonsági követelményekben foglaltak teljesítését, a szolgáltatásmeghatározásokat és szolgáltatásnyújtási szinteket, ezek működtetését és fenntartását. A Társasággal szerződéses vagy más módon kapcsolatba kerülő természetes személyekkel és gazdálkodó szervezetekkel (alvállalkozók, partnerek) titoktartási nyilatkozatot kell aláíratni és gondoskodni annak betartásáról. A titoktartási nyilatkozat aláíratásáért az érintett szerződő szervezeti egység vezetője felelős. Az információbiztonságot érintő szerződésekről tájékoztatni kell az IBO vezetőjét és az informatikai üzemeltetési igazgatót. A felek között megkötött szerződésnek a jogszabályi és belső szabályozási követelményeken túl tartalmaznia kell az információs rendszerekhez és hálózatokhoz kapcsolódó: 123

124 a) információbiztonsági ellenőrzésekre és eljárásokra, valamint a Társaság kockázatelemzését lehetővé tevő, a tevékenységet végzővel szemben támasztott követelményeket. Egyértelmű szerepkör elhatárolás szükséges az üzemeltetési folyamatok tekintetében. b) a feladatok és felelősségi viszonyok egyértelmű meghatározását, c) a szolgáltatás megbízhatóságára, valamint a maximális kiesési időre vonatkozó követelményeket, d) a kockázatok kezelésével kapcsolatos feladatokat, intézkedéseket, e) a tevékenységet végző információvédelemmel kapcsolatos kötelezettségeit f) a megbízás megszűnésekor, illetve a hozzáférési jogosultsággal rendelkező egy személyek foglalkoztatásának megszűnésekor követendő biztonsági eljárásrendet Az elkészült fejlesztések átvételére a Magyar Posta tesztelési, illetve változáskezelési szabályzataiban rögzített követelményeket kell érvényesíteni A megfelelés tesztelése A rendszer a leszállítása óta az elmúlt három évben kiterjed tesztelésen és ennek következtében jelentős fejlesztésen esett át. Jelenlegi állapotában már az eredetileg elképzelt igen komplex szolgáltatáskészlet túlnyomó részét biztosítani képes. Ez igaz az elektronikus aláírások, bélyegzők és aláírások vonatkozásában is. Ez azonban nem jelenti a folyamat lezártságát, A megbízhatóbb működés érdekében tervezzük az aláírási, aláírás-ellenőrzési szoftverek teljes egészében történő egységesítését és a frissebb fejlettebb verzióra áttérést az EU által támogatott DSS alapú szoftvereszközökkel. Ez lehetővé teszi az eidas szabályozás valamennyi elemének maradéktalan figyelembe vételét a jövőben és ezen keresztül a lehető legszélesebb interoperabilitás biztosítását. A Magyar Posta a változáskezeléshez szabályozással és a változások ellenőrzéséhez megfelelő tesztelő apparátussal, a tesztelések dokumentáláshoz pedig meg szoftverrel (Spirateam) rendelkezik. Ugyanez igaz a csatlakozó szervezetek vonatkozásában is, ahol az elektronikus aláírások megfelelő alkalmazása az esetek jelentős hányadában jelentett problémát. A csatlakozások megkönnyítésére a Magyar Posta a különböző csatornákon keresztül megvalósított csatlakozásokhoz megfelelőségi (csatlakozási) tesztelési metodikát alakított ki és az ÁSZF-fel összhangban a szolgáltatásokat nem a portálon keresztül igénybe vevő szervezetek csak e tesztek sikeres teljesítését követően tudják üzemszerűen igénybe venni a szolgáltatásokat. A tesztelést segítő metodikák, a tesztjegyzőkönyv mintája a szerződési folyamat részenként kerülnek átadásra. 124

125 1 sz. melléklet: A KEAASZ szoftver alkalmazása Az e-aláíráshoz, illetve az időbélyegzéshez, illetve az elkészült vagy megkapott aláírások és időbélyegek ellenőrzéséhez szükség van egy olyan alkalmazásra is, amely ezeket a funkciókat támogatja. Ezek egyike az ingyenes Kormányzati Elektronikus Aláíró és Aláírás-ellenőrző Szoftver (KEAASZ). A KEAASZ egy önállóan telepíthető szoftver, ami lehetővé teszi egy vagy több dokumentum aláírását és az időbélyegző létrehozását. A KEAASZ alkalmazással ellenőrizhető a már aláírt dokumentumokon elhelyezett aláírás érvényessége, illetve megismerhetők a kapcsolódó tanúsítvány adatai. A KEAASZ értelemszerűen többféle az aláírás-létrehozó adat megfelelő tárolására alkalmas hardveres és szoftveres eszközzel képes együttműködni, és csak akkor alkalmas az eszemélyivel történő használatra, ha az eszemélyi Kliens szoftver e- aláírást is támogató verzióját szintén telepítette a felhasználó a számítógépére. A KEAASZ jelenlegi (1.33) verziójának működése az alábbi operációs rendszereken támogatott: Windows 7, 8, 8.1, 10 Linux: Ubuntu desktop 17.04, 17.10, CentOS 7, SuSE Linux 13.2, opensuse Leap 42.3, Debian 9, Linux Mint 18.3 A támogatott platformok köre várhatóan tovább fog bővülni, a jelenleg még tesztelés alatt álló MacOS operációs rendszereken is használható verzióval. A KEAASZ telepítése előtt telepíteni szükséges a Java futtatókörnyezet és a Microsoft.NET-keretrendszer megfelelő verzióját (Java Runtime Environment 1.8.x, Microsoft.NET Framework 4.0). Java futtató környezet (Runtime Environment) program a weboldalról tölthető le. A honlap az esetek jelentős részében kiválasztja az operációs rendszernek és a böngészőnek megfelelő Java verziót, de erre indokolt odafigyelni, mert különösen a 64 bites verzióknál gyakran van szükség offline telepítésre. Arra is oda kell figyelni, hogy az új, 1.9 Java család támogatása még nem mindenben biztosított. Az alkalmazáshoz használt JAVA platformnak meg kell egyezni az esetlegesen használni kívánt kulcsok kezeléséhez esetleg használni kívánt PKCS11-es meghajtó platform verziójával. Azaz 32 bites PKCS11-es fájl használata esetén 32 bites JAVA használata szükséges. 64 bites PKCS11-es fájl használata esetén 64 bites JAVA használata szükséges. A Microsoft.NET-keretrendszer (Framework) webes telepítője a Microsoft Letöltőközpontból, a oldalról tölthető le. A szoftver az adott operációs rendszerhez megfelelő verziójának letöltése a 125

126 oldalról történhet, itt elérhető egy telepítési útmutató és egy a funkcionalitást elégséges részletességgel bemutató felhasználói leírás is. A telepítés maga nagyon egyszerű, mindössze azt kell kiválasztani, hogy minden az adott gépen dolgozó számára kívánja az alkalmazást telepíteni ekkor értelemszerűen rendszergazdai jogosultság szükséges vagy pedig az adott felhasználó számára. A felhasználói leírás birtokában kipróbálhatók, illetve alkalmazhatók a program különböző funkciói. Maga a kezelő felület meglehetősen minimalista, de az esetek igen jelentős hányadában még ezen a felületen belül is elégséges az ún. egyszerű üzemmód kiválasztása. A nem gyakorlott, illetve megfelelő elméleti háttérrel nem rendelkező felhasználók így kevesebb hibát vétenek. (igaz, nem is tudják valamennyi lehetőséget kihasználni, de ami elkészül, az legalább nagy valószínűséggel használható). A szoftver a 3. sz. mellékletben szereplő DSS szoftvercsomagra épít, így a következő időszakban célszerű lesz rendszeresen aktualizálni, mivel a keretrendszer fejlesztése még tovább folyik, a kompatibilitás és a szolgáltatás-készlet bővül. 126

127 2 sz. melléklet: Az e-személyi alkalmazása elektronikus aláíráshoz Az elektronikus tároló elemet tartalmazó személyazonosító igazolvány (eszemélyi) olyan okmány, amelyhez a magyar állampolgárok díjmentes elektronikus aláírás és elektronikus időbélyegzés szolgáltatást igényelhetnek. Az elektronikus aláírás és időbélyegzés szolgáltatás által lehetővé válik elektronikus dokumentumok természetes személy általi elektronikus aláírása, illetve időbélyegzése. Így az eszemélyi felhasználható különböző ügyek gyors, papírmentes elintézésére, például az e-közigazgatási folyamatokban. Az e-aláírás és az időbélyegzés szolgáltatás összefügg egymással: míg az elektronikus aláírás azt igazolja, hogy ki írta alá a dokumentumot, addig az időbélyegző lényegében azt igazolja, hogy mikor történt az aláírás. Ha valaki e-aláírás szolgáltatást igényel az eszemélyihez, akkor az okmány tároló elemén (chip) létrehozásra kerül egy ún. kulcspár, amely egy egyedi elektronikus adat, és amely két részből áll: egy ún. magánkulcsból (aláírás-létrehozó adat), és egy ún. nyilvános kulcsból (aláírás-ellenőrző adat). Az e-aláírás az eszemélyin levő magánkulccsal készül. Kizárólag a magánkulcs párjával, a nyilvános kulccsal lehet ellenőrizni az aláírás eredetiségét, az aláírt elektronikus dokumentum sértetlenségét. Ha az aláírt dokumentumban változtatás történik, akkor az elektronikus aláírás ellenőrzése sikertelen. A nyilvános kulcs és az aláíró személyének összetartozását egy tanúsítvány igazolja. A tanúsítvány egy szabványos mezőkből álló elektronikus igazolás, melyet a kulcspár előállítását követően a kormányzati hitelesítés szolgáltató bocsájt ki és helyez el a személyi igazolvány tároló elemén. Elektronikus aláíráskor a tanúsítvány hozzákapcsolódik az aláíráshoz, illetve az aláírt dokumentumhoz. Mivel a tanúsítvány tartalmazza a nyilvános kulcsot és a tulajdonos nevét, a dokumentum olvasója (a fogadó fél) meg tudja állapítani, ki írta alá a dokumentumot, illetve ellenőrizni tudja az elektronikus aláírást. 2.1 Az elektronikus aláírás alkalmazásának lehetőségei és korlátjai Az e-aláírásra, illetve elektronikus ügyintézésre vonatkozó hazai és nemzetközi jogszabályok többféle e-aláírást különböztetnek meg a felhasználhatóság lehetőségei és annak korlátjai szempontjából. Az eszemélyihez a legerősebb (legszélesebb alkalmazhatóságot biztosító) aláírások kapcsolódnak: a május 27. után igényelt e-aláírás funkcióval minősített elektronikus aláírás, az ezt megelőző időszakban igényelt e-aláírás funkcióval minősített tanúsítványon alapuló fokozott biztonságú e-aláírás hozható létre. A polgári perrendtartásról szóló évi CXXX. törvény 325. (1) bekezdés f) pontja szerint mind a két aláírás lehetőséget ad arra, hogy az állampolgárok magánjogi vagy közigazgatási jogügyleteikben elektronikusan tehessenek teljes bizonyító erejű magánokiratnak megfelelő joghatással bíró jognyilatkozatokat. A 910/2014/EU rendelet pedig kimondja, hogy a minősített elektronikus aláírás a saját 127

128 kezű aláírással azonos joghatású. A nemzeti és az európai uniós szabályozási elvek szerint az elektronikus aláírás, illetve dokumentum elfogadását megtagadni, joghatás kiváltására való alkalmasságát kétségbe vonni nem lehet kizárólag amiatt, hogy az aláírás, illetve dokumentum elektronikus formában létezik. Magyarországon az elektronikus aláírással rendelkező magánszemélyek néhány speciális jogügylet kivételével szinte bármilyen jogügyletben tehetnek elektronikus jognyilatkozatot. Kivételt képeznek a speciális formai elvárásokhoz kötött jogügyletek (pl. az ingatlanforgalmi szerződések), a bírósági eljárások egyes típusai, valamint a Ptk.-ban szabályozott családjogi, élettársi kapcsolati, öröklésjogi jogviszonyok (pl. a végrendelet, házasságkötés). Az E-ügyintézési tv és az említett EU rendelet az elektronikus ügyintézés során biztosítják az elektronikus aláírás felhasználhatóságát, a határon átnyúló ügyekben is. 2.2 A tanúsítványok igénylésének és kibocsátásának körülményei Az eszemélyihez kapcsolódó e-aláírás és időbélyegzés szolgáltatást jogszabályi kijelölés alapján a NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. mint kormányzati hitelesítés-szolgáltató nyújtja, a Belügyminisztérium, valamint a járási hivatalok (kormányablakok, okmányirodák) és a kijelölt kormányhivatal (központi okmányiroda) közreműködésével. A szolgáltatást (illetve az ehhez szükséges minősített tanúsítványt) olyan cselekvőképes nagykorú polgárok, cselekvőképességükben részlegesen korlátozottak, illetve korlátozottan cselekvőképes kiskorúak igényelhetik, akik a polgárok személyi adatainak és lakcímének nyilvántartásáról évi LXVI. törvény szerint tároló elemmel ellátott állandó személyazonosító igazolvány igénylésére jogosultak. Az elektronikus aláírás szolgáltatást személyesen lehet igényelni, a kormányablakokban vagy az okmányirodákban. Az igénylés benyújtható az új személyazonosító igazolvány igénylésével együtt, vagy utólag, amikor a polgár már rendelkezik elektronikus tároló elemet tartalmazó személyazonosító igazolvánnyal. Az igényléskor a jogszabályi előírásokra tekintettel rögzítik és ellenőrzik az igénybe vevő személyes adatait, átadják számára a szolgáltatás használatához szükséges PIN kódokat tartalmazó borítékot, és a szolgáltatói szerződés is megkötésre kerül. A szolgáltatói szerződés az e-aláírás szolgáltatáson túl kiterjed az időbélyegzés szolgáltatásra is. Ha az igénylés az új személyazonosító igazolvány igénylésével együtt történt, akkor a tanúsítvány az igazolvány gyártásakor kerül kibocsátásra, illetve elhelyezésre az okmány biztonságos tároló elemén, a NISZ Zrt. illetve a Belügyminisztérium által. Az okmány tulajdonosa az elkészült eszemélyit a rajta levő érvényes tanúsítvánnyal együtt személyesen veheti át az okmányirodában, vagy kérheti annak postai kézbesítését (saját kézbe, hivatalos iratként), ha a régi igazolványát az igényléskor leadta. 128

129 Ha az igénylés utólag történik, akkor az igénylőnek magával kell vinnie az érvényes eszemélyit, mivel ilyenkor a szolgáltatói szerződés megkötését követően sor kerül a tanúsítvány kiadására is a NISZ Zrt. által. Ekkor a tanúsítvány ott helyben a közreműködő kormányablakban vagy okmányirodában kerül elhelyezésre az okmányon. Az elektronikus aláíráshoz kapcsolódóan kibocsátott tanúsítvány érvényességi ideje 2 év, ha a kibocsátás időpontjában az eszemélyi érvényességéből több mint 2 év van hátra; ellenkező esetben a tanúsítvány érvényességének vége megegyezik az eszemélyi lejárati dátumával. A tanúsítványt bizonyos esetekben vissza lehet vonni (le lehet tiltani), még mielőtt lejár az érvényességi ideje. A visszavonás egyik oka lehet, ha az eszemélyi tulajdonosának már nincs többé szüksége a tanúsítványra. A másik jellemző ok, ha fennáll a lehetőség/gyanú, hogy az e-aláírás funkcióval illetéktelenek visszaélnek. A tanúsítvány akkor is visszavonásra kerül, ha az eszemélyit az illetékes hatóság érvényteleníti (pl. az okmány elvesztése miatt). Visszavonás után a tanúsítványt (pontosabban a hozzá kapcsolódó aláírás-létrehozó adatot) nem lehet felhasználni érvényes elektronikus aláírás létrehozására, ugyanis a visszavont tanúsítványon alapuló elektronikus aláírás jogilag érvénytelen. A visszavonás visszafordíthatatlan: a visszavont tanúsítványt nem lehet újra érvényesíteni. A tanúsítvány visszavonására vagy személyesen van lehetőség, bármelyik kormányablakban és okmányirodában ügyfélfogadási időben, vagy telefonon, a 1818-as számon hívható Kormányzati Ügyfélvonalon a hét minden napján, 0-24 órában. A telefonos visszavonás során az eszemélyi tulajdonosa a visszavonási jelszóval kell, hogy azonosítsa magát. A visszavonási jelszó és ennek használatához kapcsolódó információk az e-aláírás szolgáltatás igénylésekor megkapott, e-aláírás kódkártyát tartalmazó borítékban találhatók. A visszavont tanúsítványok sorozatszámát és a visszavonás időpontját a NISZ Zrt a jogszabályi követelményeknek megfelelően elérhetővé teszi a honlapján ( A NISZ Zrt. emellett ún. valós idejű tanúsítvány állapot információt is szolgáltat (OCSP), hogy az érintett felek ellenőrizhessék az e-aláírás érvényességét. Az eszemélyihez kapcsolódó elektronikus aláírás csak magáncélra használható fel; a szolgáltatás használata bármilyen üzleti, munkahelyi vagy egyéb szakmai tevékenység céljából nem megengedett. Az e-aláírás szolgáltatók ugyanis az általuk kibocsájtott tanúsítványokban meghatározhatják a tanúsítvány felhasználásának tárgy béli, földrajzi vagy egyéb korlátait, illetve az egy alkalommal vállalható kötelezettség legmagasabb értékét. A fentiek alapján a NISZ Zrt. az eszemélyihez kiadott minősített tanúsítvány esetében az ún. tranzakciós limitet azaz az aláíró által az aláírással tehető pénzügyi felelősségvállalás maximális mértékét jogszabályi rendelkezés alapján Euróban limitálja; ennél nagyobb összegekre az e-aláírás használata nem 129

130 megengedett. Ez a gyakorlatban azt jelenti, hogy ha valaki például egy 3,5 millió Ftos ingóság (pl. használt autó) adás-vételi szerződését elektronikus úton kívánja megkötni, és a szerződést az eszemélyihez kapcsolódó elektronikus aláírással írja alá, akkor bár az aláírása jogilag érvényes de a szolgáltatást nem rendeltetés szerűen használta fel. A NISZ Zrt. a kártérítési felelősségét káreseményenként legfeljebb Ft-ban korlátozza. A NISZ Zrt. ügyfele akkor jogosult ilyen kártérítésre, ha bizonyítást nyer, hogy a kárt a NISZ Zrt. okozta szándékos vagy gondatlan magatartásával, a szolgáltatás nyújtása során. 2.3 Az elektronikus időbélyegzés szolgáltatás Az időbélyegző az elektronikus dokumentumhoz végérvényesen hozzárendelt vagy azzal logikailag összekapcsolt olyan adat, amely igazolja, hogy az elektronikus dokumentum az időbélyeg elhelyezésének időpontja óta változatlan formában létezik (amennyiben az ellenőrzés sikeres volt). Az eszemélyihez kapcsolódó időbélyegzés szolgáltatást az állampolgárok csak az eszemélyivel történő elektronikus aláíráshoz jogosultak igénybe venni annak megengedett használati körében. Az eszemélyi e-aláírás funkciójához kiadott tanúsítvány lejártával vagy visszavonásával a továbbiakban az időbélyegzés szolgáltatás sem vehető igénybe. Az eszemélyihez kapcsolódó időbélyegzés szolgáltatás igénybe vételéhez Internet elérés szükséges, mivel a szolgáltatás a címen érhető el. A szolgáltatás használatához egy olyan szoftveralkalmazásra is szükség van, amely biztosítja a szabványos (RFC3161 szerinti) időbélyeg kérések generálását, valamint a Szolgáltató által elküldött időbélyegzők fogadását. Az alkalmazásnak támogatnia kell azt is, hogy az időbélyeg kérés SHA256 lenyomatképző algoritmussal készüljön, és az időbélyeg kérés a beküldés előtt az eszemélyin tárolt minősített tanúsítványhoz kapcsolódó magánkulccsal alá legyen írva. A fentieknek megfelelő szoftveralkalmazás (KEAASZ) díjmentesen letölthető a felhasználói és telepítési útmutatóval együtt az eszemélyi honlapjáról, a internetes oldalról. 2.4 Az aláírás-létrehozó adat használata és védelme Aláírás-létrehozó adatnak vagy magánkulcsnak nevezik azt az egyedi elektronikus adatot, amelyet az aláíró (természetes személy) az e-aláírás létrehozására használ. Ez a magánkulcs minden aláírónál más és más. A magánkulcsot védeni kell attól, hogy illetéktelen személy megismerhesse. A magánkulcs az eszemélyi biztonságos tároló elemén (chip) kerül létrehozásra, és ott tárolódik, védett módon. Az alkalmazott technológia biztosítja, hogy a magánkulcs az igazolványról nem másolható ki, nem állítható elő az egyéb 130

131 adatokból, a nyilvános kulcsból nem kiszámítható. A magánkulcs az elektronikus aláíráshoz kapcsolódó PIN kóddal aktivizálható, illetve használható, ami egyben védelmet jelent a visszaélésekkel szemben is: ha az igazolvány illetéktelen személy kezébe kerül, akkor sem tud e-aláírást létrehozni a tulajdonos nevében, hiszen ahhoz ismernie kellene a kapcsolódó PIN-kódot is. (és csak korlátozott számban próbálkozhat, utána a kártya letiltja a hozzáférést) Az eszemélyi tulajdonosának feladata és felelőssége, hogy az átvételt követően vigyázzon az okmányra, illetve a kapcsolódó PIN és PUK kódjára, ügyelve arra, hogy ezek ne kerülhessenek illetéktelen személyek birtokába vagy tudomására. Ha azt gyanítja, hogy az okmányhoz kapcsolódó PIN vagy PUK kód illetéktelen személy tudomására jutott, akkor a PIN kódot megváltoztathatja a PIN borítékban ( Elektronikus aláírás kód kártya tájékoztató") kapott részletes útmutató szerint. Az eszemélyi tulajdonosának, mint aláírást létrehozó személynek a felelősségét és kötelezettségeit a NISZ Zrt. bizalmi szolgáltatási szabályzatának fejezete tartalmazza. Ennek megfelelően aláíró felelős - többek közt - az okmánynak, mint elektronikus aláírást létrehozó eszköznek, valamint az azon levő magánkulcsnak a körültekintő felhasználásáért; aláíró felelős a magánkulcsnak, az aktivizáló adatoknak, PIN és PUK kódnak, valamint a visszavonási jelszónak a védelméért és biztonságos kezeléséért; aláíró felelős azért, hogy a magánkulcsot és a kapcsolódó tanúsítványt csak a tanúsítvány érvényességi időtartamán belül használja, a pénzügyi korlátozásoknak megfelelően. Aláíró kötelessége a tájékoztatni a NISZ Zrt.-t a jogszabályokban [pl. E-ügyintézési tv (1) bekezdésben] előírt esetekben, például akkor, ha a számára kiadott tanúsítvánnyal vagy azon alapuló elektronikus aláírással kapcsolatban jogvita indul. Köteles bejelenteni az eszemélyi eltulajdonítását, megsemmisülését, megrongálódását vagy elvesztését a kormányablakokban vagy az okmányirodákban. Az elektronikus aláírást létrehozó eszköz esetünkben az a hardvereszköz, melynek segítségével az aláíró az aláírás-létrehozó adat felhasználásával az elektronikus aláírást létrehozza. Ez maga az eszemélyi (a chipkártya), amelynek biztonságos tároló eleme a szolgáltatás igénylése esetén tartalmazza az aláírás-létrehozó adatot. Az eszemélyinek, mint minősített aláírást létrehozó eszköznek a használatához szükség van egy chipkártya-olvasóra. A kereskedelemben különböző típusú és műszaki paraméterekkel rendelkező chipkártya olvasók kaphatók; az eszemélyi használatához alkalmas kártyaolvasók listája oldalon található. Az eszemélyihez kapcsolódó elektronikus aláírás és időbélyegzés szolgáltatás díjmentesen vehető igénybe. A szolgáltatásnak nem része a chipkártya-olvasó biztosítása; ezt az eszemélyi tulajdonosának kell beszereznie és finanszíroznia. Az eszemélyi használatához egy ún. kártyaolvasó alkalmazást ( eszemélyi Kliens ) is telepíteni kell a felhasználó számítógépére. Ez a kártyaolvasó alkalmazás 131

132 díjmentesen letölthető a oldalon, a felhasználó segédlettel és telepítési leírással együtt. Az e-aláírás elkészítéséhez, illetve az időbélyeg elhelyezéséhez szükség van egy olyan számítógépes szoftveralkalmazásra is, amely az aláírási és időbélyegzési funkciókat támogatja. Egy ilyen szoftveralkalmazás korábban már hivatkozott az eszemélyi honlapjáról, a internetes oldalról. Az alkalmazás támogatja többféle pl. PDF állományok eszemélyivel történő aláírását és időbélyegzését. Az aláírni tervezett dokumentum, adatállomány típusától függően többféle egyéb alkalmazás használata is lehetséges. Pl.: az ismert levelezőprogramokkal (pl. MS Outlook) alá lehet írni egy t, az MS World és Excel alkalmazással pedig DOCX illetve XLSX állományok is aláírhatók. Acrobat Reader-rel alá lehet írni PDF dokumentumokat az Open Office alkalmazások is lehetőséget biztosítanak a velük készített dokumentumok aláírására Fentiek mellett léteznek további olyan speciális aláíró alkalmazások, amelyekkel más típusú fájlok és adatállományok is aláírhatók, akár egyszerre több együttesen. 2.5 Az aláírást ellenőrizni kívánó felek felelőssége, kötelezettsége Az elektronikus aláírás érvényességének, hitelességének, sértetlenségének ellenőrzése az elektronikusan aláírt dokumentumot fogadó fél feladata. A fogadó fél felelősségére vonatkozó előírásokat és ajánlásokat részletesen a NISZ Zrt. bizalmi szolgáltatási szabályzatának fejezete tartalmazza. Az elektronikus aláírás érvényességét a kapcsolódó tanúsítvány segítségével lehet ellenőrizni; a fogadó félnek meg kell győződnie arról, hogy a tanúsítvány érvényes volt-e az aláírás időpontjában; ez a tanúsítványban feltüntetett érvényesség kezdete" és érvényesség vége" adatok alapján tehető meg. Emellett a fogadó félnek ellenőriznie kell a tanúsítvány státuszát is, azaz, hogy nem volt-e visszavonva (letiltva) a tanúsítvány az aláírás időpontjában. Ez a NISZ Zrt. által biztosított visszavonási nyilvántartások (pl. a szolgáltatói honlapon elérhető ún. visszavonási listák) segítségével tehető meg. Az elektronikusan aláírt dokumentumokon szereplő aláírás érvényességéről a fogadó felek a gyakorlatban számítógépes alkalmazások igénybevételével győződnek meg (e-aláírás létrehozó, illetve ellenőrző alkalmazások). Egyik ilyen lehetőség a NISZ Zrt. a kormány megbízása alapján KEÜSZ-ként nyújtott Kormányzati Elektronikus Aláírás-ellenőrző Szolgáltatása, ami a internetes címen érhető el, díjmentesen. Hasonló célra felhasználható az aláírás létrehozására ajánlott KEAASZ is. 132

133 2.6 A bizalmi szolgáltatási szabályzatok és az ellenőrzéshez szükséges adatok elérhetősége A már többször hivatkozott szolgáltatási szabályzat egy olyan dokumentum, amely az e-aláírást, illetve az időbélyegzést nyújtó bizalmi szolgáltató tevékenységével kapcsolatos részletes eljárási és működési szabályokat tartalmazza. A szolgáltatási szabályzat nyilvános, így mind az ügyfelek, mind a harmadik felek megismerhetik az e-aláírás szolgáltatás műszaki, jogi, biztonsági és kereskedelmi körülményeit. A szolgáltatási szabályzat tartalmát jogszabályok és nemzetközi szakmai ajánlások írják elő; a szabályzatot ezek alapján az illetékes hatóság (Magyarországon a Nemzeti Média- és Hírközlési Hatóság - NMHH) ellenőrzi. Az eszemélyihez kapcsolódó elektronikus aláírás szolgáltatásra a NISZ Zrt. Bizalmi Szolgáltatási Szabályzat a személyazonosító igazolványokhoz kibocsátott minősített tanúsítványokhoz" (BSZ-ESZIG) szabályzata vonatkozik. A szolgáltatási szabályzat - egyebek mellett - az alábbiakat tartalmazza: a) a szolgáltató székhelyének, telephelyének postacímét és telefonszámát, illetve a szolgáltató elérhetőségének egyéb távközlési azonosítóját; b) a szolgáltató cégjegyzékszámát; c) azt a dátumot, amikor a szolgáltató a szolgáltatásait az NMHH számára bejelentette d) a szolgáltatási szabályzat változatának azonosítóját (verziószámát); e) a szolgáltatási szabályzat hatálybalépését és hatályának a megszűnését; f) a szolgáltató által a szolgáltatás nyújtásához használt aláírást létrehozó eszköz megnevezését, a g) kapcsolódó tanúsítás megjelölésével együtt; h) utalást arra, hogy a szolgáltató önkéntes akkreditációs rendszer keretében tanúsítva lett-e; i) a szolgáltató tevékenységével kapcsolatos kifogások és panaszok bejelentésének helyét és módját, a szolgáltatói ügyfélszolgálat és az illetékes fogyasztóvédelmi hatóság elérhetőségét; j) a szolgáltató által vállalt egyes nyitvatartási időket és rendelkezésre állási adatokat, például a kibocsátott tanúsítványt tartalmazó nyilvántartás, valamint a visszavonási nyilvántartás és a visszavonás kezelési szolgáltatások tekintetében; k) tájékoztatást a szolgáltató által nyújtott szolgáltatásokról és azok felhasználásának módjáról; l) tájékoztatást a szolgáltató által kibocsátott hitelesítési rendekről és az azok alapján kiadott tanúsítványok joghatásairól, a tanúsítványok felhasználásának feltételeiről, az aláíró és az ellenőrző feleket terhelő kötelezettségekről; m) tájékoztatást a tanúsítvány visszavonásának jogkövetkezményeiről; n) adatkezelési tájékoztató megjelölését, amely összefoglalja a szolgáltató által kezelt adatokat és az ezzel kapcsolatos információkat. 133

134 Az eszemélyihez kapcsolódó időbélyegzés szolgáltatásra a NISZ Zrt. Időbélyegzés Bizalmi Szolgáltatási Szabályzat" (IBSZ) szabályzata vonatkozik, mely a fentiekhez hasonlóan részletes információkat tartalmaz az elektronikus időbélyegzés szolgáltatásra nézve. Az eszemélyihez kapcsolódó elektronikus aláírás és időbélyegzés szolgáltatásokra a NISZ Zrt. Általános Szerződési Feltételek a NISZ Zrt. kormányzati hitelesítés szolgáltatásaihoz" (ÁSZF-GOVCA) című dokumentuma vonatkozik. Az ÁSZF- GOVCA a NISZ Zrt. mint Szolgáltató és az ügyfelei közötti előfizetői szerződések általános jogi- és kereskedelmi feltételeit határozza meg, és egyebek között tartalmazza a szolgáltató adatait, a szolgáltatások leírását; az előfizetői szerződés megkötésének, módosításának, megszűnésének a szabályait, a szerződő felek felelősségét, jogait és kötelezettségeit, valamint a jogviták rendezésének módját. Az személyéhez kapcsolódó elektronikus aláírás és időbélyegzés szolgáltatásokról teljes körű információt a NISZ Zrt. mint Szolgáltató honlapján ( közzétett és az alábbiakban felsorolt szabályzatok mindenkor hatályos változatai tartalmaznak: Általános Szerződési Feltételek a NISZ Zrt. kormányzati hitelesítés szolgáltatásaihoz (ÁSZF-GOVCA), Bizalmi Szolgáltatási Szabályzat a személyazonosító igazolványokhoz kibocsátott minősített tanúsítványokhoz (BSZ-ESZIG), Bizalmi Szolgáltatási Rend a személyazonosító igazolványokhoz kibocsátott minősített tanúsítványokhoz (BR-ESZIG), Időbélyegzés Bizalmi Szolgáltatási Szabályzat (IBSZ), Időbélyegzés Bizalmi Szolgáltatási Rend (ISZR). A jogszabályi előírások alapján a NISZ Zrt. szolgáltatási kivonatot is elérhetővé tesz a fogyasztók részére a címen, mely a fenti részletes szabályzatokkal összhangban, tömören, jól áttekinthető módon, összefoglaló jelleggel tartalmazza az előírt tájékoztató információkat és adatokat. Az eszemélyihez kapcsolódó minősített tanúsítványok hitelességét a NISZ Zrt. saját szolgáltatói nyilvános kulcsának felhasználásával lehet ellenőrizni. A szolgáltatói nyilvános kulcsot tartalmazó tanúsítvány alanya (Subject/CN): Állampolgári Tanúsítványkiadó Qualified Citizen CA. A szolgáltatói nyilvános kulcsot tartalmazó tanúsítvány letölthető a NISZ Zrt. honlapjáról: CCA.cer Az eszemélyihez kapcsolódó időbélyegek hitelessége a NISZ Zrt. által üzemeltetett időbélyegző szerverek (TSS1, TSS2 stb.) nyilvános szolgáltatói kulcsainak felhasználásával ellenőrizhetők. Ezen kulcsok elérhetőek a NISZ Zrt. honlapján, a tanusitvanyok címen. 134

135 2.7 A panaszok benyújtása, a jogviták rendezésére vonatkozó szabályok A NISZ Zrt. mint Szolgáltató részére panaszt a Kormányzati Ügyfélvonalon keresztül lehet benyújtani, a 1818-as hívószámon telefonon, vagy ben az ekozig@1818.hu címre küldve, valamint írásban a Kormányzati Ügyfélvonal 1389 Budapest, Pf.: 133 postacímre. A panaszt a Szolgáltató az előterjesztéstől számított 30 napon belül kivizsgálja, és ennek eredményéről a panaszost tájékoztatja. Bármely vitás kérdés felmerülése esetén a Szolgáltatót értesíteni és tájékoztatni kell a vita jogi útra terelése előtt, hogy azt békés úton, felek közötti egyeztetés útján rendezni lehessen. Ha az egyeztetés 30 napon belül nem vezet eredményre, úgy jogvita esetén a hatályos Polgári perrendtartás szerint illetékes bíróság jár el. 135

136 3 sz. melléklet: A DSS programcsomag áttekintése, alkalmazási lehetősége aláírás és aláírás ellenőrzés során Az Európa 2020 stratégia célkitűzéseinek megfelelően az intelligens, fenntartható és inkluzív növekedés megvalósítása és a munkahelyteremtés ösztönzése érdekében az Európai Uniónak olyan korszerű és nagy teljesítményű infrastruktúrára van szüksége, amely hozzájárul az Unió és valamennyi régiójának az összekötéséhez és integrációjához a közlekedési, a távközlési és az energetikai ágazatban. A transzeurópai hálózatoknak elő kell segíteniük a határokon átnyúló összeköttetéseket, elő kell mozdítaniuk a nagyobb gazdasági, társadalmi és területi kohéziót, valamint hozzá kell járulniuk egy versenyképesebb szociális piacgazdaság kialakításához és az éghajlatváltozás elleni küzdelemhez. Ezért az Európai Unió Tanácsa és a Bizottság 2013 végén létrehozta Európai Hálózatfinanszírozási Eszközt (CEF), melynek célja, hogy felgyorsítsa a transzeurópai hálózatokba történő közcélú és magánfinanszírozást beruházásokat. A CEF-nek elő kell segítenie a közlekedési, a távközlési és az energetikai ágazat közötti szinergiák teljes mértékű kiaknázását. Az egyik hangsúlyos fejlesztési, támogatási irány a digitális szolgáltatási infrastruktúra (DSI) fejlesztése, melyre az Unió az INEA-n (Innovation and Networks Executive Agency) keresztül komoly forrásokat biztosított. A digitális szolgáltatási infrastruktúra törzskomponenseit a Bizottság külön pályázati felhívások alapján finanszírozta, annak érdekében, hogy a tagországok a lehető legkisebb ráfordítással igénybe tudják venni ezeket a szolgáltatásokat és rájuk építve fejleszthessék a saját szolgáltatásaikat is. Így ezek a szolgáltatások nyílt forráskóddal és ennek megfelelő licenceléssel (Lesser General Public License (LGPL 2.1)). áll a tagországok és benne a szervezetek és magánszemélyek rendelkezésére. Az Európai Bizottság külön honlapot tart fenn ezeknek a szolgáltatásoknak és biztosítja a fejlesztéshez és igénybe vételhez szükséges támogatást is. Ilyen digitális alapszolgáltatások Az elektronikus azonosítás (eidentity) Az elektronikus aláírás (esignature) Az elektronikus számlázás (einvoicing) Az elektronikus kézbesítési (edelivery) Az automatizált fordítás (etranslation), valamint néhány szektor specifikus szolgáltatás e-egészségügy e-közbeszerzés szociális biztonsági adatok elektronikus átadása A fenti csomag egyik fontos eleme az elektronikus aláírásokat támogató DSS programcsomag, amelyet az Európai bizottság finanszírozásával jelenleg is 136

137 folyamatosan fejlesztenek. A legutóbbi, 5.2 verzió végén jelent meg, és már folyik a következő fejlesztése, illetve a közben fellelt hibák javítása. A DSS programcsomag egy Java nyelven megírt programcsomag amely az érintett ETSI műszaki előírásokkal és EU szabványokkal összhangban széles szolgáltatáskínálattal kívánja segíteni az elektronikus aláírás használatának terjedését. A 2015/1506 Bizottsági Végrehajtási határozattal összhangban különböző dokumentum- és aláírásformátumok használatára biztosít lehetőséget. Emellett működtet demonstrációs célú eszközöket is, amelyekkel mindenki, aki érdeklődik a DSS képességei iránt feltölthet és aláírhat különböző elektronikus dokumentumokat Csoportosan írhat alá feltöltött elektronikus dokumentumokat SOAP és REST API-kon keresztül webszervizeket érhet el, elvégezheti elektronikus aláírások kiterjesztését és érvényesítését DSS keretrendszer egy nagyszámú modulból álló projekt, amelyből saját build-eket a Maven nyílt forráskódú keretrendszer segítségével lehet készíteni. Egyszerűen le lehet azokat tölteni a következő Maven repository-ból : <repository> <id>cefdigital</id> <name>cefdigital</name> <url> </repository> A keretrendszer széles szolgáltatásválasztékkal áll rendelkezésre, amelyből a szolgáltatások építéséhez külön szakácskönyv is áll a projekt részeként rendelkezésre. Ezekkel a modulokkal az aláírás-készítés aláírás érvényesítés és az aláírás kiterjesztés lényegében minden fontosabb művelete megoldható az ETSI által szabványosított valamennyi aláírás-formára. Az alábbiakban mutatjuk be a keretrendszer moduljait, amelyekből az erre vállalkozók megvalósíthatják saját komplett kiszolgáló rendszerüket. dss-model dss-token dss-document dss-asic-common dss-asic-cades dss-asic-xades dss-cades dss-pades dss-xades Adatmodell, amelyet majdnem minden modul használ MS CAPI, PKCS#11, PKCS#12 token definíciók és implementációk Egy közös modul a dokumentumok aláírásához és érvényesítéséhez. Ez a modul nem tartalmaz saját megvalósítást egyik aláírási formához sem. Az dss-asic-xades és dss-asic-cades modulok által közösen használt kódelemek. CAdES aláírásokon alapuló ASiC-S és ASiC-E aláírást, kiterjesztést és érvényesítést megvalósító megoldás XAdES o aláírásokon alapuló ASiC-S és ASiC-E aláírást, kiterjesztést és érvényesítést megvalósító megoldás A CAdES aláírást, kiterjesztést és érvényesítést megvalósító megoldás A PAdES aláírást, kiterjesztést és érvényesítést megvalósító megoldás A XAdES aláírást, kiterjesztést és érvényesítést megvalósító megoldás 137

138 dss-spi dss-service dss-crl-parser dss-tsl-validation Interfészek, eszköz-osztály az ASN1 formátum használatához és a lenyomatok számításához A különböző online erőforrásokkal s (Időbélyeg, CRL, OCSP) való kommunikációt biztosító megoldások. API a CRL-ek ellenőrzéséhez és a visszavonási adatok kinyeréséhez Dss-crl-értelmező amelyik streameli a CRL állományokat (kísérleti). Dss-crl-értelmező amelyik az X509CRL java objektumot használja. Egy modul, amely lehetővé teszi a listák listájának (LOTL) és a bizalmi listáknak (TSL) a letöltését értelmezését és érvényesítését validation-policy Az aláírás érvényesítés üzleti folyamata (ETSI EN ). dss-rest dss-rest-client dss-soap dss-soap-client dss-validation-rest dss-policy-jaxb dss-crl-parserstream dss-crl-parserx509crl dss-validation-restclient dss-validationsoap dss-validationsoap-client dss-remoteservices dss-serversigning-common dss-serversigning-rest dss-serversigning-rest-client dss-serversigning-soap dss-serversigning-soap-client sscd-moccaadapter dss-diagnosticjaxb dss-simple-reportjaxb dss-detailedreport-jaxb dss-reports dss-tsl-jaxb dss-utils dss-utils-apache- REST webszerviz az aláíráshoz és aláírás kiterjesztéshez (getdatatosign, signdocument metódusok) Kliens a REST webszervizekhez SOAP webszerviz az aláíráshoz és aláírás kiterjesztéshez (getdatatosign, signdocument metódusok). Kliens a SOAP webszervizekhez REST webszervizek az aláírás érvényesítéshez Kliens az érvényesítő REST webszervizekhez. SOAP webszervizek az érvényesítéshez Kliens az érvényesítő SOAP webszervizekhez. Közös kódelemek dss-rest and dss-soap szolgáltatásokhoz Közös kódelemek a szerveralapú aláíráshoz REST webszerviz a szerveralapú aláíráshoz REST kliens a szerveralapú aláíráshoz SOAP webszerviz a szerveralapú aláíráshoz SOAP kliens a szerveralapú aláíráshoz A MOCCA token adapter megvalósítása (MOCCA az osztrák moduláris állampolgári kártya alkalmazás Modular Open Citizen Card Architecture) java alkalmazás. JAXB modell az érvényesítési szabályzathoz. JAXB modell a diagnosztikai adatokhoz JAXB modell az egyszerű (érvényesítési) jelentéshez. JAXB modell a részletes (érvényesítési) jelentéshez Segédprogram a jelentések (diagnostic-data, simple-report, detailed-report) JAXB modelljeinek egyszerű manipulálásához. A bizalmi lista (TSL) JAXB modellje segédprogramok, API String, Collection, I/O műveletek támogatásához A dss-utils megvalósítása az Apache Commons libraries használatával 138

139 commons dss-utils-googleguava dss-test dss-cookbook A dss-utils megvalósítása a Google Guava használatával Tesztadatok, tesztesetek és segédkönyvtárak az unit tesztek végrehajtásához A DSS dokumentációjához felhasznált példák és dokumentációk gyűjteménye. 12. táblázat: A DSS programelemei Ezen túlmenően vannak a keretrendszer alkalmazhatóságát bemutatni hivatott demonstrációs programok is, amelyek közvetlenül használhatók, első sorban demonstrációs célra, de egyéni felhasználók számára változatlanul is alkalmazhatók. 139

140 4 sz. melléklet: Az elektronikusan hitelesített dokumentumok ellenőrzése KEAESZ KEÜSZ segítségével 4.1 Bevezetés Amikor valaki döntést hoz egy elektronikusan aláírt, illetve elektronikus bélyegzővel ellátott dokumentum alapján, előtte ellenőriznie kell a dokumentumon elhelyezett aláírást vagy bélyegzőt. Ez az ellenőrzés megfelelő támogatás nélkül bonyolult folyamat, a lépések többségét azonban a számítógép megfelelő aláírás készítő, és ellenőrző kereskedelmi program, mint például az e-szignó, vagy a Mokka segítségével is elvégezheti az ember helyett. Ezek az ingyenesen hozzáférhető szoftverek azonban jellemzően a hazai szolgáltatók által megvalósított a saját alkalmazásaikat támogató programok, amelyek a jogszabályok által lehetővé tettnél lényegesen szűkebb technikai megoldási körben tesznek lehetővé aláírás és bélyegző készítést, illetve ellenőrzést. Ezen túlmenően inkább komoly költségű, fizetős alkalmazásokat kínálnak, amelyek jelentős szolgáltatási kínálattal, képességekkel rendelkeznek, amikre azonban egy hétköznapi felhasználónak aligha van szüksége. A magyar elektronikus ügyintézésben az aláírások díjtalan ellenőrzésére két ingyenes szolgáltatás áll rendelkezésre. Az egyik a már az 1. sz. mellékletben bemutatott, a oldalon elérhető, telepíthető, aláírásra is szolgáló KEAASZ alkalmazáscsomag. Ezt ott már bemutattuk, az ellenőrzési oldala eléggé fapados, kizárólag egyszerű értékelést ad, hogy az aláírás érvényes, nem érvényes, vagy az érvényesség nem megállapítható. Egy sor esetben ez is hasznos támpontot ad, azonban vannak olyan esetek is, ahol ennél alaposabb információ szükséges. Ilyen esetekben használható a kifejezetten aláírás ellenőrzésre szolgáló, és erről hiteles tanúsítványt is adó, a címen elérhető Kormányzati Elektronikus Aláírás Ellenőrzési Szolgáltatás. (KEAESZ) Ez a szolgáltatás is, mint a KEAASZ az előző mellékletben bemutatott, az Európai Hálózatfinanszírozási Eszközökből finanszírozott egyik szoftverprojektje, a DSS programcsomagját használja fel a szolgáltatás nyújtásához, de itt a hangsúly sokkal inkább az aláírásellenőrzésen van. A szolgáltatás egyre javuló megbízhatósággal azonosítja az aláírások széles körét. Amennyiben pozitív értékelést ad, azt igen nagy biztonsággal valóban minden szempontból megfelelő, aláírásnak lehet tekinteni. Amennyiben azonban negatív vagy nem meghatározható értékelést ad, érdemes a rendszer által a tanúsítvány mellékletében adott igen részletes értékelő adatsort megvizsgálni, valóban az aláírás-e a nem megfelelő. A jelen időszak ebből a szempontból eléggé szerencsétlen, mert relatíve nem régen változtak a jogi keretek, az alkalmazandó, illetve figyelembe veendő szabványok és műszaki előírások helyzete nem egyértelmű. A jogszabályi változásból következően maguk az aláírások is változtak és a korábbi aláírásokat az új követelményrendszerre épülő eljárásrend nem minden esetben értékeli korrekten annak ellenére, hogy az egyes értékeléshez szükséges 140

141 elemeket korrekten mutatja be. Mindezek mellett a bizalmi lista kezelésének problémái és a ellenőrző adatok pillanatnyi hozzáférhetetlensége miatt olyankor is nem megfelelőséget jelezhet a szoftver, amikor alaposabb elemzéssel az aláírás érvényessége igazolható. Ez az összefoglaló a szolgáltatás hatékony használatához kíván segítséget nyújtani. 4.2 A Kormányzati Elektronikus Aláírás Ellenőrzési Szolgáltatás A Kormányzati Elektronikus Aláírás Ellenőrzési Szolgáltatás (KEAESZ) egy, a 451/2016 (XII. 29.) Korm. rendelet 81. -ában meghatározott feladatokat teljesítő Központi Elektronikus Ügyintézési Szolgáltatás (KEÜSZ). A szolgáltatást a 84/2012 (IV.21.) Korm. rendelet 4. k) pontja alapján a NISZ Zrt. (1081 Budapest, Csokonai utca 3.) nyújtja Az ellenőrzés során a KEAESZ többek között kétséget kizáróan megállapítja, hogy az aláírt dokumentum és az elektronikus aláírás összetartozik-e, a dokumentum megváltozott-e az aláírás ideje óta, valamint, hogy az elektronikus aláírás elkészítéséhez használt magánkulcs tanúsítványa az aláírás időpontjában érvényes volt-e. A KEAESZ szolgáltatás webfelületen történő használatához kizárólag egy modern böngészőprogramra van szükség, amely támogatja a HTTPS titkosított kommunikációt. A böngésző a címsorában megjeleníti, a felhasználó meg is tekintheti a tanúsítványt. (sajnálatos módon a tanúsítvány elnevezése még nincs összhangban az eidas rendelettel, mivel egy SSL tanúsítványnak nevezik, holott amint az az első OID-ja alapján kiderül, ez a Nemzeti Infokommunikációs Szolgáltató Zrt. Bizalmi Szolgáltatási Rend weboldalhitelesítő tanúsítványokhoz. (BR-WOT). Verziószám Hatályba lépés dátuma , a második, OID alapján ez egy Az ETSI által regisztrált Organizational Validation Certificate Policy azaz a szervezetet hitelesítő tanúsítási rend, és a harmadik OID alapján a CA/Browser fórum által regisztrált Compliant with Baseline Requirements Organization identity asserted). A felhasználó számítógépén futó operációs rendszer tetszőleges. A szolgáltatással vizsgálható dokumentumok maximális méretét a szolgáltatás nem adja meg, a tapasztalatok szerint elég nagy méretű dokumentumokat is képes kezelni, de az időigény ilyenkor elég nagy és a kapcsolat megszakadása miatti sikertelenség veszélye sem csekély. Az aláírás-ellenőrzés alapvető eredménye, azaz a vizsgált dokumentumon lévő elektronikus aláírás érvényessége, vagy érvénytelensége egyszerű szövegként jelenik meg az ellenőrzés végén. Az ellenőrzés eredményét és az azt alátámasztó kiegészítő információkat részletesen tartalmazza az ellenőrzési folyamat végén letöltésre felkínált igazoló dokumentum. E dokumentum szabványos PDF formátumú, megjelenítéséhez az ingyenesen elérhető Adobe Reader vagy vele kompatibilis szoftver használható. 141

142 Az ellenőrzött dokumentumokat a szolgáltatás csak ideiglenesen tárolja, rajtuk semmilyen tartalmi elemzést nem végez, kizárólag a dokumentum sértetlenségét és az elektronikus aláírással való kapcsolatát vizsgálja. Az ellenőrzési folyamat végén a rendszer a vizsgált dokumentumot törli. 4.3 A webes aláírás-ellenőrző szolgáltatás A szolgáltatás ahogy korábban jeleztük a címen érhető el az interneten, azonosítás nélkül. A szolgáltatás igénybe vételéhez a megadott címen elérhető, eléggé egyszerű űrlapot kell kitölteni, és feltölteni az ellenőrzendő állományt. és amennyiben szükséges aláírt dokumentumot. Itt lehet kérni Archív időbélyeg elhelyezését is. Az oldal captcha védelemmel van ellátva, melynek kitöltésével és az ellenőrzendő állományok feltöltésével indítható a folyamat. Az ellenőrzés eredményét is itt jeleníti meg a rendszer, lehetővé téve egy összefoglaló dokumentum letöltését, melyet későbbi felhasználásra, emlékeztetőként, illetve igazolásként tárolhat a felhasználó. 23. ábra: KEAESZ kezdő oldala 142

143 A kérelem feldolgozását leíró folyamatábrát a Hiba! A hivatkozási forrás nem található. mutatja be a szolgáltatás jogi feltételrendszerénél Ellenőrizhető dokumentum- és aláírástípusok A KEAESZ szolgáltatás jelenleg csak bizonyos, a magyar közigazgatásban elterjedtebb aláírás-típusok ellenőrzésére alkalmas PDF dokumentumok A Portable Document Format (PDF) a dokumentumok szoftvertől, hardvertől és operációs rendszertől független, megbízható bemutatására és megosztására Adobe által kifejlesztett fájlformátum. Az PDF napjainkra a Nemzetközi Szabványügyi Szervezet (ISO) által kihirdetett, és széles körben alkalmazott szabvánnyá nőtte ki magát. (ISO :2005, ISO :2011, ISO :2012, ISO :2008, ISO :2017) A PDF az üzleti és közigazgatási dokumentumok megosztásának, tárolásának napjainkban elterjedten használt dokumentum formátuma, mely hűen megőrzi az eredeti dokumentum látványát, és számos, ingyenesen eszközzel létrehozható és megjeleníthető. A PDF-fájlok hivatkozásokat és gombokat, űrlap mezöket, hanganyagokat, videókat és üzleti logikát is tartalmazhatnak. Emellett elektronikus aláírással is elláthatók, és könnyedén megtekinthetők az ingyenes Acrobat Reader DC szoftverrel. (az aktuális verziója elérhető a címen Ez a dokumentumtípus beágyazott, PAdES szabványú elektronikus aláírást tartalmazhat. A PAdES aláírás szerkezetét és adattartalmát számos korábbi műszaki előírás után jelenleg az EN európai szabványcsalád (EN és EN ) rögzíti, amely szabadon elérhető az ETSI honlapjáról. Ugyanakkor a 2015/1506 EU bizottsági végrehajtási határozat szerint elfogadott az ETSI TS v műszaki előírás szerinti PAdES formátum használata is. A KEAESZ alkalmas a PAdES aláírások egyszerű és időbélyeggel ellátott változatainak ellenőrzésére is XML elektronikus aláírások Az XML a W3C által kidolgozott, különböző adattípusok leírására képes, általános célú leíró nyelv, a jelenleg érvényes verziója (Extensible Markup Language (XML) 1.0 (Fifth Edition)) a címen érhető el. Az elsődleges célja strukturált szöveg és információ megosztása az interneten keresztül. Egy XML dokumentum tartalma és felépítése a szabvány keretein belül szabadon meghatározható, lényegében tetszőleges adat hordozására alkalmas. A fentiekből következően egy XML dokumentumba lényegében bármilyen állomány beágyazható és így alá is írható. Az eredeti XML aláírás specifikációt is a W3C dolgozta ki, a jelenleg érvényes verziója (XML Signature Syntax and Processing Version 1.1) a címen érhető el. 143

144 Az XML alapú megjelenítés ugyanakkor strukturálisan három különböző megoldást is lehetővé tesz, ami az aláírás és a dokumentum egymáshoz való kapcsolatát jellemzi. Az egységesítés és könnyebb feldolgozás, az interoperabilitás érdekében a Magyar Elektronikus Aláírás Szövetség a szabványok biztosította lehetőségen belül egy egységes formátum kezelésére adott ki ajánlást. Ez az ún. MELASZ Ready 2.0 formátum. A magyar közigazgatás emellett használja még az úgynevezett dosszié formátumot is, amely több dokumentum együttes kezelésére kíván megoldásokat. Ezt a formátumot és korrekten kezeli a KEAESZ. 24. ábra: Az XML alapú elektronikus aláírások lehetséges elhelyezkedése Itt is jelezzük, hogy a hibrid másolatkészítés során nincs lehetőség az elválasztott, (detached) aláírások használatára, mivel az ott használt logikában az aláírás és az aláírt dokumentum együttes kezelés nem megoldott. Az XML formátumú, legalább fokozott biztonságú (azaz közigazgatásban az egyéb feltételek fennállása esetén felhasználható) elektronikus aláírások szerkezetét és adattartalmát számos korábbi műszaki előírás után jelenleg az EN európai szabványcsalád (EN és EN ) rögzíti, amely szabadon elérhető az ETSI honlapjáról. Ugyanakkor a 2015/1506 EU bizottsági végrehajtási határozat szerint elfogadott az ETSI TS v műszaki előírás szerinti XAdES formátum használata is. 144

145 A KEAESZ az XML dokumentumként létrehozott XAdES szabványú elektronikus aláírást bármelyik fentebb említett formátumban képes értelmezni, legyen az aláírt dokumentum különálló fájlban (ebben az esetben azt is fel kell tölteni, amire a kezdőoldal lehetőséget ad), vagy magában az XML dokumentumban tárolva. A szolgáltatás alkalmas a XAdES aláírások egyszerű és időbélyeggel ellátott változatainak ellenőrzésére is ASiC formátum Az ASiC egy korszerű, nemzetközi szabványon alapuló tároló formátum, amely alkalmas aláírások és időbélyegek fogadására is (az állomány nevének kiterjesztése az ajánlások szerint.asics, vagy.asice) A tároló alkalmas több elektronikusan aláírt dokumentum tárolására is a hozzájuk tartozó elektronikus aláírásokkal együtt. Nem szükségszerű az sem, hogy minden aláírás vagy időbélyeg minden ott szereplő állományra vonatkozzon. Az állomány tulajdonképpen egy ZIP konténer meghatározott belső szerkezettel. A KEAESZ alkalmas az ASiC-S (egyszerű) és ASiC-E (kiterjesztett) formátumban tárolt elektronikus aláírások változatainak ellenőrzésére is. 25. ábra: ASiC-S (balról) és ASiC-E konténerek szerkezeti mintái az EN szabvány alapján Ez a formátum jelenleg a HKKR-ben nem alkalmazható, nincsenek meg azok a feldolgozó eljárások, amelyek a konténerekből értelmezhetővé tennék a tartalmat a feldolgozó rendszerek számára. Természetesen biztonságos kézbesítési szolgáltatással ezt a formátumot is lehet továbbítani. Az ASIC-S vagy ASIC-E formátumú, aláírásokat és időbélyeget hordozó konténerek szerkezetét és adattartalmát jelenleg az EN európai szabványcsalád (EN és EN ) rögzíti, amely szabadon elérhető az ETSI honlapjáról. Ugyanakkor a 2015/1506 EU bizottsági végrehajtási határozat szerint elfogadott az ETSI TS v műszaki előírás szerinti ASiC konténerek használata is. 145

146 4.3.2 Az ellenőrzés folyamata A dokumentum ellenőrzésének feltétele még az ÁSZF elfogadása a kiválasztó négyzet bejelölésével. A KEAESZ szolgáltatás a *.pdf állományokat és a *.asic konténereket amelyek tartalmazzák az aláírást tudja ellenőrizni Az ezektől eltérő fájltípusok aláírását akkor tudja ellenőrizni a szolgáltatás, ha az aláírást az eredeti fájlhoz tartozó *.xml kiterjesztésű fájl tartalmazza, ezen túlmenően kezeli az e-akta *.es3 kiterjesztésű állományait is. Ezután indul az állományok feltöltése és feldolgozása, ami elég hosszú időt vesz igénybe még kis méretű állományok esetében is, tekintve, hogy egyenként kell lekérni hozzá az összes információt a szolgáltatóktól. 26. ábra: KEASZ munka közben Amennyiben a feltöltött dokumentum tartalmaz elektronikus aláírást, a rendszer az alábbi válaszol egyikét jeleníti meg a képernyőn. Abban az esetben, ha a válasz az Aláírás érvényes!", a rendszer azonosította az elektronikus aláírást és érvényesnek találta azt. 146

147 Ha a válasz az Aláírás érvénytelen!", a rendszer azonosította az elektronikus aláírást, de valamilyen okból azt érvénytelennek találta. 27. ábra: Egy eredménytelen (meghatározhatatlan) érvényesítés Gyakran fordul elő, hogy a rendszernek nem sikerül egyértelműen megállapítania, hogy az aláírás érvényes, vagy érvénytelen, ekkor az ellenőrzés eredménye Nem megállapítható Amennyiben Nincs aláírás!" felirat jelenik meg, a dokumentum nem tartalmaz aláírást. A rövid értékelésen túlmenően, amennyiben szükség van a KEAESZ vizsgálat elektronikus vagy nyomtatott formában történő archiválására, úgy az Ellenőrzés eredményének letöltése" gomb megnyomásával a felhasználó egy az értékelt fájl nevének _validation-nal történő kiegészítésével kapott PDF állományba mentheti az érvényesítés eredményét Itt kissé részletesebb az értékelés, és amennyiben időbélyegzést is talál, arra vonatkozóan külön elvégzi a rendszer az értékelést. A pdf állomány jelzi, illetve a feltöltött dokumentumon található aláírás(ok)at és időbélyeg(ek)et. Az elektronikus állomány hitelessége érdekében minősített tanúsítványon alapuló fokozott biztonságú elektronikus bélyegzővel és minősített időbélyegzéssel is el van látva. 147

148 28. ábra: A KEAESZ által szolgáltatott PDF formátumú igazolás az érvényesítésről A pdf dokumentumhoz tartozik három beágyazott csatolmány fájl, ami részletes, rendszerezett információt ad az aláírás ellenőrzés eredményének értelmezéséhez, esetenként felülbírálatához, mivel a benne rögzített tények alapján esetenként más következtetésre is lehet jutni az átmeneti időszak bizonytalanságai miatt. simple_report.xml (XML formában tartalmazza az aláírás ellenőrzés összefoglaló eredményét) detailed_report.xml (XML formában tartalmazza az aláírás ellenőrzés részletes eredményét) diagnostic_report.xml (XML formában tartalmazza az aláírás ellenőrzés diagnosztikai eredményét) 4.4 A három információs állomány szerkezete A három dokumentumot a szerkezetüket meghatározó XML séma fájlok segítségével mutatjuk be. Ezek támpontot adnak arra vonatkozóan, mely kérdéseket vizsgál a rendszer, illetve milyen értékeket (állapotokat) vehetnek fel az egyes változók. Fontos tudni, hogy a három állományt három független folyamat állítja elő az érvényesítés során, így az sem zárható teljes mértékben ki, hogy az egyes információcsomagok nem teljesen azonos következtetéseket alapoznak meg. Ez pusztán arra mutat rá, hogy bár ezen a területen elvileg a matematikai logika 148

149 szabályok folytán szigorúan determinisztikus eredményekre kellene jutni, a szabályozás elégtelensége miatt ez az elvárás nem minden esetben teljesül Az egyszerű riport XML állomány szerkezete Az összefoglaló információt a simple_report.xml tartalmazza, de már ez is lényegesen több információt rögzít a dokumentumról és az aláírásáról, mint az olvasható pdf dokumentum. <?xml version="1.0" encoding="utf-8"?> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns=" xmlns:xs=" <xs:element name="simplereport"> <xs:complextype> <xs:sequence> <xs:element name="policy"> <xs:complextype> <xs:sequence> <xs:element type="xs:string" name="policyname" /> <xs:element type="xs:string" name="policydescription" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element type="xs:datetime" name="validationtime" /> <xs:element type="xs:string" name="documentname" /> <xs:element type="xs:int" name="validsignaturescount" /> <xs:element type="xs:int" name="signaturescount" /> <xs:element type="xs:string" name="containertype" minoccurs="0" /> <xs:element name="signature" maxoccurs="unbounded" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element type="xs:string" name="filename" minoccurs="0" /> <xs:element type="xs:datetime" name="signingtime" minoccurs="0" /> <xs:element type="xs:string" name="signedby" /> <xs:element name="certificatechain" type="certificatechain" /> <xs:element type="signaturelevel" name="signaturelevel" minoccurs="0" /> <xs:element type="indication" name="indication" /> <xs:element type="subindication" name="subindication" minoccurs="0" /> <xs:element type="xs:string" name="errors" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="xs:string" name="warnings" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="xs:string" name="infos" minoccurs="0" maxoccurs="unbounded" /> <xs:element name="signaturescope" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute type="xs:string" name="name"/> <xs:attribute type="xs:string" name="scope"/> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute type="xs:string" name="id" use="required" /> <xs:attribute type="xs:boolean" name="countersignature" use="optional" /> <xs:attribute type="xs:string" name="parentid" use="optional" /> <xs:attribute type="xs:string" name="signatureformat" use="required" /> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="indication" final="restriction"> <xs:restriction base="xs:string"> 149

150 <xs:enumeration value="total_passed" /> <xs:enumeration value="indeterminate" /> <xs:enumeration value="total_failed" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="subindication" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="no_signing_certificate_found" /> <xs:enumeration value="format_failure" /> <xs:enumeration value="signature_policy_not_available" /> <xs:enumeration value="policy_processing_error" /> <xs:enumeration value="out_of_bounds_no_poe" /> <xs:enumeration value="no_certificate_chain_found" /> <xs:enumeration value="try_later" /> <xs:enumeration value="revoked_no_poe" /> <xs:enumeration value="revoked_ca_no_poe" /> <xs:enumeration value="chain_constraints_failure" /> <xs:enumeration value="crypto_constraints_failure" /> <xs:enumeration value="crypto_constraints_failure_no_poe" /> <xs:enumeration value="signed_data_not_found" /> <xs:enumeration value="hash_failure" /> <xs:enumeration value="sig_crypto_failure" /> <xs:enumeration value="sig_constraints_failure" /> <xs:enumeration value="not_yet_valid" /> <xs:enumeration value="timestamp_order_failure" /> <xs:enumeration value="revoked" /> <xs:enumeration value="expired" /> <xs:enumeration value="no_poe" /> <xs:enumeration value="certificate_chain_general_failure" /> <xs:enumeration value="unexpected_error" /> </xs:restriction> </xs:simpletype> <xs:complextype name="signaturelevel"> <xs:simplecontent> <xs:extension base="signaturequalification"> <xs:attribute name="description" type="xs:string" /> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:simpletype name="signaturequalification" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="qesig" /> <xs:enumeration value="qeseal" /> <xs:enumeration value="qes?" /> <xs:enumeration value="adesig-qc" /> <xs:enumeration value="adeseal-qc" /> <xs:enumeration value="ades?-qc" /> <xs:enumeration value="adesig" /> <xs:enumeration value="adeseal" /> <xs:enumeration value="ades?" /> <xs:enumeration value="indeterminate QESig" /> <xs:enumeration value="indeterminate QESeal" /> <xs:enumeration value="indeterminate QES?" /> <xs:enumeration value="indeterminate AdESig-QC" /> <xs:enumeration value="indeterminate AdESeal-QC" /> <xs:enumeration value="indeterminate AdES?-QC" /> <xs:enumeration value="indeterminate AdESig" /> <xs:enumeration value="indeterminate AdESeal" /> <xs:enumeration value="indeterminate AdES?" /> <xs:enumeration value="not AdES but QC with QSCD" /> <xs:enumeration value="not AdES but QC" /> <xs:enumeration value="not AdES" /> <xs:enumeration value="n/a" /> </xs:restriction> </xs:simpletype> <xs:complextype name="certificatechain"> <xs:sequence> <xs:element name="certificate" type="certificate" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> 150

151 </xs:complextype> <xs:complextype name="certificate"> <xs:sequence> <xs:element type="xs:string" name="id" /> <xs:element type="xs:string" name="qualifiedname" /> </xs:sequence> </xs:complextype> </xs:schema> 29. ábra: A simple_report.xml szerkezete. TOTAL_PASSED INDETERMINATE TOTAL_FAILED Az érvényesítés összességében sikeres Az eredmény nem meghatározható Az érvényesítés összességében sikertelen 13. táblázat: Az Indication javallatok az érvényesítés eredménye tag felvehető értékei e vizsgálati jelentésben 151

152 NO_SIGNING_CERTIFICATE_FOUND FORMAT_FAILURE SIGNATURE_POLICY_NOT_AVAILABLE POLICY_PROCESSING_ERROR OUT_OF_BOUNDS_NO_POE NO_CERTIFICATE_CHAIN_FOUND TRY_LATER REVOKED_NO_POE REVOKED_CA_NO_POE CHAIN_CONSTRAINTS_FAILURE CRYPTO_CONSTRAINTS_FAILURE CRYPTO_CONSTRAINTS_FAILURE_NO_POE SIGNED_DATA_NOT_FOUND HASH_FAILURE SIG_CRYPTO_FAILURE SIG_CONSTRAINTS_FAILURE NOT_YET_VALID TIMESTAMP_ORDER_FAILURE REVOKED EXPIRED NO_POE CERTIFICATE_CHAIN_GENERAL_FAILURE UNEXPECTED_ERROR Nem talált aláíró tanúsítványt Formátumhiba Aláírási rend nem elérhető Aláírási rend feldolgozási hiba A határokon kívül nincs bizonyíték Nem lehetett bizalmi láncot találni Próbálja meg később (pl. a visszavonási lista nem volt elérhető) Visszavonták, nincs bizonyíték Visszavonták a hitelesítés-szolgáltató (tanúsítványát), nincs tanúsítvány Lánccal kapcsolatos korlátozás hiba Kriptográfiai korlátozás hiba Kriptográfiai korlátozás hiba, nincs bizonyíték Az aláírt adat nem található Lenyomat(képzési) hiba Aláírás kriptográfiai hiba Aláírással kapcsolatos korlátozás hiba Jelenleg nem érvényes Hiba az időbélyegzések sorrendjében Visszahívták Lejárt Nincs bizonyíték Bizalmi lánc általános hiba Váratlan, nem kezelt hiba 14. táblázat: Subindications kiegészítő információ az érvényesítéshez tag felvehető értékei QESig QESeal QES? AdESig-QC AdESeal-QC AdES?-QC AdESig AdESeal AdES? Indeterminate QESig Indeterminate QESeal Indeterminate QES? Indeterminate AdESig-QC Indeterminate AdESeal-QC Indeterminate AdES?-QC Indeterminate AdESig Indeterminate AdESeal Indeterminate AdES? Minősített elektronikus aláírás Minősített elektronikus bélyegző Minősített elektronikus nem meghatározható Minősített tanúsítványon alapuló fokozott biztonságú aláírás Minősített tanúsítványon alapuló fokozott biztonságú bélyegző Minősített tanúsítványon alapuló fokozott biztonságú nem meghatározható célú tanúsítvány Fokozott biztonságú aláírás Fokozott biztonságú bélyegző Fokozott biztonságú nem meghatározható célú tanúsítvány Meghatározhatatlan, minősített elektronikus aláírás Meghatározhatatlan, minősített elektronikus bélyegző Meghatározhatatlan, minősített elektronikus nem meghatározható célú tanúsítványú Meghatározhatatlan, minősített tanúsítványon alapuló fokozott biztonságú aláírás Meghatározhatatlan, minősített tanúsítványon alapuló fokozott biztonságú bélyegző Meghatározhatatlan, minősített tanúsítványon alapuló fokozott biztonságú nem meghatározható célú tanúsítvány Meghatározhatatlan, fokozott biztonságú aláírás Meghatározhatatlan, fokozott biztonságú bélyegző Meghatározhatatlan, fokozott biztonságú nem meghatározható célú tanúsítvány 152

153 Not AdES but QC with QSCD Not AdES but QC Not AdES N/A Nem fokozott biztonságú de minősített tanúsítvány alapú és minősített aláíró eszközzel készített Nem fokozott biztonságú de minősített tanúsítvány alapú Nem fokozott biztonságú Nem alkalmazható 15. táblázat: a tanúsítványok lehetséges minősítése (jelölések) Összességében ez az XML állomány megadja a legfontosabb tulajdonságokat és az aláírások, illetve bélyegzők legfontosabb tulajdonságait. ha azonban kétség merül fel egy aláírás érvényessége vonatkozásában, akkor célszerű a részletes elemzést is figyelembe venni A részletes riport XML állomány szerkezete A részletes riport tételesen végig vizsgálja az aláírt dokumentum érvényességéhez szükséges elemeket és egyenként is megállításokat tesz azokról. Ennek megfelelően, ha valamit részletesen akarunk megnézni egy aláírás érvényessége szempontjából, azt itt érdemes keresni. <?xml version="1.0" encoding="utf-8"?> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns=" xmlns:xs=" <xs:element name="detailedreport"> <xs:complextype> <xs:sequence> <xs:element type="signature" name="signatures" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="basicbuildingblocks" name="basicbuildingblocks" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="tlanalysis" name="tlanalysis" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="signature"> <xs:sequence> <xs:element type="validationprocessbasicsignatures" name="validationprocessbasicsignatures" minoccurs="0" /> <xs:element type="validationprocesstimestamps" name="validationprocesstimestamps" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="validationprocesslongtermdata" name="validationprocesslongtermdata" minoccurs="0" /> <xs:element type="validationprocessarchivaldata" name="validationprocessarchivaldata" minoccurs="0" /> <xs:element type="validationsignaturequalification" name="validationsignaturequalification" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="countersignature" type="xs:boolean" use="optional" /> </xs:complextype> <xs:complextype name="basicbuildingblocks"> <xs:sequence> <xs:element type="fc" name="fc" minoccurs="0" /> <xs:element type="isc" name="isc" minoccurs="0" /> <xs:element type="vci" name="vci" minoccurs="0" /> <xs:element type="cv" name="cv" minoccurs="0" /> <xs:element type="sav" name="sav" minoccurs="0" /> <xs:element type="xcv" name="xcv" minoccurs="0" /> <xs:element type="psv" name="psv" minoccurs="0" /> <xs:element type="pcv" name="pcv" minoccurs="0" /> <xs:element type="vts" name="vts" minoccurs="0" /> <xs:element name="certificatechain" type="certificatechain" /> 153

154 <xs:element type="conclusion" name="conclusion" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="type" type="context" use="required" /> </xs:complextype> <xs:complextype name="tlanalysis"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:attribute name="countrycode" type="xs:string" use="required" /> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="validationsignaturequalification"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="signaturequalification" type="signaturequalification" use="optional" /> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="constraintsconclusion"> <xs:sequence> <xs:element type="constraint" name="constraint" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="conclusion" name="conclusion" /> </xs:sequence> </xs:complextype> <xs:complextype name="validationprocessbasicsignatures"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="validationprocesstimestamps"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="type" type="xs:string" use="required" /> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="validationprocesslongtermdata"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="validationprocessarchivaldata"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="fc"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="isc"> <xs:complexcontent> <xs:extension base="constraintsconclusion" > <xs:sequence> <xs:element name="certificatechain" type="certificatechain" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="vci"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> 154

155 <xs:complextype name="rfc"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="cv"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="sav"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="xcv"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:sequence> <xs:element name="subxcv" type="subxcv" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="subxcv"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:sequence> <xs:element name="rfc" type="rfc" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="trustanchor" type="xs:boolean" /> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="vts"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:sequence> <xs:element name="controltime" type="xs:datetime" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="pcv"> <xs:complexcontent> <xs:extension base="constraintsconclusion"> <xs:sequence> <xs:element name="controltime" type="xs:datetime" minoccurs="0" /> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="psv"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="erv"> <xs:complexcontent> <xs:extension base="constraintsconclusion" /> </xs:complexcontent> </xs:complextype> <xs:complextype name="constraint"> <xs:sequence> <xs:element type="name" name="name" /> <xs:element type="status" name="status" /> <xs:element type="name" name="error" minoccurs="0" /> <xs:element type="name" name="warning" minoccurs="0" /> <xs:element type="name" name="info" minoccurs="0" /> <xs:element type="xs:string" name="additionalinfo" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="optional" /> <!-- In case of constraint with a BBB --> </xs:complextype> 155

156 <xs:complextype name="conclusion"> <xs:sequence> <xs:element type="indication" name="indication" /> <xs:element type="subindication" name="subindication" minoccurs="0" /> <xs:element type="name" name="errors" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="name" name="warnings" minoccurs="0" maxoccurs="unbounded" /> <xs:element type="name" name="infos" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="name"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="nameid" type="xs:string" /> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:simpletype name="status" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="ok" /> <xs:enumeration value="not OK" /> <xs:enumeration value="ignored" /> <xs:enumeration value="information" /> <xs:enumeration value="warning" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="indication" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="passed" /> <xs:enumeration value="indeterminate" /> <xs:enumeration value="failed" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="subindication" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="no_signing_certificate_found" /> <xs:enumeration value="format_failure" /> <xs:enumeration value="signature_policy_not_available" /> <xs:enumeration value="policy_processing_error" /> <xs:enumeration value="out_of_bounds_no_poe" /> <xs:enumeration value="no_certificate_chain_found" /> <xs:enumeration value="try_later" /> <xs:enumeration value="revoked_no_poe" /> <xs:enumeration value="revoked_ca_no_poe" /> <xs:enumeration value="chain_constraints_failure" /> <xs:enumeration value="crypto_constraints_failure" /> <xs:enumeration value="crypto_constraints_failure_no_poe" /> <xs:enumeration value="signed_data_not_found" /> <xs:enumeration value="hash_failure" /> <xs:enumeration value="sig_crypto_failure" /> <xs:enumeration value="sig_constraints_failure" /> <xs:enumeration value="not_yet_valid" /> <xs:enumeration value="timestamp_order_failure" /> <xs:enumeration value="revoked" /> <xs:enumeration value="expired" /> <xs:enumeration value="no_poe" /> <xs:enumeration value="certificate_chain_general_failure" /> <xs:enumeration value="unexpected_error" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="signaturequalification" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="qesig" /> <xs:enumeration value="qeseal" /> <xs:enumeration value="qes?" /> <xs:enumeration value="adesig-qc" /> <xs:enumeration value="adeseal-qc" /> <xs:enumeration value="ades?-qc" /> <xs:enumeration value="adesig" /> <xs:enumeration value="adeseal" /> <xs:enumeration value="ades?" /> 156

157 <xs:enumeration value="indeterminate QESig" /> <xs:enumeration value="indeterminate QESeal" /> <xs:enumeration value="indeterminate QES?" /> <xs:enumeration value="indeterminate AdESig-QC" /> <xs:enumeration value="indeterminate AdESeal-QC" /> <xs:enumeration value="indeterminate AdES?-QC" /> <xs:enumeration value="indeterminate AdESig" /> <xs:enumeration value="indeterminate AdESeal" /> <xs:enumeration value="indeterminate AdES?" /> <xs:enumeration value="not AdES but QC with QSCD" /> <xs:enumeration value="not AdES but QC" /> <xs:enumeration value="not AdES" /> <xs:enumeration value="n/a" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="context" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="signature" /> <xs:enumeration value="counter_signature" /> <xs:enumeration value="timestamp" /> <xs:enumeration value="revocation" /> </xs:restriction> </xs:simpletype> <xs:complextype name="certificatechain"> <xs:sequence> <xs:element name="chainitem" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="source" type="xs:string" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:schema> FC Format Checking Formátumellenőrzés ISC Identification of the Signing Certificate Aláíró tanúsítvány azonosítása VCI Validation Context Initialization Az érvényesítési környezet létrehozása RFC Revocation Freshness Checker A visszavonás frissességének ellenőrzése CV Cryptographic Verification Kriptográfiai érvényesítés SAV Signature Acceptance Validation Az aláírás elfogadásának érvényesítése XCV X.509 certificate validation X509 tanúsítvány érvényesítése PSV Past Signature Validation Múltbeli aláírás érvényesítés PCV Past Certificate Validation Múltbeli tanúsítvány érvényesítés VTS Validation Time Sliding process Az érvényesítési idő csúsztatási folyamata 16. táblázat: Az aláírás-ellenőrzés alapfolyamatai az EN szabvány szerint OK NOT OK IGNORED INFORMATION WARNING Rendben Nincs rendben Figyelmen kívül hagyva Információ Figyelmeztetés 17. táblázat: A részletes vizsgálat során felvető állapotok 157

158 158 Aláírás használati rend

159 159 Aláírás használati rend

160 160 Aláírás használati rend

161 161 Aláírás használati rend

162 30. ábra: A detailed_report.xml állomány szerkezete (5. oldal) Az ábrán a Name komplex típust nem bontottuk ki ott, ahol előfordult annak érdekében, hogy az ábra valamennyire áttekinthető maradjon 162

163 Az adatok egy része közös a rövid jelentéssel, ennek megfelelően a 14. táblázat: Subindications kiegészítő információ az érvényesítéshez tag felvehető értékei és a 15. táblázat: a tanúsítványok lehetséges minősítése (jelölések) táblákat nem ismételjük meg. Eltérő viszont az értékelés, tehát a 13. táblázat helyett az alábbi táblázat szükséges az összefoglaló értelmezéshez. PASSED INDETERNINATE FAILED Sikeres Meghatározatlan Sikertelen 18. táblázat: Az Indication javallatok az érvényesítés eredménye tag felvehető értékei a részletes vizsgálati jelentés XML állományában Ez a jelentés az aláírások esetében a környezetüket, (Context) a feladatkörüket is értékeli és ebből a szempontbók a következő aláírásokat különbözteti meg. SIGNATURE COUNTER_SIGNATURE TIMESTAMP REVOCATION Aláírás Ellenjegyző aláírás Időbélyeg Visszavonás 19. táblázat: Az aláírások környezetét (Context) leíró értékek Összefoglalva a részletes jelentés az aláírás érvényesítési folyamat minden elemére igyekszik kitérni és mindegyikre külön-külön is ad értékelést. A modell úgy van felépítve, hogy egyes kérdéskörökön belül csak az első hibáig folytatja a vizsgálatot, tehát ebben az értelemben kizárólag a pozitív válaszra lehet kijelenteni, hogy teljes értékű. Egy hibás negatív válasz után még lehetnek további rejtve maradó problémák is a korábban elvetett blokkon belül Diagnosztikai adatok A diagnosztikai adatok elsődlegesen magáról az aláírásról adnak információt, bár itt is vannak dinamikusan begyűjtendő adatok, mint például a visszavonásra vonatkozók, vagy az aláírási algoritmusok extrapolálásából származók. itt is igaz azonban, hogy a diagnosztika eredménye is jelentős mértékben függ az érvényesítési rendtől. A bemutatás során nem tértünk ki az aláírási konténerekkel kapcsolatos diagnosztikai elemekre, tekintve, hogy ezeket jelenleg a rendszerben nem lehet még használni. <?xml version="1.0" encoding="utf-8"?> <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" targetnamespace=" xmlns=" xmlns:xs=" <xs:element name="diagnosticdata"> <xs:complextype> <xs:sequence> <xs:element name="documentname" type="xs:string" /> <xs:element name="validationdate" type="xs:datetime" /> <xs:element name="containerinfo" type="containerinfo" minoccurs="0" /> <xs:element name="signatures" minoccurs="0"> <xs:complextype> 163

164 <xs:sequence> <xs:element name="signature" type="signature" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="usedcertificates" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="certificate" type="certificate" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="trustedlists" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="trustedlist" type="trustedlist" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="listoftrustedlists" type="trustedlist" minoccurs="0" /> </xs:sequence> </xs:complextype> </xs:element> <xs:complextype name="containerinfo"> <xs:sequence> <xs:element name="containertype" type="xs:string" minoccurs="0" /> <xs:element name="zipcomment" type="xs:string" minoccurs="0" /> <xs:element name="mimetypefilepresent" type="xs:boolean" minoccurs="0" /> <xs:element name="mimetypecontent" type="xs:string" minoccurs="0" /> <xs:element name="manifestfiles" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="manifestfile" type="manifestfile" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="contentfiles" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="contentfile" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="manifestfile"> <xs:sequence> <xs:element name="filename" type="xs:string" minoccurs="0" /> <xs:element name="signaturefilename" type="xs:string" minoccurs="0" /> <xs:element name="entries" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="entry" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="signature"> <xs:sequence> <xs:element name="signaturefilename" type="xs:string" /> <xs:element name="parentid" type="xs:string" minoccurs="0" /> <xs:element name="errormessage" type="xs:string" minoccurs="0" /> <xs:element name="datetime" type="xs:datetime" minoccurs="0" /> <xs:element name="signatureformat" type="xs:string" /> <xs:element name="structuralvalidation" type="structuralvalidation" minoccurs="0" /> 164

165 <xs:element name="basicsignature" type="basicsignature" /> <xs:element name="signingcertificate" type="signingcertificate" minoccurs="0" /> <xs:element name="certificatechain" type="certificatechain" minoccurs="0" /> <xs:element name="contenttype" type="xs:string" minoccurs="0" /> <xs:element name="contentidentifier" type="xs:string" minoccurs="0" /> <xs:element name="contenthints" type="xs:string" minoccurs="0" /> <xs:element name="signatureproductionplace" type="signatureproductionplace" minoccurs="0" /> <xs:element name="commitmenttypeindication" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="indication" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="claimedroles" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="claimedroles" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="certifiedroles" type="certifiedrole" minoccurs="0" maxoccurs="unbounded" /> <xs:element name="policy" type="policy" minoccurs="0" /> <xs:element name="timestamps" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="timestamp" type="timestamp" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="signaturescopes" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="signaturescope" type="signaturescope" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="countersignature" type="xs:boolean" use="optional" /> </xs:complextype> <xs:complextype name="signatureproductionplace"> <xs:sequence> <xs:element name="address" type="xs:string" minoccurs="0" /> <xs:element name="city" type="xs:string" minoccurs="0" /> <xs:element name="stateorprovince" type="xs:string" minoccurs="0" /> <xs:element name="postalcode" type="xs:string" minoccurs="0" /> <xs:element name="countryname" type="xs:string" minoccurs="0" /> </xs:sequence> </xs:complextype> <xs:complextype name="policy"> <xs:sequence> <xs:element name="id" type="xs:string" /> <xs:element name="url" type="xs:string" minoccurs="0" /> <xs:element name="notice" type="xs:string" minoccurs="0" /> <xs:element name="digestalgoandvalue" type="digestalgoandvalue" minoccurs="0" /> <xs:element name="asn1processable" type="xs:boolean" minoccurs="0" /> <xs:element name="identified" type="xs:boolean" minoccurs="0" /> <xs:element name="status" type="xs:boolean" minoccurs="0" /> <xs:element name="processingerror" type="xs:string" minoccurs="0" /> <xs:element name="digestalgorithmsequal" type="xs:boolean" minoccurs="0" /> </xs:sequence> </xs:complextype> <xs:complextype name="certificate"> 165

166 <xs:sequence> <xs:element name="subjectdistinguishedname" type="distinguishedname" maxoccurs="unbounded" /> <xs:element name="issuerdistinguishedname" type="distinguishedname" maxoccurs="unbounded" /> <xs:element name="serialnumber" type="xs:integer" /> <xs:element name="commonname" type="xs:string" minoccurs="0"/> <xs:element name="countryname" type="xs:string" minoccurs="0"/> <xs:element name="organizationname" type="xs:string" minoccurs="0"/> <xs:element name="givenname" type="xs:string" minoccurs="0"/> <xs:element name="organizationalunit" type="xs:string" minoccurs="0"/> <xs:element name="surname" type="xs:string" minoccurs="0"/> <xs:element name="pseudonym" type="xs:string" minoccurs="0"/> <xs:element name="authorityinformationaccessurls" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="url" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="crldistributionpoints" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="url" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="ocspaccessurls" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="url" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="digestalgoandvalues" type="digestalgoandvalues" minoccurs="0" /> <xs:element name="notafter" type="xs:datetime" /> <xs:element name="notbefore" type="xs:datetime" /> <xs:element name="publickeysize" type="xs:int" /> <xs:element name="publickeyencryptionalgo" type="xs:string" /> <xs:element name="keyusagebits" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="keyusage" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="idkpocspsigning" type="xs:boolean" minoccurs="0" /> <xs:element name="idpkixocspnocheck" type="xs:boolean" minoccurs="0" /> <xs:element name="basicsignature" type="basicsignature" /> <xs:element name="signingcertificate" type="signingcertificate" minoccurs="0" /> <xs:element name="certificatechain" type="certificatechain" minoccurs="0" /> <xs:element name="trusted" type="xs:boolean" /> <xs:element name="selfsigned" type="xs:boolean" /> <xs:element name="certificatepolicyids" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="oid" type="oid" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="qcstatementids" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="oid" type="oid" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> 166

167 </xs:element> <xs:element name="qctypes" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="oid" type="oid" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="trustedserviceproviders"> <xs:complextype> <xs:sequence> <xs:element name="trustedserviceprovider" type="trustedserviceprovider" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="revocations" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="revocation" type="revocation" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="info" type="infotype" minoccurs="0" /> <xs:element name="base64encoded" type="xs:base64binary" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complextype> <xs:complextype name="oid"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="description" type="xs:string" use="optional" /> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:complextype name="distinguishedname"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="format" type="xs:string" use="optional" /> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:complextype name="signaturescope"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required" /> <xs:attribute name="scope" type="xs:string" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:complextype name="structuralvalidation"> <xs:sequence> <xs:element name="valid" type="xs:boolean" minoccurs="0" /> <xs:element name="message" type="xs:string" minoccurs="0" /> </xs:sequence> </xs:complextype> <xs:complextype name="basicsignature"> <xs:sequence> <xs:element name="encryptionalgousedtosignthistoken" type="xs:string" minoccurs="0" /> <xs:element name="keylengthusedtosignthistoken" type="xs:string" minoccurs="0" /> <xs:element name="digestalgousedtosignthistoken" type="xs:string" minoccurs="0" /> <xs:element name="maskgenerationfunctionusedtosignthistoken" type="xs:string" minoccurs="0" /> <xs:element name="referencedatafound" type="xs:boolean" /> <xs:element name="referencedataintact" type="xs:boolean" /> <xs:element name="signatureintact" type="xs:boolean" /> <xs:element name="signaturevalid" type="xs:boolean" /> </xs:sequence> 167

168 </xs:complextype> <xs:complextype name="signingcertificate"> <xs:sequence> <xs:element name="attributepresent" type="xs:boolean" minoccurs="0" /> <xs:element name="digestvaluepresent" type="xs:boolean" minoccurs="0" /> <xs:element name="digestvaluematch" type="xs:boolean" minoccurs="0" /> <xs:element name="issuerserialmatch" type="xs:boolean" minoccurs="0" /> <xs:element name="signed" type="xs:string" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complextype> <xs:complextype name="infotype"> <xs:sequence> <xs:element name="message" maxoccurs="unbounded" minoccurs="0"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="id" type="xs:int" use="required" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="timestampedobjects"> <xs:sequence> <xs:element name="timestampedobject" type="timestampedobject" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="timestampedobject"> <xs:sequence> <xs:element name="digestalgoandvalue" type="digestalgoandvalue" minoccurs="0" maxoccurs="1" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="optional" /> <xs:attribute name="category" type="timestampedobjecttype" use="required" /> </xs:complextype> <xs:simpletype name="timestampedobjecttype" final="restriction"> <xs:restriction base="xs:string"> <xs:enumeration value="certificate" /> <xs:enumeration value="signature" /> <xs:enumeration value="timestamp" /> <xs:enumeration value="revocation" /> </xs:restriction> </xs:simpletype> <xs:complextype name="certificatechain"> <xs:sequence> <xs:element name="chainitem" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="source" type="xs:string" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="certifiedrole"> <xs:sequence> <xs:element name="certifiedrole" type="xs:string" /> <xs:element name="notafter" type="xs:datetime" /> <xs:element name="notbefore" type="xs:datetime" /> </xs:sequence> <xs:attribute name="category" type="xs:string" use="required" /> </xs:complextype> <xs:complextype name="digestalgoandvalue"> <xs:sequence> <xs:element name="digestmethod" type="xs:string" /> 168

169 <xs:element name="digestvalue" type="xs:string" /> </xs:sequence> </xs:complextype> <xs:complextype name="timestamp"> <xs:sequence> <xs:element name="productiontime" type="xs:datetime" /> <xs:element name="signeddatadigestalgo" type="xs:string" /> <xs:element name="encodedsigneddatadigestvalue" type="xs:string" /> <xs:element name="messageimprintdatafound" type="xs:boolean" /> <xs:element name="messageimprintdataintact" type="xs:boolean" /> <xs:element name="canonicalizationmethod" type="xs:string" minoccurs="0" /> <xs:element name="basicsignature" type="basicsignature" /> <xs:element name="signingcertificate" type="signingcertificate" minoccurs="0" /> <xs:element name="certificatechain" type="certificatechain" minoccurs="0" /> <xs:element name="timestampedobjects" type="timestampedobjects" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> <xs:attribute name="type" type="xs:string" use="required" /> </xs:complextype> <xs:complextype name="revocation"> <xs:sequence> <xs:element name="origin" type="xs:string" /> <xs:element name="source" type="xs:string" /> <xs:element name="sourceaddress" type="xs:string" minoccurs="0" /> <xs:element name="available" type="xs:boolean" minoccurs="0" /> <xs:element name="status" type="xs:boolean" /> <xs:element name="reason" type="xs:string" minoccurs="0" /> <xs:element name="productiondate" type="xs:datetime" minoccurs="0" /> <!-- Can be null in case of no SUCCESSFUL response of OCSP --> <xs:element name="thisupdate" type="xs:datetime" minoccurs="0" /> <xs:element name="nextupdate" type="xs:datetime" minoccurs="0" /> <xs:element name="revocationdate" type="xs:datetime" minoccurs="0" /> <xs:element name="expiredcertsoncrl" type="xs:datetime" minoccurs="0" /> <!-- CRL --> <xs:element name="archivecutoff" type="xs:datetime" minoccurs="0" /> <!-- OCSP --> <xs:element name="digestalgoandvalues" type="digestalgoandvalues" minoccurs="0" /> <xs:element name="basicsignature" type="basicsignature" minoccurs="0" /> <!-- Can be null in case of no SUCCESSFUL response of OCSP --> <xs:element name="signingcertificate" type="signingcertificate" minoccurs="0" /> <xs:element name="certificatechain" type="certificatechain" minoccurs="0" /> <xs:element name="info" type="infotype" minoccurs="0" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complextype> <xs:complextype name="trustedlist"> <xs:sequence> <xs:element name="countrycode" type="xs:string" /> <xs:element name="url" type="xs:string" /> <xs:element name="sequencenumber" type="xs:int" minoccurs="0" /> <xs:element name="version" type="xs:int" minoccurs="0" /> <xs:element name="lastloading" type="xs:datetime" minoccurs="0" /> <xs:element name="issuedate" type="xs:datetime" minoccurs="0" /> <xs:element name="nextupdate" type="xs:datetime" minoccurs="0" /> <xs:element name="wellsigned" type="xs:boolean" /> </xs:sequence> </xs:complextype> <xs:complextype name="trustedserviceprovider"> <xs:sequence> <xs:element name="tspname" type="xs:string" /> <xs:element name="tspservicename" type="xs:string" /> <xs:element name="countrycode" type="xs:string" /> <xs:element name="trustedservices"> <xs:complextype> <xs:sequence> <xs:element name="trustedservice" type="trustedservice" minoccurs="0" maxoccurs="unbounded" /> 169

170 </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="trustedservice"> <xs:sequence> <xs:element name="servicetype" type="xs:string" /> <xs:element name="status" type="xs:string" /> <xs:element name="startdate" type="xs:datetime" /> <xs:element name="enddate" type="xs:datetime" minoccurs="0" /> <xs:element name="capturedqualifiers" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="qualifier" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="additionalserviceinfouris" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="uri" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="servicesupplypoints" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="uri" type="xs:string" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="expiredcertsrevocationinfo" type="xs:datetime" minoccurs="0" /> </xs:sequence> </xs:complextype> <xs:complextype name="digestalgoandvalues"> <xs:sequence> <xs:element name="digestalgoandvalue" type="digestalgoandvalue" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> </xs:schema> Mint látható a jelentés igyekszik az összes az aláírással kapcsolatos tulajdonságot bemutatni, azonban itt is igaz, hogy amennyiben az értelmezés egy ponton megakad, az annál mélyebb folyamatokban maradhat még hiba a jelzett hiányosságok elhárítása után. Ennek megfelelően alapesetben csak teljes értékben sikeres diagnosztikai jelentés esetén bízhatunk abban, hogy az elkészített aláírás és környezete megfelel a jogi előírásoknak. Ugyanakkor figyelni kell arra is, hogy a jogi szabályozás egyes pontokon eltér (vagy egyszerűen nem rendez) a szabványokban rögzített-től. Ahol a jogviszony két fél megállapodásán alapul, ott célszerű minél inkább a szabványokat követő megoldásokat alkalmazni, mert arra általában rendelkezésre állnak megfelelő támogató megoldások, de a közjogi viszonyokban arra is figyelemmel kell lenni, hogy ott kizárólag az kérhető számon, amit jogszabály tételesen rögzít, minden egyéb megengedett, nem tilalmazható. 170

171 171 Aláírás használati rend

172 172 Aláírás használati rend

173 31. ábra: A diagnosztikai jelentés struktúrája A három jelentés együttesen igen alapos elemzését adja minden elektronikus aláírással és bélyegzővel kapcsolatos elemnek, és ha azokat megfelelően értelmezzük, ezek a megoldások a hagyományos papír alapú megoldásokhoz képest lényegesen nagyobb biztonságot, megbízhatóságot képesek nyújtani. 173

174 5 sz. melléklet: A PDF igazolások manuális ellenőrzésének gyakorlati lebonyolítása Az eidas rendelet hatályba lépését követő időszakban, a változó szabványkövetelmények miatt jelentős a bizonytalanság tapasztalható az aláírások érvényességének gépi vizsgálatának megvalósításában, annak megbízhatóságában. Sorozatosan lehet olyan helyzetbe kerülni, hogy akár egyébként helyesen működő aláírás-ellenőrző alkalmazások sem képesek egyes, egyébként a jogi követelményeknek megfelelő aláírásokat érvényesként megjelölni. Ez különösen igaz a PDF dokumentumok aláírására szolgáló PADES aláírásokra, mivel az eidas végrehajtási rendelete más (korábbi) műszaki előírást tekint alapnak, mint az érvényes európai szabvány. A Bizottság (EU) 2015/1506 Végrehajtási Határozata (2015. szeptember 8.) a belső piacon történő elektronikus tranzakciókhoz kapcsolódó elektronikus azonosításról és bizalmi szolgáltatásokról szóló 910/2014/EU európai parlamenti és tanácsi rendelet 27. cikkének (5) bekezdése és 37. cikkének (5) bekezdése szerint a közigazgatási szervek által elismert fokozott biztonságú elektronikus aláírások és fokozott biztonságú bélyegzők formátumaira vonatkozó specifikációk meghatározásáról az ETSI TS v műszaki előírást tekinti alapnak. Ez egy 2013 áprilisában elfogadott dokumentum, amely azonban nem vált európai szabvánnyá. A határozat kiadásakor még nem létezett elfogadott szabvány. Ettől az Európai Bizottság mandátuma nyomán az ETSI (az Európai Unió távközlési szabványosítási szervezete) által 2016-ban elfogadtatott ETSI EN V1.1.1 ( ) szabvány (és ez már elfogadott európai szabvány) bizonyos elemeiben eltér. Ezek az eltérések okozzák, hogy bizonyos ellenőrzési eljárások eltérő eredményt adnak. A legteljesebb ellenőrzési lehetőséget tapasztalataink szerint a PDF aláírások vonatkozásában a PDF szabványt gondozó Adobe szoftvere biztosítja. Az itt található ismertetés kidolgozása során az általuk mindenki számára ingyenesen biztosított Acrobat Reader DC magyar nyelvű verzióját használtuk, és a használhatóságot ellenőriztük a verzióval is. A megfelelő használathoz célszerű először néhány beállítást elvégezni a programon. A leírás Windows operációs rendszer feltételezésével történik, de maga az Acrobat Reader mind OSX, mind Linux környezetre megvalósított, ott is hasonló módon kell a beállításokat és az ellenőrzést elvégezni 5.1 Beállítások Mivel ma már mind a három magyar bizalmi szolgáltató (Microsec, Netlock, NISZ) gyökértanúsítványai szerepelnek a Windows és a nagy böngészőgyártók megbízható gyökértanúsítványai között, az Acrobat Reader-t is célszerű úgy beállítani, hogy a Windows tanúsítványtárát használja a bizalmi láncok felépítéséhez. Ha esetleg, 174

175 bármilyen okból nem ezekre a gyökértanúsítványokra kívánná valaki a bizalmi láncot felépíteni, akkor a gyökértanúsítványt és az esetleges közbenső tanúsítványokat a Windows megfelelő tanúsítványtárába érdemes telepíteni. Erre a feladatra a Windows mmc applikációját érdemes használni, mely parancssorból is futtatható. Elsőként tehát nyissunk meg egy (tetszőleges) PDF állományt az Acrobat Reader-rel és válasszuk ki a Szerkesztés fül utolsó, Beállítások menüpontját. 32. ábra: A beállítások menü helye az Acrobat Reader DC-ben Ha kiválasztjuk ezt a menüelemet, akkor egy újabb menübe jutunk, ahol az Aláírások menüpontot kell kiválasztani. Mivel az adott feladatban csak az ellenőrzés beállítását vizsgáljuk, így értelemszerűen azt választjuk ki 33. ábra: A beállításokon belül az aláírás, és azon belül az ellenőrzés kiválasztása 175

176 A Tovább gomb lenyomását követően jutunk el arra a lapra, ahol a tényleges beállításokat el szükséges végezni, illetve a meglevőket le kell ellenőrizni. Az egyes beállításokat felülről lefelé tárgyaljuk (csak azokat, amelyeknek az érvénesség ellenőrzése szempontjából közvetlen jelentősége van. 34. ábra: Az aláírás-hitelesítés beállításai Az első beállítás alapvetően kényelmi célú, így biztosítható, hogy közvetlenül a dokumentum megnyitásakor ellenőrzésre kerüljön az aláírás. Ez ugyanakkor hálózati kapcsolatot és erőforrást igényel, ezek hiányában, első lépcsőben ki is lehet kapcsolni, és utóbb is van lehetőség arra, hogy az alkalmazással ellenőriztessük az aláírásokat. A második beállításnak csak ott van jelentősége, ahol a bizalmi láncok hiányoznak. Mivel esetünkben a Kormányzati Hitelesítésszolgáltató tanúsítványa már minden helyesen telepített és karbantartott Windows kliensben szerepel, célszerűbb ez a lehetőséget nem aktiválni és csak különleges eseteknél igénybe venni. Az ellenőrzés módjánál célszerű az eredeti értéket meghagyni, ami a dokumentumban elvileg elérhető módszert használja az aláírás ellenőrzésekor és csak ennek hiányában kísérli meg az alapértelmezett eljárást alkalmazni. A tanúsítvány-visszavonások ellenőrzése különös figyelmet érdemel. Elvileg az eidas rendelet 32. cikk (1) bekezdés c) pontja csak az aláírás időpontjában való érvényesség ellenőrzését igényli (és ezt a megkötést is csak a minősített aláírások 176

177 vonatkozásában rögzíti), azaz a tanúsítvány-visszavonások ellenőrzésének ezt a beállítását ki lehet kapcsolni, de ez a másik oldalról megnöveli a tévedés kockázatát. Az elmúlt időszakban a szabályozás változása miatt a tanúsítványok sűrű visszavonása zavart okozhat a dokumentumok hitelességének értelmezésében. Ez is aláhúzza, hogy minden kétséges esetben részletes elemzésre, a szoftver által biztosított adatok pontos értelmezésére van szükség ahhoz, hogy megítéljük valójában egy érvényes aláírással van-e dolgunk. Ha a lehető legóvatosabb ellenőrzési metódust akarjuk megvalósítani (ami éppen ezért jó néhány téves érvénytelenséget is jelezni fog), akkor ezt a négyzetet jelöljük be. Ezzel ellentétes az alatta levő, a lejárt időbélyegek használatát engedélyező négyzet, ugyanis különösen OCSP tanúsítványok esetén (amelyek érvényességi időtartamát több szolgáltató is igen rövidre állítja) igen könnyen ki lehet kerülni az időbélyegek érvényességi időtartamából, de ez, amennyiben a dokumentum egyébként sértetlen és a visszavonás nem kompromittálódás miatt történt (ami igen ritka), akkor az eredeti aláírási időpontra ezek érvényesek. Mivel a hibrid kézbesítési és konverziós rendszerben készített dokumentumok minden esetben tartalmaznak időbélyegzést is, így a következő blokkban mindenképpen indokolt a nagyobb biztonságot jelentő, Biztonsági idő (időbélyegző) beágyazása az aláírásba opciót kiválasztani. Ehhez az itt szereplő dokumentumok biztosítják a feltételeket. A hitelesítéséi adatok mentésére vonatkozóan az első opció kiválasztása látszik a legcélszerűbbnek, hiszen önmagában az ellenőrzés rögzítése nem lenne szükséges, annak a rögzítése csak hasznos információ, viszont érdemes megtenni, mert esetenként hasznos (ha nem is erős bizonyító erejű) információ lehet. Az utolsó blokkban szükséges kiválasztani, hogy a dokumentumok hitelességének ellenőrzésénél az Acrobat Reader a Windows tanúsítványtárát használja. Itt azonban figyelemmel kell lenni arra, hogy a Windows tanúsítványtárában sok olyan gyökértanúsítvány is szerepel, amelyek nem részei az eidas rendelet által létrehozott bizalmi listák rendszerének, így önmagában egy pozitív jelzés nem elég, fontos meggyőződni arról (lásd majd ott), hogy a gyökértanúsítvány szerepel-e az európai bizalmi listákon. Miután a fenti értékeket kiválasztottuk a rögzített értékeket az OK gombbal kell véglegesíteni. Kétség esetén a Súgó is ad bizonyos estekben támpontokat, bár az sem tárgyal minden lehetséges problémát. Az EU bizalmi lista (lásd eidas rendelet 22. cikk) aktuális verziójának figyelembe vételéhez még egy beállítást célszerű megvizsgálni, illetve frissíteni, mivel az automatizmus nem minden esetben működik. Ez az úgynevezett Megbízhatóságkezelő a 32. ábra szerinti beállítások menüpont alatt megjelenő lista alsó részében. Itt lehet kell az EU Bizalmi lista frissítését (lásd a bekeretezett mező) beállítani és egyúttal a listát frissíteni is, mivel ez a tapasztalatok szerint nem mindig történik meg. Célszerű ugyanakkor letiltani az Adobe saját 177

178 Adobe Approved Trusted List AATL szolgáltatását, mivel az ott szereplő szolgáltatók nem szükségszerűen szerepelnek az EU bizalmi listán így egy ott szereplő aláírással téves pozitív értékelést lehetne kapni. 35. ábra: A megbízhatóságkezelő javasolt beállítása Ezzel az ellenőrzési környezet előkészítése megtörtént, megkezdhetjük az ellenőrzést. 5.2 A hiteles másolatok ellenőrzése Töltsük le a hiteles másolatként megkapott dokumentumot a számítógépünkre (Ez jellemzően egy BKSZ küldemény része, és maga a hiteles másolat alapesetben egy PDF formátumú állomány). Nyissuk meg a dokumentumot. A Windows 10 operációs rendszer és több böngésző is rendelkezik saját PDF-olvasóval, mi azonban a korábban leírtak miatt az Acrobat Reader programmal történő megnyitást választjuk, az ellenőrzés leírása erre vonatkozik.) A hiteles másolatok a PDF formátumon belül is két formában készülhetnek. Az alapeset a szélesebb körű kompatibilitást biztosító, ugyanakkor több korlátozást tartalmazó, archiválásra is ajánlott PDF/A (más értelmezésben az 1.4) formátum. Ez a formátum aláírás nélkül is biztosít bizonyos integritásvédelmet, és ezt az aláírt dokumentumok esetén is megtartja. Erre figyelmeztet a kép felett megjelenő üzenet. Ez önmagában a dokumentum hitelességéről még semmit nem mond. 178

179 36. ábra: A PDF/A formátumú hiteles másolatok beöltésekor látható alapképernyő A másik lehetőség lényegesen egyértelműbb, ez a közönséges (jellemzően a PDF 1.7 verziójának megfelelő) PDF dokumentum. Ebben az esetben közvetlenül a dokumentum feletti mezőben megjelenik az érvényességre vonatkozó állítás. 37. ábra: A módosítható PDF formátumban készített hiteles másolatok esetén, érvényes aláírással, illetve bélyegzővel ellátott dokumentum esetén megjelenő képernyő, és az aláíráshoz tartozó ikon Mindkét formátumnál az eredeti beállítások esetén három vagy négy ikon látható a bal szélen. Ezek közül a tollra emlékeztető kiválasztásával lehet kezdeményezni az aláírás vagy bélyegző érvényességének ellenőrzését támogató folyamatot. Ekkor a bal oldalon megjelenik egy változtatható szélességű információs sáv, benne az aláírásra vonatkozó legfontosabb adatokkal. Ha rákattintunk magára a sötétebb, az aláírót (az Acrobat Reader nem különbözteti meg az aláírót és a bélyegző 179

180 létrehozóját, ezt csak a tanúsítvány tartalmából lehet megállapítani) jelző sorra, akkor részletesebb információ jelenik meg. 38. ábra: Az aláírás érvényességéről első lépcsőben elérhető információk Az alkalmazás azonban ennél lényegesen részletesebb információs is képe megjeleníteni. Amennyiben a jobb gombbal kattintunk ugyanerre a sötét, aláírás ikonnal kezdődő sorra, akkor egy négyelemű menü jelenik meg, ami lehetőséget ad egyrészt az ellenőrzés megismétlésére (ennek az ellenőrzési beállítások megváltoztatása esetén van gyakorlati jelentősége), másrészt itt lehet kiválasztani az aláírás tulajdonságait bemutató panel meghívását. Az így feljövő panel már elég sok információt tartalmaz az aláírás, illetve bélyegző érvényességét alátámasztó adatokról. Felül található az összegzés, hogy az adott értékelési módszerek alkalmazásával érvényesnek, érvénytelennek, vagy ismeretlennek kell tekinteni a dokumentumon elhelyezett aláírást. (ez értelemszerűen megegyezik a felső menüben is látható információval). Ezzel együtt adja meg az aláíró személyét, illetve a bélyegző létrehozóját. (ahogy jeleztük, ezt nem különbözteti meg, csak a tartalonból lehet kikövetkeztetni, hogy aláírással vagy bélyegzővel van dolgunk). Alatta az aláírás időpontja található a tényleges helyi időnek megfelelően, jelezve az időzónát is. Ez a rendszer saját órájából származó adat, Az utána levő sorban jelzi, amennyiben az aláírás gyökértanúsítványa szerepel az EU bizalmi listáján. Ezek azok az aláírások, amelyeket figyelembe kell venni, mint érvényes aláírásokat. Amennyiben nem szerepelnek a bizalmi listán, úgy az egyéb ellenőrzések sikeressége ellenére is érvénytelennek kell tekinteni az aláírást. 180

181 39. ábra: Az aláírás vagy bélyegző összefoglaló adattáblája Alatta jeleníti meg a tábla, ha az aláírás vagy bélyegző minősített, az EU bizalmi jelét és azt, hogy az eidas rendelet alapján ez egy minősített tanúsítvány. Az alatta levő blokkban helyezkednek el az aláírás érvényességéhez szükséges feltételekre vonatkozó megállapítások. Ezek közül az első azt igazolja, hogy a dokumentumból képzett lenyomat megegyezik az aláírásban tárolttal, azaz a dokumentum nem változott. Utána azt ellenőrzi a rendszer, hogy a tanúsítványtárban tárolt adatok megegyeznek-e az aláírásban szereplővel. majd az időbélyegző létét és annak alapján a tanúsítvány az aláírás időpontjára értelmezett érvényességét vizsgálja. Ha ezek a feltételek teljesülnek, akkor a változatlansággal kapcsolatos feltételek teljesülése biztosított. 181

182 Az utolsó blokk az aláíró és a kibocsátó közötti tanúsítványlánc meglétét, illetve a tanúsítvány esetleges visszavonását vizsgálja. Ha mindezek a feltételek teljesülnek az aláírást, illetve bélyegzőt érvényesnek lehet tekinteni. Az aláírás manuális ellenőrzéséhez biztosít lehetőséget az alul elhelyezkedő gomb, amellyel szintén egy több fület tartalmazó adathalmaz hívható elő az aláíró vagy bélyegző tanúsítvány adataival. 40. ábra: A Hibrid rendszer elektronikus bélyegző tanúsítványának áttekintő adatai A 40. ábra mutatja a jelenleg a Magyar Posta Hibrid kézbesítési és konverziós rendszerében használt bélyegző tanúsítványának alapvető adatait. Mint látható magára a tanúsítványra a rendszer megadja az eidas rendelet szerintiminősített tanúsítványhoz tartozó EU bizalmi jelet. Az X509 tanúsítványrendszer sajátosságai miatt a tanúsítvány alkalmazási célja két adatcsoport által meghatározott. Az első fele ennen az itt olvasható Előirányzott használat A dokumentumhitelesítésre alkalmas tanúsítványok esetében ennek mindig a letagadhatatlanság -nak kell lennie. A használati célok meghatározására vonatkozó második információsorozat a Megbízhatóság fülön található. Itt rögzítik a lehetséges felhasználási célokat, amely esetünkben a Dokumentum vagy adatok aláírása és a Dokumentum hitelesítése lehet Olyan tanúsítvánnyal, amely ezektől eltérő felhasználási célokat jelöl meg, nem lehet érvényesen aláírt vagy lebélyegzett dokumentumot előállítani. (ettől a dokumentum vagy bitsorozat még sok más célra alkalmas és hiteles lehet, aláírásként nem szolgálhat) 182

183 41. ábra: A dokumentumhitelesítésre alkalmas beállítások a megbízhatóság fülön A Részletek fülön ismerhetők meg a tanúsítványban tárolt összes adatok, a visszavonás fülön található a tanúsítvány visszavonásának ellenőrzésével kapcsolatos információ. Az adott esetben az ellenőrzés OCSP alapján történt. 42. ábra: A tanúsítvány visszavonására vonatkozó információkat tartalmazó fül Az irányelvek és a Jogi Közlemények rovat a felelősség korlátozásával, illetve a hitelesítési rendekkel kapcsolatos információt tartalmazza. Ezen információk birtokában lehet dönteni egy-egy tanúsítvány érvényességéről. A fejezet végén még bemutatjuk. az eidas rendelet hatályba lépését követő egy évben a használt, a jogszabály lehetőség megszűntével visszavont, de sok 183

184 másolaton és a rendszer által kiadott igazoláson megtalálható szervezeti aláíró tanúsítvány főbb adatait. 43. ábra: az elektronikus bélyegző bevezetése előtt használt szervezeti aláíró tanúsítvány 184

185 6 sz. melléklet: A csatolt metaadatok elérése, megjelenítése A Magyar Posta Zrt. Hibrid konverziós rendszerében a Papíralapú irat átalakítása hiteles elektronikus irattá KEÜSZ keretében készített inverz hibrid hiteles elektronikus másolatok a PDF állományba beágyazva az e-ügyintézési Vhr (2) bekezdésében rögzítetteknek megfelelően tartalmazzák a fenti jogszabályban a hiteles másolatkészítéshez előírt metaadatokat, valamint azokat a leíró adatokat, amelyek segíthetnek a hiteles elektronikus másolat alapján fogalmat alkotni az papíralapú eredetiről. Hasonló a feladat 4. sz. mellékletben bemutatott érvényesítési igazolás esetében is. A beágyazott metaadatok. elérését az előző melléklethez hasonlóan Acrobat Reader DC használatával mutatjuk be. Az eljárás ugyanígy használható azokban az esetekben is, amikor a különböző a rendszer által kibocsátott igazolásokba beágyazott XML vagy aláírt átvételi elismervény állományokat kívánjuk megismerni. Ha a hiteles elektronikus másolatot vagy az igazolást az Acrobat Reader megjelenítővel nyitjuk meg, akkor a 44. ábra elrendezésének megfelelő tartalom jelenik meg. Ezen a felületen a gemkapocs ikonra kell kattintania beágyazott mellékletek eléréséhez. 44. ábra: A beágyazott állományok eléréséhez szükséges elemek Ekkor a képernyő jobb oldalán egy munkafelület jelenik meg, rajta a beágyazott állománnyal, állományokkal végezhető műveletek ikonjai és az állomány(ok) neve. Ha a beágyazott állomány neve nem fér ki az alapbeállítású munkaterületen, a függőleges munkaterület határa elmozgatható, és az állomány képe is átméreteződik. A beágyazott állomány neve megegyezik az azt hordozó PDF 185

186 állományával, azzal az eltéréssel, hogy a nevet egy _data taggal egészíti ki, és a kiterjesztése értelemszerűen XML. Az állomány nevére jobb egérgombbal kattintva egy háromelemű menü jelenik meg. Ha itt a csatolmány megnyitása menüpontot választjuk, akkor a következő segédablak jelenik meg: 45. ábra: Az állomány megnyitásának egyik megoldása Ezen a Nyissa meg ezt a fájlt rádiógombot kiválasztva megnyílik az XML állományok kezelésére beállított eszköz használatával a metaadatokat tartalmazó beágyazott XML állomány. 46. ábra: A metaadatokat tartalmazó XML állomány egy szerkesztőben Amennyiben a PDF állomány nem csak egy beágyazott állományt tartalmaz, hasonló módon kell eljárni minden egyes beágyazott állománnyal. Az ilyen módon megnyitott állományokat értelemszerűen önálló állományként is el lehet menteni, de ebben az esetben már nem marad meg a hitelességük, az az eredeti beágyazott formában őrizhető csak meg. 186