Усовершенствования, связанные с восстановлением ID
Идентификатор Notes (Notes ID) - это краеугольный камень модели безопасности Lotus Notes и Domino, поскольку на нем основана инфраструктура общих ключей Notes (public key infrastructure, PKI). Notes ID представляет собой небольшой файл (его размер - несколько килобайтов), содержащий многое из того, что является необходимым для использования возможностей PKI, встроенных в клиент Notes (и сервер Domino).
В этой лекции мы обратимся к файлу Notes ID, расскажем о его вариантах и объясним, что можно сделать в ситуации, когда файл больше нельзя использовать либо из-за повреждения (редкий случай), либо из-за потери (по определенным причинам, редкая ситуация), либо из-за того, что пользователь просто забыл пароль, шифрующий ID-файл (большинство случаев, когда информация, содержащаяся в этой лекции оказывается необходимой).
Независимо от того по какой причине Notes ID оказывается нельзя использовать, это влечет за собой серьезные последствия. Без своего Notes ID пользователи не могут обращаться к серверам, не могут читать сообщения, не имеют доступа к данным, зашифрованным при помощи утерянного ID. Notes ID необходим для доступа к серверам Domino и к зашифрованным данным.
Хотя администраторам следует убеждать пользователей хранить в безопасном месте резервные копии Notes ID (это называется механизмом депонирования и может реализовываться как сохранение файлов Notes ID на диске, хранящемся под замком), это будет решением только для проблемы потерянных или поврежденных ID-файлов. Гораздо более распространенной проблемой является забытый пароль. Лучшим тактическим решением проблем, связанных с потерей и повреждением ID-файлов, а также с забытыми паролями, является настройка в Domino функции восстановления ID-файлов.
К концу данной лекции вы должны понимать механизмы восстановления ID и то, как они были усовершенствованы и расширены в версии 7.0 Notes и Domino.
3.1 Общий обзор Notes PKI и Notes ID
Прежде чем рассматривать восстановление файлов Notes ID, стоит посвятить немного времени и несколько абзацев обзору Notes PKI и Notes ID. Это поможет вам понять, почему Notes ID играет важную роль в Notes PKI и почему потеря Notes ID может полностью закрыть для пользователя систему Notes и Domino.
В представленной лекции не ставится цель дать подробное и полное описание инфраструктур общих ключей (public key infrastructure, PKI), стандартных реализаций PKI и способов реализации PKI. Если вы не знакомы с этими концепциями, мы предлагаем вам обратиться к предыдущей публикации этой серии, Lotus Security Handbook, SG24-7017. Тем не менее мы рассмотрим некоторые ключевые элементы Notes PKI, чтобы вы лучше понимали файл Notes ID и также природу механизмов восстановления, описываемых в этой лекции, а также чтобы не приходилось без необходимости обращаться к другим публикациям.
3.1.1 Регистрация и сертификация
Прежде чем описывать PKI в Notes и Domino, нужно поговорить о регистрации и сертификации, поскольку эти термины часто путают.
Регистрация
Регистрация - это операция, при помощи которой сведения о пользователе заносятся в директорию Здесь имеется в виду Domino Directory. В результате регистрации в Notes и Domino создается Notes ID.
Сертификация
Термин "сертификация" имеет 2 значения, важных для данной лекции и для Notes и Domino. Сертифицировать - это формально удостоверить истинность, точность, подлинность и соответствие стандарту чего-либо. Сертифицировать также означает выпустить лицензию или сертификат. Результатом сертификации в Notes и Domino является создание сертификатов Notes и их запись в Notes ID.
3.1.2 Иерархии сертификатов
Когда система Lotus Notes появилась на рынке, она предлагала только один тип сертификации - плоскую или одноуровневую (flat) сертификацию. В Notes версии 3 появилась иерархическая сертификация. Поддерживалась и одноуровневая и иерархическая сертификация в том смысле, что можно было сгенерировать и одноуровневый и иерархический сертификат. В версии 5 одноуровневая сертификация больше не использовалась, однако ранее сгенерированные сертификаты поддерживались в версиях 5, 6.0, 6.5 и 7.0 для обратной совместимости.
Поскольку одноуровневая сертификация, по сути, ушла в прошлое, мы не будем рассматривать ее здесь, а обратимся лучше к иерархической сертификации.
Иерархическая сертификация
В иерархической сертификации ID сервера и ID пользователя имеют только один сертификатор уровня организации и до четырех уровней сертификаторов подразделений.
Когда пользователи или серверы регистрируются иерархическим сертификатором, они получают сертификат, подписанный этим сертификатором, и наследуют иерархию сертификатов вышестоящих уровней. Для иллюстрации рассмотрим рис. 3.1, где показана организация с именем Acme, имеющая 2 подразделения, Canada и USA, каждое из которых включает 3 подразделения, в которых в конечном счете и проходят регистрацию и сертификацию пользователи.
При регистрации нового пользователя Amy ее регистрирует администратор, отвечающий за сертификатор подразделения East/USA/Acme. Одним из результатов этого процесса является создание новой, сгенерированной на случайной основе пары ключей RSA личный/общий. Затем администратор создает для пользователя Amy сертификат, подписывая ее новый общий ключ при помощи личного ключа сертификатора подразделения East/USA/Acme. В результате ID пользователя Amy наследует иерархию сертификатов сертификатора подразделения East/USA/Acme.
Ситуация с пользователем Luc очень похожа. При регистрации нового пользователя Luc его регистрирует администратор, отвечающий за сертификатор подразделения Montreal/Canada/Acme. Одним из результатов этого процесса является создание новой, сгенерированной на случайной основе пары ключей RSA личный/общий. Затем администратор создает для пользователя Luc сертификат, подписывая его новый общий ключ при помощи личного ключа сертификатора подразделения Montreal/Canada/Acme. В результате ID пользователя Luc наследует иерархию сертификатов сертификатора подразделения Montreal/Canada/Acme.
Пользователи и серверы организации имеют полные имена, основанные на их сертификаторах. Каждый уровень иерархии сертификатов наследует полное имя. сертификатора, использованного при его создании и, в свою очередь, является предшественником для нижележащих уровней.
В данном примере сертификатор уровня организации Acme имеет полное имя "o=Acme". Сертификатор уровня подразделения Canada имеет полное имя "ou=Canada/o=ACME". Сертификатор уровня подразделения USA имеет полное имя "ou=USA/o=ACME", а сертификатор уровня подразделения Montreal имеет полное имя "ou=Montreal/ou=Canada/o=ACME".
Для пользователя Amy полное имя будет "cn=Amy/ou=East/ou=USA/o=Acme". Для пользователя Luc полное имя "cn=Luc/ou=Montreal/ou=Canada/o=Acme".
При регистрации сервера применяется тот же метод, за исключением того, что вместо ID пользователя создается ID сервера.
И наконец, что касается аутентификации, пользователи и серверы могут аутенти-фицировать друг друга, если у них есть как минимум один общий родительский или корневой сертификат. В нашем примере это означает, что все пользователи в организации могут аутентифицировать друг друга, поскольку у них есть общий сертификат Acme. Те сущности, у которого нет общего предшественника, все же могут аутентифицировать друг друга, используя процесс перекрестной сертификации (cross-certification), о котором, чтобы не растягивать книгу, мы рассказывать здесь не будем.