NLToken 2.0 technikai működése – böngésző, tanúsítvány, USB token és Windows kapcsolata
.# NLToken 2.0 technikai működése – böngésző, tanúsítvány, USB token és Windows kapcsolata
Az elektronikus aláírás a felhasználó szemszögéből gyakran egyszerű folyamatnak tűnik.
Csatlakoztatja a kulcstároló eszközt, megnyitja a szükséges webes rendszert, kiválasztja a tanúsítványt, megadja a PIN-kódot, majd elindítja az aláírást.
A háttérben azonban ennél lényegesen összetettebb technikai folyamat zajlik.
Egy elektronikus aláírás létrehozásában egyszerre vehet részt:
- a webes alkalmazás;
- a böngésző;
- a böngészőhöz telepített NLToken bővítmény;
- az NLToken helyi háttéralkalmazása;
- a Windows felhasználói környezete;
- a Windows tanúsítványtár;
- a kulcstároló eszköz;
- az eszközhöz szükséges middleware;
- a tanúsítvány;
- és a hozzá tartozó privát kulcs.
Ezért amikor egy felhasználó azt mondja, hogy „nem működik az NLToken”, rendszergazdai szempontból ez még nem határozza meg a hiba helyét.
A probléma ugyanis a teljes kommunikációs lánc bármely pontján kialakulhat.
Ebben a cikkben ezért nem elsősorban az NLToken telepítésével vagy egy-egy konkrét hibaüzenettel foglalkozunk, hanem azt vizsgáljuk meg, hogyan épül fel technikailag az NLToken 2.0 környezete, milyen komponensek működnek együtt, és hogyan érdemes rendszerszinten gondolkodni róla.
Mi az NLToken 2.0?
Az NLToken a NETLOCK webes aláírási környezetének kliensoldali komponense.
A technológia egyik fontos feladata, hogy kapcsolatot teremtsen a webes környezet és a felhasználó számítógépén elérhető kriptográfiai erőforrások között.
A modern webböngészők biztonsági okokból nem engedik meg egy weboldal számára, hogy közvetlenül hozzáférjen például egy számítógéphez csatlakoztatott chipkártyához vagy a Windowsban tárolt privát kulcshoz.
Ehhez szükség van egy köztes komponensre.
Az NLToken 2.0 ezt a kapcsolatot teremti meg.
Egyszerűsítve:
Webes alkalmazás
↓
Böngésző
↓
NLToken böngészőbővítmény
↓
Natív kommunikáció
↓
NLToken helyi komponens
↓
Windows / kulcstároló eszköz
↓
Tanúsítvány és privát kulcs
Ez már jól mutatja, hogy az NLToken nem azonos a tanúsítvánnyal, nem azonos az USB tokennel, és nem maga a privát kulcs.
Egy köztes technológiai rétegről beszélünk.
Ha az elektronikus aláírás teljes ökoszisztémáját – többek között a NETLOCK, Mokka, eSzignó, Bit4id, tanúsítványok és időbélyegek szerepét – szeretnénk megérteni, részletesen foglalkoztunk vele az Elektronikus aláírás vállalkozásoknak: Netlock Mokka, eSzignó, Bit4id és minden, amit tudni érdemes című útmutatóban.
NETLOCK, NLToken, tanúsítvány és kulcstároló: nem ugyanaz
Az elektronikus aláírási környezet hibakeresésének egyik legfontosabb feltétele, hogy pontosan megkülönböztessük az egyes komponenseket.
NETLOCK
A NETLOCK bizalmi szolgáltató, amely többek között elektronikus aláíráshoz kapcsolódó szolgáltatásokat és tanúsítványokat biztosít.
NLToken
Az NLToken kliensoldali technológiai komponens, amely lehetővé teszi, hogy egy támogatott webes környezet kommunikáljon a helyileg elérhető kulcsokkal és kulcstároló eszközökkel.
Tanúsítvány
A digitális tanúsítvány többek között összekapcsolja az aláíró személyazonosságára vagy szervezetére vonatkozó adatokat a hozzá tartozó nyilvános kulccsal.
Privát kulcs
A privát kulcs az a védendő kriptográfiai kulcs, amellyel az aláíráshoz szükséges kriptográfiai művelet történik.
Kulcstároló eszköz
A privát kulcs megfelelő környezetben hardveres kulcstárolón – például chipkártyán vagy más támogatott kriptográfiai eszközön – is elhelyezhető.
Ezért szakmailag nem elég azt mondani:
„A NETLOCK nem működik.”
A helyes kérdés inkább az:
A teljes elektronikus aláírási lánc melyik komponense nem működik megfelelően?
Hogyan kommunikál az NLToken a böngészővel?
A webes alkalmazások működése biztonsági szempontból erősen korlátozott.
Egy böngészőben megnyitott weboldal nem kaphat korlátlan hozzáférést a számítógép operációs rendszeréhez vagy a hozzá csatlakoztatott kriptográfiai eszközökhöz.
Ezért az NLToken működésében két külön világ találkozik:
a böngésző környezete
és
a helyi Windows környezet.
A kettő között az NLToken komponensei biztosítják a szükséges kommunikációt.
A NETLOCK jelenlegi NLToken környezetében ehhez böngészőbővítmény és a számítógépre telepített natív háttéralkalmazás is tartozik.
Ez fontos hibakeresési szempont.
Attól ugyanis, hogy az NLToken telepítője megtalálható a Windowsban, még nem biztos, hogy a böngésző oldali komponens megfelelően működik.
És fordítva:
attól, hogy a böngészőben látható a bővítmény, még nem következik automatikusan, hogy a helyi háttérkomponenssel vagy a kulcstárolóval is megfelelő a kommunikáció.
Mi történik egy aláírás kezdeményezésekor?
A tényleges folyamat az alkalmazott szolgáltatástól és aláírási folyamattól függ, de az NLToken szerepe leegyszerűsítve a következő logika mentén érthető meg.
A felhasználó megnyit egy NLToken-kompatibilis webes alkalmazást.
A webes rendszer aláírási műveletet kezdeményez.
A böngészőben működő NLToken komponens kommunikál a helyi NLToken környezettel.
A helyi komponens eléri a használható kriptográfiai kulcsot.
A szükséges aláírási művelet a privát kulcs használatával történik.
A folyamat eredménye visszakerül a webes aláírási folyamatba.
A NETLOCK dokumentációja alapján az NLToken 2.0 szerver-kliens architektúrában is működik a SIGNASSIST komponenseivel: a kliensoldali modul végzi a kulcstárolóval kapcsolatos kommunikációt és a szükséges kriptográfiai műveletet, miközben az aláírási folyamat további részei szerveroldalon is történhetnek.
Ez azért fontos, mert az NLToken működését nem szabad egy egyszerű „USB-token kezelőprogramként” elképzelni.
Hol található valójában a privát kulcs?
Erre nincs minden környezetre egyetlen válasz.
A kulcs tárolási helyét az alkalmazott tanúsítvány és kulcstárolási megoldás határozza meg.
Az NLToken támogatott környezetben képes lehet például:
- chipkártyás kulcstároló használatára;
- támogatott kriptográfiai eszközök kezelésére;
- a helyi Windows tanúsítványtárban elérhető kulcs használatára.
Ez fontos különbség.
A Windows tanúsítványtárban megjelenő tanúsítvány és a privát kulcs fizikai vagy logikai tárolási helye nem feltétlenül ugyanaz.
Hardveres kulcstároló esetén a cél éppen az, hogy a privát kulcs megfelelő védelem alatt maradjon, és az aláíráshoz szükséges kriptográfiai művelet a védett környezetben történjen.
Mi a kapcsolat az NLToken és a Bit4id között?
Az NLToken és a Bit4id szintén nem ugyanaz.
A Bit4id különböző kriptográfiai eszközöket és az azok használatához kapcsolódó technológiákat gyárt.
A NETLOCK dokumentációja az NLToken által támogatott kulcstárolók között többek között BIT4ID Crypto Java Card eszközt is felsorol.
Ebben az esetben leegyszerűsítve a következő rétegek jelenhetnek meg:
Webes rendszer
↓
Böngésző
↓
NLToken
↓
helyi kriptográfiai környezet / middleware
↓
Bit4id kulcstároló
↓
privát kulcs
Ezért amikor egy Bit4id-alapú környezetben az aláírás nem működik, nem szabad automatikusan az NLTokenre következtetni.
Lehetséges probléma:
- a böngészőnél;
- az NLToken bővítménynél;
- a helyi NLToken komponensnél;
- az eszközkezelésnél;
- a middleware-nél;
- a kulcstárolónál;
- a tanúsítványnál;
- vagy magánál a webes szolgáltatásnál.
Miért kér PIN-kódot a kulcstároló?
Hardveresen védett privát kulcs esetén a PIN egyik feladata, hogy az eszköz használatát jogosult felhasználóhoz kösse.
Fontos azonban különválasztani két dolgot:
a PIN nem maga a privát kulcs.
A PIN a védett kulcs használatához szükséges hitelesítési mechanizmus része.
Ezért egy megfelelően kialakított rendszerben a privát kulcsot nem kell „kiolvasni” az eszközből ahhoz, hogy aláírás történjen.
A szükséges kriptográfiai művelet a kulcsot kezelő biztonságos környezetben hajtható végre.
Ez az elektronikus aláírás biztonságának egyik lényeges eleme.
Az NLToken és a Windows tanúsítványtár kapcsolata
A Windows saját tanúsítványkezelési infrastruktúrával rendelkezik.
Ez azért fontos, mert vállalati környezetben több alkalmazás is támaszkodhat a Windows által elérhetővé tett tanúsítványokra és kriptográfiai szolgáltatásokra.
Az NLToken hivatalos dokumentációja szerint a rendszer képes a helyi Windows tanúsítványtárban elérhető kulccsal történő elektronikus hitelesítésre is.
Ez egyben azt is jelenti, hogy hibakereséskor külön kell vizsgálni:
- látható-e a megfelelő tanúsítvány;
- tartozik-e hozzá használható privát kulcs;
- melyik felhasználói környezetben érhető el;
- megfelelő-e a tanúsítvány érvényessége;
- az adott alkalmazás számára használható-e.
A „tanúsítvány látható” és a „tanúsítvány aláírásra használható” nem feltétlenül ugyanaz az állapot.
Miért fontos a Windows-felhasználói profil?
Többfelhasználós környezetben különösen fontos megérteni, hogy nem minden konfiguráció gépszintű.
Egy Windows rendszerben számos beállítás és erőforrás felhasználói profilhoz kapcsolódhat.
Ugyanez igaz a böngészőkre is.
Külön felhasználókhoz külön:
- böngészőprofil;
- böngészőbővítmény-beállítás;
- tanúsítványkörnyezet;
- jogosultság;
- alkalmazáskonfiguráció
tartozhat.
Ezért teljesen reális hibajelenség lehet:
„Ugyanazon a számítógépen az egyik felhasználónál működik az NLToken, a másiknál nem.”
Ez nem feltétlenül ellentmondás.
Éppen ellenkezőleg: értékes diagnosztikai információ.
Ha ugyanazon a gépen az egyik felhasználói profilban működik az aláírás, egy másikban pedig nem, akkor már szűkíthető a vizsgálandó komponensek köre.
NLToken többfelhasználós vállalati környezetben
Egyetlen felhasználó munkaállomásán viszonylag egyszerű a helyzet.
A vállalati infrastruktúrában azonban megjelenhet:
- több Windows-felhasználó;
- több böngésző;
- több tanúsítvány;
- több kulcstároló;
- központi jogosultságkezelés;
- Active Directory;
- Remote Desktop;
- Windows Server;
- Terminal Server;
- központilag telepített alkalmazások.
Ilyenkor az NLToken már nem kezelhető pusztán egy „feltelepítendő programként”.
A teljes környezetet kell vizsgálni.
Ez ugyanaz az alapelv, amely általánosan is érvényes a vállalati infrastruktúrára: egy üzleti alkalmazás stabil működése nem választható el az operációs rendszertől, jogosultságoktól, hálózattól és a mögötte működő infrastruktúrától. Erről részletesebben a Mi az IT üzemeltetés, és miért létfontosságú minden vállalkozás számára? című cikkünkben írtunk.
NLToken Windows Terminal Server környezetben
A Terminal Server különösen érdekes eset.
A NETLOCK jelenlegi dokumentációja szerint az NLToken 2.0 támogatja a Windows Terminal Server alapú működést.
Ez azonban nem jelenti azt, hogy minden tetszőleges Terminal Server-konfiguráció automatikusan működni fog.
Ebben a környezetben ugyanis különválik:
a felhasználó fizikai munkaállomása
és
az a Windows munkamenet, amelyben az alkalmazás ténylegesen fut.
Egy leegyszerűsített infrastruktúra például így nézhet ki:
Felhasználói számítógép
↓
Remote Desktop kapcsolat
↓
Windows Terminal Server
↓
Felhasználói munkamenet
↓
Böngésző
↓
NLToken
↓
tanúsítvány / kulcstároló elérése
Ha a kulcstároló fizikailag a felhasználó helyi számítógépéhez csatlakozik, további kérdés, hogy a távoli munkamenet hogyan fér hozzá a szükséges kriptográfiai eszközhöz.
Itt már nem kizárólag NLToken-konfigurációról beszélünk.
Megjelenhet:
- RDP-eszközátirányítás;
- smart card redirection;
- kliensoldali komponensek;
- szerveroldali komponensek;
- middleware;
- munkamenetenkénti elkülönítés;
- Windows Server házirendek;
- felhasználói jogosultságok.
Ezért Terminal Server esetén különösen fontos a teljes infrastruktúra dokumentálása.
Miért nem ugyanaz az USB-átirányítás és a smart card átirányítás?
RDP környezetben gyakori félreértés, hogy minden USB-eszközt ugyanúgy kell átirányítani.
Kriptográfiai eszközök esetén azonban a helyzet ennél összetettebb lehet.
Egy smart card jellegű kulcstároló használata nem feltétlenül egyszerű általános USB redirection formájában történik.
A Windows Remote Desktop Services külön mechanizmusokat is használhat intelligens kártyák kezelésére.
Ezért a hibakeresésnél először azt kell meghatározni:
- milyen típusú kulcstárolót használunk;
- hogyan ismeri fel a helyi Windows;
- milyen middleware tartozik hozzá;
- milyen módon kerül át a távoli munkamenetbe;
- a szerveroldali alkalmazás milyen interfészen próbálja elérni.
A „dugjuk be az USB-t és irányítsuk át” megközelítés ezért nem minden környezetben megfelelő diagnosztikai módszer.
Hogyan érdemes hibát keresni az NLToken környezetében?
A legfontosabb alapelv:
ne az egész rendszert telepítsük újra első lépésként.
Először határozzuk meg, hogy a kommunikációs lánc meddig működik.
Egy célszerű vizsgálati sorrend:
- működik-e maga a webes szolgáltatás;
- megfelelő böngészőt használunk-e;
- engedélyezett-e az NLToken böngészőbővítmény;
- működik-e a helyi NLToken komponens;
- felismeri-e a Windows a kulcstároló eszközt;
- megfelelően működik-e a szükséges middleware;
- elérhető-e a tanúsítvány;
- rendelkezésre áll-e a hozzá tartozó privát kulcs;
- megfelelő-e a felhasználói jogosultság;
- működik-e maga az aláírási tranzakció.
A diagnosztika lényege:
meg kell találni az utolsó olyan réteget, amely még bizonyíthatóan megfelelően működik.
Innen lehet tovább haladni a hiba irányába.
A konkrét NLToken hibajelenségekkel és azok megoldásával külön foglalkoztunk az NLToken Hiba: Megoldások ügyvédi rendszerek gyakori problémáira című útmutatóban.
Az NLToken telepítve van, mégsem működik
Ez az egyik legfontosabb különbség a telepítés és a működőképesség között.
A Windows alkalmazáslistájában megjelenő NLToken önmagában még nem bizonyítja, hogy a teljes rendszer működik.
Ellenőrizni kell többek között:
- a böngészőbővítményt;
- annak engedélyezett állapotát;
- a helyi háttéralkalmazást;
- a böngésző és a helyi komponens közötti kommunikációt;
- a kulcstároló elérhetőségét;
- a tanúsítványt;
- és az adott webes rendszer működését.
A NETLOCK külön is felhívja a figyelmet arra, hogy Google Chrome inkognitó módban a bővítmények alapértelmezett működése miatt az NLToken bővítmény nem töltődik be.
Ez jó példa arra, hogy egy látszólag kriptográfiai probléma mögött akár egyszerű böngészőkonfiguráció is állhat.
NLToken 1.x és NLToken 2.0: miért számít a verzió?
Régebbi munkaállomásokon még előfordulhatnak korábbi NLToken-komponensek.
Ez problémát jelenthet, ha régi és új komponensek keverednek.
A NETLOCK jelenlegi útmutatója az NLToken 1.4-ről történő áttérésnél a régi „NL signing” böngészőkiegészítő és a Chrome Token Signing alkalmazás eltávolítását, majd az NLToken 2.0 telepítését és az új böngészőbővítmény hozzáadását írja elő.
Ez rendszergazdai szempontból fontos tanulság:
frissítéskor nemcsak azt kell ellenőrizni, mi került fel a gépre, hanem azt is, mi maradt rajta a korábbi verzióból.
A párhuzamosan jelen lévő régi komponensek:
- hibás kommunikációt;
- böngészőproblémát;
- inkompatibilitást;
- nehezen reprodukálható hibát
okozhatnak.
A szoftverkomponensek naprakészen tartásának általános jelentőségéről a Miért fontosak a szoftverfrissítések? IT biztonság és stabil működés című cikkünkben írtunk részletesebben.
Miért romolhat el egy korábban működő NLToken-környezet?
Ez az egyik legérdekesebb üzemeltetési kérdés.
Gyakori helyzet:
„Tegnap még működött, ma már nem.”
Ha a felhasználó tudatosan semmit nem változtatott, abból még nem következik, hogy a rendszer sem változott.
A háttérben történhetett például:
- Windows-frissítés;
- böngészőfrissítés;
- böngészőbővítmény-frissítés;
- middleware-frissítés;
- biztonsági szoftver frissítése;
- tanúsítvány lejárata;
- felhasználói profil módosulása;
- csoportházirend változása;
- szerveroldali alkalmazásfrissítés.
Ezért a „nem nyúltunk hozzá” önmagában nem diagnosztikai bizonyíték.
Vállalati környezetben változásnapló, dokumentáció és központi felügyelet nélkül az ilyen hibák feltárása jelentősen nehezebb.
Böngészőfrissítés után jelentkező hibák
Mivel az NLToken egyik komponense közvetlenül a böngésző környezetében működik, egy böngészőfrissítés hatással lehet az aláírási folyamatra.
Érdemes ellenőrizni:
- fut-e támogatott böngésző;
- engedélyezett-e a bővítmény;
- frissült-e maga a bővítmény;
- megfelelő-e a kapcsolat a natív komponenssel;
- nem privát/inkognitó munkamenetben próbáljuk-e használni;
- vállalati házirend nem tiltja-e a bővítményt.
Központilag felügyelt környezetben különösen fontos a böngészőbővítményekre vonatkozó Group Policy vagy más endpoint-management szabályok ellenőrzése.
Mit támogat az NLToken 2.0?
A NETLOCK jelenlegi dokumentációja alapján az NLToken webes aláíró modul több szabványos elektronikus aláírási formátum kezelésére használható.
Ezek között szerepel:
- PAdES;
- XAdES;
- CAdES;
- ASiC;
- valamint a Magyarországon használt E-AKTA formátum támogatása.
A támogatás különböző aláírási szintekre is kiterjedhet, például:
- B;
- T;
- LT;
- LTA.
Ezek jelentősége már túlmutat azon, hogy egy dokumentumon egyszerűen „látszik-e az aláírás”.
A hosszú távú ellenőrizhetőség, időbélyegzés és visszavonási információk kezelése különösen fontos lehet jogi, vállalati vagy archiválási környezetben.
Miért nem szabad összekeverni az aláírásképet az elektronikus aláírással?
Egy PDF dokumentumon megjelenő grafikus aláíráskép nem maga a kriptográfiai elektronikus aláírás.
A vizuális elem csak az aláírás megjelenítése lehet.
A tényleges elektronikus aláírás mögött kriptográfiai struktúra található, amely többek között lehetővé teszi annak vizsgálatát, hogy:
- milyen tanúsítvánnyal készült;
- megváltozott-e a dokumentum;
- érvényes volt-e a tanúsítvány;
- tartozik-e hozzá időbélyeg;
- ellenőrizhető-e az aláírás.
Ezért egy dokumentumba beszúrt aláíráskép és egy szabványos elektronikus aláírás technikailag két teljesen különböző dolog.
Hogyan dokumentáljunk egy NLToken-környezetet?
Vállalati üzemeltetésben nem elegendő, hogy „most működik”.
A működő konfigurációt dokumentálni is érdemes.
Minimum célszerű rögzíteni:
Munkaállomás vagy szerver
- gép neve;
- Windows-verzió;
- architektúra;
- Terminal Server használata.
Felhasználó
- Windows-fiók;
- helyi vagy tartományi felhasználó;
- releváns jogosultságok.
Böngésző
- böngésző típusa;
- verzió;
- NLToken bővítmény állapota.
NLToken
- telepített verzió;
- telepítés helye;
- frissítés dátuma.
Kulcstároló
- eszköz típusa;
- middleware;
- driver;
- csatlakoztatás módja.
Tanúsítvány
- kibocsátó;
- tulajdonos;
- érvényességi idő;
- felhasználási cél.
Távoli munkavégzés
- RDP használata;
- smart card redirection;
- kliensoldali és szerveroldali komponensek.
Egy ilyen dokumentáció jelentősen felgyorsíthatja a későbbi hibakeresést.
A tanúsítvány lejárata is üzemeltetési feladat
A technikai infrastruktúra lehet teljesen hibátlan, mégis leállhat az aláírás, ha lejár a szükséges tanúsítvány.
Ezért vállalati környezetben célszerű a tanúsítványokat ugyanúgy életciklus alapján kezelni, mint más üzletmenet-kritikus komponenseket.
Érdemes nyilvántartani:
- melyik felhasználóhoz tartozik;
- mire használják;
- melyik eszközön található;
- mikor jár le;
- mikor kell megkezdeni a megújítást;
- ki felel érte.
A lejárat napján elkezdeni keresni a megoldást már nem megfelelő üzemeltetési gyakorlat.
Biztonsági szempontok NLToken-környezetben
Az elektronikus aláírás nemcsak rendelkezésre állási, hanem információbiztonsági kérdés is.
Különösen fontos:
- a privát kulcs megfelelő védelme;
- a PIN-kód bizalmas kezelése;
- a Windows-fiókok elkülönítése;
- a szükségtelen adminisztrátori jogosultságok kerülése;
- az elveszett kulcstárolók megfelelő kezelése;
- a távozó munkatársak hozzáféréseinek megszüntetése;
- a tanúsítványok életciklusának követése;
- az operációs rendszer és a kapcsolódó komponensek frissítése.
A működőképesség és a biztonság nem választható el egymástól.
Egy olyan megoldás, amely csak azért működik, mert minden felhasználó helyi rendszergazda és minden biztonsági korlátozást kikapcsoltak, nem tekinthető megfelelő vállalati konfigurációnak.
Mikor NLToken-hiba, és mikor infrastruktúra-hiba?
Ez az egyik legfontosabb kérdés.
Ha a böngésző nem látja a bővítményt, lehet NLToken-konfigurációs probléma.
Ha a Windows egyáltalán nem ismeri fel a kulcstároló eszközt, valószínűleg már az NLToken alatti rétegben kell keresni.
Ha a tanúsítvány lejárt, nem az NLToken javítása a megoldás.
Ha Terminal Serveren nem jut el a kriptográfiai eszköz a megfelelő munkamenetbe, infrastruktúra-konfigurációs problémáról lehet szó.
Ha minden helyi komponens működik, de maga a webes szolgáltatás nem érhető el, a kliens újratelepítése szintén nem fogja megoldani a hibát.
Ezért fontos a réteges diagnosztika.
Az üzleti rendszerek leállásának hátterében általában is sokféle függőség állhat; ezekkel részletesebben a Miért áll le váratlanul egy cég informatikai rendszere? A leggyakoribb okok és hogyan előzhetők meg című cikkünkben foglalkoztunk.
Az elektronikus aláírás üzletmenet-kritikus szolgáltatás lehet
Egy ügyvédi iroda, könyvelőiroda vagy más elektronikus ügyintézést végző vállalkozás számára az elektronikus aláírás kiesése nem egyszerű informatikai kellemetlenség.
Megállhat:
- dokumentumok beadása;
- szerződések aláírása;
- hivatalos ügyintézés;
- határidős beadványok elkészítése;
- ügyfelek kiszolgálása.
Ezért az elektronikus aláírási infrastruktúrát érdemes ugyanolyan tudatosan kezelni, mint más üzletmenet-kritikus rendszereket.
Nem elegendő az, hogy egyszer telepítettük és működött.
Figyelni kell:
- a komponensek verzióira;
- a tanúsítványok lejáratára;
- a Windows környezetre;
- a böngészőkre;
- a jogosultságokra;
- a Terminal Server konfigurációra;
- és a változások dokumentálására.
Mikor érdemes informatikust bevonni?
Egy egyszerű böngészőbővítmény engedélyezéséhez általában nincs szükség komplex infrastruktúra-vizsgálatra.
Más a helyzet azonban, ha:
- több felhasználó érintett;
- Terminal Server működik;
- Remote Desktop használat történik;
- többféle token található a környezetben;
- az egyik felhasználónál működik, másiknál nem;
- Windows-frissítés után állt le;
- több middleware került a gépre;
- tanúsítvány- vagy kulcstároló-probléma gyanítható;
- az elektronikus aláírás üzletmenet-kritikus.
Ilyenkor az NLToken önmagában történő újratelepítése sokszor csak elfedi a problémát.
A cél nem az, hogy „valahogy működjön”, hanem hogy azonosítható, dokumentált és reprodukálható módon működjön a teljes aláírási lánc.
Gyakori kérdések az NLToken 2.0 működéséről
Mi az NLToken?
Az NLToken a NETLOCK webes aláírási környezetének kliensoldali modulja. Böngészőoldali bővítmény és helyi komponens segítségével teszi lehetővé, hogy támogatott webes folyamatok hozzáférjenek a helyileg elérhető kriptográfiai kulcsokhoz és támogatott kulcstároló eszközökhöz.
Az NLToken ugyanaz, mint az USB token?
Nem.
Az NLToken szoftveres komponens, míg az USB-s vagy chipkártyás kulcstároló egy kriptográfiai eszköz lehet. A kettő együtt is részt vehet ugyanabban az elektronikus aláírási folyamatban.
Az NLToken ugyanaz, mint a tanúsítvány?
Nem.
A tanúsítvány és az NLToken teljesen eltérő szerepet tölt be. Az NLToken a technikai kommunikáció egyik komponense, míg a tanúsítvány az elektronikus aláírás PKI-környezetének része.
Mi a különbség az NLToken és a Bit4id között?
Az NLToken a NETLOCK kliensoldali aláíró technológiája. A Bit4id többek között kriptográfiai hardvereket és kapcsolódó technológiákat gyárt. Egy támogatott Bit4id kulcstároló az NLToken által elérhető kriptográfiai eszköz lehet.
Hol található a privát kulcs?
Ez az alkalmazott megoldástól függ. Elérhető lehet például támogatott hardveres kulcstárolón vagy a Windows kriptográfiai környezetén keresztül. A konkrét tárolási módot mindig a használt tanúsítvány és kulcstárolási megoldás alapján kell meghatározni.
Miért kér PIN-kódot az elektronikus aláírás?
Hardveresen védett kulcs esetén a PIN a kulcstároló használatához szükséges hitelesítés része. A PIN nem azonos magával a privát kulccsal.
Működik az NLToken Chrome böngészőben?
Igen, a NETLOCK jelenlegi dokumentációja támogatott böngészőként felsorolja a Google Chrome-ot. Az NLToken böngészőbővítményének telepítve és engedélyezve kell lennie.
Működik az NLToken Microsoft Edge-ben?
A NETLOCK dokumentációja a Chromium-alapú Microsoft Edge böngészőt is támogatottként jelöli.
Működik az NLToken Firefoxban?
A NETLOCK jelenlegi dokumentációja Mozilla Firefox támogatást is jelez.
Miért nem működik Chrome inkognitó módban?
A NETLOCK külön felhívja a figyelmet arra, hogy Chrome inkognitó módban az NLToken bővítmény nem töltődik be az alapértelmezett bővítménykezelés miatt.
Működik az NLToken Windows Terminal Serveren?
A NETLOCK dokumentációja szerint az NLToken 2.0 támogatja a Windows Terminal Server alapú működést. A teljes működőképességhez azonban a kapcsolódó kulcstároló, felhasználói munkamenet, middleware és RDP-konfiguráció megfelelő kialakítása is szükséges lehet.
Miért működik ugyanazon a gépen az egyik felhasználónál, a másiknál pedig nem?
Mert több komponens felhasználóspecifikus lehet. Ilyen lehet többek között a böngészőprofil, a bővítmény állapota, a tanúsítványkörnyezet, a jogosultság vagy egy alkalmazás konfigurációja.
Miért nem érdemes rögtön újratelepíteni az NLToken alkalmazást?
Mert a hiba nem feltétlenül az NLToken telepítésében található. Először meg kell határozni, hogy a böngésző, a bővítmény, a helyi komponens, a middleware, a kulcstároló, a tanúsítvány és a webes szolgáltatás közül melyik rétegben szakad meg a működés.
Összegzés
Az NLToken 2.0 működésének megértéséhez nem elegendő egyetlen alkalmazásként tekinteni rá.
Egy modern elektronikus aláírási folyamat több technológiai réteg együttműködéséből áll.
A folyamatban szerepet kaphat:
- a webes szolgáltatás;
- a böngésző;
- az NLToken bővítmény;
- az NLToken natív háttérkomponense;
- a Windows;
- a tanúsítványtár;
- a middleware;
- a kulcstároló;
- a tanúsítvány;
- és a privát kulcs.
Ha ezek közül bármelyik réteg hibásan működik, a felhasználó számára az eredmény gyakran ugyanaz:
nem sikerül az elektronikus aláírás.
Rendszergazdai szempontból azonban nem az a kérdés, hogy „működik-e az NLToken”, hanem az, hogy:
a teljes aláírási lánc melyik pontjáig működik megfelelően a kommunikáció, és pontosan hol szakad meg?
Ez a szemlélet gyorsabb és megbízhatóbb hibakeresést tesz lehetővé, mint az alkalmazások ismételt újratelepítése.
Vállalati, ügyvédi vagy könyvelőirodai környezetben pedig az elektronikus aláírás már nem pusztán egy felhasználói alkalmazás.
Az informatikai infrastruktúra üzletmenet-kritikus része.
Források
- NETLOCK – NLToken modul
- NETLOCK – Gyakori kérdések / NLToken aláíró modul
- NETLOCK – NLToken 2.0 műszaki és támogatási dokumentáció
- NETLOCK – NLToken adatkezelési tájékoztató
- ETSI elektronikus aláírási szabványok
- eIDAS – 910/2014/EU rendelet