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

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

В этом разделе мы обсудим, как Lotus Notes и Domino проводят аутентификацию друг друга по порту 1352 протокола TCP с использованием протокола вызова удаленных процедур Notes [Notes Remote Procedure Calls (NRPC)]. Целью этого обсуждения является прояснить процесс и объяснить, что на самом деле происходит каждый раз, когда пользователь вводит пароль и получает доступ к серверу Domino с использованием клиента Notes.

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

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

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

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

Этап 1. Проверка достоверности

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

увеличить изображение
Рис. 6.13. Процесс проверки достоверности в Notes и Domino

Пронумерованные на схеме шаги описаны далее.

1. Сервер читает сертификат "Восток", который Фред отправляет из своего файла Notes ID пользователя, который был подписан Widget. Сервер заинтересован в нем, потому что "Восток" является источником сертификации для сертификата Фреда.
2. Сервер читает открытый ключ Widget из своего собственного файла Notes ID сервера. (Согласно правилу 1, сервер будет доверять открытому ключу любого предка, который хранится в его файле Notes ID сервера.)
3. Сервер использует открытый ключ Widget (который является доверенным, так как находится в его файле Notes ID сервера) для проверки того, является ли сертификат Восток/Widget действительным. (Согласно правилу 2, если сервер доверяет открытому ключу предка, то он будет доверять любому открытому ключу, полученному из сертификатов, которые были выпущены предком.)
4. Сервер читает сертификат Фреда, отправленный из его файла Notes ID пользователя, который был подписан "Востоком".
5. Сервер использует открытый ключ Восток/Widget, который теперь является доверенным, для проверки того, что сертификат Фред/Восток/Widget является действительным. (Согласно правилу 3, доверяем любому открытому ключу, который был сертифицирован любым из доверенных источников сертификации и принадлежит одному из потомков источника сертификации.)
6. Теперь сервер достоверно ознакомился с открытым ключом Фреда.

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

Этап 2. Аутентификация

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

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

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

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

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

Рис. 6.14. Процесс аутентификации в Notes и Domino

Пронумерованные на схеме шаги описаны далее^{2На схеме указан другой алгоритм.}.

7. Сервер генерирует случайное число и ключ сеанса и шифрует их обоих с использованием открытого ключа Фреда.

8. Сервер отправляет зашифрованное случайное число Фреду.

9. Фред получает запрос и расшифровывает его с помощью своего секретного ключа.

10. Фред отправляет расшифрованное число обратно серверу.

11. Сервер сравнивает ответ Фреда с исходным случайным числом.

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

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

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

Отключение аутентификации на основе сертификатов

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

Недостаток от осуществления этого должен быть очевиден. Сервер Domino, для которого разрешен анонимный доступ, не записывает активность пользователей и серверов. [Обычно это выполняется в файле журнала и в диалоговом окне активности пользователей (User Activity).] При анонимном доступе нет никакой возможности узнать, кто осуществляет доступ к базам данных на сервере. Таким образом, подлин ность пользователя невозможно применить для управления доступом к базам данных и элементам дизайна.

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

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

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

На данном этапе приведем шаги, которые необходимо выполнить для разрешения анонимного доступа к серверу Domino со стороны пользователей Notes и других серверов Domino.

1. В Domino Administrator щелкните мышью на закладке Configuration (Конфигурация) и откройте документ Server (Сервер).
2. Щелкните мышью на закладке Security (Безопасность).
3. В разделе Security Settings (Параметры безопасности) включите Allow anonymous Notes connections (Разрешить анонимные соединения Notes).
4. Сохраните документ.
5. Создайте элемент с именем Anonymous (Анонимный) в списках управления доступом (ACL) всех баз данных, для которых вы желаете разрешить анонимный доступ. Задайте соответствующий уровень доступа – обычно доступ с правами Reader (Читатель). Если вы не добавите Anonymous в качестве элемента в ACL, анонимные пользователи и серверы получат доступ Default (По умолчанию).
6. Остановите и перезапустите сервер, чтобы изменения вступили в действие.

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

Server X cannot authenticate you because: the server's Address Book does not contain any cross-certificates capable of authenticating you. You are now accessing that server anonymously. (Сервер Х не может аутентифицировать вас, потому что: адресная книга сервера не содержит никаких перекрестных сертификатов, допускающих вашу аутентификацию. В настоящее время вы осуществляете анонимный доступ к этому серверу.)

6.1.11 Целостность данных с цифровыми подписями

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

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

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

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

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

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

Рис. 6.15. Используемые в Lotus Notes цифровые подписи

Пронумерованные на схеме шаги описаны далее.

1. Алиса решает отправить Бобу сообщение электронной почты Notes. Клиент Notes, видя, что установлен флажок Sign (Подпись), генерирует хеш (используя MD5) сообщения Алисы (результат в сборнике d – "digest").
2. После этого хеш шифруется Notes с использованием секретного RSA-ключа Алисы (с применением RC2), и это означает, что только ее открытый RSA-ключ будет способен расшифровать хеш.
3. Зашифрованный хеш вместе с сообщением отправляется Бобу.
4. Клиент Notes Боба использует открытый RSA-ключ Алисы для расшифровки хеша (снова с применением RC2) (результат в сборнике d).
5. Клиент Notes Боба вычисляет новый хеш на основе отправленного Алисой текста (используя MD5, результат в сборнике d').
6. После этого клиент Notes Боба сравнивает расшифрованный хеш (сборник d) и заново вычисленный хеш (сборник d'), что позволяет Бобу узнать, является ли цифровая подпись действительной или нет. Если два хеша одинаковы, то сообщение действительно пришло от Алисы и не было сфальсифицировано в процессе транзита. Если они различаются, то либо сообщение не от Алисы, либо оно было сфальсифицировано в процессе транзита.

Таким образом, результатом для пользователя является то, что Notes отобразит, кто подписал сообщение, если проверка достоверности подписи прошла успешно. В противном случае Notes отобразит, что не может проверить достоверность подписи.

Процесс цифровой подписи гарантирует две вещи:

1. Отправитель был аутентифицирован, потому что сборник должен быть зашифрован с использованием секретного ключа отправителя.
2. Сообщение прибыло немодифицированным, потому что сборники идентичны.

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