Войти
 
 
   
 
  
Новости 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

Средства защиты информации в Notes

Николай Норкин
Вятские Информационные Технологии
nickanor@mail.ru

Средства защиты информации в Notes

Часть 1 2 3
Механизмы разграничения доступа на различных уровнях
Безопасность информации Notes обеспечивается гибким и многоуровневым механизмом разграничения доступа. По вертикали этот механизм можно описывать как разграничение на уровне доступа к серверу, уровне доступа к базе данных, уровне доступа к представлениям и папкам, уровне доступа к документам и, еще ниже, уровне доступа к полям документа

Доступ к серверу. Процедура взаимной аутентификации
Доступ пользователя или другого сервера к серверу Domino определяет успешное выполнение четырёх процедур: процедуры аутентификации, процедуры сравнения публичного ключа с ключом, хранящимся в Адресной книге, проверка пароля и проверка списка управления доступом к серверу.
  • Процедура аутентификации является процедурой взаимной аутентификации. То есть, при обращении сервера или пользователя к серверу не только вызывающая сторона должна пройти аутентификацию на сервере, но после этого происходит обратная процедура. Обе стороны, участвующие в процедуре аутентификации, должны иметь сертификат от общего сертификатора или взаимные (перекрёстные) сертификаты (о кросс-сертификатах см. ниже). Если у клиента в файле учётной записи (для иерархического сертификата) или в Локальной Адресной книге (для перекрёстного) нет сертификата, выданного лично им серверу или одному из иерархических сертификаторов сервера, то ему будет сообщено об отсутствии сертификата и предложено создать сертификат. Если сервер не смог аутентифицировать пользователя (или другой сервер), то в зависимости от значения поля Allow anonymous Notes connections: серверного документа (секция Security) пользователю может быть отказано в доступе (значение No) либо он может получить доступ с правами Anonymous (значение Yes)

Диалог с запросом создания перекрёстного сертификата
  • Сравнение публичного ключа со значением из адресной книги сервера происходит, если в поле Compare Notes public keys against those stored in Address Book: серверного документа стоит значение Yes. Пользователь или сервер посылает вызываемому серверу свой публичный ключ в зашифрованном виде и этот ключ сравнивается с ключом, хранящимся в Адресной книге. При несовпадении ключей доступ отвергается. Такая возможность предотвращает доступ злоумышленника, похитившего файл идентификационной записи пользователя и знающего его пароль, после того, как клиент сменит публичный (а вместе с ним, и личный) ключ. Правда, следует отметить, что подобная смена ключа доставит большие хлопоты владельцу ключа, так как на ключи ориентированы механизмы шифрования и электронной подписи, а значит, все ранее зашифрованные документы и локальные базы данных будут недоступны, все подписи будут недействительны. Поэтому для устранения последствий компрометации учётной записи на серверах внутренней сети Domino лучше задействовать следующую опцию - опцию смены пароля
  • Проверка пароля будет выполнятся при взведенном флажке Check passwords on Notes IDs: в документе сервера и значения поля Check password в соответствующее значение в документе пользователя. Об использовании этой возможности говорилось несколько ранее.
  • В полях секции Restrictions серверного документа могут быть перечислены поименно, в составе групп или в виде маски пользователи, имеющие возможность работать с сервером и(или) пользователи, которым в доступе к серверу отказано. В соответствии с этими списками пользователю (или серверу) может быть отказано в доступе в следующей вежливой форме: Server Error: You are not authorized to access the server, что означает, что три предыдущие проверки прошли успешно, но доступ явно запрещен
    Server AccessWho can -
    Access server: All users can access this server
    Not access server:AccessDeniedServerA
    Create databases & templates:Administrators
    Create new replicas:Administrators
    Create master templates:
    Allowed to use monitors:Administrators
    Not allowed to use monitors:
    Trusted servers:
Доверительные отношения. Кросс-сертификаты
Для доступа к ресурсам серверов внутри иерархической организации пользователя действуют сертификаты, выданные от лица сертификатора организации или сертификаторов подразделений. Эти сертификаты описаны в документах Корпоративной Адресной книги и используются при аутентификации пользователя

Но за пределами этой иерархической организации существует еще множество иерархических организаций, порожденных от независимых сертификаторов. Могут ли пользователи вне иерархической организаций (которые могут являться партнерами, заказчиками, друзьями, наконец, просто членами сообщества пользователей Notes) воспользоваться ресурсами вашей организации, которыми вы готовы поделиться? Можете ли вы сами воспользоваться открытыми ресурсами других Notes-серверов?
Lotus поддерживает модель Расширенной организации на основе установления доверительных отношений между сертификаторами различных иерархических организаций. Для доступа к серверам другой организации администраторы (сертификаторы) организаций должны выпустить взаимные сертификаты (перекрестные сертификаты, кросс-сертификаты). При наличии этих перекрестных сертификатов в Адресной книге, хранящейся на вызываемом сервере, пользователь или сервер аутентифицируется после проверки сертификата иерархического сертификатора, хранящегося в его учётной записи

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

Доступ к базам данных. Таблица управления доступом (ACL) базы
Основным средством контроля доступа к базе данных является Список управления доступом (Access Control List, ACL), являющийся неотъемлимой принадлежностью каждой базы Notes и определяющий, какие пользователи и серверы могут иметь к ней доступ и какие задачи в этой базе они могут выполнять.
Список управления доступом включает две компоненты:
  • список элементов ACL, каждый из которых содержит имя субъекта (пользователя, сервера или группы), его уровень доступа к базе и дополнительные свойства;
  • список ролей вместе с назначением субъектов на роли.
Список управления доступом создается при создании базы и далее ведется Управляющим (Manager) базы данных.

Если пользователь не прошел процедуру аутентификации на сервере Notes/Domino, он фигурирует под именем Anonymous.
Если имя пользователя или сервера не внесено в ACL базы явно или как члена группы, а также по маске имени, ему предоставляются права, определенные для -Default-.
В списке управления доступом к базе Notes используется семь уровней доступа
  • No Access (Нет доступа) - не имеет доступа к базе данных
  • Depositor (Корреспондент) - может добавлять новые документы, но не имеет доступ к существующим (не видит их)
  • Reader (Читатель) - может читать документы, доступ к которым разрешен (или не запрещен) ему на уровне документа
  • Author (Автор) - может читать существующие документы, доступ к которым разрешен ему на уровне документа, создавать новые (в зависимости от соответствующего флага - см. ниже), модифицировать документы, если доступ на изменение разрешен ему на уровне документа
  • Editor (Редактор) - может читать и править документы, даже имея к ним доступ (на уровне документа) только на чтение, создавать новые документы
  • Designer (Разработчик) - в дополнение к возможностям редактора, может создавать, модифицировать и удалять элементы дизайна (формы, виды, папки, общих агентов и другие), модифицировать репликационные формулы, создавать полнотекстовый индекс
  • Manager (Управляющий) - в отличие от более низких уровней может изменять Список управления доступом к базе, настройки репликации, установки локального шифрования базы и удалять базу

Кроме того, для каждого уровня доступа имеется свой собственный набор дополнительных флагов, уточняющих возможности пользователя. Ниже приведены все возможные флаги без учета уровня доступа, для которого они имеют смысл (возможна установка/снятие для пользователя с соответствующим уровнем доступа)
Create documents - возможность создавать документы;
Delete documents - возможность удалять документы, на редактирование которых пользователь уполномочен;
Create personal agents - возможность создавать личных агентов;
Create personal folders/views - возможность хранить личные виды и папки на сервере (в противном случае пользователь имеет возможность создавать личные виды и папки, но храниться их элементы дизайна и индексы будут в файле desktop.dsk рабочей станции пользователя, не требуя серверных ресурсов)
Create shared folders/views - возможность создавать общие виды и папки;
Create LotusScript agents - возможность создавать агентов на LotusScript
Read public documents - возможность чтения общедоступных документов (документов со специальным флагом-полем $PublicAccess);
Write public documents - возможность создания/изменения общедоступных документов
Replicate or copy documents - возможность реплицирования базы и документов, копирования, печати документов, копирования содержимого документов в буфер обмена. Побочный эффект - невозможность реплицирования/копирования/печати документов, созданных пользователем, если у того снят данный флажок
Примером общедоступных (public) документов можно привести календарные записи в почтовой базе пользователя. Секретарь или начальник сотрудника может просматривать календарь пользователя и делать календарные записи в его органайзер, не имея доступа к почтовой переписке (Доступ к базе данных No Access с возможностью Read public documents/Write public documents)

Группы - списки пользователей, серверов или других групп, создаваемые в Адресной книге. В таблице управления доступом базы данных используется состав групп Адресной книги того сервера, на котором расположена эта база. Для локальных баз используются документы групп Локальной Адресной книги. При определении доступа в составе групп действуют следующие правила:
  • если пользователь фигурирует в ACL базы и как член группы и индивидуально, он получает права доступа, прописанные для него лично, даже если права группы предоставляют ему больший уровень доступа
  • если пользователь - член двух групп в Списке управления доступом базы, он получает права группы с большим уровнем доступа

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

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

Для создания связи нужно в Domino Administrator выбрать закладку Файлы, необходимый каталог для размещения файла ссылки (и относительно которого будет расположен линкованный каталог в структуре ресурсов сервера) и воспользоваться командой Панели сервиса Папки -> Создать связь... В диалоговом окне ввести имя ссылки(каталога), путь к каталогу относительно файловой структуры сервера и заполнить поле доступа к каталогу для пользователей и групп (или оставить его пустым, если доступ разрешен всем).
При этом создается файл ссылки (файл с расширением .dir или .lnk). Имя файла становится именем каталога в структуре данных сервера. Файл имеет текстовый формат. Первая строка представляет путь на каталог данных в файловой системе сервера, следующие строки - список пользователей и групп, которым разрешен доступ к каталогу.
e:/lotus/domino/mail
Administrators
*/OrgUnit1/Org/RU

Интерфейсные ограничения. Доступ к представлениям и папкам
Часть решений, используемых в приложениях Notes/Domino, не является, строго говоря, средствами защиты, но позволяет разработчикам приложений разграничить доступ пользователям на уровне интерфейса, предохранив систему от несанкционированных или неквалифицированных действий. Одним из таких ограничений доступа можно назвать разграничение доступа (видимости) к имеющимся в базе представлениям и папкам
Разработчик дизайна базы может ограничить выборочно использование того или иного элемента дизайна (в частности, представления или папки), внеся в Свойства элемента дизайна (Закладка с ключиком, поле Who may use this view) список пользователей, групп, ролей, которые могут пользоваться этим представлением или папкой. Однако, приложение Notes не ограничивает возможность пользователю с уровнем читателя создать собственное представление, куда вошли бы и документы, которые от него хотели скрыть на уровне доступа к представлению. Именно этим вызвана оговорка в предыдущем абзаце


Доступ к документам. Поля типа Readers и Authors
Не меньший арсенал интерфейсных ограничений представляется разработчикам и на уровне формы документа. Это и свойство формы Who can create documents with this form; это и формулы скрытия абзацев, ячеек таблиц и гиперобъектов; это и секции с ограниченным доступом. Беда лишь в том, что все эти механизмы привязаны к определенной форме. Значения полей, скрытых от пользователя, будут видны в Свойствах документа; создать документ можно, не пользуясь заготовленной разработчиком формой.
Средствами защиты информации на уровне документа являются содержащиеся в нем поля типа Readers и Authors.
  • Документ, не содержащий ни одного поля типа Readers будет виден всем пользователям с уровнем доступа к базе не ниже Читателя. Поля типа Readers при просмотре Свойств документа можно узнать. Хотя их тип показывается как Text, параметр Field Flags содержит SUMMARY READ-ACCESS NAMES.
  • Документ, содержащий поля типа Readers, будет виден всем, кто явно или как член группы или носитель роли присутствует хотя бы в одном поле типа Readers. Кроме того, такой документ будут видеть и пользователи, прописанные явно или опосредовано хотя бы в одном поле типа Authors. Для пользователя, не прописанного в полях доступа документа, этот документ остаётся невидимым. Доступ пользователя к документу определяется его доступом к базе данных. Пользователь с уровнем доступа Editor (Редактор) и выше к базе может не только читать, но и редактировать документ, который видит. Пользователь, ущемленный в своих правах, - только читать.
  • Поля типа Readers могут быть предусмотрены в форме разработчиком базы. Для этого используется или свойство формы Default Read access for documents created with this form, или в форме просто создаются собственные поля типа Readers.
  • Даже если в форме не были предусмотрены поля типа Readers, любой пользователь, уполномоченный редактировать документ, может "защитить" его, использовав набор полей на закладке с ключиком Свойств документа. В результате в документе появится поле $Readers с флагом SUMMARY READ-ACCESS
  • Если пользователь имеет к базе доступ ниже Author (Автор), он ни в коем случае не сможет изменить содержащиеся в ней документы (за исключением public-документов - для их изменения нужен соответствующий доступ к базе и опять же наличие пользователя в одном из полей типа Authors). Пользователь с уровнем доступа Author (Автор) для получения этой привилегии должен быть прямо или опосредовано указан в одном из полей типа Authors документа. Пользователям, имеющим к базе доступ редактора, достаточно только видеть документ, чтобы его редактировать

Разграничение доступа на уровне полей
На уровне полей для защиты могут быть использованы следующие механизмы:
  • Шифрование полей. Один из наиболее эффективных способов защиты информации в базах. Пользователь или сервер, имея возможность читать документ, не будет видеть содержимое зашифрованных полей в нем, если не имеет необходимого ключа шифрования в файле идентификационной записи. Шифрование полей в документах отличается от шифрования почты. Подробнее механизмы шифрования будут рассмотрены ниже
  • Электронная подпись документа. Электронная подпись - это "слепок" (hash-код) с информации, содержащейся в полях, отмеченных значением Security Options Sign if mailed or saved in section. Этот hash-код шифруется приватным ключом пользователя. Положительный результат проверки электронной подписи на документе свидетельствует о двух фактах: первое - содержимое документа действительно было подписано пользователем, обладавшим доступом к приватному ключу пользователя, и второе - информация, защищённая электронной подписью, не изменилась со времени её подписания
  • Защита поля флагом Protected (Опция Must have at least Editor access to use Свойств поля в дизайне формы) требует от пользователя доступ к базе не ниже Editor (Редактор) для того, чтобы он мог изменить значение поля. Даже если пользователь может редактировать документ, значение поля с флагом Protected он изменить не сможет

Часть 1 2 3
 
  Опубликовано — 08/08/2007 |    



Добавить комментарий
Имя * :
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