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

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

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

1. Если для пользователя можно выполнить настройку восстановления, администратору следует это сделать и отправить пользователю почтовое сообщение с прикрепленной информацией восстановления.
2. Пользователь должен открыть почтовое сообщение от администратора, содержащее информацию восстановления.
3. Пользователю нужно выбрать Action (Действие) -> Accept Recovery Information (Принять информацию восстановления).
4. В диалоговом окне Backup ID File (Резервный ID-файл) пользователь должен нажать Send (Отправить), чтобы отправить первоначальный резервный идентификатор пользователя в базу данных восстановления.

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

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

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

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

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

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

   Примечание. Если некоторые пользователи не имеют доступа к своим идентификаторам пользователей Notes, им следует связаться со своим администратором, который может предоставить им зашифрованные резервные копии идентификаторов пользователей Notes. После получения резервной копии идентификатора пользователя Notes такие пользователи могут продолжать выполнение следующих действий.
2. После получения пользователем паролей восстановления следует перезапустить Notes. В диалоговом окне Password (Пароль) при первом входе пользователя в Notes следует нажать OK, не вводя свой пароль.
3. В диалоговом окне Wrong Password (Неправильный пароль) нажмите Recover Password (Восстановить пароль).

   Примечание. Может потребоваться какое-то время подождать появления диалогового окна Backup ID File (Резервный ID-файл).
4. В диалоговом окне Choose ID File to Recover (Выбор ID-файла для восстановления) выберите идентификатор пользователя, который следует восстановить.
5. В диалоговое окно Enter Passwords (Ввод паролей) введите пароли, назначенные пользователю администраторами, повторяя операцию до тех пор, пока не будут введены все пароли и пользователю не будет предложено ввести новый пароль для идентификатора пользователя.
6. Введите новый пароль для идентификатора пользователя Notes, подтвердив его при запросе.

   Внимание. Следует объяснить пользователям, что, если они не введут новый пароль, им придется повторно восстанавливать идентификатор пользователя Notes.
7. И наконец, пользователю следует заменить все резервные копии идентификатора пользователя Notes и применяемые копии идентификатора пользователя Notes на новый восстановленный идентификатор пользователя Notes.

   Настройка восстановления идентификаторов и паролей Notes может показаться довольно сложной и трудоемкой процедурой. Однако важно учитывать следующее:

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

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

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

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

• Аутентификация с использованием имени и пароля.

  Аутентификация с использованием имени и пароля выполняется с применением простого всплывающего окна HTTP с запросом для пользователя. На клиента не отправляются cookie-файлы "cookies", и учетные данные аутентификации никоим образом не кешируются на сервере.
• Аутентификация с использованием имени и пароля на основе сеансов.

  Аутентификация на основе сеансов выполняется с применением HTML-формы с запросом для пользователя. Затем выполняется кеширование учетных данных аутентификации в сеансе, создаваемом в Domino для пользователя, и cookie-файл идентификации сеанса передается в браузер для идентификации пользователя при последующих запросах.

  Этот метод аутентификации позволяет обеспечить постоянство подключения пользователя на одном сервере, а также позволяет выполнить настройку HTML-формы запроса учетных данных входа. Данный метод не обеспечивает поддержку единой регистрации (single sign-on).
• Многосерверная аутентификация на основе сеансов.

  Многосерверная аутентификация похожа на простую сеансовую аутентификацию, с той разницей, что LTPA-cookie передается в браузер, содержащий имя пользователя и осуществляющий проверку действительности аутентификации пользователей. Этот LTPA-токен является доверенным на других серверах, на которых требуется выполнить аутентификацию. Таким образом, этот метод аутентификации поддерживает единую регистрацию (single sign-on) в многосерверной инфраструктуре.

Более подробное описание некоторых из вышеперечисленных вариантов аутентификации приведено в разделе 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-файле.

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

• создание документа конфигурации домена (документа Web SSO Configuration) в каталоге Domino Directory (в домене или каталоге Domino может быть несколько документов Web SSO Configuration, распространяющихся на несколько серверов, или один документ, относящийся к целому домену);
• включение опции Multi-server для аутентификации на основе сеансов в документ Web Site или в документ Server.

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

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

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

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

• URL, назначенные серверам, сконфигурированным для единой регистрации, должны содержать полное доменное имя (fully qualified domain name, FQDN), а не имя хоста или IP-адрес. Чтобы браузеры могли отправлять cookie-файлы группе серверов, DNS-домен должен быть включен в cookie-файл, а DNS-домен в cookie-файле должен соответствовать URL сервера. Поэтому cookie-файлы нельзя использовать между доменами. Все серверы, участвующие в среде SSO, должны находиться в одном DNS-домене).
• Для кластерных серверов в поле имени хоста документа Web Site или Server должно быть указано полное доменное имя (FQDN). Это позволяет Internet Cluster Manager (ICM) осуществлять перенаправление участников кластера с использованием SSO. Если не указать имя хоста DNS-сервера, ICM по умолчанию будет перенаправлять URL на кластерные Web-серверы, для которых указано только одно имя хоста TCP/IP, и не сможет отправить cookie-файл, так как DNS-домен не включен в URL.

Аспекты WebSphere

• WebSphere и Domino должны быть настроены на один LDAP-каталог. Токен аутентификации, используемый для единой регистрации (SSO), содержит полное отличительное имя (Distinguished Name, DN) пользователя, например cn=john smith, ou=sales, o=ibm, c=us. Чтобы настроить LDAP на единую регистрацию, следует установить средство Directory Assistance в Domino и настроить его таким образом, чтобы оно указывало на LDAP-сервер, применяемый WebSphere-сервером. Другое решение состоит в том, чтобы загрузить LDAP в Domino Directory и настроить WebSphere на использование LDAP-сервера Domino.
• Если группа серверов, участвующих в единой регистрации, включает серверы WebSphere, применяющие LDAP-каталог Domino, пользователи с "плоскими" (flat) именами в каталоге не смогут выполнять единую регистрацию (если все участвующие серверы являются серверами Domino, тогда SSO будет работать с flat-именами пользователей).
• SSO-токен должен быть сгенерирован в WebSphere и затем импортирован в Domino. WebSphere не может использовать LTPA-токен SSO, сгенерированный Domino.

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

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

• Вы должны быть зарегистрированным пользователем Notes, и ваш сервер должен быть зарегистрированным сервером. Это дает вам и серверу право на дешифрование документа Web SSO Configuration в вашем текущем домене, а также право на создание документов в Domino Directory для нового домена.
• Документ Server и документ Person администратора должны существовать в домене, для которого вы будете создавать документ Web SSO Configuration, так как открытые ключи, применяемые для шифрования и дешифрования, хранятся во всех зарегистрированных документах Person и Server.

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

1. Скопируйте документ Web SSO Configuration из каталога Domino Directory, в котором он был создан, и вставьте его в каталог Domino Directory в новом домене.
2. Откройте документ Web SSO Configuration для нового домена и отредактируйте поле Participating Domino Servers (Участвующие серверы Domino), включив в него только те серверы с документами Server в новом домене, которые будут настроены на единую регистрацию.
3. Клиент должен быть способен найти документы Server для участвующих серверов с единой регистрацией. Убедитесь в том, что домашний сервер, указанный в документе Location клиента, указывает на сервер в том же домене, что и серверы, участвующие в единой регистрации, чтобы операции просмотра были способны найти открытые ключи серверов. Если домашние серверы не могут найти участвующие серверы, тогда нельзя будет зашифровать документ SSO и единая регистрация не будет работать.
4. Сохраните документ. Он зашифрован для участвующих серверов в новом домене и должен позволить этим серверам в новом домене участвовать в единой регистрации вместе с серверами в первоначальном домене.