Műszaki specifikáció NETLOCK CryptoServer - YAQUD

1. számú​​melléklet

Műszaki​​specifikáció​​NETLOCK​​CryptoServer​​-​​YAQUD

A NETLOCK CryptoServer család egy moduláris felépítésű, univerzális és vállalati IT rendszerekhez is illeszthető szerver oldali hitelesítő és folyamatvezérlő alkalmazás, amely komplex és nagyszámú kriptográfiai művelet végrehajtására képes. A NETLOCK CryptoServerrel nagy megbízhatóságú, illetve nagy biztonsági igényű központosított aláírási környezet alakítható ki, amely mind szoftveres, mind hardveres kulcskezelés támogatására képes. A NETLOCK CryptoServer családba tartozó YAQUD​​termék​​a​​következő​​magas​​szintű​​funkciókat​​teszi​​elérhetővé. Főbb​​funkciók PDF, ​

·

XML dokumentumok, illetve tetszőleges bináris fájlok tömeges elektronikus

aláírása​ ​vagy​ ​bélyegzése ·​ ​​​​​​​​​​ PDF,​ ​XML​ ​dokumentumok,​ ​illetve​ ​tetszőleges​ ​bináris​ ​fájlok​ ​tömeges​ ​időbélyegzése ·​ ​​​​​​​​​​ Elektronikusan​ ​hitelesített​ ​állományok​ ​hitelességellenőrzése

PDF ​

·

dokumentumok hitelesítése esetén a digitális aláírások mellett látható

aláírásképek​ ​elhelyezése​ ​is​ ​biztosítható Egyidejűleg ​

·

több hitelesítést kérő és hitelesített állományokat fogadó rendszerrel

képes együttműködni és több szoftveres vagy hardveres aláíró kulcs (PKCS11-es interfészen​ ​keresztül​ ​HSM​ ​alapú​ ​vagy​ ​chipkártyás)​ ​kezelésére​ ​képes Különböző, ​

·

az ügyfél által megrendelt - és lentebb specifikált - integrációs

interfészeken képes külső rendszerekkel kommunikálni, akár egyidejűleg több különböző​ ​rendszerrel​ ​is Hitelesítési ​

·

folyamatvezérlési műveletek, aláírási profilok és ezek közötti prioritás

sorrend​ ​kezelése ·

A ​

hitelesítéshez kapcsolódó elő- és utóműveletek végrehajtása az egyedi igényektől

és​ ​megrendelt​ ​funkcióktól​ ​függően Integrációs​​interfészek Az elektronikus hitelesítési feladatok során a YAQUD alkalmazás a következő integrációs interfészek​ ​támogatására​ ​képes​ ​az​ ​ügyfél​ ​műszaki​ ​igényeitől​ ​függően. Nyers​​http​​ és​​HTTPS A küldő alkalmazás egy http POST segítségével küldi be a hitelesítendő állományt a konfigurációs beállításoknál megadott URL-re és portra. A POST data csak a fájlt

tartalmazza.

A

sornak

megfelelő

művelet

eredményét

(aláírás

vagy

ellenőrzés)

kétféleképpen​ ​adhatja​ ​vissza​ ​a​ ​YAQUD,​ ​http​ ​válaszban​ ​vagy​ ​fájlrendszerben. SOAP Amennyiben az ügyfél SOAP interfészen keresztül szeretné a YAQUD alkalmazást elérni, akkor a NetLock által készített WSDL fájl alapján generált SOAP üzeneteket vár és ad vissza válaszként. Ez tartalmazza a base64 kódolt aláírandó/aláírt fájlt és a megadható opcionális​ ​paramétereket​ ​(nonce,​ ​csatolmány…). Fájlrendszer Abban az esetben, ha a YAQUD alkalmazást úgy konfiguráltuk be, hogy egy az alkalmazás által elérhető fájlrendszerben lévő mappát figyeljen, akkor az ide mozgatott fájlokat fogja feldolgozni és (sikeres aláírás/időbélyegzés esetén) a hitelesített állományt a kimeneti könyvtárba menti. Hiba esetén a fájlok egy harmadik hiba mappába (error queue-ba) kerülnek.

Integrációs​​interfész​​megnevezése

Szerződéses elérhetősége​[ FC1]

Nyers​ ​HTTP​ ​és​ ​HTTPS

X

HTTP​ ​SOAP​ ​(elsősorban​ ​SOAP​ ​v1.1​ ​vagy​ ​v1.2),​ ​WSDL Fájlrendszer

X

Támogatott​​platformok A NETLOCK CryptoServer családba tartozó YAQUD terméknek létezik Microsoft Windows operációs rendszeren szolgáltatásként és LINUX operációs rendszeren daemonként futtatható verziója. E szerződés keretében a YAQUD szerver oldali szoftver alkalmazás elérhetősége​ ​a​ ​következő​ ​operációs​ ​rendszeren​ ​biztosított. Támogatott​​Operációs​​Rendszer

Szerződéses elérhetősége​[ FC2]

Linux​ ​CENT​ ​OS​ ​(preferált​ ​CentOS​ ​6​ ​32-bit)

X

Microsoft Windows (preferált Windows Server 2008 vagy Windows​ ​7​ ​32-bit) Egyéb

Támogatott​​kriptográfiai​​célhardverek A NETLOCK CryptoServer családba tartozó YAQUD hitelesítő alkalmazás mind hardveres, mind szoftveres kulcstárolás támogatására képes. A következő kulcstároló eszközök támogatása​ ​biztosított: 1. HSM (Hardware Security Modul, elsősorban minősített tanúsítványok használata esetén​ ​indokolt)

a. SafeNet​ ​Luna

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​i.​​​​​​​​PCI:​

​Luna-PCI

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ii.​​​​​​​N ​ etHSM:​

b. SafeNet/Gemalto​ ​ProtectServer

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​i.​​​​​​​​PCI:​

​ProtectServer-PCIE

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ii.​​​​​​​N ​ etHSM:​

c. Thales​ ​nShield

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​i.​​​​​​​​PCI:​

tárolt

titkosított

kulcsok

​ProtectServer-Network

​nShield​ ​Solo

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ii.​​​​​​​N ​ etHSM:​

2. Fájlrendszeren

​Luna-SA​ ​NetHSM

​nShield​ ​Connect

(elsősorban

fokozott

biztonságú

tanúsítványok​ ​használata​ ​esetén​ ​alkalmazott)

Támogatott​​aláírás​​típusok​​(a​​megoldás​​ezen​​aláírások​​ellenőrzésére​​is​​képes)

Támogatott​​elektronikus​​aláírás​​típusok

Szerződéses elérhetősége​[ FC3]

PKCS​ ​#7​ ​(PDF)

X

Adat​ ​(PKCS​ ​#1,​ ​p7pem,​ ​p7pemdet)

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-BES

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-EPES

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-T

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-C

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-X-L

X

ETSI​ ​TS​ ​101​ ​903​ ​XAdES-A

X

ETSI​ ​TS​ ​103​ ​171​ ​XAdES-B​ ​(Baseline​ ​Basic)​[FC4] ETSI​ ​TS​ ​103​ ​171​ ​XAdES-T​ ​(Baseline​ ​Timestamped) ETSI​ ​TS​ ​103​ ​171​ ​XAdES-LT​ ​(Baseline​ ​Long​ ​Term) ETSI TS 103 171 XAdES-LTA (Baseline Long Term with Archive​ ​timestamps) ETSI​ ​TS​ ​103​ ​172​ ​PAdES-B​ ​(Baseline​ ​Basic) ETSI​ ​TS​ ​103​ ​172​ ​PAdES-T​ ​(Baseline​ ​Timestamped) ETSI​ ​TS​ ​103​ ​172​ ​PAdES-LT​ ​(Baseline​ ​Long​ ​Term) ETSI TS 103 172 PAdES-LTA (Baseline Long Term with Archive​ ​timestamps) ETSI​ ​TS​ ​103​ ​174​ ​ASIC-S​ ​(Baseline​ ​Standard) ETSI​ ​TS​ ​103​ ​174​ ​ASIC-E​ ​(Baseline​ ​Extended)

Időbélyegzés ·​ ​​​​​​​​​​ Formátum:​ ​RFC3161 ·​ ​​​​​​​​​​ Használható​ ​visszavonás​ ​ellenőrzés:​ ​CRL-ek

Támogatott​​bemeneti​​és​​kimeneti​​fájl​​formátumok: ·

XAdES, ​

illetve bármely más adat típusú aláírás formátum használata esetén

bármilyen kiterjesztésű bemeneti fájl formátum elfogadott, a kimeneti állomány pedig egy​ ​„.xml”​ ​kiterjesztésű​ ​és​ ​struktúrájú​ ​állomány​ ​lesz

·

PAdES ​

(PDF) aláírás formátumok használata esetén ISO-32000-1 szabványnak

megfelelő PDF típusú ​[SKd5]

[FC6] ​állományokat

fogad el a megoldás, a kimeneti

állomány​ ​pedig​ ​ugyanaz​ ​a​ ​verziójú​ ​PDF​ ​fájl​ ​formátum​ ​lesz​ ​“.pdf”​ ​kiterjesztéssel. Működés​​fő​​jellemzői: A kész kimeneti állományok a hitelesített PDF/XML állományok. A NETLOCK CryptoServer család YAQUD terméke alkalmas arra, hogy különböző rendszerek által átadott dokumentumokat, az aláírást és az időbélyeget a folyamatvezérlési parancsok által meghatározott​ ​formátumban,​ ​egy​ ​állományban​ ​visszaadja. A rendszer konfigurálható módon képes üzleti típusok alapján megjelölt állományokhoz alapértelmezett folyamatvezérlési paramétereket rendelni, melyeket folyamatvezérlési parancsokkal felül lehet írni. A beállítható paraméterek: hitelesítés módja (aláírás, aláírás+időbélyeg,

időbélyeg),

hitelesítéshez

használandó

kulcs

megnevezése,

hitelesítés/aláírás​ ​formátuma​ ​és​ ​az​ ​egyes​ ​aláírási​ ​profilok​ ​prioritása. A YAQUD alkalmazás alkalmas arra, hogy az átadott dokumentumokat a 910/2014/EU eIDAS rendeletnek és a 2015. évi CCXXII. törvénynek megfelelő módon elektronikus aláírással​[SKd7]

[FC8]

, ​

elektronikus bélyegzővel, valamint minősített időbélyeggel és

visszavonási információval lássa el. A rendszer képes a hitelesítéseket akár emberi beavatkozás nélkül, automatikusan végezni. A rendszer képes egy modulban több kulcs/tanúsítvány, valamint akár több aláíró modul kezelésére, s lehetővé teszi az aláíró kulcsok​ ​közötti​ ​választást. Redundancia,​​rendelkezésre-állás,​​ skálázhatóság A YAQUD alkalmazás minden komponense képes redundáns konfigurációban a működésre. Ennek megfelelően a hardware követelményeket az elvárt rendelkezésre állás alapján minden​ ​esetben​ ​ki​ ​lehet​ ​alakítani​ ​megfelelő​ ​redundanciával. Redundáns szerver kialakítással párhuzamosan a skálázhatóság érdekében az alkalmazás szerverek és az aláíró alkalmazás közötti terhelés elosztás biztosító. Ezen szétválasztás nélkül is külön skálázható a hitelesítést végző esetlegesen több szerver, illetve az alkalmazás​ ​szerver​ ​pár​ ​további​ ​szerverek​ ​beállításával. Service​​Quality​​(SQ)​​mérések A YAQUD alkalmazás és a rajta keresztül elért rendszer alkalmas arra, hogy a rendelkezésre​ ​állását,​ ​szolgáltatási​ ​szintjét,​ ​minőségét​ ​folyamatosan​ ​mérni​ ​lehessen. Naplózási​​folyamatok,​​naplóarchiválás A YAQUD általánosan, minden szolgáltatási eseményről részletes naplóbejegyzést készít, így természetesen a hitelesítő rendszerrel kapcsolatos minden sikeres és sikertelen hitelesítési​ ​kísérletről​ ​is.

Aláírás​​ellenőrző​​modul​[SKd9]​​[FC10] A NETLOCK CryptoServerben (YAQUD) beállított aláírás ellenőrző queue megadott ellenőrzési feltételek alapján képes hitelesség ellenőrzést végezni, és visszaadni az ellenőrzés eredményét. Ilyen ellenőrözési kritérium lehet: az aláíró tanúsítvány kiadója; aláíró tanúsítvány érvényességi ideje;

az aláíró tanúsítvány lenyomata (lehet SHA1 is);

aláíró tanúsítvány sorszáma; aláíró tanúsítvány pem formátumban; aláíró tanúsítvány szöveges formátumban, az időbélyegző tanúsítvány kiadója; időbélyegző tanúsítvány érvényességi ideje; az időbélyegző tanúsítvány lenyomata (lehet SHA1 is); az időbélyegzés időpontja; időbélyegző tanúsítvány pem formátumban; időbélyegző tanúsítvány szöveges formátumban. 4.​​​​​​​​számú​​melléklet Hibabejelentés

A​​Szolgáltató​​a​​hibajelzéseket,​​illetve​​egyéb​​technikai​​jelzéseket​​az​​alábbi​​módokon​​fogadja: ·​​​​​​​​​​​telefonon​​a​​+36​​1​​437​​6655/​​8-as​​melléken ·​​​​​​​​​​​írásban​​(e-mail)​​keresztül​​([email protected]). A telefonon keresztül történő hibabejelentésre kizárólag a fentebb meghatározott technikai kérdésekre megadott – rögzített - telefonszámon van lehetőség. A határidők a fenti rögzített telefonszámra történő bejelentéstől​​számítódnak. E-mailen történő hibabejelentéseket a Szolgáltató 7*0-24 órában fogadja, viszont kizárólag a munkanapokon 9:00-17:30 között érkezett e-maileket fogadja el úgy, hogy azok a hibabejelentés kezdetének számítsanak, ebben az esetben a hibabejelentést nem kell külön a fent meghatározott telefonszámon is megtenni. Amennyiben a fent meghatározott munkaidőn kívül érkezik az e-mail, telefonos​​bejelentés​​hiányában​​a​​hibabejelentés​​kezdetének​​a​​következő​​munkanap​​9:00​​óra​​számít.

A​​bejelentés​​során​​minden​​esetben​​szükséges​​a​​hiba​​prioritásának​​meghatározása: ·

Critical ​

(A): a hiba megakadályozza a rendszert az üzleti funkcióinak

ellátásában. ·​​​​​​​​​​​Major​ ​(B):​ ​nem​ ​kritikus,​ ​részfunkciót​ ​érintő​ ​hiba. ·

Minor ​

(C): nincs hatása a szolgáltatásokra, felügyeletet, üzemeltethetőséget

érintő​ ​hiba. ·​​​​​​​​​​​Információ​ ​kérés​ ​(D). A​​hibaelhárítás​​megkezdése​​alapszintű​​támogatás​​esetén​​a​​hiba​​prioritásának​​megfelelően​​történik:

Hiba​​prioritása

Elhárítás megkezdésének​​ideje

Critical

1​ ​munkanap

Major

2​ ​munkanap

Minor

3​ ​munkanap

Információ​ ​kérés

5​ ​munkanap

Az​​írásos​​hibabejelentésnek​​tartalmaznia​​kell​​az​​alábbi​​adatokat: ·​​​​​​​​​​​A​ ​bejelentés​ ​subject​ ​mezőjében​ ​a​ ​következőnek​ ​szerepelnie​ ​kell:​ ​ALTA​ ​E02B ·​​​​​​​​​​​A​ ​bejelentő​ ​neve; ·​​​​​​​​​​​A​ ​bejelentés​ ​időpontja; ·​​​​​​​​​​​Alkalmazás/rendszer​ ​megnevezése; ·​​​​​​​​​​​A​ ​hiba​ ​részletes​ ​leírása; ·​​​​​​​​​​​Érintett​ ​felhasználók​ ​megnevezése; ·​​​​​​​​​​​A​ ​hiba​ ​kért​ ​prioritása​ ​(A,​ ​B,​ ​C,​ ​D). A hibaelhárítás megkezdésének az minősül, ha a Szolgáltató telefonon és/vagy e-mailben felveszi a kapcsolatot​​ a​​Megrendelővel​​(visszajelzés).

Ügyfelenként​ ​​​[FC1]​kiválasztandó!

​​[FC2]​Ügyfelenként​ ​ ​ ​[FC2]​kiválasztandó! ​​[FC3]​Ügyfelenként​ ​ ​ ​[FC3]​kiválasztandó! ​​[FC4]​Innen​ ​​[SKd5]​Itt​ [FC6]​Az

​lefelé​ ​lévő​ ​aláírás​ ​formátumok​ ​csak​ ​a​ ​SignAssist​ ​termékben​ ​elérhetőek.

​nincs​ ​korlátozás,​ ​hogy​ ​pdf​ ​hanyas​ ​verziótól​ ​felfelé?

ISO-32000-es szabvány a PDF v1.7-et szabványosította, emiatt ezt a szabvány

egyértelműsíti. A gyakorlatban működik a megoldásunk korábbi PDF verziókkal is (de ezt nem​ ​garantáljuk),​ ​ezért​ ​nem​ ​írunk​ ​verziódefiníciót​ ​ide. ​​[SKd7]​Ilyen​

​aláírás​ ​nincs,​ ​max.​ ​tanúsítvány,​ ​amellyel​ ​létre​ ​tud​ ​hozni​ ​aláírást…

​​[FC8]​Ezt​

​jogilag​ ​korrektül​ ​javítsátok!

[SKd9]​Ezt

mindig adjuk vagy csak akkor, ha az ügyfél kéri? Ha opcionális, akkor viszont

tudnunk kellene, hogy mikor kéri az ügyfél és mikor nem, azaz benne legyen a szerződésben​ ​vagy​ ​sem? [FC10]​Az

aláírásellenőrzés része az alap terméknek, de csak akkor konfiguráljuk fel, ha az

ügyfélnek​ ​szüksége​ ​van​ ​rá.