Построить СЭД без существенных надстроек типовой IT-инфраструктуры - ВОЗМОЖНО?

Владислав Воеводин
Независимый эксперт

Еще совсем недавно оживленно дискутировали о том, что такое электронный документ, возможно ли его использовать для информационного взаимодействия и как обеспечить юридическую силу электронных документов (ЭД). Сегодня электронный документооборот (ЭДО) не дань моде, не удел отдельных технологически продвинутых компаний, а насущная необходимость, вызванная потребностью бизнеса - оперативно, надежно и безопасно осуществлять информационное взаимодействие субъектов бизнеса между собой.

Сложившийся стереотип -практика делового оборота с использованием документов на бумажном носителе - стремительно меняется в направлении осуществления информационного взаимодействия с применением электронных документов. Приходит понимание необходимости использования электронных документов.

C позиций руководителя

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

Поэтому предлагаю встать на позиции руководителя, перед которым стоит задача выбора решения по построению эффективной СЭД.

Первое, что приходит в голову и подсказывает практика, это оценить существующие решения:

• присоединиться к одной из действующих СЭД;
• приобрести специализированное программное обеспечение и на его базе построить СЭД;
• построить СЭД своими силами;
• использовать возможности типовой IT-инфраструктуры и построить СЭД.

Первое решение с точки зрения затрат более выгодное. Однако необходимо учесть, что действующие системы ЭДО - корпоративные и "заточены" под соответствующий бизнес, хотя на практике такие прецеденты встречаются. Следует учесть, что сегодня на рынке нет независимых операторов ЭДО и, следовательно, найти независимого оператора СЭД практически невозможно. Плюсом этого решения является то, что нет необходимости развертывать удостоверяющий центр (УЦ) и обеспечивать функционирование инфраструктуры открытых ключей, получать необходимые лицензии - довольно хлопотное мероприятие.

Второе решение потребует приобретения коробочного программного продукта (на рынке таковые имеются), который позволит решить частную задачу подготовки, учета, передачи/приема ЭД. Но для решения задачи полноценного ЭДО потребуется разработка нормативной базы ЭДО, сложность которой часто недооценивается. Кроме того, необходимо будет развернуть свой УЦ либо воспользоваться услугами стороннего УЦ.

Третье решение предполагает разработку специального программного средства своими силами или силами внешнего разработчика. Для этого нужно будет получить соответствующие лицензии для работы с криптографией. Кроме того, потребуется разработка нормативной базы ЭДО, а также решение проблемы с УЦ. Плюсом является потенциальная возможность построить СЭД, более тонко удовлетворяющую требованиям бизнеса, а также оперативно осуществлять ее адаптацию при их изменениях. Однако это решение требует значительных разовых затрат на разработку и периодических на сопровождение.

Четвертое решение потребует произвести оценку возможностей типовой IT-инфраструктуры. Под типовой инфраструктурой IT будем понимать стандартный набор офисных программных средств, которые широко предлагаются на рынке. Также потребуется решение проблемы с УЦ.

Введем ограничение: при выборе любого из приведенных решений обязательно нужно будет приобрести средства криптографической защиты информации (СКЗИ), которые в состав базовой IT-конфигурации не входят.

Необходимо учесть, что каждое из решений имеет свои плюсы и минусы, которые в зависимости от требований бизнеса проявляются в различном сочетании.

Таким образом, из очень обобщеного анализа потенциальных решений можно сделать вывод, что наименее затратным может быть четвертый вариант.

Определение требований к функционалу СЭД

Возникает вопрос, а достаточно ли функциональных возможностей стандартного набора офисных программ для обеспечения ЭДО?

Допустим, что мы приняли принцип разработки "сверху вниз" и бизнес сформулировал требования к СЭД, которые обобщены на рис. 1.

Можно утверждать, что для обеспечения юридически значимого ЭДО необходимо выполнить следующие условия:

• представление документа в электронном виде не запрещено законом или иными нормативно-правовыми актами;
• электронное сообщение должно быть подписано электронно-цифровой подписью (ЭЦП);
• обмен электронными сообщениями, каждое из которых подписано ЭЦП, должен осуществляться в порядке, установленном федеральными законами, иными нормативными правовыми актами или соглашением сторон.

Примем данные утверждения как обязательные требования к СЭД.

Кроме того, сформулируем и примем основополагающий принцип при построении СЭД: "СЭД не должна зависеть от логики бизнес-приложений". Другими словами, СЭД взаимодействует с бизнес-приложениями только и только через соответствующий интерфейс, а внутренняя структура и логика бизнес-приложения скрыты для СЭД, также как для бизнес приложения скрыта структура и логика СЭД.

Возникает справедливый вопрос: возможно ли построение СЭД в поле типовой IT-инфра-структуры?

Под типовой IT-инфраструк-турой будем понимать базовый набор офисных программ, которые могут выполнять функции по работе с электронно-цифровой подписью (ЭЦП) и шифрования (расшифрования):

• текстовый редактор;
• редактор электронных таблиц;
• почтовая программа и др.

Примем, что СЭД строится на фундаменте сетевого и нижележащих уровней, которые развернуты и оказывают услуги транспортному уровню требуемого качества.

Для решения задачи разобьем ее на две частные подзадачи (рис. 2):

• обеспечение обмена ЭД на транспортном уровне (требования к обмену - обеспечить конфиденциальность и неотказуемость отправки/получения ЭД, учет ЭД);
• обеспечение обработки на представительском уровне (требования к обмену - обеспечить контроль целостности ЭД, доказательство авторства ЭД, защитить само сообщение от подделки, проверить (опционально) соответствие формата ЭД).

Определим, каким функционалом должна обладать типовая IT-инфраструктура, чтобы обеспечить решение следующих задач:

• шифрование (расшифрование) ЭД при их транспортировке (конфиденциальность);
• автоматическое формирование и отправка уведомления о доставке ЭД получателю (неотказуемость от отправки/получения ЭД);
• подписание электронного сообщения ЭЦП отправителя и проверка ее получателем (контроль целостности, авторство, защита от подделки; этот функционал можно реализовать как на представительском, так и на транспортном уровнях);
• автоматическая проверка соответствия формата ЭД (опционально);
• формирование уведомлений о доставке и об обработке ЭД.

Анализ функционала офисных приложений показывает, что:

1. Реализовать транспортный протокол обмена ЭД (рис. 2) можно с помощью почтовых программ, которые, как правило, обеспечивают учет почтовых сообщений, подписание файлов ЭЦП, шифрование при передаче и обратное преобразование на приеме. Имеются почтовые программы, которые работают через Web-интерфейс. На рынке представлены почтовые программы с данным функционалом.
2. Реализовать представительский протокол (обработку ЭД) (рис. 2) позволяют офисные приложения, поддерживающие функционал текстовых редакторов, электронных таблиц, управления базами данных, которые, как правило, обеспечивают шифрование, подписание ЭЦП, проверку форматов. Сегодня на рынке представлены офисные программные средства, которые обеспечивают данный функционал.

Какой же вывод? Строго говоря, построить СЭД (в соответствии с требованиями, обозначенными на рис. 1) в рамках только типовой IT-инфраструктуры не представляется возможным, хотя все условия для этого есть. Почему? Нужно создать инфраструктуру УЦ либо воспользоваться услугами стороннего. Отметим, что на рынке сегодня присутствуют УЦ, которые предлагают эти услуги.

Создание УЦ

Эта задача носит относительно самостоятельный характер.

Существуют ли решения, которые можно реализовать в рамках типовой IT-инфраструктуры? Да!

На рынке присутствуют решения для корпоративного варианта центра сертификации для небольших предприятий, использующих типовые средства криптографической защиты информации. Они обеспечивают централизованную генерацию ключей и сертификатов или выдают сертификаты по запросам PKCS#10. Они не требуют развертывания отдельного серверного оборудования и не накладывают явного ограничения на количество пользователей.

Функциональность этих УЦ обеспечивает реализацию основных функций центра сертификации (ЦС):

• генерацию ключа ЦС;
• выдачу корневого сертификата ЦС;
• централизованную генерацию ключей пользователей;
• централизованную выдачу сертификатов пользователей;
• выдачу сертификатов пользователей по запросу PKCS#10;
• отзыв сертификатов с формированием СОС;
• просмотр и распечатку выданных сертификатов и СОС;
• протоколирование событий и ошибок.

Кроме того, в состав поставки может входить так называемый "Клиент" со следующим функционалом:

• генерация ключей пользователей на рабочем месте;
• формирование запросов PKCS#10 на выдачу сертификатов пользователей;
• просмотр и распечатка запросов, сертификатов и СОС;
• протоколирование событий и ошибок.

Если же в состав инфраструктуры входит серверное оборудование и соответствующие программные средства, то для развертывания центра сертификации все есть. Весьма полезным является функционал почтового сервера, с помощью которого можно реализовать доступ к его ресурсам через Web-интерфейс. При этом в СЭД нужно иметь только один почтовый сервер, развернутый на стороне организатора СЭД, а на стороне клиента - Интернет-обозреватель и СКЗИ.

Таким образом, минимизировать затраты по развертыванию СЭД можно путем надстроек типовой IT-инфраструк-туры.

Допустим, что мы приобрели и развернули надстройку (СКЗИ и УЦ). Можно ли считать задачу решенной? Скорее всего, нет. По оценкам, это не более 20% от всей работы, остальные 80% лежат в поле организационном, и основные "грабли" именно на этом поле.

Конечно, если число участников будет значительным и заключать договоры об ЭДО по схеме "каждый с каждым" будет весьма затратным делом, то потребуется организатор СЭД. Именно с ним заключают участники СЭД договор об ЭДО. Организатор СЭД устанавливает правила игры, а участники СЭД должны будут к ним присоединиться. Организатор разрабатывает правила обмена ЭДО - транспортный уровень (рис. 2), регламент обработки ЭД - представительский уровень (рис. 2), развертывает и эксплуатирует, например, почтовый сервер для совместной работы, обеспечивает управление сертификатами. Однако это тема для отдельной публикации.