Використання електронного цифрового підпису у електронному документообігу

5.Технічну підтримку при проведенні розбору конфліктних ситуацій. ЗЦ забезпечує ведення завіреної "історії життя" сертифіката. Будь-яка подія, будь те централізоване ухвалення рішення про випуск сертифіката або зміна статусу уже випущеного сертифіката, оформляється у виді спеціального запису (у форматі CMC (RFC 2797)) у "історії" сертифіката і має ЕЦП ініціатора ухвалення рішення. Взаємозалежні CMC запису визначають усю "історію життя" сертифіката. Даний підхід дозволяє, аргументовано вирішувати задачі арбітражу і використовувати ЗЦ у системах, де ухвалення рішення вимагає проведення спеціальних організаційно технічних заходів групи офіцерів безпеки. 

6.Додатково ЗЦ забезпечує: 

•Підтвердження дійсності електронного цифрового підпису на електронному документі у відношенні виданих ЗЦ сертифікатів. 

•Формування "штампа часу" на електронному документі. 

•Надання публічного сервісу - "Служби часу ЗЦ". 

 

 

ЗЦ є програмно - апаратним комплексом, що виконує функції формування сертифіката ключа підпису. Ключі можуть створюватися як зовні на відповідному програмному забезпеченні користувача, так і засобами ЗЦ. Носієм інформації про випущений сертифікат виступає відчужуваний носій (Floppy Disk, або інший носій, використання якого визначається специфікою автоматизованої системи). 

ЗЦ спроектований і повинний експлуатуватися, як довірена, замкнута, автоматизована система, що модифікується не. Під замкнутістю розуміється неможливість впливу на склад і компоненти системи іншим способом, крім як визначеним регламентом образом. Під немодифікованістю розуміється відсутність у системі засобів розробки прямо або побічно впливають на функціональну однозначність виконуваних процедур. 

ЗЦ побудований по модульному принципі і містить у своєму складі наступні компоненти (підсистеми): 

 

Рис. 1.1 Структурна схема ЗЦ

 

Підсистеми ЗЦ виконані з захистом від НСД. Контроль за незмінністю програмного середовища здійснює спеціалізований сервіс, що конфігурується при інсталяції ЗЦ і веде робочі журнали контролю цілісності ПО, доступ до яких має обслуговуючий персонал ЗЦ. 

 

 

Однією з технологій, що дозволяє вирішити більшість проблем зв’язаних з безпекою в комп’ютерних мережах, є інфраструктура відкритих ключів. 

За допомогою інфраструктури відкритих ключів вирішуються наступні задачі: 

Забезпечення приховання переданої інформації. 

Забезпечення цілісності цієї інформації, тобто захист від модифікації. Існують технічні рішення, що дозволяють розміщати на серверах ресурсу завірену інформацію, має електронний цифровий підпис, перевірка якого (у тому числі й у ON-LINE) дозволяє підтвердити цілісність і авторство розміщеної інформації. 

Забезпечення автентифікації ресурсу, тобто доказ того, що ресурс є саме тим, за кого він себе видає. 

Забезпечення автентифікації користувачів при доступі до ресурсу. 

Узявши за основу ці корисні властивості, реалізовані в системі, можна побудувати систему захищеного електронного документообігу, у якій поняття документообігу багато ширше чим простий рух наказів або листів усередині організації. 

 

Рис. 1.2 Система захищеного електронного документообігу

 

Запропонована схема дозволяє вирішити IT задачі організацій фактично будь-якого профілю, а використання типових стандартних рішень роблять розробки прозорими для розуміння й аналізу.

 

 

Такий вид запиту призначений для створення сертифіката з локальної генерації ключів і формування запиту у форматі PKCS#10. Такий запит припускає генерацію ключової пари, тому при реальній експлуатації набирають сили обмеження Ліцензійної угоди. 

Далі користувачем заповнюється запропонований ланцюжок форм, деякі полючи в аркушах ланцюжка є недоступними для даного виду запиту. 

Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем, минаючи службу Адміністраторів взаємодії з користувачами. 

1.необхідно вказати яким сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);

2.необхідно вказати для яких задач буде використані створюваний сертифікат і визначити (додаткова функція "Редагувати") області і порядок застосування сертифіката, для яких його використання буде вважатися дійсним; 

3.визначити для якого криптографічного алгоритму буде локально створена ключова пара з наступним розміщенням цієї інформації в запиті. Як уже раніше відзначалося, ПО має модульну структуру підтримуваних алгоритмів і користувач у праві вибрати кожної на свій розсуд; 

4.вказується інформація (загального і додаткова) про власника цифрового сертифіката;

5.на цьому етапі відбувається генерація ключової інформації - операція ресурсномісткої і тривала за часом із усієї введеної інформації підготовляється запит і користувачеві дається можливість перевірити введені дані і при необхідності, повернувши по кроках назад, змінити помилково введену інформацію. 

Запис про запит виду PKCS#10 не повинна віддалятися з бази "Запити в ЗЦ" доки, не буде отримана відповідь зі служб ЗЦ і на клієнтському робочому місці не буде згрупована (процедура автоматична або в ON-LINE). Персональний сертифікат (секретний ключ, що не залишав робочого місця і відповідний йому, завірений сертифікат з відкритим ключем). 

Теоретично можлива така ситуація, при якій запит на створення сертифіката саме для даного відкритого ключа може бути відхилений. Таке поводження ЗЦ порозумівається тим, що ЗЦ при створенні сертифіката забезпечує "унікальність відкритих ключів". Самі ключі були створені локально (ЗЦ не керує даною