В условиях тотальной цифровизации делового оборота подготовка электронных документов к архивному хранению перестает быть чисто технической процедурой и становится стратегически важным бизнес-процессом. От качества этой подготовки зависят юридическая сила документов, скорость поиска информации, соблюдение требований законодательства (в РФ — 476-ФЗ, 149-ФЗ, ГОСТ Р 7.0.100-2018) и, в конечном счете, историческая память организации.
Главная цель проекта, организовать в электронном виде весь жизненный цикл документа: от создания до передачи его в архив. До цифровизации большинство документов подписывалось вручную и хранилось на бумаге, что создавало огромные массивы неструктурированных данных. Современный подход требует системности на каждом этапе.
Нормативно-правовая база и стандарты
Прежде чем приступать к практическим действиям, необходимо определить регуляторную среду. В Российской Федерации ключевыми документами являются:
- Федеральный закон от № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 9 — требования к информационным системам хранения);
- Федеральный закон от № 476-ФЗ «Об архивном деле в Российской Федерации» (регламентирует порядок формирования, учета и хранения архивных документов).
- ГОСТ Р 7.0.100-2018 «Система стандартов по информации, библиотечному и издательскому делу. Архивное дело. Электронные архивные документы. Общие требования к формированию, составу, параметрам и порядку передачи в архив».
- ГОСТ Р 7.0.99-2018 «Метаданные электронных архивных документов. Общие требования».
- Приказ Минкультуры России от № 2768 (утверждает типовые составы и значения метаданных).
Важно: Несоблюдение требований ГОСТ Р 7.0.100-2018 при передаче документов в государственный архив является основанием для отказа в приеме фондов.
Этапы подготовки: От теории к практике
Процесс подготовки можно разделить на пять последовательных этапов. Пропуск любого из них ведет к рискам потери юридической значимости или невозможности долгосрочного хранения.
Этап 1: Инвентаризация и классификация (Аудит)
Нельзя подготовить то, что не учтено. На этом этапе проводится:
- Выявление всех источников: ECM-системы, файловые серверы, почтовые серверы, облачные хранилища, локальные диски сотрудников.
- Классификация по срокам хранения: Временные (до 10 лет), Долговременные (более 10 лет), Постоянные (бессрочно). Основание — Номенклатура дел организации, утвержденная экспертной комиссией.
- Оценка юридической значимости: Наличие усиленной/неусиленной квалифицированной электронной подписи (КЭП/НЭП), печатных форм, нотариальных заверений.
Этап 2: Проверка целостности и аутентичности
Это критический момент. Неправильная подготовка документов к архивному хранению становится одной из самых недооцененных проблем бизнеса, которая проявляется именно здесь.
- Верификация ЭП: Проверка действительности сертификатов ключей проверки ЭП на момент подписания (а не на момент проверки!). Необходимо сохранять цепочки доверия (CRL, OCSP) или использовать штампы времени (RFC 3161).
- Контрольные суммы (Хеши): Расчет хеш-сумм (ГОСТ Р 34;11-2012 / Streebog-256/512) для каждого файла и фиксация их в реестре/манифесте. Это гарантирует неизменность бинарного содержимого.
- Проверка форматов: Соответствие файлов допустимым форматам архивного хранения (см. Этап 3).
Этап 3: Нормализация форматов (Миграция в архивные форматы)
Собственные форматы (proprietary formats) — враг долгосрочного хранения. ГОСТ Р 7.0.100-2018 и международная практика (OAIS, Library of Congress) диктуют использование открытых, документированных, широко поддерживаемых форматов:
| Тип документа | Рекомендуемый архивный формат | Недопустимо / Рискованно |
|---|---|---|
| Текстовые документы | PDF/A-2b или PDF/A-3b (ISO 19005) | .docx, .rtf, .odt (зависят от ПО-рендерера) |
| Таблицы | CSV (UTF-8) с описанием структуры (XSD/JSON Schema) или PDF/A | .xlsx, .ods (сложная внутренняя структура, макросы) |
| Растровые изображения | TIFF (Baseline 6.0, сжатие CCITT Group 4 / LZW) или JPEG 2000 (JP2) | .jpg (потери качества), .png (не всегда поддерживается в старых системах), .bmp (объем) |
| Векторная графика / Чертёжи | PDF/A-2u или SVG | .dwg, .cdr, .ai (проприетарные) |
| Email-сообщения | EML (RFC 5322) или MBOX с вложениями в нативных форматах | .msg (формат Outlook), .pst |
| Базы данных / Реестры | SIARD 2.0 (ISO 16363) или CSV/XML + XSD | .mdb, .accdb, .dbf, бинарные дампы БД |
| Видео/Аудио | FFV1 (видео в контейнере Matroska/MKV), FLAC (аудио) | Проприетарные кодеки (H.264 в MP4 допустим, но менее предпочителен для вечного хранения) |
Правило: Конвертация должна быть верифицируемой. Исходный файл (native format) рекомендуется хранить рядом с архивной копией (в пакете PDF/A-3 можно вложить исходник как EmbeddedFile).
Этап 4: Формирование метаданных (Описание контекста)
Документ без контекста — бесполезный набор бит. Метаданные по ГОСТ Р 7.0.99-2018 делятся на группы:
- Идентифицирующие: Уникальный идентификатор (UUID), шифр дела, регистрационный номер, дата документа.
- Контекстные: Автор, исполнитель, организация-создатель, вид документа (договор, акт, приказ), тема/аннотация.
- Технические: Формат файла (MIME-type), размер в байтах, хеш-сумма (алгоритм + значение), кодировка, версия ПО, создавшего файл.
- Правовые: Срок хранения, категория доступа (Гриф доступа: ДСП, Коммерческая тайна, Открытый), основание хранения (статья номенклатуры), наличие ЭП (данные сертификата).
- Связи: Ссылки на родительский дело, на приложения, на исходящие/входящие связанные документы.
Метаданные упаковываються в XML-манифест (схема часто задается архивом-приемщиком или соответствует профилю METS/PREMIS).
Этап 5: Упаковка в Архивный Информационный Пакет (АИП / AIP) /SIP_Root
|-- manifest.xml (Основной манифест METS/MODS/PREMIS)
|-- metadata/
| |-- descriptive.xml (Описательные метаданные)
| |-- preservation.xml (Метаданные сохранности: хеши, форматы, среда)
| |-- rights.xml (Правовые метаданные)
|-- content/
| |-- case_001/
| | |-- doc_001.pdf (PDF/A-2b)
| | |-- doc_001.xml (Метаданные конкретного документа)
| | |-- attachments/
| |-- case_002/
|-- signatures/ (Открепленные подписи .sig, если не встроены в PDF/A)
|-- logs/
|-- verification_report.pdf (Отчет о верификации ЭП и хешей)
|-- conversion_log.xml (Лог миграции форматов)
Ключевые проблемы и риски (Lessons Learned)
Проблема 1: «Мертвые» электронные подписи
/SIP_Root
|-- manifest.xml (Основной манифест METS/MODS/PREMIS)
|-- metadata/
| |-- descriptive.xml (Описательные метаданные)
| |-- preservation.xml (Метаданные сохранности: хеши, форматы, среда)
| |-- rights.xml (Правовые метаданные)
|-- content/
| |-- case_001/
| | |-- doc_001.pdf (PDF/A-2b)
| | |-- doc_001.xml (Метаданные конкретного документа)
| | |-- attachments/
| |-- case_002/
|-- signatures/ (Открепленные подписи .sig, если не встроены в PDF/A)
|-- logs/
|-- verification_report.pdf (Отчет о верификации ЭП и хешей)
|-- conversion_log.xml (Лог миграции форматов)
Срок действия сертификата КЭП истек, УЦ лицензии не имеет, списки отзыва (CRL) недоступны.
Решение: Использование штампов времени (Time Stamping Authority — TSA) на момент подписания. Внедрение политики Long-Term Validation (LTV) — внедрение в PDF/A всех данных для проверки (OCSP/CRL/сертификаты) в момент создания архивной копии.
Проблема 2: Потеря связей между документами
В ECM-системе документ привязан к процессу, задаче, карточке контрагента. При выгрузке «плоскими» файлами контекст теряется.
Решение: Обязательное сохранение идентификаторов связей (ParentID, ProcessID, EntityID) в метаданных пакета. Использование стандарта CIDOC CRM или RiC (Records in Contexts) для моделирования связей.
Проблема 3: Объемные данные (Big Data / BIM / Видео)
Архивирование терабайт видеонаблюдения или BIM-моделей строительных объектов стандартными методами неэффективно.
Решение: Выделение «горячего» и «холодного» контуровов. Для холодного — ленточные библиотеки (LTO-9/10) с LTFS, объектные хранилища (S3 API) с политиками Immutable Object Lock (WORM). Использование специализированных форматов (IFC для BIM, FFV1 для видео).
Проблема 4: Человеческий фактор и «Теневое IT»
Сотрудники хранят финальные версии договоров в личных чатах Telegram, WhatsApp, на Google Drive или в личной почте.
Решение: Внедрение DLP-систем, обучение, удобные интерфейсы «Одной кнопки» для отправки в архив (интеграция в почтовый клиент, Explorer, мобильное приложение). Автоматический захват входящей/исходящей почты на уровне MTA (Mail Transfer Agent).
Технологический стек: Инструменты автоматизации
Ручная подготовка тысяч документов невозможна. Необходим программный комплекс (модуль ЭА — Электронный Архив), реализующий:
- Коннекторы к источникам: API 1С, Directum, Docsvision, 1С:Документооборот, SharePoint, Exchange, PostgreSQL/Oracle (прямой доступ к БД).
- Модуль валидации форматов: veraPDF (валидация PDF/A), DROID (идентификация форматов по PRONOM), JHOVE (TIFF, JPEG2000, WAV, XML).
- Модуль конвертации: LibreOffice Headless / ONLYOFFICE Document Builder (Office -> PDF/A), Ghostscript (PS/EPS -> PDF/A), ImageMagick (Растр -> TIFF/JP2), FFmpeg (Видео -> FFV1/MKV).
- Модуль криптографии: КриптоПро CSP / VipNet CSP / OpenSSL (GOST) для верификации ЭП, расчета хешей (Streebog), формирования LTV-пакетов.
- Модуль упаковки (SIP Creator): Генерация XML по схемам METS/PREMIS/ГОСТ Р 7.0.99, создание package-level хеш-манифестов (bagit.txt / manifest-sha256.txt).
- Интерфейс передачи: S3 API, SFTP, WebDAV, физическая передача на LTO-картриджах (с протоколом передачи).
Взаимодействие с архивом-приемщиком (Протокол передачи)
Передача — это не «сбросил на флешку и ушел». Это формализованная процедура:
- Предварительное согласование: Согласование профиля метаданных (XSD-схемы), набора форматов, структуры пакета, алгоритмов хеширования с архивом (государственным или корпоративным).
- Тестовая передача (Pilot SIP): Передача небольшой выборки (1-5 дел) для прогона через валидатор архива.
- Акт приема-передачи: Документ, фиксирующий передачу прав ответственности за сохранность. Подписывается руководителем организации и главой архива (на бумаге или двусторонней КЭП).
- Инвентарная опись: В электронном виде (XML/PDF/A) и на бумаге (для гос. архивов) — перечень передаваемых дел с указанием шифров, сроков, грифов.
- Контрольная проверка (Fixity Check): Архив пересчитывает хеш-суммы принятых файлов и сверяет с манифестом. Протокол сверки подписывается обеими сторонами.
Чек-лист готовности к архивированию (Definition of Done)
Документ (или дело) считается готовым к передаче в архив, если:
- [ ] Наличие утвержденной Номенклатуры дел с экспертными сроками хранения.
- [ ] Документ завершен (нет статусов «Проект», «На согласовании», есть дата регистрации/исполнения).
- [ ] Верифицирована ЭП (действительна на момент подписания, цепочка доверия полная, есть LTV/штамп времени).
- [ ] Файл сконвертирован в архивный формат (PDF/A-2b, TIFF, CSV, SIARD и т.д.) и пройден валидатор (veraPDF = PASS).
- [ ] Исходный (native) файл сохранен (внутри PDF/A-3 или отдельно в пакете).
- [ ] Рассчитаны и зафиксированы хеш-суммы (Streebog-256/512) для всех файлов.
- [ ] Заполнен полный комплект метаданных по профилю архива (ГОСТ Р 7.0.99).
- [ ] Упакован в SIP-пакет со структурой METS/BagIt.
- [ ] Пройдена внутренняя верификация пакета (скрипт проверки хешей, схемы XML, наличия файлов).
- [ ] Составлен и подписан Акт приема-передачи и Инвентарная опись.
Подготовка электронных документов в архив — это не разовое действие, а непрерывный процесс Digital Preservation (Цифрового сохранения). Организации, которые закладывают требования архивности (Authenticity, Integrity, Reliability, Usability) на этапе создания документа (By Design), экономят колоссальные ресурсы на этапе передачи в архив.
Инвестиции в автоматизацию валидации форматов, верификацию ЭП с LTV-поддержкой и генерацию стандартных SIP-пакетов (METS/PREMIS/BagIt) окупаются за счет исключения рисков отказа архива в приеме фондов, потери юридической силы документов и штрафов за нарушение законодательства об архивном деле. Помните: архив начинается не в хранилище, а на рабочем столе сотрудника, создающего документ.