Подписанный договор, который можно изменить или потерять, теряет юридическую силу. Мы сталкивались с кейсами, когда отсутствие целостного хранилища приводило к судебным спорам: истец не мог доказать, что представленная копия идентична оригиналу. В этой статье расскажем, как построить архитектуру, гарантирующую неизменяемость, целостность и полный аудит каждого действия с документом. Наше решение подходит для банков, финтеха, госсектора и любого бизнеса, где важна юридическая значимость документов.
Почему важно хранить подписанные документы в неизменяемом хранилище?
Любая модификация подписанного документа делает подпись недействительной. Требования: неизменяемость, целостность и доступность. Мы используем комбинацию 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; } Сравнение типов электронных подписей
| Тип подписи | Уровень безопасности | Юридическая значимость | Стоимость внедрения |
|---|---|---|---|
| Простая (логин/пароль, SMS) | Низкий | Минимальная | Низкая |
| Усиленная неквалифицированная | Средний | Для внутреннего документооборота | Средняя |
| Усиленная квалифицированная | Высокий | Полная юридическая сила | Высокая |
Сроки хранения
| Тип документа | Срок хранения | Основание |
|---|---|---|
| Договоры купли-продажи | 10 лет | ГК РФ |
| Трудовые договоры | 50 лет | ФЗ-125 |
| Кадровые документы | 75 лет | Архивное законодательство |
| Согласия на обработку ПД | 3 года после отзыва | 152-ФЗ |
Автоматическое проставление 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 дня. Итоговый срок зависит от сложности интеграции и объёма кастомизации.
Свяжитесь с нами для оценки вашего проекта — мы поможем спроектировать защищённое хранилище под ваши требования. Закажите разработку и получите гарантию юридической значимости документов.