Ukjent nøkkelbruk 1.2 643.3 7.8 1. Dårlig signatur Signatur mislyktes verifisering Manglende objektidentifikator OID

I samsvar med Spesifikasjoner implementering av AEI PRIME CJSC av handlinger for å avsløre informasjon om verdipapirer og andre finansielle instrumenter godkjent av Bank of Russia (), elektroniske dokumenter som inneholder offentlig informasjon må signeres av gjenstanden for informasjonsavsløring med en forbedret kvalifisert elektronisk signatur (se punkt 1.7 i de tekniske betingelsene). Dette kravet gjelder fra 1. februar 2017.

For øyeblikket har en testperiode for påføring av en elektronisk signatur startet på PRIME-avsløringsserveren, som vil vare til og med 31. januar 2017.

For å teste funksjonaliteten kan PRIME-kunder bruke ethvert ES-nøkkelsertifikat tidligere mottatt for denne juridiske enheten.

Fra 1. februar 2017, på forespørsel fra de tekniske betingelsene (se punkt 1.7. og 9.6.), må det kvalifiserte sertifikatet for brukerens elektroniske signaturverifiseringsnøkkel være i samsvar med kravene til formen til et kvalifisert sertifikat fastsatt ved Order of the Russlands føderale sikkerhetstjeneste datert 27. desember 2011 nr. 795 "Om godkjenningskrav for formen til et kvalifisert sertifikat for bekreftelsesnøkkelen for elektronisk signatur. Brukersertifikatutvidelse "Enhanced key" (objektidentifikator 2.5.29.37) må inneholde en objektidentifikator for informasjonsavsløring PRIME - OID 1.2.643.6.42.5.5.5

Pålogging til den personlige kontoen til brukeren av informasjonsavsløring "PRIME" vil bli utført ved å bruke LOGIN og PASSORD tidligere mottatt av klienten.

Klientens handlinger for å publisere meldinger i informasjonsstrømmen, legge ut dokumenter på en side på Internett, gjøre endringer på utsteders registreringskort i informasjonssystemet må bekreftes med elektronisk signatur.

For å bruke ES på PRIME-serveren for informasjonsavsløring, må klienten først installere plug-in (installasjonen er gratis for brukere og tar ikke mye tid). Se plugin-installasjonsinstruksjonene nedenfor.

I den personlige kontoen til informasjonsavsløringsbrukeren, etter at klienten har installert plugin-modulen, når du fyller ut skjemaer for å publisere en melding i informasjonsavsløringsfeeden eller plassere et dokument på Internett, samt når du endrer registreringsdataene kortet, vil flere felt "Dokument elektronisk signatur" vises, hvor du må velge den som vises i det tilsvarende tjenestefeltet signeringsnøkkelsertifikat og klikke på "Sign"-knappen. På denne måten vil klienten bekrefte sine handlinger for å utlevere informasjon eller gjøre endringer på registreringskortet sitt.

• Etter å ha signert meldingen med elektronisk signatur, må klienten klikke på "Publiser"-knappen
• Etter å ha signert dokumentet med elektronisk signatur, må klienten klikke på knappen "Legg til dokument".
• Etter å ha signert endringene i registreringskortet med elektronisk signatur, må klienten klikke på knappen "Send identifikasjonsskjema".

Vær oppmerksom på at alle meldinger sendt av klienter via deres personlige konto gjennom "Testpålogging (arbeid med ES)"-autorisasjonen vil bli publisert i informasjonsstrømmen i arbeidsmodus. Alle dokumenter plassert av klienter gjennom deres personlige konto gjennom "Testoppføring (arbeid med ES)"-autorisasjonen vil automatisk bli lagt ut på sidene til utstedere i arbeidsmodus.

Ellers endres ikke utsteders prosedyre i den personlige kontoen på PRIME-informasjonsserveren.

Når du går inn på din personlige konto for å be om en QEP, vises en melding « Datamaskinen er ikke konfigurert . For å fortsette, gå til siden for datamaskininnstillinger og følg de foreslåtte trinnene » . Etter å ha gått til innstillingssiden og installert alle nødvendige komponenter i kontoen din, vises en melding igjen om at datamaskinen ikke er konfigurert.

For å fikse feilen må du:

1. Legg til adressen til din personlige konto https://i.kontur-ca.ru til de pålitelige nodene. For dette:

• Velg menyen "Start" > "Kontrollpanel" > "Alternativer for Internett";
• Gå til "Sikkerhet"-fanen, velg elementet "Trusted sites" (eller "Trusted sites") og klikk på "Noder"-knappen;
• Spesifiser følgende nodeadresse https://i.kontur-ca.ru i feltet Legg til sone og klikk på Legg til-knappen.

Hvis denne adressen allerede er på listen over pålitelige nettsteder, gå til neste trinn.

2. Sjekk at adressen til den personlige kontoen https://i.kontur-ca.ru er definert som pålitelig:

• Hvis Internet Explorer versjon 8 brukes, bør du, når du er på autorisasjonssiden, sjekke om avmerkingsboksen Trusted Sites er nederst på siden. Hvis det ikke er noen avkrysningsboks, men det er en inskripsjon « Internett", så har ikke adressen https://i.kontur-ca.ru blitt lagt til pålitelige nettsteder.

• Hvis Internet Explorer versjon 9 og nyere brukes, bør du, når du er på autorisasjonssiden, høyreklikke hvor som helst på siden, velge "Egenskaper". I vinduet som åpnes, skal "Sone"-linjen inneholde påskriften "Trusted Sites". Ellers har ikke adressen https://i.kontur-ca.ru blitt lagt til pålitelige nettsteder.

Hvis den personlige kontoadressen ikke er definert som pålitelig, bør du kontakte systemadministratoren med en forespørsel om å legge til adressen https://i.kontur-ca.ru til de pålitelige nettstedene.

3. Sjekk om du kan logge inn på din personlige konto. Hvis feilen gjentar seg, bør du kjøre RegOids-verktøyet fra lenken. Dette verktøyet vil automatisk konfigurere OID-innstillingene i datamaskinens register. Du kan også importere en av registergrenene manuelt, avhengig av bitheten til det installerte operativsystemet:

4. Sjekk at datamaskinen bruker administratorrettigheter (for å sjekke, gå til Start - Kontrollpanel - Brukerkontoer og familiesikkerhet - Brukerkontoer). Hvis rettighetene ikke er nok, må du gi brukeren fulle rettigheter, for dette, kontakt din administrator.

5. Etter å ha fullført trinn 3, er det nødvendig å starte datamaskinen på nytt og sjekke inngangen til den personlige kontoen.

Hvis ingen av instruksjonene hjalp, bør du kontakte teknisk støtte på [e-postbeskyttet] Brevet må angi:

1. Diagnosenummer.

For å gjøre dette må du gå til diagnoseportalen påhttps://help.kontur.ru , trykk på knappen " Start diagnostikk » . Når bekreftelsesprosessen er fullført, vil diagnosenummeret vises på skjermen. Angi det tildelte referansenummeret i brevet.

2. Skjermbilde av vinduet med feilen (ved bruk av Internet Explorer versjon 9 og høyere må du også legge ved et skjermbilde av vinduet "Egenskaper" - se punkt 2).

3. Eksporter og legg ved følgende registergrener:

32-bit: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-bit: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

Tusen takk, Mikhail, alt ble gjort raskt, og viktigst av alt, det var klart for meg ... Siden vi har funnet et felles språk. Jeg vil gjerne holde kontakten med deg i fremtiden. Jeg håper på et fruktbart samarbeid.

Olesya Mikhailovna - daglig leder LLC "VKS"

På vegne av State Unitary Enterprise "Sevastopol Aviation Enterprise" uttrykker vi vår takknemlighet for profesjonaliteten og effektiviteten til din bedrift! Vi ønsker din bedrift videre velstand!

Guskova Liliya Ivanovna - manager. SUE "SAP"

Takk Michael for hjelpen med designet. Meget kvalifisert medarbeider +5!

Nadiya Shamilyevna - Entreprenør IP Anoshkina

På vegne av selskapet "AKB-Avto" og på mine egne vegne uttrykker jeg min takknemlighet til deg og alle ansatte i din bedrift for produktivt arbeid av høy kvalitet, sensitiv holdning til kundenes krav og effektivitet i utførelse av bestilt arbeid .

Nasibullina Alfira - Senior Manager"AKB-Auto"

Jeg vil takke konsulenten Mikhail for det utmerkede arbeidet, rettidige og komplette konsultasjoner. Veldig oppmerksom på klientens problemer og spørsmål, rask løsning av det mest tilsynelatende for meg vanskelige situasjoner. Det er en glede å jobbe med Michael!!! Jeg vil nå anbefale din bedrift til mine kunder og venner. Ja, og teknisk støttekonsulenter er også veldig høflige, oppmerksomme, de hjalp til med å takle den vanskelige installasjonen av nøkkelen. Takk!!!

Olga Sevostyanova.

Anskaffelse av nøkkelen viste seg å være veldig enkelt og til og med hyggelig. Tusen takk for hjelpen til manager Michael. Forklarer ting som er komplekse og massive å forstå, kortfattet, men veldig tydelig. I tillegg ringte jeg vakttelefonen gratis linje og på nettet, sammen med Mikhail la en forespørsel. Jeg fikk nøkkelen innen 2 virkedager. Generelt anbefaler jeg det hvis du sparer tid, men samtidig ønsker å ha en forståelse av hva du kjøper og hva du betaler for. Takk skal du ha.

Levitsky Alexander Konstantinovich Samara

Personlig takknemlighet til konsulenten Mikhail Vladimirovich for den raske konsultasjonen og arbeidet med akselerert mottak av ES-sertifikatet. Under den foreløpige konsultasjonen velges det optimale settet med individuelle tjenester. Sluttresultatet er umiddelbart.

Stoyanova N.L. - Regnskapssjef LLC "SITECRIME"

Takk for raskt arbeid og eksperthjelp! Jeg ble veldig fornøyd med rådet!

Dmitry Fomin

LLC "Expert System" takker konsulenten Mikhail for det raske arbeidet! Vi ønsker din bedrift vekst og velstand!

Sukhanova M.S. - TakstmannLLC "Expert System", Volgograd

Takk til konsulenten, som introduserte seg som Mikhail, for effektiviteten i arbeidet med kunder.

Ponomarev Stepan Gennadievich

Tusen takk til konsulenten Michael, for hjelpen i å få en EDS. For raskt arbeid og råd om problemer som oppstår under registreringsprosessen.

Leonid Nekrasov

Selskapet, representert ved konsulent Mikhail, gjør det umulige! Få fart på akkrediteringen på mindre enn 1 time! Betaling ved levering av tjenesten. Jeg trodde dette ikke skjedde. Med fullt ansvar kan jeg råde deg til å kontakte Senteret for utstedelse av elektroniske signaturer.

Vadim Malykh
02.10.2013

For en tid tilbake var det i Forum Rus-gruppen på Facebook en diskusjon om bruk av myndigheter i informasjonssystemer (diskusjonen var utenfor tema, du kan se den i kommentarfeltet under). Essensen av tvisten er at på grunn av OID (objektidentifikator - objektidentifikator) av informasjonssystemer som må registreres i kvalifiserte elektroniske signatursertifikater (ES) til tjenestemenn, må disse samme ES endres enda oftere enn én gang pr. år (som er diktert av sikkerhetskrav) , og dette fører igjen til ytterligere kompleksitet og kostnader, siden de fleste myndigheter jobber med kommersielle CA-er uten å ha sine egne. Problemet forverres av mangelen på en felles forståelse av nøyaktig hva disse OID gir og hvor nødvendige og/eller obligatoriske de er.

I løpet av argumentasjonen advarte min motstander meg om at jeg på grunn av uvitenhet om noen av de grunnleggende elementene i fagområdet kunne komme inn i visse juridiske problemer i fremtiden. Jeg kunne ikke ignorere en slik advarsel fra en kollega, så jeg bestemte meg for å studere dette emnet nøye igjen og sørge for at jeg forstår alt og gjør det riktig. Nedenfor er noen av resultatene fra denne ekskursjonen til fagområdet. Kanskje noen vil være interessert.

Fra og med grunnleggende konsepter, er elektronisk signering basert på asymmetriske krypteringsalgoritmer. Hovedtrekket til disse algoritmene er at to forskjellige nøkler brukes til å kryptere og dekryptere en melding. Symmetriske algoritmer er mer kjent for allmennheten, når vi krypterer og dekrypterer en melding med samme nøkkel (eller passord), for eksempel arkiverer vi en fil med et passord eller beskytter et MS Word-dokument.

Mange ting er basert på asymmetriske krypteringsalgoritmer, selv om det faktum at forskjellige nøkler brukes til kryptering og dekryptering ennå ikke ville tillate oss å finne noen nyttig applikasjon for disse algoritmene. For å gjøre dette må de ha noen tilleggsegenskaper. For det første må nøklene ikke kunne beregnes, det vil si at hvis du kjenner én nøkkel, kan du ikke beregne den andre. Det er også svært viktig at ulike krypteringsnøkler korresponderer med ulike dekrypteringsnøkler og omvendt – kun én krypteringsnøkkel tilsvarer én dekrypteringsnøkkel.

Hva er den faktiske signaturen? Tross alt må vi signere dokumentet, ikke kryptere det. Først må du forstå hva en signatur er og hvorfor den er nødvendig. Når du setter din håndskrevne signatur på et papirdokument, forsikrer du dermed at det var du (og ikke noen andre) som så (og godtar) dette bestemte dokumentet (og ikke et annet). Den viktigste egenskapen til en signatur er ikke-avvisning. Dette betyr at når du signerer dokumentet, kan du ikke gi avkall på det senere. Når det gjelder en papirsignatur, vil håndskriftekspertise dømme deg, når det gjelder en elektronisk, matematiske metoder basert på asymmetriske krypteringsalgoritmer.

Hvordan det hele fungerer, i et nøtteskall. Vi tar en asymmetrisk krypteringsalgoritme, genererer et nøkkelpar (for kryptering og dekryptering). Vi gir krypteringsnøkkelen til den som skal signere dokumentene. Han må alltid ha det med seg og ikke gi det til noen. Derfor kalles den "privat" nøkkel. Vi gir en annen nøkkel (dekryptering) til alle, så den er "åpen". Når du signerer et dokument, må en person kryptere det med sin private nøkkel. Det er ikke selve dokumentet som faktisk er kryptert, siden det kan være ganske stort, og vi trenger faktisk ikke kryptere det. Derfor oppnås en hash for dokumentet - dette er en viss numerisk sekvens med en høy grad av sannsynlighet forskjellig for forskjellige dokumenter, som et "fingeravtrykk" av dokumentet. Den er kryptert med underskriverens private nøkkel. Denne krypterte hashen er den elektroniske signaturen til dokumentet. Nå, med et dokument, en signatur og en offentlig nøkkel, kan hvem som helst enkelt bekrefte at dette bestemte dokumentet ble signert med denne spesielle private nøkkelen. For å gjøre dette får vi igjen hashen til dokumentet, dekrypterer signaturen med den offentlige nøkkelen og sammenligner. Bør få to identiske numeriske sekvenser.

Alt dette er flott, men så langt har vi fått ikke-avvisning av signaturen for den private nøkkelen, det vil si at vi har bevist at dokumentet er signert med en spesifikk nøkkel. Vi må bevise at den ble signert av en bestemt person. For å gjøre dette finnes det sertifiseringssentre og digitale sertifikater. Det viktigste en sertifiseringsinstans gjør er at den sertifiserer at den private nøkkelen tilhører en bestemt person. For å garantere dette er det sertifiseringssenteret som genererer nøkkelpar og utsteder dem personlig til eierne (det finnes alternativer via proxy, eksternt, men dette er detaljer). Sammen med nøklene genereres et digitalt sertifikat - dette er et elektronisk dokument (noen ganger papirrepresentasjonen), som inneholder informasjon om eieren av nøkkelen, selve nøkkelen, sertifiseringsmyndigheten og annen informasjon. Eieren mottar som regel all denne godheten på et sikkert medium (smartkort, ru-token og så videre), som inneholder en privat nøkkel og et sertifikat med en innebygd offentlig nøkkel. Selve transportøren skal alltid oppbevares hos deg, og det offentlige nøkkelsertifikatet som er kopiert fra denne kan gis til alle slik at de kan verifisere din elektroniske signatur.

Så signering gjøres med en privat nøkkel, og signaturverifisering med en offentlig nøkkel. Derfor er uttrykket "dokumentet er signert av settet med OID" (høres i tvisten ovenfor) meningsløs. Bare to nøkler er involvert i signerings- og verifiseringsprosedyren, i 63-FZ er de navngitt tilsvarende - signaturnøkkelen og signaturverifiseringsnøkkelen.

Og hva er disse beryktede OID-ene? Det digitale sertifikatformatet X.509 gjør at utvidelser kan lagres i det. Dette er noen valgfrie attributter som kan brukes til å lagre tilleggsinformasjon. Hvert slikt attributt er et objekt som er spesifisert av en identifikator fra den hierarkiske katalogen. Derfor OID - Object Identifier. Det gir ingen mening å fordype seg i selve OID-ene. Faktisk er dette noe tilleggsinformasjon som kan være tilstede i sertifikatet.

Disse tilleggsattributtene kan brukes til forskjellige formål. De kan enten gi tilleggsinformasjon om eieren, nøklene, CA, eller ha noe tilleggsinformasjon for applikasjoner og tjenester som bruker dette sertifikatet. Den vanligste bruken er for rollebasert tilgangskontroll. For eksempel kan det skrives i sertifikatet at eieren av nøkkelen er leder for organisasjonen, og dette vil gi ham muligheten til umiddelbart å få tilgang til alle IS-er. ønskede funksjoner og informasjon, uten å måtte kontakte administratorene for hver IS og endre tilgangsinnstillinger. Alt dette, selvfølgelig, forutsatt at alle disse IS-ene bruker brukersertifikatet for autorisasjon og analyserer det samme attributtet på samme måte (av denne grunn velges attributtene fra katalogen og ikke settes vilkårlig).

På grunn av ulike søknader mottar vi to sertifikater som er helt forskjellige av natur. En - bekrefter at jeg er jeg, og dette er alltid tilfelle. For godt kan det utstedes en eller flere ganger i løpet av livet, som et pass. Men på grunn av ufullkommenheten til eksisterende kryptografiske algoritmer, av sikkerhetshensyn, må disse sertifikatene nå utstedes på nytt hvert år. Den andre typen sertifikat administrerer tilleggsinformasjon og kan endres mye oftere enn en gang i året. Det kan sammenlignes med telefonkort. posisjon endret, E-post, telefon - du må lage nye visittkort.

I verden kalles disse to typene sertifikater henholdsvis Public Key Certificate (PKC) og Attribut Certificate (eller Authorization Certificate - AC). Et sertifikat av den andre typen kan utstedes mye oftere enn det første, av en annen organisasjon, og bør være mer tilgjengelig og lettere å få tak i enn et personlig "offentlig nøkkel"-sertifikat. Det er i alle fall dette som RFC 3281 anbefaler, dedikert til denne typen sertifikater. Sertifikatet av den andre typen skal kun inneholde en lenke til det offentlige nøkkelsertifikatet slik at systemet som bruker det til å autorisere brukeren først kan identifisere personen som bruker PKC.

La oss nå gå nærmere vår virkelighet. På lovnivå er spørsmål knyttet til bruk av elektroniske signaturer i Den russiske føderasjonen, er regulert av to hoveddokumenter - loven til den russiske føderasjonen av 04/06/2011 nr. 63-FZ "Om elektronisk signatur" og ordren fra den føderale sikkerhetstjenesten i den russiske føderasjonen av 27.12.2011 nr. 795 "Ved godkjenning av kravene til formen til et kvalifisert sertifikat for bekreftelsesnøkkelen for elektronisk signatur". Sammensetningen av et kvalifisert sertifikat er beskrevet i 795. rekkefølge (Del II "Krav til feltsettet til et kvalifisert sertifikat") og den inneholder ikke krav til attributter som kontrollerer autorisasjon i noen informasjonssystemer. Som ekstra obligatoriske attributter spesifiseres kun informasjon som lar deg identifisere en fysisk eller enhet i den russiske føderasjonen (TIN, SNILS, etc.). Selv om verken loven eller ordren fra FSB forbyr inkludering av annen informasjon i et kvalifisert sertifikat.

Som du kan se, dikterer ingen lovbestemte normer obligatorisk tilstedeværelse i et kvalifisert sertifikat for attributter knyttet til autorisasjon i noen informasjonssystemer. Hvor kommer disse kravene fra? Og de kommer fra utviklerne (eller "eierne") av spesifikke systemer. Ta for eksempel " Retningslinjer om bruk av elektronisk signatur i tverretat elektronisk interaksjon(versjon 4.3)», lagt ut på SMEV-teknologiportalen. Faktisk, i avsnitt 6 i dette dokumentet leser vi: "Når du forbereder informasjon for dannelsen av et EP-SP-sertifikat, er det nødvendig å bestemme behovet for å be om informasjon fra Rosreestr (utdrag fra USRR). Hvis en slik forespørsel er nødvendig, må OID angis i feltet "Forbedret nøkkel" (OID=2.5.29.37) i ES-SP-sertifikatet i henhold til kravene i Rosreestr. Det vil si at Rosreestr informasjonssystemet bruker dette attributtet for å bestemme informasjonen som kan utstedes til sertifikateieren. Det samme dokumentet inneholder imidlertid en viktig merknad, nemlig dette kravet er gyldig inntil ESIA (enkelt autorisasjonstjeneste i statlige systemer) er fullstendig lansert og Rosreestr-systemet er koblet til det. Dette er en viktig merknad, husk det.

Jeg vil ikke forholde meg til andre IP-er som brukes i staten. organer. Jeg mistenker at situasjonen er lik. Den offentlige anskaffelsesportalen, elektroniske handelsplattformer, ulike regnskaps- og finansapplikasjoner kan også kreve tilstedeværelse av enkelte ekstra OIDer i brukersertifikatet. Samtidig er påstanden om at ved å skrive OID til informasjonssystemet i sertifikatet, på en eller annen måte delegerer ansvaret til sertifiseringssenteret, for å si det mildt, feil. CA legger inn disse dataene i sertifikatet i henhold til søknaden min. Hvis min stilling er endret, og jeg har glemt å søke om tilbakekall av det gamle og utstedelse av nytt sertifikat, kan ikke CA holdes ansvarlig for min glemsel. I tillegg tildeler loven 63-FZ direkte ansvaret for feil bruk av sertifikatet til eieren. I paragraf 6 i artikkel 17 leser vi:
Innehaveren av et kvalifisert sertifikat må:
1) ikke bruk den elektroniske signaturnøkkelen og ta umiddelbart kontakt med det akkrediterte sertifiseringssenteret som utstedte det kvalifiserte sertifikatet for å avslutte dette sertifikatet hvis det er grunn til å tro at konfidensialiteten til den elektroniske signaturnøkkelen er krenket;
2) bruke en kvalifisert elektronisk signatur i samsvar med begrensningene i det kvalifiserte sertifikatet (hvis slike begrensninger er etablert).

Behovet for å lagre informasjon om rollene og tilgangene til brukeren i spesifikke informasjonssystemer i sertifikatet fører til et problem som forårsaket en tvist på Facebook, nemlig at sertifikatet må utstedes på nytt mye oftere enn sikkerhetskravene for en personlig elektronisk signatur diktere. Stillingen er endret - vi utsteder sertifikatet på nytt. En ny IS har dukket opp - vi utsteder sertifikatet på nytt. Det var behov for å be om informasjon fra IS til en ny organisasjon (Rosreestr) - vi utsteder sertifikatet på nytt.

Det er et 100 % treff i konseptet kalt i verden Attribut Certificate (eller Authorization Certificate), som ble nevnt ovenfor og der det anbefales å utstede disse sertifikatene av en annen sertifiseringsmyndighet (Attribute Autority, i motsetning til Certificate Authority - en vanlig CA som utsteder kvalifiserte ES-sertifikater) og på en forenklet måte. Dette sertifikatet i seg selv skal ikke inneholde en elektronisk signaturnøkkel og informasjon om eieren. I stedet inneholder den en lenke til eierens offentlige nøkkelsertifikat, hvorfra du kan hente resten av nødvendig informasjon om personen.

Det skal bemerkes at denne ordningen også har en svært begrenset anvendelse og løser ikke alle problemer. Hva om det neste informasjonssystemet bestemmer seg for å bruke det samme sertifikatfeltet "Forbedret nøkkel" (OID=2.5.29.37), som allerede er okkupert av Rosreestr-verdien, for sine behov? Skriv inn to forskjellige betydninger i ett felt vil ikke fungere. Derfor må vi gi ut en annen AC! Et annet problem er knyttet til den korte levetiden til PKC (ett år). Hvis vi har flere AC-er (som inneholder en lenke til et personlig sertifikat), må alle utstedes på nytt etter at PKC-en utløper. For effektiv bruk av AC, noen enkelt senter autorisasjon av brukere i alle informasjonssystemer, og alle applikasjoner må konsekvent og enhetlig bruke attributtene til sertifikater.

Et slikt enkelt autorisasjonssenter for staten. myndigheter eksisterer allerede - dette er ESIA. La oss huske notatet om Rosreestrs OIDs. I fremtiden vil de bli erstattet av informasjon fra ESIA. Andre bør gjøre det samme Informasjonssystemer der statsansatte jobber. ansatte. I stedet for å bruke AC for autorisasjon, er det nødvendig å integrere med ESIA og motta nødvendig informasjon derfra. ESIA skal kunne binde et kvalifisert ES-sertifikat til regnskap Dermed vil informasjonssystemer kunne autentisere brukeren ved hjelp av en personlig nøkkel, og autorisere vedkommende (gi tilgang til applikasjonen) gjennom ESIA. Et slikt system ser ut til å være mer universelt og mer pålitelig enn bruk av sertifikatfelt, og i fremtiden vil det tillate automatisering av tilgangskontroll. Hvis opprettet ett system personaljournaler ansatte, vil ESIA kunne ta informasjon om kreftene til en person direkte derfra. En person ble overført til en annen stilling - han mistet automatisk tilgang til noen systemer og fikk tilgang til andre. Samtidig fortsetter han å bruke ES-nøkkelen sin til å signere dokumenter, det er ikke nødvendig å utstede noe på nytt.