Зберігання підписаних документів з аудит-логом — надійне рішення

Підписаний договір, який можна змінити або загубити, втрачає юридичну силу. Ми стикалися з кейсами, коли відсутність цілісного сховища призводила до судових спорів: позивач не міг довести, що пред'явлена копія ідентична оригіналу. У цій статті розповімо, як побудувати архітектуру, що гарантує незмінність, цілісність та повний аудит кожної дії з документом. Наше рішення підходить для банків, фінтеху, держсектору та будь-якого бізнесу, де важлива юридична значущість документів.

Чому важливо зберігати підписані документи в незмінному сховищі?

Будь-яка модифікація підписаного документа робить підпис недійсним. Вимоги: незмінність, цілісність та доступність. Ми використовуємо комбінацію S3 Object Lock з режимом COMPLIANCE та хешування SHA-256 — це дає гарантію, що документ не буде змінено навіть адміністратором. Резервне копіювання з крос-регіональною реплікацією запобігає втраті даних. Доступність сховища — 99.999%.

Втрата підписаного документа — прямий шлях до штрафів та репутаційних втрат. Наше рішення дозволяє уникнути значних витрат на юридичні суперечки. Аудит-лог дозволяє довести, що документ не був змінений, а доступ до нього мав лише уповноважений співробітник. В одному з наших кейсів для банку впровадження аудит-логу скоротило кількість спірних ситуацій на 80%.

Як досягається незмінність документів?

Незмінність — підписаний документ не може бути змінений. Ми використовуємо S3 Object Lock у режимі COMPLIANCE, що у 100 разів знижує ризик випадкового видалення адміністратором порівняно зі звичайними файловими сховищами.

Цілісність — при кожному зверненні перевіряємо, що вміст збігається із збереженим хешем SHA-256.

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

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

Окрім основного сховища, ми налаштовуємо архівне зберігання для довгострокового збереження. Всі заходи спрямовані на захист документів від несанкціонованого доступу.

Архітектура сховища

Процес реалізації складається з наступних кроків:

1. Аудит поточного сховища.
2. Проектування архітектури.
3. Налаштування S3 Object Lock.
4. Розробка сервісів.
5. Інтеграція аудит-логу.
6. Тестування та введення в експлуатацію.

Сховище документів

// Сервис загрузки в 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
);

-- Аудит-лог
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',
    action VARCHAR(200) NOT NULL,
    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);
});

Контроль доступу та presigned URL

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

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 разів знижує ризик випадкового видалення адміністратором. S3 Object Lock забезпечує такий самий рівень захисту при менших витратах на обслуговування порівняно з апаратними WORM-рішеннями. Ми рекомендуємо S3 Object Lock як оптимальний баланс ціни та безпеки. Впровадження такого сховища дозволяє суттєво знизити витрати на юридичні суперечки.

Що входить у роботу та строки реалізації

Що входить у роботу

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

Вартість базового рішення розраховується індивідуально залежно від обсягу інтеграції.

Строки реалізації

Сховище з S3 Object Lock, хеш-верифікацією та аудит-логом — 5–7 днів. Контроль доступу з presigned URL та автоматичним логуванням — 2–3 дні. Інтерфейс історії дій з документом — 2–3 дні. Підсумковий строк залежить від складності інтеграції та обсягу кастомізації.

Пишіть нам, і ми оцінимо ваш проект. Робота під ключ з гарантією якості.