Lotus notes как настроить подпись – ЭЦП Эксперт – ЭЦП Эксперт

Семейство программных продуктов IBM Lotus Notes и Domino представляет собой программное обеспечение для совместной работы, которое помогает пользователям эффективно создавать информационные ресурсы, находить информацию и обмениваться ею, а также быстро принимать решения и оптимизировать работу [1] .

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

IBM Lotus является документоориентированной платформой, а Lotus Domino – сервер документоориентированных баз данных (и не только), что и определяет их предпочтительное применение для решения задач электронного документооборота по сравнению с реляционными СУБД [2].

Можно сказать, что Lotus Notes является объектной СУБД с архитектурой клиент-сервер. Серверная часть имеет имя собственное Lotus Domino. Клиентская часть не имеет отдельного имени. Помимо работы с сервером, она может работать как настольная СУБД.

IBM Lotus Domino Server – сервер приложений системы Lotus Notes, является основой инфраструктуры для совместной работы сотрудников предприятия и платформой для приложений, реализующих разнообразные бизнес-функции. Предоставляет целый ряд сервисов и может использоваться для построения корпоративных систем электронного документооборота, коллективной работы, других приложений (каталоги, картотеки, справочники, любые хранилища информации, Интернет-приложения и др.). Имеет в своем составе большой набор модулей. Из основных это – сервер баз данных, почтовый сервер, http сервер, сервер каталогов. Набор модулей может быть расширен решениями от IBM и других сторонних производителей.

Lotus Domino работает под управлением различных серверных операционных систем, включая Windows, Linux, Solaris, AIX.

Линейка IBM Lotus Domino включает следующие основные программные продукты: сервер приложений Lotus Domino, стандартный клиент Lotus Notes, рабочее место администратора Lotus Domino Administrator (позволяющее удобно управлять сервером Lotus Domino), рабочее место разработчика Lotus Domino Designer (служащее для создания приложений).

Электронный документооборот, системы документооборота, организация документооборота

• основная сфера применения Lotus. Документооборот – это приложения со сложной логикой (ветвистые маршруты документов, множество различных состояний документа, утверждение и отклонение и т.д.), документы движутся от одного пользователя к другому, отслеживается статус, рассылаются уведомления.

Создание системы электронного документооборота на платформе Lotus Notes/Domino, дает возможность использовать сразу все основные компоненты, которые объединяет в себе уникальная технология Domino: средства электронной почты; документоориентированные базы данных; средства разработки приложений; систему репликации баз данных; средства защиты информации; средства календарного планирования; Internet/intranet, web-технологии; средства интеграции с приложениями сторонних разработчиков.

Фактически, в повседневном делопроизводстве при реализации электронного документооборота приходится решать три задачи:

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

Lotus Domino, обеспечивающий хранение серверной базы данных документов Lotus Notes, имеет развитые встроенные механизмы защиты, которые включают в себя: список управления доступом к базе данных; защиту форм, видов и документов; защиту разделов и полей; локальное шифрование базы данных.

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

Для хранения и обработки смешанной информации поддерживается специальный тип поля: Rich text. Описание структуры каждого документа запоминается вместе с его данными, и это позволяет как программно разбирать его содержимое; так и, по мере необходимости, менять структуру для создаваемых документов, не затрагивая уже существующие. Для связи по сети Lotus Notes/Domino использует собственный неопубликованный протокол Notes RPC (Notes Remote Procedure Call), не имеющий отношения ни к SQL, ни к ODBC.

Имеющиеся в системе документы необходимо защищать от подделок и несанкционированного просмотра (хищения информации) как при хранении на диске, так и при передаче через сеть [2,3]. Для защиты от подделки информация должна сопровождаться цифровой (электронной) подписью, удостоверяющей ее подлинность, а для защиты от несанкционированного просмотра информация должна шифроваться. Причем, могут шифроваться:

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

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

Открытый (или публичный) ключ помещается в учётную запись пользователя в Публичной Адресной Книге на закладке «Certificates/Notes certificates». Публичный ключ используется другими пользователями, чтобы:

• шифровать отправляемую данному пользователю почту;
• проверять, пришедшие от данного пользователя данные на подлинность.

Закрытый (или приватный) ключ записывается в специальный ID-файл, принадлежащий данному пользователю. Закрытый ключ используется:

для расшифровки входящей почты;

для цифровой подписи исходящих данных.

Под исходящими/пришедшими данными имеется в виду не только почта, но вообще любые документы из любых баз, элементы дизайна баз, в том числе программы на языке LotusScript и т.д. Хотя открытый и закрытый ключи связаны между собой определенной взаимооднозначной зависимостью, гарантируется, что вычисление закрытого ключа по известному открытому будет

очень трудоёмким. Это означает, что:

• имея доступ к открытому ключу, расшифровать предназначенные другому пользователю данные практически невозможно, даже если эти данные были зашифрованы вами самим;
• имея возможность проверить чужую цифровую подпись, её невозможно воспроизвести, то есть подделать.

Такие шифросистемы принято называть несимметричными, или системами с открытым ключем. В Notes используется популярная шифросистема RSA.

RSA в широком смысле – это не название конкретного шифра (т.е. пары чисел), а название алгоритма, позволяющего генерировать шифры. Каждый полученный шифр записывается в очередной ID-файл (USER.ID).

ID-файл используется для решения задач защиты базы данных. Каждый сервер или пользователь Notes имеет свой уникальный ID – ассоциированный с сервером или пользователем

уникальный файл. ID-файл идентифицирует своего владельца, как паспорт идентифицирует.гражданина.

ID-файл создает сертификатор (certifier) – лицо, имеющее специальный ID-файл – так называемый ID-файл сертификатора. ID-файл сертификатора необходим только для сертификации ID-файлов пользователей и серверов. ID-файл сертификатора можно рассматривать как “печать- инструмент”, с помощью которого сертификатор “ставит печать-оттиск” в ID-файл пользователя, т.е. добавляет в него сертификат.

При создании в ID-файл включаются:

• имя владельца ID (оно может быть изменено сертификатором в дальнейшем),
• тип и номер лицензии Notes,
• сертификат (“печать-оттиск”), обеспечивающий серверу возможность аутентифицировать пользователя (устанавливать его подлинность), а станции пользователя в свою очередь аутентифицировать сервер. Когда пользователь впервые в сеансе работы пробует открыть базу данных на сервере, сервер использует ID-файл этого пользователя, чтобы убедиться, имеет ли пользователь и этот сервер сертификат от одного и того же сертификатора. Если да, то доступ разрешается; если нет, доступ отклоняется. Дополнительно на решение вопроса о предоставлении доступа могут повлиять взаимные сертификаты (но они хранятся не в ID-файлах, а в адресных книгах) и настройки в документе Server из общей адресной книги,
• публичный ключ, используемый при шифровании почты и обеспечении “электронной подписи”. Его копия заносится также в общую адресную книгу и становится доступной другим пользователям домена,
• личный (закрытый) ключ, используемый при шифровании почты и обеспечении “электронной подписи”. Он имеется только в ID-файле пользователя. Невозможно извлечь личный ключ из ID-файла или создать новый ID-файл с таким же личным ключом,
• пароль, применяемый для предотвращения неавторизованного доступа к базам на серверах с использованием этого ID-файла.

После создания ID-файла в нем может быть:

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

ID-файл используется для идентификации и аутентификации пользователя, а для авторизации пользователя (проверки его прав на работу с документами) используется список управления доступом – Access Control List (ACL).

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

Список управления доступом (ACL) к базе данных является основным элементом управления доступом в Notes. Все остальные элементы управления доступом просто усиливают ограничения ACL. Сервер Domino выполняет проверку прав доступа, когда получает от клиентов Notes запросы на доступ к расположенным под его управлением базам. Domino читает из базы ACL, определяет уровень доступа для данного пользователя, и в зависимости от уровня обрабатывает запрос либо отказывает в его выполнении. Список прав доступа к базе выводится в специальном окне, вызываемом из главного меню или контекстного меню базы.

ACL делится на четыре части: Basics (Основные параметры), Roles (Роли), Log (Регистрация) и Advanced (Дополнительно).

Центральный элемент вкладки Basics – список пользователей. Можно выбрать любого пользователя в списке, и остальные поля покажут его права доступа.

Роли – это именованные носители прав доступа, которые упрощают администрирование БД и которые хранятся в ACL.

Роли используются для указания прав доступа к формам, документам и оглавлениям наравне с обычными группами и именами пользователей из Адресной Книги. Роли вправе создавать, переименовывать и удалять лишь администраторы (уровень Manager). Это делается на вкладке Roles диалогового окна Access Control List. Однако на практике разработчики тоже создают роли, когда имеют доступ администратора к базе данных. Имя роли может включать до 15 символов и содержать пробелы, символы верхнего и нижнего регистров и числа. Notes автоматически заключает имя роли в квадратные скобки. Существующие роли отображаются в квадратных скобках. Имя роли в любом поле или в формуле следует писать в скобках.

После создания роли ее имя (заключенное в квадратные скобки) появляется в списке Roles (Роли) на вкладке Basics диалогового окна Access Control List. Чтобы назначить роль пользователю (или снять назначение), необходимо отметить пользователя в списке и затем щелкнуть по имени роли, устанавливая или снимая флажок у этого имени.

Роли в каталоге Domino

В то время как большинство ролей полезны только для администраторов и разработчиков, некоторые роли, такие как [CreateResource] в базе данных Resource Reservation, представляют интерес для администраторов Domino. Наиболее важны роли, появляющиеся в каталоге Domino. Всего существует восемь ролей, разбитых по парам. Пользователи, которым назначены перечисленные ниже роли, могут создавать и изменять определенные документы:

Log (Журнал) – в нем хранятся дата и время всех изменений, внесенных в список ACL базы данных, а также идентифицируются пользователи, которые производили изменения, и основные свойства этих изменений.

Вкладка Advanced содержит несколько инструментов, которые позволяют дополнительно защитить доступ к базе данных. Эти инструменты определяются полями для назначения административного сервера, установки защиты базы данных, определения максимального уровня доступа через Internet и массового обновления поля User type (Тип пользователя).

Защита форм, видов и документов.

Для клиентских форм имеются свои списки доступов, которые формируются разработчиком форм. Формы могут иметь два различных списка доступа: Default read access for documents created with this form (Доступ «только чтение» для документов, созданных с помощью данной формы) и Who can create document with this form (Кто может создавать документы с помощью этой формы). Оба списка доступны разработчику форм в окне Form Properties (Свойства формы) на вкладке Security.

Когда разработчик устанавливает в поле Default read access for documents created with this form значение ниже All readers and above, программа Domino Designer создает внутри формы поле, называемое SReaders. Это поле типа Names (Имена), содержащее имена людей, серверов и групп, которые отмечены в поле Default read access. Все документы, созданные с помощью данной формы, будут наследовать указанное поле и его параметры. Окончательные документы смогут читать только те пользователи, которые указаны здесь и в любом поле документа с типом данных Author или Reader.

Если разработчик задает поле Who can create document with this form, то форма становится недоступной для пользователей, не указанных в данном поле. Таким способом каталог Domino ограничивает права создания документов людям, которым назначены различные роли класса Creator, – используются только роли, присутствующие в поле Who can create соответствующей формы.

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

Защита разделов и полей.

Разработчики в состоянии ограничивать доступ на редактирование отдельных разделов документа. Раздел – это определенная часть формы или документа, созданного с помощью такой формы. Любой, кому разрешено читать документ, вправе читать все разделы. Но если ограничена возможность редактирования, то изменить определенный раздел способны только те пользователи, которые перечислены в списке редакторов данного раздела. Можно ограничить доступ к отдельным полям документа, и/или шифруя эти поля (используя ключи шифрования из ID-файла).

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

Если поле зашифровано открытым ключом, то расшифровать его сумеет только владелец соответствующего закрытого ключа. Поле, зашифрованное секретным ключом, в состоянии расшифровать только пользователь, располагающий копией этого ключа. Различные поля документа допустимо шифровать различными ключами. Но один ключ шифрования позволяет дешифровать все поля. Хотя любой автор или редактор в состоянии зашифровать любое поле по своему усмотрению, чаще поля шифруются автоматически, поскольку так было задано разработчиком базы данных. В этом случае разработчик или администратор базы данных создает ключи шифрования во время проектирования. Затем, когда база данных вводится в эксплуатацию, разработчик должен передать ключ шифрования администратору, который в свою очередь распространяет ключи среди пользователей. Эти ключи хранятся в ID-файле каждого пользователя.

Шифрование локальной базы данных.

В отличие от полей, в локальной базе данных шифруется все ее содержимое. База данных шифруется с помощью ключа, который в свою очередь шифруется открытым ключом отдельного пользователя или сервера (в зависимости от расположения базы). Чтобы получить доступ к этой базе из Notes, необходимо войти в систему с помощью идентификатора пользователя или сервера, который сможет расшифровать ключ. Для блокирования доступа к зашифрованной локальной базе данных не из Notes, необходимо использовать среднее или стойкое шифрование, но не нестойкое.

Целью локального шифрования является предотвращение несанкционированного локального доступа к базе данных, размещенной на сервере или на рабочей станции. Опасность в случае с сервером заключается в том, что пользователь с помощью локальной копии Notes может обойти защиту ACL и получить административный доступ к базе данных, а в случае с рабочей станцией – доступ к базе данных для чтения. Он сумеет открыть ее, даже не зная пароля ни к одному ID-файлу системы Notes.

Для шифрования базы данных необходимо иметь административный доступ к ней. Обычно пользователи обладают таким доступом к базам данных на своих рабочих станциях, поэтому могут шифровать их самостоятельно с помощью собственных ID-файлов. Но если в локальной базе данных установлен согласованный список ACL, то пользователь должен попросить администратора базы данных зашифровать ее. Администратор переключается на свой ID-файл, а затем шифрует базу данных с помощью ID-файла пользователя, блокируя таким образом свой доступ к локальной реплике базы данных.

В последних версиях программных продуктов IBM Lotus Notes и Domino [4] механизмы защиты усилены и дополнены. Организация инфраструктуры документооборота с использованием механизмов защиты IBM Lotus Notes и Domino позволяет обеспечить безопасный и надежный электронный документооборот.

ЛИТЕРАТУРА

1. Ионцев Н..Н., Некрасов В.В. Почтовая система сервера Lotus Domino 6.5. – М.: ИнтерТраст, 2005.
2. Евсеев И. Lotus Notes 5.– М.: УЦВЦ, 2002.
3. Роб Кирклэнд. Domino 5 & 6 Администрирование сервера. – М.: ДМК Пресс, 2003
4. Некрасов В.В. Администрирование Lotus Domino 6.5. – М.: ИнтерТраст, 2004.
5. Официальный сайт Lotus: www.lotus.com