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

Мы обратимся не только к конкретной реализации PKI в Notes и Domino, но и к реализации PKI, ориентированной на Web, которая нацелена на предложение служб и технологий обеспечения безопасности, основанных на стандартах и ориентированных на Интернет.

Мы дадим определение центрам сертификации (Certificate Authorities) и центрам регистрации (Registration Authorities), а также укажем различия между ними. Далее мы объясним понятия набора ключей и сертификатов открытых ключей, а также рассмотрим, как их создать с помощью поставляемых с сервером Domino инструментов.

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

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

Начнем наше рассмотрение с конкретной реализации инфраструктуры открытых ключей (PKI) в Lotus Notes и Domino. Для этого существует две причины:

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

Нам необходимо охватить большой объем информации. В "Основы ИТ-безопасности" мы обсуждали ключевые службы безопасности, которые должна предлагать безопасная система. Это следующие службы: конфиденциальность (confidentiality), аутентификация (authentication) и идентификация (identification), обеспечение целостности (integrity) и невозможность отказа от авторства (non-repudiation).

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

Позже в этом разделе рассмотрены конкретные усовершенствования в Notes версии 6.

6.1.1 Регистрация и сертификация

Перед тем как мы перейдем к подробному рассмотрению PKI, присутствующей конкретно в Notes и Domino, важно поговорить о регистрации и сертификации, так как эти термины часто путают.

Регистрация

Регистрация является действием, при котором подробная информация о пользователе вносится в каталог. В данном случае каталогом является каталог Domino (Domino Directory). Результатом процесса регистрации в Notes и Domino является идентификатор Notes ID.

Сертификация

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

6.1.2 Иерархии сертификации

Когда Lotus был впервые представлен, он предлагал только один тип сертификации: линейную сертификацию (flat certification). В Notes Версии 3 была представлена иерархическая сертификация (hierarchical certification). В этой версии поддерживались как линейная, так и иерархическая сертификация, было возможным генерирование линейных и иерархических сертификатов. Выполнение линейной сертификации перестало быть возможным с выходом версии 5; однако сгенерированные ранее линейные сертификаты поддерживаются в версиях 5 и 6 по принципу обратной совместимости.

Линейные сертификаты

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

Между линейными и иерархическими сертификатами существуют следующие ключевые различия:

• Линейные сертификаты генерируют ID с линейными именами, которые промаркированы одним или более ID источников сертификации Notes. В отличие от этого иерархические сертификаты создают структурированные имена, которые содержат организованные в строгой иерархии имена идентификаторов ID источников сертификации Notes.
• Линейные сертификаты сохраняются исключительно в файле Notes ID, в то время как иерархические сертификаты сохраняются также в публичной адресной книге (Public Address Book).
• При аутентификации пользователей с применением линейных сертификатов аутентификация выполняется только в одном направлении – сервер осуществляет аутентификацию клиента. Пользователь может осуществлять доступ к любому серверу, с которым он совместно использует общий сертификат, предусматривая при этом, что сертификат был определен сервером как доверенный.
• При аутентификации серверов с применением линейных сертификатов аутентификация выполняется в обоих направлениях, оба сервера осуществляют взаимную аутентификацию. Если сервер организации и внешний сервер совместно используют один общий сертификат, они могут осуществлять аутентификацию только в том случае, если оба сервера признали данный сертификат доверенным. Это значит, что один из серверов должен доверять сертификату, который не принадлежит его организации. В случае вашей организации результатом будет то, что любой другой сервер, который владеет этим внешним сертификатом, может осуществлять доступ к вашему серверу. Это огромный риск для безопасности! Значит, любые пользователи или серверы внешней организации должны также представить свои сертификаты с целью обеспечения возможности доступа к серверу вашей организации. Если наша цель состоит в ограничении числа тех, кто может получить доступ к серверу нашей организации, то данный вариант не имеет права на жизнь. Гораздо более безопасно иметь в общем пользовании два сертификата, по одному от каждой организации, и доверять только сертификату, принадлежащему вашей организации.

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

Иерархические сертификаты

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

К примеру, рассмотрим иерархию сертификации, показанную на рис. 6.1. Здесь показана организация с названием Acme, в составе которой находятся три подразделения, находящиеся в Швейцарии, США и Великобритании. Находящееся в США подразделение организации имеет в своем составе еще два подразделения, Восток и Запад.

увеличить изображение
Рис. 6.1. Иерархическая сертификация

При регистрации Сэнди в качестве нового пользователя ее регистрирует администратор подразделения Switzerland/Acme. Одним из результатов этого процесса является пара новых, сгенерированных случайным образом RSA-ключей (секретного/открытого). После этого администратор создает для Сэнди сертификат путем подписания ее нового открытого ключа с использованием секретного ключа источника сертификации Switzerland/Acme. Как результат, ID пользователя Сэнди наследует иерархию сертификации источника сертификации Switzerland/Acme.

В случае Дэйва все очень схоже. При регистрации Дэйва в качестве нового пользователя его регистрирует администратор подразделения Запад/США/Acme. Одним из результатов этого процесса является пара новых, сгенерированных случайным образом RSA-ключей (секретного/открытого). После этого администратор создает для Дэйва сертификат путем подписания его нового открытого ключа с использованием секретного ключа источника сертификации Запад/США/Acme. Как результат, ID пользователя Дэйва наследует иерархию сертификации источника сертификации Запад/США/Acme.

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

В этом примере источник сертификации уровня организации Acme имеет полностью определенное имя "o=Acme". Источник сертификации уровня подразделения организации в Швейцарии имеет полностью определенное имя "ou=Switzerland/o=Acme". Соответственно источник сертификации уровня подразделения организации в США имеет полностью определенное имя "ou=USA/o=Acme", источник сертификации уровня подразделения организации Восток имеет полностью определенное имя "ou=East/ou=USA/o=Acme".

Для Сэнди ее полностью определенным именем является "cn=Sandy/ou=Switzerland/o=Acme".

Для Дэйва его полностью определенным именем является "cn=Dave/ou=East/ou=USA/o=Acme".

При регистрации сервера применяется все то же, с той лишь разницей, что вместо ID пользователя создается ID сервера.

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

Наконец, иерархическая сертификация является решительным шагом вперед, и организации, которые все еще используют линейную сертификацию, должны серьезно рассмотреть переход на иерархическую сертификацию [а соответственно иерархические идентификаторы ( ID ) серверов, пользователей и источников сертификации] по следующим причинам:

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

6.1.3 Идентификаторы (ID) Notes

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

ID-файлы пользователей, серверов и источников сертификации

Notes ID является, по существу, "контейнером" для сертификатов и ключей шифрования. Существует три различных типа Notes ID:

• ID-источников сертификации (Certifier ID). Являются идентификаторами, используемыми для генерирования других ID. Они разделяются на два типа:

  ID-источников сертификации организации (О) и ID-источников сертификации подразделений организации (OU) (organizational unit). При генерировании идентификаторов первым создается ID-источника сертификации организации; это главный идентификатор для домена. Этот ID (если организация достаточно большая) используется по очереди для генерирования ID-источников сертификации подразделений организации. Эти источники сертификации используются позднее для генерирования двух других типов ID: ID-серверов и Notes ID^{1Здесь ошибка: имеются в виду ID пользователей.}.

  • ID-серверов ( Server ID ). Как предполагает их название, используются для серверов, являющихся частью домена Domino. Они уникально идентифицируют каждый сервер в домене.
  • ID-пользователей ( User ID ). Создаются для пользователей, являющихся частью домена Domino. Они уникально идентифицируют каждого пользователя в домене.

  Идентификаторам источников сертификации по причине способности генерировать ID-пользователей и серверов должна быть предоставлена большая защита, чем идентификаторам других типов. Они должны сохраняться на флоппи-дисках и находится в безопасном месте, отличном от жесткого диска сервера. Если вы применяете Domino 6, у вас имеется возможность использования Domino 6 CA, который позволит избежать распространения ID-источников сертификации Notes при употреблении администраторами.

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

• Имя владельца. Файл ID-пользователя может также содержать одно альтернативное имя. ID-источника сертификации может содержать множество альтернативных имен.
• Постоянный лицензионный номер. Этот номер отображает легальность владельца и указывает, какую лицензию имеет владелец на запуск Domino или Notes: североамериканскую или интернациональную.
• Пара сертификатов Notes из ID-источника сертификации. Сертификаты Notes, которые обсуждаются в следующем разделе, являются цифровыми подписями, добавляемыми к ID-пользователя или сервера. Такая подпись, которая генерируется с применением секретного ключа ID источника сертификации, проверяет, что имя владельца ID правильно ассоциировано с конкретным открытым ключом. Как уже упоминалось, этих сертификатов два:
  • Первый сертификат предназначен для использования в Северной Америке, причем как для шифрования данных, так и для предоставления электронной подписи. Каждый из пары ключей в этом сертификате имеет длину 630 бит. Они называются первичными ключами ( primary keys ). Этот сертификат упоминается в Notes 6 как многоцелевой сертификат Notes.
  • Второй сертификат предназначен для интернационального использования, причем только для шифрования данных. Каждый из пары ключей в этом сертификате имеет длину 512 бит. Этот сертификат упоминается в Notes 6 как интернациональный сертификат шифрования Notes.
• Наследственные сертификаты. Для каждого источника сертификациипредка имеется сертификат (как минимум один для источника сертификации организации и по одному для каждого дополнительного источника сертификации подразделений организации).
• Секретный ключ. Notes использует секретный ключ для подписи сообщений, отправляемых владельцем этих секретных ключей, для расшифровки отправляемых их владельцу сообщений и, если ID принадлежит источнику сертификации, для подписи сертификатов.
• (Необязательно.) Один или более секретных ключей шифрования. Они создаются и распространяются разработчиками приложений или пользователями с особыми привилегиями по отношению к базе данных для предоставления другим пользователям возможности шифровать и расшифровывать поля в документе.
• (Необязательно, только для клиентов Notes.) интернет-сертификаты. Интернет-сертификаты используются для обеспечения безопасных соединений по протоколу SSL, а также шифрования и подписи почтовых сообщений S/MIME. Интернет-сертификат выпускается центром сертификации [Certificate Authority (CA)] и подтверждает личность пользователя. Секретный ключ пользователя, связанный с интернет-сертификатом, хранится вместе с этим сертификатом. Мы обсудим это в данной лекции позже.

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

Рис. 6.2 отображает структуру Notes ID, показывая как стандартную часть (которая создается для каждого Notes ID), так и необязательную часть (которая может быть добавлена в ID позднее).

Здесь необходимо отметить две вещи:

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

Рис. 6.2. Notes ID