Распространение электронных документов в глобальных и локальных сетях с использованием клиент-серверной архитектуры

Даниленко А.Ю., Подрабинович А.А., Сургучев В.А., Хлюстов К.В.

В статье рассматривается программный комплекс по созданию и работе с электронными документами в локальных и глобальных сетях с использованием клиент-серверной архитектуры при наличии различных программ на клиентских рабочих местах, в том числе WEB–браузеров. Приводится схема и описание отдельных компонент для выполнения этой цели, а также методика защиты данных на сервере.

В связи с современным бурным развитием безбумажной технологии остро встает вопрос о развитии новых методов работы с электронными документами, которые позволяют эффективно хранить, просматривать, искать и модифицировать документы в глобальных и локальных сетях.

На рис.1 представлена схема программного комплекса для решения такой проблемы.

Приведем пояснения к данной схеме:

• 
  Рабочее место N – это клиентская программа, в которой создаются, просматриваются, ищутся и редактируются документы;
  
• 
  WEB-браузер N – это стандартное клиентское средство для просмотра данных через Интернет (например, MS Internet Explorer);
  
• 
  HTTP Сервер - служит для работы с системой через WEB-браузер;
  
• 
  Сервер приложений - служит для организации обработки всех видов запросов, приходящих в систему;
  
• 
  TCP/IP-библиотека - служит для связи рабочего места и HTTP сервера с Сервером приложений;
  
• 
  Сервер Системы - программный модуль, выполняющий команды, посылаемые с клиентских мест на добавление объекта, поиск, просмотр и пр., взаимодействует с Сервером приложений через COM-интерфейс;
  
• 
  Файлы документов – хранилище файлов, составляющих электронный документ;
  
• 
  СУБД – база данных для хранения информации о документах.
  

• 
  WEB-браузер – тонкий клиент, предпочтительно, MS Internet Explorer(IE);
  

• 
  Рабочее место – в данном комплексе это система электронного архива Евфрат (КЕ);
  

Рис.1

• 
  Сервер Системы – основан на базе данных НИКА (СЕ);
  
• 
  Сервер приложений – СП.
  

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

Модуль предоставляет следующую функциональность:

• 
  Хранение и работу с документами (создание, модификацию, удаление);
  
• 
  Создание и модификацию иерархической папочной структуры;
  
• 
  Создание реквизитов;
  
• 
  Поиск документов и папок;
  
• 
  Разграничение уровня доступа пользователей к папкам и документам;
  

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

• 
  Docs – имя директории, где хранятся файловые образы серверных документов;
  
• 
  Base – имя директории, где хранятся файлы БД.
  

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

1.1. Формат запроса

Определены следующие допустимые команды и параметры:

1.2. Формат ответа на запрос

В случае возникновения ошибки при обработке запроса буфер ответа содержит в качестве параметра ответа текстовое описание произошедшей ошибки.

1.3. Основные операции

1.3.1. Список объектов

Здесь Type> – символ, определяющий тип объекта;

F – папка,

D – документ,

Например:

• 
  F12345 Входящие\r\n – папка «Входящие» с идентификатором 12345;
  
• 
  D34567 Инструкция\r\n – документ «Инструкция» с идентификатором 34567.
  

1.3.2. Список реквизитов

Здесь ID> – текстовое представление идентификатора реквизита;

Например:

• 
  2 1 0 Все слова\r\n – реквизит с именем «Все слова», идентификатором 2, типом 1, флагом 0;
  

1.3.3. Создание документа

Создание (а также изменение редактируемого) документа происходит в несколько этапов.

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

2. 
   Клиент посылает запрос на создание документов, указывая имя директорий «Корневая директория» последовательно для всех создаваемых документов (например: Doc1\0Doc2\0. Здесь символ ‘\0’ означает конец строки).
   
3. 
   Сервер, выполняя скрипты, формирует аналогичную структуру каталога в своей директории для хранения файловых образов документов. При этом в качестве «Корневой директории» для созданного (изменённого) документа используется текстовое представление его идентификатора в серверной БД. Если создаваемый документ был взят на редактирование данным пользователем, то предварительно происходит удаление из базы всех его реквизитов, а также тех файловых образов, которые были исключены редактировавшим документ пользователем из его структуры, храняшейся в скрипт-файле.
   
4. 
   Сервер формирует ответ в виде списка созданных (изменённых) документов.
   

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

1.3.4. Создание папки

1.3.5. Запрос на поиск

Normalize=&Operation=&Field=&From=&

Здесь - текст, который может быть либо YES, либо NO;

0 – пресечение результатов;

1 – объединение результатов;

2 – вычитание результатов.

Результат выполнения запроса возвращается в виде списка найденных объектов. В список будут включены все объекты, уровень доступа к которым для пользователя будет не ниже ReadAccess. Если документ взят на редактирование пользователем с пометкой «закрыть от просмотра другими пользователями», то он не будет включён в список найденного.

1.3.6. Работа со словарём

Здесь - числовой идентификатор реквизита (DWORD);

Само слово может быть не заданно. В этом случае возвращается слов с начала словаря.

Результатом выполнения запроса является следующий буфер.

…

Здесь - количество полученных слов (DWORD);

1.3.7. Список групп доступа

• 
  FullAccess – полный доступ к реквизитам и файлам документа или к папке и её содержимому;
  
• 
  ReadAccess – доступ на чтение реквизитам и файлам документа или к папке и её содержимому;
  
• 
  FullRecvAccess – полный доступ к реквизитам документа или папки;
  
• 
  ReadRecvAccess – доступ на чтение к реквизитам документа или папки.
  

где задаёт группу доступа и является именем одного из перечисленных реквизитов. -- идентификатор группы пользователей или отдельного пользователя.

Все элементы и отделяются друг от друга пробелами. В конце списка для каждой группы идёт последовательность символов \r\n.

1.3.8. Содержимое папки

DOCUMENTS = 1 – возвращать документы;

FOLDERS = 2 – возвращать папки.

По умолчанию, если параметр не был передан, то будут выданы подобъекты всех типов. При этом у пользователя должен быть уровень доступа не ниже ReadAccess к папке. В список будут включены все подобъекты, уровень доступа к которым для пользователя будет также не ниже ReadAccess. Если документ взят на редактирование пользователем с пометкой «закрыть от просмотра другими пользователями», то он не будет включён в список содержимого.

1.3.9. Удаление объектов

• 
  Для документов
  
  • 
    Уровень доступа пользователя к документу равен FullAccess;
    
  • 
    Документ не был взят на редактирование другим пользователем;
    
• 
  Для папок
  
  • 
    Уровень доступа пользователя к папке и всем её подобъектам на любом уровне вложенности равен FullAccess;
    
  • 
    В папке на любом уровне вложенности не существует документов, взятых на редактирование другим пользователем.
    

1.3.10. Редактирование документа

• 
  2 – пометить документ как редактируемый;
  
• 
  3 – пометить документ как редактируемый и закрыть документ от просмотра для других пользователей.
  

1.3.11. Получение реквизитов документа

Где - строковое представление идентификатора реквизита, для которого возвращены значения;

2. Описание «Сервера приложений»

Сервер приложений выполняет следующие функции:

• 
  Управление базой данных пользователей и обеспечение механизмов регистрации пользователей и проверки их полномочий на выполнение различных функций системы;
  

• 
  Прием и отправку файлов по заказу Рабочих мест. Расположение и параметры каталогов, с которыми можно работать через СП задаются в файле конфигурации;
  
• 
  Хранение и управление наборами параметров сервисов (произвольный набор пар текстовых строк – имя, значение длиной до 255 символов);
  
• 
  Приём, организация очередей, передача заявок клиентов на исполнение внешними сервисами, а также передача результатов обработки клиентам.
  

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

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

После загрузки параметров база данных закрывается. Если параметры конфигурации принимаются сервером, основной поток запускает три служебных потока. Один ожидает соединения клиентов по TCP, второй обеспечивает передачу данных между СП и соединившимися клиентами, третий периодически отписывает в БД изменённые параметры конфигурации и учётные записи пользователей. Плюс ещё по одному потоку на каждый из активных сервисов – т.е. сервисов, которые являются OLE серверами. Далее служебные потоки выполняют всю функциональную часть работы СП, а основной поток обеспечивает работу интерфейсного элемента – иконки, через которую можно остановить СП.

Клиентская библиотека и СП, обмениваются пакетами данных через гарантированное TCP соединение. Максимальный размер пакета 8Кб, если требуется передать больше данных, то сетевая библиотека и СП разбивают их на серии связанный пакетов.

Заголовки всех пакетов имеют общую структуру, тело пакета определяется его типом и передаваемыми данными. При передаче по сети тело пакета шифруется (заголовок нет).

3. HTTP Сервер

• 
  работа в режиме стандартного http сервера, а именно, исполнение CGI программ и показ требуемых файлов в случае, если эти действия не должны делаться через СП;
  
• 
  в случае прихода команд, предназначенных для СП или Сервера Системы, передает их СП;
  
• 
  получает ответы от СП в согласованном виде, на основе которых создает html-страничку, предназначенную для отправки пользователю в качестве ответа на запрос;
  
• 
  если результат запроса большой, режет его на странички, заносит их во временную директорию и назначает им время жизни порядка получаса;
  
• 
  выполняет чистку временных страниц.
  

3.1. Общая организация выполнения команд

BOOL ExecCommand(const char *pCommand, const char *pParams, char **ppResultBuffer, char *cResultFile, CRequestSocket *pRS);

передаются название команды, ее параметры, указатель на указатель на результирующий буфер, указатель на буфер для имени файла в случае, если результатом выполнения команды будет файл (если в результате получится текст в буфете, вместо имени файла пишется тип данных в нем, например, .htm), а также указатель на объект класса CRequestSocket, из которого вызвана функция, для получения сопутствующей информации. Возвращаемое значение показывает, команда выполнена или требуется ее выполнение стандартными средствами.

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

3.2. Проверка доступности файла

void CheckDocFileForShow(CString &sUrl, CString &sArgs, DWORD *pdwAction, CRequestSocket *pRS)

Главной особенностью функционирования этой функции является то, что она для выдачи сообщения о недоступности файла перестраивает логику работы механизма формирования ответа на запрос. Дело в том, что от клиента пришел запрос на показ файла, что отражено в передаваемых функции параметрах sUrl – Url файла, sArgs – аргументы для команды – пустая строка, pdwAction – признак требуемого действия = 0. В случае если файл данному пользователю недоступен, все эти параметры меняются таким образом, чтобы была выполнена команда выдачи пользователю сообщения об ошибке ErrMess с параметрами, в которые входят само сообщение об ошибке и код сессии. При нормальном завершении работы в случае, если файл доступен, параметры не изменяются и показ файла происходит, как обычно.

Сама проверка доступности осуществляется следующим образом. В случае если требуемый файл – index.htm (заглавная страничка системы), он считается доступным. Если в имени файла нет имени одной из предопределенных виртуальных директорий (например, директории с документами или с результатами поиска), он считается чужим, не обслуживаемым нашей системой. В этом случае возможность показа определяется настройками системы. Далее из Url файла извлекаются идентификатор документа и код сессии пользователя, если он есть. По величине идентификатора определяется, является ли документ общедоступным и если это так, требуемый файл показывается. После этого по временной базе сервера делается проверка, не разрешался ли ранее показ данного документа этому пользователю, если разрешался, разрешается снова. Попутно при обращении к базе из нее извлекается информация о пользователе, а именно его идентификатор и список групп, в которые он входит. Только после этого запрашивается у СЕ через СП информация о правах доступа к требуемому документу, которая возвращается в виде списка идентификаторов пользователей и групп с различными правами. Из сравнения этого списка со списком групп пользователя и его идентификатором делается окончательный вывод о возможности показа файла.

3.3. Форматы принимаемых Url

Итак, адрес исходной странички: http://ServerName>.

Команды, предназначенные для исполнения сервером: http://ServerName>/commands/Command>, где - команда с параметрами. Проверка полномочий на исполнение команд делается по коду сессии, который является одним из параметров команд.

Запрос на просмотр файлов может быть двух видов:

Здесь DocId> - системный идентификатор документа, совпадающий с именем директории файловой системы, где лежат файлы документа, FileName> - имя файла, SesCode> - код сессии. Первая форма соответствует запросу от незарегистрированного пользователя, либо просмотру документа свободного доступа, поскольку никакие права доступа не проверяются. Вторая форма – запрос на показ документа с проверкой всех прав.

3.4.Настройки системы.

Все перечисленные настройки системы хранятся в ini-файле и периодически обновляются, настройки директорий хранятся, помимо этого, в файле конфигурации Сервера приложений.

Рис. 2

5. Рабочее место - «Клиентский Евфрат»

О

Для передачи информации о документе или каком-нибудь другом объекте с клиентского рабочего места на сервер была специально разработана методика описания свойств объекта в виде скрипта [2].

При нажатии на правую клавишу мыши на этой иконке появляется меню рис.3.




Рис. 3

Пункт "Настройки…"

Здесь находятся некоторые настройки программы, рис.4.




Рис. 4



Пункт "Статус"

Содержит подпункты "Подключиться…", "Отключиться"

Позволяет подключиться к серверу приложений (без которого нельзя работать с серверной базой).

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



Рис. 5

В этом диалоге можно перейти к другому серверу или изменить его имя путем нажатия на кнопку "Задать / Изменить сервер". На рис.6 изображен соответствующее окно.

Здесь можно настроиться на сервер приложения, указав либо URL, либо IP адрес, либо выбрать из списка существующих серверов. А также присвоить серверу приложений свое имя рис.7.

После подключение к серверу приложений можно работать с поиском и добавлением документов на сервер.

После выполнения этого пункта связь с сервером прекращается.

Диалог поиска аналогичный клиентскому Рабочему месту, см. рис.8.

Отличие составляет только то, что словарь загружается порциями, начиная с заданного слова, по нажатию на кнопку "Словарь".

На рис.9 показано окно для добавления документов на сервер.

В правой части окна располагаются документы, которые можно добавить на сервер. В левой части окна должны находиться объекты, которые добавляются на сервер. Добавлять можно как документы, так и папки, содержащие их. Так же можно задать права доступа к добавляемым объектам рис.10. По умолчанию все пользователи имеют право читать документ, а тот, кто добавляет на сервер, то имеет полный доступ к соответствующим документам.



Рис. 9




Рис. 10

5.2. Работа с серверными документами

При взятии документа на редактирование предоставляется возможность выбора – оставить его доступным для чтения другим пользователям системы (умолчательный, предпочтительный вариант) или полностью заблокировать доступ, что может понадобиться, если содержание документа неверно. Взятие документа на редактирование сопровождается его разметкой в серверной базе по системным реквизитам, в частности, "Идентификатор взявшего" идентификатором пользователя и выставлением первого бита в том случае, если документ блокируется. Это проверяется всякий раз при показе документа.

Если документ взят кем-то на редактирование, при попытке взять его выдается сообщение о том, что он взят с именем пользователя и временем взятия (освобождения).

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

6. Защита и безопасность системы

6.1. Защита данных при нормальном функционировании системы

С точки зрения http-сервера, существуют следующие уровни защиты (речь идет только о чтении документов и, возможно, реквизитов, поскольку отдача документов на редактирование – редкая операция, что делает допустимой долгую и тщательную проверку прав доступа, к тому же она должна делаться через СП):

• 
  Низший, для документов, доступных для всех чужих, когда никакие права доступа не проверяются. Это не означает, однако, что эти документы совсем общедоступны. Например, если система сконфигурирована так, что доступа к ней через Интернет нет (внутренняя интрасеть, сервер расположен на машине, недоступной извне), тут могут быть документы, фактически доступные для всех своих.
  
• 
  Высший, права доступа проверяются полностью через СП и СЕ.
  

http://ad/GetDoc//DOCS//Script.htm

где - код сессии, DocId> - идентификатор документа.

С точки зрения документа, уровни защиты следующие:

• 
  все чужие;
  
• 
  все свои;
  
• 
  заданы группы пользователей для чтения;
  
• 
  заданы конкретные пользователи для чтения;
  

Таким образом, для быстрой работы системы требуется, чтобы документов с первым уровнем защиты было очень много, со вторым – много, с третьим – мало, с четвертым – очень мало.

При формировании ответа на запрос для документов «Для всех чужих» формируются обычные ссылки на условное имя файла. Для всех остальных категорий (это определяет сервер по диапазонам идентификаторов) ссылки оформляются с подстановкой кода сессии. В случае, когда соответствующая html- страничка формируется на КЕ по данным, пришедшим напрямую от СП, код сессии подставляется КЕ перед открытием документа для просмотра.

Для ускорения работы, а также для обеспечения работы с оглавлением документа, ссылками внутри него, картинками, права доступа данного пользователя к данному документу проверяются один раз за сеанс работы и запоминаются средствами http-сервера

Для сохранения конфиденциальности информации о пользователях системы применяется шифрование параметров при входе и создании новых пользователей. С целью исключить использование зашифрованных пакетов данных, содержащих пароль, для входа в систему предполагается следующее. При отправке с сервера странички для входа в систему или других действий с паролем в нее вносится, как значение скрытого поля, длинный случайный текст. По этому тексту на сервере формируется с помощью Хэш-функции или другого алгоритма ключ для шифрования, и то, и другое запоминаются. Время жизни этой записи на сервере ограничено – примерно 1 минута, для особо удаленных пользователей – до 5 минут. На клиенте при перехвате отправки на сервер этот текст извлекается из параметров, опять формируется ключ, с помощью которого шифруются пароль и имя. Далее на сервере по первой записи извлекается запомненный ключ, происходит расшифровка. Сразу при получении значений из формы для входа ключ на сервере сбрасывается.

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

6.3. Защита от хакерских атак (некорректное функционирование системы)

1. 
   Отказ в обслуживании – невозможность дальнейшего функционирования системы;
   
2. 
   Похищение файлов и данных;
   
3. 
   Порча файлов и данных;
   
4. 
   Получение контроля над системой.
   

1. 
   Вести протоколы следующих действий: вход – выход пользователей, запись – скачка - удаление файлов, действия, рассматриваемые как хакерская атака. При этом список подозрительных действий должен быть отделен от всех прочих.
   
2. 
   Всем администраторам системы следует иметь помимо административного входа, используемого именно для администрирования системы, обычный вход для обычной работы.
   
3. 
   Вход администратора может быть (опционально) заблокирован в случае, если он происходит не из локальной сети, либо не с заранее оговоренного компьютера либо не с консоли сервера (что является гораздо более жестким ограничением). Можно каждый раз открывать с консоли возможность администрирования.
   
4. 
   При входе администратора в систему выдавать сообщение на консоль, заносить это в список подозрительных действий.
   
5. 
   Для исключения появления посторонних пользователей с большими правами вести независимый список пользователей, групп и их состава. Регулярно, примерно раз в сутки, проверять соответствие этого списка содержимому базы специальной утилитой.
   
6. 
   При получении команд, особенно административных, проверять их на наличие непредусмотренных параметров. Это должно восприниматься как нападение и отражаться в соответствующем протоколе с указанием пользователя.
   
7. 
   Особое внимание должно быть уделено функциям определения пути к файлу по его URL. Желательно, чтобы она была универсальна, на выходе из нее надо принудительно проверять наличие в отдаваемом пути директорий с документами или служебными файлами. Это позволит исключить проникновение через систему в чужие (не обслуживаемые нами) файлы.
   
8. 
   Ни в коем случае не должно быть доступно получение файла по обычному внутреннему пути – только по условным именам через функцию определения пути к файлу по его URL.
   
9. 
   Желательно размещать обслуживаемые и используемые нами файлы на отдельном логическом диске, при этом он должен быть закрыт на чтение всем пользователям локальной сети, кроме наших серверов.
   
10. 
    Для блокирования перегрузки серверов (http и СП) задавать числа допустимого количества одновременных соединений. При превышении первого из них следует выдавать сообщение о перегрузке сервера и закрывать соединение, при превышении второго – просто пропускать запрос на соединение. Величины этих параметров определяются логикой работы сотрудников организации Заказчика и возможностями серверного компьютера, выход за их пределы рассматривается как подозрительное действие, ведущее к отказу в обслуживании (хакерская атака путем перегрузки сервера и перевода его в некорректный режим работы).
    

Заключение

Представлен механизм публикации документов, созданных клиентскими приложениями, а также разработана структура хранения, просмотра, изменения и поиска документов на сервере.

Разработан собственный HTTP Сервер, который позволяет организовать портал электронных документов в Интернете, работать с документами через WEB-браузеры, а также заниматься удаленной настройкой всей системы.

Весь разработанный программный комплекс является очень гибкой системой и легко переписывается под различные требования, такие как изменения СУБД или переход к другому интерфейсу.

Литература

1.Даниленко А.Ю. Программный интерфейс электронного архива: возможности и принципы построения. //Методы и средства работы с документами: Сборник трудов Института системного анализа Российской академии наук. М.: Эдиториал УРСС, 200. С.167-172.