Utasítások az elektronikus aláírási kulcs létrehozásához. Utasítások az elektronikus aláírási kulcs létrehozásához Hitelesítési központ létrehozása
Ma a következőkről fogunk beszélni:
- mi érdekes a kriptográfia témakörében és Elektronikus aláírás Ma;
- mik a jelenlegi szabályozások ebben a témában;
- milyen titkosítási képességek valósulnak meg az 1C platformon;
- hogyan bővítheti ezeket a képességeket külső összetevőkkel;
- beszéljünk a BSP "Elektronikus aláírás" alrendszeréről;
- az "1C-EDO" és az "1C: DirectBank" szolgáltatások megvalósításáról, amelyek fejlesztését felügyeltem;
- érinteni fogjuk azt a kérdést, hogy kifejlesztjük saját megoldásainkat az 1C: Enterprise platform kriptográfiai munkájához;
- Tekintsük a tipikus problémákat, amelyek az EDM megvalósításakor felmerülnek a vállalatnál - elmondom, hogyan kell megoldani őket.
Szeretném felhívni a figyelmet két kifejezésre, amelyeket a mesterkurzusban fognak használni.
- Az első az EDF, elektronikus dokumentumkezelés... Ez alatt a vállalaton belüli belső elektronikus dokumentumáramlást és a külső partnerekkel való külsőt értjük.
- A második rövidítés az EP. Az interneten vannak átiratok: "elektronikus kormányzás" és "elektromos hajtás". Nálunk lesz Elektronikus aláírás.
Miért aktuálisak jelenleg a kriptográfia és az elektronikus aláírás kérdései?
- Egy modern vállalkozáshoz az üzleti folyamatok gyorsasága az egyik versenyelőny... Az elektronikus dokumentumkezelés használatával a statisztikákra fordított idő 75%-kal csökken.
- Amikor elektronikus dokumentumfolyamra vált, a saját erőforrások megtakarítása(papír, nyomtatópatronok, dokumentumok tárolóhelye, a személyzet ideje a papír munkafolyamatának megszervezésére). Mindez nagyban segíti a céget.
- Ma már szinte minden vállalkozás távoli banki csatornákat használ, és a távoli fizetések biztonsága jelenleg nagyon releváns.
- Most minden nagy adófizető a szerződésben tartalmazza azokat a téziseket, hogy ha velük szeretne dolgozni, cserélje ki a dokumentumokat elektronikus formátumban. Minden e-mailre megy- elektronikus számlák, elektronikus megrendelések stb. Ha részt kíván venni az aukción - elektronikus aláírással kell rendelkeznie.
- Mindezt fokozatosan masszív lesz, de ennek ellenére lakosságunk nem kellően tájékozott. Ez súlyos mulasztás, ezért ennek az áttekintésnek az a célja, hogy olyan tanfolyamot biztosítson Önnek, amely segít eligazodni ezekben a kérdésekben, és kitalálni, hogy mit lehet tanulmányozni és hol érdemes keresni.
Szabályozási keret, alkalmazási gyakorlat
Milyen fogalmakat fogunk figyelembe venni?
Elektronikus dokumentum
Az elektronikus dokumentum minden olyan információ, amelyet elektronikus úton nyújtanak be:
- Ön lefényképezte járművét - ez a kép egy elektronikus dokumentum;
- e -mailben elküldte a kérelmet a főnöknek - ez is elektronikus dokumentum.
Bármely dokumentum lefordítható "digitális" -ra, de nem minden elektronikus dokumentum ismerhető fel emberi beavatkozás nélkül.
A megmunkálás ígéretesebb, így sok dokumentum felosztható formalizált és nem formalizált elektronikus dokumentumok.
- Formázatlan dokumentum alatt azt értjük, hogy egy személy ránéz egy fényképre, és látja, hogy az autó száma ilyen és olyan.
- És a formalizáláshoz elektronikus dokumentumokáltalában olyan sémákat dolgoznak ki, ahol a mezők összetételét, korlátait, kötelező vagy választható stb. határozzák meg. Az ilyen formalizált dokumentumok automatikusan felismerhetők.
A formalizált elektronikus dokumentumok kilátása. Az osztályok fokozatosan új sínekre váltanak. Sokan közülük saját szabályzatot adnak ki, amely leírja az információcsere formátumát.
- A választottbíróság például csak PDF formátumú dokumentumokat fogad el.
- Az elektronikus számlákat pedig el kell küldeni XML formátum, és van egy speciális szabályozási keret, amely leírja a szükséges területeket. Azoknak az adózóknak, akik elektronikus úton kívánnak számlát váltani, szigorúan be kell tartaniuk ezeket a követelményeket.
Korábban az volt a probléma, hogy a Szövetségi Adószolgálat köteles volt az elektronikus dokumentumok új formátumára váltani, nagyjából ugyanúgy, mint az új elektronikus jelentési formátumra - március 1 -től új formátum lesz, majd „legalább a fű nem fog nőni ”. Most, pár év után, közzéteszik a formátumot, várjon Visszacsatolás majd figyelmeztesse, hogy az év folyamán zökkenőmentesen át kell alakítani. Ugyanakkor a régi és az új formátumokat is párhuzamosan fogadják el. Az adóhivatalnak minden esetben el kell fogadnia a dokumentumokat bármilyen formátumban, mert a dokumentumok ötévesek lehetnek, és továbbra is elektronikus formában kell elfogadni őket.
Elektronikus aláírás
A 63-FZ törvény bevezeti az elektronikus aláírás fogalmát. Korábban létezett az "elektronikus" fogalma digitális aláírás"(EDS), most helyesebb az" elektronikus aláírás "kifejezést használni. E törvény szerint van háromféle elektronikus aláírás.
- Az első fajta az egyszerű elektronikus aláírás... Például mobilbank használata esetén SMS -t kap egy egyszeri jelszóval, és megerősítést tesz - ez egy egyszerű elektronikus aláírás analógja. Ilyen aláírással csak a szerző azonosítható.
- A második és a harmadik típus az továbbfejlesztett elektronikus aláírás... A "továbbfejlesztett" azt jelenti, hogy valamilyen kriptoeszközt használnak. A továbbfejlesztett aláírás a következőkre oszlik: képzetlen és szakképzett.
A továbbfejlesztett minősített elektronikus aláírást néha egyszerűen minősített elektronikus aláírásnak (QEP) nevezik. Ez egy elektronikus aláírás, amely egy akkreditált tanúsító hatóság által kiállított tanúsítványon alapul. A Távközlési és Tömeges Hírközlési Minisztérium listát vezet azokról a tanúsító központokról, amelyek elektronikus aláírási tanúsítványokat bocsátanak ki.
Elektronikus aláírási tanúsítvány(más néven az elektronikus aláírás ellenőrző kulcsának tanúsítványa) - ez az papír vagy elektronikus dokumentum, amely egyedileg azonosítja, hogy ki az aláírás tulajdonosa.
A minősített elektronikus aláírás a legelterjedtebb. Fő célja, hogy bizonyítsa a szerzőséget, garantálja a visszautasítást és biztosítja az aláírt adatok integritását. Ez azt jelenti, hogy ha elektronikus számlát írt alá minősített elektronikus aláírással, akkor:
- Nem mondhatja, hogy ez nem az Ön aláírása;
- Nem utasíthatja el (visszavonja);
- aláírása után ellenőrizheti, hogy nem történt -e módosítás ezen a dokumentumon.
Ha arról beszélünk az elektronikus aláírások alkalmazása, akkor érdemes lokálisra és felhőre osztani őket.
- Helyi elektronikus aláírás- olyan helyzet, amikor aláír néhány dokumentumot a számítógépén. Ebben az esetben egy titkosító eszközre van szükség, a tanúsítvány telepítése sok nehézséget okoz.
- Felhő elektronikus aláírás- olyan helyzet, amikor a privát kulcsok tárolását egy bizonyos „felhőben” lévő tulajdonosra bízza, és ahhoz, hogy aláírjon egy dokumentumot, továbbítania kell ezt a felhőt. Valószínűleg egyszeri jelszót kap a telefonjára, amelyet meg kell erősíteni. És a megerősítés után egy elektronikus aláírás jön létre a szerverben a "felhőben", és kap egy aláírt dokumentumot.
Az FSB pontosító levelet adott ki, amelyben ezt kifejtette a felhő elektronikus aláírása nem minősített... Ezért, ha a törvény azt írja elő, hogy a dokumentumot minősített elektronikus aláírással kell aláírni, és a dokumentumot a "felhőben" írják alá, akkor ne feledje, hogy ezzel problémák merülhetnek fel - ezt nagyon óvatosan kell megközelíteni.
Mit tud még érdekesnek mondani a ránk vonatkozó jogszabályokról?
- 2016 -ban megjelent az Orosz Föderáció Távközlési és Tömegkommunikációs Minisztériumának egyetlen tanúsító központja, amely lehetővé teszi a bizalmi lánc kiépítését bármely tanúsítványhoz. A Távközlési és Hírközlési Minisztérium vezető tanúsító központja tanúsítványokat ad ki az akkreditált tanúsító központoknak, és már kiállítják a fizikai és jogalanyok... Ezért mindig bizalmi láncot építhet bármely elektronikus aláíráshoz. Ez nagyon kényelmes, mert korábban a gyakorlatban nehéz volt ellenőrizni, hogy egy másik tanúsító hatóság aláírása érvényes -e.
- Egészen új - 2017 elején a Távközlési és Tömeges Hírközlési Minisztérium jogalkotási kezdeményezéssel állt elő, hogy az összes minősített elektronikus aláírás kérdését az állami monopóliumra ruházza. Erre a Központi Bank, valamint a Gazdasági Fejlesztési és Kereskedelmi Minisztérium szó szerint júliusban azt válaszolta, hogy ezt nem szabad megtenni, mert munkahelyeket foglal el, és tönkreteszi az évek során felhalmozottakat. Valószínűleg ez a jogalkotási kezdeményezés nem megy tovább, de volt egy ilyen elképzelés.
Az elektronikus aláírással ellátott EDF használatának jellemzői a vállalatoknál
Milyen jellemzői vannak az elektronikus dokumentumkezelésnek a vállalatoknál? Kérjük, vegye figyelembe, hogy amikor elektronikus aláírással és titkosítással kapcsolatos projekteket indít, a tanácsadói szolgáltatások nagyon fontosak.
Ha a vállalat elindítja az elektronikus dokumentumkezelést, azután:
- az első feladat az ben regisztrálja az elektronikus dokumentumkezelés használatát számviteli politikák;
- további szükséglet rendelést ad ki a vállalkozásnál hol jelezze, hogy mely személyek írhatnak alá dokumentumokat;
- ha egy másik féllel cserél, akkor rendelkeznie kell egy megállapodással, amely tartalmazza a dokumentumok törlésének és javításának módját. Például, ha nem tetszik valami papír alapú dokumentum, akkor egyetérthet a partnerével, és csak széttépheti, és minden rendben lesz. És elektronikus formában minden némileg bonyolultabb, mert a létrehozott és aláírt dokumentum példányszáma korlátlan lehet. És még akkor is, ha Ön és partnere megállapodtak a dokumentum törlésében, akkor az elektronikus megfelelője nem elegendő ahhoz, hogy egyszerűen törölje azt az adatbázisból. Ahhoz, hogy kijavítson egy elektronikus dokumentumot vagy elutasítsa azt, új elektronikus dokumentumot kell létrehoznia annak alapján, és már benne kell jeleznie, hogyan néz ki a tranzakció most. És csak azután, hogy mindkét oldalról aláírta ezt az új elektronikus dokumentumot, a tranzakcióval kapcsolatos információk a kívánt formában kerülnek rögzítésre.
Mindezt elő kell írni és használni.
A szabályozási keret készsége
Nagyra értékelném szabályozási keretünk készenlétét - már létezik valamiféle "épület", de még be kell fejezni.
- Például, nincs értelme annak, hogyan fogjuk öt év múlva ellenőrizni az elektronikus aláírást az elektronikus dokumentumok archívumában... Mivel a tanúsítvány egy évig él, és ha lejár az érvényességi ideje, az aláírás érvénytelen lesz - nem világos, hogyan ellenőrizhető.
- Nem világos, mi az "aláírás dátuma". Néhány számviteli dokumentum esetében fontos tudni, hogy a dokumentumot mikor írták alá. Most, amikor aláír egy dokumentumot, "csalhat" - lefordították a számítógép dátumát, aláírták, és úgy fog kinézni, mintha a dokumentumot "visszamenőleg" írták volna alá. Ezért ahhoz, hogy egyértelműen kijelenthessük, hogy a dokumentumot akkor és akkor írták alá, a következő lehetőségek közül kell választani:
- vagy egyetlen központnak kell lennie az időbélyeg elosztására, hogy a dokumentumok aláírásakor valamilyen szövetségi szolgáltatási osztályhoz forduljunk, amely megadná nekünk az aláírás időbélyegét;
- vagy amikor elektronikus számlákat cserél, van egy harmadik link - az elektronikus dokumentumkezelés üzemeltetője. A dokumentumokat önmagán keresztül továbbítja, és nem engedi meg a "csalást", mert előállítja a nyugtákat (visszaigazolásokat), amelyek előírják a dátumot és az időt.
Általában van mozgástér.
Kriptográfiai mechanizmus az 1C: Enterprise 8 platformon
A platform kriptográfiai mechanizmusa a 8.2 verzió óta jelent meg - ez egy meglehetősen fiatal mechanizmus. Maga a platform nem tartalmaz titkosítási algoritmusokat, csak hívásokat és objektumokat tartalmaz, amelyekkel elérheti a számítógépen található kriptográfiai eszközöket:
- Windows esetén a CryptoAPI interfész;
- Linuxhoz nincsenek ilyen interfészek, közvetlen hívás van a kriptográfiai modulokra.
Innen világossá válik, hogy A kriptográfia csak akkor használható, ha titkosító eszköz van telepítve a számítógépre... Másrészt pedig magát az 1C: Enterprise platformot nem kell tanúsítani a kriptográfia szempontjából.
Alapvető titkosítási műveletek az 1C: Enterprise 8 platformon:
- Tudja, hogy a platform különböző módokban működhet: vastag, vékony, webes kliens, külső kapcsolat és mobilalkalmazás. Mindezen indítási módokban a titkosítás támogatott- egy mobilalkalmazás esetében a 8.3.10 verzió óta megjelent a titkosítási mechanizmusok támogatása. Azt javaslom, hogy olvassa el a Syntax Assistant alkalmazást, és nézze meg, milyen módszerek állnak rendelkezésre az indítási módban, mert vannak korlátozások.
- A platform lehetővé teszi a tanúsítványokkal való munkát nyilvános kulcs(X.509) amelyek a számítógépre vannak telepítve. Nem állíthatunk ki új tanúsítványt, vagy nem kérhetjük annak kiadását, csak azzal dolgozunk, amink van - a platformmechanizmusok segítségével megtalálhatunk egy tanúsítványt a számítógépen, elolvashatjuk annak attribútumait, feltölthetjük egy fájlba, és ellenőrizhetjük, mennyire érvényes.
- Gyakorlatom során gyakran találkoztam félreértéssel hogyan működik a titkosítás és a visszafejtés a platformon... Ez különösen akkor fontos, ha olyan külső vállalkozóval integrálódik, aki nem dolgozik az 1C -n. Amikor titkosította a dokumentumot, elküldte a másik oldalra, és ott megpróbálják visszafejteni. Például gyakran felmerülnek kérdések, ha a GOST 28147-89 algoritmust 1C-ben adták meg egy szimmetrikus kriptográfiai szolgáltató beállításakor, és a visszafejtés során fellebbezésre van szükség a privát kulcshoz. Hadd emlékeztessem önöket, hogy a szimmetrikus titkosítási algoritmus azt jelenti, hogy ugyanazt a kulcsot használja a titkosításhoz és a visszafejtéshez. Az aszimmetrikus titkosítás pedig az, amikor az adatokat nyilvános kulccsal titkosítják, és egy másik, titkos (titkos) kulcsot használnak a visszafejtésre. A vállalkozók megkérdezik: "De azt mondta, hogy a titkosítási algoritmus szimmetrikus, miért van szükség a kulcs privát részére a visszafejtéshez?" Nézzük meg, hogyan működik a titkosítási mechanizmus a platformon:
- véletlenszerűen generál egy bizonyos rögzített hosszúságú kulcsot, amellyel az adathalmazt szimmetrikus algoritmus segítségével titkosítják;
- magát a kulcsot ezután aszimmetrikusan titkosítják a címzett tanúsítvány nyilvános kulcsa segítségével;
- a szimmetrikus algoritmussal történő titkosítás gyorsabban működik - nagy mennyiségű adatot titkosítottunk vele, majd aszimmetrikus algoritmus segítségével gyorsan titkosítottunk egy kis, meghatározott hosszúságú kulcsot;
- a titkosított adatok, a címzett tanúsítványok listája és maga a titkosított kulcs egy adatcsomagba vannak csomagolva a PKCS # 7 specifikáció szerint;
- ezt a csomagot a címzett oldalára küldik;
- és a visszafejtés fordított sorrendben működik.
- Az elektronikus aláírás aláírása és ellenőrzése... A platform segítségével történő aláíráskor a kulcs privát része hozzáférhető, és a platformba épített aláírás épsége (matematikai érvényessége) ellenőrizhető. Jogi jelentőség szempontjából ez nem elég. Ha ellenőrizni szeretné a dokumentum alatti elektronikus aláírást, ellenőrizze:
- a tanúsítvány érvényessége;
- az elküldött adatok matematikai érvényessége.
Pontosan ez történik a BSP mechanizmusban - erről egy kicsit később lesz szó. A platform ezt nem teszi meg.
Biztonságos TLS kapcsolat titkosított kommunikációs csatorna szervezéséhez. A TLS két verziója támogatott - 1.0 / 1.2. A TLS verziót az a forrás állítja be, amellyel kapcsolatot létesít - ha a forrás az 1.2 protokollt használja, akkor a platform titkosított kapcsolatot is 1.2 -re emeli. Ha BSP -t használ, akkor a "https" címet tartalmazó erőforrás elérésekor a titkosítás automatikusan bekapcsol. Ha a cím "http" -t tartalmaz, akkor a forgalom nincs titkosítva. Egy másik érdekes dolog, amit elmondhatok, hogy korábban titkosított kapcsolat csak RSA algoritmusokkal jött létre, most pedig GOST algoritmusokkal is. A böngészők még nem támogatják a GOST algoritmusokat, de a platform már tudja, hogyan. De sajnos nem minden olyan jó.
Már említettem, hogy a platform csak azokkal a titkosítóeszközökkel működhet, amelyek a számítógépre vannak telepítve. Ennek megfelelően van egy korlátozás - ha kriptográfiát szeretne használni, akkor rendelkeznie kell valamilyen kriptográfiai eszközzel. Hol a titkosító eszköz nem használható hordozható módban, telepíteni kell az operációs rendszerre... Úgy tűnik, hogy egy tokent egy kriptoeszközzel ragasztottak a számítógépbe, a platform működött vele - ez nem fog működni.
Az elektronikus aláírás csak PKCS # 7 formátumban jön létre(külön, külső fájl), a platform nem tud mást.
Néhány iroda aláírási formátumot igényel XMLDSig- leegyszerűsített változatban az a helyzet, amikor egy XML -fájlban felvehet egy bizonyos címkekészletet, aláírhatja őket, és az aláírást a következő címkébe teheti, így több aláírás található egy dokumentumban. A platform nem tudja, hogyan kell ezt megtenni.
Arra is felhívnám a figyelmet a platform használatával nehéz diagnosztizálni a felmerülő problémákat. Például van egy titkosító eszköz a számítógépen, van egy tanúsítvány, valahol van egy privát része a kulcsnak, és ha a platform elkezdi hívni mindezt, és valamikor valami nem felel meg, egyszerűen hibát adnak ki - hogy hiba történt és a művelet nem történt meg. Hogy mi történt ott, hol a probléma, nem világos. Ezért van mozgástér ebbe az irányba mind a platform, mind a titkosítási alapok tekintetében.
Kriptográfia a külső komponensekben
A platformkorlátozások megszüntetéséhez próbáljon meg külső összetevőt létrehozni.
- Ebből a célból az 1C -nek egésze van módszertan, elérhető az ITS -lemezen a https://its.1c.ru/db/metod8dev#content:3221:hdoc címen. Példák vannak csatolva hozzá, használhatja.
- Amikor külső összetevőt fejleszt, akkor Ön össze kell állítania az összes operációs rendszert, amelyen az ügyfelei futnak. Jó, ha előre tudja, hogy 100 ügyfele van, és mindegyik 32 bites Windows-al rendelkezik. Ha ez nem így van, akkor fel kell építeni:
- Linux esetén;
- Windows (32 bites és 64 bites);
- ha ügyfelei böngészőn keresztül dolgoznak, akkor minden egyes böngészőhöz külön bővítményeket kell létrehoznia.
- Működés közben még rosszabb lehet. Külső komponenssel dolgozik, mint olyan objektummal, amelynek tulajdonságait csak Ön ismeri. Ha a megvalósítás során valahol hibát követett el, az objektummal való interakció programkódja nem fog működni.
- Van még egy probléma - nem világos, hogyan fogja ezt a külső összetevőt eljuttatni az ügyfélhez... Az ügyfélnek már van platformja, a kriptoeszközökkel minden világos, most pedig írt egy külső összetevőt, amely összeköti a titkosítóeszközöket és a platformot. De hol van ez a külső összetevő, hogyan nem juttatta el az ügyfélhez, nem világos.
- Neked kellene a programkód karbantartása és frissítése... Ha külső komponensét tipikus megoldásként használja, akkor mindezt figyelembe kell venni a frissítéskor. És ha elengedik egy új verzió platformokon, mindent újra kell tesztelnie.
- Van kész példák külső alkatrészek. Gyakorlatom legszembetűnőbb példája a Sberbank külső összetevője. Pontosabban, a Sberbank külső összetevőt bocsát ki az 1C: DirectBank szolgáltatáshoz. Ez a külső komponens megvalósítja saját elektronikus aláírási formátumát és titkosított kapcsolat létrehozását.
BSP "Elektronikus aláírás" alrendszer
Most arról, hogy mennyire egyszerű a munka.
Az "1C: Library of Standard Subsystems" (BSP) az 1C kész szabványos konfigurációja, az univerzális funkcionális alrendszerek halmaza, amelyek közül az egyik az "Electronic Signature".
Rögtön szeretném felhívni a figyelmét, hogy maga a BSP egy bizonyos szint, amely el van szigetelve a platformtól, amely szoftverrel és felhasználói felülettel rendelkezik. Az "Elektronikus aláírás" alrendszer a titkosítással (titkosítás, elektronikus aláírás) való munkavégzéshez szükséges szoftvert és felhasználói felületet valósítja meg.
Az "Elektronikus aláírás" alrendszer mérlegelésekor fontos megérteni, hogy mit tartalmaz:
- Alapfunkciók, amelyek megvalósítanak valamit, amit soha nem szabad megérinteni, ha azt szeretné, hogy minden működjön.
- És van egy speciális újradefiniált rész a hozzánk hasonló fejlesztők számára, ahol hozzáadhat valamit, hogy valami másként működjön. Ha valami hiányzik, azt javaslom, hogy írjon azoknak a srácoknak, akik fejlesztik a BSP -t, hogy azok tartalmazzák az újradefiniálás lehetőségét az alapfunkciókban, és akkor megteheti, amire szüksége van az újra definiált részben.
Az alrendszer objektumai nem túl nagyok, csak két könyvtár van:
- "Programok elektronikus aláíráshoz és titkosításhoz";
- "Az elektronikus aláírási és titkosítási kulcsok tanúsítványai".
De a közös modulokban a kódsorok száma nagyon nagy - 11,5 ezer kódsor. És maga az alrendszerrel végzett munka nem túl egyszerű.
Hogyan lehet beágyazni az "Elektronikus aláírás" alrendszert?
Tegyük fel, hogy rendelkezik valamilyen konfigurációval, és úgy döntött, hogy ezt az alrendszert kell beépítenie:
- először is el kell olvasnia az ITS -en, hogy az alrendszerek hogyan vannak beágyazva;
- majd - olvassa el az alrendszerre vonatkozó utasításokat ("Az alrendszerek beállítása és használata konfiguráció kialakításakor" fejezet, "Elektronikus aláírás" alfejezet) - meg van írva a működési eljárás;
- feltétlenül ismerkedjen meg a BSP demóbázis "Elektronikus aláírás" alrendszerének hívási példáival;
- és végül, az alrendszer beépítése után ellenőriznie kell:
- objektumok beágyazásakor kiterjesztett platformellenőrzés történik;
- és van egy külön feldolgozás is az ITS -en "A BSP alrendszerek beágyazásának ellenőrzése" - segítségével ellenőrizheti, hogyan építette be mindezt.
És ha a nulláról van konfigurációja, akkor vegyen egy alrendszert, és írjon annak alapján - frissíti magát.
Hogyan tesztelhetem az elektronikus aláírást?
- A teszteléshez megteheti használjon önaláírt tanúsítványt- hogy kiadják azt a Microsoft titkosítási létesítményükben, amely a Windowsba van beépítve.
- Vagy tudsz használjon külső titkosítási információvédelmi eszközöket... A "CryptoPro" segítségével:
- töltse le a próbaverziót a webhelyéről;
- rendelje meg tanúsítványát a teszt -tanúsító központon keresztül;
- telepítse a teszt tanúsító hatóság gyökértanúsítványát;
- töltse le és telepítse a tanúsítvány -visszavonási listát (CRL) ettől a CA -tól.
Így "a kanapé kényelméből" tesztkörnyezetet kap a tanúsítványokkal és a titkosítással való munkavégzéshez. Ezt fel lehet használni.
Az "Elektronikus aláírás" alrendszer fő funkciói a BSP -től
Ez egy példa a BSP demo alapra. Az "Adminisztráció" részben két funkcionális lehetőség áll rendelkezésre: "Titkosítás" és "Elektronikus aláírás". Ha engedélyezte őket, lépjen a beállításokhoz.
A beállításokban két könyvtár található: "Programok" és "Tanúsítványok". A "Programok" részben a rendszer észleli, hogy mely programok vannak telepítve, és azonnal megmutatja, hogy minden jó vagy minden rossz. Ha olyan speciális kriptoeszközt használ, amely nem szerepel a BSP-ben, akkor kattintson a "Hozzáadás" gombra, és adja meg a hozzáférési paramétereket.
Ha webes ügyfélprogramon keresztül dolgozik, a BSP alrendszer felszólítja Önt, hogy először telepítsen egy kiterjesztést a fájlokkal való munkavégzéshez, és egy bővítményt a titkosítással való munkavégzéshez. Ez nagyon kényelmes, mert nem kell saját maga konfigurálnia - a rendszer megtalálja a kiterjesztést, és felajánlja a telepítését.
A tanúsítványokat kétféleképpen adhatja hozzá.
- Az első opció a "A számítógépre telepítettekből". Ebben az esetben megnyílik egy párbeszédpanel, ahol jelezzük, hogyan fogjuk használni ezt a tanúsítványt.
- És a második lehetőség - megrendelheti az új minősített tanúsítvány kiadását. Kérjük, vegye figyelembe, hogy maga a platform nem teszi lehetővé a tanúsítvány kiadásának elrendelését, de a BSP igen. A BSP integrálta az 1C tanúsítási központot, amely minősített elektronikus aláírást tanúsít. A beállítások varázslón keresztül léphet:
- a rendszer megmondja, mely dokumentumokat kell kitöltenie és kinyomtatnia a tanúsítvány kiadásához;
- megállapodást kell kötnie egy partnerrel, aki képes lesz azonosítani és átadni a dokumentumokat az 1C -nek;
- miután az 1C megkapta a dokumentumokat, tanúsítványt állítanak ki;
- a rendszer megtalálja és telepíti a számítógépre.
Így a felhasználók a program elhagyása nélkül minősített elektronikus aláírási tanúsítványt kapnak.
Aztán megtörténik a varázslat - a tanúsítvány ellenőrzése a beállítások helyességének diagnosztizálásával. Ez a párbeszédablak lehetővé teszi annak ellenőrzését, hogy a titkosítás helyesen van -e konfigurálva a számítógépen - a rendszer megpróbál aláírni egy tanúsítvánnyal, ellenőrizni, titkosítani, visszafejteni. Itt további diagnosztikai elemeket is beilleszthet.
Ha Önnek vagy ügyfeleinek problémái vannak, futtassa a "Diagnosztika" -t, és minden világos lesz. Ha problémák merülnek fel, mint például a dián lévő példában, akkor kattintson a hiba ikonra, ez megmutatja lehetséges okok, és megpróbál javaslatot tenni a javításra.
Az aláírásra és titkosításra / visszafejtésre vonatkozó hívások kezdeményezését a BSP bemutató adatbázis "Files" könyvtárának példáján vagy az "1C: Trade Management", "1C: ERP" - ugyanaz az alrendszer tartalmazza.
"1C-EDO" és "1C: Direct-Bank" szolgáltatások
Hogyan használják a titkosítást a szolgáltatásokban? Az első szolgáltatás, az 1C-EDO egy olyan szolgáltatás, amelyet jogilag jelentős elektronikus dokumentumok cseréjére terveztek barátságos 1C üzemeltetőkön keresztül.
- Az ügyfélfunkciókat az "Elektronikus dokumentumok könyvtárában" fejlesztették ki.
- Amikor megpróbál csatlakozni a szerverhez, titkosított SSL -kapcsolat (HTTPS -en keresztül) jön létre RSA algoritmusok használatával.
- A kriptográfiai hitelesítést használják. Mivel a szerver semmit nem tud rólunk, titkosított jogkivonatot küldünk Önnek, és ha Ön „helyes” személy, akkor ezt a jogkivonatot egy privát kulcs segítségével dekódolja, majd adatcserére használja.
- Lehetőség van egy elektronikus dokumentum megtekintésére, aláírására, ellenőrzésére, adatcsomagba csomagolására és elküldésére.
- Az ellenőrzés és általában minden titkosítás a BSP -n keresztül működik. Az elektronikus aláírás ellenőrzése két lépésben történik:
- először a tanúsítvány érvényességét ellenőrzik: érvényességi idő, bizalmi lánc, attribútumok;
- ha minden rendben van a tanúsítvánnyal, akkor a matematikai hash számítása történik. Ha minden rendben van a matematikával, az aláírást érvényesnek kell tekinteni, és csatolni kell a dokumentumhoz.
- Továbbá a BSP segítségével megvalósítják az EDM beállítások kiterjesztett diagnosztikáját - megállapítják, hogy a kiszolgálók rendelkezésre állnak, és hogy minden rendben van az elektronikus dokumentumáramlás résztvevőjével - aktív tarifatervei vannak stb.
A második szolgáltatás az 1C: DirectBank. Célja az elektronikus dokumentumok közvetlen cseréje a bankokkal, megkerülve az ügyfél-bank programot.
- Ezt a szolgáltatást az "Elektronikus dokumentumok könyvtára" is biztosítja.
- A nyílt technológia DirectBank a GitHubon található.
- Az újból - a szolgáltatással titkosított kommunikációs csatorna emelhető a GOST algoritmuson.
- A tőzsde beállítása a következőképpen történik: 1C kérést küld a banknak, hogy szerezze be egy adott ügyfél beállításait. Ha szükséges, a beállításokkal együtt a bank külsõ komponenst küld, amelyet további cserére használnak (a Sberbank megvalósítása szerint).
- Az engedélyezés vagy titkosított jogkivonat vagy SMS-ben történik (egyszeri jelszóval).
- Az elektronikus aláírás aláírása és ellenőrzése vagy a BSP -n, vagy külső összetevőkön keresztül működik (attól függően, hogy maga a bank hogyan valósította meg ezt).
- És a diagnosztika itt még érdekesebbé válik, a speciális típusú elektronikus dokumentumok cseréjének teljes ciklusán keresztül - "Request -probe".
- Az 1C rendszer engedélyezett a bank rendszerében, és elektronikus dokumentumot küld aláírásával;
- A bank ellenőrzi az ügyfél elektronikus aláírását, értesítést generál arról, hogy minden rendben van, és aláírja azt.
- Az értesítés megérkezik az 1C -hez, ellenőrzi, hogy a bank aláírása érvényes -e, majd azt mondja, hogy minden rendben van.
Itt van egy ilyen mini -ciklus - világossá teszi, hogyan van megfelelően beállítva a tőzsde a bankkal.
Saját megoldások titkosítással az 1C platformon
Hogyan fejleszthet saját titkosítási megoldásokat?
A konfigurációt a semmiből hozhatja létre, ha megnyitja a Syntax Assistant alkalmazást, és használja a platform képességeit a kriptográfiai műveletekhez. De én a BSP használatát javasolnám - ott már sokat írtak. Ebben az esetben nem 11 ezer sornyi kódot kell írnia, hanem kevesebbet. De az ötezer kódsor biztosan.
Már elmondtam, hogyan kell tesztelni. Kaphat egy vizsgálati bizonyítványt, és megpróbálhat dolgozni.
Ha a nulláról dolgozott ki egy konfigurációt, akkor azt saját maga karbantartja. És ha a fejlesztés során a BSP -t használta, és új funkciót adott ki, akkor frissítheti a BSP alrendszert, és kipróbálhatja ezt a funkciót. Nehézségek mindenképpen lesznek, mert itt nincs "ezüstgolyó". A megoldandó problémától függően megközelíteném annak felmérését, hogy érdemes -e kitalálni valamit, vagy sem. Egy adott feladatot figyelembe véve már Ön választ: a saját megoldását vagy a BSP -n alapuló szabványos megoldást.
Saját megoldásunk példája az IT Industry partner fejlesztése. Kifejlesztettek egy kis modult a belső elektronikus dokumentumkezeléshez az 1C: UPP alapján. Ott a nyomtatott nyomtatvány alapján egy elektronikus dokumentumot alakítanak ki, amelyet az információs bázis dokumentumához kötnek, és lehetőség van elektronikus aláírással aláírni. Egyszerű dokumentumáramlás a vállalaton belül, de még mindig kísérnie kell.
A titkosítás és a digitális aláírás megvalósításának nehézségei a szervezetekben
Mik fő problémák?
- Ha egy számítógépre kell telepítenie két titkosítási eszköz esetén konfliktus lép fel... Például, ha a jelentések a VipNeten keresztül működnek, és az elektronikus dokumentumkezelés a partnerekkel a CryptoPro -n keresztül. Hogyan lehet megoldani ezt a problémát?
Az első lehetőség az, hogy ezeket a titkosítási eszközöket különböző számítógépekre terjesztjük.
Ha ez nem lehetséges, akkor az egyik szolgáltatáshoz tanúsítványt kell kiadnia egy másik titkosítási létesítményről - amikor tanúsítványt rendel egy tanúsító központtól, megadhatja, hogy melyik titkosítási létesítményhez használja azt.
- Néha az ügyfeleknél A titkosítás nem működik az IE böngészőben- a bővítmény telepítése kötelező, de nincs telepítve. Banális tanácsok - futtassa a böngészőt rendszergazdaként... Ez telepíti a bővítményt, és a probléma megoldódik.
- Az 1C program nem mindig lát JaCard tokeneket... Nem tudom, mi a probléma, hogy JaCard vagy a platform. Újra telepíti a titkosító eszközt - egy ideig működik, és a rendszer újraindítása után újra repül. Valamiért az 1C és a JaCard nem túl barátságos.
- Van egy másik probléma is - a tanúsítványok ellenőrzésekor a platform mindig megpróbálja ellenőrizni, hogy mennyire megbízható ez a tanúsítvány, és néha meghiúsul. Miért történik ez? Van egy visszavonási lista, amely érvénytelen tanúsítványokat tartalmaz. Például, amikor egy alkalmazott elhagyja a vállalatot, tájékoztatnia kell a tanúsító központot arról, hogy a munkavállaló kilépett, és a tanúsítványa nem érvényes. Ezt követően a tanúsító hatóság kiadja a felülvizsgálati listát, amely tartalmazza ezt a tanúsítványt, és ezt követően érvénytelennek minősül. Néha valamilyen oknál fogva nem lehet ellenőrizni a tanúsítványt a visszavont listában. Mi a probléma? Ezeknek a véleménylistáknak semmi köze az 1C -hez, azokat maga a titkosító eszköz automatikusan frissíti. Ehhez stabil csatornát kell konfigurálni a tanúsító hatósággal. Ha a vélemények listája nem frissül automatikusan, az azt jelenti, hogy a szolgáltatás nincs megfelelően konfigurálva a tanúsító hatóságban, vagy egyáltalán nem létezik. Cserélje ki a tanúsító hatóságot, és a probléma megszűnik.
- Ha sok bizonyítvány van (például több mint 30), akkor nehézségek kezdődnek. Tegyük fel, hogy áthelyezte vállalkozását elektronikus sínekre, és a munkanap végén kiderül, hogy az aláírás érvénytelen, mert a tanúsítványa lejárt. A tanúsítvány kiállítása némi időt vesz igénybe, az üzlet "fülön van", Ön is. Ilyen esetekre a tanúsítványok listájának karbantartásához speciális szoftvert kell használnia... Vannak olyan programok, amelyek lehetővé teszik az irányítást életciklus tanúsítványt, és amikor lejár, emlékeztetőket küldenek a rendszergazdának. Ez mindennapos lehetőség, de lehetővé teszi a tanúsítványok többé -kevésbé megrendelését.
- Az 1C -ből származó adatcsere a szerverekről történik, ezért:
- nyitott portok az 1C -n: vállalati szerverek;
- jogait fiókot a kiszolgálóknak "internetkapcsolatnak" kell lenniük;
- ha van kiszolgálófürtje, akkor a fürtbe tartozó összes 1C szervernek nyitott portokkal kell rendelkeznie.
- Ha nincs bizalom egy külső erőforrás iránt, külön cikk található az ITS -ről "A probléma diagnosztikája" A távoli csomópont nem teljesítette a tesztet "".
- Alapvető biztonsági szabályok:
- nem tárolunk jelszavakat matricákon;
- munka után kivesszük a jelzőket az autókból;
- Rendszeresen frissítjük a víruskeresőt.
Ellenkező esetben kiderül, hogy hitelesített kriptográfiai eszközöket, kulcsokat szállított, és vannak olyan vírusok, amelyek kihasználhatják ezt. Ezért védje a kerületet.
Információ forrásai
Kérdések
Javaslom, hogy vegye igénybe azt a tanúsító központot, amellyel a jövőben együtt fog működni az elektronikus dokumentumok cseréje szempontjából. Például van egy "Taxcom" elektronikus dokumentumkezelő üzemeltetője, van egy tanúsító központja. Ha elkezdi az elektronikus dokumentumkezelést a Taxcomon keresztül, akkor érdemes tanúsítványt kérni tőlük.
Azt mondta, hogy az FSB adott egyfajta felvilágosítást a felhőtanúsítványokkal kapcsolatban. Hogy ha a tanúsítványt nem helyben, hanem a felhőben tárolják, akkor nem tekinthető megerősítettnek. Szokásos számla- és FRTT -csere esetén használhatunk felhőtanúsítványt, vagy szükség van megerősített tanúsítványra?
A törvény szerint a számlák cseréjénél szükség van egy továbbfejlesztett minősített elektronikus aláírásra, így a "felhő" itt nem fog működni. De más típusú elektronikus dokumentumok esetében - kérem.
Nagyjából elmondható, hogy bármely szabványos EFA esetében, amelyet 1C -ben használunk, szükségünk van egy továbbfejlesztett tanúsítványra?
Nem, nem mindenkinek. A törvény csak az elektronikus számlákról szól. Ezeket minősített elektronikus aláírással kell aláírni. A többi dokumentumról nem írtak semmit. Ez azt jelenti, hogy a számlákhoz, megrendelésekhez megerősített, minősítés nélküli elektronikus aláírást használhat - beleértve a felhőt is.
És nincs semmi az FRT -ről? Valójában az FRT ugyanaz, mint a számla.
Van egy homályos meghatározás - számla kiterjesztett mutatókkal, de ez nem ugyanaz, mint az UPD. Ezért úgy gondolom, hogy az UPD a minősítetlen elektronikus aláírás kategóriájába tartozik.
És milyen funkciót lát el az üzemeltető ebben az egész láncban - 1C -EDO vagy Taxcom? Általában az üzemeltetőkön keresztül küldünk dokumentumokat a kormányzati szerveknek, és számlát cserélünk, és amikor más dokumentumokat cserélünk a partnerekkel, miért van szükségünk operátorra?
A piacon lévő üzemeltetők is több napja dolgoznak, számlák mennek keresztül rajtuk. Azt mondják - elküldi az egyik számlát, a másik két dokumentum pedig ingyenes. Számláit továbbra is rajtuk keresztül cseréli, így azokon keresztül is könnyebb dokumentumokat küldeni. Egy másik dolog, ha egyszerűsített rendszeren dolgozik, és nincsenek számlái, akkor megkérheti az üzemeltetőt, hogy keressen Önnek egy olcsó díjcsomagot. És így ugyanabban az "Elektronikus dokumentumok könyvtárában" lehetőség van dokumentumok cseréjére elektronikus aláírással e-mailben, FTP-n keresztül stb. De ha 100 vállalkozója van, akkor nehéz lesz saját kommunikációs csatornát szervezni mindegyikük számára a támogatás szempontjából.
És ha egy önaláírt tanúsítványt akarunk tesztelni, az operátoron keresztül, akkor tesztelhetünk-e valamilyen cserét egy saját aláírású tanúsítvány használatával?
Nem, a kezelőn keresztül - nem. Ha valóban tesztelni szeretne, írjon az 1C címre, hogy csatlakozni szeretne az EDF szolgáltatáshoz a teszteléshez.
Azt mondják, hogy nem vagyunk tanúsító hatóság.
Írj nekem, segítek.
És ha EDM operátor nélkül cserélünk, aláírt elektronikus dokumentumot hoznak nekem, és fel akarom tölteni az 1C -re, hogy ott tárolhassam. Van -e elegendő pénze a BSP -nek annak ellenőrzésére, hogy ez CEP, és rendelkezik -e a megfelelő részletekkel, hogy mindez automatikus módban történjen, modális ablakok stb. Nélkül?
A gyakorlatomban nem láttam ilyen eseteket, de a BSP -ben mindenképpen lehetséges letölteni egy fájlt és ellenőrizni az elektronikus aláírását. Valószínűleg ehhez csak egy mestert kell rajzolni ehhez a forgatókönyvhöz: ellenőrizze a mappát, vegye át a dokumentumot, vegye alá az aláírást, ellenőrizze az összeset, tegye oda, ahol szüksége van rá, és mondja, hogy minden rendben van. Ami a hívás szinkronizálását illeti, mindezt a BSP -ben valósítják meg, a böngészőkben minden aszinkron módban működik.
És ha 1C -ben dolgozik a terminálon? Lehetséges a CryptoPro telepítése és a kulcsok továbbítása a terminálba? Mik azok a jellemzők, problémák? És ennek megfelelően, ha több mint 20 jogi személyünk van, és mindegyikhez két kulcs tartozik, hogyan zajlik ezekhez a kulcsokhoz való jogok megkülönböztetése? 1C szinten vagy mi?
Magában a BSP -ben, amikor betölti a kulcs nyitott részét, jelezheti, hogy melyik felhasználó számára lesz elérhető. Itt a saját neve alatt bejelentkezve csak a tanúsítványait láthatja. De ugyanakkor mind a számítógépen lesznek. Ezért maga is megérti, hogy feltétlenül nem szükséges a privát rész telepítése a rendszerleíró adatbázisba, mert a kulcs privát része könnyen átvihető gépről gépre. Jobb a tokenek használata. Lehetőség van token továbbítására a következővel: zárt rész kulcsot a terminálkiszolgálóhoz. A srácok, akik maguk készítik a kulcsokat, segítenek beállítani, hogy ez a kulcs látható legyen a terminálon. Próbálja ki, kísérletezzen, keressen más kulcsokat, keressen embereket, akik segítenek a beállításban. De itt meg kell értenie, hogy ez az alagút a terminálkiszolgálótól a kulcsáig nem biztonságos. Létrehoz egy elektronikus dokumentumot a terminálkiszolgálón, és azt mondja - írja alá. Mi fog történni? Az adatokat nem védett csatornán továbbítják először a helyi számítógéphez, ahol a kulcs telepítve van, elektronikus aláírás jön létre, majd az adatok visszakerülnek a terminálkiszolgálóra. De ez a csatorna nem biztonságos. Védeni csak szakember telepítésével lehet szoftver ami biztonságossá teszi az alagutat a terminálkiszolgáló és a helyi gép között. Ha biztonságosan szeretne dolgozni, akkor egy tokent kell szállítania, továbbítania a terminálhoz, és telepítenie kell a szoftvert a terminálkiszolgáló és az ügyfélgép közötti csatorna titkosítására.
Mondja meg, hogy van-e különbség az elektronikus számla aláírása és a szkennelt 100 oldalas szerződés között (ahol tisztán grafika).
Minél nagyobb a dokumentum, annál lassabb az aláírása, mert aszinkron titkosítás létezik - a kivonat kiszámítása aszinkron algoritmus segítségével történik. De abból a szempontból, hogy elektronikus számlát ír alá több sorban, vagy 10 MB -os fájlt, vizuálisan nem fogja észrevenni a különbséget. Csak az 1000-3000 dokumentumból álló köteteknél vegye figyelembe.
Az 1C-EDO barangolásról. A Taxcom barangol az üzemeltetők között. Mennyire hatékony az 1C-EDO-ban? Van ilyen tapasztalata? Mivel minden vállalkozó különböző operátorokat használ, és nagyon nehéz a maximális lefedettségű üzemeltetőt választani. Kit ajánlanátok?
Ha az 1C-EDO és mások közül választ, akkor természetesen az 1C-EDO. De az 1C -EDO -nak vannak problémái a roaminggal - nem támogatja sok szolgáltatót. Van egy külön forrás az 1C-EDO számára, van egy lista a támogatott operátorokról, azt hiszem, hogy idővel pótolni kell.
Hol tárolja az aláírt dokumentumok archívumát? Helyileg a cégben vagy a felhőben? Biztosítható -e a felhőben tárolt dokumentumok érvényessége?
Az, hogy hol tároljuk az aláírt dokumentumokat (a felhőben vagy sem), nem számít. Matematikailag a hash már kiszámításra került, és a dokumentum tartalma nem cserélhető nyom nélkül. Ezután legalább 10 -szer átviheti valahová, az aláírás tisztán matematikailag mindig ellenőrizhető. Ha a felhőszolgáltatás kényelmes, kérjük, tárolja benne, ez valószínűleg még érdekesebb.
Az üzemeltető nyújt -e ilyen szolgáltatást?
Ha külön szerződést köt vele a biztonsági mentések tárolására, azt külön pénzért teszik.
Nem őrzik meg az aláírt dokumentumokat?
Fizikailag tárolják, de a törvény nem írja elő, hogy tárolják. Csak a nyugtát kell megőrizniük. Ha az adóhatóságok hozzájuk fordulnak, és megkérdezik, hogy átment -e ilyen és ilyen dokumentum, akkor azt mutatják, igen, itt a nyugta, nézd - az aláírás ilyen és olyan. És hogy mi van ebben a dokumentumban, az már nem kérdés számukra.
És az SCP esetében az üzemeltetők nem biztosítanak feldolgozást az EDF számára?
Az üzemeltetőkről nem mondhatok, sokan vannak, és mindegyiknek megvan a maga fejlesztése, de maga a UPP rendelkezik elektronikus dokumentumárammal.
****************
Ez a cikk az INFOSTART EVENT 2017 COMMUNITY konferencián elolvasott eredmények alapján készült. További cikkek olvashatók.
2020 -ban mindenkit meghívunk, hogy vegyen részt 7 regionális találkozón, valamint a jubileumi INFOSTART EVENT 2020 moszkvai rendezvényen.
Elektronikus aláírás (a továbbiakban: ES), a szövetségi törvénnyel összhangban Orosz Föderáció A 63-ФЗ sz., 2011. március 25-én kelt "Az elektronikus aláírásról" elektronikus formában meghatározott információ, amelyet más elektronikus formában (aláírt információ) csatolnak, vagy más módon az ilyen információhoz társítanak, és amelyet az aki aláírja az információkat ... A meghatározott normatív aktus felváltotta az Orosz Föderáció 2002. január 10-i 1-FZ számú „Elektronikus digitális aláírásról” szóló szövetségi törvényét, amely 2013. július 1-jén elveszítette jogi erejét.
A 2011. március 25 -i törvény kétféle elektronikus aláírást különböztet meg: egyszerű és továbbfejlesztett. Ez utóbbi lehet minősített vagy szakképzetlen. Ha egy egyszerű ES csak megerősíti, hogy egy adott elektronikus üzenetet egy meghatározott személy küldött, akkor a megerősített, minősítés nélküli ES lehetővé teszi nemcsak a feladó egyértelmű azonosítását, hanem azt is, hogy senki sem változtatott rajta a dokumentum aláírása óta. A jövőben megerősített, minősítetlen ES -ről fogunk beszélni. A minősítés nélküli elektronikus aláírással ellátott üzenet a saját kezűleg aláírt papíralapú dokumentummal egyenlő, ha erről a felek előre megállapodtak, valamint a törvényben kifejezetten előírt esetekben.
Egyrészt az ES -t használják a dokumentum szerzőségének megerősítésére - ez a jelentése a dokumentum feladója számára. Másrészt az elektronikus aláírás, ha jogerősnek ismerik el, biztosítja, hogy a szerző ne utasítsa el az aláírt dokumentumot, ami viszont fontos a dokumentum címzettje számára. Vitatható helyzet esetén mindig elvégezhető a konfliktusok elemzése, amely egyértelműen meghatározza az aláírt dokumentum szerzőjét, és felelőssé teszi őt az aláírt dokumentumért.
Az elektronikus aláírással kapcsolatos konfliktusok elemzése
A sporthelyzetekben fennálló konfliktusok elektronikus aláírással aláírt dokumentumokon alapuló elemzésének fő problémája annak bizonyítása, hogy "az elektronikus formában közölt információ, amely más formában elektronikus információhoz van csatolva (aláírt információ)" jogilag jelentős egy adott személy elektronikus aláírása egy adott dokumentum alatt.
A kriptográfiai módszerek használata lehetővé teszi számunkra, hogy megoldjuk ezt a problémát. Ha egy személy egyedi elektronikus kulcsot kap, majd speciális átalakításokat hajt végre ezen elektronikus kulcs és egy elektronikus dokumentum használatával, akkor ezen átalakítások eredménye (és ez az elektronikus aláírás) egyedi lesz erre a párra (kulcsdokumentum). Így a konfliktusok elemzésének első szakaszának feladatát - annak feltárását, hogy egy adott aláírás adott elektronikus kulccsal készült -e vagy sem - kriptográfiai módszerekkel oldják meg.
A konfliktusok elemzésének második szakasza annak bizonyítása, hogy ez az elektronikus kulcs egy adott személy tulajdona. Ez a bizonyíték az ES jogi jelentőségét adja. Ennek a szervezeti problémának a megoldására - a kiadott kulcsok elszámolására - a PKI -t (Public Key Infrastructure) használják.
Az ES jogi értékének megadása a PKI használatával
Az elektronikus aláírásról szóló törvény megkülönbözteti az ES -kulcsot és az ES -ellenőrző kulcsot. Az elektronikus aláírás kulcsa az elektronikus aláírás létrehozásához használt egyedi karaktersorozat. Az elektronikus aláírás ellenőrző kulcsa olyan egyedi karaktersorozat, amely egyedi módon kapcsolódik egy elektronikus aláírási kulcshoz, és amelynek célja az elektronikus aláírás hitelességének ellenőrzése. Az ES kulcs az ES kulcsból származik, de a fordított művelet lehetetlen. Így az ES-kulcs és az ES-ellenőrző kulcs között egy-egy levelezés van. Az ES kulcsot az ügyfélnek kell létrehoznia, és titokban kell tartania. Ezt a kulcsot használják a dokumentumok elektronikus aláírással történő aláírására. Az ES ellenőrző kulcs az ES ellenőrzésére szolgál, és elküldik mindenkinek, aki szeretné ellenőrizni az aláírást.
A PKI fő eleme a tanúsító hatóság. A Hitelesítési Központ nyilvántartást vezet a kulcsok és a kulcsok tulajdonosai közötti levelezésről. A kulcs regisztrálásához az ügyfél elviszi kulcsa nyilvános részét és azonosító adatait a CA -hoz, és megkapja a megfelelőségi tanúsítványt, amely megerősíti, hogy tulajdonosa ennek a kulcsnak. A megfelelőségi tanúsítvány tartalmazza az ES ellenőrző kulcsot és az ügyfél azonosító adatait, és a hitelesítésszolgáltató ES aláírja. Így a CA igazolja, hogy az ügyfelet ellenőrizték, és azt állítja, hogy ő az. A tanúsítvány kézhezvétele után az ügyfél saját kezű aláírásával aláírja a kiállított tanúsítvány érvényességéről szóló speciális dokumentumokat. Ezek a dokumentumok a fő összeköttetés egy adott személy és az "elektronikus szimbólumok halmaza", az ő elektronikus aláírása között.
Így az aláíró tanúsítványa elegendő az aláírás ellenőrzéséhez és az aláíró azonosításához. Vagyis az aláíró aláírja a dokumentumot az ES kulcsával, majd elküldi a címzettnek ezt az aláírt dokumentumot és az ES ellenőrző kulcsot tartalmazó tanúsítványát. Így a címzett képes lesz ellenőrizni, hogy az aláírás valóban az aláíró ES kulccsal készült -e, és megkapja az aláíró azonosító adatait a tanúsítványból. Az ügyfélnek meg kell védenie ES kulcsát a kompromisszumoktól. Ebből a célból különféle hardverkulcs -tárolókat hoznak létre emelt szint védelem, például egy ruToken USB -eszköz.
Orosz szabvány EP
Az EDS szabványok kétszintűek. Az első szinten az elektronikus aláírás közvetlenül a dokumentumból található. A második szint tartalmazza az ES -t és az ES jogi jelentőségéhez szükséges összes dokumentumot: az aláíró tanúsítványát vagy a tanúsítványok láncolatát, az aláírás létrehozásának idejét stb.
Az első szintű elektronikus szabvány orosz szabványa a GOST 34-10.2012. A második szint ES orosz szabványa a PKCS # 7, TSA időbélyegek hozzáadásával.
Az EP alkalmazási területei
- Internet bank
- elektronikus piactér
- vállalati dokumentumkezelő rendszerek
- jelentések benyújtása a különböző szövetségi szolgálatoknak
- szerzői jog
WEB-oldal elektronikus aláírással
A probléma megfogalmazása
Tegyük fel, hogy szervezete úgy döntött, hogy áttér a webes elektronikus dokumentumkezelő rendszerre. Ugyanakkor a legfontosabb helyek, ahol ES szükséges:
- Tetszőleges formátumú ES fájlok, amikor azokat a felhasználó a beviteli űrlapon keresztül feltölti a webhelyre
- A felhasználó által a webhelyen található beviteli űrlapba beírt szöveges adatok ES
- A honlapon több felhasználó által közzétett dokumentum elektronikus aláírása
- az adatátvitel kriptográfiai védelme a felhasználó munkahelye és a weboldal között
- felhasználói hitelesítés digitális tanúsítvánnyal az övéhez való hozzáféréshez Személyes terület
- a szerveren tárolt információk kriptográfiai védelme
Megoldási séma
Tanúsító központ létrehozása
válassza ki azt a szervert, amelyen a tanúsító hatóság telepítésre kerül. Opcionálisan időbélyegző és online tanúsítványállapot -ellenőrző szolgáltatások is telepíthetők. Pénzmegtakarítás céljából a CA és a megadott szolgáltatások egy szervert használhatnak, amelynek online elérhetőnek kell lennie. Az alábbiakban ezen szolgáltatások megvalósíthatóságáról fogunk beszélni.
telepítse a MagPro CryptoPacket terméket a szerverre
hozzon létre egy CA kulcsot és egy alkalmazást egy CA gyökértanúsítványhoz a MagPro CryptoPacket mkkey segédprogramjával. A kulcs létrehozható egy biztonságos eszközön, például a ruToken -en. A CA -kulcs létrehozása után szervezeti módszerekkel kell biztosítania annak biztonságát. A legtöbb biztonságos lehetőség a kulcs tárolása a ruToken eszközön, és csak a tanúsítványok kiadásakor csatlakozik a szerverhez. A CA tanúsítvány egy fájl. Ezt a fájlt a tanúsítvány kézhezvételét követően a CA minden ügyfele kiállítja.
hozzon létre gyökér CA tanúsítványt a MagSpro CryptoPacket OpenSL segédprogramjával.
hozzon létre egy könyvtárszerkezetet a fájlrendszerben, amelyben a kiállított felhasználói tanúsítványokat, a kiadott szervertanúsítványokat és a tanúsítványalkalmazásokat fájlok formájában tárolja. A szervezeti módszereknek (például az ACL -ek használata) megfelelő engedélyeket kell biztosítaniuk ezekhez a könyvtárakhoz. A tanúsítványokat PEM fájlként adják ki. Ne feledje, hogy a tanúsítványfájlok nevét a legjobban tisztán kell tartani, hogy később könnyebben megtalálják a tanúsítványokat.
Hozzon létre PKCS # 10 tanúsítványkulcsot és regisztrációt
A tanúsítvány beszerzéséhez egy CA felhasználó kétféle sémát használhat: központosított és távoli. Központosított sémával a felhasználó a CA -hoz érkezik, és kap egy fájlt, amely tartalmazza a kulcsot és a tanúsítványt. Ezután hozzáadja ezt a fájlt egy USB flash meghajtóhoz. Ez a séma egyszerű és kényelmes, de nem biztonságos, mivel lehetővé teszi a CA alkalmazottai számára, hogy megtudják a felhasználói kulcsot. De bizonyos esetekben e rendszer használata indokolt.
A tanúsítvány megszerzésének legbiztonságosabb rendszere kerül terjesztésre. A felhasználó létrehoz egy kulcsot, létrehoz egy PKCS # 10 tanúsítványkérést, amely tartalmazza az ES ellenőrző kulcsát és azonosító adatait. A felhasználó az ES -kulccsal aláírja ezt az alkalmazást, és viszi a CA -hoz. A CA ellenőrzi az aláírást az alkalmazásban, ellenőrzi a felhasználó azonosító adatait, például útlevéladatokkal, és tanúsítványt állít ki. Ezután a tanúsítvány kinyomtatásra kerül, és a felhasználó manuálisan aláírja a dokumentumot, amely megerősíti a kiadott tanúsítvány megfelelőségét.
A vitatott megoldás részeként a MagPro CryptoPacket speciális programja segítségével kulcsokat generálnak és rendelést hoznak létre. Ez a program a CryptoTunnel egyéni készlet tartalmazza.
Ez a program rugalmas konfigurációs rendszerrel rendelkezik, amellyel teljes mértékben rendeléseket hozhat létre különböző fajták tanúsítványok, bővítse az azonosítási információk szabványos halmazát, szerepeket és felhasználói jogokat adjon hozzá a tanúsítványokhoz, például a webes erőforrásokhoz való hozzáférés korlátozásához; különféle attribútumokat adhat az alkalmazáshoz.
A kulcs létrehozása után a felhasználónak gondoskodnia kell arról, hogy biztonságosan tárolja.
Az elektronikus aláírásra vonatkozó tanúsítványok típusai a WEB-oldalon
Portálunkon többféle tanúsítványt fogunk használni:
root CA tanúsítvány
Ez a tanúsítvány az összes többi tanúsítvány érvényesítésére szolgál a webportál tagjai számára.
TLS szerver hitelesítési tanúsítvány
Ezt a tanúsítványt használja az ügyfél a szerver ellenőrzésére, amikor biztonságos TLS kapcsolatot hoz létre, amikor aláírt dokumentumokat továbbít egy webhelyre
TLS ügyfél -hitelesítési tanúsítvány
Ezt a tanúsítványt arra használják, hogy a szerver ellenőrizze az ügyfelet, és hogy az ügyfél hozzáférhessen személyes fiókjához, amikor biztonságos TLS -kapcsolatot hoz létre, amikor aláírt dokumentumokat továbbít a webhelyre.
az ügyfél ES tanúsítványa
Az ügyfél hozzáadja ezt a tanúsítványt az elektronikus aláírásához, és így az ellenőrző fél ellenőrizheti az aláírást és azonosíthatja az aláírót
OCSP szerver aláíró tanúsítvány
Ezzel a tanúsítvánnyal az OCSP szerver kiegészíti az aláírt válaszát annak ellenőrzésére
TSA szerver aláíró tanúsítvány
Ezzel a TSA szerver tanúsítványt ad az aláírt válaszhoz annak ellenőrzésére és jogi jelentőségének megadására.
Mindezek a tanúsítványtípusok a MagPro CryptoPacket és a CA segédprogramjával hozhatók létre a MagPro CryptoPacket alapján.
Tanúsítvány beszerzése a CA -nál
Amikor a felhasználótól érkezik egy alkalmazás, a CA rendszergazdája biztonsági másolatot készít az alkalmazásról. Ezután ellenőrzi az alkalmazást, és az openssl segédprogram használatával létrehoz egy felhasználói tanúsítványt, aláírja a CA -kulcson, és gondoskodik annak biztonsági mentéséről is. Ezenkívül a jogi jelentőség biztosítása érdekében az adminisztrátor kinyomtatja a tanúsítványból az információkat (ezeket az információkat az openssl.exe segédprogram segítségével szerezheti be), és kézi felhasználói aláírást kap ezen a nyomaton. Ezután kiállítja a felhasználónak a tanúsítványát egy fájlban.
Így pillanatnyilag telepíthettük a CA -t, és megtanultuk, hogyan lehet felhasználói kulcsokat létrehozni, tanúsítványok iránti kérelmeket elfogadni tőlük, és tanúsítványokat kiadni a beérkezett alkalmazások után. A felhasználó megerősíti a tanúsítvány kézhezvételét és megfelelését kézi aláírásával, ezért vitatható, hogy a PKI -t telepítettük, ami biztosítja a felhasználó elektronikus aláírásának jogi jelentőségét
A következő feladat az, hogy a telepített PKI -t használja egy alkalmazott probléma megoldására - az aláírt elektronikus dokumentumok biztonságos átvitelének megszervezése böngésző segítségével egy webhelyre, és fogadása a webhelyen történő feldolgozásra.
Elektronikus aláírás ellenőrző és tároló modul (szerver)
Általában a webhely valamilyen webszerveren (Apache, IIS, nginx stb.) Van telepítve. Ez a webhely személyes fiókot tartalmaz minden, az oldalon regisztrált felhasználó számára. A személyes fiók eléréséhez a felhasználónak át kell esnie a hitelesítési eljáráson. A hitelesítés általában a felhasználói regisztráció során megállapított bejelentkezési név és jelszó megadásából áll.
Ezenkívül egy webes beviteli űrlapot használnak elektronikus dokumentumok feltöltésére a szerverre.
Annak érdekében, hogy az oldalra feltöltött dokumentumok elektronikus aláírásának ellenőrzését "hozzáköthessük" ehhez a rendszerhez, biztosítsuk a felhasználó böngészője és az oldal közötti kapcsolatok védelmét, valamint biztosítsuk a felhasználó szigorú kriptográfiai hitelesítését a a személyes fiókot, a MagPro CryptoServer terméket telepíteni kell a szerverre.
Az építészeti megoldás így fog kinézni:
A CryptoServer a védett webszerver elé van telepítve. Ebben az esetben a webszerver úgy van konfigurálva, hogy csak a CryptoServerről fogadja a bejövő kapcsolatokat (lásd a telepítési utasításokat). A CryptoServer elfogadja a bejövő HTTS kapcsolatokat, dekódolja azokat és továbbítja a webszerverre. Ezenkívül a CryptoServer hozzáadja az X509-Cert fejlécet a HTTP-kéréshez, amelyben továbbítja a hitelesítési eljáráson átesett ügyfél digitális tanúsítványát. Ezt a tanúsítványt használják az ügyfél személyes fiókjához való hozzáféréshez. A továbbított dokumentumok alatti elektronikus aláírás ellenőrzéséhez a CryptoServer tartalmazza az openssl segédprogramot, amely lehetővé teszi a különböző típusú aláírások ellenőrzését, aláírói tanúsítvány vagy tanúsítványlánc beszerzését a PKCS # 7 borítékból stb. Az elektronikus aláírás ellenőrzéséhez a dokumentumok fogadására szolgáló weboldalnak hívnia kell ezt a segédprogramot.
Elektronikus aláírás generáló modul (kliens)
A felhasználó fő feladata a weboldal elérésekor elektronikus dokumentumok és szöveges adatok feltöltése a webhelyre, valamint elektronikus dokumentumok letöltése a webhelyről. Az SSL / TLS -en keresztüli webes kapcsolat védelme érdekében és a webhelyre továbbított adatok online aláírásához a CryptoTunnelt kell használni az ügyfél munkaállomásán.
A CryptoTunnel fő előnyei:
- védi a webkapcsolatokat bármely böngésző és egy weboldal között az SSL / TLS protokoll használatával, támogatva az orosz titkosítási algoritmusokat
- lehetővé teszi a felhasználó hitelesítését digitális tanúsítvány használatával a felhasználó személyes fiókjának eléréséhez
- lehetővé teszi a dokumentumok online aláírását a webhelyre feltöltve, CSP és Active X használata nélkül
- Támogatja az online tanúsítvány állapot -ellenőrzőt (OCSP)
- támogatja a megbízható időbélyegek beszerzését a digitális aláírás (TimeStamp) alatt
- Támogatja a különböző USB tokeneket és intelligens kártyákat a kulcsok tárolásához
- nem igényel telepítést egyedi helyekre, másolás útján
- rendes pendrive -on tárolható és futtatható
- nem igényel rendszergazdai jogokat a működéshez
- támogatja a működést bármilyen webböngészővel (Internet Explorer, Mozilla Firefox, Google chrome, Opera, Safari Apple, stb.)
- nem "kötődik" egy számítógéphez - a felhasználó használhat egy készletet irodai és otthoni használatra - pénzt takaríthat meg
- egyszerű és érthető felhasználói felülettel rendelkezik, így nincs szükség felhasználói képzésre
- lehetővé teszi, hogy minimalizálja a felhasználók technikai támogatásának költségeit
- operációs rendszerek széles skáláján futhat (platformok közötti megoldás)
Ez az összes művelet, amelyet el kell végezni ahhoz, hogy a CryptoTunnel elkezdhesse aláírni a webes űrlapon keresztül továbbított adatokat és fájlokat. Nincs szükség további szkriptek írására, Active X hívására stb.
Több elektronikus aláírás megszervezése
Több dokumentumot kell megadni, ha a dokumentumot több személynek kell aláírnia. Ebben az esetben a dokumentumot általában úgy teszik közzé az oldalon, hogy csak azok a felhasználók érhessék el, akiknek kötelező az elektronikus aláírásuk. A hozzáférés ezen megosztását a felhasználók digitális tanúsítvánnyal történő hitelesítése biztosítja.
A CryptoTunnel használata során a felhasználónak nem kell letöltenie a dokumentumot, majd alá kell írnia és újra fel kell töltenie a dokumentumot a szerverre - a CryptoTunnel automatikusan elvégzi ezeket a műveleteket, amikor rákattint a weboldalon található gombra.
OCSP szolgáltatás
Gyakran előfordul, hogy a CA visszavonja a felhasználó tanúsítványát (például ha a felhasználó kulcsát ellopta egy betolakodó). Ugyanakkor a többi felhasználót értesíteni kell a tanúsítvány visszavonásáról, hogy ne bízhassanak benne. Számos módon értesítheti a felhasználókat a felülvizsgálatról.
A legtöbb egyszerű módon a visszavonási listák (CRL) megoszlása. Vagyis a CA létrehoz és periodikusan frissít egy speciális fájlt, amelyet a felhasználók is rendszeresen letöltenek.
Egy másik módja az online tanúsítvány állapot -ellenőrző szolgáltatás, az OCSP szolgáltatás használata. Bármely tanúsítvány állapotának ellenőrzéséhez a CryptoTunnel és a CryptoServer automatikusan OCSP kérést alkot, küldje el ezt a kérelmet a szolgáltatásnak a hálózaton keresztül. A szolgáltatás ellenőrzi a tanúsítványt, aláírja az ES ellenőrzési eredményét, és választ küld az ügyfélnek. Az ügyfél megnézi a választ, ellenőrzi az aláírást, és eldönti, bízik -e benne ezt a bizonyítványt vagy nem.
Az OCSP szolgáltatás a MagPro CryptoPacket OpenSL segédprogramjával hozható létre. Kérjük, vegye figyelembe, hogy a CRL és az OCSP közötti választás mindig a webhely -építők saját belátása szerint történik. A CRL valamivel olcsóbb, az OCSP valamivel biztonságosabb.
El kell vetni, hogy a CryptoTunnel és a CryptoServer egyaránt támogatja az OCSP -t és a CRL -t.
TSA időbélyegző szolgáltatás
Az időbélyeg -szolgáltatás fő célja annak megerősítése, hogy a dokumentumot elektronikus aláírással írták alá legkésőbb az időbélyegzőben meghatározott időpontig.
Időbélyegző létrehozásához a CryptoTunnel létrehoz egy TSA kérést, amelyhez kivonatot csatol a digitális aláírásból; elküldi ezt a kérést a TSA szolgálatnak. A TSA szolgáltatás hozzáadja az aktuális időt ehhez a kivonathoz, és aláírja az eredményt az ES -vel. Így létrejön egy megbízható időbélyeg.
A megbízható időbélyegekből álló online szolgáltatás létrehozásához használja a MagPro TSA terméket. Ebben az esetben az időbélyegző szolgáltatás URL -jét a webes aláírási űrlapot tartalmazó weboldal határozza meg
A TSA kliens része a CryptoTunnelbe van beépítve. Az elektronikus aláírás időbélyegzőjének kézhezvétele után minden művelet automatikusan, a felhasználó bevonása nélkül történik.
Döntőbíró
A választottbíró egy speciális program, amelyet a konfliktusok elektronikus aláírással történő elemzésére használnak.
A döntőbíró lehetővé teszi, hogy megjelenítse a PKCS # 7 aláírásban szereplő tanúsítvány azonosságát; vizualizálja a bizalmi láncot és az elektronikus aláírás (TimeStamp) létrehozásának idejét. A konfliktus elemzéséhez a választottbíró ellenőrzi az aláírást a megadott dokumentum alatt, és megtudja, hogy azt a tanúsítvány tulajdonosa készítette -e.
Meg kell jegyezni, hogy a konfliktusok megoldásának lehetősége érdekében a dokumentumokat és azok aláírásait hosszú ideig elektronikus archívumban kell tárolni.
Személyes adatok védelme a WEB-oldalon
Az ügyfél böngészője és az oldal között kicserélt adatok személyes adatokat és bizalmas információkat tartalmazhatnak. Ha a webhely minden felhasználója érdekli a bizalmas információk védelmét, akkor a személyes adatok védelme a 152-FZ „A személyes adatokról” szövetségi törvény követelménye.
A webhely használata során az adatok veszélyben vannak, amikor azokat az interneten keresztül továbbítják, és amikor később tárolják azokat a webhely szerverén.
Védelem a kliens és a szerver között
Az Internet nem biztonságos kommunikációs csatorna. Az interneten keresztül történő adattovábbítás fő veszélye az "ember a közepén" támadás, vagyis a támadó csatlakozik az ügyfél és a szerver közötti vonalhoz, és lecseréli a továbbított információkat. Az adatok védelmének egyetlen módja az interneten az adatok titkosítása. Mivel a titkosítás titkosítási módszer az információk védelmére, az FSB kriptográfiai információvédelmi eszközökre vonatkozó követelményei vonatkoznak rá - az FSB tanúsítvány megléte.
Az SSL / TLS a felhasználó böngészője és a webhely közötti kommunikáció titkosítására szolgál (webkapcsolatok). A CryptoTunnel adatvédelmet biztosít ehhez a protokollhoz, amely teljes mértékben megfelel az FSB követelményeinek. Így a "CryptoTunnel" tanúsított megoldás, amely teljes mértékben megfelel a személyes adatok védelmére vonatkozó technikai eszközökre vonatkozó követelményeknek.
Tárolási védelem
Amikor adatokat tárol az oldal elektronikus archívumában, ezeket az adatokat titkosított formában kell tárolni. A biztonságos elektronikus archívum létrehozása külön cikk témája.
ALAPFOGALMAK
KSKPEP
- Az elektronikus aláírás ellenőrző kulcsának minősített tanúsítványa.
CEP- minősített elektronikus aláírás.
Kripto -szolgáltató – az információk titkosításának védelmének eszközei.A program, amelynek segítségével az elektronikus aláírás zárt része készül, és amely lehetővé teszi az elektronikus aláírással való munkát. Ez a jelölőnégyzet automatikusan be van állítva.
Export kulcs – az elektronikus aláírás másolási lehetőségére. Ha nincs pipa, akkor az elektronikus aláírás másolása lehetetlen.
Festés- bal egérgomb.
PKM- jobb egérgomb.
CRM-ÜGYNÖK- a CA szakemberei által kifejlesztett alkalmazás, amely egyszerűsíti a kulcspárok létrehozásának, a kérés létrehozásának és a tanúsítvány megírásának eljárását.
Miután meglátogatta a tanúsító központot, és elvégezte a személyazonosság -ellenőrzési eljárást, a kérelemben megadotthoz email, A CA levelet küldött a létrehozandó linkre. Ha nem kapott leveleket, kérjük, vegye fel a kapcsolatot a menedzserével vagy a TC műszaki támogatásával a kézikönyvben található elérhetőségen.
Nyissa meg az e -mailből létrehozott linket az ajánlott böngészők egyikében:Google chrome, Mozilla Firefox, Yandex böngésző... Ha már a fenti böngészők valamelyikében van, kattintson a linkre Festés vagy PKM> "Link megnyitása új lapon". A generációs oldal (1. ábra) új ablakban nyílik meg.
Amikor megnyitja a linket, egy kezdeti figyelmeztetés jelenik meg. Nézze meg, ha tárolóeszközt használ a CEP tárolására.Jacarta LT ... Tudjon meg többet a médiáróllent. Ha másik adathordozót használ, kattintson a gombra "Bezárás".
1. ábra - Generációs oldal
Kattintson a linkre"Töltse le az alkalmazást" a letöltés megkezdéséhez. Ha a kattintás után nem történt semmi, kattintson a linkre PKM > "Link megnyitása új lapon"... Az alkalmazás letöltése után indítsa el a telepítést.
Javasoljuk, hogy a program letöltése előtt tiltsa le a víruskereső szoftvert !
A telepítési folyamat során « crm - ügynök » megjelenik egy hozzáférést kérő üzenet (2. ábra).
2. ábra - Hozzáférési kérelem
Kattintson a gombra "Igen".
Az alkalmazás telepítésének befejezése után térjen vissza az oldalra a generációval. Megjelenik a „Hozzáférés engedélyezése” üzenet (3. ábra).
3. ábra - Hozzáférés a tanúsítványtárolóhoz
Kattintson "Folytassa"és a megjelenő ablakban, "Hozzáférést biztosít"(4. ábra).
4. ábra - Hozzáférés a tanúsítványtárolóhoz 2
Ha a gomb nem jelenik meg "Folytassa"
Ha az alkalmazás telepítése után « crm - ügynök » , az alkalmazás letöltésére szolgáló link nem tűnt el, ennek oka lehet az, hogy a biztonsági rendszer blokkolja a kapcsolatot.
A helyzet kiküszöböléséhez a következőket kell tennie:
Tiltsa le a számítógépre telepített víruskereső programot;
Nyisson meg egy új lapot a böngészőben;
Írja be a címet szóköz nélkül a böngésző címsorába - 127.0.0.1:90 - és menjen (nyomja megBelép billentyűzeten);
Amikor megjelenik egy böngészőüzenet "A kapcsolat nem biztonságos", adja hozzá az oldalt a böngésző kivételeihez. Például,Króm: "További" - "Mindenképpen menjen az oldalra"... Más böngészők esetén használja a megfelelő fejlesztői utasításokat.
A hibaüzenet megjelenése után térjen vissza a generációs oldalra, és ismételje meg 2. pont jelen kézikönyvben.
Ha nincs előre telepített titkosítási szolgáltatója, akkor a hozzáférés engedélyezése után a CryptoPRO letöltésére szolgáló linkek jelennek meg (5. ábra).
Fontos: Alkalmazás « crm - ügynök » észleli a számítógépen található titkosítási szolgáltatókat, és ha másikat telepített CryptoPRO CSP program (pl.VipNET CSP ), lépjen kapcsolatba a szakemberekkel technikai támogatás CA konzultációra.
Kattintson a linkre "CryptoPRO 4.0" a generációs oldalon vagy az alábbi hasonló linken letöltheti a CryptoPRO telepítőfájlt a számítógépére.
CryptoPro CSP 4.0 - verzió Windows 7/8/10 operációs rendszerhez
A letöltés befejezése után nyissa megpostai irányítószám-archiválni egy megfelelő archiváló program segítségével (pl.Győzelem - RAR ). Belül lesz a CryptoPRO telepítőfájlja. Futtassa és telepítse alapértelmezett paraméterekkel. A telepítési folyamat során a következő ablak jelenhet meg:
5. ábra - A CryptoPRO telepítése
Kattintson a gombra az ablak kihagyásához "További"... A CryptoPRO telepítése befejeződött.
A token illesztőprogramjának telepítése
Az aláírások tárolhatók a számítógép nyilvántartásában, közönséges flash meghajtókon és speciálisusb-tokens. A tokenek, pin -kódok és a szoftverre mutató hivatkozások listáját az alábbi táblázat tartalmazza (1. táblázat).
1. táblázat - Illesztőprogramok a biztonságos adathordozóhoz
|
USB adathordozó típusa |
Megjelenés USB kulcs |
Link az illesztőprogramok letöltéséhez |
PIN-kód |
|
ruToken |
 |
