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, ML dokumentumok, illetve tetszőleges bináris fájlok tömeges elektronikus aláírása vagy bélyegzése PDF, ML 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 Nyers HTTP és HTTPS Szerződéses elérhetősége [ FC1] HTTP SOAP (elsősorban SOAP v1.1 vagy v1.2), WSDL Fájlrendszer 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 LINU 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 Linux CENT OS (preferált CentOS 6 32-bit) Szerződéses elérhetősége [ FC2]
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. NetHSM: Luna-SA NetHSM b. SafeNet/Gemalto ProtectServer i. PCI: ProtectServer-PCIE ii. NetHSM: ProtectServer-Network c. Thales nshield i. PCI: nshield Solo ii. NetHSM: nshield Connect 2. Fájlrendszeren tárolt titkosított kulcsok (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 PKCS #7 (PDF) Adat (PKCS #1, p7pem, p7pemdet) ETSI TS 101 903 AdES-BES ETSI TS 101 903 AdES-EPES Szerződéses elérhetősége [ FC3]
ETSI TS 101 903 AdES-T ETSI TS 101 903 AdES-C ETSI TS 101 903 AdES--L ETSI TS 101 903 AdES-A ETSI TS 103 171 AdES-B (Baseline Basic) [FC4] ETSI TS 103 171 AdES-T (Baseline Timestamped) ETSI TS 103 171 AdES-LT (Baseline Long Term) ETSI TS 103 171 AdES-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: AdES, 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/ML á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 CCII. 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. Hibabejelentés 4. számú melléklet 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 (itsupport@netlock.hu). 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 Critical Major Minor Információ kérés Elhárítás megkezdésének ideje 1 munkanap 2 munkanap 3 munkanap 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 lefelé lévő aláírás formátumok csak a SignAssist termékben elérhetőek. [SKd5] Itt nincs korlátozás, hogy pdf hanyas verziótól felfelé? [FC6] Az 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á.