Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Безопасность Lotus Domino: заметки системному администратору

Евгений Поляков

Сервер Domino обеспечивает свои приложения многослойной системой безопасности. Наибольший уровень безопасности предоставляется при работе с сервером Domino через клиент Lotus Notes («толстый» клиент). ИБМ в этом случае говорит о семи уровнях безопасности:

  • Network (сеть) - данный уровень относится к возможности доступа к серверу по сети (физической возможности);
  • Authentication (аутентификация) - процесс установления "доверия" между сервером и тем, кто пытается обращаться к серверу;
  • Domino Server Security (безопасность на уровне сервера Domino) - Данный уровень относится к ограничениям, определяемым в серверном документе Server;
  • Database Access (ACL) (список управления доступом БД) - данный уровень относится к ограничениям, определяемым в списке управления доступом конкретной базе данных;
  • Design Element Security (безопасность на уровне элементов дизайна) - данный уровень относится к ограничениям, определяемым в списке управления данного элемента дизайна (т.е. кто может работать с этим элементом дизайна). Этот список позволяет ограничить доступ к объектам, базирующимся на конкретном элементе дизайна (например, кто может создавать документы по указанной форме);
  • Document Security (безопасность на уровне документа) - данный уровень относится к ограничениям, определяемым в полях типа Readers и Authors;
  • Field Security (безопасность на уровне полей) - данный уровень относится к шифрованию информации из полей с включенным свойством поддержки шифрования (Enable encryption).

Опуская уровень Network, про процедуру Authentication можно сказать, что она реализована как стандартная проверка сертификатов в их общей части.
На уровне Domino Server Security в документе Server определяется достаточно много параметров безопасности, начиная от определения групп пользователей, которым можно/нельзя работать с сервером, до пользователей – полных администраторов сервера, которые могут работать с базами данных сервера, миную все четыре последующих уровня безопасности.

Database Access (ACL) определяется независимо для каждой базы Lotus Domino и предоставляет семь основных уровней доступа:
  • Manager (управляющий) – пользователь/группа пользователей, которые имеют доступ на изменение ко всей информации базы данных, могут менять ACL базы данных, параметры репликации и локального шифрования;
  • Designer (разработчик) - пользователь/группа пользователей, которые имеют доступ на изменение ко всей информации базы данных (документы с данными и элементы дизайна);
  • Editor (редактор) - пользователь/группа пользователей, которые имеют доступ на изменение к любым документам с данными;
  • Author (автор) - пользователь/группа пользователей, которому разрешено создавать и модифицировать документы, созданные им самим;
  • Reader (читатель) - пользователь/группа пользователей, которому разрешено читать документы в базе данных;
  • Depositor (корреспондент) - пользователь/группа пользователей, которому разрешено создавать документы, но который не «видит» даже «свои» (исключая, возможно, «общедоступные» - Public ) документы;
  • No access (нет доступа) - пользователь/группа пользователей, который не имеет доступа к БД, исключая «общедоступные» документы и элементы дизайна.

В рамках каждого из перечисленных уровней есть дополнительные параметры доступа (например, кто может создавать личные папки, агентов и т.д.).

В рамках уровня Document Security используются два типа полей:
  • Authors (поле типа Авторы). Предназначено для ограничения доступа к документам, содержащим такие поля. Используется совместно с ACL БД. Само поле может содержать список значений имен, групп пользователей и серверов, а так же ролей, определенных в ACL текущей БД. Данный тип полей влияет только на доступ к информации на уровне Author (автора) согласно ACL БД. Если пользователь имеет доступ к БД на уровне Author, но в документе нет ни одного поля типа Authors, то такой пользователь не сможет редактировать документы даже те, которые он сам создал. Если же поле типа Authors присутствует в документе, то модифицировать данный документ могут только те пользователи, которые имеют уровень доступа Author к БД в ее ACL, и, имя которых входит в поле Authors явно, на уровне группы, или назначено на соответствующую роль;
  • Readers (поле типа Читатели). Предназначено для ограничения доступа к документам, содержащим такие поля. Используется совместно с ACL БД. Документы, содержащие такие поля, будут не доступны тем пользователям, имена которых не присутствуют в полях Readers и/или в Authors (явно или в виде групп и ролей), и/или явно не определены в Default read access for documents created with this form (доступ на чтение к документам, созданным по данной форме) на закладке Security свойств текущей формы.

На уровне Field Security шифрование информации из назначенных полей может осуществляться как по алгоритмам симметричного, так и несимметричного шифрования.

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

При работе с сервером Domino через браузер процедура Authentication выполняется не так как в клиенте Lotus Notes. При работе с Domino через Web может использоваться Authentication на уровне имя/пароль, либо с применением механизма x.509 сертификатов. В последнем случае уровень безопасности значительно повышается, и сервер Domino корректно работает по протоколу HTTP + SSL. В Web-приложениях Domino по умолчанию не поддерживаются уровень безопасности Field Security и electronic signature, т.к. эти механизмы используют в своей работе ID-файл пользователя.

Помимо перечисленных клиентов (Lotus Notes и браузер) с сервером Domino могут работать:
  • почтовые клиенты по протоколам SMTP, POP3 и IMAP;
  • клиенты новостных групп по протоколу NNTP;
  • клиенты служб каталогов по протоколу LDAP;
  • приложения использующие технологию OLE и COM.

Однако рассмотрение проблем обеспечения безопасности в этих случаях выходит за рамки настоящей статьи.
 
  Опубликовано — 03/30/2005 |    



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :

Мероприятия
Пресс-релизы
Биржа труда
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU