5.5 Общие ключи в Notes и Domino 7: проверка и аутентификация

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

Правила, определяющие доверие к общим ключам

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

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

Как работает проверка и аутентификация

В следующем примере описывается, как работают проверка и аутентификация при обеспечении безопасности системы. В данном примере пользователь Randi Bowker/ Marketing/East/Acme (клиент) пытается обратиться к Mail-E/East/Acme (сервер).

1. Сервер Mail-E читает общий ключ Acme из файла Mail-E ID. В соответствии с первым из описанных выше правил сервер Mail-E доверяет общему ключу, назначенному для Acme.
2. Пользователь Randi посылает серверу Mail-E информацию, содержащуюся в своем ID-файле. Сервер Mail-E читает из пользовательского ID Randi сертификат, выпущенный Acme для East. Сервер Mail-E использует общий ключ Acme, которому он теперь доверяет, для проверки действительности сертификата East. В соответствии со вторым правилом, если сертификат действителен, Mail-E доверяет общему ключу, назначенному для East.
3. Сервер Mail-E читает из пользовательского ID Randi сертификат, выпущенный East/Acme для Marketing. Сервер Mail-E использует общий ключ East/Acme для проверки действительности сертификата Marketing/East/Acme. И снова, согласно второму правилу, сервер Mail-E теперь доверяет общему ключу, назначенному для Marketing/East/Acme.
4. Сервер Mail-E читает из пользовательского ID сертификат, выпущенный Marketing/East/Acme для Randi. Сервер Mail-E использует общий ключ Marketing/East/Acme,которому он теперь доверяет, для проверки действительности сертификата Randi. В соответствии с третьим правилом, если сертификат действителен, Mail-E доверяет общему ключу, назначенному для Randi.
5. После того как сервер Mail-E установил доверие к общему ключу Randi, начинается процесс аутентификации.
6. Сервер Mail-E посылает случайные данные Randi.
7. Рабочая станция Randi шифрует данные личным ключом и посылает зашифрованные данные серверу Mail-E.
8. Сервер Mail-E с помощью общего ключа Randi дешифрует ответ. Если результат совпадает с исходными данными, Mail-E убеждается в том, что Randi является тем, за кого себя выдает.
9. Процесс повторяется в обратном направлении. Рабочая станция Randi проверяет общий ключ сервера Mail-E, обрабатывая сертификаты Mail-E, а затем, используя только что описанную процедуру запроса-ответа, аутентифицирует сервер.

Проверка общих ключей

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

Этот дополнительный уровень проверки ключа защищает от неверного использования потерянного или раскрытого ID-файла. Как правило, если ID-файл теряется, пользователь должен перерегистрироваться, чтобы можно было создать новый ID-файл и запись в Domino Directory. Если ID-файл оказывается взломан, то общий и личный ключи владельца необходимо заменить (за дополнительной информацией о смене ключей обращайтесь к разделу 5.4, "Смена ключей пользователей и серверов") и этот новый набор ключей нужно сертифицировать (с обновлением записи в Domino Directory). Включив проверку ключа на уровне Domino Directory, вы не дадите атакующему, который завладел старым ID-файлом, использовать его для доступа к серверу, даже если старый ID-файл содержит действительный сертификат.

Новым усовершенствованием в Domino 7 является возможность включить принудительную проверку ключей пользователей Notes и серверов Domino, указанных только в доверенных директориях. Эта возможность позволяет администраторам разрешить пользователям, не указанным в директориях, доступ к базам данных и приложениям на сервере. Например, в списке контроля доступа к базе данных может быть указано, что права Editor предоставляются пользователям, указанным в Domino Directory, а права Reader — всем остальным пользователям. Таким образом, при включении данной опции проверки ключей пользователи, не упомянутые в Domino Directory, также могут обращаться к серверу и применять эту базу данных, в которой они имеют права Reader.

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

Проверка общих ключей включается на закладке Security (Безопасность) документа Server. Щелкните по раскрывающемуся списку Compare public keys (Сравнение общих ключей) и выберите один из следующих вариантов:

• Enforce key checking for all Notes users and Domino servers (Проверка ключей для всех пользователей Notes и серверов Domino). Сравнение значения ключа в сертификатах, передаваемых при аутентификации, со значением ключа в Domino Directory. Любой пользователь или сервер, не указанный в директории, будет считаться не прошедшим проверку и ему не будет предоставлен доступ к серверу.
• Enforce key checking for Notes users and Domino servers listed in trusted directories only servers (Проверка ключей только для пользователей Notes и серверов Domino, входящих в доверенные директории). Сравнение значения ключа в сертификатах, передаваемых при аутентификации, со значением ключа в Domino Directory только для тех пользователей, которые входят в доверенную директорию. Любой пользователь или сервер, не указанные в директории, будут считаться не прошедшим проверку и им не будет предоставлен доступ к серверу.
• Do not enforce key checking (Нет проверки ключей). Если вы хотите, чтобы при аутентификации проверялись только подписи сертификатов, но ключи не сравнивались с содержимым Domino Directory.

Щелкните по раскрывающемуся списку Log public key mismatches (Записывать в журнал сведения о несовпадении ключей) и выберите один из следующих вариантов:

• Log key mismatches for all Notes users and Domino servers (Записывать в журнал сведения о несовпадении ключей для всех пользователей Notes и серверов Domino). Регистрировать в журнале события, происходящие, если значение ключа в сертификате, переданном при аутентификации, не совпадает со значением ключа в Domino Directory.
• Log key mismatches for Notes users and Domino servers listed in trusted directories only (Записывать в журнал сведения о несовпадении ключей только пользователей Notes и серверов Domino, входящих в доверенные директории). Регистрировать в журнале события, происходящие, если значение ключа в сертификате, переданном при аутентификации, не совпадает со значением ключа в Domino Directory только в том случае, если пользователь или сервер входит в доверенную директорию.
• Do not log key mismatches (He записывать в журнал сведения о несовпадении ключей). В журнале регистрируются только ошибки аутентификации.