Подписанный договор, который можно изменить или потерять, теряет юридическую силу. Мы сталкивались с кейсами, когда отсутствие целостного хранилища приводило к судебным спорам: истец не мог доказать, что представленная копия идентична оригиналу. В этой статье расскажем, как построить архитектуру, гарантирующую неизменяемость, целостность и полный аудит каждого действия с документом. Наше решение подходит для банков, финтеха, госсектора и любого бизнеса, где важна юридическая значимость документов.
Почему важно хранить подписанные документы в неизменяемом хранилище?
Любая модификация подписанного документа делает подпись недействительной. Требования: неизменяемость, целостность и доступность. Мы используем комбинацию S3 Object Lock с режимом COMPLIANCE и хэширование SHA-256 — это даёт гарантию, что документ не будет изменён даже администратором. Резервное копирование с кросс-региональной репликацией предотвращает потерю данных.
Какие риски покрывает аудит-лог?
Утеря подписанного документа — прямой путь к штрафам и репутационным потерям. Например, за несохранность персональных данных по 152-ФЗ компанию могут оштрафовать до 5 млн рублей. Аудит-лог позволяет доказать, что документ не был изменён, а доступ к нему имел только уполномоченный сотрудник. В одном из наших кейсов для банка внедрение аудит-лога сократило число спорных ситуаций на 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 дня. Итоговый срок зависит от сложности интеграции и объёма кастомизации.
Свяжитесь с нами для оценки вашего проекта — мы поможем спроектировать защищённое хранилище под ваши требования. Закажите разработку и получите гарантию юридической значимости документов.