Инфраструктуры открытых ключей

Качество и длина паролей

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

В предыдущих версиях Notes и Domino при создании или повторной сертификации файлов Notes ID администратор мог указать минимальное количество символов для паролей.

Однако не все идентификационные фразы одинаковой длины являются равными по силе; некоторые из них являются более уязвимыми для атак подбора идентификационных фраз, чем остальные. К несчастью, выбор хороших идентификационных фраз может быть достаточно трудным. Идеальным вариантом будет полностью случайный набор символов алфавита верхнего и нижнего регистров совместно с цифрами и знаками пунктуации (например, Т3-%9&4#_6!), но подобные идентификационные фразы нелегки в запоминании и могут нуждаться в записывании. В отличие от этого идентификационные фразы, состоящие из одного-единственного слова (к примеру, password), обеспечивают слишком слабую безопасность.

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

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

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

• Длина пароля. Пароль пользователя должен иметь количество символов, отображенное в диалоговом окне Change Password (Изменение пароля).
• Качество пароля. Чем выше число, отображенное в диалоговом окне Change Password (Изменение пароля), тем лучше должно быть качество пароля пользователя (0 является минимальным значением, 16 является максимальным). Чем лучше качество, тем тяжелее для других отгадать пароль. Существует заслуживающая внимания позиция, согласно которой качество пароля зависит от смешения используемых букв, цифр и знаков пунктуации. Если качество установлено на определенный уровень, а пользователь пытается ввести пароль низкого качества (такой, как находящиеся в словаре слова, распространенные имена или повторяющиеся символы), то Notes может отклонить пароль и запросить пользователя о введении нового.

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

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

В Domino 6 администраторы могут теперь требовать либо обеспечения минимальной длины пароля, либо минимального качества пароля. Их больше не обязывают использовать качество пароля для введения в действие паролей, которые незначительно лучше, чем обычно применяемые пользователями. Это может быть реализовано посредством политик, а конкретно с помощью документа параметров установки политик безопасности. (За дополнительной информацией обратитесь к документации на Lotus Domino 6 или к файлу помощи Lotus Domino 6 Administrator Help.)

Когда пользователь изменяет свой пароль с применением Domino 6, то, если введен в действие минимальный уровень качества, качество этого пароля оценивается и затем сравнивается с минимальной длиной пароля, указанной для этого файла ID. Если указанный пароль недостаточно сложен, попытка пользователя установить этот пароль отклоняется и пользователь увидит окно с сообщением об ошибке "Your Password is Insufficiently Complex (Ваш пароль недостаточно сложен)".

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

Начиная с версии 4.5 в Notes добавлен процесс проверки паролей на сервере, который продолжает поддерживаться в версии 6.

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

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

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

Как мы разъясняем в обсуждении аутентификации позднее в этой лекции, Lotus Notes использует для аутентификации пару ключей RSA. Это означает, что даже если кто-то разгадает пароль пользователя, то для возможности выдачи себя за другого пользователя этому человеку еще необходимо овладеть файлом ID пользователя. Хранимая в Domino Directory информация не является предметом атак с применением словаря, за исключением тех случаев, когда атакующий также имеет ID-файл.

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

Файл Notes ID и восстановление Notes ID

Функциональная возможность восстановления Notes ID была представлена в версии 5 и продолжает поддерживаться в версии 6. Она предоставляет администраторам возможность восстановления файла Notes ID, если пользователь утерял, повредил или забыл свой пароль для Notes ID.

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

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

Источник сертификации для сайта может выбрать до восьми центров восстановления (Recovery Authorities) (не путать с центрами регистрации [Registration Authorities (RA)], которые авторизованы для восстановления файлов Notes ID, и требовать совместной работы (более чем одного) центров восстановления для обеспечения доступа к файлу Notes ID.

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

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

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

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

Функциональная возможность восстановления Notes ID заменила собой использовавшийся в версиях 4.х Notes Escrow Agent (Агент условного депонирования). С применением этого свойства администраторы могли настроить счет условного депонирования, и, когда в организации регистрировался новый пользователь, новый Notes ID автоматически отправлялся (по электронной почте) агенту условного депонирования. Для администраторов это было способом автоматического хранения резервных копий каждого созданного ими ID.

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

Настройка восстановления Notes ID

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

Все это ясно и лаконично изложено в разделе "Восстановление ID" документации по администрированию Lotus Domino 6 и в файле помощи Lotus Domino 6 Administrator Help.

Выполнение восстановления Notes ID

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

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

Подробное описание процедуры выполнения восстановления Notes ID находится в документации о продукте и в файле помощи Lotus Domino 6 Administrator Help.

6.1.5 Каталог Domino

Информация обо всех идентификаторах Notes ID (включая ID каждого пользователя, сервера и источника сертификации) сохраняется на сервере Domino, а конкретно в базе данных Notes, называемой каталогом Domino (Domino Directory).

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

Рис. 6.7. Каталог Domino

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

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

То же самое верно и для источников сертификации, которые представлены в каталоге Domino документами Certifier. На рис. 6.7 показано, как работает каталог Domino при обслуживании и распространении всех этих сертификатов.

6.1.6 Домен Domino

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

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

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

6.1.7 Иерархия сертификации

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

Один домен, две иерархии сертификации

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

Рис. 6.8. Две независимые иерархии сертификации

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

Два домена, одна иерархия сертификации

В качестве альтернативы существует возможность управлять одной иерархией сертификации в нескольких доменах Domino, как показано на рис. 6.9. В этом примере корпорация Acme имеет две дочерние компании: корпорацию Sprocket и корпорацию Widget. Здесь существует одна иерархия (причем источником сертификации высшего уровня является Acme), но она разделена между двумя доменами, Sprocket и Widget.

Рис. 6.9. Одна иерархия сертификации в двух доменах

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