Электронная подпись на своём сервере: что законно

MAATRIX

Дисклеймер сразу: это обзорный технический материал, а не юридическая консультация. Автор — не юрист, конкретные требования к видам подписи и порядок их применения нужно сверять с действующим законодательством и, в спорных случаях, с практикующим юристом. Дальше — общая логика, которая полезна разработчику, чтобы не наступить на грабли «мы сделали криптографию сами и назвали это квалифицированной подписью». Если вы разворачиваете сервис на своём VPS и в очередной задаче в трекере написано «добавить подпись документов» — вопрос быстро упирается не в код, а в то, какая подпись вообще нужна. Технически подписать PDF хешем и приватным ключом можно за вечер. Юридически это может не значить вообще ничего — или значить ровно столько, на сколько вы договорились с другой стороной. Разберём, где граница.

Зачем вообще разбираться в видах подписи, а не просто писать код

Соблазн разработчика — воспринять «электронную подпись» как чисто техническую задачу: взять приватный ключ, посчитать хеш документа, приложить подпись. С точки зрения криптографии всё будет работать: подпись верифицируется, документ не подделаешь незаметно. Проблема в том, что юридическая значимость подписи — это не свойство алгоритма, а свойство того, кто и как этот алгоритм признал.

Разные страны регулируют электронную подпись по-разному, но общая логика похожая: закон выделяет несколько уровней подписи с разной юридической силой, и чем выше уровень — тем строже требования к тому, кто и чем эту подпись создаёт. Для российского законодательства (без привязки к точным номерам статей и формулировкам — это то, что стоит свериться отдельно) логика выглядит так: чем ближе подпись к «равнозначна собственноручной по умолчанию», тем меньше в этом остаётся места для самодельной реализации.

Практический вывод для разработчика простой: прежде чем писать код, нужно понять — вы делаете внутренний инструмент подтверждения действий или подписываете документы, которые будут иметь юридические последствия вовне (договор, акт, отчётность, доверенность). Это разные задачи с разными техническими решениями, и путать их — источник как минимум разочарования, а как максимум — юридических проблем у ваших пользователей.

Простая электронная подпись: что это в общей логике закона

Самый нижний уровень — простая электронная подпись (ПЭП). По общей логике регулирования, ПЭП — это когда факт подписания подтверждается кодом, паролем или иным простым идентификатором, который показывает, что действие совершил конкретный человек. Классический пример — код из СМС, который подтверждает согласие с условиями, вход в личный кабинет по логину и паролю, или галочка «я согласен» вместе с фиксацией IP и времени.

Ключевая особенность простой подписи — её юридическая сила не возникает автоматически. По общей логике закона, чтобы простая подпись имела значение (например, чтобы можно было ссылаться на неё в споре), между сторонами обычно должно быть отдельное соглашение о том, что они признают такой способ подписания равнозначным собственноручному — и описывают, как именно эта подпись формируется и проверяется. Это соглашение может быть частью пользовательского соглашения сервиса, отдельного договора или оферты.

Это как раз тот уровень, где разработчик может действовать самостоятельно:

• SMS-код, привязанный к конкретному действию (акцепт договора, подтверждение заявки).
• Подтверждение через личный кабинет с логином/паролем и MFA.
• Клик по ссылке из письма с уникальным токеном, привязанным к конкретному документу.
• Штамп времени, IP, user-agent и хеш документа, зафиксированные в момент подтверждения.

Минимальная схема на своём сервере может выглядеть так — таблица с фактом подтверждения:

CREATE TABLE document_signatures (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  document_id UUID NOT NULL REFERENCES documents(id),
  user_id UUID NOT NULL REFERENCES users(id),
  document_hash TEXT NOT NULL,       -- sha256 документа на момент подписания
  confirmation_method TEXT NOT NULL, -- 'sms_code', 'email_link', 'session_password'
  confirmation_value TEXT,           -- обезличенный след подтверждения, не сам код
  ip_address INET NOT NULL,
  user_agent TEXT,
  signed_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Это рабочая техническая реализация ПЭП. Но она становится юридически значимой не потому, что вы посчитали хеш, а потому, что в пользовательском соглашении явно написано что-то вроде «стороны признают простую электронную подпись, формируемую путём ввода кода из SMS/подтверждения через личный кабинет, равнозначной собственноручной подписи». Без этого пункта у вас просто есть лог действий пользователя — полезный технически, но не «подпись» в юридическом смысле.

Усиленная неквалифицированная подпись: промежуточный уровень

Между простой и квалифицированной подписью в общей логике закона обычно выделяется усиленная неквалифицированная электронная подпись (НЭП). Она построена на криптографии — использует пару ключей и позволяет однозначно определить подписанта и обнаружить изменения документа после подписания. В этом смысле она технически сложнее ПЭП и ближе к тому, что интуитивно ожидает разработчик от «настоящей» электронной подписи.

Важное отличие от квалифицированной подписи — сертификат ключа проверки для НЭП не обязательно должен быть выдан аккредitованным удостоверяющим центром. Его в некоторых сценариях можно создать и использовать самостоятельно (например, через собственный удостоверяющий центр внутри организации) или получить у неаккредитованного центра. Но, как и с простой подписью, по общей логике закона юридическая сила НЭП обычно тоже требует соглашения сторон о её признании — она не приравнивается к собственноручной подписи автоматически без такой договорённости, за исключением случаев, прямо предусмотренных законом или соглашением сторон.

Это уровень, где технически реализуемо на своём сервере (генерация ключевой пары, подпись хеша документа, проверка), но подойдёт он для сценариев внутри контролируемого периметра — между вашей компанией и её сотрудниками, между вами и контрагентом, с которым заключено рамочное соглашение о признании такой подписи. Для внешних юридически значимых документов без предварительной договорённости она работает хуже.

Усиленная квалифицированная подпись: почему её нельзя сделать самому

Верхний уровень — усиленная квалифицированная электронная подпись (УКЭП, часто говорят просто «квалифицированная подпись» или КЭП). Это тот случай, ради которого стоит писать весь этот материал: по общей логике закона, УКЭП имеет юридическую силу, равную собственноручной подписи, по умолчанию, без необходимости заключать отдельное соглашение сторон. Именно поэтому её используют для отчётности в госорганы, участия в госзакупках, юридически значимого документооборота между организациями.

Но именно поэтому требования к ней максимально жёсткие, и здесь пролегает граница, которую нельзя перешагнуть самостоятельной реализацией:

• Ключ подписи и сертификат выдаёт аккредитованный удостоверяющий центр — организация, прошедшая государственную аккредитацию и включённая в соответствующий реестр.
• Средства создания и проверки подписи должны быть сертифицированы уполномоченным органом — это не любая криптографическая библиотека, а конкретный сертифицированный криптопровайдер.
• Сертификат ключа проверки подписи содержит подтверждённые данные о владельце — физическом или юридическом лице, — и эта проверка личности выполняется удостоверяющим центром, а не вашим сервисом.

Из этого следует практический и не подлежащий обходу вывод: вы не можете развернуть свою криптографию на своём сервере, назвать результат «квалифицированной подписью» и получить ту же юридическую силу. Даже если алгоритм подписи технически безупречен (та же математика, тот же уровень защиты), отсутствие аккредитации удостоверяющего центра и сертификации средств означает, что подпись не будет иметь статуса УКЭП, а собственноручная сила документу не присвоится автоматически. Это не вопрос качества кода — это вопрос институционального признания, которое находится вне зоны того, что можно «просто написать».

Что это значит для архитектуры сервиса: где проходит граница

Практический вывод для разработчика — на этапе проектирования сразу разделить документы на две категории и не пытаться закрыть обе одним и тем же техническим решением.

Если ваш сервис работает с первыми двумя строками таблицы — самостоятельная реализация на своём сервере технически и юридически применима, при условии, что в пользовательском соглашении явно прописано признание такой подписи сторонами. Если речь о нижних строках — правильная архитектура выглядит как интеграция с API аккредитованного удостоверяющего центра, а не как попытка «сделать так же, но своими силами».

Практически это означает отдельный модуль в вашем бэкенде, который умеет:

POST /api/documents/{id}/sign-request
  -> обращение к API аккредитованного УЦ
  -> получение статуса подписания
  -> сохранение подписанного документа с меткой УЦ и сертификатом

Вы по-прежнему держите документы, базу, приложение на своём сервере — только сам акт подписания квалифицированной подписью делегируется внешнему аккредитованному провайдеру через его API. Это ничем не отличается от того, как вы делегируете, например, приём платежей платёжному шлюзу вместо того, чтобы самостоятельно писать процессинг банковских карт.

Практическая реализация простой ЭП на своём VPS

Если ваш сценарий — именно простая электронная подпись для внутренних документов или подтверждения действий пользователей, вот минимальный рабочий набор для развёртывания на своём сервере.

Базовые компоненты:

• База данных (PostgreSQL) для хранения документов, их хешей и записей о подтверждении.
• Хранилище исходных файлов документов (локальный диск с бэкапом или S3-совместимое хранилище).
• Модуль отправки SMS или email с кодом подтверждения.
• Модуль генерации PDF с визуальной отметкой о подписании (дата, ФИО, IP — не сама подпись, а её видимое отражение в документе).

Пример фиксации факта подписания с сохранением неизменности документа:

import hashlib
from datetime import datetime, timezone

def sign_document(document_bytes: bytes, user_id: str, confirmation_method: str, ip: str) -> dict:
    document_hash = hashlib.sha256(document_bytes).hexdigest()
    record = {
        "document_hash": document_hash,
        "user_id": user_id,
        "confirmation_method": confirmation_method,
        "ip_address": ip,
        "signed_at": datetime.now(timezone.utc).isoformat(),
    }
    # запись в document_signatures, документ после этого считается неизменным —
    # любое повторное подписание требует нового хеша и новой записи
    return record

Если вам нужен не самописный, а готовый инструмент для полноценного оборота документов с полями подписи, аудиторским следом и рассылкой подписантам — обратите внимание на готовые open-source платформы для самостоятельного развёртывания. Мы разбирали установку Documenso на VPS — это открытая альтернатива DocuSign с собственным Docker Compose-файлом, а также частые ошибки при её эксплуатации на сервере. Важно понимать: и Documenso, и любой другой self-hosted инструмент реализуют именно уровень простой или неквалифицированной подписи — сам факт, что инструмент готовый и решает 90% задач с интерфейсом, аудитом и рассылкой, не меняет того, что для юридического приравнивания к КЭП всё равно нужен аккредитованный удостоверяющий центр.

Частые вопросы