У традиційному, звичному для переважної більшості користувачів розумінні електронного підпису(ЕП) ключ цього самого підпису зберігається у її власника. Найчастіше для цього використовується захищений ключовий носій у форматі USB-токена або смарт-карти, який користувач може носити з собою. Цей ключовий носій ретельно оберігається власником від сторонніх осіб, оскільки попадання ключа до чужих рук означає його компрометацію. Для використання ключа на пристрої власника встановлюється спеціалізоване програмне забезпечення (СКЗІ), призначене для обчислення ЕП.
З іншого боку, у світі ІТ все ширше застосовується концепція «хмарних обчислень», яка багато в чому має масу переваг у порівнянні з використанням традиційних додатків, встановлених на комп'ютері користувача. Внаслідок цього виникає цілком закономірне бажання скористатися цими перевагами хмарних технологій для створення «ЕП у хмарі».
Але перш ніж вирішувати це завдання необхідно визначити, що ж ми розумітимемо під «електронним підписом у хмарі». В даний час у різних джерелах можна зустріти різні ж трактування цього поняття, що часто годяться хіба що тільки для пояснення на пальцях людині «з вулиці», яка зайшла до Центру, щоб «купити електронний підпис».
Що таке кваліфікований електронний підпис у хмарі
Для цілей цієї статті, а також інших науково-популярних та практичних дискурсів про хмарний електронний підпис пропонується використовувати таке визначення.
Електронний підпис у хмарі (хмарний електронний підпис) – це обчислювальна система, що надає через мережу доступ до можливостей створення, перевірки ЕП та інтеграції цих функцій у бізнес-процеси інших систем.
Відповідно до даного визначення, для хмарного електронного підпису може використовуватися, зокрема, і локальний засіб ЕП. Наприклад, використовуючи , користувач через веб-браузер може підписувати електронний документ за допомогою засобу ЕП, встановленого на його кінцевому пристрої ( персональний комп'ютерабо планшет). У подібній системі ключ підпису залишається у власника і питання безпеки вирішуються за допомогою стандартного набору коштів, відомого у світі традиційної ЕП. Якщо хочете, можна назвати це хмарний ЕП з локальним засобом ЕП.
Інший варіант хмарної ЕП виходить за використання засобу ЕП, розміщеного у хмарі. Для зручності подальшого викладу н азовемо таку схемуповністю хмарний ЕП, щоб відрізняти її від попередньої. Ця схема регулярно викликає палкі дискусії серед фахівців, оскільки передбачає передачу самого ключа підпису «в хмару».Ця стаття покликана прояснити низку питань, пов'язаних з безпекою повністю хмарної ЕП.
Почнемо з головного
Основним головним болем при перекладі будь-якої ІТ-системи «в хмару» стає біль «безпеків» (і юристів, які їм допомагають), пов'язана з передачею «туди» інформації для обробки або зберігання. Якщо раніше ця інформація не залишала деякого захищеного периметра, можна було порівняно легко забезпечити її конфіденційність, то в хмарі поняття периметра відсутнє. У цьому відповідальність забезпечення конфіденційності інформації у сенсі « розмивається» між її власником і постачальником хмарних послуг.
Те саме відбувається і з ключем ЕП, що передається в хмару. Більше того, ключ ЕП – це не просто конфіденційна інформація. Ключ має бути доступний лише одній особі – його власнику. Таким чином, довіра до хмарного підпису визначається не тільки особистою відповідальністю користувача, але й безпекою зберігання та використання ключа на сервері та надійністю механізмів автентифікації.
В даний час проводяться сертифікаційні випробування нашого рішення. Це сервер хмарної ЕП, що зберігає ключі та сертифікати користувачів та надає автентифікований доступ до них для формування електронного підпису. Обидва згадані вище аспекти безпеки хмарної ЕП, зокрема, є предметом досліджень, що проводяться в ході випробувань КриптоПро DSS. У той же час, варто зазначити, що значна частина цих питань вже розглянута в рамках тематичних досліджень , на якому ґрунтується КриптоПро DSS.
У нашій країні поки що слабко опрацьовано організаційно-правові аспекти застосування хмарної ЕП, тому в цій статті ми розглянемо КриптоПро DSS з точки зору вимог до сервера підпису, розроблених Європейським Комітетом зі Стандартизації (CEN).Європейський шлях
У жовтні 2013 року Європейський Комітет зі Стандартизації (CEN) схвалив технічну специфікацію CEN/TS 419241 "Security Requirements for Trustworthy Systems Supporting Server Signing". У цьому документі наводяться вимоги та рекомендації до сервера електронного підпису, призначеного для створення, у тому числі, кваліфікованих підписів.
Хочеться відзначити, що вже зараз КриптоПро DSS у повному обсязі відповідає вимогам даної специфікації у найбільш сильному варіанті: вимогам рівня 2, що висуваються для формування кваліфікованого електронного підпису (у термінах європейського законодавства).
Однією з основних вимог рівня 2 є підтримка суворих варіантів аутентифікації. У цих випадках автентифікація користувача відбувається безпосередньо на сервері підпису - на противагу допустимої для рівня 1 автентифікації в додатку, який від свого імені звертається до сервера підпису. Усі методи аутентифікації, що підтримуються КриптоПро DSS, задовольняють даною вимогоюрівня 2.
Відповідно до цієї специфікації, ключі користувача підписи для формування кваліфікованої ЕП повинні зберігатися в пам'яті спеціалізованого захищеного пристрою (криптографічний токен, HSM). Що стосується КриптоПро DSS таким пристроєм є програмно-апаратний криптографічний модуль КриптоПро HSM - сертифікований ФСБ Росії за рівнем KB2 як ЭП.
Аутентифікація користувача на сервері електронного підпису до виконання вимог Рівня 2 мусить бути щонайменше двухфакторной. КриптоПро DSS підтримує широкий спектр методів автентифікації, що постійно поповнюється, у тому числі і двофакторних. Крім звичних криптографічних токенів як засіб аутентифікації може використовуватися і спеціалізований додаток на смартфоні, таке як , і генератори одноразових паролів (OTP-токени). У документі CEN ці методи також згадані.
Ще одним перспективним способом аутентифікації за рівнем 2 може стати використання криптографічної програми на SIM-карті в телефоні. На нашу думку, даний варіантвикористання SIM-карт з криптографією найбільш реальний, оскільки побудова функціонально закінченого СКЗІ (або кошти ЕП) за новими вимогами ФСБ на базі тільки SIM-карти навряд чи можливе.
Розглянута технічна специфікація також дозволяє використовувати сервер електронного підпису для формування підписів відразу для деякого набору документів. Ця можливістьможе бути корисною при підписанні великого масиву однорідних документів, що відрізняються лише даними в кількох полях. При цьому автентифікація користувача проводиться один раз для пакета документів. Підтримка такого варіанту використання також є у КриптоПро DSS.
У документі CEN міститься також ряд вимог до формування, обробки, використання та видалення користувача ключового матеріалу, а також до властивостей внутрішньої ключової системи сервера електронного підпису та до аудиту. Ці вимоги повністю і навіть «із запасом» покриваються вимогами, що пред'являються до засобів ЕП класу KB2, за яким сертифікований ПАКМ «КріптоПро HSM», що відповідає за ці питання.
Наше майбутнє
Рішення КриптоПро DSS підтримує широкий набір методів аутентифікації, серед яких для кожного завдання можна підібрати відповідний. Надійність найбезпечніших із них відповідає найсуворішим критеріям європейських вимог CEN/TS 419241 і, як ми розраховуємо, у недалекому майбутньому буде підтверджена сертифікатом відповідності ФСБ Росії.
Олексій Голдбергс,
заступник технічного директора
ТОВ "КРІПТО-ПРО"
Станіслав Смишляєв, к.ф.-м.н.,
начальник відділу захисту інформації
ТОВ "КРІПТО-ПРО"
Павло Смирнов, к.т.н.,
заступник начальника відділу розробок
ТОВ "КРІПТО-ПРО"
19 червня 2014 р. 09:21У Останнім часоммова часто заходить про електронний підпис (ЕП) у хмарі. Здебільшого цю тему обговорюють IT-фахівці. Однак із розвитком сервісів електронного документообігу(ЕДО), у тему хмарної ЕП стали втягуватися і фахівці-предметники – бухгалтери, секретарі, аудитори та інші.
Поясню, хмарний електронний підпис має на увазі, що ваш закритий ключЕП зберігається на сервері центру, що підтверджує, і підписання документів відбувається там же. Супроводжується це укладанням відповідних договорів та довіреностей, а фактичне підтвердження особи підписувача відбувається, як правило, з використанням авторизації через SMS.
Необхідність використання хмарної ЕП бухгалтером залежить від цього, в якому режимі він працює. Якщо ви часто знаходитесь поза офісом або, наприклад, працюєте в компанії, яка надає послуги з бухобліку (аутсорсинг бухгалтерії), то хмарна ЕП допоможе вам підписувати документи з будь-якого місця. При цьому не потрібно встановлювати жодного додаткового програмного забезпечення. Однак, незважаючи на простоту використання, не всі компанії готові використати цю можливість.
Щоб ви змогли самі вибрати, потрібний вам хмарний електронний підпис чи ні, розглянемо всі «за» та «проти» його використання. А також подумаємо, кому може справді стати в нагоді такий підпис. До речі, у цій статті ми говоритимемо лише про посилений кваліфікований електронний підпис (далі – УКЕП).
За
Хмарний електронний підпис дешевший за звичайний. В основному це пов'язано з тим, що вам не потрібно купувати засіб криптографічного захисту інформації (СКЗІ) та токен (флешка із сертифікатом). Як правило, з урахуванням їх придбання ціна на сертифікат злітає в 2-2.5 рази.
Зручність та простота використання. Для роботи з хмарним електронним підписом не потрібно встановлювати як сам сертифікат електронного підпису, так і спеціальні засобидо роботи з нею. Це означає, що ви не витрачатимете час на те, щоб розібратися, як все це працює.
Мобільність. на Наразіпоширених та безкоштовних рішеньдля використання не хмарного електронного підпису на мобільних пристрояхще немає. У цьому плані величезним плюсом хмарного електронного підпису є те, що працювати з ним можна з будь-якого комп'ютера, планшета, смартфона, де є інтернет.
Проти
Фізично документ підписуєте не ви. Потрібно розуміти, що в разі хмарного електронного підпису закрита частина ключа, яка є конфіденційною і повинна належати тільки вам, буде перебувати на сервері центру, що посвідчує. Звичайно, це буде оформлено документально, а сервери надійно захищені. Але тут все залежить від вимог компанії до безпеки та політики, пов'язаної з підписанням документів. Якщо вам важливо, щоб документи підписували самі власники закритих ключів, то електронний хмарний підпис вам не підійде. У цій ситуації лише вам вирішувати, наскільки ви довіряєте УЦ та серверам, на яких зберігаються закриті ключі.
Ви можете використовувати хмарну ЕП тільки у тих сервісах, з якими є інтеграція програмного забезпечення центру, що посвідчує. Це також пов'язано з тим, що у разі хмарної ЕП закритий ключ зберігається на сервері УЦ. Для того щоб потрібний вам сервіс міг використовувати такий закритий ключ ЕП для підписання, йому потрібно вміти надсилати запит на формування електронного підпису на сервер УЦ. Зрозуміло, що на даний момент сервісів багато, і вони не зможуть передбачити інтеграцію з програмним забезпеченням УЦ. Виходить, що хмарну ЕП вам доведеться використовувати лише з певними сервісами. Для роботи з іншими сервісами доведеться купувати інший сертифікат ЕП, і немає гарантій, що ці сервіси підтримуватимуть будь-який хмарний електронний підпис.
І що ж?
Хмарний електронний підпис – це зручний, мобільний та простий інструмент, але не найгнуткіший. А з точки зору надійності, можливо, зберігати закритий ключ на захищеному сервері буде краще ніж на токені в ящику столу.
Кому ж справді потрібний електронний підпис? Насамперед тим, хто часто працює не зі свого кабінету в офісі. Наприклад, юристи та аудитори, які часто виїжджають до клієнтів. Або керівники та директори, яким важливо підписувати документи у будь-якому місці. Для них хмарний електронний підпис стане незамінним помічникомв роботі.
Також дуже багато залежить від політики компанії. Якщо організація рухається у бік хмарних технологій, наприклад, у частині зберігання документів, використання сервісів для внутрішнього та зовнішнього документообігу, то й електронні підписи, найімовірніше, теж будуть хмарними. В іншому, бухгалтерам, діловодам та іншим співробітникам, які зазвичай при роботі не залишають свій кабінет, хмарний електронний підпис не потрібний. Їм можна придбати закритий ключ ЕП та сертифікат ЕП у звичайному режимі, на носії, який можна використовувати у більшості сервісів для обміну з контрагентами та державними установами.
(4,33 – оцінили 9 чол.)
Схожі записи
Ну, неправда ж. Наприклад, для iOS вже давно є Крипто-Про. Постачальники рішень для СЕД його використовують. Для того ж DIRECTUM є і ЕЦП на базі Кріпто-Про під Android.
Фізично будь-який електронний документ підписуєте не ви. Це робить програмне забезпечення.
Точніше, не на сервері УЦ, а у спеціалізованому апаратному сервері зберігання ключів сервісу електронного підпису, що взаємодіє з інформаційною системою (електронного документообігу).
У цьому випадку, дійсно, користувачеві нічого не потрібно встановлювати у себе, але вся безпека використання ключа залежить не від користувача, а від надійності автентифікації власника ключа електронним підписом та інформаційною системою.
Ну і ключем можна користуватися лише в тих інформаційних системах, які "підключені" до сервісу електронного підпису, що зберігає та застосовує ключ власника. Тобто. ключ буде "неповнофункціональним" (наприклад, їм не можна захистити криптографією підключення до серверів, операційну систему, електронну пошту та файли, забезпечити авторизацію на ДЕРЖСЛУГІТОЧКАРУ і ще багато де), а тільки для конкретного завдання у певній системі. Це як порівнювати автобус та трамвай, скрізь є +/-.
Рішення є, але вони не поширені через їхню відносну небезпеку. Безкоштовні невідомі. Та й чи з'являться вони...
У мене дещо інша думка: якщо первинним вважати не хмарний сертифікат, а хмарний сервіс. Так, єдиний сертифікат хмари можна використовувати не про всі сервіси. Але цінність, як на мене, не в сертифікаті, а в сервісах. І немає нічого поганого в тому, що кожен сервіс використовує свій хмарний ключ. На відміну від "on premise" сертифікатів (на токенах, смарт-картах або в реєстрі вашого персонального пристрою) вам не доведеться носити намисто з токенів або копіювати сертифікати в реєстри на всі пристрої. Просто приходитимуть SMS з різних номерів. Тим більше, що хмарний сертифікат, як правило, дешевший on premise, і не потрібна покупка ПЗ (криптопровайдера). Ну і з погляду безпеки така схеми апріорі виглядає надійніше, оскільки при компрометації одного ключа інші можуть залишатися робітниками (нескомпрометованими).
Поганого нічого немає, але витрати більше, ніж використовувати один повнофункціональний ключ (а не намисто) у багатьох системах. У моделі загроз застосування "хмарного ключа ЕП" додається ризик порушення безпеки каналу аутентифікації. Крім того, не скрізь можна безпечно використовувати OTPviaSMS. Та й психологічно більшість людей впевненіше почувається при зберіганні свого ключа у своєму сейфі, ніж з віртуальним ключем у віртуальному сховищі з умовно безпечним каналом управління його використанням.
Звичайно, це так, поки підписання ініціюється одним пристроєм, а SMS із кодом підтвердження підписання приходить на інший пристрій. А як тільки мобільний клієнт залишається один, така схема вже не апріорі надійніша. Залишається лише зручність користувача, але не надійність.
Користувач може виграти, отримати якусь перевагу перед конкурентами, які використовують папір з чорнилом або фізичні токени з апаратною підтримкою OneTimePassword, за рахунок швидкої реакції, більшої мобільності. Але й прийме великі ризики. Ризик відсутності сервісу. Ризик компрометації мобільного пристрою. Ризики виправдані, якщо йдеться про невеликі грошові суми. Угоду на мільйон я довірив би старому доброму паперу, що підписується в тиші, без сторонніх очей, без посередників і без поспіху.
Якщо треба буде підписати пакет із 30 документів. А сервіс не підтримує пакетне підписання. То доведеться отримати 30 SMS (або одне з 30 кодами підтвердження) і 30 разів ввести коди підтвердження. Це час, і реакція вже не швидша.
Але якщо кожен сервіс має свій сервіс для простановки ЕП, то інтеграція сервісів повинна бути дуже тісною. І пакетне підписання туди входитиме. Наприклад, прийде одне логічне SMS: "Код 0xs3cr3t для операції #22_1806. Шановний Костянтине Васильовичу. Для підтвердження отримання вхідних документів за період 01.06.2014-18.06.2014 (20 рахунків-фактур, 7 актів виконаних ), а саме - підписання 30-ти службових документів, що підтверджують отримання, введіть вказаний код.
Рішення є. Але, наскільки я знаю, КриптоПро для iOS та Android поширюється не безкоштовно.
Згодна. Загалом, це й маю на увазі. У цьому плані використовувати сертифікат хмари не дуже зручно.
Загалом, якщо потрібно працювати з кількома сервісами, то купівля кількох хмарних ЕП може бути навіть витратнішою, ніж купівля одного кваліфікованого сертифікату, СКЗІ та токена.
Щодо надійності, то тут питання довіри до захищеності того місця, на якому зберігатимуться ключі, до технологій, за допомогою яких здійснюватиметься підписання. Думаю, поки що технологія не дуже обкатана, і довіри буде не дуже багато. Але, погодьтеся, користуватися хмарним підписом все-таки досить зручно у деяких випадках. Щоб зрозуміти, який підпис підійде у конкретному випадку, потрібно подивитися на процеси, вивчити потреби, оцінити плюси та мінуси обох варіантів і потім уже ухвалювати рішення. Тому намагаємося показати обидві сторони однієї медалі хмарної ЕП.
А для яких платформ КриптоПро безкоштовний?
Думаю, технологія мало що вирішує – питання лише у довірі до постачальника рішення, якому ви довірите свій сертифікат.
Тому коли про подібні технології говорять у контексті внутрішньокорпоративного використання, я ще розумію, що це може "злетіти". Як тільки ми говоримо про довіру сертифікату третій стороні, я не бачу жодного шансу.
Наскільки я пам'ятаю, Крипто-Про для iOS та Android не продається кінцевим користувачам. Тому все йде на розсуд вендора прикладного ПЗ. Захоче він вам дати безкоштовно – дасть. Не захоче – не дасть. А може дати на додачу до тієї функціональності, заради якої ви рішення і купували.
Це припущення (як у вихідній статті), чи ви можете підтвердити це реальними цифрами?
А також Microsoft, Facebook, Twitter та сотні інших постачальників федеративної аутентифікації, причому кожен ресурс сам вибирає з якимсь із постачальників йому інтегруватися. Ви пропонуєте так само вчинити і із зберіганням сертифікатів?
І я правильно розумію, що ви ставите знак рівності між федеративною аутентифікацією, в якій ніякі дані користувача, за винятком дуже обмеженого набору, що передається з аутентифікаційним токеном, не залишають периметра сервісу та сервісом ЕЦП, через який повинні будуть проходити всі ваші дані, що підписуються?
А може, й не бути. Для хмарного ключа не потрібно токена та ПЗ. Сервіс може, наприклад, включити витрати на видачу хмарного токена в абонентську плату та надавати сертифікати хмар "безкоштовно". У будь-якому випадку це питання маркетингу, а не техніки.
Можна і підписати пакет із 30 документів. Це вже як налаштований сам сервіс, чи він підтримує пакетне підписання. А звідки береться ключ (з хмари чи з реєстру/токена) – це вже ортогональне питання. Слава, ти далі в коменті розвинув цю думку. Таке часто відбувається і "на папері". Біг бос може підписати власноруч лише реєстр платежів, а платіжки потім підписують довірені особи.
Слава, у крапку! :) Поки що хмарний підпис застосовується в хмарній бухгалтерії та здаванні звітності.
Мишко, вже працює:)
Євгене, аплодую Вашому коментарю стоячи:)
Мишко, дочекаємось відповіді Євгена, але я це зрозумів як приклад. Нове, зручніше і, можливо, менш безпечне рішення, через свою зручність, згодом приймається споживачами, оскільки отриманий комфорт переважив можливі ризики. Можливо, до першої біди. Можливо, що споживачі продовжать користуватися цим рішенням після негативної події.
Хмарний підпис зараз здається зручнішим, але апріорі менш безпечним. Але частина користувачів спокуситься зручністю та оцінить ризики безпеки як прийнятні. І користуватиметься хмарним підписом.
Хмарний підпис вже працює у "low-cost" сегменті. Цікаво було б спробувати її у сегменті “enterprise”. Можливо, бізнес заспокоять слова "КріптоПро HSM" чи щось інше. Треба думати, пропонувати та пробувати.
Ну так видаліть у статті аргумент "мобільність" з розділу "за".
А навіщо вона там?
Адже я правильно розумію, що під хмарною бухгалтерією розуміється сервіс, на якому ведеться облік і з якого потім надсилається звітність? Чому в цьому випадку мало просто авторизації користувача на сервісі? Навіщо ще ЕЦП – щоб відповідати вимогам регулятора?
Де саме? Всередині одного сервісу чи сервісів одного постачальника? Ок, приймається.
Тільки тепер мені потрібно завести сертифікат у кожного постачальника? Так?
У чому саме вона зручна?
Я бачу плюс лише в одному – якщо ти користуєшся web-сервісом, то організація підпису з локального клієнта може бути проблематичною.
На згадку КриптоПро (як і всього, що пов'язано з нашою дивною "російською" кваліфікованим підписом") У нормального бізнесу вже починається ідіоскарзія.
Так, правильно, але це можуть бути різні послуги. Не всім потрібна й бухгалтерія та звітність. Багато хто воліє вести бухоблік on premise, а потім уже складати звітність через сервіс. КЕП потрібна, щоб відповідати вимогам законодавства.
Так, усередині сервісів одного постачальника це працює. Теоретично можна навчитися надавати сертифікат хмари іншим постачальникам, якщо в цьому буде економічний сенс. Але цінність, як на мене, надають саме сервіси та середовища, де може бути використана ЕП, просте володіння хмарним чи звичайним сертифікатом не несе економічного сенсу.
У разі хмарного сертифіката користувача немає необхідності встановлювати ПЗ на свій пристрій і думати про копіювання сертифікатів на кожен пристрій або носити з собою завжди ключовий носій. Володіння хмарним сертифікатом - менш клопітка процедура, так що я не став би так сильно лякатися заводити купу сертифікатів у різних провайдерів. Та й вартість необхідного ПЗ та ключового носія (у випадку з on premise сертифікатами) буде помітно меншою за абонентські платежі, так що використання одного універсального сертифіката - питання скоріше зручності, ніж економічної вигоди.
Про HSM шануй – штука цікава. Подібні рішення мають і зарубіжні конкуренти, і давно. Отже, тут КриптоПро використовує універсальний світовий досвід.
Тішить, що ця тема викликає інтерес. Намагатимуся розвинути висловлену вище концепцію хмарного сервісу з урахуванням зауважень. 1. Хмарний сервіс як розвиток інформаційних систем є доконаним фактом, що передбачає підтягування до цього стандарту виробників програмного софту. З погляду зниження витрат - раніше вам доводилося купувати 2-3 програмного продукту, що забезпечують ваші потреби, тепер це 1, причому на 30-40% нижче за сумарну вартість.
2. Що таке цифровий підпис і для кого він насамперед потрібний? ЦП - це ваш ідентифікатор в IT системах, що дозволяє вам сказати "Я-це Я" для прийняття рішень за будь-якого рівня фінансової відповідальності з гарантованим рівнем захисту від злому або неправомірного використання. У будь-якому випадку поява ЦП - це еволюція "живого" підпису з метою прискорення реалізації бізнес-процесів компанії. Тобто. якщо раніше паперовий документоброблявся не поспішаючи, то тепер достатньо одного клацання для ухвалення рішень.
3. Ніхто не каже, що є ідеальні рішення та засоби. Дійсно КриптоПро набив оскому при його використанні. Нещодавно перевстановлював систему для бухгалтерів, що використовують 1C, НВІС та 2 обліки банків через web-інтерфейс (з використанням КриптоПро) - прокляв все, поки додав усі необхідні сертифікати та підтримку ключів.
Михайле, не зовсім знак рівності. Скоріше знак тотожність, т.к. ФА дозволяє реалізувати механізм єдиного вікна користувачів різних доменів, тобто. є ідентифікаційним гарантом для учасника авторизації. Сервіс ЕЦП сам має засоби авторизації та вирішує свої конкретні завдання. В даному випадку, явним прикладом може бути сайт держпослуги та послуги сателіти (наприклад РОІ). Сайт держпослуг є ФА, який гарантує ідентифікацію користувачів інших сервісів.
Сергію, абсолютно з вами згоден. Хмарний підпис може і повинен виступати як єдиний ідентифікаційний сервіс, який приймають інші учасники бізнес-процесів. Зараз це все надто фрагментоване і існує багато посередників на шляху руху документів.
Звідки слідує цей висновок?
Можливо, Ви не вмієте ним користуватися? Встановлення сертифікатів завдання дуже тривіальне і ні в кого не викликає питань. Причому технологічно вона нічим не відрізняється від встановлення сертифікатів на інших криптопровайдерах.
Використовуйте Зручні прикладні засоби, які працюють із СКЗІ та буде Вам щастя.
Нині те, що продається під назвою "хмарний підпис", не може виконувати функції ідентифікаційного сервісу, т.к. саме цілком залежить від автентифікації. У хмарного підпису і немає завдання ідентифікації, потрібно перенести процес формування підпису з робочого місця в хмару, але лише через те, що робоче місцекористувача не так безпечно, щоб працювати зі СКЗІ.
Що фрагментовано? Які посередники? Якщо про УЦ, то він потрібний для виготовлення кваліфікованих сертифікатів. Якщо про оператора, то як Ви без нього це уявляєте? Потрібен оператор електрики, оператор доступу до мережі, оператор хмарного підпису, оператор інформаційної системиі т.п. Це спеціалізована діяльність. А в нас не натуральне господарство.
Я як би цього не говорив:) Цілком припускаю використання хмарних підписівдля окремих сервісів, ну гаразд, нехай сервісів від одного оператора. Але як єдиний ідентифікаційний сервіс я поки що посоромився її використовувати.
Ага, останнім часом часто доводиться чути, як операторів ЕДО порівнюють із продавцями повітря. Напевно, напишу таки велику статтю, що робить оператор, крім забезпечення юридичної значущості, поки обмежусь тезами:
1. Створення ЕД. В інтерфейсі сервісу, як правило, можна створити найпоширеніші ЕД (ЕСФ, ТОРГ-12, акти тощо).
2. Зберігання ЕД. Не скажу за всі послуги, але Діадок зберігає ваші документи до тих пір, поки ви самі їх не видалите. Навіть якщо ви вже не сплачуєте абонплату.
3. Єдиний правовий простір. Спробуйте укласти договори з усіма своїми контрагентами, якщо ви, скажімо, оператор зв'язку чи енергозбутова компанія!
4. Транспорт. Ок, ви самі зможете організувати транспортування ЕД каналами зв'язку та контролювати підписання для всіх своїх 10 тисяч контрагентів? Ну ну...
5. Інтеграція. Розповім маленьку історію. Одна транснаціональна корпорація надумала надіслати через оператора ЕСФ і ТОРГ-12. Та біда, що ERP могла вивантажувати тільки PDF і те особливого збоченого формату. ІТ корпорації був десь у Латинська Америката приймав замовлення на розробку наступного року. Це не рахуючи тяганини з формулюванням ТЗ і узгодженням на кількох континентах. Хто зміг швидко налагодити інтеграцію? Правильно, оператор.
Сергій, тобто. Чи можна резюмувати про неспроможність IT-інфраструктури для забезпечення необхідної якості ЕД у рамках існуючих ERP? Виходячи з вищесказаного Вами, ЕД ще знаходиться в зародковому стані і не може повністю задовольнити потреби кінцевих користувачів у повному обсязі.
Тоді виходить, що виробники паперу продають оброблену целюлозу.
Навіщо так? Електронний документообіг – не самоціль, це інструмент. Він розвивається, і вимоги зростають те саме. Десь вимоги вищі, десь ЕД сам формує потреби. Загалом, я вважаю, стан ЕДО в Росії більш-менш адекватний вимогам ринку.
Сергій, роблячи такий висновок, я спираюся на те, що ви написали вище. Адже ви порушуєте питання щодо ефективності IT-засобів для реалізації ЕД. Крім цього, хмарний сервіс як сфера послуг досить динамічно розвивається і шанси появи електронного підпису - питання часу.
Щоденна передплата. Інші види передплат доступні при реєстрації.
(ЕП) у хмарі. Здебільшого цю тему обговорюють IT-фахівці. Проте з розвитком сервісів електронного документообігу (ЕДО), у тему хмарної ЕП стали втягуватися і фахівці-предметники - бухгалтери, секретарі та інші.
Поясню, хмарний електронний підпис має на увазі, що ваш закритий ЕП зберігається на сервері і підписання документів відбувається там же. Супроводжується це укладанням відповідних договорів та довіреностей. А фактичне підтвердження особи підписувача відбувається, як правило, з використанням авторизації через SMS.
Необхідність використання хмарної ЕП бухгалтером залежить від цього, в якому режимі він працює. Якщо ви часто знаходитесь поза офісом, або, наприклад, працюєте в компанії, яка надає послуги з бухобліку (аутсорсинг бухгалтерії), то хмарна ЕП допоможе вам підписувати документи з будь-якого місця. Однак, незважаючи на простоту використання, не всі компанії готові використовувати цю можливість.
Щоб ви змогли самі вибрати, потрібний вам хмарний електронний підпис чи ні, розглянемо всі «за» та «проти» його використання. А також подумаємо, кому може справді стати в нагоді такий підпис. До речі, у цій статті ми говоритимемо лише про посилену (далі – УКЕП).
За
Хмарний електронний підпис дешевший за звичайний. В основному це пов'язано з тим, що вам не потрібно купувати засіб криптографічного захисту інформації (СКЗІ) та токен (флешка із сертифікатом). Як правило, з урахуванням їх придбання, ціна на злітає у 2-2.5 рази.
Зручність та простота використання. Для роботи з хмарним електронним підписом не потрібно встановлювати як сам сертифікат електронного підпису, так і спеціальні засоби для роботи з ним. Це означає, що ви не витрачатимете час на те, щоб розібратися, як все це працює.
Мобільність. На даний момент поширених та безкоштовних рішень для використання нехмарного електронного підпису на мобільних пристроях ще немає. У цьому плані величезним плюсом хмарного електронного підпису є те, що працювати з ним можна з будь-якого комп'ютера, планшета, смартфона, де є інтернет.
Проти
Фізично документ підписуєте не ви. Потрібно розуміти, що в разі хмарного електронного підпису закрита частина ключа, яка є конфіденційною і повинна належати тільки вам, буде перебувати на сервері центру, що посвідчує. Звичайно, це буде оформлено документально, а сервери надійно захищені. Але тут все залежить від вимог компанії до безпеки та пов'язаної з підписанням документів. Якщо вам важливо, щоб документи підписували самі власники закритих ключів, то електронний хмарний підпис вам не підійде. У цій ситуації лише вам вирішувати, наскільки ви довіряєте УЦ та серверам, на яких зберігаються закриті ключі.
Ви можете використовувати хмарну ЕП тільки у тих сервісах, з якими є інтеграція програмного забезпечення центру, що посвідчує. Це також пов'язано з тим, що у разі хмарної ЕП закритий ключ зберігається на сервері УЦ. Для того щоб потрібний вам сервіс міг використовувати такий закритий ключ ЕП для підписання, йому потрібно вміти надсилати запит на формування електронного підпису на сервер УЦ. Зрозуміло, що на даний момент сервісів багато і всі вони не зможуть передбачити інтеграцію з програмним забезпеченнямУЦ. Виходить, що хмарну ЕП вам доведеться використовувати лише з певними сервісами. Для роботи з іншими сервісами доведеться купувати інший сертифікат ЕП, і немає, що ці сервіси будуть підтримувати будь-який хмарний електронний підпис.
І що ж?
Хмарний електронний підпис - це зручний, мобільний та простий інструмент, але не найгнуткіший. А з точки зору надійності, можливо, зберігати закритий ключ на захищеному сервері буде краще ніж на токені в ящику столу.
Кому ж справді потрібний електронний підпис? Насамперед тим, хто часто працює не зі свого кабінету в офісі. Наприклад, аудитори, які часто виїжджають до клієнтів. Або та яким важливо підписувати документи у будь-якому місці. Для них хмарний електронний підпис стане незамінним помічником у роботі.
Також дуже багато залежить від політики компанії. Якщо організація рухається у бік хмарних технологій, наприклад, щодо зберігання документів, використання сервісів для внутрішнього і зовнішнього документообігу, то й електронні підписи, швидше за все, теж будуть хмарними. В іншому, бухгалтерам, діловодам та іншим співробітникам, які зазвичай при роботі не залишають свій кабінет, хмарний електронний підпис не потрібний. Їм можна придбати закритий ключ ЕП та сертифікат ЕП у звичайному режимі, на носії, який можна використовувати у більшості сервісів для обміну з контрагентами та державними установами.
У хмару можуть бути перенесені тільки крипто ключі, випущені з СКЗІ КриптоПро.
Перенесення проводиться у 2 етапи, вони описані нижче.
Перевірка ЕЦП на відповідність вимогам, що висуваються
- У вікні «» (Малюнок 3) заповніть поле «Ім'я ключового контейнера». Він може бути знайдений у списках контейнерів (кнопка « Огляд») або сертифікатів (кнопка « За сертифікатом»).
Відкрийте панель управління засобу криптографічного захисту інформації (СКЗІ) КриптоПро CSP («Пуск» – «Панель управління» – «КриптоПро CSP») від імені адміністратора (Вкладка «Загальні» - «Запустити від імені адміністратора») та перейдіть на вкладку «Обладнання» (Малюнок 1).
Рисунок 1 – Налаштування зчитувачів
Натисніть кнопку " Налаштувати зчитувачі…». Зчитувач USB флеш-накопичувача та дискет встановлюється за умовчанням при встановленні CryptoPro CSP. Перевірте, що на закладці «Зчитувачі» є пункт « Усі знімні диски». Якщо пункт «Всі знімні диски» відсутній, його необхідно додати через кнопку « Додати…» (Малюнок 2).
Рисунок 2 – Управління зчитувачами
Переконайтеся, що чистий USB флеш-накопичувач підключений та доступний.
Перейдіть на вкладку «Сервіс» та натисніть кнопку « Копіювати».
Рисунок 3 – Вкладка «Сервіс» кнопка «Скопіювати»
Відкриється вікно "Копіювання контейнера закритого ключа".
Після того, як ключовий контейнер буде знайдено, натисніть кнопку « Далі». Якщо на доступ до закритого ключа встановлено пароль, він буде запитаний.
Введіть пароль та натисніть кнопку « ОК». Відкриється вікно введення параметрів нового контейнера закритого ключа (Малюнок 4).
Рисунок 4 – Вікно введення параметрів нового контейнера закритого ключа
Відкриється вікно « Копіювання контейнера закритого ключа»(Малюнок 5).
Малюнок 5 - Вікно "Копіювання контейнера закритого ключа"
Введіть ім'я нового ключового контейнера та встановіть перемикач « Введене ім'я задає ключовий контейнерв положення « Користувач».
Натисніть кнопку "Готово". Відкриється вікно, в якому необхідно вибрати USB флеш-накопичувач для розміщення скопійованого контейнера (Малюнок 6).
Малюнок 6 - Вікно вибору носія
Натисніть кнопку " ОК». Відкриється вікно створення пароля для доступу до контейнера закритого ключа (Малюнок 7).
Малюнок 7 - Вікно введення пароля
На цьому кроці слід створити пароль для нового контейнера закритого ключа та підтвердити його. Цим паролем буде захищено цифровий підпис., його потрібно вводити при кожному зверненні до неї. Після введення потрібних даних натисніть кнопку «ОК». Засіб криптографічного захисту інформації (СКЗІ) "КриптоПро CSP" здійснить копіювання контейнера закритого ключа на USB флеш-накопичувач.
Для копіювання відкритого ключа ЕЦП запустіть панель налаштувань Internet Explorer (« Пуск» – « Панель управління» – « Властивості браузера» (Малюнок 8)) і перейдіть на вкладку « Зміст(Малюнок 9).
Малюнок 8 - « Панель управління» – « Властивості браузера»
Малюнок 9 - « Властивості браузера» - « Зміст» - « Сертифікати»;
На вкладці «Зміст» натисніть кнопку «Сертифікати». У вікні «Сертифікати» виберіть пов'язаний із закритим ключем сертифікат ЕЦП та натисніть кнопку «Експорт…» (Малюнок 10).
Малюнок 10 – Оснащення «Сертифікати»
Відкриється вікно « Майстер експорту сертифікатів»(Малюнок 11).
Малюнок 11 – Майстер експорту сертифікатів
У вікні майстра експорту сертифікатів натисніть кнопку « Далі». На наступному кроці відмовтеся від експорту закритого ключа, встановивши прапорець « Ні, не експортувати закритий ключ» (Малюнок 12) та натисніть кнопку «Далі».
Рисунок 12 – Вибір типу ключів для експорту
На наступному кроці виберіть формат файлу сертифіката ЕЦП, встановивши перемикач у полі «Файли X.509 (.CER) у кодуванні DER», та натисніть кнопку « Далі(Малюнок 13).
Рисунок 13 – Вибір формату файлу сертифіката ЕЦП
На завершальному етапі вкажіть ім'я та розташування файлу та натисніть кнопку « Далі». На останньому кроці майстра перевірте вибрані параметри та натисніть кнопку « Готово»(Малюнки 14 та 15).
Малюнок 14 – Вказівка шляху збереження та найменування сертифіката
Малюнок 15 – Збереження сертифіката ЕЦП
Файли, отримані в результаті вищеописаних маніпуляцій, слід помістити в папку і скопіювати в хмару шляхом « W:\ЕЦП». Дана папка доступна лише основному користувачеві.
В результаті має вийти приблизно наступне "W:\ЕЦП\ТОВ Тест" (рисунок 16).
Малюнок 16 - ЕЦП скопійовано в хмару.
Установка проводиться фахівцями з інформаційної безпеки, вони працюють у будні з 9 до 18 по Мск. У заявці слід зазначити назву папки, в яку ви зберегли ЕЦП.
Якщо ключі випущені за допомогою СКЗІ VipNet, то працювати на термінальній фермі (через віддалений робочий стіл або RemoteApp) вони не будуть. У такому разі робота може проводитися на локальному ПК з використанням тонкого клієнта, детальніше про встановлення та роботу в .
Якщо варіант роботи в тонкому клієнті Вам не підходить, то ЕЦП слід перевипустити через КриптоПро, з питань схвалення заявки на перевидання сертифіката слід звертатися до своєї обслуговуючої організації.
Ще минулого століття багато підприємств почали масово переходити на електронний документообіг. В усіх з'явилися комп'ютери з офісними програмами. Документи часто набирали в Microsoft Wordабо інших текстових редакторів, експортованих до PDF, надсилали електронною поштою.
Здавалося, що якщо документообіг електронний, то ми скоро забудемо про шафи з паперовими архівами, на робочих столах не залишиться жодного паперового листа. Якщо раптом до організації надішлють паперовий документ звичайною поштою, то артефакт негайно відсканують і переведуть у цифровий вигляд. Насправді сталося зовсім навпаки. Виявилося, що чим більше організація використовує комп'ютери для цифрового документообігу – тим більше документів вона друкує. Адже кожен документ треба завізувати. Документ без підпису - це просто чернетка чи інформаційна записка. Щоб отримати підпис, документи друкують, а потім часто сканують назад, зберігаючи оригінали в архіві.
Зараз зрозуміло, що справді електронний(безпаперовий) документообіг не впровадити без цифрових підписів.
Сьогодні B2B, B2C компанії та державні організаціїпереходять до впровадження цифрових підписів за їх незаперечні переваги:
- Безпаперовий документообіг. Економія часу, грошей та ресурсів.
- Ефективні бізнес-процеси. Підписання у електронному виглядіробить кожну транзакцію гладкішим процесом.
- Мобільні здібності. Взаємодія всередині організації та з клієнтами стає простіше.
Поступово виробляються єдині стандарти електронного документообігу та інфраструктури цифрових підписів. Наприклад, у країнах Євросоюзу з 1 липня 2016 року діє стандарт eIDAS (electronic IDentification, Authentication and trust Services) для електронних сервісівідентифікації, автентифікації та довіри. У США прийнято стандарт 21 CFR 11 .
Найбільші у світі довірені служби для електронних документів- довірений список Adobe (AATL) та програма Microsoft Root Trust. Центри, що засвідчують, включені до цього списку, випускають засновані на сертифікатах цифрові ідентифікатори та служби позначок часу, які відповідають нормативним вимогам у світі, як стандарт eIDAS. Для найпопулярніших форматів офісних документів вже підтримуються електронні цифрові підписи. У тому числі підтримується підпис документа декількома особами, з позначками часу.
Що таке Digital Signing Service (Хмарний сервіс цифрових підписів)?
Digital Signing Service (DSS) - це масштабована платформа з підтримкою API для швидкого розгортання цифрових підписів, яка забезпечує:Для свого сервісу DSS потрібно налагодити не тільки робочий процес підпису та керування користувачами. Потрібні ще сертифікати підпису для посвідчення особи автора кожного документа. Це включає криптографічні елементи, такі як управління ключами, система зберігання ключів рівня безпеки FIPS level 2 або вище (наприклад, апаратні токени або HSM), служба OCSP або CRL, а також служба міток часу. Об'єднання цих компонентів, особливо інтеграція з апаратним модулем безпеки (HSM) безпосередньо, чи то хмара, чи локально, вимагає значних зусиль з боку відділу ІТ та відділу інформаційної безпеки поряд з хорошими знаннями криптографії та наявністю необхідних ресурсів.
Важливо враховувати ці приховані витрати та інвестиції, а також обмеження та накладні витрати при оцінці рішень для цифрового підпису.
Окремо варто згадати, що якщо служба DSS є критично важливою для організації, то вона повинна працювати з високим рівнем аптайму та забезпечувати більшу пропускну здатність. Тобто потрібно проектувати своє рішення з певною часткою надмірності – із запасом на майбутнє. І слід припускати, що бізнесу властиве зростання. Інфраструктура має бути масштабованою.
| Digital Signing Service | Традиційна реалізація | |
|---|---|---|
| Інтеграція із додатками для підпису документів | Через простий REST API | Потребує внутрішньої криптографічної експертизи для конфігурації та підтримки |
| Компоненти криптографічного підпису (сертифікати, OCSP, CRL, мітки часу | Включені в API, не вимагають розвинених знань криптографії або ресурсів розробки | Йдуть окремо, вимагають окремих викликів із додатків та внутрішніх ресурсів розробки для налаштування |
| Масштабованість | Висока масштабованість - не потрібно додаткове налаштуванняабо інтеграція | Може знадобитися закупівля додаткового обладнання та конфігурація |
| Висока доступність та аварійне відновлення | Постачається через інфраструктуру GlobalSign, перевірену WebTrust, з глобальними центрами обробки даних, надмірністю та найкращим обладнанням для захисту мережі | Вимагає додаткових інвестицій у обладнання |
| Управління секретними ключами та їх зберігання | Через REST API, внутрішні ресурсиабо обладнання не використовуються | Клієнт відповідає за керування ключами та їх зберігання (наприклад, у хмарі або локальному HSM) |
| Посвідчення підпису | Підтримка підписів двох рівнів: відділів та співробітників (наприклад, Джон Доу, бухгалтерія) | Не всі рішення підтримують обидва типи посвідчень |
Хмарний сервіс дуже спрощує розгортання системи документообігу за допомогою цифрових підписів. Усі операції просто проходять через API.
Хмарні послуги відрізняються за цінами та функціональністю. Але всі вони гарантують гнучкість, масштабованість та високий рівеньдоступність. Хоча послуги платні, зате позбавляють компанії необхідності інвестувати в розробку власних рішень, у тому числі закуповувати дороге криптографічне обладнання.
Кому знадобиться хмарний сервіс цифрових підписів? За ідеєю, це будь-які організації будь-якого розміру, які розробляють або вводять в експлуатацію спеціально розроблені додатки і мають намір або інтегрувати туди цифрові підписи або використовувати вже інтегрований додаток.
- Постачальники рішень документообігу чи додатків, які бажають інтегрувати цифрові підписи чи друку. Інший варіант: запропонувати їх клієнтам як преміальну опцію як гарантований захист документів від підробки. Тут підтримується гнучка модель: цифрові підписи можна додати як додатковий шар або опцію.
- Підприємства, які хочуть інтегрувати цифрові підписи чи печатки до свого документообігу.
- Системні інтегратори, які впроваджують цифрові підписи до існуючих та нових систем документообігу.
