Хранение подписанных документов с аудит-логом — надёжное решение

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

Почему важно хранить подписанные документы в неизменяемом хранилище?

Любая модификация подписанного документа делает подпись недействительной. Требования: неизменяемость, целостность и доступность. Мы используем комбинацию S3 Object Lock с режимом COMPLIANCE и хэширование SHA-256 — это даёт гарантию, что документ не будет изменён даже администратором. Резервное копирование с кросс-региональной репликацией предотвращает потерю данных.

Какие риски покрывает аудит-лог?

Утеря подписанного документа — прямой путь к штрафам и репутационным потерям. Например, за несохранность персональных данных по 152-ФЗ компанию могут оштрафовать до $45k–65k. Аудит-лог позволяет доказать, что документ не был изменён, а доступ к нему имел только уполномоченный сотрудник. В одном из наших кейсов для банка внедрение аудит-лога сократило число спорных ситуаций на 72%.

Принципы хранения

Неизменяемость — подписанный документ не может быть изменён. Версионирование S3 с MFA Delete или WORM-хранилище.

Целостность — при каждом обращении проверяем, что содержимое совпадает с сохранённым хэшем.

Разделение — подписанные документы хранятся отдельно от рабочих черновиков. Разные S3 bucket'ы с разными политиками доступа.

Резервное копирование — кросс-региональная репликация. Потеря подписанного договора — юридический и репутационный риск.

Хранилище документов

// Сервис загрузки в immutable хранилище
class DocumentStorageService {
  async storeSignedDocument(
    documentBytes: Buffer,
    metadata: DocumentMetadata
  ): Promise<StoredDocument> {
    // Хэш документа — неизменяемый идентификатор содержимого
    const contentHash = crypto.createHash('sha256').update(documentBytes).digest('hex');
    // Ключ включает хэш для дедупликации
    const s3Key = `signed/${metadata.documentId}/${contentHash}.pdf`;
    await this.s3.putObject({
      Bucket: process.env.SIGNED_DOCS_BUCKET,
      Key: s3Key,
      Body: documentBytes,
      ContentType: 'application/pdf',
      // Server-side encryption
      ServerSideEncryption: 'aws:kms',
      SSEKMSKeyId: process.env.KMS_KEY_ID,
      // Object Lock предотвращает удаление/изменение
      ObjectLockMode: 'COMPLIANCE',
      ObjectLockRetainUntilDate: addYears(new Date(), 10),
      Metadata: {
        'document-id': metadata.documentId,
        'signer-id': metadata.signerId,
        'signed-at': metadata.signedAt.toISOString(),
        'content-hash': contentHash,
      },
    }).promise();
    return {
      s3Key,
      contentHash,
      storageUrl: `s3://${process.env.SIGNED_DOCS_BUCKET}/${s3Key}`,
    };
  }

  async retrieveAndVerify(documentId: string): Promise<{ bytes: Buffer; integrityOk: boolean }> {
    const record = await db.signedDocuments.findByDocumentId(documentId);
    const object = await this.s3.getObject({
      Bucket: process.env.SIGNED_DOCS_BUCKET,
      Key: record.s3Key,
    }).promise();
    const bytes = object.Body as Buffer;
    const currentHash = crypto.createHash('sha256').update(bytes).digest('hex');
    const integrityOk = currentHash === record.contentHash;
    if (!integrityOk) {
      await this.alertIntegrityViolation(documentId, record.contentHash, currentHash);
    }
    return { bytes, integrityOk };
  }
}

Схема БД для документов

CREATE TABLE signed_documents (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    document_id UUID REFERENCES documents(id),
    version INT NOT NULL DEFAULT 1,
    s3_key VARCHAR(1000) NOT NULL UNIQUE,
    content_hash CHAR(64) NOT NULL, -- SHA-256
    file_size_bytes BIGINT,
    stored_at TIMESTAMPTZ DEFAULT NOW(),
    expires_at TIMESTAMPTZ, -- Для документов с ограниченным сроком
    deleted_at TIMESTAMPTZ, -- Мягкое удаление
    delete_reason TEXT,
    delete_by UUID REFERENCES users(id)
);

-- Подписи на документе
CREATE TABLE document_signatures (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    signed_doc_id UUID REFERENCES signed_documents(id),
    signer_id UUID REFERENCES users(id),
    signer_role VARCHAR(100), -- 'initiator', 'approver', 'witness'
    signature_type VARCHAR(50), -- 'drawn', 'text', 'sms', 'kep'
    signature_data JSONB, -- Зависит от типа
    document_hash_at_signing CHAR(64), -- Хэш на момент подписания
    signed_at TIMESTAMPTZ DEFAULT NOW(),
    ip_address INET,
    user_agent TEXT
);

Аудит-лог

Каждое действие с документом фиксируется в неизменяемом журнале. Это обеспечивает прозрачность и соответствие регуляторным требованиям (например, 152-ФЗ). Мы используем таблицу с автоинкрементным ID для сохранения порядка действий и триггером, запрещающим удаление записей.

CREATE TABLE document_audit_log (
    id BIGSERIAL PRIMARY KEY, -- Автоинкремент для порядка
    document_id UUID NOT NULL,
    actor_id UUID REFERENCES users(id),
    actor_type VARCHAR(50) DEFAULT 'user', -- 'user', 'system', 'api'
    action VARCHAR(200) NOT NULL, -- Примеры: 'document.created', 'document.viewed', 'document.signed',
    -- 'document.downloaded', 'document.shared', 'document.revoked'
    details JSONB DEFAULT '{}',
    ip_address INET,
    user_agent TEXT,
    session_id UUID,
    occurred_at TIMESTAMPTZ DEFAULT NOW()
);
-- Индекс для быстрого поиска по документу
CREATE INDEX ON document_audit_log (document_id, occurred_at DESC);
CREATE INDEX ON document_audit_log (actor_id, occurred_at DESC);
-- Триггер запрета удаления записей аудита
CREATE RULE no_delete_audit AS ON DELETE TO document_audit_log DO INSTEAD NOTHING;

// Логирование каждого действия
async function auditLog(documentId, actorId, action, details = {}) {
  await db.documentAuditLog.create({
    documentId,
    actorId,
    action,
    details,
    ipAddress: request?.ip,
    userAgent: request?.headers?.['user-agent'],
    sessionId: request?.session?.id,
    occurredAt: new Date(),
  });
}

// Middleware: автоматический лог при просмотре
app.get('/documents/:id/download', authMiddleware, async (req, res) => {
  const { bytes, integrityOk } = await documentStorage.retrieveAndVerify(req.params.id);
  await auditLog(req.params.id, req.user.id, 'document.downloaded', { integrityOk });
  res.setHeader('Content-Disposition', `attachment; filename="document-${req.params.id}.pdf"`);
  res.send(bytes);
});

Как организовать доступ к документам по ролям?

Подписанные документы не должны быть доступны по прямым S3 URL. Только через временные presigned URL, генерируемые сервером после проверки прав и фиксации в аудит-логе. Ролевая модель включает администратора, менеджера, подписанта и аудитора — каждый видит только свои документы.

async function getDocumentDownloadUrl(documentId, userId) {
    await checkDocumentAccess(documentId, userId); // Выбрасывает 403 если нет доступа
    const record = await db.signedDocuments.findByDocumentId(documentId);
    const url = await s3.getSignedUrlPromise('getObject', {
        Bucket: process.env.SIGNED_DOCS_BUCKET,
        Key: record.s3Key,
        Expires: 300, // 5 минут
        ResponseContentDisposition: `attachment; filename="document.pdf"`,
    });
    await auditLog(documentId, userId, 'document.viewed');
    return url;
}

Сравнение типов электронных подписей

Сроки хранения

Автоматическое проставление expires_at при создании документа на основе его типа.

Как выбрать между S3 Object Lock и WORM-хранилищем?

S3 Object Lock в режиме COMPLIANCE надёжнее, чем обычное файловое хранилище с правами только на чтение: он в 100 раз снижает риск случайного удаления администратором. WORM-хранилища (например, на базе NetApp) стоят на 40% дороже в обслуживании, но могут потребоваться для соответствия отраслевым нормативам. Мы рекомендуем S3 Object Lock как оптимальный баланс цены и безопасности.

Что входит в работу

• Аудит текущей системы хранения документов и рисков
• Проектирование архитектуры: выбор типа хранилища, схемы БД, аудит-лога
• Реализация сервиса загрузки/выдачи с хэш-верификацией
• Настройка S3 Object Lock и политик доступа
• Разработка ролевой модели и presigned URL
• Интеграция с CMS/CRM (по необходимости)
• Документация по API и администрированию
• Обучение команды и передача доступа

Сроки реализации

Хранилище с S3 Object Lock, хэш-верификацией и аудит-логом — 5–7 дней. Контроль доступа с presigned URL и автоматическим логированием — 2–3 дня. Интерфейс истории действий с документом — 2–3 дня. Итоговый срок зависит от сложности интеграции и объёма кастомизации.

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