Серверная ЭЦП — это схема, при которой закрытый ключ подписи не выдаётся владельцу на носитель, а хранится и применяется на защищённом сервере: в аппаратном модуле КриптоПро HSM, в инфраструктуре удостоверяющего центра или в мобильной схеме вроде Госключа. Рабочее место при этом не требует ни токена, ни установленного криптопровайдера: пользователь подтверждает операцию, а криптографическое преобразование выполняется на стороне сервиса. Токен решает другую задачу — обеспечивает существование ключа в единственном экземпляре: ключ рождается в криптоядре носителя и не покидает его память. Главное различие, от которого зависит выбор: подписывает живой человек каждый документ отдельно или информационная система подписывает поток документов обезличенным сертификатом. В первом случае схемы взаимозаменяемы, во втором токен на рабочем месте становится узким местом.
Разберём режимы ключей в КриптоПро CSP, чем неизвлекаемый ключ отличается от неэкспортируемого, что 63-ФЗ реально требует от хранения ключа и почему обезличенный сертификат нельзя выдать сотруднику. Покажем, как по файлу .p7s или .sig увидеть, чем подписан документ, и где серверная схема ломается: терминальные сессии, ЕГАИС, требования отдельных приёмных сторон. Сравнительная таблица по восьми параметрам, пошаговый выбор схемы, тарифы на 2026 год и ответы на частые вопросы — во второй половине статьи.
Что такое серверная ЭЦП и где физически лежит ключ
Термин «электронная подпись» в обиходе покрывает три разные сущности, и путаница начинается именно здесь. Ключ электронной подписи — это число, которым выполняется криптографическое преобразование. Ключ проверки — парное ему число, жёстко связанное математическим соотношением. Сертификат ключа проверки — электронный документ удостоверяющего центра, который связывает ключ проверки с владельцем: ФИО, ИНН, СНИЛС и прочие атрибуты. В удостоверяющем центре человек получает сертификат, а не подпись; сама подпись вычисляется каждый раз заново по конкретному документу.
Серверная схема меняет только одно: место, где живёт ключ подписи и где выполняется преобразование. В КриптоПро CSP начиная с пятой версии ключ можно хранить не локально на токене или в реестре, а удалённо в КриптоПро HSM — специализированном сервере в составе системы дистанционной подписи. Пользователь формирует документ в системе документооборота, документ уходит на сервер, оттуда прилетает на смартфон, человек открывает его, читает и подтверждает подписание. Дальше команда возвращается на сервер, и подпись формируется либо в HSM, либо на самом мобильном устройстве, в зависимости от реализованной схемы.
Облачная подпись от удостоверяющего центра устроена так же по принципу: закрытый ключ находится на сервере центра, а пользователь обращается к нему через интеграцию с конкретным сервисом. Отсюда два практических следствия. Первое: доверять приходится не только математике, но и оператору, который держит ключ. Второе: облачную подпись можно применять только в тех системах, где интеграция с программным обеспечением этого центра уже сделана. Мобильная подпись стоит рядом: она встроена в приложение на телефоне и работает там, где приложение поддержано приёмной стороной.
Факт: в схеме дистанционной подписи ключи хранятся в КриптоПро HSM — сервере, сертифицированном по классу КВ2, максимальному для устройств, не связанных с гостайной. Криптопровайдер и токен на рабочем месте пользователя при этом не нужны.
Экономика схемы понятна любому, кто обслуживал парк носителей: не нужно закупать токены, не нужно покупать локальные лицензии криптопровайдера на каждое рабочее место, не нужно обновлять и чинить эти рабочие места. При большом количестве пользователей централизованная схема выигрывает по трудозатратам. Это не замена токена, а второй равноправный вариант: у локальной и дистанционной подписи разные сильные стороны, и выбор определяется сценарием, а не модой. В практике Добыто чаще всего встречается смешанный контур: руководитель подписывает токеном из удостоверяющего центра ФНС, а сотрудники — подписью, выпущенной внутри платформы, без установки чего-либо на их компьютеры.
Токен: неизвлекаемый ключ, ФКН и режимы КриптоПро CSP
Ключи на токене делятся на две категории, и различие между ними важнее, чем модель носителя. Программные ключи генерируются криптопровайдером, а токен работает как защищённое ПИН-кодом хранилище: при подписании закрытый ключ ненадолго выгружается в оперативную память компьютера. Такие ключи называют извлекаемыми, а носители — пассивными. Аппаратные ключи генерируются внутри криптоядра микроконтроллера, никогда не покидают память носителя и потому неизвлекаемы: скопировать их нельзя в принципе.
Внутри извлекаемых ключей есть ещё одно деление, которое регулярно путают с неизвлекаемостью. Флаг экспортируемости выставляется криптопровайдером при генерации или копировании контейнера. Экспортируемый контейнер копируется, неэкспортируемый — нет, но и тот и другой при подписании попадает в память компьютера. Неэкспортируемый ключ — это запрет на копирование средствами провайдера, неизвлекаемый — физическая невозможность вынести ключ с устройства.
Полезно знать: по регламенту удостоверяющего центра ФНС извлекаемый ключ выдаётся только в неэкспортируемом контейнере, а сертификат руководителя записывается на токен без права копирования. Первичная выдача происходит лично, доверенности на получение не работают.
Неизвлекаемые ключи бывают двух форматов. PKCS#11 генерируется аппаратными средствами устройства и является открытым стандартом: любое приложение, которое встраивает библиотеку PKCS#11, увидит такой ключ и сможет с ним работать. Функциональный ключевой носитель, ФКН, генерируется совместно аппаратными возможностями токена и КриптоПро CSP, а канал между провайдером и носителем дополнительно шифруется по протоколу SESPAKE. ФКН защищает не только ключ, но и сам обмен: ПИН-код не передаётся в открытом виде, а навязать носителю чужой хэш через перехват канала не получится.
Отсюда требования к железу. Рутокен Лайт — пассивный носитель без криптоядра, он не сгенерирует ни PKCS#11, ни ФКН и годится только под извлекаемые ключи. Рутокен ЭЦП 3.0 работает как активный токен, генерирует неизвлекаемые ключи, поддерживает алгоритмы «Магма» и «Кузнечик», несёт 128 КБ защищённой памяти и в дуальных моделях работает и по USB, и по NFC. ESMART Token ГОСТ построен на отечественном микроконтроллере производства «Микрона» и сертифицирован ФСБ по классам КС1, КС2 и КС3; младшая модель ESMART Token 192K имеет сертификат ФСТЭК и применяется как защищённое хранилище для сертификатов удостоверяющих центров ФНС и Федерального казначейства. Разница в сертификации не косметическая: если носитель используется как криптоядро, а не как хранилище, для квалифицированной подписи нужен именно сертификат ФСБ.
Важный нюанс из практики: режим ключа выбирается в момент выпуска, в выпадающем списке при создании контейнера. Ключ в режиме ФКН заработает только с КриптоПро CSP не ниже пятой версии; на машине с CSP 4.0 он не заведётся. Если сотрудник ходит по разным рабочим местам с разными версиями провайдера, нужен пассивный извлекаемый ключ в режиме «КриптоПро CSP» — он совместим со всей линейкой провайдеров. В КриптоПро CSP 5.0 R2 режим PKCS#11 пришлось выбирать отдельным считывателем, и с ним ломались вход в Windows и RDP; в R3 этот режим встроили в общий список, и проблема ушла.
Пожалуйста, подпишитесь на нас в мессенджерах
Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.
Мария Ж, специалист по цифровой подписи и КЭДО: «Перед выпуском ключа мы всегда спрашиваем, на скольких машинах он будет работать и какие там версии криптопровайдера. Токен — вещь мобильная, и вероятность, что он всю жизнь проживёт в одном компьютере, мала. Если сомневаетесь, берите режим обратной совместимости: неизвлекаемый ключ безопаснее, но он бесполезен, если сотрудник не может им подписать документ на втором рабочем месте».
На носителе со 128 КБ защищённой памяти помещается до 31 ключевого контейнера в формате КриптоПро CSP. Реальное число меньше: контейнер с длинными цепочками сертификатов и дополнительными расширениями удостоверяющего центра занимает до 12 КБ, так что десяток таких контейнеров — это нижняя граница вместимости. Если вы планируете хранить на одном токене подписи по нескольким организациям, считайте объём заранее.
Как по файлу подписи понять, чем подписан документ
Файл подписи — это контейнер формата CMS, он же PKCS#7. Внутри лежат версия контейнера, идентификатор алгоритма хэширования по ГОСТ, при присоединённой подписи сам подписанный контент, список отозванных сертификатов, блок сертификатов подписанта в формате X.509 с цепочкой доверия и структура SignerInfo со значением подписи, заявленным временем подписания и штампом времени.
Присоединённая подпись включает документ в себя, отсоединённая лежит рядом отдельным файлом. Расширение при этом ничего не говорит о содержимом: в настройках Инструментов КриптоПро расширение выбирается из списка p7s, sig и sgn, а в КриптоАРМ ГОСТ доступны ещё sign и bin. Все они могут быть одним и тем же контейнером CMS. Ориентироваться нужно на структуру, а не на суффикс имени файла.
Различить серверную и локальную подпись по контейнеру можно, если смотреть на сертификат подписанта. Обезличенный сертификат для информационной системы выдаётся на юридическое лицо или индивидуального предпринимателя и не содержит ФИО физического лица: в нём нет владельца-человека, потому что документ подписывает не человек, а система. Сертификат обычного сотрудника содержит ФИО и СНИЛС. Уровень усовершенствования подписи виден по составу неподписываемых атрибутов: CAdES-BES ограничивается значением подписи, CAdES-T добавляет штамп времени от службы TSP, CAdES-X Long Type 1 добавляет ответ службы OCSP о статусе сертификата на момент подписания, CAdES-A накрывает предыдущие доказательства архивной меткой.
Проверьте свой файл подписи и посмотрите, что внутри
Добыто · Проверка подписи
Что за файл пришёл с документом
Загрузите файл — определим по расширению и содержимому: присоединённая это подпись или откреплённая, чем открыть и куда идти дальше. Архивы раскрываем и смотрим, что внутри.
Файл остаётся на вашем устройстве — мы его не получаем и не хранимНет файла под рукой? Выберите расширение вручную:
Пожалуйста, подпишитесь на нас в мессенджерах
Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.
Мы не храним ваши файлы и не имеем к ним доступа. Файл читается только в памяти вашего браузера, на сервер Добыто он не передаётся, копий не остаётся. Закройте страницу — и от файла не останется следов.
Проверка вручную по контейнеру занимает время, поэтому в сервисе Добыто разбор файла подписи вынесен в браузер: загружаете документ и файл подписи, получаете статус, сведения о сертификате и дату подписания. Тот же принцип лежит в основе серверных решений: КриптоАРМ Server ставится в контуре заказчика в виде готовых Docker-образов, разбирает входящий поток фоном, сохраняет результаты проверки в базу и формирует протокол проверки в PDF. Из запросов, которые получают разработчики таких решений, около 80 процентов касается подписи и её проверки и около 20 процентов — шифрования и расшифрования документов.
Важный нюанс из практики: когда серверный сервис подписывает и шифрует исходящую почту, получателю без ГОСТ-совместимого почтового клиента приходит письмо с вложением вида .p7m, которое он не откроет. Сквозное шифрование по ГОСТ работает только при наличии подходящего клиента на обеих сторонах, поэтому в регламенте обмена этот пункт согласовывают до запуска, а не после первой жалобы контрагента.
Что разрешает 63-ФЗ: конфиденциальность ключа, обезличенный сертификат и МЧД
Норматива, который обязывал бы хранить ключ именно на аппаратном носителе, в российском праве нет. Закон 63-ФЗ требует другого: участник электронного взаимодействия обязан обеспечивать конфиденциальность ключа и не допускать использование принадлежащего ему ключа без своего согласия, а при подозрении на компрометацию — уведомить удостоверяющий центр и отозвать сертификат. Технически ключ может лежать на токене, в реестре операционной системы или на сервере. Неизвлекаемый ключ — это хорошая инженерная практика, а не требование закона. Для сравнения: европейская директива в аналогичной части предписывает вычислять квалифицированную подпись только специальным сертифицированным устройством.
Мария Ж, юрист со стажем более 20 лет: «Спор о том, где лежит ключ, часто подменяет собой спор об ответственности. По 63-ФЗ отвечает владелец сертификата, и неважно, отдал он токен помощнику или пустил подрядчика в серверный контур. Поэтому в положении об электронной подписи фиксируйте не только место хранения, но и порядок доступа: кто выдаёт ПИН, кто имеет права на сервере подписания, что происходит при увольнении».
Для квалифицированной подписи добавляются формальные требования: сертификат выпускает аккредитованный удостоверяющий центр по составу, установленному приказом ФСБ № 795, а средство электронной подписи проходит оценку соответствия по приказу ФСБ № 796. Для усиленной неквалифицированной подписи нужны либо норма закона, либо соглашение сторон о порядке создания и проверки подписи и разбора конфликтных ситуаций. Кадровый контур опирается на статьи 22.1-22.3 ТК РФ и 377-ФЗ, а правила формирования и использования УНЭП в мобильном приложении задаёт постановление Правительства от 1 декабря 2021 года № 2152: именно эта подпись выдаётся дистанционно, без визита в удостоверяющий центр. Проверить, как выглядит клиентский путь, можно самостоятельно: отправьте документ сам себе через приложение Госключ на портале госуслуг и подпишите его.
Отдельная сущность серверной схемы — обезличенный сертификат для информационной системы. Оператор системы получает его в удостоверяющем центре ФНС, сертификат выдаётся на юридическое лицо или индивидуального предпринимателя и привязывается к конкретной системе. Сотрудники таким сертификатом пользоваться не могут: он существует ровно для того, чтобы система подписывала документы, которые формирует сама, — запросы в госорганы, счета, квитанции. Носитель с таким сертификатом устанавливается на сервере, и дальше документы подписываются по настроенным правилам без участия человека.
Мария Ж, соучредитель сервиса КЭДО Добыто: «Обезличенный сертификат не решает кадровую задачу. Приказ о приёме или дополнительное соглашение подписывает конкретное лицо, и подмена его подписью информационной системы обесценивает документ как доказательство. Автоматике отдают то, что машина и породила: реестры, уведомления, регулярную отчётность. Всё, где нужна воля человека, идёт через персональный сертификат».
Полномочия сотрудника, подписывающего от имени компании, с сентября 2023 года подтверждает машиночитаемая доверенность. Это XML-файл, подписанный квалифицированной подписью руководителя; состав сведений задаёт приказ № 857, формат — приказ № 858, порядок формирования классификатора полномочий — приказ № 856. У доверенности есть 36-символьный идентификатор, по которому её статус и полномочия проверяются на сервисе ФНС при знании трёх параметров: номера доверенности, ИНН доверителя и СНИЛС доверенного лица. Классификатор полномочий предусматривает ограничения по суммам, типам документов, видам сведений и по филиалам.
Внимание: любое изменение XML-файла машиночитаемой доверенности ломает подпись под ней. Расширение полномочий — это всегда новая МЧД, а не правка существующей. Сертификат и доверенность между собой не связаны: за пять лет действия МЧД сотрудник может сменить несколько сертификатов.
Формы учёта и образцы для контура электронной подписи
Комплект закрывает учётную часть: начните с реестра выданных токенов, если у вас уже есть парк носителей и вы не знаете, у кого что на руках.
| Документ | Скачать |
|---|---|
| Реестр выданных токенов | Скачать |
| Реестр сертификатов сотрудников | Скачать |
| Приказ об ответственном за КЭДО и делегировании права подписи | Скачать |
| Чек-лист диагностики «Подпись не валидна» | Скачать |
| Протокол проверки электронной подписи, образец | Скачать |
| Машиночитаемая доверенность: образец и структура XML | Скачать |
Токен и серверная подпись: сравнение по восьми параметрам
Сравнение имеет смысл вести не по абстрактной безопасности, а по параметрам, которые определяют работу администратора и пользователя.
| Параметр | Ключ на токене | Ключ на сервере |
|---|---|---|
| Где хранится закрытый ключ | В защищённой памяти носителя, при неизвлекаемом ключе не покидает её | В КриптоПро HSM или в инфраструктуре удостоверяющего центра |
| Что нужно на рабочем месте | Криптопровайдер с лицензией, драйверы носителя, считыватель | Ничего: ни токена, ни локального криптопровайдера |
| Копируемость ключа | Неизвлекаемый скопировать нельзя, извлекаемый экспортируемый копируется | Ключ пользователю не выдаётся вовсе |
| Как подтверждается подписание | ПИН-код носителя на рабочем месте | Подтверждение в мобильном приложении после просмотра документа |
| Сертификация средства | ФСТЭК для хранилища, ФСБ для носителя с криптоядром | Класс КВ2 для HSM, максимальный вне гостайны |
| Работа без связи | Подпись формируется офлайн, включая смарт-карту по NFC без интернета | Нужен доступ к серверу подписания |
| Поток документов | Носитель физически подключён к рабочему месту всю смену | Пакетное и автоматическое подписание обезличенным сертификатом |
| Типовое применение | УКЭП руководителя, госсистемы, ЕГАИС, нотариат | Массовый кадровый документооборот, подпись рядовых сотрудников |
Из таблицы следует практический критерий: чем сильнее сценарий завязан на конкретную приёмную сторону с собственными требованиями к средству подписи, тем весомее аргументы за токен. Чем больше в сценарии однотипных документов и людей без администрируемых рабочих мест, тем выгоднее сервер.
Что проверить до закупки носителей и подключения сервиса
Большая часть ошибок в контуре электронной подписи закладывается до первого подписанного документа: сертификат выпускают в режиме, который не поддерживается половиной рабочих мест, или подключают облачную подпись к системе, где интеграции с этим удостоверяющим центром нет. Шесть шагов ниже закрывают эту зону.
Как выбрать схему хранения ключа: пошаговая инструкция
- Шаг 1. Разложите документы по видам подписи. Отдельно то, что требует УКЭП по закону; отдельно то, где достаточно УНЭП по соглашению или по правилам кадрового документооборота; отдельно то, что подписывает система, а не человек.
- Шаг 2. Соберите список приёмных сторон. Госсистемы, электронные площадки, банки и операторы ЭДО задают собственные требования к средству подписи; облачная подпись работает только там, где интеграция с программным обеспечением удостоверяющего центра уже реализована.
- Шаг 3. Проведите инвентаризацию рабочих мест: версии КриптоПро CSP, операционные системы, наличие терминального доступа. Ключ в режиме ФКН требует пятой версии провайдера, PKCS#11 — версии 5.0 R2 и выше.
- Шаг 4. Определите модель полномочий. Если от имени компании подписывают сотрудники, посчитайте, сколько машиночитаемых доверенностей вам нужно и какие полномочия в них войдут, включая ограничения по филиалам.
- Шаг 5. Задайте требования к хранению. Если документы живут дольше срока действия сертификата, закладывайте штамп времени и усовершенствованный формат подписи сразу, а не при первом споре.
- Шаг 6. Опишите учёт и порядок доступа: реестр носителей и сертификатов, ответственный за выдачу, порядок действий при блокировке ПИН-кода, смене фамилии и увольнении. Без этого любая схема разваливается на втором году эксплуатации.
В практике Добыто мы закладываем пилотную группу до раскатки на всю компанию: одно подразделение проходит полный цикл от выдачи подписи до подписания и выгрузки архива. Ошибки настройки, которые на пилоте стоят нескольких дней, на полном контуре стоят месяца.
Важный нюанс из практики: учёт носителей нужно ставить до выдачи первого токена, а не после. Реестр с моделью и серийным номером, ФИО, датой выдачи, реквизитами сертификата и отметкой о возврате при увольнении избавляет от типовой ситуации, когда у уволившегося сотрудника остаётся действующий ключ, а компания узнаёт об этом при инвентаризации.
Лайфхак: при работе с большими файлами хэш считается программно, а на токене подписывается уже готовый хэш. Сама операция подписи на Рутокен ЭЦП 2.0 занимает около 0,3 секунды, так что время обработки пакета определяется хэшированием, а не носителем.
Когда серверная подпись не подходит
Есть сценарии, где централизованное хранение ключа либо не работает технически, либо не принимается второй стороной.
Сертификат руководителя организации выдаёт только удостоверяющий центр ФНС и доверенные лица, выдача первичная и личная, ключ записывается на токен без права копирования. Перевести эту подпись в облако нельзя: схема выдачи не предусматривает такого варианта. Отчётность через ЕГАИС требует ключей в формате PKCS#11 — производителям и поставщикам алкоголя другой формат не подойдёт. Нотариусы работают с максимально сертифицированным комплектом: сертифицированное СКЗИ с формуляром и сертифицированный ключевой носитель в обязательном порядке.
Отдельная история — терминальный доступ. Протокол RDP не умеет работать с токеном, который физически подключён к удалённой машине: устройство нужно пробрасывать с того компьютера, за которым сидит пользователь, а канал закрывать защищённым соединением. Схема, при которой токен воткнут в сервер в офисе, а сотрудник подключается к нему из дома и подписывает, разработчиками протокола не предусмотрена.
Наконец, офлайн. Смарт-карта с NFC подписывает документ в поле, в поезде и под землёй, без всякой сети; серверная схема в этот момент недоступна. Для выездных бригад, нарядов-допусков и актов приёма-передачи в рейсе это решающий довод.
Во что обходится ошибка выбора
Стоимость ошибки редко сводится к цене носителя. Ключ, выпущенный в режиме ФКН для парка машин с КриптоПро CSP 4.0, придётся перевыпускать целиком, потому что сменить режим у готового контейнера нельзя. Утрата токена означает не покупку нового, а обязанность уведомить удостоверяющий центр и отозвать сертификат; пользоваться сохранёнными копиями ключа после утраты запрещено, нужны новые ключи и новый сертификат. Документ, подписанный сертификатом, который на момент подписания уже был в списке отозванных, проверку не пройдёт. А подпись без штампа времени перестанет проверяться вместе с истечением срока действия сертификата, и восстановить её задним числом невозможно.
Мария Ж, судебный эксперт в сфере корпоративного и трудового права: «Штамп времени и ответ службы о статусе сертификата — это то, что превращает подпись в доказательство спустя годы. Сертификат службы штампов времени даёт срок действия ключа 3 года плюс 15 лет проверяемости, то есть максимум 18 лет. Для кадровых документов со сроком хранения полвека этого мало, и подпись приходится периодически переподписывать поверх, продлевая цепочку доказательств».
Стоимость КЭДО и электронных подписей для сотрудников
Итоговая сумма складывается из численности сотрудников, набора видов подписи и потребности в интеграции с учётной системой.
| Услуга | Стоимость | Сроки |
|---|---|---|
| Тариф «Старт»: до 25 сотрудников, ПЭП и УНЭП, базовые шаблоны | от 30 ₽ за сотрудника / мес | по запросу |
| Тариф «Бизнес»: без ограничения численности, ПЭП, УНЭП и УКЭП, электронный архив | от 50 ₽ за сотрудника / мес | по запросу |
| Минимальная оплата по тарифу «Бизнес» | 50 сотрудников за 30 000 ₽ в год | год |
| Тариф «Корпорация»: выделенный сервер, SLA 99.9%, API и кастомные интеграции | по запросу | рассчитывается индивидуально |
| Выпуск ПЭП и УНЭП для сотрудников | входит в тариф | по запросу |
| УКЭП для сотрудников | через партнёров-удостоверяющих центров | по запросу |
| Установка и настройка модуля для 1С:ЗУП | входит в тариф «Бизнес» | один день |
Электронные подписи ПЭП и УНЭП для сотрудников выпускаются на всех тарифах и отдельно не оплачиваются, поэтому сравнивать серверную схему с парком токенов корректнее по совокупной стоимости: носитель, лицензия криптопровайдера и обслуживание рабочего места против абонентской платы за сотрудника. Актуальные условия по каждому тарифу и состав функций собраны на странице тарифов ДОБЫТО КЭДО.
Переход между тарифами возможен в любой момент, при повышении разница пересчитывается пропорционально оставшемуся периоду. Платформа соответствует требованиям 377-ФЗ, статей 22.1-22.3 ТК РФ и 152-ФЗ.
Выводы
Серверная и токенная схемы отличаются не уровнем законности, а местом хранения ключа и составом требований к рабочему месту. Закон 63-ФЗ не предписывает аппаратный носитель, он требует конфиденциальности ключа и запрета на его использование без согласия владельца, поэтому спор о железе на практике превращается в спор о регламенте доступа и учёте. Токен остаётся обязательным там, где приёмная сторона диктует средство подписи: сертификат руководителя из удостоверяющего центра ФНС, ЕГАИС, нотариат, работа в поле без сети. Серверная схема выигрывает на потоке однотипных документов и на людях, у которых нет администрируемого рабочего места.
Мы в Добыто закрываем именно вторую часть задачи: подписи ПЭП и УНЭП для сотрудников выпускаются внутри платформы, маршруты согласования и электронный архив настраиваются под структуру компании, а интеграция с 1С:ЗУП снимает двойной ввод. Токены при этом никуда не деваются: они остаются там, где без них действительно нельзя.
Частые вопросы
Можно ли передать токен другому сотруднику, чтобы он подписал документы?
Часть 1 статьи 10 63-ФЗ обязывает не допускать использование ключа без согласия владельца. Формально закон не запрещает передачу ключа с согласия, но ответственность за подписанный документ остаётся на владельце сертификата: считается, что подписал именно он. Практика «директор отдал токен помощнику» юридически отличается от бумажной доверенности, где представитель ставит собственную подпись и отвечает сам. Если полномочия нужно передать по-настоящему, выпускается сертификат на физическое лицо и оформляется машиночитаемая доверенность.
Работает ли токен через RDP и терминальную сессию?
Протокол RDP не предусматривает работу с токеном или смарт-картой, подключёнными к удалённой машине: это ограничение заложено разработчиками протокола ради безопасности. Носитель нужно пробрасывать в терминальную сессию с того компьютера, за которым находится пользователь, а сам канал закрывать защищённым соединением, желательно сертифицированным средством. Схема с токеном, постоянно воткнутым в сервер, и подключением извне не поддерживается.
Что делать, если забыт ПИН-код токена или пароль контейнера?
ПИН-код пользователя разблокируется через панель управления носителя с помощью ПИН-кода администратора: соответствующая вкладка есть в утилите производителя. Если утрачены оба кода, остаётся форматирование носителя, а вместе с ним теряются и ключи, поэтому сертификат придётся перевыпускать. Если токен потерян или есть подозрение на компрометацию, порядок другой: уведомить удостоверяющий центр, отозвать сертификат и выпустить новые ключи. Пользоваться сохранёнными копиями ключа после утраты нельзя.
Сколько сертификатов помещается на один токен?
На носителе со 128 КБ защищённой памяти помещается до 31 ключевого контейнера в формате КриптоПро CSP. Фактическая вместимость зависит от того, что удостоверяющий центр записал в сертификат: контейнер без дополнительных цепочек может занимать порядка 200 байт, а контейнер с полной цепочкой и расширениями — до 12 КБ. Для оценки сверху считайте, что таких «тяжёлых» контейнеров на токен войдёт около десяти.
Как проверить машиночитаемую доверенность, полученную вместе с документом?
У доверенности есть 36-символьный идентификатор. Полные сведения на сервисе ФНС открываются при знании трёх параметров: номера доверенности, ИНН доверителя и СНИЛС доверенного лица. По ним видны статус доверенности, данные сторон и перечень полномочий. Автоматическая проверка полномочий пока ограничена: часть полномочий указывается текстом, а из неформализованного PDF-договора информационная система условия вроде лимита суммы не извлечёт.
Нужен ли нотариус для машиночитаемой доверенности на сотрудника филиала?
По Гражданскому кодексу передоверие требует нотариального удостоверения всегда, кроме двух случаев: доверенность от юридического лица в адрес другого юридического лица и цепочка через руководителя обособленного филиала. Внутренние передоверия между работниками одной организации или одного филиала удостоверяются нотариально, и машиночитаемая доверенность здесь исключением не является. Классификатор полномочий предусматривает ограничение прав по филиалам, так что разграничить полномочия внутри структуры можно и без цепочки передоверий.
