Функции безопасности Domino/Notes 6

Стандартная безопасность базы данных webadmin.nsf

Стандартные параметры ACL для базы данных Web-администратора см. в табл. 11.2. Вам не требуется изменять эти параметры, если имя администратора указано в поле Administrators (Администраторы) документа Server.

Аутентификация администраторов

Для доступа к Web-администратору можно использовать либо интернет-пароль, либо сертификат SSL-клиента. Web-администратор использует либо имя и пароль, либо SSL-аутентификацию для проверки личности пользователя. Используемый Web-администратором метод зависит от того, настроен ли сервер и/или база данных Web-администратора Domino (WEBADMIN.NSF) на требование имени и пароля или SSL-аутентификации.

Для доступа к базе данных Web-администратора необходимо настроить на сервере аутентификацию с использованием имени и пароля или аутентификацию SSL-клиента. Аутентификация с использованием имени и пароля включена для протокола HTTP по умолчанию.

11.1.4 Ограничения программируемости

Для управления типами агентов, которые пользователи могут запускать на сервере, можно установить ограничения для серверных агентов в документе Server. Как и в случае административного доступа, список серверных агентов в документе Server организован иерархически с учетом привилегий. Категория Run unrestricted methods and operations (Выполнение неограниченных методов и операций) имеет наибольший уровень привилегий, тогда как Run Simple and Formula agents (Выполнение простых агентов и агентов формул) имеет наименьший уровень привилегий. Имя пользователя или группы в списке автоматически получает права всех списков, находящихся ниже в иерархии. Таким образом, имя нужно вводить только в одном списке, в результате чего пользователь получит наивысшие права.

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

Run unrestricted methods and operations (Выполнение неограниченных методов и операций)

Новое в Domino 6

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

Только пользователи с таким уровнем доступа могут выбрать опцию, отличную от Do not allow restricted operations (Не разрешать ограниченные операции). Такой доступ устанавливается по умолчанию для текущего сервера и разработчиков шаблонов Lotus Notes.

Если пользователи из этого списка также указаны как администраторы базы данных в документе Server, им разрешается выполнять операции с базой данных без явного указания в ACL базы данных (например, они могут удалять базы данных, не будучи указанными в ACL этих баз данных).

Примечание. Чтобы иметь возможность выполнения агентов в неограниченном режиме с полными административными правами, пользователь (группа), выполнивший подписание агента, должен быть указан в этом поле или в поле Full Access Administrators (Администраторы с полным доступом), а также для них должен быть выбран этот режим в Agent Builder. Внесение в список Full Access Administrators (Администраторы с полным доступом) само по себе не является достаточным для выполнения агентов в этом режиме.

Sign agents to run on behalf of someone else (Подписание агентов для выполнения от имени другого пользователя/группы)

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

Примечание. Эту привилегию следует использовать с осторожностью, так как имя, применявшееся для подписания агента, употребляется для проверки доступа в ACL.

Sign agents to run on behalf of the invoker of the agent (Подписание агентов для выполнения от имени вызывающей стороны)

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

Run restricted LotusScript/Java agents (Выполнение ограниченных агентов LotusScript/Java)

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

Run simple and formula agents (Выполнение простых агентов и агентов формул)

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

Sign script libraries to run on behalf of someone else (Подписание библиотек скриптов для выполнения от имени другого пользователя/группы)

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

11.1.5 Политики и документы политик

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

Политики Domino не следует путать с корпоративными политиками безопасности. Корпоративная политика безопасности представляет собой набор инструкций и стандартов, используемых в организации для установления и применения безопасных методов работы с информацией. Дополнительные сведения о политиках без-опасности в организации см. в лекции 2, "Методологии построения систем безопасности".

Создание документов с параметрами политик выполняется для следующих областей администрирования:

Важно! При проверке паролей информация в документе Person отменяет информацию в документе Server. При отключении проверки паролей для пользователя Domino не проверяет пароли для пользователя, даже если проверка паролей включена для сервера. При отключении проверки паролей для сервера Domino не проверяет пароли для любых пользователей, осуществляющих доступ к серверу, даже если для пользователя включена проверка пароля.

Что касается ECL, политика позволяет осуществлять управление следующими параметрами:

Существует два типа политик: организационные (organizational) и явные (explicit). Понимание различий между этими типами помогает при планировании реализации.

Организационные политики

Организационная политика автоматически применяется ко всем пользователям, зарегистрированным в определенном подразделении. Например, для распространения параметров по умолчанию для всех пользователей, зарегистрированных в Sales/Acme, следует создать организационную политику с именем */Sales/Acme. Затем при употреблении идентификатора центра сертификации Sales/Acme для регистрации пользователя этот пользователь автоматически получает параметры из соответствующей организационной политики.

При перемещении пользователя в иерархической структуре, например в связи с переходом пользователя из отдела продаж (Sales) в отдел маркетинга (Marketing), пользователю автоматически назначается организационная политика для соответствующего идентификатора центра сертификации. Например, при перемещении пользователя из Sales/Acme в Marketing/Acme пользователю назначаются все параметры рабочего стола, архивации и безопасности, связанные с организационной политикой */Marketing/Acme. Новые параметры политики вводятся в действие при первой аутентификации пользователей на домашнем сервере.

Явные политики

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

Существует три способа назначения явной политики: во время регистрации пользователя, при редактировании документа Person пользователя или с применением инструмента Assign Policy.

Использование исключений

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

Политики исключений представляют собой способ специального обслуживания пользователей в организации, что может быть связано с их должностью или специальными требованиями. Например, предположим, что политика */Acme включает параметр политики регистрации, применяющий квоту почтовой базы данных объемом 60 Мб. Однако небольшой группе сотрудников в подразделении Acme требуется превысить эту квоту. Решение состоит в том, чтобы создать политику исключения, включающую только документ параметров политики регистрации, не устанавливающий ограничение квоты для почтовой базы данных. При назначении политики исключения пользователям они могут заменить параметр квоты базы данных. Так как политики исключений отменяют применение параметров политик, их использование должно быть умеренным.

Дополнительные сведения о настройке и назначении политик см. в разделе "Policies" ("Политики") главы "User and Server Configuration" ("Конфигурация пользователей и серверов") руководства "Domino 6 Administration Guide".

11.1.6 Безопасность интернет-сайта

Новое в Domino 6

Документы Internet Site используются для настройки интернет-протоколов, поддерживаемых серверами Domino. Отдельный документ Internet Site создается для каждого протокола [Web (HTTP), IMAP, POP3, SMTP Inbound, LDAP и IIOP] и затем используется для предоставления информации о настройке протокола для одного сервера или для нескольких серверов в организации Domino. В частности, можно создавать следующие типы документов:

Документы Internet Site упрощают для администраторов конфигурирование и управление интернет-протоколами в своих организациях. Например, до появления Domino 6 при установке Web-сайта в организации необходимо было настраивать каждый сервер Domino в домене с использованием документов Mapping, Web realms (экземпляров) и документов File Protection. При использовании виртуальных серверов и виртуальных узлов необходимо было выполнять для них такие же операции. В Domino 6 можно сконфигурировать документ Web Site, который будет использоваться всеми серверами и узлами для получения информации о конфигурации для Web-сайта, включая информацию о сопоставлении, информацию о защите файлов и информацию об аутентификации экземпляра Web realm.

Необходимо использовать документы Internet Site в следующих случаях:

Дополнительные сведения о конфигурировании Domino для хостируемых организаций см. в руководстве "Domino 6 Administration Guide".

Изменения в документах Internet Site (включая создание новых документов Site) являются динамическими. Не требуется перезапускать сервер или протокол после создания нового документа Site или после изменения или удаления существующего. Изменения обычно вступают в действие через несколько минут после их внесения.

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

Сервер Domino настраивается на использование документов Internet Site, если эта опция включена в документ Server. Если опция не включена, сервер использует параметры документа Server для получения информации о конфигурации для интернетпротоколов.

Документы Internet Site создаются в представлении Internet Sites, которое помогает в управлении информацией о конфигурации интернет-протоколов, выводя сконфигурированные документы Internet Site для каждой организации в домене.

Важно! При использовании документа Internet Site для конфигурирования одного интернетпротокола на сервере необходимо также использовать документы Internet Site для всех интернет-протоколов на этом сервере. Например, нельзя настроить документ LDAP Internet Site и на том же сервере использовать документ Server для конфигурирования HTTP.

Хотя настройка большинства параметров протоколов осуществляется через документы Internet Site, некоторые параметры требуется настраивать в документе Server для поддержки конфигураций интернет-протоколов. К ним относятся следующие параметры:

Защита документов Internet Site

Для обеспечения защиты документов Internet Site можно включить SSL-аутентификацию сервера и клиента, аутентификацию с использованием имени и пароля или анонимный доступ для интернет-клиентов и клиентов интрасети.

Чтобы включить SSL для интернет-сайтов, необходимо сконфигурировать SSL-порт в документе Server и установить SSL на сервере, получив сертификат сервера и набор ключей (key ring) от центра сертификации в Интернете.

Для настройки SSL-аутентификации необходимо создать файл набора ключей сервера (server key ring file) для каждого документа Internet Site. Однако если документы Internet Site относятся к одной организации, но создаются для различных протоколов, можно использовать один файл набора ключей сервера. Следует обязательно ввести имя файла набора ключей сервера в соответствующем поле вкладки Security (Безопасность) документа для каждого сайта.

Если требуется использовать списки отзыва сертификатов (Certificate Revocation List, CRL) для аутентификации на основе интернет-сертификатов, сервер должен использовать центр сертификации на основе сервера Domino для выдачи интернетсертификатов.

Чтобы включить SSL для хостируемой организации, необходимо ввести IP-адрес сервера в поле Host names or addresses mapped to this site (Имена или адреса узлов, поставленных в соответствие этому сайту) на вкладке Basics (Основные параметры) документа Internet Site.

Для Web-сайтов общее имя (common name) в серверном наборе ключей должно соответствовать DNS-имени, которому ставится в соответствие IP-адрес в документе Web Site. IP-адрес должен быть записан в поле Host name or addresses to map to this site (Имя узла или адреса, ставящиеся в соответствие этому сайту) в документе Web Site. При включении опции Redirect TCP to SSL (Перенаправление TCP в SSL) в документе Web Site в этом поле следует указать как имя, так и IP-адрес узла.

В Domino 6 можно эффективно препятствовать доступу к документу Internet Site, выбрав "No" для всех опций аутентификации в документе Internet Site. К этим опциям относятся TCP-аутентификация, SSL-аутентификация и анонимный доступ TCP.

Нельзя использовать документы Internet Site в среде со смешанными версиями Domino. Вместо них следует применять документы конфигурации Web Server и параметры протоколов в документе Server.

Дополнительные сведения о настройке SSL см. в лекции 6, "Инфраструктуры открытого ключа".

Дополнительные сведения о центре сертификации на основе сервера Domino 6 см. в разделе 11.5.1, "Центр сертификации на основе сервера Domino".

11.1.7 Физическая защита сервера

И наконец, при планировании безопасности любой серверной среды следует обязательно рассмотреть методы физической защиты сервера от злоумышленников. Физическая защита включает следующие методы:

Новое в Domino 6

11.2 Безопасность HTTP-сервера

Новое в Domino 6

Начиная с Domino 6, Lotus Domino имеет полностью новый HTTP-сервер. Этот новый "стек" HTTP более актуален, чем первоначальный код, реализованный в Domino при внедрении поддержки протокола HTTP в Domino 4.5. Новый стек Domino 6 больше не содержит устаревших компонентов кода HTTP оригинального HTTP-сервера IBM (также известного как ICS). Это означает, что в Domino 6 изменена поддержка API-интерфейсов стеков HTTP.

Новый стек содержит функции расширенного администрирования Web-сайта и виртуального хоста, поддержку постоянных подключений HTTP 1.1 и улучшенную обработку сеансов. С точки зрения безопасности также реализована улучшенная защита от атак типа "denial of service" (отказ в обслуживании, DOS) с большей степенью контроля над количеством сегментов путей, максимальным размером заголовков, длиной URL length и т. д. Также можно осуществлять IP-фильтрацию с помощью шаблонов с использованием списков разрешений и отказов в доступе на основе IP-адреса.

Кроме того, новый стек содержит улучшенную поддержку подключаемых модулей HTTP, что позволяет подключать HTTP-сервер Domino к Web-серверам сторонних производителей (включая установку брандмауэра между Web-сервером и Domino), а также расширенный и улучшенный подключаемый модуль DSAPI, что упрощает создание собственных подключаемых модулей для HTTP-сервера Domino. Эти две функции (подключаемые модули DSAPI и HTTP) более подробно описываются в следующих двух разделах.

11.2.1 Domino Web Server API

Domino Web Server Application Programming Interface (DSAPI) представляет собой инструмент C API, позволяющий создавать собственные расширения для Web-сервера Domino. Эти расширения (или фильтры) позволяют настраивать аутентификацию Web-пользователей.

Во времена Domino 4.6.1 оригинальный Web-сервер IBM Web Server (ICS) был переименован в Domino "GO" Web Server и общий API для Domino и нового Domino "GO" Server был назван GWAPI (Go Webserver Application Programming Interface). Однако начиная с Domino 5.0 был реализован новый, в полной мере кросс-платформенный API для расширения функциональности таких дополнительных подключаемых модулей. Domino 5 DSAPI взаимодействовал с "устаревшим" HTTP-стеком ICS, который все еще входил в состав Domino 5, обеспечивая совместимость с GWAPI (хотя и не объявленную, а только толерантную совместимость). Это представляло дополнительную сложность, поэтому такая схема была упрощена в новом HTTP-стеке Domino 6, включающем улучшенный DSAPI.

Принимая во внимание исторические изменения в DSAPI, при обновлении до Domino 6 важно рассмотреть все подключаемые модули DSAPI на основе R5, существующие в вашей архитектуре. Несмотря на то что DSAPI, разработанный для Domino 5, может выполняться и в Lotus Domino 6, он не предназначен для поддержки новой архитектуры HTTP-стека, поэтому он может не работать оптимальным образом. Другими словами, он может функционировать, однако функции, выполняемые API, могут требовать другого архитектурного способа реализации, чтобы использовать преимущества новой архитектуры HTTP, встроенной в Domino 6.

Одним из изменений, реализованных в Domino 6 API, которое может быть причиной для перезаписи R5 DSAPI, состоит в том, что в R5 DSAPI ваш код вызывается в 100 % случаев, когда требуется "шаг" HTTP-стека (другими словами, при перехвате запросов аутентификации DSAPI вызывается в 100 % случаев). Однако в Domino 6 можно назначать DSAPI для отдельных интернет-сайтов, вследствие чего они не вызываются в 100 % случаев, что позволяет улучшить производительность.

Ограничение. DSAPI-интерфейсы, разработанные для R5, могут вызвать отказ HTTP-сервера при выделении динамической памяти DSAPI для использования в качестве частного (private) контекста с нарушением новых правил для Domino 6. Это означает, что вам (или поставщику вашего DSAPI-приложения) может потребоваться внести некоторые изменения в исходный код R5/DSAPI-приложения и перекомпилировать его с использованием нового пакета инструментов. Это та цена, которую приходится платить за улучшение стабильности памяти в соответствии с требованиями HTTP-стека R6.

Дополнительные сведения об использовании DSAPI в конфигурации с единой регистрацией (single sign-on) см. в разделе 7.4, "DSAPI".

11.2.2 Подключаемые модули HTTP-сервера

Новое в Domino 6

Domino R6 использует модель подключаемых модулей Web-сервера WebSphere. Эта функция заменяет архитектуру "Domino for IIS", которая была реализована в Release 5. Эта новая модель позволяет использовать Web-сервер стороннего производителя (например, IIS) для работы с браузерами и обслуживания статического содержимого (что является их специализацией), направляя все NSF-запросы в HTTP-стек Domino. Подключаемые модули используют HTTP для связи с сервером Domino; при этом HTTP-сервер стороннего производителя может находиться в демилитаризованной зоне, тогда как его подключаемые модули, осуществляющие обмен данными с HTTP-сервером Domino, находятся в брандмауэре. Подключаемые модули поддерживают основные службы заднего плана Domino [основные функции базы данных Domino, Lotus iNotes Web Access, Lotus Domino Off-Line Services (DOLS), Lotus Discovery Server™]; остальной HTTP-трафик игнорируется подключаемым модулем и обрабатывается HTTP-сервером переднего плана.

Такая новая архитектура подключаемых модулей применима для всех поддерживаемых операционных систем, в которых работает Domino, так как подключаемый модуль в действительности не устанавливается непосредственно на сервере Domino. Вместо этого подключаемый модуль устанавливается на HTTP-сервере переднего плана. Domino 6.0 поддерживает следующие серверы переднего плана:

Файлы подключаемых модулей для этих серверов поставляются вместе с сервером Domino 6, и их использование покрывается лицензией Domino (при условии, что подключаемый модуль, устанавливаемый в системе, будет использоваться для доступа к лицензированному серверу Domino 6).

При установке Lotus Domino 6 процедура установки генерирует подкаталог plugins в каталоге data/domino. Этот подкаталог plug-ins содержит подключаемые модули WAS 4.x и 5.x для работы со множеством серверов переднего плана, включая Microsoft IIS и IBM Apache HTTP. Повторимся, что вам не следует устанавливать эти подключаемые модули в Domino 6, их следует копировать и устанавливать в других HTTP-стеках (например, в IIS).

После установки и надлежащего конфигурирования подключаемого модуля на HTTP-сервере переднего плана на сервере Domino выполняется настройка параметра файла notes.ini (HTTPEnableConnectorHeaders=1). Этот параметр файла notes.ini сообщает Domino о том, что следует начать использовать и доверять информации USER, как передаваемой в HTTP-заголовках подключаемым модулем переднего плана.

Дополнительные сведения о внутренней работе новой модели подключаемых модулей HTTP см. в прил. "C", "Советы и рекомендации по подключаемым модулям HTTP в Domino 6".

Дополнительные сведения об архитектуре подключаемых модулей HTTP в Domino 6, а также об их использовании в системах IBM iSeries см. в руководстве Lotus Domino 6 for iSeries Implementation, SG24-6592.

11.3 Среда поставщика услуг (xSP)

Новое в Domino 6

Поставщик услуг Domino (доступ к приложениям, доступ к Интернету, хранение, управление и т. д.) поставляет услуги предприятиям небольшого и среднего размера или нескольким хостируемым организациям из единого домена Domino. Для таких хостируемых организаций поставщик услуг предлагает доступ на основе интернет-протоколов к определенному набору приложений, выполняющихся на серверах Domino. Работа с поставщиком услуг позволяет компании передать администрирование приложений и служб, которые ранее выполнялись в компьютерной инфраструктуре компании.

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

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

Защита среды поставщика услуг Domino

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

Кроме того, конфигурация поставщика услуг применяет расширенные ACL в Domino Directory для защиты данных каждой хостируемой организации от доступа пользователей из других хостируемых организаций. Расширенные ACL, необходимые для поддержки модели безопасности xSP, автоматически устанавливаются при создании новых хостируемых организаций. Необходимо осуществлять тщательное планирование и тестирование, прежде чем вносить изменения в ACL и расширенные ACL в среде xSP: безопасность здесь очень важна.

Средства управления аутентификацией в документах Site осуществляют контроль только над тем, кто может подключиться и использовать интернет-протоколы. После аутентификации ACL и расширенные ACL осуществляют контроль над чтением и записью данных в Domino Directory.

Пользователь в хостируемой организации не может получить прямой доступ к базам данных, расположенных в каких-либо подкаталогах, кроме каталога хостируемой организации. Исключением являются подкаталоги help и common каталога данных Domino, которые содержат базы данных, доступные для пользователей из всех хостируемых организаций.

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

11.4 Перемещающиеся пользователи

Новое в Domino 6

Пользователи, осуществляющие доступ к Notes с различных клиентов Notes, могут получить доступ к своим настройкам и личной информации автоматически с любого клиента Notes в домене. Осуществляется репликация данных для этих пользователей, называемых перемещающимися пользователями (roaming users), между компьютером пользователя и сервером перемещающегося пользователя, на котором эти файлы хранятся. При входе перемещающегося пользователя с другого клиента Notes он автоматически получает ID-файл пользователя, личную адресную книгу, закладки и журнал с сервера перемещающегося пользователя. Любые изменения, вносимые пользователем в эти файлы, реплицируются на сервер перемещающегося пользователя. Это позволяет обеспечить согласованность работы перемещающегося пользователя на всех клиентах Notes.

Для настройки параметров регистрации перемещающихся пользователей можно применять документ параметров политики регистрации.

Защита перемещающихся пользователей

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

11.5 Центр сертификации Domino

Центр сертификации (certificate authority, CA), или сертификатор (certifier), представляет собой доверенное средство администрирования, осуществляющее выпуск и обслуживание цифровых сертификатов. Сертификаты позволяют подтвердить личность пользователя, сервера или организации и в случае интернет-сертификаторов позволяют использовать SSL для связи и S/MIME для обмена почтой. Сертификаты содержат цифровую подпись сертификатора, которая служит для получателей сертификата подтверждением того, что предъявитель сертификата является сущностью, указанной в сертификате.

Сертификаторы также могут выпускать доверенные корневые сертификаты (trusted root certificates), которые позволяют клиентам и серверам, имеющим сертификаты, выданные различными центрами сертификации, осуществлять обмен данными друг с другом.

Важно понимать разницу между Notes-сертификаторами и интернет-сертификаторами. При установке и настройки первого сервера Domino в домене автоматически устанавливается Notes-сертификатор для выдачи сертификатов Notes для клиентов Notes. Эти сертификаты необходимы аутентификации клиентов Notes на сервере Domino, а также для взаимной аутентификации серверов Domino. Поэтому Notes438 сертификаторы важны даже в среде, состоящей исключительно из Web-клиентов. С другой стороны, интернет-сертификатор выпускает интернет-сертификаты (X.509), которые являются стандартом для безопасного обмена данными через Интернет (SSL, TLS и т. д.). Установка интернет-сертификаторов выполняется в Domino по мере необходимости.

Например, можно установить SSL на сервере Domino, чтобы клиенты, подключающиеся к серверу, использовали SSL для обеспечения конфиденциальности обмена данными.

Примечание. Установка SSL выполняется для различных протоколов в отдельности. Например, можно включить SSL только для почтовых протоколов, таких, как IMAP, POP3 и SMTP.

Для установки SSL на вашем сервере необходим набор ключей, содержащий сертификат сервера от интернет-сертификатора. Можно запросить и получить сертификат сервера либо в центре сертификации Domino, либо в стороннем центре сертификации, после чего установить его в наборе ключей. Сертификат сервера представляет собой двоичный файл, уникально идентифицирующий сервер; он хранится на жестком диске сервера и содержит открытый ключ, имя, срок действия и цифровую подпись. Набор ключей также содержит корневые сертификаты, используемые сервером для принятия решений о доверительных отношениях.

Дополнительные сведения об инфраструктуре открытого ключа (PKI) в Domino и включении SSL см. в лекции 6, "Инфраструктуры открытых ключей", а также в документе "The Domino Certificate Authority" из серии "IBM Redpapers".

Примечание. Можно включить SSL на сервере при первоначальной регистрации сервера, если у вас уже есть центр сертификации на основе сервера Domino, запущенный в домене Domino.

11.5.1 Центр сертификации на основе сервера Domino

Новое в Domino 6

В Domino 6 можно установить Domino-сертификатор, использующий серверную задачу (процесс CA ) для управления запросами сертификатов и их обработки. Процесс CA выполняется как автоматизированный процесс на серверах Domino, используемых для выдачи сертификатов. Можно настроить работу таким образом, чтобы Notes-сертификаторы применяли процесс CA вместе с интернет-сертификаторами. При настройке работы с одним из типов сертификатора выполняется его привязка к процессу CA на сервере, что позволяет использовать операции процесса CA. На сервере может выполняться только один экземпляр процесса CA ; однако процесс может быть связан с несколькими сертификаторами. После настройки центра сертификации на основе сервера Domino вы можете осуществлять управление процессом CA из консоли Domino с использованием серверных команд Tell.

Преимущества центра сертификации на основе сервера Domino 6 состоят в том, что он:

Для установки центра сертификации на основе сервера Domino в вашей организации необходимо настроить Notes- и интернет-сертификаторы на использование процесса CA. Можно настроить на использование процесса CA либо только один тип сертификатора (например, только интернет-сертификаторы для процесса CA ), либо все сертификаторы для процесса CA.

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

Список выданных сертификатов (ICL)

Каждый сертификатор имеет список выданных сертификатов (Issued Certificate List, ICL), создаваемый вместе с созданием сертификатора или его миграцией в процесс CA. ICL представляет собой базу данных, содержащую копии всех выпущенных им действительных сертификатов, списки отзыва сертификатов и документы конфигурации CA. Документы конфигурации генерируются при создании сертификатора и его подписания открытым ключом сертификатора. Документы конфигурации CA включают:

Еще один документ конфигурации CA (документ Certifier) создается в Domino Directory при установке сертификатора.

Список отзыва сертификатов (CRL)

Список отзыва сертификатов (Certificate Revocation List, CRL) представляет собой список с отметками времени, идентифицирующий отозванные интернет-сертификаты, например сертификаты, принадлежащие уволенным сотрудникам. Процесс CA создает и обслуживает списки CRL для каждого интернет-сертификатора. Список CRL связан с сертификатором, подписан сертификатором и находится в базе данных ICL сертификатора. Копия CRL также хранится в Domino Directory, где она применяется для проверки действительности сертификата при аутентификации с использованием сертификатов.

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

Использование CRL позволяет осуществлять управление сертификатами, выпущенными в вашей организации. Сертификат можно легко отозвать, например при уходе владельца сертификата из организации или при компрометации ключа. HTTP-серверы и Web-браузеры выполняют проверку CRL, чтобы определить, не был ли тот или иной сертификат отозван, в результате чего он больше не является доверенным у сертификатора. При использовании документов Internet Site для конфигурации интернет-протоколов на сервере Domino также можно включить проверку CRL для каждого протокола.

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

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

База данных запросов сертификатов

Каждому создаваемому интернет-сертификатору требуется база данных запросов сертификатов (CERTREQ.NSF) для управления запросами сертификатов серверов и клиентов. В этой базе данных хранятся активные запросы сертификатов и отзывов, которые были переданы в процесс Administration Process для обработки. Используя интерфейс на основе браузера, серверы и клиенты запрашивают сертификаты и получают выпущенные сертификаты.

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

Администрирование центра сертификации на основе сервера

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

Примечание. Многие задачи, связанные с управлением центром сертификации, которые до Domino 6 выполнялись вручную, теперь автоматизированы при использовании процесса CA.

Задачи администратора центра сертификации Domino

Администратор центра сертификации Domino (certificate authority administrator, CAA) отвечает за выполнение следующих задач:

Администратор центра сертификации должен иметь доступ к главному каталогу Domino Directory в домене, по меньшей мере на уровне Editor (Редактор).

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

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

Задачи администратора центра регистрации Domino

Администратор центра регистрации (registration authority, RA) регистрирует пользователей Notes и серверы Domino, принимает или отклоняет запросы интернет-сертификатов и при необходимости отзывает интернет-сертификаты. Хотя администратор центра сертификации может выполнять функции администратора центра регистрации, основное преимущество использования отдельной роли центра регистрации состоит в том, чтобы разгрузить администратора Domino или центра сертификации, сняв с него эти задачи. Кроме того, администратор Domino может установить один или несколько центров регистрации для каждого сертификатора, настроенного на процесс CA.

Центр регистрации должен принимать только те запросы, которые будут приняты сертификатором. Приемлемые запросы описываются в документе CA Configuration, хранящемся в базе данных ICL центра сертификации.

Администраторы Domino, выполняющие регистрацию пользователей Notes, также должны быть указаны как центры регистрации для Notes-сертификатора.

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

Администратор центра регистрации Domino отвечает за следующие задачи:

Примечание. Центры сертификации и центры регистрации должны иметь доступ к главному каталогу Domino Directory в домене, по меньшей мере на уровне Editor (Редактор).

Создание сертификаторов, использующих процесс CA

При создании сертификатора для процесса CA необходимо убедиться в том, что процесс CA запущен на сервере. Сертификаторы не будут функционировать, если процесс CA не запущен. Для управления процессом CA можно использовать команды Tell с консоли сервера.

Если при создании сертификатора процесс CA запущен, он автоматически добавляет новые созданные сертификаторы при обновлении, которое выполняется каждые 12 часов. Однако период времени, в который база данных Administration Requests обрабатывает запросы к CA, варьируется. Можно ускорить процесс с использованием команд Tell для принудительной обработки всех запросов процессом AdminP с последующим обновлением процесса CA.

Примечание. Для автоматической загрузки задачи CA следует добавить параметр ca к параметру Server в файле NOTES.INI.

Общий процесс создания сертификатора, настроенного на процесс CA, выглядит следующим образом:

Дополнительные сведения о каждой процедуре см. в главе "Установка центра сертификации на основе сервера" в руководстве Domino 6 Administering the Domino System.

11.6 Службы каталогов

Существует несколько аспектов служб каталогов Domino, которые следует учитывать при защите среды Domino.

11.6.1 Серверы администрирования каталога

Каждый домен Domino содержит по меньшей мере один сервер администрирования Domino Directory. Сервер администрирования отвечает за выполнение запросов к процессу Administration Process, который автоматизирует изменения в Domino Directory. По умолчанию первый сервер, установленный в домене, является сервером администрирования Domino Directory.

11.6.2 Выделенные серверы каталога

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

Сервер каталога может:

Можно настроить клиенты Notes таким образом, чтобы они использовали для просмотра имен и адресов серверы каталога, а не почтовые серверы.

Использование централизованной архитектуры каталогов в домене Domino

До выхода Domino 6 компании всегда применяли распределенную архитектуру каталогов, при которой каждый сервер в домене Domino содержал полную реплику основного каталога Domino Directory в домене. Основной каталог содержит все типы документов: документы, используемые для предоставления служб каталогов, например документы Person и Group, а также документы, применяемые для конфигурирования серверов Domino.

Новое в Domino 6

В этой версии компании могут внедрить централизованную архитектуру каталогов, при которой несколько серверов каталогов в домене содержат реплики основного каталога Domino Directory, которые включают все содержимое Domino Directory. Остальные серверы в домене содержат каталоги Configuration Directory, которые представляют собой небольшие выборочные реплики Domino Directory и содержат только документы, используемые для конфигурирования Domino. Сервер, содержащий Configuration Directory, применяет основной каталог Domino Directory на другом сервере (называемый удаленным основным каталогом Domino Directory) для просмотра информации в документах Person, Group, Mail-In Database и Resource, а также в любых собственных документах новых типов, которые компания добавила в каталог.

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

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

11.6.3 Directory Assistance

Directory Assistance представляет собой средство, которое сервер может использовать для просмотра информации в каталоге, отличном от локального основного каталога Domino Directory (NAMES.NSF). Можно настроить Directory Assistance на применение определенного каталога для любой из следующих задач:

Можно установить Directory Assistance для удаленного LDAP-каталога или каталога Domino. В качестве удаленного LDAP-каталога может использоваться любой удаленный LDAP-совместимый каталог либо на сервере внешнего LDAP-каталога, либо на сервере Domino, на котором выполняется служба LDAP.

Каталог Domino создается на основе шаблона PUBNAMES.NTF, и доступ к нему осуществляется через вызовы NAMELookup. Серверы могут использовать Directory Assistance для выполнения просмотров в локальных или удаленных репликах в каталоге Domino. Каталог Domino, настроенный на использование Directory Assistance, может представлять собой дополнительный (secondary) каталог Domino Directory, расширенный список каталогов (Extended Directory Catalog) или основной (primary) каталог Domino Directory.

Directory Assistance и аутентификация клиента

Для аутентификации пользователя, осуществляющего доступ к базе данных на сервере Domino через любой из поддерживаемых интернет-протоколов (Web (HTTP), IMAP, POP3 или LDAP), сервер может просмотреть учетные данные пользователя в каталоге, сконфигурированном в соответствующей базе данных Directory Assistance. Серверы могут выполнять аутентификацию с применением сертификатов X.509 или с использованием имени и пароля.

Для того чтобы сервер мог применять каталог для аутентификации интернет-клиентов, сконфигурированной в базе данных Directory Assistance, выполните следующие действия в документе Directory Assistance для каталога:

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

Внимание! Сервер может использовать каталог Domino в базе данных Directory Assistance для аутентификации клиента, если каталогу назначен тот же домен, что и домену сервера, вне зависимости от конфигурации документа Directory Assistance.

Управление типами аутентификации клиентов, разрешенными сервером интернет-протоколов, выполняется в документе Internet Site или на вкладке Ports (Порты) -> Internet Ports (интернет-порты) документа Server.

Имена, принимаемые для выполнения аутентификации с использованием имени и пароля

Если сервер выполняет аутентификацию интернет-клиентов с использованием имени и пароля, вы можете выбрать типы имен, принимаемых сервером от клиентов. На вкладке Security (Безопасность) -> Internet Access (Доступ в Интернет) документа Server в основном каталоге Domino Directory выберите More name variations with lower security (Больше вариантов имен с более низкой безопасностью) или Fewer name variations with higher security (Меньше вариантов имен с более высокой безопасностью (установлено по умолчанию). Выбранный параметр относится к аутентификации с использованием имени и пароля в любом каталоге, включая основной каталог Domino Directory.

Хотя сервер может принимать не только отличительные имена от клиента для поиска записи пользователя в каталоге, сервер всегда применяет отличительное имя пользователя в записи каталога для сравнения с правилами доверия в документе Directory Assistance, чтобы определить, выполнять ли аутентификацию клиента. Например, предположим, что пользователь зарегистрирован в каталоге под отличительным именем cn=alice browning,o=Acme, но при этом в клиенте пользователь конфигурирует имя alice browning. При аутентификации сервер выполняет поиск записи, содержащей имя alice browning. Когда он найдет запись, он может выполнить аутентификацию клиента, только если "cn=alice browning,o=acme" соответствует доверенному правилу именования для каталога.

Отличительное имя пользователя также употребляется в качестве основы для управления доступом в Domino, поэтому вам следует употреблять отличительные имена пользователей в ACL базы данных, в группах, употребляемых в ACL базы данных, в списках доступа в документах Server, а также в документах File Protection Web-сервера.

Обнаружение повторяющихся имен при аутентификации клиента

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

Согласование имен и паролей клиентов по протоколам

Если серверы Domino осуществляют аутентификацию клиента с использованием нескольких интернет-протоколов, для простоты администрирования каталога следует создать одну запись каталога для клиента с одним именем и паролем для всех протоколов. Затем следует настроить клиент на использование одного имени и пароля для всех протоколов.

Например, если клиент подключается к Domino через HTTP для просмотра Web-содержимого и через LDAP для работы со службами каталогов, следует создать одну запись каталога для клиента с именем и паролем, после чего настроить клиент на использование этого имени и пароля для всех типов подключений.

Аутентификация клиента Notes

По умолчанию при аутентификации клиента Notes сервер не использует информацию из документов Domino Directory Person для проверки идентификатора Notes. Однако при включении опции Compare Notes public keys against those stored in Directory (Сравнивать открытые ключи Notes с сохраненными в каталоге) на вкладке Basics (Основные параметры) документа Server на сервере сервер выполняет аутентификацию пользователя Notes, только если открытый ключ, предоставленный клиентом Notes, соответствует открытому ключу в документе Person пользователя.

Если пользователь Notes, осуществляющий подключение к серверу для аутентификации, зарегистрирован в дополнительном каталоге Domino Directory, а не в основном каталоге Domino Directory и при этом включена опция Compare Notes public keys against those stored in Directory (Сравнивать открытые ключи Notes с сохраненными в каталоге) для сервера, к которому подключается пользователь, необходимо выбрать опцию Make this domain available to: Notes clients and Internet Authentication/Authorization (Сделать этот домен доступным для: Аутентификации/авторизации Notes- и интернет-клиентов) в документе Directory Assistance, чтобы разрешить серверу выполнять сравнение открытых ключей. Для этого можно применять следующие документы Directory Assistance:

Примечание. Если имя домена, заданное для Domino Directory или Extended Directory Catalog, совпадает с именем домена серверов, использующих базу данных Directory Assistance, серверы могут автоматически применять каталог для аутентификации клиентов, просмотров групп для авторизации базы данных и адресации почты Notes, вне зависимости от того, выбрана ли опция Make this domain available to: Notes clients and Internet Authentication/Authorization (Сделать этодомен доступным для: Аутентификации/авторизации Notes- и интернет-клиентов). Кроме того, серверы сначала осуществляют поиск в каталоге в том же домене, вне зависимости от порядка поиска, заданного для каталога.

Аутентификация клиентов с использованием удаленного LDAP-каталога

Для аутентификации клиентов с использованием удаленного LDAP-каталога доступны следующие возможности:

Вызов Directory Assistance для аутентификации с использованием LDAP-каталога

Процесс аутентификации начинается, когда клиент пытается получить доступ к приложению или базе данных Domino, требующей аутентификации. Пользователю выдается окно запроса пароля, куда пользователь вводит идентификатор и пароль. Затем процесс аутентификации пытается найти запись, соответствующую введенному идентификатору, в каталоге Domino Directory. Если запись найти не удалось, тогда используется список каталогов – Directory Catalog (если он существует), после чего выполняется проверка через Directory Assistance.

Если процесс аутентификации обнаруживает соответствие идентификатору пользователя (при этом поиск соответствия выполняется в нескольких полях), процесс аутентификации возвращает отличительное имя (Distinguished Name, DN), связанное с записью соответствующего пользователя. После этого отличительное имя и пароль, предоставленные пользователем, применяются для создания аутентифицированной связи с каталогом, в котором была найдена запись. Если создание связи прошло успешно, это означает, что пара "отличительное имя/учетные данные" является корректной, после чего пользователь является аутентифицированным. В случае сбоя при создании связи процесс аутентификации продолжает поиск записей, соответствующих предоставленному идентификатору пользователя. Он продолжает этот процесс, пока не найдет первую запись с совпадающей парой "идентификатор пользователя/пароль" или пока не будут просмотрены все сконфигурированные каталоги.

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

11.6.4 Расширенные таблицы управления доступом

Новое в Domino 6

Расширенная таблица управления доступом (ACL) является дополнительной функцией управления доступом к каталогу, доступной для каталога, созданного на основе шаблона PUBNAMES.NTF, – Domino Directory или Extended Directory Catalog. Расширенные ACL дополняют ACL базы данных и ограничивают доступ пользователей к определенным разделам Domino Directory или Extended Directory Catalog. Также они применяют защиту базы данных при просмотрах имен Notes-клиентов, а также при анонимном доступе для LDAP-поиска.

Расширенная ACL привязана к ACL базы данных, и доступ к ней осуществляется через диалоговое окно Access Control List (Таблица управления доступом) клиента Notes 6 или Domino Administrator 6. Расширенные ACL используются для применения ограничений общего доступа, разрешенного пользователю таблицей управления доступом базы данных; их нельзя употреблять для расширения доступа, разрешенного таблицей управления доступом базы данных. Следует употреблять расширенные ACL для назначения доступа:

Расширенные ACL позволяют:

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

Планирование управления доступом к каталогу

Для управления общим доступом пользователей и серверов к Domino Directory следует применять ACL базы данных. Кроме того, можно использовать расширенные ACL для уточнения ACL базы данных и дополнительного ограничения доступа к определенным фрагментам каталога. Расширенная ACL доступна только для Domino Directory и Extended Directory Catalog.

При планировании управления доступом к каталогу следует рассмотреть следующие вопросы:

Запись Anonymous (Анонимный) в ACL базы данных каталога по умолчанию имеет уровень доступа No Access (Нет доступа) и управляет анонимным доступом для всех пользователей, кроме пользователей LDAP. При употреблении расширенной ACL запись Anonymous (Анонимный) в ACL базы данных и расширенной ACL также управляют анонимным доступом к LDAP. Обычно записи Anonymous (Анонимный) не назначается уровень доступа выше Reader.

11.6.5 LDAP-каталоги

Протокол LDAP (Lightweight Directory Access Protocol) является стандартным интернет-протоколом для поиска и управления записями в каталоге. Domino и Notes обеспечивают поддержку LDAP с использованием следующих инструментов:

Конфигурирование фильтров поиска в документе Directory Assistance для удаленного LDAP-каталога

Новое в Domino 6

Можно использовать собственные LDAP-фильтры для замещения встроенных фильтров поиска, используемых средством Directory Assistance при поиске в LDAP-каталоге. Их можно применять для просмотров почтовых адресов, просмотров учетных данных аутентификации клиента и просмотров авторизации группы.

Управление использованием фильтров для поиска в каталоге осуществляется через поле Type of search filter to use (Тип используемого фильтра поиска) в документе Directory Assistance. Возможные опции перечислены в табл. 11.3.

Определение собственных фильтров поиска

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

При выборе опции "Custom" в поле Type of search filter to use (Тип используемого фильтра поиска) выводятся три поля, употребляемые для определения собственных фильтров поиска, как показано в табл. 11.4.

Чтобы определить собственные фильтры поиска, нужно иметь представление о допустимых фильтрах поиска, описанных в RFC 2251 и 2254.

Синтаксис собственных фильтров поиска LDAP

Чтобы определить собственный фильтр поиска, следует добавлять в стандартные фильтры поиска LDAP параметры, представляющие фрагмент имен, которые требуется найти.

11.7 Синхронизация интернет-паролей и паролей Notes

Новое в Domino 6

Можно осуществлять синхронизацию интернет-пароля пользователя, хранящегося в записи Person в каталоге Domino Directory с Notes-паролем пользователя. Это означает, что пользователи могут применять один пароль для входа на сервер Domino через клиент Notes и через Web-браузер. Вы можете выполнить синхронизацию паролей Notes и интернет-паролей для отдельных пользователей во время регистрации пользователя или включить синхронизацию интернет-паролей и паролей Notes для нескольких пользователей на сервере посредством применения документа политики параметров безопасности.

Дополнительные сведения о политиках см. в разделе 11.1.5, "Политики и документы политик".

Изменение пользователем пароля Notes приводит к изменению интернет-пароля.

Важно! Администраторы должны помнить о том, что пользователи, серьезно относящиеся к безопасности, могут обойти синхронизацию паролей Notes и интернет-паролей через диалоговое окно User Security (Безопасность пользователя) и выбрать применение различных паролей в качестве паролей Notes и интернет-паролей. Как ни парадоксально, но это обеспечивает более высокий уровень безопасности и обычно не представляет проблемы. Дополнительные сведения о диалоговом окне User Security (Безопасность пользователя) см. в разделе 11.14, "Безопасность клиента Notes".

11.8 Восстановление идентификаторов Notes

Первым этапом в настройке восстановления ID-файла Notes является настройка централизованной почтовой или базы данных mail-in для хранения зашифрованных резервных копий ID-файлов Notes. Затем необходимо ввести информацию о том, какие администраторы (называемые администраторами центра восстановления -Recovery Authorities) имеют право восстанавливать идентификаторы Notes.

Таблица управления доступом централизованной почтовой или базы данных mail-in должна иметь как минимум следующие настройки:

Корректное определение этой ACL необходимо для защиты резервных копий идентификаторов Notes, которые будут здесь храниться. Поэтому следует уделить большое внимание определению ACL.

Для настройки восстановления идентификаторов ID необходимо выполнить следующие действия:

Примечание. При внесении изменений в этом диалоговом окне кнопка Export (Экспорт) становится недоступной. Нельзя экспортировать информацию восстановления, пока не будет сохранена новая или обновленная информация.

load ca

tell adminp process all

После этого пользователи получат почту Notes, содержащую информацию восстановления. Каждый пользователь должен принять ее, выбрав Action (Действие) -> Accept Recovery Information (Принять информацию восстановления), и сохранить информацию в своем ID-файле Notes. В то же время резервная копия информации восстановления записывается в резервную базу данных идентификаторов.

При регистрации администратором нового пользователя Notes после выполнения этой операции резервная копия ID-файла Notes автоматически записывается в резервную базу данных идентификаторов.

Настройка параметров информации восстановления идентификаторов Notes с использованием смарт-карт

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

Примечание. Зашифрованную резервную копию ID-пользователя Notes можно применять в Notes, только если она будет восстановлена администраторами центра восстановления.

Выполнение восстановления ID-файла Notes и пароля

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

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

Для восстановления идентификатора пользователя Notes, пользователю следует выполнить следующие действия:

Это также может устранить привычку пользователей не устанавливать сложные (т. е. хорошие) пароли из-за страха их забыть.

11.9 Аутентификация Web-клиента

Существует несколько вариантов аутентификации Web-клиентов, пытающихся получить доступ к Web-серверу Domino. К ним относятся:

Более подробное описание некоторых из вышеперечисленных вариантов аутентификации приведено в разделе 6.2.4, "Аутентификация Web-клиента", тогда как более подробное описание LTPA находится в разделе 7.2, "LTPA".

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

11.9.1 Аспекты количества вариантов имен

Вы можете выбрать уровень ограничения имен, применяемый Domino при аутентификации пользователей в каталогах Domino Directory и LDAP-каталогах. Этот параметр относится ко всем интернет-протоколам (HTTP, LDAP, IMAP, POP3). Использование этого параметра снижает уязвимость сервера к атакам на систему безопасности, настраивая поиск имен и аутентификацию интернет-клиентов в Domino. Domino также применяет этот параметр, когда Java-апплет, расположенный на сервере Domino, выполняет аутентификацию пользователей с применением протокола Domino IIOP.

Fewer name variations with higher security (Меньше вариантов имен с более высокой безопасностью)

Опция Fewer name variations with higher security (Меньше вариантов имен с более высокой безопасностью) используется по умолчанию и является рекомендуемой опцией для обеспечения более высокой безопасности. Этот метод аутентификации менее уязвим к атакам, так как при одной попытке аутентификации создается меньше соответствий, что снижает вероятность соответствия взятого наугад пароля. Пользователь может ввести в диалоговом окне имени и пароля в Web-браузер или интернет-клиент только те варианты, которые представлены в табл. 11.7.

More name variations with lower security (Больше вариантов имен с более низкой безопасностью)

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

11.9.2 Многосерверная аутентификация на основе сеансов (SSO)

Многосерверная аутентификация на основе сеансов, также называемая единой регистрацией (single sign-on, SSO), позволяет Web-пользователям выполнить однократный вход на сервер Domino или WebSphere и затем осуществлять доступ ко всем остальным серверам Domino или WebSphere в том же домене DNS, поддерживающим единую регистрацию (SSO), без выполнения повторной процедуры входа.

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

Настройка среды многосерверной аутентификации состоит из следующих действий:

Дополнительные сведения о конфигурировании многосерверной среды единой регистрации на основе LTPA см. в лекции 14, "Подробности реализации сценария", которая содержит образец сценария, представляющего такую среду.

Контрольный список включения единой регистрации

Используйте следующий контрольный список как инструкцию при конфигурировании своей среды Domino, чтобы обеспечить успешность конфигурирования SSO.

Основные аспекты

Аспекты WebSphere

Настройка Web SSO для нескольких доменов Domino

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

Чтобы настроить документ Web SSO Configuration на несколько доменов Domino:

11.9.3 Web-пользователи из дополнительных каталогов Domino Directory и LDAP-каталогов

При аутентификации Web-клиента на сервере по умолчанию сервер проверяет основной каталог Domino Directory на наличие сертификата клиента в документе Person. Если ваша организация использует дополнительный каталог Domino Directory или LDAP-каталог для проверки сертификатов клиентов, вы можете настроить Domino на проверку в этих дополнительных каталогах. Для этого необходимо настроить дополнительный каталог Domino и LDAP-каталог в качестве доверенных доменов в базе данных Directory Assistance.

Если вы отмечаете домен как доверенный, Domino выполняет поиск пользователя в основном каталоге Domino Directory, после чего осуществляет поиск в доверенном дополнительном каталоге Domino и LDAP-каталогах. При настройке средства Directory Assistance указывается, в каком порядке Domino должен выполнять поиск в дополнительных каталогах.

Кроме того, Domino просматривает основной каталог Domino Directory и дополнительные каталоги, с которыми установлены доверительные отношения, при добавлении SSL-сертификатов клиента в Domino Directory с использованием приложения Domino Certificate Authority. Однако нельзя добавлять сертификаты клиентов в LDAP-каталог, даже если LDAP-каталог установлен на сервере Domino.

Рекомендуется использовать SSL для защиты информации, пересылаемой между сервером и сервером LDAP-каталога.

Иерархическое имя, возвращаемое Domino Directory или LDAP-каталогом, сверяется с правилом доверия в базе данных Directory Assistance, чтобы убедиться в том, что организация и подразделения соответствуют заданному правилу. Например, если возвращаемое имя пользователя имеет вид Dave Lawson/Acme, документ Directory Assistance должен включать правило */Acme.

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

В целях управления доступом к серверу Domino клиентами, которые он поддерживает, существуют механизмы аутентификации, дополняющие механизмы аутентификации, установленные по умолчанию. Используется механизм Public Key Checking (Проверка открытого ключа), а также права группы пользователей Allow Access (Разрешить доступ) к серверу. Помимо этого применяется средство Password Checking (Проверка паролей). В остальной части раздела описывается этот аспект аутентификации пользователей, а также объясняется его работа и употребление не только для клиентов Notes, но и для альтернативных клиентов, таких, как iNotes.

11.9.4 Сопоставление имен в Domino

При интеграции существующей среды Domino с другими Web-технологиями через механизм единой регистрации или при использовании средой Domino внешнего LDAP-каталога для аутентификации возможности сопоставления имен в Domino могут быть необходимы для непрерывного использования полных имен Notes/Domino в ACL базы данных Domino.

Ниже представлены некоторые примеры ситуаций, когда может потребоваться сопоставление имен:

К счастью, Domino поддерживает некоторые варианты решения этой проблемы, один из которых был впервые реализован в Domino 6:

Использование LDAP-имени в ACL базы данных

Этот подход в действительности не является решением для сопоставления имен, а скорее представляет собой изменение ACL в Domino таким образом, чтобы установить доверие к LDAP-именам. При таком подходе потребуется изменить все ACL базы данных таким образом, чтобы они содержали иерархические имена LDAP вместо оригинальных полных имен Notes.

Например, если изначально ACL содержала запись "William Tworek/Cambridge/IBM" с правами менеджера, LDAP-имя будет иметь вид "uid=tworek/ou=users/o=redbooks/c=us". Обратите внимание на то, что при вводе LDAP-имени в ACL Domino следует заменить запятые, используемые в традиционном синтаксисе LDAP, на символы "/".

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

Включение LDAP DN в качестве "альтернативного" имени в Domino

При данном подходе к постановке имен в соответствие необходимо выполнить обновление всех пользователей в каталоге Domino Directory таким образом, чтобы отличительное имя LDAP каждого пользователя было включено в документ Person в качестве "альтернативного" имени.

Пример использования данного метода представлен на рис. 11.7.

Реализация этого подхода чаще всего осуществляется с использованием одного из инструментов синхронизации каталогов, рассматриваемых в лекции 8, "Стратегии каталогов". Использование такого инструмента позволяет обеспечить синхронизацию двух каталогов; при этом все изменения имен в LDAP-каталоге будут своевременно отражаться в документах Person каталога Domino, обеспечивая непрерывную постановку имен в соответствие.

Повторимся, что эта опция поддерживается в Domino 5.x и Domino 6.02+. Однако она не работает в Domino 6.0 и 6.01.

Включение полного отличительного имени Domino в LDAP-каталог

Эта последняя опция сопоставления имен в соответствие в Domino требует дополнительного времени для настройки, а также требует изменения LDAP-каталога. Ее действие, в сущности, является обратным действию предыдущей опции, т. е. теперь имя Domino распространяется по LDAP-каталогу.

Для реализации этой опции необходимо выполнить следующие действия:

Это изменение в Directory Assistance представлено на рис. 11.8.

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

Эта опция была впервые реализована в Domino 6, поэтому она поддерживается в Domino 6.x, но не поддерживается в Domino 5.x и более ранних версиях.

11.10 Проверка паролей в Domino

Инструмент Password Checking (Проверка паролей) представляет собой средство аутентификации клиентов, обеспечивающее принудительное регулярное изменение пользователями своих паролей и включение защиты базы пользователей. Рассмотрим следующий пример. Если кто-либо каким-то образом получит ID-файл пользователя Notes и будет знать пароль для этого идентификатора Notes, он обычно сможет получить доступ к серверу с применением этой копии идентификатора Notes. Однако при включении функции Password Checking в тот момент, когда пострадавший пользователь изменяет свой пароль в настоящем ID-файле Notes, это средство сообщает об изменении серверу. Если какой-либо злоумышленник после этого попытается получить доступ к украденной копии ID-файла Notes, ему будет отказано в доступе к серверу.

При включении администратором функции Password Checking он может установить опцию Required Change Interval (Интервал обязательного изменения) (изменяется в днях), которая принуждает пользователей изменять пароли для своих ID-файлов Notes в течение заданного интервала времени. С приближением даты истечения срока действия пароля клиент Notes просит пользователя изменить свой пароль. Помимо интервала изменения администратор может задать опцию Grace Period (Период отсрочки). Он содержит значение (опять же измеряемое в днях), которое указывает временной интервал (по окончании срока действия пароля), в течение которого пользователь должен изменить свой пароль. Как в R5, так и в Version 6 по истечении интервала изменения и периода отсрочки пользователю будет отказано в доступе к серверу до тех пор, пока администратор не переустановит его учетную запись в документе Person пользователя. Это отличается от способа работы клиентов Notes до версии R4.67. Дальнейшее описание относится к клиентам R5 и Version 6.

11.10.1 Система проверки паролей Notes и Domino

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

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

Информация для проверки паролей в ID-файле пользователя Notes

Относительно проверки паролей ID-файл пользователя Notes содержит следующие элементы:

Информация для проверки паролей в Domino Directory

Относительно проверки паролей Domino Directory содержит элементы, представленные в табл. 11.9 и 11.10.

Запись информации на стороне сервера в идентификатор пользователя Notes

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

Наблюдение за запланированной задачей Adminp для проверки паролей.

Откройте базу данных запросов администрирования, после чего вы сможете увидеть запрос Set password information (Настройка информации о паролях).

При открытии документа, содержащего запрос Adminp, выводится имя запроса, а также определенные параметры. Пример из п. 2 представлен на рис. 11.10.

(рис 11.10) Запланированная задача Adminp для проверки паролей

Наблюдение за выполнением задачи Adminp для проверки паролей.

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

(рис 11.11) Задача Adminp для проверки паролей

Открыв документ Person для этого пользователя, вы можете убедиться в том, что поля Check Password (Проверять пароль), Change Interval (Интервал изменения) и Grace Period (Период отсрочки) были заполнены должным образом.

Обратите внимание на то, что поле Password digest (Дайджест пароля) в документе Person осталось пустым. Это не ошибка, так как пользователь не выполнял аутентификацию на сервере с момента включения проверки паролей.

Когда пользователь пытается получить доступ к серверу, используя свой идентификатор пользователя Notes (и после аутентификации сертификата), клиент Notes проверяет, включена ли проверка паролей на сервере, и, если она включена, проверяет, включена ли проверка паролей в документе Person. В нашем примере эти проверки возвратили значение true.

Помимо этих проверок, также выполняется проверка в базе данных admin4.nsf на наличие незавершенных запросов. В нашем примере клиент определяет незавершенный запрос Adminp и копирует параметры Grace Period (Период отсрочки) и Change Interval (Интервал изменения) в ID-файл Notes. После их принятия клиент создает новый запрос на изменение в базе данных admin4, подтверждающий, что идентификатор пользователя Notes получил параметры Grace Period (Период отсрочки) и Change Interval (Интервал изменения). Этот запрос теперь также включает дайджест текущего пароля из ID-файла и текущую дату.

Используя встроенный инструмент для изучения идентификатора пользователя Notes, можно увидеть, что установлена новая структура, как показано в примере 11.1.

PWD_KEY_HDR
Type: 0000
Version: 0000
LastChanged: TIMEDATE
Innards: 0025 69DC 0039 822B
Text format: 22/01/2001 10:28:08
ExpirationDays: 0000 005A
NextExpirationDays: 0000 005A
NumDomains: 0001
NumOldPwds: 0001
OldPwdTotLen: 0214

Когда Adminp впоследствии обрабатывает новый запрос на изменение, параметр Password digest (Дайджест пароля) сохраняется в документе Person пользователя вместе с параметром Last Changed Date (Дата последнего изменения), отражая инициализацию пароля. Чтобы в этом убедиться, можно просмотреть требуемый документ Person, как показано на рис. 11.12.

После того как мы убедились в том, что документ Person содержит дайджест текущего пароля пользователя, проверка паролей для этого идентификатора пользователя Notes и для этого сервера настроена и выполняется.

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

11.10.2 Получение доступа к серверу и схема процесса

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

Проверка даты окончания срока действия

Файл NOTES.INI содержит переменную CertificateExpChecked. Эта переменная определяет имя текущего ID-файла Notes, используемого клиентом, и дату последнего применения идентификатора пользователя Notes. При загрузке программного обеспечения Lotus Notes клиент Notes выполняет проверку этого параметра.

Если дата, указанная в параметре CertificateExpChecked, меньше сегодняшней даты, выполняется проверка идентификатора пользователя Notes, чтобы убедиться в том, что он имеет действительный актуальный сертификат и, при необходимости, предупредить пользователя, о том, что срок действия его пароля может заканчиваться; для этого используется формула, представленная в примере 11.1.

Where дата окончания срока действия = (дата последнего изменения
+ интервал изменения)
{If (дата окончания срока действия - текущая дата) < (25% интервала изменения)
{вывод предупреждения
}
}

При проверке даты, указанной в параметре CertificateExpChecked, пользователю выдается предупреждение только раз в сутки.

Однако при выдаче предупреждения выводится диалоговое окно Password Expiry (Окончание срока действия пароля), как показано на рис. 11.13. Это диалоговое окно содержит сведения о дате окончания срока действия пароля. Пользователь нажимает OK и решает, что ему следует делать.

Подключение к серверу

При подключении пользователя к серверу клиент проверяет документ Server, чтобы определить, настроена ли проверка пароля на сервере. Если она настроена, то выполняется проверка в документе Person пользователя с установленным параметром Check Password (Проверять пароль).

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

Дата 22/04/2001 определяется по следующей формуле:

(Дата последнего изменения пароля) + (интервал изменения, заданный в ID)

В R4 на данном этапе пользователь мог получить доступ к серверу, нажав OK. Такому пользователю давалась отсрочка еще на несколько дней, чтобы он мог изменить пароль, прежде чем будет заблокирован доступ к серверу. Однако по советам клиентов было внесено значительное изменение.

В клиентах после версии R4.6.7, клиентах R5 и клиентах Version 6 пользователь не может получить доступ к серверу, пока он не изменит свой пароль. В данном случае при нажатии OK ошибка исчезает, однако, когда пользователь пытается получить доступ к серверу, он получает еще одно предупреждение, показанное на рис. 11.15.

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

В R5 и Version 6 период отсрочки определяется как время после окончания срока действия пароля, но когда пользователь еще может изменить свой пароль, прежде чем будет заблокирована учетная запись (в период отсрочки пользователь не сможет выполнить вход на сервер, на котором включена проверка паролей). В клиентах до версии R4.6.7 период отсрочки представлял собой продление даты окончания срока действия пароля; пользователь все еще мог получить доступ к серверам, но с течением времени получал все более строгие предупреждения до тех пор, пока его учетная запись полностью не блокировалась в конце периода отсрочки.

Блокировка идентификатора пользователя

В нашем примере в качестве периода отсрочки для пользователя задано значение 30 дней. Если пользователь применит клиент R5 или Version 6, это дает пользователю 30-дневный временной интервал, в который он должен изменить пароль в применяемом ID-файле Notes, если он хочет снова получить доступ к какому-либо серверу с включенной проверкой паролей. После завершения этого 30-дневного периода отсрочки потребуется вмешательство администратора сервера, который бы вручную переустановил учетную запись пользователя, изменив документ Person для этого пользователя; 30-дневный период является достаточным, так как в случае, если срок действия пароля завершится в день ухода пользователя в отпуск, при возвращении он сможет изменить пароль и продолжить работать без вмешательства администратора.

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

На данном этапе клиентское программное обеспечение Notes не позволит пользователю получить доступ к серверу.

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

Однако это нельзя считать заменой применению списков отказа в доступе.

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

Разблокировка учетной записи

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

Этот процесс достаточно прост, однако возможны ошибки, если администратор не выполнит весь процесс Adminp или по ошибке изменит не те поля.

Например, при удалении дайджеста пароля в документе Person, при следующем входе пользователя на сервер, ему все еще будет отказано в доступе (такое поведение является корректным, так как ID-файл пользователя Notes все еще содержит прошедшую дату окончания срока действия пароля). Однако когда пользователь изменяет пароль в своем ID-файле, дайджест пароля в файле user.id также обновляется, однако так как в документе Person дайджест отсутствует, не выполняется проверка дайджеста пароля и пользователь получает доступ. Так как дата последнего изменения является более поздней, чем дата, записанная в документе Person, клиент генерирует запрос к Adminp.

На рис. 11.17 показан запрос к Adminp, сгенерированный клиентом для информирования сервера о новом изменении пароля.

После завершения обработки запроса процессом Administration Process документ Person пользователя содержит те же значения параметров Password Digest (Дайджест пароля) и Last Change Date (Дата последнего изменения), что и ID-файл пользователя. После передачи запроса с клиента на сервер в ID-файле не выполняется никаких изменений. Пользователь теперь может получить доступ к серверу.

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

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

11.10.3 События проверки паролей

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

Предупреждения, рассмотренные выше, представлены как в блок-схеме, так и в псевдокоде. Кроме того, они содержат некоторые дополнительные проверки, выполняемые сервером для обеспечения синхронизации дайджестов и дат. Например, когда клиент отправляет на сервер дайджест идентификатора пользователя с отметкой времени, настолько опережающей время сервера, что сервер решает, что на клиенте проблемы с системным временем. В такой ситуации на клиенте будет выдано следующее сообщение: Connection failed because of a problem with clock synchronization and password change intervals. Check your clock setting, change your password, or consult your system administrator (Подключение не было установлено из-за проблем с синхронизацией времени и интервалов изменения паролей. Проверьте настройку времени, смените пароль или обратитесь к системному администратору).

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

Блок-схема изображена на рис. 11.19, а псевдокод приведен в примере 11.3.

Загрузка клиентского программного обеспечения
Пользователю выдается запрос на ввод пароля
if NOTES.INI CertificateIsExpChecked = системная дата
{/
/ да
Разрешается доступ клиента к локальной базе данных
}else
{/
/ нет
if (системная дата > дата окончания срока действия) or (систем-
ная дата < дата последнего изменения)
{/
/ да
print " Вы должны изменить свой пароль, его срок действия закон-
чился dd-mm-yyyy"
}else
{/
/ нет
if (системная дата - дата окончания срока действия) < (25% интер-
вала изменения)
{print "ПРЕДУПРЕЖДЕНИЕ: срок действия вашего пароля закончится ddmm-
yyyy"
}}}if клиент подключился к серверу
{/
/ нет
if включена проверка паролей в документе Server
{if включена проверка паролей в документе Person
{if дайджест пароля в документе Person = EMPTY
{/
/ да
if дата последнего изменения в документе Person = EMPTY
{/
/ да
Изменение пароля пользователя в адресной книге
Обновление даты последнего изменения и дайджеста пароля в ID пользователя
Обновление даты последнего изменения и дайджеста пароля в документе Person
Разрешается доступ клиента к серверу
Проверка наличия незавершенных запросов к AdminP, обрабатываемых клиентом
}else
{/
/ нет
if дата последнего изменения + 3 часа > текущая дата
{/
/ да
Изменение пароля пользователя в адресной книге
Обновление даты последнего изменения и дайджеста пароля в ID пользователя
Обновление даты последнего изменения и дайджеста пароля в документе Person
Разрешается доступ клиента к серверу
Проверка наличия незавершенных запросов к AdminP, обрабатываемых клиентом
}else
{/
/ нет
Разрешается доступ клиента к серверу
Проверка наличия незавершенных запросов к AdminP, обрабатываемых клиентом
}}}
{
// нет
if дата последнего изменения в документе Person = EMPTY
{/
/ да
print "Ошибка на сервере: срок действия вашего пароля закончился
(...)"
Клиент уничтожает дайджест пароля в ID-файле пользователя
В доступе к серверу отказано
Процесс проверки пароля завершен
}else
{/
/ нет
If (интервал изменения + период отсрочки) <
системная дата - дата последнего изменения)
{/
/ да
print "Ошибка на сервере: срок действия вашего пароля закончился
(...)"
Клиент уничтожает дайджест пароля в ID-файле пользователя
В доступе к серверу отказано
Процесс проверки пароля завершен
}else
{/
/ нет
if пользователь изменил свой пароль
{/
/ да
Изменение пароля пользователя в адресной книге
Обновление даты последнего изменения и дайджеста пароля в ID пользователя
Обновление даты последнего изменения и дайджеста пароля в документе Person
Разрешается доступ клиента к серверу
Проверка наличия незавершенных запросов к AdminP, обрабатываемых клиентом
}else
{/
/ нет
if дайджест пароля в ID = дайджест пароля в документе Person
{/
/ да
if срок действия пароля в ID-файле закончился
{/
/ да
print "ПРЕДУПРЕЖДЕНИЕ: срок действия вашего пароля закончится
(...)"
Изменение пользователем своего пароля
Изменение пароля пользователя в адресной книге
Обновление даты последнего изменения и дайджеста пароля в ID пользователя
Обновление даты последнего изменения и дайджеста пароля в документе Person
Разрешается доступ клиента к серверу
Проверка наличия незавершенных запросов к AdminP, обрабатываемых клиентом
}else
{/
/ нет
В доступе к серверу отказано
Процесс проверки пароля завершен
}}else
{/
/ нет
print "Другая копия вашего ID-файла содержит другой пароль (...)"
В доступе к серверу отказано
Процесс проверки пароля завершен
}}}}}}}
}

11.10.4 Дополнительная информация

Изменения периода отсрочки и интервала изменения пароля следует выполнять с использованием действий процесса Adminp. Редактирование полей непосредственно в документе Person препятствует генерированию запросов Adminp и нарушает синхронизацию идентификатора пользователя Notes, что впоследствии приведет к проблемам с блокировкой.

Так как предупреждения на стороне клиента выводятся прежде, чем пользователь получит доступ к серверу (например, Warning: Your password will expire on dd/mm/yy ), отключение проверки пароля в документе Server не устранит эти предупреждения. Однако это позволит идентификатору пользователя Notes получить доступ к серверу даже после окончания срока действия пароля. Чтобы устранить предупреждения, пользователь должен изменять пароли с частотой, определяемой значениями Last Change Date (Дата последнего изменения), Grace Period (Период отсрочки) и Expiration Date (Дата окончания срока действия), сохраненными в идентификаторе.

Примечание. Недостаточно очистить значение Last Change Date (Дата последнего изменения) в документе Person, чтобы разблокировать идентификатор пользователя и дать ему возможность получить доступ к серверу.

Если администратору требуется заблокировать доступ определенного пользователя к серверу, он может отправить adminp-запрос Lockout the user (Блокировка пользователя). При обработке запроса процессом adminp вносятся изменения в документ Person; при этом в поле Check Passwords (Проверять пароли) устанавливается значение Lockout ID. Когда пользователь попытается получить доступ к серверу снова, он получит сообщение об ошибке, подобное показанному на рис. 11.20.

В данном примере описание относится к односерверной инсталляции. При многосерверной инсталляции существуют некоторые особенности, которые могут вызвать отклонение доступа пользователей к определенным серверам. Так как все изменения производятся в файле names.nsf на сервере администрирования, Domino осуществляет репликацию, чтобы другие серверы могли получить обновления. Изменение документа Person (например, очистка дайджеста пароля) для переустановки учетной записи пользователя на одном сервере даст возможность пользователю снова осуществлять доступ ко всем остальным серверам, на которых включена проверка паролей, но только после репликации изменений в Domino Directory.

Во время тестирования перед развертыванием работа системы может несколько отличаться от приведенного здесь описания. Проблема часто заключается в том, что результаты тестирования записываются до обработки adminp-запросов. Также не рекомендуется тестировать проверку паролей с периодом отсрочки и интервалом изменения в 1–2 дня. Перед каждым действием следует убедиться в том, что выполняется обработка незавершенных adminp-запросов. Это также относится и к рабочим серверам. Например, если пользователь изменяет свой пароль два раза, тогда оба adminp-запроса на изменение пароля должны быть обработаны перед записью финального результата. Если будет обработан только первый запрос на изменение, информация дайджеста не будет синхронизирована, пока второй запрос на изменение не выполнит обновление документа Person.

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

11.10.5 iNotes и проверка паролей

Так как планируется использовать iNotes Web Access с серверами Domino, применение проверки паролей вызывает следующий вопрос: будет ли пользователям iNotes выдаваться запрос на изменение пароля, если их срок действия закончился в связи с включением проверки паролей?

Так как пользователи iNotes применяют интернет-пароль для доступа, им не будет выдаваться запрос на изменение пароля после истечения срока его действия при включенной проверке паролей на сервере. Когда эта функция включена на сервере, он делает недействительным пароль, связанный с идентификатором Notes. Если пользователь применяет и iNotes Web Access и клиент Notes, ему будет предложено сменить свой пароль для клиента Notes. В настоящее время не реализовано принудительное изменение интернет-пароля.

11.11 Таблицы управления доступом к базе данных

Базы данных и приложения Notes защищаются с использованием таблиц управления доступом (ACL), шифрования базы данных и защищенного употребления элементов дизайна базы данных для создания базы данных или приложения. В этом разделе рассматривается употребление ACL базы данных. Дополнительные сведения о функциях защиты дизайна приложений в Domino Designer 6 см. в руководстве из серии IBM Redbooks "Domino 6 Designer: A Developer's Handbook", SG24-6854.

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

Как администратор базы данных, вы выбираете уровень доступа, тип пользователя и привилегии уровня доступа для каждого пользователя или группы в базе данных. В качестве дополнительной настройки дизайнер базы данных может определить роли. Роль определяет набор пользователей и серверов и используется в элементах дизайна базы данных или функциях для ограничения доступа к этим элементам или функциям. Например, роль UserCreator в ACL Domino Directory должна назначаться тем администраторам, которым требуется создавать документы Person.

По умолчанию новая база данных содержит следующие записи в ACL:

Изо всех применяемых по умолчанию записей ACL только Anonymous (Аноним) и имя пользователя создателя базы данных определены как Person в ACL.

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

Anonymous (Аноним) и -Default- – единственные записи, относящиеся к базе данных и не связанные с записью в Domino Directory. Например, запись LocalDomainServers (Серверы локального домена) создается автоматически в Domino Directory и добавляется в ACL при создании базы данных. Запись Anonymous (Аноним) создается только при создании базы данных.

-Default-

Пользователи и серверы получают уровень доступа, определенный записью -Default-, если им не был назначен другой уровень доступа, либо индивидуально, либо в составе группы, либо с использованием записи-шаблона. Кроме того, если ACL базы данных не содержит записи Anonymous (Аноним), тогда пользователи, осуществляющие анонимный доступ к базе данных, получают уровень доступа -Default-. Заданный по умолчанию уровень доступа для записи -Default- зависит от дизайна шаблона базы данных и варьируется для различных шаблонов.

Уровень доступа, назначаемый записи -Default-, зависит от требуемого уровня безопасности базы данных. Выберите No Access (Нет доступа), если требуется, чтобы база данных была доступна для ограниченного числа пользователей. Выберите уровень доступа Author (Автор) или Reader (Читатель), чтобы сделать базу данных доступной для общего использования. Запись -Default- должна иметь тип пользователя Unspecified (Неопределенный).

Удаление записи -Default- из ACL невозможно.

Anonymous (Аноним)

Доступ к базе данных на уровне Anonymous (Аноним) назначается интернет-пользователям и пользователям Notes, не прошедшим аутентификацию на сервере.

Используемая по умолчанию ACL-запись Anonymous (Аноним) для всех шаблонов базы данных (.NTF-файлов) имеет уровень доступа Reader (Читатель), так что пользователи и серверы могут осуществлять чтение шаблона при создании или обновлении .NSF-файлов на основе шаблона.

Употребляемая по умолчанию ACL-запись Anonymous (Аноним) для файлов базы данных (.NSF-файлов) имеет уровень доступа No Access (Нет доступа).

Имя пользователя-создателя базы данных

Имя пользователя-создателя базы данных представляет собой иерархическое имя пользователя, создавшего базу данных. По умолчанию пользователю, создавшему базу данных, назначается уровень доступа Manager (Менеджер). Обычно для этого пользователя сохраняется уровень доступа Manager (Менеджер) или назначается уровень доступа Designer (Дизайнер).

LocalDomainServers (Серверы локального домена)

Группа LocalDomainServers (Серверы локального домена) содержит серверы из того же домена, что и сервер, на котором хранится база данных, и создается по умолчанию в каждом каталоге Domino Directory. При создании новой базы данных группа LocalDomainServers (Серверы локального домена) имеет уровень доступа Manager (Менеджер). Для осуществления репликации изменений в дизайне базы данных в пределах домена группа должна иметь доступ по меньшей мере на уровне Designer (Дизайнер). Для группы LocalDomainServers (Серверы локального домена) обычно устанавливается более высокий уровень доступа, чем для группы OtherDomainServers (Серверы других доменов).

OtherDomainServers (Серверы других доменов)

Группа OtherDomainServers (Серверы других доменов) содержит серверы, находящиеся вне домена сервера, на котором хранится база данных, и по умолчанию создается в каждом каталоге Domino Directory. При создании новой базы данных по умолчанию группа OtherDomainServers (Серверы других доменов) имеет уровень доступа No Access (Нет доступа).

Допустимые записи ACL

Записи-шаблоны

Чтобы разрешить общий доступ к базе данных, можно ввести в ACL иерархические имена с подстановочным символом (*). Можно использовать подстановочные символы в компонентах общего имени и имени подразделения. Пользователи и серверы, которые еще не имеют записи имени пользователя или группы в ACL и чьи иерархические имена включают компоненты, содержащие подстановочный символ, получают наивысший уровень доступа, определенный каждой совпадающей записью-шаблоном.

Ниже представлен пример ACL-записи в формате шаблона.

Эта запись назначает заданный уровень доступа следующим пользователям:

Эта запись не назначает заданный уровень доступа пользователям:

Подстановочный знак можно использовать только в самой левой позиции записи ACL. Например, нельзя применять запись

для представления записей

При использовании записи-шаблона ACL следует установить тип пользователя Unspecified, Mixed Group или Person Group.

Имена пользователей

Можно добавлять в ACL имена пользователей с сертифицированными идентификаторами Notes или интернет-пользователей, осуществляющих аутентификацию с использованием имени и пароля или посредством SSL-аутентификации.

При добавлении пользователей Notes следует ввести полное иерархическое имя для каждого пользователя, например John Smith/Sales/Acme, вне зависимости от того, находится ли пользователь в одной иерархической организации с сервером, хранящим базу данных.

Для интернет-пользователей следует ввести имя, выводимое в качестве первой записи в поле User name (Имя пользователя) документа Person.

Примечание. В поле User name (Имя пользователя) можно ввести много синонимов, которые можно применять для аутентификации; однако только первое имя в списке используется для выполнения проверки авторизации безопасности. Это имя следует применять во всех ACL базы данных Domino, в параметрах безопасности в документе Server и в .ACL-файлах.

Имена серверов

Вы можете добавлять имена серверов в ACL для управления изменениями, получаемыми базой данных из реплики базы данных. Для обеспечения более высокого уровня безопасности, следует использовать полное иерархическое имя сервера (например, Server1/Sales/Acme ), вне зависимости от того, относится ли добавляемый сервер к другой иерархической организации по отношению к серверу, содержащему базу данных.

Имена групп

Добавление имени группы (например, Training) в ACL осуществляется для представления нескольких пользователей или серверов, требующих одинакового уровня доступа. Пользователи должны быть указаны в группах с основным иерархическим именем или с альтернативным именем. В качестве имен групп можно также указывать записи с шаблонами. Прежде чем использовать имя группы в ACL, необходимо создать группу в Domino Directory, в дополнительном каталоге Domino Directory или во внешнем LDAP-каталоге, настроенном на групповую авторизацию в базе данных Directory Assistance.

Группы представляют собой удобный способ администрирования ACL базы данных. Использование группы в ACL имеет следующие преимущества:

Замечание. Можно также использовать группы, чтобы разрешить определенным пользователям управлять доступом к базе данных, не назначая им уровень доступа Manager (Менеджер) или Designer (Дизайнер). Например, можно создавать группы в Domino Directory для каждого требуемого уровня доступа к базе данных, добавлять группы в ACL и разрешать определенным пользователям быть владельцами групп. Эти пользователи могут изменять группы, но не могут изменять дизайн базы данных.

Группа уволенных сотрудников

После ухода сотрудников из организации необходимо удалить их имена изо всех групп в Domino Directory и добавить их в группу Deny List Only, используемую для запрета доступа к серверам. Список Deny Access (Запрет доступа) в документе Server содержит имена пользователей и групп Notes, больше не имеющих доступа к серверам Domino. Вам следует также убедиться в том, что имена уволенных сотрудников удалены из ACL всех баз данных в вашей организации. При удалении сотрудника из Domino Directory, у вас есть вариант Add deleted user to deny access group [Добавить удаленного пользователя в группу Deny Access (Запрет доступа)], если такая группа была создана; если такой группы не существует, выводится диалоговое окно No Deny Access group selected or available [Группа Deny Access (Запрет доступа) не выделена или недоступна)].

Альтернативные имена

Альтернативное имя представляет необязательный синоним, назначаемый администратором зарегистрированному пользователю Notes. Допускается добавление альтернативных имен в ACL. Альтернативное имя обеспечивает такой же уровень безопасности, какой обеспечивает и основное иерархическое имя пользователя. Например, у пользователя с основным именем Sandra Brown/West/Sales/Acme альтернативное имя может иметь формат Sandra Smith/ANWest/ANSales/ANAcme, где AN – альтернативное имя.

Пользователи LDAP

Для аутентификации интернет-пользователей можно использовать дополнительный LDAP-каталог. Затем можно добавлять имена этих интернет-пользователей в ACL базы данных для управления доступом к базам данных.

Также в дополнительном LDAP-каталоге можно создавать группы, включающие имена интернет-пользователей, и затем добавить группы в качестве записей в ACL базы данных Notes. Например, интернет-пользователь может попытаться получить доступ к базе данных на Web-сервере Domino. Если Web-сервер осуществляет аутентификацию пользователя, и если ACL содержит группу с именем Web (Веб), сервер может посмотреть имя интернет-пользователя в группе Web (Веб), расположенной во внешнем LDAP-каталоге, помимо поиска записи в основном каталоге Domino Directory. Обратите внимание на то, что для того, чтобы этот сценарий работал, база данных Directory Assistance на Web-сервере должна включать документ LDAP Directory Assistance для LDAP-каталога с включенной опцией Group Expansion (Расширение групп). Эту функцию также можно применять для просмотра имен пользователей Notes, хранящихся в группах внешнего LDAP-каталога для проверки ACL базы данных.

При добавлении имени пользователя или группы LDAP-каталога в ACL базы данных следует использовать LDAP-формат имени, однако при этом в качестве разделителя необходимо применять слеш ( ,). Например, если имя пользователя в LDAP-каталоге имеет следующий вид:

uid=Sandra Smith,o=Acme,c=US

в ACL базы данных необходимо ввести следующее:

uid=Sandra Smith/o=Acme/c=US

При вводе имени для неиерархического имени группы LDAP-каталога в ACL следует вводить только значение атрибута без имени атрибута. Например, если неиерархическое имя LDAP-группы имеет вид

cn=managers

в ACL нужно ввести только

managers

При вводе имени для иерархического имени группы следует включать имена LDAP- атрибутов в записи ACL. Например, если иерархическое имя группы имеет вид

cn=managers,o=acme

в ACL следует ввести

cn=managers/o=acme

Обратите внимание на то, что, если заданные вами имена атрибутов точно соответствуют именам атрибутов, используемым в ( cn, ou, o, c ), ACL не отображает атрибуты.

Например, при вводе в ACL следующего имени:

cn=Sandra Smith/ou=West/o=Acme/c=US

так как атрибуты точно соответствуют используемым в Notes, имя отображается в ACL следующим образом:

Sandra Smith/West/Acme/US

Примечание. При аутентификации пользователей во внешнем LDAP-каталоге, при которой эти пользователи имеют соответствующие записи в Domino Directory, в Domino 6 может быть включена сопоставления имен в соответствии, при которой имена Domino можно использовать в ACL. Дополнительные сведения о постановке имен в соответствии см. в лекции 8, "Стратегии каталогов".

Anonymous (Аноним)

Любой пользователь или сервер, осуществляющие доступ к серверу без предварительной аутентификации, известны на этом сервере под именем Anonymous (Аноним). Анонимный доступ к базе данных назначается интернет-пользователям и пользователям Notes, не прошедшим аутентификацию на сервере.

Анонимный доступ обычно используется в базах данных, расположенных на общедоступных серверах. Вы можете контролировать уровень доступа к базе данных, назначаемый анонимному пользователю или серверу, введя имя Anonymous (Аноним) в таблицу управления доступом и назначив соответствующий уровень доступа. Обычно анонимным пользователям назначается уровень доступа Reader (Читатель) к базе данных.

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

Анонимным пользователям [как тем, для которых назначен доступ к базе данных через запись Anonymous (Аноним), так и тем, которые осуществляют доступ через запись -Default-], пытающимся выполнить некоторые действия в базе данных, не разрешенные их уровнем доступа, будет предложено пройти аутентификацию. Например, если для записи Anonymous (Аноним) установлен уровень доступа Reader (Читатель) и анонимный пользователь попытается создать новый документ, ему будет предложено пройти аутентификацию по имени и паролю.

Замечание. Если требуется, чтобы все пользователи проходили аутентификацию в базе данных, убедитесь в том, что ACL содержит запись Anonymous (Аноним) с уровнем доступа No Access (Нет доступа), а также что не включены разрешения Read Public Documents (Чтение открытых документов) и Write Public Documents (Запись открытых документов). Затем следует добавить имя интернет-пользователя в ACL с требуемым уровнем доступа.

Сервер Domino использует имя группы Anonymous (Аноним) исключительно при проверках управления доступом. Например, если запись Anonymous (Аноним) имеет уровень доступа Author (Автор) в ACL базы данных, в поле Authors (Авторы) этого документа будет выводиться действительное имя пользователя. Сервер Domino может отображать только действительные имена анонимных пользователей Notes, но не имена анонимных интернет-пользователей в поле Authors (Авторы) документа. Поле Authors (Авторы) не является средством безопасности, вне зависимости от того, применяется ли анонимный доступ; если в целях безопасности требуется достоверность имени автора, то документ следует подписать.

Идентификаторы реплик

Для того чтобы агент в одной базе данных мог использовать @DbColumn или @DbLookup для извлечения данных из другой базы данных, следует ввести идентификатор реплики базы данных, содержащей агент, в ACL базы данных, содержащей извлекаемые данные. База данных, содержащая агент, должна иметь как минимум уровень доступа Reader (Читатель) к базе данных, содержащей извлекаемые данные. Обе базы данных должны находиться на одном сервере. Пример идентификатора реплики в ACL базы данных имеет следующий вид: 85255B42:005A8fA4. При вводе идентификатора реплики можно использовать символы как верхнего, так и нижнего регистра, но не заключать их в кавычки.

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

Порядок оценки записей ACL

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

Журнал ACL

Вы можете вывести журнал всех изменений, внесенных в ACL базы данных. Каждая запись в списке показывает, когда произошло изменение, кто сделал изменение и что было изменено. В журнале сохраняется только 20 строк изменений, а не вся история. Только пользователи с уровнем доступа Manager (Менеджер) в ACL могут просматривать журнал ACL.

Примечание. При включении ACL для расширенного доступа (Extended Access) ограничение в 20 строк снимается. Журнал также включает больше информации об изменениях в расширенном доступе.

Максимальный интернет-доступ с использованием имени и пароля

Пользователи, осуществляющие доступ к базе данных через браузер Интернета или интрасети, не могут быть идентифицированы в Notes таким же способом, как и пользователи Notes. Следует применять параметр Maximum Internet name password access (Максимальный интернет-доступ с использованием имени и пароля) для осуществления контроля над максимальным типом доступа к базе данных через браузер Интернета или интрасети. Список содержит стандартные уровни доступа для пользователей Notes.

Эта опция относится к пользователям, применяющим аутентификацию по имени и паролю или осуществляющим анонимный доступ к серверу через Интернет и подключающимся к серверам через TCP/IP-порт или через SSL-порт. Данная опция не относится к пользователям с идентификаторами SSL-сертификата клиента, осуществляющим доступ к базе данных через Интернет по SSL-порту. Пользователям с клиентским SSL-доступом назначается уровень доступа, определенный в ACL базы данных.

Следует добавить запись для группы Anonymous (Аноним) в ACL базы данных, если это подходит для этой базы данных. Затем следует выбрать максимальный уровень доступа к определенной базе данных, который требуется назначить всем пользователям Интернета и интрасети, применяющим аутентификацию по имени и паролю. Пользователи, осуществляющие доступ к базе данных Notes через Интернет либо анонимно, либо посредством аутентификации по имени и паролю, никогда не будут иметь более высокий уровень доступа, чем определенный параметром Maximum Internet name password access (Максимальный интернет-доступ с использованием имени и пароля).

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

Например, пользователь Sandra Smith/West/Sales/Acme может получить доступ к серверу через Web-браузер с применением имени и пароля. Если пользователю Sandra Smith/West/Sales/Acme в ACL назначен уровень доступа Editor (Редактор), а в параметре Maximum Internet name password access (Максимальный интернетдоступ с использованием имени и пароля) установлен уровень доступа Reader (Читатель), применяется более низкий из двух уровней доступа и пользователю Sandra разрешается доступ на уровне Reader (Читатель). Подобным же образом, если пользователю Sandra Smith/West/Sales/Acme в ACL назначен уровень доступа Reader (Читатель), а в параметре "максимального" уровня доступа установлен уровень доступа Editor (Редактор), пользователю Sandra разрешается доступ на уровне Reader (Читатель). Однако если пользователь Sandra Smith также применяет клиент Notes для доступа к базе данных, параметр "максимального" уровня доступа игнорируется и пользователю Sandra разрешается доступ на уровне Editor (Редактор).

По умолчанию для этой опции установлен доступ на уровне Editor (Редактор). Такие задачи, как создание папок, представлений и агентов, неприменимы для интернет-пользователей.

Замечание! Этот параметр можно использовать, чтобы не допустить доступ интернетпользователей к базе данных с применением аутентификации по имени и паролю. Если установить уровень доступа No Access (Нет доступа), база данных будет доступна только для пользователей Notes или интернет-пользователей, осуществляющих аутентификацию с применением SSL-сертификатов клиента.

Фактический доступ

Новое в Domino 6

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

Список Effective Access (Фактический доступ) в локальной реплике базы данных может отличаться от списка Effective Access (Фактический доступ) в реплике на сервере. Вы можете не иметь такой же уровень доступа к Domino Directory для чтения групп при работе в локальных репликах.

Для определения фактического доступа пользователя, группы или сервера к базе данных следует выделить соответствующую запись в ACL базы данных и выбрать Effective Access (Фактический доступ). Откроется диалоговое окно, которое показывает:

На данном этапе можно определить уровень доступа других пользователей, выделив новое имя в поле Names (Имена) и выбрав Calculate Access (Определить уровень доступа).

Важно! Пользователь также может получить доступ к базе данных, запустив агент с привилегией Unrestricted with Full Access (Неограниченный полный доступ), даже если его имя не указано в ACL базы данных. Такая привилегия существует, но не отражается в списке Effective Access (Фактический доступ), так как она обходит ACL и списки читателей. Например, администратору может потребоваться запустить агент такого типа для базы данных, к которой у него нет доступа, для обновления полнотекстового индекса этой базы данных.

"Принудительное согласование ACL" и локальная репликация

Новое в Domino 6

До выхода Domino 6 пользователи, выполнявшие локальную репликацию базы данных, в которую не был включен параметр enforce consistent ACL (принудительное согласование ACL), получали полный доступ к базе данных без назначенных ролей. В результате пользователь мог изменять параметры, для которых не выполняется репликация. В R6 при локальной репликации базы данных Domino распространяет параметры доступа пользователя в соответствии со сведениями на сервере и при доступности осуществляет их принудительное применение. Это происходит автоматически для локальной репликации, вне зависимости от того, включен ли параметр Enforce a consistent Access Control List (Принудительное согласование таблицы управления доступом). Поведение системы зависит от списка имен, распространяемого при репликации. Изменение не вступает в силу до первой репликации и получения базой данных доступа пользователя с сервера.

Следует отметить, что локальные реплики с включенным параметром Enforce a consistent access control list (Принудительное согласование таблицы управления доступом) пытаются учитывать информацию в ACL и определяют, кому и что разрешается делать. Однако они имеют некоторые ограничения. Одно ограничение состоит в том, что информация о группах генерируется на сервере, а не в локальной реплике. При локальной репликации базы данных информация об участии в группах пользователя, выполняющего репликацию, сохраняется в базе данных для употребления при проверке ACL. При осуществлении доступа к локальной реплике пользователем, отличным от пользователя, выполнившего репликацию, не будет доступна информация об участии в группах для этого пользователя и ACL сможет применять для проверки доступа только личную информацию пользователя, но не информацию об участии в группах.

При включенном параметре Enforce consistent ACLs (Принудительное согласование ACL):

При невключенном параметре Enforce consistent ACLs (Принудительное согласование ACL):

Защита ACL базы данных

Записи ACL по умолчанию

Другие записи ACL

Общая безопасность базы данных

11.12 Безопасность почты

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

Функции управления входящей почтой, описанные в этой лекции, включают контроль спама с использованием параметров управления ретрансляцией входящих сообщений (inbound relay controls) и фильтры-"черные списки", а также управление почтовой политикой посредством применения параметров управления получением входящих сообщений (inbound recipient controls) и почтовые правила.

Обеспечение целостности сообщений включает защиту передачи сообщения и защиту содержимого сообщения. Чтобы обеспечить безопасную передачу сообщений между клиентами и серверами, почтовый сервер Domino поддерживает аутентификацию по имени и паролю и протокол Secure Sockets Layer для маршрутизации SMTP-почты, IMAP и доступ POP3. Для шифрования и подписания сообщений клиенты Notes могут использовать шифрование Notes с использованием ID-файлов и открытых-закрытых ключей или защиту электронной почты с применением сертификатов X.509. Клиенты электронной почты могут использовать сертификаты X.509. В Notes для внешней почты (через Интернет) используется S/MIME для цифровых подписей, шифрования сообщений и обеспечения целостности сообщений.

Дополнительные сведения об использовании цифровых подписей и S/MIME в почте Notes см. в лекции 6, "Инфраструктуры открытых ключей".

11.12.1 Контроль спама

Термин "спам" был придуман в середине 80-х, и со временем его значение претерпело некоторое развитие. Первоначальное его значение определяло поведение, которое сейчас называется переполнением (flooding). В прошлом спаммеры использовали открытые SMTP-ретрансляторы, главным образом для маскировки источника своих сообщений. Открытый ретранслятор представляет собой почтовый сервер, принимающий сообщения вне зависимости от адресов источника и назначения. Управление ретрансляцией и контроль спама тесно связаны друг с другом. Для ограничения спама необходимо выполнять проверку ретрансляции. В Domino существует несколько опций для контроля над тем, кто может ретранслировать почту из вашего домена.

Дополнительные сведения о контроле спама в Domino, помимо тех, которые включены в этот раздел, см. в руководстве серии IBM Redbooks Lotus Domino 6 spam Survival Guide, SG24-6930.

Управление ретрансляцией входящих сообщений

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

Используя параметры управления ретрансляцией входящих сообщений, определите:

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

Чтобы блокировать ретрансляции в определенный домен или с определенного узла, необходимо установить ограничения в параметрах управления ретрансляцией входящих сообщений в документе Configuration Settings на сервере [Router/SMTP -> Restrictions and Controls (Ограничения и параметры управления) -> SMTP Inbound Controls (Параметры управления входящими сообщениями SMTP)].

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

В случае конфликта между разрешенным и запрещенным пунктами назначения ретрансляции и между разрешенным и запрещенным источниками ретрансляции запись в поле "Allow..." имеет преимущество. Таким образом, узел, для которого явным образом разрешена ретрансляция, может всегда выполнить ретрансляцию в любой пункт назначения, включая запрещенные пункты назначения. Подобным же образом, если вы разрешите ретрансляции в определенный домен, все узлы смогут осуществлять ретрансляцию в этот домен, включая узлы, для которых ретрансляция была явным образом запрещена. Запрещенные узлы не могут осуществлять ретрансляцию в домены, отличные от явно заданные в поле "Allow...". В табл. 11.12 представлено несколько примеров того, как Domino разрешает конфликты между записями в полях "Allow..." и "Deny..." параметров управления ретрансляцией входящих сообщений.

Примечание. Такое поведение отличается от работы Domino Release 5, в котором, если была запрещена ретрансляция в домен назначения, разрешенный узел-источник не мог осуществлять ретрансляцию в запрещенный домен, а запрещенный источник не мог осуществлять ретрансляцию в любой пункт назначения. Вы можете включить режим работы Release 5 путем включения переменной SMTPRelayAllowHostsandDomains в файле NOTES.INI.

Если одну и ту же запись поместить в список разрешенных и запрещенных пунктов назначения или в список разрешенных и запрещенных источников, Domino отдает предпочтение записи в списке "Deny...". Например, Domino запрещает ретрансляцию в домен xyz.com при настройке параметров управления ретрансляцией в соответствии с табл. 11.14.

Фильтры-"черные списки"

Новое в Domino 6

Черный список (blacklist, blackhole list) представляет собой список известных открытых серверов ретрансляции (например, Open Relay Database и Spamhaus Project). Чтобы избежать попадания незапрашиваемой коммерческой электронной почты (unsolicited commercial e-mail, UCE), или спама, в вашу систему, можно настроить в Domino проверку на наличие серверов-источников входящих SMTP-подключений в одном или нескольких черных списках DNS (DNS blacklists, DNSBL). Черные списки DNS представляют собой базы данных, обслуживаемые специальными DNSBL-серверами, ведущими учет SMTP-узлов, являющихся известными источниками спама или осуществляющих стороннюю открытую ретрансляцию.

При включении черного списка DNS для каждого входящего SMTP-подключения Domino выполняет DNS-запрос к черным спискам на заданных сайтах. При обнаружении подключающегося узла в списке Domino выводит событие в консольном сообщении и в записи в представлении Mail Routing Events (События маршрутизации почты) журнала Notes Log. И консольное сообщение, и запись журнала содержат имя узла (если применяется обратный DNS-просмотр) и IP-адрес сервера, а также имя сайта, на котором указан сервер.

Помимо регистрации события в журнале, можно настроить Domino на отклонение сообщений, полученных от узлов в черном списке, или добавить специальный элемент Notes ($DNSBLSite) для пометки сообщений, полученных от узлов из черного списка.

Указание сайтов черных списков DNS

После включения фильтров-"черных списков" DNS вы можете определить сайт или сайты, которые задача SMTP должна использовать, чтобы определить, является ли подключающийся узел "известным" открытым ретранслятором или источником спама. Следует указать сайты, поддерживающие IP-запросы к черным спискам DNS.

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

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

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

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

Узлы, освобожденные от проверки в черных списках DNS

Во избежание ненужных DNS-просмотров Domino выполняет проверки в черном списке DNS только для тех узлов, для которых установлена проверка ретрансляции, в соответствии с ограничениями ретрансляции входящих сообщений SMTP. Любой узел, авторизованный для ретрансляции, освобождается от проверок в черных списках. Например, по умолчанию Domino применяет ограничения ретрансляции входящих сообщений только для внешних узлов [Router/SMTP -> Restrictions and Controls (Ограничения и параметры управления) -> SMTP Inbound Controls (Параметры управления входящими сообщениями SMTP) -> Perform Anti-Relay enforcement for these connecting hosts (Применение антиретрансляции для заданных подключающихся узлов)]. При использовании заданных по умолчанию параметров для внутренних узлов не осуществляется управление ретрансляцией и они, таким образом, также освобождаются от проверок в черных списках.

Управление обработкой подключений от узлов, обнаруженных в черном списке DNS

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

В любом случае сервер записывает в журнал Notes следующую информацию: IP-адрес и имя хоста (если обратный DNS-просмотр может определить эту информацию), а также имя сайта, на котором указан хост.

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

При пометке сообщений Domino добавляет специальный элемент Notes к сообщениям, полученным от хостов, найденных в черном списке. После того как Domino определил, что подключающийся узел находится в черном списке, он добавляет элемент $DNSBLSite к каждому сообщений, принимаемому им от узла, прежде чем сохранять сообщение в MAIL.BOX. Значение элемента $DNSBLSite указывает на сайт черного списка, в котором был найден узел. Администраторы могут использовать элемент $DNSBLSite для выполнения собственной обработки сообщений, полученных от узлов, указанных в черном списке. Например, вы можете проверить наличие элемента посредством использования языка формул в агенте или представления и выполнять условную обработку сообщений, содержащих элемент, в частности перемещая сообщения в специальную базу данных.

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

Статистика черных списков DNS

Задача SMTP ведет учет статистики, отслеживая общее количество подключающихся узлов, найденных во всех черных списках DNS на всех сайтах, а также количество узлов, найденных в черном списке на каждом используемом сайте. Так как учет статистики осуществляется задачей SMTP, она накапливает данные, полученные на протяжении работы задачи, и эти данные удаляются при остановке задачи.

Вы можете просматривать статистику из Domino Administrator или с использованием команды SHOW STAT SMTP с консоли сервера. Можно далее расширять статистику, определяя, сколько раз тот или иной IP-адрес был найден в одном из заданных черных списков DNS. Для сбора расширенной информации следует установить переменную SMTPExpandDNSBLStats в файле NOTES.INI на сервере. Из-за большого количества значений, генерируемых при настройке расширенной статистики, Domino не ведет запись расширенных статистических показателей по умолчанию.

Примечание. Domino использует IPv4-адреса в запросах к сайтам с черными списками DNS для проверки вхождения подключающегося узла. Если подключающийся узел имеет IPv6-адрес, Domino пропускает проверку вхождения в черный список DNS для этого узла.

Применение параметров управления ретрансляцией входящих сообщений

Новое в Domino 6

При первоначальном создании документа Configuration Settings для сервера по умолчанию параметры управления ретрансляцией входящих сообщений SMTP или параметры антиретрансляции применяются только ко всем внешним узлам, т. е. к узлам, не расположенным в локальном интернет - домене. После установки параметров управления ретрансляцией входящих сообщений можно настроить их применение в Domino путем выбора опций использования ретрансляции входящих сообщений, чтобы контролировать то, на кого распространяются ваши ограничения ретрансляции.

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

Применение ограничений ретрансляции для внутренних узлов

Новое в Domino 6

По умолчанию Domino использует параметры антиретрансляции только для внешних узлов. Внутренние узлы освобождаются от проверок антиретрансляции, так что Domino не рассматривает внутренний узел как потенциальный ретранслятор, даже если он явно указан в поле Deny messages from the following Internet hosts to be sent to external Internet domains (Запретить отправление сообщений во внешние интернет-домены со следующих интернет-узлов) в параметрах управления ретрансляцией входящих сообщений.

В зависимости от вашей среды вам может потребоваться расширить область применения параметров путем наложения ограничений ретрансляции и на внутренние и на внешние узлы. Применение ограничений ретрансляции ко внутренним узлам позволяет достичь более защищенной и контролируемой маршрутизации. Например, вы можете сконфигурировать SMTP-сервер Domino таким образом, что только другие почтовые серверы Domino смогут осуществлять ретрансляцию. Это позволит не допустить использования SMTP-сервера Domino внутренними пользователями, применяющими другие почтовые клиенты (например, POP- или IMAP-клиенты), а также серверами в других внутренних почтовых системах для отправки почты в Интернет.

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

Узел в локальном интернет-домене всегда может осуществлять ретрансляцию во внешние интернет-домены, если только это не запрещено явным образом в поле Deny messages from the following internet hosts to be sent to external internet domains (запретить отправление сообщений во внешние интернет-домены со следующих интернетузлов).

Если внутренний ретранслятор или брандмауэр не применяет собственные параметры управления ретрансляцией, SMTP-сервер Domino может получать почту, не предназначенную для локального пользователя. Если сервер Domino настроен на применение параметров антиретрансляции только для внешних узлов, то почта, полученная от внутреннего ретранслятора или брандмауэра, не подлежит обработке с использованием параметров управления ретрансляцией входящих сообщений, так как система-отправитель, ретранслятор или брандмауэр относятся к тому же локальному интернет-домену. Таким образом, если Router определяет, что интернет-адрес, указанный в команде RCPT TO, не имеет соответствий в представлении $Users в Domino Directory, выполняется отправление сообщения назад в Интернет.

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

По умолчанию при запрете ретрансляции для домена или набора доменов (например, для всех внешних доменов) все узлы в запрещенных доменах подлежат применению параметров управления ретрансляцией. Такой уровень ограничений не позволяют удаленным IMAP- или POP3-клиентам, подключающимся к Domino через интернет-провайдеров во внешних доменах, отправлять исходящую электронную почту, так как Domino не распознает источник сообщения как допустимый источник ретрансляции.

Чтобы убедиться в том, что Domino позволяет POP3- и IMAP-пользователям отправлять исходящую электронную почту, можно настроить параметры ретрансляции таким образом, чтобы разрешить ретрансляцию для всех аутентифицированных пользователей. После того как SMTP-слушатель (listener) Domino определил, что подключающийся узел прошел аутентификацию, он рассматривает подключение как исходящее от локального пользователя и освобождает его от проверки ретрансляции входящих сообщений. Применяйте этот параметр в сочетании с параметрами SMTP-аутентификации в разделе Ports (Порты) документа Server, чтобы разрешить своим POP3-пользователям осуществлять ретрансляцию через ваш домен.

При установке в этом поле значения External hosts (Внешние узлы) ваш сервер Domino установит доверительные отношения для всех серверов, находящихся в вашем домене. Domino игнорирует параметры проверки ретрансляции входящих сообщений для узлов при подключении (при этом Domino выполняет проверку на DNS-сервере, чтобы после использования информации в заголовке IP-пакета SMTP_Caller убедиться в том, что узел находится в вашем домене).

При установке в этом поле значения All connecting hosts (Все подключающиеся узлы) тестирование будет выполняться даже для систем из вашего домена. Это очень полезный параметр, например если вы используете брандмауэр промежуточной буферизации (store-and-forward firewall), не выполняющий проверку ретрансляции.

Последняя опция – None (Нет). При выборе этого параметра Domino игнорирует параметры управления входящими сообщениями для всех подключающихся узлов.

Определение исключений применения параметров на основе имени или IP-адреса узла

По умолчанию после запрета ретрансляции в домене для всех узлов в этом домене выполняется управление ретрансляцией. Можно настроить применение параметров управления ретрансляцией, чтобы позволить некоторым клиентам или серверам в домене осуществлять ретрансляцию (например, серверу sendmail, выполняющему ретрансляцию почты на сервер Domino) путем ввода имен или IP-адресов узлов в поле Exclude these connecting hosts from anti-relay checks (Исключить эти подключающиеся узлы из списка проверки антиретрансляции). Для заданных исключений Domino не применяет параметры управления ретрансляцией входящих сообщений. Применяйте исключения, чтобы узлы, расположенные вне локального интернет-домена, могли использовать SMTP-сервер Domino в качестве ретранслятора для отправления и получения почты из Интернета и в то же время не допускать применения Domino в качестве открытого ретранслятора неавторизованными интернет-узлами.

Примечание. Так как многие интернет-провайдеры применяют протокол DHCP (Dynamic Host Control Protocol) для назначения IP-адреса каждому подключающемуся пользователю, при каждом сеансе IP-адрес пользователя может меняться. В результате определение исключений применения параметров на основе имени или IP-адреса узла является неэффективным для обеспечения ретрансляции для IMAP- и POP3-пользователей, подключающихся к Domino через интернет-провайдера. Для обеспечения ретрансляции для этих пользователей следует включить исключения применения параметров для аутентифицированных пользователей.

Последний параметр предназначен для работы с удаленными пользователями. Если вы предоставили аутентифицированным пользователям осуществлять ретрансляцию, это позволит вашим IMAP- и POP3-пользователям, подключающихся через интернет-провайдера, отправлять почту, применяя ваш сервер.

Выберите Yes (Да), чтобы дать возможность вашим POP3-пользователям отправлять SMTP-почту через ваш сервер. Вам необходимо настроить POP3-клиент на выполнение аутентификации при отправлении SMTP-почты.

11.12.2 Управление политикой электронной почты

Через документ Configuration Settings администраторы Domino могут установить ограничения, определяющие кто, что и кому может переслать, а также установить правила электронной почты на сервере Domino для управления сообщениями, входящими в ваш домен.

Параметры управления получением входящих сообщений

Новое в Domino 6

В ND6 параметры управления получением входящих сообщений (Inbound Intended Recipients Controls) были доработаны. Теперь вы можете принимать только сообщения, адресованные пользователям из вашего домена. Это снижает количество недействительных сообщений в MAIL.BOX.

В поле Verify that local domain recipients exist in the Domino Directory (Проверять существование получателей из локального домена в Domino Directory) выберите Enabled (Включено), чтобы Domino проверял имя подключающегося узла, выполняя обратный DNS-просмотр. Domino проверяет DNS на наличие PTR-записи, ставящий IP-адрес подключающегося узла в соответствие имени хоста. Если Domino не может определить имя удаленного узла из-за неспособности DNS выполнить эту операцию или отсутствия PTR-записи, он не позволяет узлу осуществлять передачу почты. Хотя Domino разрешает первоначальное подключение, позже в SMTP-транзакции он возвращает подключающемуся узлу ошибку в ответ на команду Mail From.

Нельзя использовать подстановочные символы в поле All messages intended only for the following (Все сообщения, предназначенные только для следующих).

Дополнительные сведения см. в REDP-3622.

Правила электронной почты

Новое в Domino 6

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

Правила электронной почты позволяют бороться со спамом следующими способами:

Например, можно создать правило, отклоняющее почту с такими темами, как "make money fast", или поступающую от известного поставщика спама. Подобным образом можно ограничить получение пользователями вложений, не связанных с функциями пользователей, установив правило перехвата сообщений, содержащих в качестве вложений определенные типы файлов (EXE, VBS, VBE, SCR и т. д.), и их перенаправления в базу данных карантина, где администратор может их просмотреть и, возможно, отправить целевому получателю.

Если это не задано явным образом в правиле, Domino не уведомляет отправителя или получателя о том, что правило не позволяет сообщению достичь целевого адреса. Например, если правило приводит к перенаправлению сообщения в базу данных захоронения, Domino не генерирует отчет о невыполненной доставке и не сообщает целевым получателям о том, что предназначенное для них сообщение было перехвачено. С другой стороны, если сообщение инициирует правило с двойным действием Don't deliver message/Send NDR (Не доставлять сообщение/Отправлять NDR), отправитель получает отчет о невыполненной доставке, сообщающий о том, что сообщение было отклонено в связи с настройками политики.

Примечание. Хотя Domino не генерирует уведомление для отправителя, когда условие правила инициирует действие don't accept message (не принимать сообщение), так как правила выполняются при записи почты в MAIL.BOX, отправитель все же может получить уведомление о том, что сообщение было отклонено. Например, если SMTP-слушатель Domino отклоняет сообщение в связи с правилом электронной почты, отправляющий SMTP-сервер получает ошибку, сообщающую о том, что транзакция была отклонена в связи с настройками политики. Обычно серверы, получающие такие ошибки, генерируют отчет о невыполненной доставке для пользователя-отправителя. Подобным образом, когда правило электронной почты не позволяет серверу получить сообщение, клиент Notes, пытающийся записать сообщение в MAIL.BOX, выводит ошибку, сообщающую о том, что сообщение не может быть отправлено.

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

Управление и настройка правил электронной почты выполняется в вашем документе Messaging Settings. Domino сохраняет правила электронной почты, созданные в документе Configuration Settings. При запуске каждый сервер извлекает правила из соответствующего документа Configuration Settings и регистрирует их как мониторы для каждой используемой базы данных MAIL.BOX.

Когда MAIL.BOX получает новое сообщение из какого-либо источника (SMTP-процесса, Router на другом сервере или клиента, содержащего сообщение), сервер оценивает различные поля сообщения с зарегистрированными правилами электронной почты. Каждое сообщение оценивается только один раз. Дополнительные изменения, происходящие после добавления сообщения в MAIL.BOX (в частности, обновления, отражающие количество получателей), не вызывают повторную оценку правил.

Создание правил электронной почты

Создание правил электронной почты выполняется в разделе Messaging (Сообщения) документа Configuration Settings для серверов, на которых применяются правила. Для каждого правила можно задать критерии, используемые сервером для определения того, следует ли применять правило к заданному сообщению (табл. 11.15).

Можно дополнительно изменить условие:

Кроме того, можно определить действие, которое необходимо выполнять при получении сообщения, соответствующего условному выражению, и нажать Add Action (Добавить действие) (табл. 11.16). Можно задавать одно действие для каждого правила.

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

Документ Configuration Settings отображает новые правила электронной почты, только если документ был предварительно сохранен. Перед добавлением правил в новый документ Configuration Settings следует сохранить и закрыть документ. Для добавления правил следует заново открыть документ.

При добавлении нового правила оно вступает в действие только после перезагрузки сервером правил электронной почты. Перезагрузка инициируется автоматически, если задача Server обнаруживает изменение правила при выполнении стандартной проверки документа Configuration Settings. Такая проверка выполняется приблизительно каждые 5 минут.

Можно выполнить принудительную перезагрузку правил сервером, используя консольную команду set rules.

Правила электронной почты и зашифрованные сообщения

Если MAIL.BOX получает зашифрованное сообщение (с использованием шифрования Notes, S/MIME, PGP и т. д.), правила электронной почты сервера обрабатывают все условия правила, основанные на незашифрованной информации в заголовке сообщения (отправитель, важность и получатели), но не обрабатывает условия, основанные на зашифрованной части тела сообщения. Большинство условий правил основаны на информации в заголовке сообщения. Сервер не регистрирует случаи, когда правила не могут обработать сообщение.

Можно также определить, для каких типов сообщений правило инициирует действие, указав тип формы сообщения в условии правила. При определении типа формы сервер выполняет проверку используемой формы сообщения Notes (элемент Form отображается в свойствах документа); он не использует информацию о форме, определенную в элементах сообщения MIME. Все сообщения, хранящиеся в MAIL.BOX, интерпретируются как документы Notes, включая входящие интернет-сообщения в "родном" формате MIME. По умолчанию сообщения, полученные через SMTP, используют форму Memo, за исключением отчетов о невыполненной доставке SMTP, которые Domino интерпретирует с применением формы NonDelivery Report. Существуют следующие основные формы Notes:

11.13 Служба Domino Off-Line Services

Новое в Domino 6

Служба Domino Off-Line Services (DOLS) обеспечивает способ перевода Web-приложений IBM Lotus Domino Release 6 в автономный режим, работы в них и синхронизации изменений с подключенной репликой на сервере Domino. Пользователям необязательно применять клиент IBM Lotus Notes 6, так как доступ к приложениям осуществляется через браузер.

При переводе приложения с поддержкой DOLS (называемого subscription – "подписка") в автономный режим сохраняются почти все функциональные возможности Notes. Пользователи могут выполнять создание, редактирование, удаление, сортировку и категоризацию документов Notes, а также выполнять полнотекстовый поиск. DOLS subscriptions могут осуществлять полноценное использование Java-апплетов, выполнения агентов и потоков заданий. DOLS также поддерживает полную репликацию данных, сохраняет логику приложений и поддерживает полную модель безопас- ности Notes.

Защита DOLS

Для назначения различных политик идентификаторов для пользователей из разных доменов следует использовать документы Offline Security Policy. Например, можно генерировать идентификаторы автоматически для пользователей внутри компании, но требовать, чтобы пользователи из домена за пределами компании предоставляли идентификаторы, которые вы им дали.

Создание документа Offline Security Policy осуществляется в представлении Offline Services в разделе Configuration (Конфигурирование) инструмента Domino Administrator. Раздел Security (Безопасность) содержит следующие опции увеличения безопасности для DOLS subscriptions (табл. 11.17).

11.14 Безопасность клиента Notes

Новое в Domino 6

Функции безопасности Notes позволяют пользователям защищать свою рабочую область и данные. Начиная с Notes 6 большинство функций безопасности, реализованных в Notes, были объединены в одном диалоговом окне с названием User Security (Безопасность пользователя). До Notes 6 пользователи осуществляли доступ к этим функциям через опции меню или через предпочтения пользователей или почты. Диалоговое окно User Security (Безопасность пользователя) дает возможность пользователям:

Дополнительные сведения об изменении параметров безопасности клиента пользователями через диалоговое окно User Security (Безопасность пользователя) см. в справке Notes 6 Client Help.

Администраторам следует помнить о том, что через это диалоговое окно пользователи могут обойти административные параметры безопасности. Например, пользователи могут:

11.14.1 Смарт-карты

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

Сведения о настройке устройств для чтения смарт-карт пользователями с применением клиента Notes см. в справке Notes 6 Client Help.

Сведения о защите серверной консоли с использованием устройства для чтения смарт-карт см. в руководстве Domino 6 Administration Guide.

Требования для эффективного использования смарт-карт

11.14.2 Таблицы управления выполнением

Таблица управления выполнением (Execution Control List, ECL) защищает рабочие станции пользователей от активного содержимого из неизвестных или подозрительных источников и может быть настроена на ограничение выполнения активного содержимого, запуск которого разрешен на рабочих станциях. ECL определяет, разрешено ли объекту, подписавшему код, выполнять код на данной рабочей станции, а также определяет уровень доступа кода к различным функциям рабочей станции. Например, ECL может не допустить выполнение кода другого пользователя на компьютере и предотвратить, таким образом, повреждение или удаление данных.

"Активное содержимое" включает все, что можно запустить на рабочей станции пользователя, включая формулы, скрипты, агенты, элементы дизайна в базах данных и шаблонах, документы с сохраненными формами, действия, кнопки и активные точки (hot spots), а также злоумышленный код (например, вирусы и так называемые троянские кони).

Существует два вида ECL: ECL администрирования, устанавливаемый в Domino Directory (NAMES.NSF), и ECL рабочей станции, хранящийся к личной адресной книге пользователя (NAMES.NSF). ECL администрирования является шаблоном для всех ECL рабочих станций. ECL рабочей станции создается при первой установке клиента Notes. Программа установки копирует ECL администрирования из Domino Directory на клиент Notes для создания ECL рабочей станции.

ECL рабочей станции содержит подписи доверенных авторов активного содержимого. "Доверие" предполагает, что подпись получена от известного и безопасного источника. Например, все шаблоны систем и приложений, поставляемые с Domino или Notes, содержат подпись Lotus Notes Template Development. Подобным же образом все шаблоны и базы данных, разрабатываемые вашей организацией, должны содержать либо подпись разработчика приложения, либо подпись администратора. Для каждой подписи ECL содержит параметры, контролирующие действия, выполнение которых разрешено для активного содержимого, подписанного этой подписью, а также системные ресурсы рабочей станции, к которым активное содержимое может осуществлять доступ.

Если активное содержимое пытается выполнить действия, не разрешенные для подписавшейся стороны, или если подписавшаяся сторона не указана в ECL, Notes генерирует оповещение безопасности выполнения (Execution Security Alert, ESA), указывающее неудавшееся действие, имя подписавшейся стороны и запрещающий параметр ECL. Оповещение предлагает пользователю четыре возможных варианта:

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

Новое в Domino 6

Например, локально запланированные агенты, равно как и ручные агенты, могут генерировать оповещения. Нажмите More Info (Дополнительные сведения), чтобы получить информацию об агенте, сгенерировавшем оповещение.

Новое в Domino 6

В Notes 6 ECL рабочей станции устанавливается в диалоговом окне User Security (Безопасность пользователя). Выберите опцию What Others Do (Что делают другие) в диалоговом окне User Security (Безопасность пользователя), чтобы просмотреть опции доступа рабочей станции, апплетов и JavaScript.

Дополнительные сведения о доступе рабочей станции, апплетов, и JavaScript см. в главе "Защита рабочих станций пользователей таблицами управления доступом" руководства Domino 6 Administration Guide или справку Lotus Notes 6 Client Help.

ECL администрирования

При установке первого сервера в домене Domino создает ECL администрирования по умолчанию, для которого затем можно выполнить дополнительную настройку. ECL администрирования представляет собой шаблон для всех ECL рабочей станции. При создании нового клиента Notes программа установки копирует ECL администрирования из Domino Directory в личную адресную книгу на рабочей станции клиента Notes. В ECL рабочей станции добавляется идентификатор пользователя Notes с полным доступом. Например, при установке клиента для пользователя John Doe пользователь John Doe автоматически добавляется в список подписавшихся сторон ECL.

Если домашний сервер недоступен при установке клиента Notes (например, если пользователь отключен), ECL рабочей станции создается с параметрами по умолчанию, а не копируется из ECL администрирования.

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

ECL администрирования применяется для определения и развертывания настроенных ECL для ваших пользователей. Вы можете управлять изменениями в ECL или разрешить пользователям изменять собственные ECL. Кроме того, вы можете обновлять ECL рабочих станций своих пользователей при изменении требований безопасности – автоматически (посредством использования документа Security Settings, установленного с применением политики) или вручную (предлагая пользователям выполнить обновление ECL своих рабочих станций).

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

Дополнительные сведения о конфигурировании и развертывании ECL см. в главе "Защита рабочих станций пользователей таблицами управления доступом" руководства Domino 6 Administration Guide. Дополнительные сведения о настройке документа Security Settings для развертывания ECL см. в главе "Использование политик" в руководстве Domino 6 Administration Guide.

Инструкции по эффективному использованию ECL

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

При создании защищенных ECL придерживайтесь следующих инструкций: