Мы обратимся не только к конкретной реализации PKI в Notes и Domino, но и к реализации PKI, ориентированной на Web, которая нацелена на предложение служб и технологий обеспечения безопасности, основанных на стандартах и ориентированных на Интернет.
Мы дадим определение центрам сертификации (Certificate Authorities) и центрам регистрации (Registration Authorities), а также укажем различия между ними. Далее мы объясним понятия набора ключей и сертификатов открытых ключей, а также рассмотрим, как их создать с помощью поставляемых с сервером Domino инструментов.
После создания соответствующих наборов ключей и генерирования сертификатов мы опишем, как настроить конфигурацию протокола SSL, и объясним, как SSL работает. Нами также предусмотрены некоторые примеры передового опыта по достижению наибольшей безопасности с использованием SSL при одновременном уменьшении оказываемого всем этим на сервер Domino воздействия.
Начнем наше рассмотрение с конкретной реализации инфраструктуры открытых ключей (PKI) в Lotus Notes и Domino. Для этого существует две причины:
Нам необходимо охватить большой объем информации. В лекции 1 мы обсуждали ключевые службы безопасности, которые должна предлагать безопасная система. Это следующие службы: конфиденциальность (
В этой лекции мы покажем, что встроенная в Notes и Domino инфраструктура открытых ключей предоставляет эти службы. Так как конфиденциальность, обеспечение целостности и невозможность отказа от авторства зависят от аутентификации, то основное внимание мы сосредоточим на этой службе безопасности.
Позже в этом разделе рассмотрены конкретные усовершенствования в Notes версии 6.
Перед тем как мы перейдем к подробному рассмотрению PKI, присутствующей конкретно в Notes и Domino, важно поговорить о регистрации и сертификации, так как эти термины часто путают.
Регистрация является действием, при котором подробная информация о пользователе вносится в каталог. В данном случае каталогом является каталог Domino (Domino Directory). Результатом процесса регистрации в Notes и Domino является идентификатор Notes ID.
Сертификация имеет два значения, которые имеют отношение к этой лекции и к Notes и Domino. Сертифицировать – значит официально подтвердить, что нечто является достоверным, правильным, подлинным и соответствующим стандарту. Сертифицировать также значит выдать лицензию или сертификат. Результатом процесса сертификации в Notes и Domino является создание сертификатов Notes и их запись в Notes ID.
Когда Lotus был впервые представлен, он предлагал только один тип сертификации: линейную сертификацию (flat certification). В Notes Версии 3 была представлена иерархическая сертификация (
Линейные сертификаты являются пережитком ранних времен Lotus Notes, и тот факт, что они все еще поддерживаются в версии 6, свидетельствует о приверженности Lotus принципу обратной совместимости. Обсуждением здесь данных сертификатов мы демонстрируем наше желание разобрать в этом справочнике все аспекты обеспечения безопасности. Однако мы рассмотрим важнейшие различия и интересные моменты. Для подробного ознакомления с линейными сертификатами читатели могут обратиться к ранней документации по Lotus Notes.
Между линейными и иерархическими сертификатами существуют следующие ключевые различия:
ID с линейными именами, которые промаркированы одним или более ID источников сертификации Notes. В отличие от этого иерархические сертификаты создают структурированные имена, которые содержат организованные в строгой иерархии имена идентификаторов ID источников сертификации Notes.Так как 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=.
Для Сэнди ее полностью определенным именем является "cn=Sandy/ou=Switzerland/o=Acme".
Для Дэйва его полностью определенным именем является "cn=Dave/ou=.
При регистрации сервера применяется все то же, с той лишь разницей, что вместо ID пользователя создается ID сервера.
Что касается аутентификации, пользователи и серверы могут осуществлять аутентификацию друг друга только в том случае, если они имеют как минимум один общий унаследованный сертификат. В нашем примере это означает, что все пользователи организации могут осуществлять
Наконец, иерархическая сертификация является решительным шагом вперед, и организации, которые все еще используют линейную сертификацию, должны серьезно рассмотреть переход на иерархическую сертификацию [а соответственно иерархические идентификаторы ( ID ) серверов, пользователей и источников сертификации] по следующим причинам:
Основой инфраструктуры открытых ключей Notes является идентификатор ( ID ) Notes. Notes ID является файлом небольшого размера (всего лишь несколько килобайтов), который содержит множество элементов, необходимых для использования служб, которые обеспечивает встроенная в клиент Notes инфраструктура открытых ключей (PKI). В этом разделе выполним обзор и рассмотрим различные типы Notes ID.
Notes ID является, по существу, "контейнером" для сертификатов и ключей шифрования. Существует три различных типа Notes ID:
ID-источников сертификации организации (О) и ID-источников сертификации подразделений организации (OU) (organizational unit). При генерировании идентификаторов первым создается ID-источника сертификации организации; это главный идентификатор для домена. Этот ID (если организация достаточно большая) используется по очереди для генерирования ID-источников сертификации подразделений организации. Эти источники сертификации используются позднее для генерирования двух других типов ID: ID-серверов и Notes ID пользователей.
Server ID ). Как предполагает их название, используются для серверов, являющихся частью домена Domino. Они уникально идентифицируют каждый сервер в домене.User ID ). Создаются для пользователей, являющихся частью домена Domino. Они уникально идентифицируют каждого пользователя в домене.Идентификаторам источников сертификации по причине способности генерировать ID-пользователей и серверов должна быть предоставлена большая защита, чем идентификаторам других типов. Они должны сохраняться на флоппи-дисках и находится в безопасном месте, отличном от жесткого диска сервера. Если вы применяете Domino 6, у вас имеется возможность использования Domino 6 CA, который позволит избежать распространения ID-источников сертификации Notes при употреблении администраторами.
Domino применяет идентификаторы ID для идентификации пользователей и управления доступом к серверам. ID-пользователей, серверов и источников сертификации содержат следующее:
primary keys ). Этот сертификат упоминается в Notes 6 как многоцелевой сертификат Notes.Наконец, секретный ключ и ключи шифрования в файле ID шифруются с использованием ключа, вычисленного на основе пароля пользователя, и, таким образом, получить доступ к нему может только владелец. Открытая информация, такая, как имя пользователя и открытый ключ, не шифруется.
Рис. 6.2 отображает структуру Notes ID, показывая как стандартную часть (которая создается для каждого Notes ID), так и необязательную часть (которая может быть добавлена в ID позднее).
Здесь необходимо отметить две вещи:
ID. Если секретный ключ Notes изменен, то устаревшая информация также сохраняется в файле ID в целях обратной совместимости (к примеру, вам может понадобиться устаревшая информация для прочтения старого зашифрованного письма электронной почты).ID источника сертификации. Это линейный Notes ID, который содержит минимум информации и не будет никак исприменяться во время попыток соединения клиента Notes с сервером в домене.
(рис 6.2) Notes ID
Аутентификация Lotus Notes основана по большому счету на сертификатах Notes, которые хранятся в идентификаторах Notes ID.
Вообще говоря, сертификат является электронной "печатью", которая отображает доверенные взаимоотношения между объектами в мире Notes.
Если более формально, то сертификат является уникальным, обладающим электронной подписью сообщением, добавленным источником сертификации в файл Notes ID, который идентифицирует пользователя или сервер. Наряду с тем что пользователь может хранить и работать как с сертификатами Notes, так и с интернет-сертификатами (в оставшейся части этого раздела упоминаются конкретно сертификаты Notes).
Когда пользователь Lotus Notes пытается соединиться с сервером Lotus Domino, будь то почтовый сервер или другой тип сервера Domino в организации, то для идентификации себя на этом сервере ему необходим сертификат, а серверу необходим сертификат для идентификации данного лица. Соответственно вовлеченные в процесс клиент Notes и сервер Domino представляют друг другу свои сертификаты. Путем проверки сертификатов клиент Notes проведет идентификацию и аутентификацию сервера Domino, а сервер Domino проведет идентификацию и аутентификацию пользователя.
В целях разрешения установления этих доверенных взаимоотношений в сертификатах должно присутствовать определенное число информационных элементов. Сертификат Notes, как и Notes ID, содержит такие элементы, как:
ID. Notes использует открытый ключ для шифрования сообщений, которые посылаются владельцу открытого ключа, и для проверки достоверности подписи владельца ID.Затем все это сертифицируется, что означает – сертификат подписывается цифровой подписью источника сертификации с использованием секретного ключа источника сертификации, в целях подтверждения его аутентичности.
Рис. 6.3 отображает структуру сертификата Notes в составе Notes ID.
(рис 6.3) Сертификат NotesКак уже упоминалось, сертификаты хранятся в файлах Notes ID. Они также хранятся в документах Person (Человек), Server (Сервер) и
Представляя сущность содержимого файлов Notes ID, наилучшим вариантом будет думать о них, как о разновидности специализированной базы данных, которая хранит сертификаты Notes и пары ключей (секретный/открытый). Эта база данных затем шифруется с помощью пароля пользователя.
Когда серверы и пользователи зарегистрированы, Domino автоматически создает сертификат Notes для каждого файла ID сервера и пользователя. Эти сертификаты Notes имеют даты истечения срока действия, что означает необходимость повторного сертифицирования Notes ID по наступлению даты истечения его срока действия.
В дополнение к этому если изменилось имя сервера или пользователя, также должна быть осуществлена повторная сертификация соответствующего Notes ID таким образом, чтобы новый сертификат мог корректно связывать открытый ключ с новым именем.
Примечание. Изменение имени в ID пользователя может также оказать воздействие на представленные в данном файле Notes ID интернет-сертификаты. Мы расскажем об интернет-сертификатах немного позднее; однако заслуживает внимания то, что не только сертификат Notes связан с именем пользователя или сервера в файле Notes ID.
Существует три типа сертификатов Notes, которые могут находиться в вашем ID пользователя:
ID пользователя (User ID), даже если он не применяется.ID пользователя, он уже должен был иметь данный сертификат при модернизации до Notes 5 или выше.Вы можете просмотреть все сертификаты, представленные в ID пользователя Notes путем выбора следующих пунктов меню: File (Файл) – Security (Безопасность) – User Security (Безопасность пользователя) [для пользователей Macintosh будет Notes – Security (Безопасность) – User Security (Безопасность пользователя)]. После этого введите защищающий Notes ID пароль и щелкните мышью на Your Identity (Ваша подлинность) – Your Certificates (Ваши сертификаты). Существует две опции для отображения сертификатов Notes. Выберите опцию "Your Notes Certificates (ваши сертификаты Notes), как показано на рис. 6.4, для просмотра сертификатов, которые могут быть использованы для входа в Notes, для доступа к базам данных Notes и для обмена безопасной почтой с другими пользователями Notes.
(рис 6.5) Сертификаты Notes в Notes ID, опция Your Notes Certificates (Ваши сертификаты Notes)(рис 6.4) Сертификаты Notes при выборе опции All Notes Certificates (Все сертификаты Notes)Для предоставления более полного списка сертификатов Notes выберите опцию All Notes Certificates (Все сертификаты Notes), как показано на рис. 6.5, которая отображает вам все представленные в вашем ID сертификаты Notes, включая ваши сертификаты Notes, а также сертификаты центров сертификации Notes (Notes CA), которые выпустили ваши сертификаты.
Это одно из диалоговых окон, которые значительно изменились со времен R5.0. Отображение информации в вашем Notes ID было значительно упрощено и стало более легким для прочтения. Несмотря на это, потратим некоторое время на обзор списка сертификатов Notes, которые отображены на рис. 6.5.
Два элемента, отмеченные как Frederic Dahm/Switzerland/IBM, являются двумя сертификатами человека по имени Frederic Dahm, причем оба из них подписаны источником сертификации Switzerland/IBM. Один из них является интернациональным ключом с ограниченным размером ключа; другой является полноценным североамериканским ключом. Элемент, отмеченный как /Switzerland/IBM, является источником сертификации швейцарского подразделения, который, в свою очередь, был сертифицирован источником сертификации компании IBM. Наконец, элемент /IBM является источником сертификации IBM (источником сертификации самого высшего уровня в домене).
В сервере Domino и клиенте Notes версии 5.0 добавлена полная поддержка сертификатов x.509 v3. Это значит, что начиная с версии 5 и продолжая в версии 6, для клиента Notes существует возможность запрашивать сертификат у любого центра сертификации, включая центр сертификации Domino 6, и сохранять
Повторно обращая ваше внимание на Notes ID, заметим, что открытый ключ упоминается также как сертифицированный открытый ключ Notes. Он хранится в сертификате Notes. Его дополнение, секретный ключ, хранится в другой части файла Notes ID (как показано на рис. 6.2) и может встречаться только в Notes ID.
Открытые ключи несекретны, отсюда и их название. Любой пользователь может найти открытый ключ другого пользователя и употребить его для отправки пользователю шифрованной почты или для его аутентификации.
Пользователи должны быть способны получить открытый ключ источника сертификации, который выпустил сертификат, еще перед тем, как они смогут провести аутентификацию владельца сертификата. Если пользователь имеет сертификат, выпущенный тем же источником сертификации, который применялся для другого пользователя или сервера, то он может проверить открытый ключ сертификата, после чего достоверно знать, что открытый ключ связан с именем сервера или пользователя. Если пользователь не имеет сертификата, выпущенного тем же источником сертификации, то пользователь нуждается в проведении перекрестной сертификации в целях аутентификации.
Начиная с версии R5.0 существует возможность добавлять в файл Notes ID для пользователя Notes
Альтернативные имена несовместимы с версиями Notes, выпущенными ранее версии 5. В частности, существуют следующие ограничения:
Главной причиной наличия и использования Notes ID является аутентификация. Мы полностью опишем процесс аутентификации с использованием Notes ID в этой лекции позднее; а теперь обратим внимание на пароли.
Пароль, заданный идентификатору ID пользователя Notes во время регистрации, является механизмом защиты файла Notes ID от неавторизованного использования. При попытке применения файла Notes ID пользователю будет нужно ввести пароль для этого файла.
Относительно пароля Notes ID существует некоторая путаница. Он используется исключительно для разблокировки самого файла ID пользователя Notes – и больше ни для чего. Фактически для идентификации пользователя применяется пара ключей, содержащаяся в ID.
Пользователи могут иметь более одной копии своего файла Notes ID, и эти различные копии могут иметь разные пароли. По существу, это означает, что для изменения пароля пользователь должен знать существующий пароль для каждой из копий ID.
Несмотря на то что еще в предыдущей версии Notes была (и остается доступной в версии 6) представлена функциональная возможность восстановления Notes ID, хорошим тоном все еще считается выполнение резервного копирования файлов ID и запоминание их паролей.
Для предотвращения атак методами "подбора по словарю" и "прямого подбора" на пароли файлов ID и для уменьшения риска перехвата пароля в Notes применяется диалоговое окно введения пароля с антиспуфинговой функцией (функцией предотвращения обмана). Данное окно было представлено в версии 4 и получило дальнейшую поддержку в версии 6 Notes.
Если пользователь вводит некорректный пароль, то перед разрешением ему повторной попытки введения пароля Notes несколько секунд ожидает. Эта задержка увеличивается с каждой неудачной попыткой ввода вплоть до своего максимума в 30 секунд. Функция задержки затрудняет попытки ввода множества паролей в быстрой очередности в надежде получить правильную комбинацию.
Антиспуфинговый аспект диалогового окна пароля Notes состоит в изменении шаблона слева от текстового поля ввода пароля.
В версиях 4 и 5 этот шаблон был представлен в виде набора из четырех иероглифических символов. В версии 6 эти иероглифы были заменены на изображение кольца для ключей, к которому прикреплены различные объекты (такие, как ключи, карманный фонарик, карманный нож и т. д.), изменяющиеся после набора пятого символа. Этот новый дизайн показан на рис. 6.6.
(рис 6.6) Диалоговое окно ввода пароля NotesДанные динамические символы делают более затруднительной подмену на фальшивое диалоговое окно, которое перехватывает пароли, выдавая себя за диалоговое окно ввода паролей Notes. Пользователи должны быть осведомлены об особенностях данного окна и о факте изменения символов при вводе ими паролей. Если пользователи замечают, что символы не изменяются или вообще отсутствуют, они должны прекратить введение своих паролей и щелкнуть мышью на Cancel (Отмена). Также они должны запомнить последнее изображение после ввода своего пароля, потому что следующий после выведения символов алгоритм будет всегда вычислять один и тот же символ в конце. (Однако алгоритм достаточно сложен, и поэтому не так легко выяснить пароль, обращая внимание только на символы и на способ их изменения.)
Для обеспечения устойчивой безопасности файлов ID серверов и источников сертификации существующим Notes ID можно задавать составные пароли. При реализации указанного существует возможность потребовать, чтобы при использовании Notes ID действовали совместно более одного человека (как правило, это администраторы).
Здесь важно избежать некоторой, обычно присутствующей, путаницы. Когда к Notes ID применяются составные пароли, исходный пароль для Notes ID (или предыдущий, если пароль отличается от исходного) не является более действительным. Эти составные пароли заменяют исходный пароль и не являются кумулятивными (значит, они не добавляют себя к исходному паролю).
Существует также возможность указать, что для доступа к Notes ID требуется только подмножество заданных паролей. К примеру, существует возможность назначить для доступа к указанному Notes ID четыре пароля, но определено, что для доступа к Notes ID требуются только любые два из четырех паролей. Это свойство полезно, когда должны быть отменены положения политики безопасности, дающие полномочия по работе с ID источника сертификации единственному человеку.
Примечание. Мы рекомендуем, чтобы составные пароли задавались только для идентификаторов ID серверов Notes и идентификаторов ID источников сертификации Notes. Идентификаторы ID пользователей Notes не должны иметь заданных им составных паролей. Для установки составных паролей на Notes ID необходимо присутствие всех людей, которые будут задавать пароль для Notes ID. Для установки составных паролей выполните следующие действия:
Наиболее слабой частью инфраструктуры открытых ключей Notes являются выбираемые пользователями пароли, так как – и это хорошо известный факт – пользователи просто не выбирают хорошие пароли. Пароли, которые придумывает большинство пользователей, являются слишком короткими и слишком простыми для догадки (или, что еще хуже, в некоторых случаях они записываются на клочке бумаги рядом с компьютером).
В предыдущих версиях Notes и Domino при создании или повторной сертификации файлов Notes ID администратор мог указать минимальное количество символов для паролей.
Однако не все идентификационные фразы одинаковой длины являются равными по силе; некоторые из них являются более уязвимыми для атак подбора идентификационных фраз, чем остальные. К несчастью, выбор хороших идентификационных фраз может быть достаточно трудным. Идеальным вариантом будет полностью случайный набор символов алфавита верхнего и нижнего регистров совместно с цифрами и знаками пунктуации (например, Т3-%94#_6!), но подобные идентификационные фразы нелегки в запоминании и могут нуждаться в записывании. В отличие от этого идентификационные фразы, состоящие из одного-единственного слова (к примеру, password), обеспечивают слишком слабую безопасность.
Идентификационные фразы со смешанными регистрами, содержащие цифры и пунктуацию, обычно сильнее посимвольно, чем пароли, полностью содержащие символы нижнего регистра. Пароли, которые содержат слова, находящиеся в словарях проверки орфографии, как правило, намного более уязвимы посимвольно, чем любой другой вид пароля.
В Domino версии 5 было представлено новое свойство, которое было встроено на место замененного свойства ограничения минимальной длины пароля. При регистрации пользователя Notes администраторы систем версии 5 могут указывать уровень качества пароля.
Различие между длиной и качеством пароля является простым:
Уровни качества паролей сохраняются в файле ID как эквивалентные длины паролей, и, таким образом, ID-файл, созданный клиентом Notes 6, может использоваться в предыдущей версии Notes.
Так как пользователи не слишком хороши в создании достаточно сложных паролей для обеспечения устанавливаемого системой уровня качества, эта функциональная возможность породила большое разочарование у пользователей и вызвала появление множества запросов с просьбами восстановить функциональную возможность установки длины пароля.
В Domino 6 администраторы могут теперь требовать либо обеспечения минимальной длины пароля, либо минимального качества пароля. Их больше не обязывают использовать качество пароля для введения в действие паролей, которые незначительно лучше, чем обычно применяемые пользователями. Это может быть реализовано посредством политик, а конкретно с помощью документа параметров установки политик безопасности. (За дополнительной информацией обратитесь к документации на Lotus Domino 6 или к файлу помощи Lotus Domino 6 Administrator Help.)
Когда пользователь изменяет свой пароль с применением Domino 6, то, если введен в действие минимальный уровень качества, качество этого пароля оценивается и затем сравнивается с минимальной длиной пароля, указанной для этого файла ID. Если указанный пароль недостаточно сложен, попытка пользователя установить этот пароль отклоняется и пользователь увидит окно с сообщением об ошибке "Your Password is
Начиная с версии 4.5 в Notes добавлен процесс проверки паролей на сервере, который продолжает поддерживаться в версии 6.
Когда разрешена проверка паролей, то информация, зависящая от пароля пользователя и даты предоставления пароля, хранится на сервере в документе Person.
Для получения доступа к серверу пользователь должен ввести пароль, соответствующий хранимой в документе Person информации. Способность проверки паролей добавляет возможность потребовать установку интервалов изменения паролей пользователя и защищает от повторного применения 50 предыдущих, старых паролей.
Это очень хороший способ убедиться в том, что пользователями поддерживаются должные пароли, которые периодически изменяются. При употреблении в соединении с параметрами качества/длины паролей это свойство гарантирует, что созданные пользователями пароли соответствуют минимальным требованиям, изложенным в политике безопасности организации.
Как мы разъясняем в обсуждении аутентификации позднее в этой лекции, Lotus Notes использует для аутентификации пару ключей RSA. Это означает, что даже если кто-то разгадает пароль пользователя, то для возможности выдачи себя за другого пользователя этому человеку еще необходимо овладеть файлом ID пользователя. Хранимая в Domino Directory информация не является предметом атак с применением словаря, за исключением тех случаев, когда атакующий также имеет ID-файл.
Проверка паролей во время аутентификации требует, чтобы и клиенты Notes, и серверы Domino имели в своем распоряжении версию 4.5 или выше. Если вы разрешите проверку паролей на сервере, имеющем версию более раннюю, чем 4.5, то процесс аутентификации происходит без проверки паролей. Если вы разрешите проверку паролей у клиента, работающего на предыдущей версии, процесс аутентификации потерпит неудачу при осуществлении попыток клиента соединиться с сервером, требующим проверки паролей. Когда пользователь, для которого требуется проверка пароля, проходит процесс аутентификации с сервером в первый раз, 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, которые были сертифицированы с применением ID источника сертификации, который не содержит информации о восстановлении.
Все это ясно и лаконично изложено в разделе "Восстановление ID" документации по администрированию Lotus Domino 6 и в файле помощи Lotus Domino 6 Administrator Help.
После того как восстановление 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.
Информация обо всех идентификаторах Notes ID (включая ID каждого пользователя, сервера и источника сертификации) сохраняется на сервере Domino, а конкретно в базе данных Notes, называемой каталогом Domino (Domino Directory).
Каталог Domino содержит документ Person для каждого пользователя, который, в свою очередь, содержит множество информации о каждом из пользователей Notes. В табл. 6.1 показана структура документа Person.
| Закладка | Элементы |
|---|---|
| Basics (Основная информация) | Имя; Инициал второго имени; Фамилия; Имя пользователя; |
| Mail (Почта) | Почтовая система; Файл почты; Адрес пересылки; Интернетадрес; Шифрование входящей почты |
| Certificates (Сертификаты) | Сертифицированный открытый ключ Notes; Интернетсертификат; Ключ линейного имени |
| Administration (Администрирование) | Администраторы; Проверка пароля; Требуемый интервал изменения; Период льгот (grace period); Дата последнего изменения; Сборник паролей; |
(рис 6.7) Каталог DominoПримечание. В процессе регистрации идентификатору ID пользователя Notes, принадлежащему зарегистрированному пользователю, разрешается прикрепляться к документу Person. Это очень не одобряется, поскольку каталог Domino открыт по своей сущности, а идентификаторы ID пользователей Notes должны храниться безопасным образом.
Как результат процесса регистрации
То же самое верно и для источников сертификации, которые представлены в каталоге Domino документами
Как правило, люди путают концепцию иерархии сертификации с концепцией доменов Domino, полагая, что это одно и то же. На самом деле они полностью различны и независимы друг от друга.
Для простоты понимания домен Domino соответствует каталогу Domino. Домен Domino является совокупностью серверов Domino и пользователей, которые совместно применяют общий каталог Domino.
Каталог Domino является каталогом пользователей, серверов, групп и других элементов. По сути, основной функцией домена Domino является маршрутизация почты. Домены пользователей определяются по расположению их почтовых файлов на сервере.
В этом разделе мы рассмотрим несколько различных видов иерархии сертификации, а именно те из них, в которых существует множественная иерархия сертификации или множество доменов. В первую очередь рассмотрим модель, имеющую две иерархии сертификации в одном домене, а после этого опишем модель, имеющую одну иерархию, распределенную между двумя доменами.
Так как иерархия сертификации и домены Domino независимы друг от друга, внутри домена Domino вполне возможным представляется управление двумя и более иерархиями сертификации. В примере, отображенном на рис. 6.8, корпорации Acme и Widget подвергаются администрированию в пределах одного отдельного домена.
(рис 6.8) Две независимые иерархии сертификацииПримером того, что эта модель может быть подходящей, является ситуация, при которой две организации или компании являются недавно слившимися. Существует возможность продолжать управлять этими организациями независимо, без сворачивания обеих иерархий в одну общую, как показано на рисунке; но в конечном счете вы, возможно, захотите осуществить перекрестную сертификацию этих двух иерархий.
В качестве альтернативы существует возможность управлять одной иерархией сертификации в нескольких доменах Domino, как показано на рис. 6.9. В этом примере корпорация Acme имеет две дочерние компании: корпорацию
(рис 6.9) Одна иерархия сертификации в двух доменахПодобная конфигурация, "одна иерархия/два домена", может быть полезна в той ситуации, когда отдельный домен (или каталог Domino) вырос до очень больших размеров и вы должны настроить производительность сервера. Однако, принимая во внимание масштабируемость Domino, особенно в версии 6, и мощность доступных в наше время серверов, это не самый подходящий сценарий. Несмотря на это, такая возможность существует и заслуживает упоминания здесь.
Domino использует два типа перекрестных сертификатов: перекрестные Notes-сертификаты и перекрестные интернет-сертификаты. Перекрестные сертификаты Notes мы опишем в данном разделе, а перекрестные интернет-сертификаты – в разделе об инфраструктуре открытых ключей в Интернете далее в этой лекции.
Перекрестные сертификаты Notes разрешают аутентификацию и безопасный обмен сообщениями, и этим они дают возможность пользователям из различных организаций со своей иерархией сертификации осуществлять доступ к серверам и получать подписанные почтовые сообщения. Перекрестные сертификаты Интернета, с другой стороны, более сфокусированы на обеспечении безопасного обмена сообщениями, и этим они позволяют пользователям получать подписанные почтовые сообщения и отправлять зашифрованные почтовые сообщения.
Рассматривая уже приведенную нами модель с иерархиями сертификации, отметим, что аутентификация одним пользователем другого пользователя или сервера не будет проводиться, если любой из них находится в другом дереве имен.
Важность этой проблемы возрастает в организациях с динамической структурой, которые в наши дни становятся нормальным явлением (когда обычными являются слияния, приобретения, укрупнения и реорганизации).
В связи с этим регулярно возникает вопрос: "Как мы можем соединить несколько иерархий сертификации или деревьев имен?" Ответ состоит в том, что, хотя и невозможно просто и эффективно соединить несколько существующих деревьев сертификации в одну-единственную иерархию сертификации, возможность достичь успеха в этом направлении существует.
Notes и Domino предоставляют людям и серверам метод проведения аутентификации по отношению к другим серверам из других иерархий сертификации. Также они предоставляют людям из одной иерархии сертификации метод эффективного взаимодействия и обеспечения доверия людям из другой иерархии сертификации.
Это достигается посредством перекрестной сертификации, которая является формой одноранговой доверительной модели (сертификации).
Таким образом, если вкратце, перекрестные сертификаты Notes позволяют пользователям и серверам из различных организаций со своей иерархией сертификации осуществлять доступ к серверам организаций друг друга и проверять цифровые подписи пользователей из другой организации. Серверы Domino хранят перекрестные сертификаты в каталоге Domino. В целях обеспечения доступа к серверам Domino клиенты Notes получают перекрестные сертификаты для этих серверов и хранят их в своих персональных адресных книгах (Personal
Перекрестная сертификация может встречаться в организации на различных уровнях. Существует три возможных типа перекрестной сертификации, как это представлено далее:
Перед тем как мы опишем эти типы в деталях, определим несколько концепций, которые вам необходимо понимать.
Давайте допустим, что произошел типичный для наших дней случай из жизни организаций, при котором две отдельные организации, Widget и Acme, решили объединиться.
В этом случае организациям требуется простейшая форма перекрестной сертификации, при которой все пользователи и серверы обоих организаций способны проводить аутентификацию друг друга.
Для достижения этой цели будут выполнены следующие шаги:
/Acme ) получает перекрестный сертификат для источника сертификации организации Widget ( /Widget ) и сохраняет его в каталоге Domino организации Acme./Widget ) получает перекрестный сертификат для источника сертификации организации Acme ( /Acme ) и сохраняет его в каталоге Domino организации Widget.Как результат этой процедуры устанавливаются специальные отношения (говорят: "Acme и Widget доверяют друг другу" ). Это явление проиллюстрировано на рис. 6.10. В данной модели перекрестной сертификации все пользователи и серверы обоих организаций способны теперь проводить аутентификацию друг друга.
(рис 6.10) Перекрестная сертификация между двумя организациями
В этом случае перекрестная сертификация может осуществляться для двух пользователей, двух серверов или для пользователя и сервера.
Давайте предположим сценарий, при котором организации Acme и Widget желают проводить репликацию базы данных, которая содержит представляющую взаимный интерес информацию, но по своим политикам безопасности не желают иметь ничего общего, кроме взаимодействия друг с другом этих двух серверов.
Здесь организации хотят иметь наиболее ограниченную форму перекрестной сертификации, при которой сервер из одной организации выполняет аутентификацию и репликацию с сервером из другой организации.
Будут выполнены следующие шаги:
Server/Acme ) получает перекрестный сертификат для сервера Widget ( Server/Widget ) и сохраняет его в публичной адресной книге сервера Acme.Server/Widget ) получает перекрестный сертификат для сервера Acme ( Server/Acme ) и сохраняет его в публичной адресной книге сервера Widget.Как результат этой процедуры устанавливаются специальные отношения (говорят: "Сервер Acme и сервер Widget доверяют друг другу"). Это явление проиллюстрировано на рис. 6.11. В данной модели перекрестной сертификации только эти два сервера доверяют друг другу и могут осуществлять репликацию друг с другом.
(рис 6.11) Перекрестная сертификация между двумя пользователями (серверами)
В этом случае перекрестная сертификация может осуществляться для пользователя и всей организации или для сервера и организации.
Давайте предположим сценарий, при котором организации Acme и Widget желают проводить репликацию базы данных, которая содержит представляющую взаимный интерес информацию. Организация Widget намного меньше организации Acme и соответственно не имеет никаких проблем с предоставлением доступа ко всем своим серверам со стороны организации Acme, но так как Acme ведет дела со множеством организаций, являющихся конкурентами Widget, то согласно политике безопасности в этой организации желают предоставить доступ только к определенному серверу Domino.
Здесь одна из организаций желает провести наиболее ограниченную форму перекрестной сертификации, а другую организацию устраивает наиболее либеральная форма перекрестной сертификации, при которой один сервер организации Acme проводит аутентификацию и репликацию с любым сервером организации Widget.
Будут выполнены следующие шаги:
Server/Acme ) получает перекрестный сертификат для источника сертификации организации Widget ( /Widget ) и сохраняет его в публичной адресной книге сервера Acme./Widget ) получает перекрестный сертификат для сервера Acme ( Server/Acme ) и сохраняет его в каталоге Domino организации Widget.
(рис 6.12) Перекрестная сертификация между пользователем и организациейКак результат этой процедуры устанавливаются специальные отношения (говорят: "Сервер Acme и организация Widget доверяют друг другу"). Это явление проиллюстрировано на рис. 6.12. В данной модели перекрестной сертификации серверу Acme доверяет вся организация Widget, и соответственно этот сервер Acme может выполнять репликацию с любым сервером организации Widget.
За дополнительной информацией по перекрестной сертификации и реальных стадиях ее выполнения обратитесь к документации на программный продукт Domino 6, либо к файлу помощи администратора Lotus Domino 6.
Аутентификация является наиболее важным аспектом обеспечения безопасности. Она более важна, чем шифрование. Мы затрагивали эту тему в лекции 1, а теперь наступил момент повторно обратиться к этому понятию.
Давайте возьмем Алису и Боба, которые были представлены нами в лекции 1. Предположим также существование Кэрол, которая не обменивается информацией ни с Алисой, ни с Бобом, но вместо этого имеет желание подслушивать и незаконно читать информацию, которой обмениваются первые двое.
Как мы узнали, Алиса и Боб хотят обмениваться данными друг с другом, но при этом желают удостовериться в том, что этот обмен выполняется настолько безопасно, насколько это возможно. В приведенном примере Алиса и Боб обмениваются финансовой информацией. Как люди, добросовестные в плане обеспечения безопасности, они используют безопасный канал связи, в котором применяется шифрование, чтобы таким подслушивающим, как Кэрол, было чрезвычайно трудно расшифровать и понять информацию.
Шифрование является важным элементом по причине существования потенциального ущерба, который мог бы быть нанесен, если бы Кэрол была способна получить понятную копию проходящей между Алисой и Бобом информации.
Тем не менее важно рассмотреть, что могло бы случиться, если бы Кэрол смогла выдать себя за Алису или Боба. В этом случае Кэрол смогла бы получить больше информации, а также смогла бы модифицировать информацию для обмена. Нанесенный в результате ущерб мог бы быть гораздо сильнее, чем ущерб, который мог бы быть нанесен в результате простого прослушивания.
Таким образом, аутентификация является краеугольным камнем эффективной безопасности. Так как она дает системе возможность отличать одного пользователя от другого, аутентификация является также краеугольным камнем безопасности Notes и Domino.
Без проведения аутентификации могли бы появиться следующие проблемы:
Аутентификация является тем элементом, который позволяет администраторам разрешать или запрещать доступ к ресурсам системы. Если лицо получило разрешение на доступ к системе, то этому лицу могут быть предоставлены различные привилегии (обычно называемые уровнями доступа).
Таким образом, аутентификация является ключом к обеспечению ограниченного доступа к ресурсам Notes и Domino.
Как правило, процедуру аутентификации в Notes не понимают. Люди полагают, что это простой ID пользователя/пароля, хотя в реальности эта процедура намного более сложна.
Так как в Notes процедура аутентификации зависима от инфраструктуры открытых ключей, непосредственно встроенной в клиента и сервер, мы займем некоторое время на рассмотрение того, как устроена собственная инфраструктура открытых ключей (PKI) Notes, после чего объясним, как работает аутентификация Notes.
Примечание. Термин "аутентификация Notes" используется потому, что он означает аутентификацию пользователя, применяющего клиент Notes по отношению к серверу Domino. Мы уточним этот термин немного позже, а его использование поможет нам отличать этот тип аутентификации от других ее типов, которые мы обсудим в этом курсе далее.
В этом разделе мы обсудим, как Lotus Notes и Domino проводят аутентификацию друг друга по порту 1352 протокола TCP с использованием протокола вызова удаленных процедур Notes [Notes Remote Procedure Calls (NRPC)]. Целью этого обсуждения является прояснить процесс и объяснить, что на самом деле происходит каждый раз, когда пользователь вводит пароль и получает доступ к серверу Domino с использованием клиента Notes.
При выполнении аутентификации Notes двумя отдельными этапами происходит проверка подлинности пользователя или сервера. Первый этап, называемый проверкой достоверности (validation), является процессом достоверного определения открытого ключа отправителя. Другими словами, проверка достоверности является подготовительным этапом реальной аутентификации.
При принятии решения об оказании доверия открытому ключу Notes использует следующие три правила:
Сейчас мы проведем обзор процесса проверки достоверности и рассмотрим, как эти три правила применяются во время этого процесса. Давайте в качестве примера пользователя возьмем Фреда. Файл ID пользователя для Фреда содержит все, что ему необходимо для своей идентификации, и устанавливает его полномочия. Когда он запрашивает у сервера сеанс, то первым шагом является отправка серверу всех сертификатов из файла Notes ID (как собственного сертификата пользователя, так и последовательности сертификатов источников сертификации, которые его поддерживают). Процесс проверки достоверности проиллюстрирован на рис. 6.13.
(рис 6.13) Процесс проверки достоверности в Notes и DominoПронумерованные на схеме шаги описаны далее.
Widget. Сервер заинтересован в нем, потому что "Восток" является источником сертификации для сертификата Фреда.Widget из своего собственного файла Notes ID сервера. (Согласно правилу 1, сервер будет доверять открытому ключу любого предка, который хранится в его файле Notes ID сервера.)Widget (который является доверенным, так как находится в его файле Notes ID сервера) для проверки того, является ли сертификат Восток/Widget действительным. (Согласно правилу 2, если сервер доверяет открытому ключу предка, то он будет доверять любому открытому ключу, полученному из сертификатов, которые были выпущены предком.)Восток/Widget, который теперь является доверенным, для проверки того, что сертификат Фред/Восток/Widget является действительным. (Согласно правилу 3, доверяем любому открытому ключу, который был сертифицирован любым из доверенных источников сертификации и принадлежит одному из потомков источника сертификации.)Этот же процесс выполняется в обратную сторону, и таким же образом Фред может достоверно ознакомиться с открытым ключом сервера.
Как мы упоминали в предыдущем разделе, аутентификация является доказательством подлинности. На этом этапе данное доказательство еще не осуществлено. Вот поэтому теперь, после завершения процесса проверки, нам необходимо начать процесс аутентификации.
Важно понимать, что процесс проверки, который мы только что описали, еще не полностью подтверждает, кто конкретно является вашим партнером в каждом из сеансов. То, что реально происходит на этапе проверки достоверности, является просто представлением сертификатов. Это взаимное представление сертификатов гарантирует, что как минимум один из сертификатов является общим для пользователей или серверов (или, в случае отсутствия этого, как минимум один сертификат имеет общего предка).
Установив это, сертификат ассоциирует пользователя с открытым ключом и сообщает получателю, что открытый ключ может быть доверенным, после чего в данном примере пользователь и сервер могут доказать, что они реально те, за кого себя выдают, путем демонстрации того, что они хранят секретный ключ, соответствующий открытому ключу в сертификате.
Процесс аутентификации добивается этого с помощью диалога запроса/ответа между рабочей станцией и сервером или между двумя серверами при запуске репликации баз данных либо при пересылке почты.
Процесс аутентификации, который построен на предыдущем примере, в котором Фред пытается получить доступ к серверу, проиллюстрирован на рис. 6.14. Несмотря на то что схема является сильным упрощением действительного процесса, она предназначена для иллюстрации того, что происходит, легким для понимания способом.
(рис 6.14) Процесс аутентификации в Notes и DominoПронумерованные на схеме шаги описаны
7. Сервер генерирует случайное число и
8. Сервер отправляет зашифрованное случайное число Фреду.
9. Фред получает запрос и расшифровывает его с помощью своего секретного ключа.
10. Фред отправляет расшифрованное число обратно серверу.
11. Сервер сравнивает ответ Фреда с исходным случайным числом.
12. Если результат совпадает с исходным случайным числом, то сервер может доверять тому, что Фред действительно тот, за кого себя выдает.
Как и в случае проверки достоверности, аутентификация также является двухсторонней процедурой. Далее Фред проводит аутентификацию сервера с использованием такого же процесса запроса/ответа, но на этот раз в обратном направлении.
Действительный алгоритм является сложным, но эффективным. Он избегает всяческих RSA-операций при последующих проведениях аутентификации между той же парой "клиент-сервер". Алгоритм также устанавливает
Существует возможность избежать процедуры проверки достоверности и сертификации, которые мы только что описали, путем отключения аутентификации на основе сертификатов. По существу, это указывает серверу разрешить анонимный доступ со стороны пользователей и серверов, достоверность которых сервер не проверяет и аутентификацию которых он не проводит.
Недостаток от осуществления этого должен быть очевиден. Сервер Domino, для которого разрешен анонимный доступ, не записывает активность пользователей и серверов. [Обычно это выполняется в файле журнала и в диалоговом окне активности пользователей (User Activity).] При анонимном доступе нет никакой возможности узнать, кто осуществляет доступ к базам данных на сервере. Таким образом, подлин ность пользователя невозможно применить для управления доступом к базам данных и элементам дизайна.
Позитивной стороной разрешения анонимного доступа является то, что он наиболее пригоден для предоставления общего публичного доступа к серверам для пользователей и серверов, с которыми у них не проводилась перекрестная сертификация. Как правило, это применяется для разрешения пользователям и серверам из-за пределов организации получить доступ к серверу без предварительного полученисертификата для организации.
В общем и целом, говоря о преимуществах и недостатках разрешения анонимного доступа к серверам Domino, следует отметить, что этот тип доступа должен рассматриваться только тогда, когда нет необходимости знать, кто осуществляет доступ к базе данных, или когда нет необходимости управлять доступом на основе подлинности клиента. Соответственно это предполагает, что доступная в этих базах данных и на серверах информация имеет низкую чувствительность, если не полностью находится в публичном домене.
Об анонимном доступе существует гораздо больше информации, чем мы можем привести здесь. Анонимный доступ может также быть предусмотрен для пользователей Интернета/интранета в соединении с шифрованием сеанса. Мы опишем это позднее в данной лекции в разделе об инфраструктуре открытых ключей в Интернете.
На данном этапе приведем шаги, которые необходимо выполнить для разрешения анонимного доступа к серверу Domino со стороны пользователей Notes и других серверов Domino.
Anonymous (Анонимный) в списках управления доступом (ACL) всех баз данных, для которых вы желаете разрешить анонимный доступ. Задайте соответствующий уровень доступа – обычно доступ с правами Reader (Читатель). Если вы не добавите Anonymous в качестве элемента в ACL, анонимные пользователи и серверы получат доступ Default (По умолчанию).Наконец, финальное слово об анонимном доступе. Если пользователь находится в среде иерархической сертификации и предпринимает попытки соединиться с сервером, который настроен на анонимный доступ, а сервер не может аутентифицировать пользователя, то в строке состояния этот человек увидит следующее сообщение:
Server X cannot authenticate you because: the server's
В начале курса мы обсуждали службы обеспечения безопасности, которые необходимо предусмотреть. Одной из них является целостность данных (
Когда реплицируются базы данных или по сети направляются сообщения электронной почты, существует определенный риск, что они могут быть модифицированы либо по причине аппаратного сбоя, либо по причине действий неавторизованной третьей стороны [часто упоминаемых как фальсификация (
С целью обнаружения любых подобных изменений используются цифровые подписи. Целостность данных предполагает, что текущее состояние данных идентично исходному "чистому" состоянию. Это гарантирует, что информация не изменена в процессе транзита. Цифровая подпись может подтвердить, что человек, который внес данные, является их автором и что никто не сфальсифицировал данные.
Инициаторы данных могут добавлять свою цифровую подпись к сообщениям электронной почты, а также к полям или разделам документов Notes.
Примечание. Разработчик базы данных настраивает, подписываемы или нет поля и разделы базы данных. Используя эту возможность, отдельные пользователи могут затем осуществить выбор относительно того, подписывать или нет почтовые сообщения.
Для цифровых подписей, применяемых клиентом Notes, применяется та же пара RSA-ключей, что была использована в процессе проверки достоверности и аутентификации. Способ, которым цифровые подписи применяются в Lotus Notes, проиллюстрирован на рис. 6.15.
(рис 6.15) Используемые в Lotus Notes цифровые подписиПронумерованные на схеме шаги описаны далее.
Таким образом, результатом для пользователя является то, что Notes отобразит, кто подписал сообщение, если проверка достоверности подписи прошла успешно. В противном случае Notes отобразит, что не может проверить достоверность подписи.
Процесс цифровой подписи гарантирует две вещи:
В противном случае получатель знает, что данные были сфальсифицированы либо что отправитель не имеет сертификата, которому доверяет читатель.
Другой рассмотренной нами службой обеспечения безопасности, которую необходимо предусмотреть, является конфиденциальность (
При отправке данных по сети, включая почтовые сообщения, любой, кто может перехватить сетевые пакеты [как правило, посредством способов отслеживания (трассировки) или электронного сниффинга] может читать данные без прохождения аутентификации.
Возможно, это не является проблемой для организации, поскольку информация, вероятно, несекретна. Однако данное явление может восприниматься организацией и как проблема, так как это означает, что вся почта, которая отправляется и получается, может быть прочтена другими людьми, которые обычно не имеют на это разрешения.
Недостаток секретности является серьезной проблемой. Несмотря на то что основной объем трафика электронной почты не содержит чувствительных данных, он содержит небольшое, но важное подмножество сообщений. Для этой проблемы существует только два решения: либо убедить пользователей серьезно относиться к безопасности, либо трактовать всю электронную почту как содержащую чувствительную информацию и шифровать все. Опыт показывает, что внесение эффективных изменений в ИT-архитектуру обычно проще, чем изменение сознания людей, поэтому зачастую применяется последний подход. (Однако пользователи должны продолжать серьезно относиться к безопасности, а также должны применяться политики безопасности, чтобы гарантировать, что минимум в обеспечении безопасности соблюдается в организации всеми.)
Выполнение шифрования во всей ИT-инфраструктуре не является тривиальной и простой задачей, за исключением, конечно, случаев использования Notes.
Электронная почта зашифровывается автоматически клиентом Notes и отправляется далее. После того как зашифрованная электронная почта достигнет места назначения, клиент Notes расшифровывает ее, чтобы дать получателю возможность ее прочитать. Этот метод защищает данные от неавторизованного доступа. Для шифрования и расшифровки данных Notes использует механизм группового шифрования, в основе которого лежит секретный ключ. Это также подтверждает, что полученные данные не были прочитаны другими. Принимая во внимание тот факт, что клиенты Notes и серверы Domino обрабатывают огромное множество электронной почты, важно, чтобы используемый алгоритм был эффективным. Для группового шифрования данных Notes использует алгоритмы
Единственный вариант относительно изменения криптостойкости представлен типом имеющейся у пользователя лицензии Notes.
Все Notes ID содержат две пары открытого/секретного ключей. До версии 5.0.4 длины ключей были ограничены в целях шифрования данных, но не в интересах аутентификации и осуществления электронной подписи. Все, что было свыше 512-битового RSA-ключа и 56-битового симметричного ключа, рассматривалось как сильное шифрование, и правительство США запретило это экспортировать. Заказчики были вынуждены соблюдать эти правила и осуществлять выбор среди комплектов программного обеспечения с различными силами криптографии.
По мере смягчения постановлений правительства США относительно экспорта криптографии, программные продукты сервера Domino, Domino Administrator, Domino Designer®, клиента Lotus Notes объединили все предыдущие разновидности криптостойкости – североамериканскую (North American), интернациональную (International) и французскую (France) – в один уровень криптостойкого шифрования в отдельном выпуске "Global (Глобальный)" этих продуктов. Глобальный выпуск принял характеристики шифрования, ранее известные как североамериканские. Криптостойкое шифрование программных продуктов глобальной версии может использоваться по всему миру, за исключением тех стран, в которых это запрещают законы об импорте либо в которые экспорт товаров и услуг запрещен правительством США. Покупателям больше не требуется заказывать программное обеспечение Notes в соответствии с силой криптографии.
Когда организация обновляет программное обеспечение до глобальной версии Domino и Notes, более сильная криптография будет использоваться без требования повторного выпуска существующих ID. Эти изменения безболезненны как для пользователей, так и для администраторов. При взаимодействии двух различных версий программного обеспечения переговоры по шифрованию закончатся переходом к более слабому его уровню. Поэтому все преимущества криптостойкого шифрования будут реализованы только в том случае, когда все программное обеспечение обновлено до глобального уровня (dерсия 5.0.4 и выше). Однако любые смешанные версии программного обеспечения все же будут взаимодействовать друг с другом.
Диалоговое окно Register New User (Регистрация нового пользователя) все еще будет предлагать осуществить выбор между североамериканскими и интернациональными ID. Это было оставлено, потому что администраторы часто используют их различие в административных целях и потому что в некоторых компаниях все еще используются более старые версии программного обеспечения. В дополнение к этому различные страны имеют свои собственные правила импорта. Сохранение этого различия позволит Lotus реагировать на изменения для определенных стран, если это потребуется.
Примечание. Эти предписания касаются только экспорта из США. Для других стран с собственными предписаниями относительно импорта заказчикам необходимо осуществить проверку на предмет соответствия требованиям для определенной страны. Несмотря на то что Lotus предпринимает все шаги для обеспечения согласования правительственных предписаний относительно шифрования по всему миру, компания все же рекомендует, чтобы заказчики ознакомились с местными предписаниями относительно шифрования, чтобы обеспечить соответствие им.
Тот факт, что североамериканский и интернациональный типы ID продолжают существовать и поддерживаются в Notes и Domino, порождает множество вопросов и забот. Последующий разговор коснется некоторых из них.
Наилучшей стратегией при выборе между североамериканскими и интернациональными ID является продолжение использования того способа решения, который применялся для более ранних версий Notes и Domino. В конечном счете по мере обновления клиентов Notes и серверов Domino ваше решение перестанет иметь значение.
Очень важно беречь Notes ID. Соответственно приведем два особых момента, которые достойны запоминания.
ID, как это обсуждалось ранее).Одним из способов, который Lotus Notes предлагает для обеспечения конфиденциальности, является предоставление служб, с помощью которых электронная почта может быть легко и эффективно зашифрована. Метод, с использованием которого это выполняет клиент Lotus Notes, проиллюстрирован на рис. 6.16.
(рис 6.16) Шифрование сообщений электронной почты в Lotus NotesЭто практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на схеме шаги описаны далее.
Важно указать на пару следующих моментов:
Предыдущие примеры применимы к почте Notes, но Lotus Notes предусматривает также другие методы шифрования информации. С использованием различных методов шифрования могут быть защищены базы данных, документы, поля и передача данных по сети.
ID сервера или пользователя путем применения опции безопасности, касающейся шифрования локальной базы данных. Это защитит базы данных, которые используют это свойство безопасности, от доступа со стороны неавторизованного пользователя, получившего доступ к файловой системе рабочей станции, на которой хранится база данных, и сделавшего копию базы данных в файловой системе посредством операционной системы.Мы рассмотрели все важнейшие аспекты инфраструктуры открытых ключей Notes (Notes PKI) и показали, каким образом безопасность Notes и Domino строится на надежной инфраструктуре открытых ключей, которая делает возможным обеспечение аутентификации, целостности данных и конфиденциальности для всех пользователей Notes, воспользовавшихся этими встроенными функциями. Принимая во внимание прозрачность PKI в Lotus Notes, инфраструктуру открытых ключей Notes удобно применять, обеспечивая безопасность без наличия всяких трудностей, свойственны стандартным реализациям инфраструктур открытых ключей, что сделало ее наиболее распространенной PKI в корпоративном мире.
Так как Notes и Domino взаимодействуют также и с людьми, их не использующими, то в оставшихся разделах этой лекции мы обсудим, как Notes и Domino расширили свои возможности в целях представления поддержки интернет-стандартов в вопросах инфраструктуры открытых ключей и служб, которые становятся доступными при ее употреблении.
Исходя из открытости Интернета и того факта, что любой желающий может делать в нем почти все, что угодно, и когда угодно, компаниям необходимо защищать себя в Интернете. В этих целях существует определенное количество стандартов, технологий и инструментов обеспечения безопасности, которые мы рассмотрим в данном разделе.
Как и в случае с безопасностью в Notes, эти стандарты, технологии и инструменты по большей части основаны на технологии сертификатов открытых ключей. Двумя наиболее распространенными форматами сертификатов являются PGP и X.509. Принимая во внимание широкую поддержку со стороны Domino сертификатов X.509, мы сфокусируем ваше внимание на этом формате.
Поддержка подобных встроенных в сервер интернет-стандартов осуществлялась с момента представления в 1996 г. сервера Domino 4.5. Целью этого являлась все большая интеграция данных стандартов в ядро сервера Domino, и результат таких усилий хорошо виден в Domino 6. На протяжении оставшейся части этой лекции мы обсудим необходимые вам основы технологий обеспечения безопасности в Интернете, а более подробное разъяснение новых сервисов и услуг представлено в лекции 11, "Свойства безопасности Domino/Notes 6".
Одно дело использовать Интернет, и совершенно другое выполнять технические работы, основанные на интернет-стандартах. Если построение шаблона достаточно просто, то дальнейшая работа способна обескуражить в плане временных затрат.
При выполнении подобной технической работы упоминаются такие акронимы, как STD и RFC, причем каждый из них идет с определенным номером. Важно знать, откуда происходят эти акронимы, что они означают и каковы различия межу ними.
Интернет-стандарты определяются целевой группой инженерной поддержки Интернета IETF (
Спецификации, которые планируется сделать интернет-стандартами, проходят в своем развитии последовательность уровней зрелости, известных как путь стандартов (standards track). Эти уровни зрелости включают предложенный стандарт (
Спецификация предложенного стандарта (
Спецификация, на основе которой были разработаны как минимум две независимые и взаимодействующие реализации на базе различного кода и для которой был получен достаточно удачный опыт использования, может подняться до уровня чернового стандарта (Draft Standard).
Черновой стандарт обычно рассматривается как финальная спецификация, а изменения в нем можно делать только для решения неожиданно возникших специфических проблем. В большинстве случаев разумным для производителей решением будет помещать реализации черновых стандартов в среды, чувствительные к поломкам.
Спецификация, для которой получены достоверная реализация и успешный опыт работы с ней, может подняться до уровня интернет-стандарта (Internet Standard). Интернет-стандарт [который может упоминаться просто как стандарт (Standard)] характеризуется высокой степенью технической зрелости и в целом предполагает, что указанный протокол или служба предоставляют значительную пользу интернет-сообществу.
Как правило, интернет-стандарты определяют способность к взаимодействию систем путем задания протоколов, форматов сообщений, схем и языков. Наиболее фундаментальные стандарты определяют интернет-протокол IP (Internet Protocol).
Все интернет-стандарты задаются в последовательности STD числом. Первый документ в этой последовательности, STD1, описывает оставшиеся в последовательности документы и содержит список предложенных стандартов. Зачастую документы в последовательности STD являются копиями RFC либо несколькими собранными вместе RFC. Номера STD не имеют номеров версий, так как все обновления выполняются через RFC, а номера RFC являются уникальными. Для четкого указания того, какая версия стандарта упоминается, должны быть точно определены номер стандарта и все RFC, которые он включает.
Запросы на комментарии [requests for comments (RFC)] являются начатой в 1969 г. последовательностью пронумерованных информационных документов и стандартов Интернета, которым в значительной степени следуют разработчики коммерческого и
RFC, выпущенные организацией IFTF и ее предшественниками, являются наиболее известной последовательностью с названием RFC; эта последовательность почти всегда является тем, что означает RFC без последующего уточнения. Однако в прошлом последовательности с названием RFC выпускались также и другими организациями.
RFC необычны тем, что они запускаются в ход техническими экспертами, действующими по своей собственной инициативе, и детально оцениваются в Интернете, причем даже лучше, чем если бы они были официально опубликованы таким институтом, как Национальный институт стандартизации США (ANSI). По этой причине они остаются известными как RFC даже после принятия в качестве стандартов. Эта традиция получения не допускающего возражений, подтвержденного опытом, становящегося таковым после завершения процесса стандарта, написанного отдельными людьми или небольшими рабочими группами, имеет важные преимущества по сравнению с более официальным, проводимым комиссиями процессом. Символичным для этих преимуществ является наличие процветающей традиции выпуска "шуточных" RFC. Обычно такой RFC выпускается как минимум один раз в году, как правило 1 апреля.
Наиболее поразительным является то, насколько хорошо работают RFC; они ухитряются не иметь ни неопределенностей, которыми обычно изобилуют спецификации, ни совершенных комиссиями ошибок, которые часто неотступно преследуют официальные стандарты, и они описывают сеть, которая выросла действительно до общемировых масштабов.
STD и RFC являются свободно доступными, в том числе и в режиме онлайн. Наиболее легким способом получить их является посещение Web-сайта организации IETF, находящегося по следующему URL-адресу:
Полный каталог RFC в текстовом формате доступен на сайте организации по адресу:
http://www.ietf.org/iesg/1rfc_index.txt
Однако по этому каталогу вследствие его длины непрактично осуществлять навигацию. Вместо этого лучшим способом найти и извлечь текст отдельного RFC является ввести его номер, зайдя по следующему адресу:
За более подробным описанием RFC и процесса создания RFC обратитесь к RFC 2026 The Internet Standards Process,
Не все RFC являются документами интернет-стандартов. Многие RFC имеют статус информационных или экспериментальных и не представляют собой никакого стандарта. Вместо этого они содержат информацию, которая может быть полезной или важной для сохранения в качестве части последовательности документов RFC.
Это важно понимать, поскольку недобросовестные специалисты по маркетингу и невнимательная профессиональная пресса иногда ошибочно внушают нам, что каждый RFC представляет собой стандарт или что все стандарты имеют одинаковый вес. Взаимоотношения между техническими спецификациями Интернета зачастую очень сложны. На самом деле существует даже RFC, который разъясняет это, – RFC 1796, называемый Not All RFCs are Standards (Не все RFC являются стандартами), доступ к которому можно получить по адресу:
http://www.faqs.org/rfcs/rfc1796.html
Когда вы будете читать о технологиях, инструментах и службах Интернета, которые поддерживаются и предлагаются сервером Domino для интернет-клиентов, помните об этих отличиях между STD и RFC.
Перед тем как мы подробно коснемся отдельных, предлагаемых PKI служб, в этом разделе мы дадим описание компонентов PKI.
Первоначально "PKI" было общим термином, который просто обозначал набор служб, использующих криптографию на основе открытых ключей. В наши дни "PKI" больше ассоциируется с предоставляемыми инфраструктурой открытых ключей службами либо в виде приложений, либо в виде протоколов. Некоторыми примерами таких служб являются:
Давайте рассмотрим, что необходимо для обеспечения этих служб, а также те компоненты, которые требуются современной инфраструктуре открытых ключей.
Основные компоненты инфраструктуры открытых ключей (PKI), как показано на рис. 6.17, включают:
End Entity (EE) ];Certificate Authority (CA) ];Certificate Repository (CR) ];Registration Authority (RA) ];Digital Certificates (X.509 V3)Далее следуют подробные определения этих компонентов.
(рис 6.17) Компоненты PKIКонечный объект лучше всего определить как
Центр сертификации [ Certificate Authority (CA) ] по существу, является подписчиком сертификатов. Центр сертификации, зачастую совместно с центром регистрации (описанным далее), имеет своей обязанностью обеспечивать надлежащую идентификацию сертификата конечного объекта ( ЕЕ ). Логический домен, в котором СА выпускает сертификаты и управляет ими, называется доменом безопасности (security domain), который может быть реализован для защиты множества различных групп разных размеров, начиная от одного контрольного пользователя вплоть до департамента и далее до уровня всей организации. Основные проводимые СА операции включают: выпуск сертификатов, обновление сертификатов и аннулирование сертификатов.
СА создает цифровой сертификат путем подписывания его цифровой подписью. По существу пара открытого и секретного ключей генерируется запрашивающим клиентом ( ЕЕ ). После этого клиент передает СА на рассмотрение запрос на выпуск сертификата.
Запрос на выпуск сертификата содержит по меньшей мере открытый ключ клиента и некоторую другую информацию, такую, как имя клиента, адрес электронной почты, почтовый адрес или другую относящуюся к делу информацию. Когда установлен центр регистрации ( RA ), СА делегирует ему процесс верификации клиента и другие функции управления. После подтверждения запроса клиента СА создает цифровой сертификат и подписывает его.
В качестве альтернативы СА может генерировать пару ключей клиента, а впоследствии и подписанный сертификат для этого клиента. Однако этот процесс выполняется достаточно редко, так как секретный ключ необходимо пересылать от СА к клиенту, что может стать слабым местом. Как правило, более безопасным представляется случай, когда клиенты генерируют свои собственные пары ключей, при этом секретные ключи никогда не покидают своей зоны полномочий.
В целях обеспечения правильной работы инфраструктуры открытых ключей основным предположением является то, что любая сторона, которая желает проверить сертификат, должна доверять СА, который произвел его цифровую подпись. В инфраструктуре открытых ключей "А доверяет Б" означает, что "А доверяет центру сертификации, который подписал сертификат Б". Соответственно, в общих чертах, "А доверяет центру сертификации" означает, что "А" имеет локальную копию сертификата этого центра сертификации.
К примеру, при установке безопасного HTTP-соединения посредством SSL основные Web-браузеры имеют список сертификатов нескольких, заслуживающих доверия СА (обычно упоминаемых как Trusted Roots или Trusted CA, браузеры будут полностью доверять серверу, за исключением тех случаев, когда пользователь умышленно удаляет сертификат CA-подписчика из списка доверенных СА.
СА способен выпускать определенное количество различных типов сертификатов, таких, как:
СА. Если частью инфраструктуры является центр регистрации RA, то он также должен иметь этот сертификат. Сертификат пользователя может быть ограничен до специфических случаев применения и целей (таких, как безопасная электронная почта, безопасный доступ к серверам и т. д.).СА ). Когда СА выпускает сертификат для самого себя, такой сертификат называется СА. Если СА выпускает сертификат для подчиненного СА, то этот сертификат также называется сертификатом СА.Каждый сертификат имеет период достоверности и связанной с ним датой истечения срока действия. Когда срок действия сертификата истекает, то может быть инициирован процесс его обновления, после одобрения которого для конечного объекта будет выпущен новый сертификат.
Максимальный срок службы сертификата ограничен датой истечения его срока действия. Однако в некоторых случаях возникает необходимость аннулировать сертификаты до наступления этой даты. Когда это случается, CA включает сертификат в CA включает в этот список серийный номер сертификата вместе с некоторой другой информацией. Клиенты, которым необходимо знать о достоверности сертификата, могут осуществлять в
Репозиторий сертификатов [Certificate CR )] является хранилищем выпущенных сертификатов и CR необязательный компонент инфраструктуры открытых ключей, он значительно способствует доступности и управляемости PKI.
Так как формат сертификатов X.509 нормально приспособлен к каталогу X.500, то соответственно наилучшим образом будет реализовать CR как каталог (Directory), который затем может быть доступен посредством наиболее общего протокола доступа – облегченного протокола доступа к каталогам LDAP (
LDAP является наиболее эффективным и наиболее распространенным методом, с помощью которого конечные объекты или СА извлекают или модифицируют хранящиеся в CR сертификаты и информацию bind, search или modify и CR, определены классы объектов и атрибутов [называемые схемами (Schemas)].
Для получения сертификатов или информации CR, существуют альтернативные методы. Однако их применять не рекомендуется, и после рассмотрения требований, которым должен соответствовать CR, все сводится к тому, что каталог на самом деле является лучшим местом для хранения информации CR. Эти требования включают: простую доступность, доступ на основе стандартов, сохранение новейшей информации, встроенную безопасность (если требуется), вопросы управления данными и возможность объединения подобных данных. В случае инфраструктуры открытых ключей в Интернете на основе Domino репозиторием сертификатов является каталог Domino (Domino Directory).
Центр регистрации [Registration Authority ( RA )] является необязательным компонентом инфраструктуры открытых ключей. В некоторых случаях роль RA выполняет CA. Там, где используется отдельный RA, он является доверенным конечным объектом, который сертифицирован CA и действует как CA. CA может делегировать некоторые из своих функций управления RA. К примеру, RA может выполнять персональные задачи аутентификации, сообщать об RA не производит выпуск сертификатов или
Ключевой частью инфраструктуры открытых ключей (и достойной собственного раздела для описания) является сертификат X.509.
Несмотря на то что для сертификатов открытых ключей было предложено несколько форматов, большинство доступных сегодня коммерческих сертификатов основаны на интернациональном стандарте, рекомендации ITU-T X.509 (ранее X.509 организации
Сертификаты X.509 обычно используются в защищенных интернет-протоколах, таких, как те, которые мы рассматриваем в настоящей лекции, а именно:
Первоначально основной целью стандарта X.509 было определить средства для проведения аутентификации на основе сертификатов по отношению к каталогу X.500. Аутентификация каталогов в X.509 может проводиться с использованием либо техники секретных ключей, либо техники открытых ключей. Последняя основана на сертификатах открытых ключей.
В настоящее время определенный в стандарте X.509 формат сертификата открытого ключа широко используется и поддерживается в мире Интернета определенным количеством протоколов. Стандарт X.509 не устанавливает особого криптографического алгоритма, хотя и производит впечатление, что RSA является единственным наиболее широко используемым алгоритмом.
RFC, касающиеся электронной почты повышенной защиты [Privacy Enhanced Mail (
Эти поля предоставляют большую гибкость по причине того, что они могут сообщать дополнительную информацию вдобавок к наличию только ключа и связанного с ним имени. Стандартизация основного формата v3 была завершена в июне 1996 г.
Сертификат X.509 состоит из следующих полей:
Стандартные расширения включают среди прочих атрибуты субъекта и выпускающего сертификат, информацию о политике сертификации, ограничения в использовании ключей. Структура
(рис 6.18) Структура сертификата X.509Данные сертификата записываются согласно правилу синтаксиса системы обозначений для описания
(рис 6.19) Представление сертификата X.509 согласно системе обозначений для описания абстрактного синтаксиса 1 (ASN. 1)После этого они конвертируются в двоичные данные в соответствии с характерными правилами кодирования ASN.1, который является языком описания данных и определен организацией ITU-T как стандарты X.208 и X.209. Эта операция позволяет сделать данные сертификата независимыми от правил кодирования каждой конкретной платформы.
В некоторых полях сертификата для представления специальной последовательности значений параметров используется идентификатор объекта [AlgorithmIdentifier для signatureAlgorithm, который фактически состоит из идентификатора объекта ( СА ). Приложение, которое проверяет подпись сертификата, должно понимать
Несмотря на тему о сертификатах, давайте потратим немного времени для рассмотрения перекрестных сертификатов в Интернете, так как мы уже рассмотрели тему об перекрестных сертификатах в инфраструктуре открытых ключей Notes.
Перекрестный сертификат Интернета, как и обычный интернет-сертификат, является сертификатом, который подтверждает идентичность пользователя или сервера. Этот тип сертификата гарантирует получателю зашифрованного S/MIME-сообщения, что сертификат отправителя может быть доверенным, и то, что используемый для подписи S/MIME-сообщения сертификат является действительным. Также он подтверждает идентичность сервера в том случае, когда клиент Notes использует для доступа к интернет-серверу протокол SSL.
Перекрестный сертификат Интернета сохраняется в документе Certificate персональной адресной книги пользователя и может быть применен только тем пользователем, для которого он был выпущен. Перекрестный сертификат Интернета может быть выпущен для "листового" сертификата (СА.
Создание перекрестного сертификата для листового сертификата отображает доверие только к СА отображает доверие для всех владельцев, которые имеют выпущенный этим СА сертификат.
Если СА перекрестно сертифицировал СА, то этим оказывается доверие СА на выпуск сертификатов для пользователей и серверов, находящихся ниже в иерархическом дереве имен. К примеру, после перекрестной сертификации Sales/Acme доверие оказывается Sales/ABC на выпуск сертификата для Fred/Sales/Acme. В качестве альтернативы после создания перекрестного сертификата для Fred/Sales/Acme доверие оказывается только Fred/Sales/Acme.
За подробной информацией о том, как создать перекрестный сертификат Интернета для СА, обратитесь к разделу "Создание перекрестного сертификата Интернета для СА " базы данных помощи Lotus Domino Administrator 6.
Мы покажем сертификаты X.509 в действии достаточно кратко. Перед тем как мы сможем сделать это, необходимо повторно просмотреть материал об аутентификации, так как она важна в Интернете настолько же, насколько она важна в среде Notes. Для напоминания о том, почему так важна аутентификация, обратитесь к разделу "Аутентификация".
В этом разделе мы опишем различные методы, которые доступны для проведения аутентификации пользователей Интернета и интранета.
Протоколом связи прикладного уровня, используемым в WWW, является протокол HTTP (Hypertext Transfer Protocol). В HTTP включена схема с использованием простого имени пользователя и аутентификации на основе пароля, известная как основная (или базовая) аутентификация. Реализация основной аутентификации является специфической для каждого сервера, но обычно все они используют ее в двух целях:
После того как установлен доступ на основе имени и пароля и для интернет- или интранет-пользователей созданы документы Person, Domino будет осуществлять аутентификацию пользователей в тех случаях, когда:
К примеру, когда пользователь пытается открыть базу данных, которая имеет список управления доступом (ACL) с параметром No Access (Нет доступа) по умолчанию, Domino запрашивает пользователя о действительном имени пользователя и пароле. Аутентификация пройдет удачно только в том случае, если пользователь предоставит имя и пароль, которые соответствуют имени и паролю, хранящимся в документе Person пользователя, и если ACL базы данных предоставит этому пользователю доступ. Аутентификация анонимных пользователей не производится.
Существует возможность использовать доступ по имени и паролю и анонимный доступ вместе с протоколом TCP/IP и протоколом SSL (который мы подробно рассмотрим в следующем разделе). Анонимный доступ и доступ на основе имени и пароля вместе с протоколом TCP/IP описаны здесь.
Этот раздел применим также к Web-клиентам, осуществляющим доступ к Web-серверу Domino, для которого была разрешена аутентификация сеанса.
Аутентификация по имени и паролю, известная также как основная
Когда это настроено, Domino запрашивает имя и пароль только в тех случаях, когда интернет- или интранет-пользователь пытается получить доступ к защищенному ресурсу сервера. Интернет- или интранет-доступ отличается от доступа клиента Notes и сервера Domino тем, что сервер Domino запрашивает клиента Notes или сервер Domino на предмет имени и пароля, когда клиент или сервер осуществляют первоначальные попытки получить доступ к серверу.
Если администратор желает назначить доступ к базе данных со стороны интернет- или интранет-клиента, основываясь на обеспечиваемой ACL безопасности Domino, то данный человек должен создать для этого клиента документ Person в каталоге Domino либо, на свой выбор, во вторичном каталоге Domino или внешнем каталоге LDAP. Клиенты, которые не имеют документов Person, рассматриваются как анонимные и могут получить доступ только к тем серверам и базам данных, к которым разрешен анонимный доступ.
Аутентификация по имени и паролю позволяет Domino определить местоположение документа Person (если он существует) для обеспечения доступа клиента к серверу. Доступ к ресурсам сервера может быть разрешен только после идентификации клиента. К примеру, если мы хотим задать Алисе доступ к базе данных с правами Editor (Редактор), а все остальные осуществляют доступ к базе данных с правами Author (Автор), для Алисы необходимо создать документ Person. Существует возможность настроить список управления доступом (ACL) к базе данных для включения туда Алисы с правами Editor, а анонимных пользователей (Anonymous) с правами Author.
Аутентификацию по имени и паролю можно использовать либо с TCP/IP, либо с SSL на любых серверах, на которых используется интернет-протокол (LDAP, POP3, HTTP, SMTP,
Пример аутентификации по имени и паролю с использованием протокола HTTP показан на рис. 6.20. Сам процесс описан ниже.
(рис 6.20) Аутентификация по имени и паролю с использованием протокола HTTPPrivate (Конфиденциально) из области состояния 401 HTTP). После получения от сервера этого ответа Web-браузер выводит диалоговое окно простой аутентификации и предлагает пользователю ввести его имя и пароль.ID пользователя и пароль (зашифрованные в формате Base64).В общем, на рисунке показано, что, когда клиент запрашивает определенный URL-адрес, сервер проверяет, требуется ли для данного URL-адреса применять аутентификацию. Если да, то сервер отклоняет запрос с кодом состояния 401. На экране пользователя появляется диалоговое окно, запрашивающее ID пользователя и пароль. Когда пользователь представляет их, браузер повторно отправляет первоначальный запрос, но с добавлением в него следующего MIME-элемента с HTTP-заголовком:
Authorization : Basic <user ID and password block>
ID пользователя ( user ID ) и блок пароля ( password block ) сконструированы путем создания строки формы UserID:Password с последующим кодированием ее с помощью алгоритма Base64.
Запрос пароля у пользователей не производится каждый раз повторно при доступе к странице с ограниченным доступом, потому что браузер кеширует в памяти ID пользователя, пароль, имя сервера и название области. Таким образом, если он получает другой код состояния 401 для той же комбинации "сервер/область", браузер может повторно выдать запрос с применением соответствующих ID пользователя и пароля.
Некоторые браузеры идут дальше и просто отправляют ID пользователя и пароль любому URL-адресу, которому это, вероятно, необходимо. Как Opera и Mozilla, Netscape Navigator и Internet Explorer отправляют информацию с любым URL, который находится в том же логическом каталоге.
Целью этих технических приемов является уменьшение сетевого трафика и увеличение быстроты реакции путем исключения определенного количества неверных запросов и ответов с кодом состояния 401. К сожалению, они имеют и нежелательный побочный эффект, заключающийся в повторной передаче ID пользователя и пароля в тех случаях, когда, возможно, в этом нет необходимости.
Однако существуют способы для ослабления этого явления. Для каждого разрешенного на сервере интернет-протокола существует возможность указать метод обеспечения безопасности. К примеру, администратор может разрешить для соединений HTTP аутентификацию клиента с применением сертификата, но для соединений LDAP, которые используют протокол TCP/IP, потребовать обеспечения безопасности с применением имени и пароля. Либо администратор может использовать обеспечение безопасности с применением имени и пароля при анонимном доступе и при аутентификации клиента SSL, например для разрешения пользователям с сертификатами клиентов SSL проводить аутентификацию с использованием аутентификации клиента SSL и для разрешения прочим пользователям вводить имя и пароль, если они не имеют сертификата клиента SSL.
Примечание. Аутентификация с использованием имени и пароля не поддерживается, когда сервер Domino работает как SMTP-клиент, например когда сервер Domino соединяется с SMTP-сервером для передачи почты. Аутентификация с использованием имени и пароля поддерживается только в тех случаях, когда сервер Domino работает как SMTP-сервер, а именно когда SMTP-клиенты получают доступ к серверу Domino.
Существует возможность выбрать уровень ограничения, который Domino применяет при аутентификации пользователей в каталогах Domino и каталогах LDAP. Это применимо ко всем интернет-протоколам (HTTP, LDAP, IMAP, POP3). Использование этой установки делает серверы менее уязвимыми для атак по безопасности путем уточнения того, как Domino осуществляет поиск имен и проводит аутентификацию интернет-клиентов. Domino также применяет эту установку, когда расположенный на сервере Domino Java-апплет производит аутентификацию пользователей по протоколу
Опция Fewer name variations with higher security является установкой по умолчанию и рекомендуется для обеспечения наилучшей безопасности. Этот метод аутентификации менее уязвим для атак, потому что попытка простой аутентификации не порождает так много совпадений, уменьшая вероятность соответствия предполагаемого пароля. Пользователям требуется ввести только те элементы, которые перечислены в табл. 6.2 в диалоговом окне введения имени и пароля Web-браузера или другого интернет-клиента.
| Аутентификация каталога Domino | Аутентификация каталога LDAP |
|---|---|
| Полное иерархическое имя | DN |
Общее имя или общее имя с CN=prefix |
CN или CN с CN=prefix |
| Не применяется | UID или UID с UID=prefix |
Имя псевдонима (имя, приведенное в поле имени пользователя документа Person, за исключением приведенного в поле имени alice .first name ) |
Не применяется |
| Интернет-адрес (адрес электронной почты пользователя, указанный в поле интернет-адреса документа Person пользователя) | Почта |
Domino пытается производить аутентификацию пользователей на основе введенных имен и паролей. Этот метод аутентификации может быть уязвим для хакеров, которые подбирают имена и пароли в попытке применить для доступа к серверу легальную учетную запись пользователя. Эта опция дает возможность пользователям вводить любые из перечисленных в табл. 6.3 элементов в диалоговом окне введения имени и пароля Web-браузера.
| Аутентификация каталога Domino | Аутентификация каталога LDAP |
|---|---|
| Фамилия (Last name) | Фамилия (Surname) |
| Имя человека (First name) | Имя человека (Given name) |
Общее имя или общее имя с cn=prefix |
Общее имя ( CN ) или CN с CN=prefix |
| Полное иерархическое имя (каноническое) | DN |
| Полное иерархическое имя (сокращенное) | DN |
| Короткое имя | UID или UID с UID=prefix |
| Имя псевдонима (имя, приведенное в поле имени пользователя документа Person, за исключением приведенного в поле имени человека – first name) | Не применяется |
| Не применяется | |
| Интернет-адрес (адрес электронной почты пользователя, указанный в поле интернет-адреса документа Person пользователя) | Почта |
Если аутентификация по имени и паролю рассматривается для сервера HTTP, то существует дополнительный метод, который может использоваться совместно с ней: аутентификация на основе сеанса.
Аутентификация по имени и паролю отправляет имя и пароль в незашифрованном формате, причем отправка происходит при каждом запросе. Аутентификация на основе сеанса отличается тем, что имя пользователя и пароль заменяются на cookie.
Имя пользователя и пароль отправляются по сети только один раз, когда пользователь подключается к серверу. Впоследствии для аутентификации применяется cookie.
Аутентификация по имени и паролю на основе сеанса предлагает более лучшее управление взаимодействием с пользователем, чем простая аутентификация по имени и паролю, и позволяет администратору настраивать форму ввода пользователями своих имен и паролей. Она также дает возможность пользователям заканчивать сеанс без закрытия браузера.
Аутентификация по имени и паролю при незащищенных соединениях (не являющихся SSL-соединениями) применяется для идентификации пользователей без обеспечения наилучшей безопасности при доступе к данным на сервере, например когда администратор желает отобразить другую информацию для других пользователей при предоставлении имени пользователя и когда информация в базе данных не является конфиденциальной. Между пользователем и сервером в зашифрованном виде не передается никакая информация, включая имя и пароль. В этом случае аутентификации по имени и паролю некоторые хакеры удерживаются от проведения атак, что, впрочем, не предотвращает действия других по прослушиванию сетевых пересылок и подбору паролей.
При использовании протокола SSL вся информация, включая имя и пароль, зашифрована. SSL обеспечивает пользователям конфиденциальность и целостность данных при проведении аутентификации по имени и паролю. Требование введения имени и пароля в дополнение к предоставляемой протоколом SSL безопасности обеспечивает безопасность для тех пользователей, которые не применяют аутентификацию по сертификату клиента, и позволяет вам идентифицировать отдельных пользователей, которые осуществляют доступ к базе данных.
Программный интерфейс приложений Web-сервера Domino [Domino Web
За дополнительной информацией о DSAPI обратитесь к инструментарию программного интерфейса приложений для криптографии Lotus для Domino и Notes. Этот инструментарий доступен по следующему адресу:
Сеансовая аутентификация по имени и паролю является альтернативой аутентификации по имени и паролю для Web-клиентов, и обеспечивает дополнительные функциональные возможности, которые не доступны при простой аутентификации по имени и паролю.
Сеансом считается время, в течение которого Web-клиент проводит работу на сервере с наличием cookie. Для указания параметров, которые разрешат сеансовую аутентификацию и дадут возможность управлять ею, в зависимости от желаемой конфигурации должен быть отредактирован документ Web Site или документ Server.
Кроме того, при разрешении сеансовой аутентификации существует два варианта выбора: опция использования для отдельного сервера и опция для мультисерверного использования. Выбор опции применения для отдельного сервера вызывает генерирование cookie, который принимается на обработку только тем сервером, который его сгенерировал, тогда как опция для мультисерверного использования генерирует cookie, который позволяет применить принцип единственной подписи при работе с любым сервером, который участвует в совместном употреблении документа конфигурации принципа единственной подписи для Web.
Для применения аутентификации на основе сеанса Web-клиенты должны использовать браузер, который поддерживает cookies.
Использование сеансовой аутентификации по имени и паролю предлагает более хорошее управление взаимодействием с пользователем, чем простая аутентификация по имени и паролю. К примеру, существует возможность осуществлять пользовательскую настройку формы ввода пользователями своих имен и паролей. Она также позволяет пользователям заканчивать сеанс без закрытия браузера.
HTML-форма начала сеанса дает возможность пользователю вводить имя и пароль, после чего применять эти имя и пароль на протяжении всего пользовательского сеанса. Браузер отправляет имя и пароль серверу с использованием набора символов сервера. При сеансовой аутентификации по протоколу HTTP пользователь может ввести имя с применением любых печатаемых символов из кодовой таблицы Unicode. Однако пароль пользователя должен быть введен любыми печатаемыми символами из кода US-ASCII.
Примечание. Диапазон печатаемых символов не допускает наличия управляющих символов.
Domino предусматривает HTML-форму по умолчанию ($$LoginUserForm), которая предоставляется и конфигурируется в базе данных конфигурации Domino (DOMCFG.
Вы можете задать временной период окончания сеанса по умолчанию для отключения Web-клиента от сервера после указанного периода отсутствия его активности. Это приведет к тому, что cookie, который Domino применяет для отслеживания сеанса пользователя, окончит функционирование.
Автоматическое окончание сеанса пользователя на сервере помешает другим применять Web-клиент, выдавая себя за пользователя, если последний покинул рабочую станцию, не завершив сеанс.
Если для сервера разрешена аутентификация по имени и паролю на основе сеанса, то пользователи могут также добавлять в конец URL-адреса ? для окончания сеанса, например:
http://acmeserver/sessions.nsf?logout
Также существует возможность по окончании сеанса осуществлять перенаправление к элементу дизайна или к URL-адресу, для примера приведем следующие адреса:
http://acmeserver/sessions.nsf?logoutredirectto=/logoutDB.nsf/logoutApp?Open http://acmeserver/sessions.nsf?logoutredirectto=http://www.sales.com
Существует возможность встроить такое выражение в приложение (к примеру, используя его в кнопке) или вписать его как URL-адрес.
Вы можете задать максимальное количество параллельных пользовательских сеансов, разрешенных на сервере, только для аутентификации на основе сеанса для отдельного сервера. Если производительность сервера мала, это количество может быть уменьшено.
Domino 6 предусматривает возможности управления интернет-паролями для аутентификации на основе сеанса. Подробно это рассмотрено в документации по администрированию программного продукта Lotus Domino 6 и в файле помощи администратора Lotus Domino 6.
Примечание. Если серверы организации настроены на циклическую (
Мультисерверная сеансовая аутентификация, известная также как
В Web-браузерах пользователей должно быть разрешено использование cookies, так как генерируемый сервером маркер (token) аутентификации передается браузеру в cookie.
Аутентификация на основе сеанса при мультисервером использовании, или принцип единственной подписи, настраивается следующим образом:
Принимая во внимание различные сценарии обеспечения принципа единственной подписи для семейства программных продуктов Lotus, этой теме посвящена целая лекция. За дополнительной информацией по этому вопросу обратитесь к лекции 7, "Принцип единого входа".
Анонимный доступ позволяет интернет- и интранет-клиентам осуществлять доступ к серверам без идентификации себя. Domino не производит запись активности обращения таких клиентов к базам данных. К примеру, в этом случае вхождения не записываются в файле журнала (log file) и в диалоговом окне активности пользователей (User Activity).
Как и в случае анонимного доступа в Notes, при использовании анонимного интернет- или интранет-доступа невозможно узнать, кто осуществляет доступ к базам данных на сервере. Поэтому невозможно установить идентичность клиента, а соответственно имя и пароль клиента, для обеспечения управления их доступом к базам данных и элементам дизайна. Как и в случае анонимного доступа в Notes, анонимный интернет- и интранет-доступ должны использоваться в тех случаях, когда нет необходимости управлять доступом на основе идентичности клиента.
Возможность применять анонимный доступ с протоколами TCP/IP или SSL существует для любого сервера, на котором запущены LDAP, HTTP, SMTP или
Как уже упоминалось, существуют ограничения в плане безопасности при использовании данных механизмов аутентификации без привлечения дополнительных средств. Для того чтобы обойти эти ограничения, следует выполнять процесс аутентификации по защищенным шифруемым соединениям. Хорошим решением может быть использование протокола SSL, который будет описан в следующем разделе.
Как нами уже неоднократно упоминалось, аутентификация – это попытка реализовать два наших основных требования по обеспечению безопасности, а именно: обеспечение управления доступом и проверки подлинности. Как ни прискорбно, аутентификация не обеспечивает других первичных требований безопасности: обеспечения конфиденциальности и целостности данных.
Что еще хуже, аутентификация не является по-настоящему безопасной, потому что пароли отправляются по сети в форме, близкой к открытому тексту, – они закодированы с использованием кода Base64. Здесь надо сделать акцент на том, что пароли закодированы, а не зашифрованы. Base64 является алгоритмом кодирования, а не шифрования, и как таковой подразумевает возможность легкого обратного преобразования. Таким образом, принимая во внимание то, что пароли, как правило, передаются в HTTP-заголовках, в случае их перехвата (к примеру, с использованием пакетного сниффера) они легко могут быть декодированы и применены теми, кто выдает себя за реального пользователя.
Таким образом, необходим протокол, который использует технику криптографии. Существует несколько протоколов, которые могли бы удовлетворить данную потребность, но только один из них реализован универсально: протокол защищенных соединений SSL (Secure Sockets Layer).
Протокол SSL является широко используемым в Интернете, причем не только в связке с HTTP, но и совместно с другими популярными прикладными протоколами, а именно LDAP, POP3, HTTP, SMTP,
Протокол защищенных соединений первоначально был разработан компанией Netscape Inc., но на данный момент он реализован в большинстве клиент-серверного программного обеспечения, используемого в Интернете. В SSL применяется некоторое количество технических приемов криптографии, таких, как шифрование на основе открытого и симметричного ключей, цифровые подписи и сертификаты открытых ключей.
Примечание. Текущей версией протокола SSL является 3.0, однако она была вытеснена новым протоколом защиты транспортного уровня TLS (Transport Layer Security), протоколом стандарта IETF. Впервые TLS был определен в RFC 2246: "The TLS Protocol Version 1.0" ("Протокол TLS версии 1.0"). Так как в Notes и Domino нет поддержки протокола TLS - и нет планов по его поддержке в ближайшем будущем, в этой лекции речь пойдет только о протоколе SSL v3.
Протокол SSL версии 3, который был представлен в 1996 г., является протоколом обеспечения безопасности, который:
Существует две важные части протокола SSL:
Рис. 6.21 отображает упрощенную версию процесса рукопожатия SSL. Вот что происходит на этом этапе:
ClientHello с целью увидеть, сконфигурирован ли на сервере протокол SSL. Вместе с сообщением ClientHello клиент также передает список поддерживаемых клиентом опций шифрования и случайное число, которое будет использовано позднее.ServerHello и отправляет список поддерживаемых сервером опций шифрования. На этой стадии клиент и сервер узнают, какой из видов шифрования является для них общим (выбирается самое криптостойкое шифрование из всех возможных).Если требуется произвести аутентификацию клиента, которая предполагает использование сертификатов клиента, после завершения первых трех шагов происходит следующее:
(рис 6.21) Ведение переговоров об установлении сеанса протокола SSLПо существу, два "hello" сообщения используются, во-первых, для того, чтобы удостовериться в возможности проведения SSL сеанса, а если это возможно, то сервер предоставляет сертификат открытого ключа ( public key certificate ). Если требуется, клиент также предоставит сертификат открытого ключа ( public key certificate ). Это метод, с помощью которого SSL проверяет идентичность ( identity ) и подлинность ( authenticity ) сторон. На рис. 6.21 показаны как шаги по аутентификации сервера, так и шаги по аутентификации клиента.
(рис 6.22) Передача ключа сеанса SSLТак как имеет место аутентификация, то может быть и процесс передачи
На этой стадии "рукопожатия" (
ClientHello с перечнем возможных шифров (или алгоритмов шифрования) для использования в процессе шифрования.ChangeCipherSpec ) для подтверждения того, что они готовы взаимодействовать безопасным образом.Из этого примера вы можете видеть, что по сравнению с обычным HTTP-соединением в начале SSL-сеанса передается значительное количество дополнительных служебных данных. Протокол позволяет избежать некоторых из этих непроизводительных издержек путем разрешения клиенту и серверу сохранять информацию о ключе сеанса и возобновления этого сеанса второй раз без проведения переговоров об установлении сеанса и аутентификации.
Примечание. Важно быть внимательным по отношению к количеству SSL-соединений, которые будут разрешены на сервере, поскольку на стадии "рукопожатия" SSL может отрицательно влиять на производительность, что, соответственно, может неблагоприятно повлиять на производительность Web-сервера, предлагающего этот сервис.
После того как будет определен основной ключ ( master key ), клиент и сервер могут использовать его для шифрования данных приложения. Если требуется проведение аутентификации клиента, каждый обмен включает в себя также хеш содержимого сообщений. Хеш может использоваться для доказательства того, что сообщение является оригинальным, путем проверки его содержимого на предмет идентичности тому, что было отправлено. Алгоритм хеширования является частью выбираемых шифров. Хеш шифруется в обоих направлениях с помощью открытых ключей получателей. Каждый из участников (клиент и сервер) имеет соответствующий секретный ключ, который он использует для расшифровки пересылок по мере их получения.
Обычно в этом случае применяются алгоритмы
Заслуживает внимания тот факт, что, когда создается сертификат X.509, генерируются открытый и секретный ключи, которые никогда не уничтожаются. В отличие от этого
Это является важным преимуществом в обеспечении безопасности. Взлом (или математический вывод)
На практике, перед тем как применять подобную службу обеспечения безопасности на Web-сайте организации, необходимо найти ответы на некоторые вопросы. Вот несколько из этих вопросов:
Эти вопросы сводятся к четырем широким областям рассмотрения, с которыми мы будем иметь дело далее, а именно:
Если клиенты браузера, которые подключаются к Web-серверу, имеют общий с сервером доверенный сертификат или корневой сертификат, это обеспечивает доверие клиента браузера к тому факту, что сервер является тем, за что себя выдает.
Однако если существует необходимость настройки того, что пользователь может видеть на безопасном сайте, то возникает необходимость управлять именами пользователей и паролями для каждого пользователя.
С точки зрения клиента браузера, подключающегося к Web-сайту с использованием SSL, весь процесс ведения переговоров об установлении сеанса и аутентификации может быть полностью прозрачным. Для установления SSL-соединения префикс URL-адреса должен быть заменен с http:// на https://.
После того как SSL-соединение будет установлено, браузер предоставляет пользователю визуальную индикацию этого. Как правило, в большинстве браузеров это принимает форму символа закрытого висячего замка в нижней части окна браузера.
При аутентификации клиента аутентификация продвигается на один шаг далее. В этом случае сервер захочет узнать, можно ли доверять клиенту браузера на основе личности пользователя и его
Браузер производит обмен сертификатом клиента, который подписан центром сертификации [Certificate Authority (CA)], являющимся доверенной третьей стороной или даже внутренним доверенным центром. (Это разъясняется в разделе "Внутренний центр сертификации".)
Это обеспечивает необходимое доверие тому факту, что представленный сертификатом пользователь является тем самым человеком, за которого себя выдает. Данное явление предоставляет также дополнительное преимущество, состоящее в отсутствии необходимости управлять паролями для этих пользователей (что снимает одну из административных нагрузок), так как их аутентичность уже подтверждена центром сертификации.
С точки зрения Web-мастера SSL также достаточно прост. Web-мастеру необходимо только сгенерировать для сервера пару ключей, после чего получить для него сертификат.
Обычно это влечет за собой представление документации центру сертификации и уплату ежегодного взноса, хотя существует также возможность генерирования внутренних сертификатов для тестирования и использования в интранет-сети. Также существует возможность установить центр сертификации для организации. Различие между использованием внутреннего CA или CA третьей стороны, по существу, является предметом доверия. В пределах организации можно принять решение о том, что для служащих организации резонно будет доверять любому серверу интранет-сети, который по своему типу является внутренним сервером организации.
Если в организации принято решение разместить Web-сервер в Интернете, то возникает проблема, связанная с тем, как и почему Web-пользователь Интернета должен доверять организации и кем он является. Это особенно важно, если пользователи активно поддерживаются в проведении электронных транзакций с сервером, таких, как отправка данных кредитной карты при оплате товаров и услуг. Использование внешнего центра сертификации (доверенной третьей стороны), которому доверяет ваш браузер, позволит решить данную проблему.
Как показано на рис. 6.21, на котором отражен процесс "рукопожатия" SSL, аутентификация в SSL зависит от того, способен ли клиент доверять сертификату открытого ключа сервера. Мы уже упоминали об этом несколько раз, но, так как это очень важно, повторим снова. Сертификат связывает описание владельца пары ключей с открытой частью ключа. Достоверность сертификата гарантируется тем фактом, что он подписан некоторой доверенной третьей стороной, центром сертификации [certificate authority (CA)].
Но как сертифицирующий центр становится доверенным? В случае наличия браузера, способного работать с SSL, сертификаты доверенных центров сохраняются в базе данных ключей, иногда называемой файлом связки ключей (key ring file).
Перечень центров высшего уровня предварительно занесен в используемый браузер. Рис. 6.23 отображает доверенные корневые сертификаты (или сертификаты центров сертификации) для браузера Opera, который подобен другим широко распространенным браузерам.
(рис 6.23) Доверенные корневые сертификаты для браузера OperaЭтот подход имеет преимущество, заключающееся в очень простой настройке. Браузер может производить аутентификацию любого сервера, который получил сертификат открытого ключа от одного из центров сертификации из перечня без проведения какой-либо конфигурации или связи с требуемым CA.
Но ничто не безупречно, и при использовании этого метода также возникают некоторые проблемы.
Первая из них заключается в том, что новый CA не будет автоматически распознан до момента обновления браузера (где бы он в мире ни находился).
Вторая проблема заключается в том, что не существует способа обработки CA определяет, что владелец открытого ключа является мошенником, уже после выпуска сертификата, то сертификат все равно будет пригоден к употреблению до момента истечения его срока службы, причем без уведомления конечного пользователя о необходимости проявлять беспокойство.
Производители браузеров имеют состоящую из двух частей схему для решения первой проблемы.
Существует специальный формат MIME, application/x-x509-ca-cert, который позволяет браузеру принимать сертификат нового CA, который был подписан одним из известных CA. Этот формат определен в стандарте
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/
Если сеанс SSL установлен с CA. После этого пользователи могут сами выбрать, доверять ли этому серверу (но не CA, который подписал сертификат сервера).
Примечание. Неразумно, особенно для интернет-сайтов, устанавливать сервер, который предусматривает SSL-соединения, но для которого сертификат сервера выпущен неизвестным CA. При условии, что люди желают покупать у людей, которым они доверяют, получение предупреждения о том, что серверу сайта не может быть оказано доверие, не побудит людей доверять ему. Как правило, наилучшей практикой будет приобретение сертификата у одного из известных центров сертификации, предпочтительнее всего у одного из перечисленных во всех широко распространенных браузерах.
Существуют случаи, когда организация может рассмотреть учреждение внутреннего центра сертификации. По существу, это не такая уж и грандиозная задача, ведь обычно такое рассматривается для внутренних пользователей организации. В этой ситуации возможный риск будет небольшим и поэтому наличие CA вполне приемлемо для организации, так как Web-пользователи организации будут доверять любому серверу организации (даже в случае получения не рекомендующего делать это предупреждения). Также это означает, что организации нет необходимости уплачивать ежегодные отчисления внешнему CA.
Как упоминалось ранее, браузер поставляется с предварительно занесенным перечнем центров сертификации высшего уровня, и таким образом вы будете должны сделать выбор: либо иметь сертификат нового CA для организации, установленный на всех используемых в организации браузерах, либо, как это объяснялось ранее, дать пользователям знать о сообщении, которое они получат от браузера при подключении к сайту, подписанному не опознанным браузером центром сертификации.
На рис. 6.24 отображено предупреждающее сообщение, которое выдает браузер Opera при подключении к сайту, не являющемуся доверенным, и попытке установить с ним SSL-соединение.
В этой ситуации пользователь имеет три варианта выбора:
(рис 6.24) Сообщение, предупреждающее о том, что сайт не является довереннымТакже заслуживает внимания тот факт, что принятие доверия не является постоянным явлением и оно не будет применяться ко всем серверам, аналогично сконфигурированным в той же области. Другими словами, это не делает CA доверенным, и таким образом пользователь увидит те же уведомления, если ко второму серверу осуществляется доступ с сертификатом, подписанным тем же CA.
Примечание. Неразумно, особенно для интранет-сайтов, устанавливать сервер, который предусматривает SSL-соединения, но для которого сертификат сервера выпущен draft-ietf-smime- .
Так как сертификат открытого ключа предоставляет подтверждение личности, разумно предположить, что уровень подтверждения, необходимый для клиента, гораздо ниже уровня, необходимого для сервера.
Перед предоставлением сертификата сервера CA потребует документальное подтверждение законности запроса. Для клиента это доказательство зачастую может быть предоставлено online, потому что в этом случае требуется более низкий уровень проверки. Это особенно справедливо для интранет-среды. Сертификационные серверные продукты первоначально предназначались для тех организаций, которые хотели настроить процесс внутренней аутентификации.
Браузер Netscape для инициирования запроса сертификата клиента использует механизм, отличный от механизмов, применяемых в других браузерах (таких, как Mozilla, IE, Lynx и т. д.).
В случае Netscape ключом механизма является тег <, расширение HTML, которое применяется только в форме. Когда браузер видит этот тег, он генерирует пару ключей и возвращает запрос сертификата (в формате CA обрабатывает запрос сертификата и отправляет его обратно как подписанный
В случае других браузеров, к примеру Internet Explorer, единственным отличием в процессе запроса сертификата является то, что IE требует установки управляющего элемента регистрации сертификатов ActiveX (CERTENR3.DLL для IE 3.0 и XENROLL.DLL для IE 4.0). Этот управляющий элемент ActiveX генерирует открытый/секретный ключи и шифрует их в формат CA точно таким же образом, как это делает Netscape.
Помимо разъяснения понятия центра сертификации (Certificate Authority) в разделе о компонентах PKI, в предыдущем разделе мы увидели, что CA является связующим звеном, которое позволяет серверу и клиенту использовать протокол SSL. CA также является связующим звеном при обмене безопасными сообщениями электронной почты (такими, как S/MIME, которые мы кратко описали).
Существует возможность использовать третью сторону, коммерческий орган сертификации одной из упомянутых ранее компаний. В качестве альтернативы можно использовать центр сертификации Domino как внутренний CA для всей организации. За подробностями о настройке центра сертификации Domino 6 и обо всем процессе генерирования связок ключей, а также о сертификатах X.509 сервера и клиента (используемых для SSL-аутентификации и S/MIME) обратитесь к документу IBM (IBM Redpaper) The Domino Certification Authority, REDP (Центр сертификации Domino).
Бурное развитие применения в Интернете электронной почты является результатом упрощенного характера используемых протоколов. Данный факт является палкой о двух концах: простота в управлении гарантирует, что текущие стандарты обмена сообщениями хорошо подходят для миллионов пользователей; однако простота в исполнении имеет своим результатом множество открытых брешей и уязвимостей в обеспечении безопасности.
В этом разделе мы опишем средства, предлагающие обеспечить безопасный обмен сообщениями между клиентами электронной почты в Интернете, а именно опишем, как реализована эта безопасность обмена сообщениями, когда Lotus Notes используется как интернет-клиент обмена сообщениями, а Domino является интернет-сервером обмена сообщениями.
Перед тем как сделать это, давайте все-таки выполним краткий обзор технологий и стандартов, вовлеченных в основной процесс обмена сообщениями в Интернете.
Для отправки и получения почты в Интернете обычно употребляются следующие интернет-протоколы.
SMTP (Simple Mail Transport Protocol) определяет протокол для отправки сообщений электронной почты между хостами, хотя при использовании службы доменных имен DNS (Domain Name Service) и записей Mail eXchange (MX) он может предлагаться для отправки сообщений электронной почты пользователям между доменами.
Большинство систем электронной почты, которые отправляют почту по Интернету, используют для отправки сообщений с одного сервера на другой протокол SMTP. В дополнение к этому протокол SMTP, как правило, применяется для отправки сообщений от почтового клиента к почтовому серверу. Любой хост, который поддерживает SMTP, может также работать как ретранслятор SMTP, и в этом случае он может пересылать сообщения другому SMTP-хосту.
SMTP поддерживает только 7-битовые символы ASCII, что означает отсутствие поддержки выделенных символов, иностранных символьных наборов, обогащенного текста и чего-либо двоичного по своей сущности, например изображений и видео.
MIME (Multipurpose Internet Mail Extensions) являются спецификацией для форматирования сообщений, которые не являются сообщениями ASCII, для обеспечения возможности их отправки по Интернету.
Как упоминалось ранее, одной из проблем исходной спецификации SMTP было предположение о том, что сообщения электронной почты будут состоять в основном из текста, и соответственно в ней поддерживается только открытый текст ASCII.
MIME расширяет эту спецификацию за счет разрешения "переупаковки" двоичных данных в текстовую форму и передачи их по Интернету в почтовых сообщениях, которые совместимы с исходной спецификацией.
Если проводить сравнение, то сообщение электронной почты, которое поддерживает MIME, будет иметь дополнительную информацию в заголовке после поля Subject. Здесь приведен пример подобного сообщения.
From: frederic.dahm@ch.ibm.com To: roger.guntli@ch.ibm.com Subject: Map of Western Canada… MIME-Version: 1.0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: Content-Description: […JPEG data…]
Практически каждый клиент электронной почты поддерживает стандарт MIME, что позволяет им отправлять и получать графические, аудио- и видеофайлы посредством инфраструктуры обмена сообщениями в Интернете. В дополнение к этому, как уже упоминалось, MIME также поддерживает сообщения, представленные наборами символов, отличных от ASCII.
POP и IMAP (который мы опишем следующим) являются протоколами, которые определяют доступ к почте из почтового ящика в Интернете или с почтовой станции.
Почтовый протокол POP (Post Office Protocol) версии 3 (POP3) используется для приема электронной почты в сети. Не все компьютерные системы, которые применяют электронную почту, подключены к Интернету 24 часа в сутки, 7 дней в неделю. Некоторые пользователи звонят поставщику услуг по мере необходимости, в то время как другие могут быть подключены к ЛВС с постоянным соединением с Интернетом, но их рабочие станции могут быть не всегда включены.
В подобных случаях электронная почта, адресованная пользователям этих систем, отправляется центральной почтовой системе электронной почты, где она сохраняется для пользователей до тех пор, пока они не смогут ее принять.
POP3 дает возможность пользователю подключиться к почтовой системе электронной почты по сети. Почтовая система производит аутентификацию пользователя с применением ID и пароля, после чего позволяет скачать почту и, по выбору, удалить почту, находящуюся в центральной почтовой системе.
IMAP4 (
Последняя версия, IMAP4, подобна POP3, но предлагает дополнительные и более сложные возможности. С помощью IMAP, к примеру, можно работать с электронной почтой на сервере, проводить сортировку и управление электронной почтой, находящейся в папках на сервере.
За дополнительной информацией о IMAP обратитесь к Web-странице Стэнфордского университета, находящейся по следующему адресу:
http://www-camis.stanford.edu/projects/imap/ml/imap.html
Как упоминалось ранее, простота этих протоколов означает, что они создают проблемы в обеспечении безопасности для любого, кто отправляет и принимает почту посредством Интернета.
Протокол SMTP не использует какого-либо процесса аутентификации при установке связи с другим SMTP-хостом для передачи и доставки почты.
По существу, отправляющий хост посылает принимающему SMTP-хосту команду, содержащую информацию о том, кто он такой, и о его желании взаимодействовать. Принимающий хост доверяет тому, кто сказал, кто он такой, и ожидает дальнейших команд. После этого отправляющий хост посылает другую команду, содержащую информацию о том, от кого почта, и эту команду снова получает принимающий SMTP-хост. После этого отправляющий хост посылает другую команду, содержащую информацию о том, кто является вероятным получателем этой почты, и эту команду также получает принимающий SMTP-хост. После этого отправляющий хост посылает команду, сообщающую о том, что следует в текстовом сообщении, причем конец строки сообщения уведомляет о завершении сообщения.
Как можно видеть, при таком сценарии любой, имеющий в своем распоряжении сетевой сниффер, может получить сведения о таком трафике в сети, так как весь он отправляется в виде открытого текста. Что еще хуже, любому человеку достаточно просто сфальсифицировать сообщение на любом SMTP-сервере. Очень легко инициировать связь с SMTP-хостом и представить все так, будто почта была отправлена кем-то другим.
Насколько все это просто, демонстрирует следующий пример. При подключении к SMTP-хосту с использованием TELNET по порту 25 и отправке команд, которые ожидает принимающий SMTP-хост, мы можем сфальсифицировать сообщение электронной почты:
Telnet <SMTP host> 25 HELO foobar.com MAIL FROM: <reverse-path> RCPT TO: <forward-path> DATA SEND FROM: whatever.address@you.like
Исходная спецификация POP3 не определяет каких-либо методов аутентификации. Подобно SMTP, информация между клиентом POP3 и сервером POP3 отправляется открытым текстом. Фактически команды USER и PASS применяются для передачи имени пользователя и пароля при использовании для авторизации при подключении к серверу POP3 в целях получения почты. За дополнительной информацией об этом мы рекомендуем вам обратиться к RFC 1725 – Post Office Protocol – Version 3.
Существуют определенные усовершенствования, сделанные в этих протоколах для преодоления некоторых технических ограничений относительно вопросов обеспечения ИT-безопасности, однако все это еще далеко от совершенства, как мы и покажем в процессе последующего обсуждения.
В протокол были внесены изменения в метод аутентификации между клиентом и сервером, включая более новые и более
IMAP4 также предоставляет дополнительные механизмы аутентификации, такие, как Kerberos V4.
При связи с использованием POP3 или IMAP4 для шифрования сеанса существует возможность применять SSL. Это позволяет решить проблему слабых схем аутентификации, используемых в POP3 и IMAP4.
SASL (Simple Authentication and Security Layer (SASL)) определен в RFC 2222. Он описывает метод добавления поддержки аутентификации к протоколам на основе соединения. Каждый протокол, который использует SASL, включает команду для идентификации и авторизации пользователя на сервере и необязательного проведения переговоров об уровне безопасности при последующих взаимодействиях в рамках протокола.
Разработчики протоколов хотят использовать спецификацию SASL для поддержки аутентификации в своих протоколах (к примеру, расширение SMTP для проведения аутентификации является профилем SASL).
Domino применяет SASL только для служб LDAP. Domino использует SASL автоматически, если SSL – вместе с аутентификацией клиента – настроен на сервере и если клиент LDAP поддерживает протокол. В этом случае дополнительная конфигурация не нужна.
ESMTP, или расширенные службы для простого протокола пересылки электронной почты (
Расширения службы SMTP зарегистрированы в комитете по цифровым адресам в Интернете [Internet Assigned Numbers Authority (IANA)]. Примеры расширений SMTP включают: SMTP по TLS/SSL и уведомления о статусе доставки (Delivery Status notifications).
Когда клиент передает сообщение серверу SMTP, который поддерживает расширение аутентификации SMTP (AUTH=LOGIN), это позволит клиенту произвести аутентификацию пользователя по отношению к серверу. Расширение также защищает подлинность аутентификации в том случае, когда сообщение пересылается от одного SMTP-сервера к другому (предполагая, что оба SMTP-сервера поддерживают расширение). Однако, как упоминалось ранее, эта комбинация имени и пароля закодирована только с использованием base64.
SSL и TLS являются популярными механизмами для усиления TCP-соединений за счет обеспечения конфиденциальности и аутентификации. SSL и TLS широко используются вместе с протоколом HTTP, а также они применяются для дополнения безопасностью множества других общеизвестных протоколов, которые работают по TCP.
TLS и SSL очень подобны и используются одними и теми же способами; различие между ними заключается в применяемых ими алгоритмах шифрования. Вместо использования MD5, TLS употребляет функцию безопасного ключевого сборника сообщений HMAC.
При обеспечении безопасности SMTP с использованием SSL или TLS безопасным является только соединение между двумя хостами. Этот механизм не является механизмом "полного цикла", и транспортировка почты от инициирующего ее агента пользователя к получателю не является безопасной. Доставка отдельной части почты может проходить между более чем двумя SMTP-серверами, и, таким образом, добавление конфиденциальности SSL или TLS для одной пары серверов не означает, что вся цепочка SMTP сделана конфиденциальной.
Примечание. Служба SMTP из состава Domino 6 поддерживает несколько расширений SMTP, включая SSL-передачу по TCP/IP.
Разрешите расширения SMTP, используя Lotus Domino Administrator или клиент Lotus Notes и выполнив следующие действия:
SMTP при поддержке расширений SMTP может гарантировать, что была проведена корректная аутентификация исходного соединения "клиент-сервер". Однако это не гарантирует, что во время транзита при использовании SMTP каждый отдельный двухточечный отрезок пути передачи сообщения будет использовать вышеупомянутую аутентификацию.
Кроме того, само сообщение не зашифровано. Это может быть решено путем использования другого расширения SMTP, которое обеспечивает, что соединения SMTP (клиент/сервер или сервер/сервер) шифруются с использованием пары открытого/закрытого ключей. Однако это снова не гарантирует, что сообщение во время транзита будет зашифрованным на каждом отдельном двухточечном отрезке пути передачи сообщения на всем своем пути по направлению к получателю. Даже если было бы возможным гарантировать, что сообщение электронной почты было корректно аутентифицировано доверенными серверами SMTP и полностью зашифровано на двухточечных отрезках пути передачи сообщения на своем пути от отправителя к получателю, все равно это еще не позволит избежать возможности того, что сообщение не было сфальсифицировано (подделано) кем-то другим.
Таким образом, единственным надежным способом обеспечить конфиденциальность, аутентификацию и целостность сообщения электронной почты является обеспечение уверенности в том, что MIME-контент сообщения обработан криптографическим образом (с использованием различных методов шифрования). До настоящего времени для достижения этого существовало два конкурирующих стандарта: PGP и S/MIME. Первым давайте обсудим PGP.
PGP (Pretty Good Privacy), является высоко безопасной системой шифрования на основе открытых ключей, предназначенной для отправки безопасной почты по всему миру. Она была разработана
Доступна также система GnuPG (Gnu Privacy
Информацию относительно общедоступной лицензии GNU можно найти по адресу:
http://www.gnu.org/copyleft/gpl.html
PGP не имеет ключевых возможностей управления. Фактически структура его сертификатов очень неопределенная, в ней вместо наличия центров, выпускающих сертификаты для отдельных людей, работает модель "инфраструктуры доверия", когда сертификаты приобретают полномочия после подписки их известными или доверенными людьми.
Более новый стандарт, называемый OpenPGP, разрешает иерархический подход для согласования работы центров сертификации, сертификатов X.509 и других уже принятых стандартов. За дополнительной информацией об OpenPGP обратитесь к следующему URL-адресу:
Формат сообщений OpenPGP разъяснен в RFC2440, доступном по адресу:
http://www.ietf.org/rfc/rfc2440.txt
Пока PGP рассматривается как некоторая хорошая альтернатива для принятия по всему миру, большинство корпораций увлечены реализацией протокола S/MIME для обеспечения обмена сообщениями как внутри, так и за пределами организации. Мы рассмотрим S/MIME в последующем разделе и подробно опишем, как он работает совместно с клиентом Lotus Notes и сервером Lotus Domino.
S/MIME (Secure Multipurpose Internet Mail Extension) является технологией обеспечения безопасности электронной почты, разработанной компанией RSA для шифрования и цифрового подписания сообщений электронной почты.
Рабочая группа S/MIME завершила работу по пяти предложенным стандартам, которые были обобщены в спецификации S/MIME версии 3. Они приведены далее.
Lotus Notes и Domino 6 полностью поддерживают S/MIMEv3.
Шифрование сообщения происходит для всего контента сообщения или только для определенных частей MIME путем осуществления прогона их через алгоритм шифрования, который использует открытый ключ получателя. S/MIME применяет алгоритм открытых ключей для обмена ключами и для обеспечения цифровых подписей, предлагая для этого два
В этом разделе мы более подробно рассмотрим то, как работает S/MIME. Нашей целью является помочь вам понять, как в Notes и Domino 6 осуществлена реализация и поддержка S/MIME. S/MIME предоставляет пользователям следующие основные возможности:
С помощью этих возможностей достижимы следующие преимущества:
В целях обеспечения секретности сообщений, или конфиденциальности, S/MIME использует асимметричные ключи (открытый и секретный ключи) для шифрования сообщений. По существу, это тот же метод, который используется в Notes и разъяснен в разделе о Notes PKI.
Для отправки зашифрованного S/MIME-сообщения необходимо получить открытый ключ получателя сообщения и зашифровать сообщение с его использованием. Так как единственным человеком, который имеет связанный с этим ключом секретный ключ, является получатель, сообщение может быть безопасно отправлено с уверенностью в том, что только его получатель будет способен расшифровать это сообщение. Данный метод полностью подобен методу, используемому в Notes, и представлен на рис. 6.16 и 6.26.
Это практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на рис. 6.26 шаги описаны далее.
(рис 6.26) Шифрование сообщения электронной почты в S/MIMEЕсли клиент обмена сообщениями Боба не способен расшифровать отправленную Алисой электронную почту, причиной этого возможно будет то, что Боб получил новый сертификат X.509 и открытый ключ в каталоге, к которому осуществляет доступ Алиса, является старым ключом.
Рассматривая показанный на рис. 6.26 процесс, мы увидим, что на самом деле этот метод в S/MIME часто упоминают как "цифровой конверт" (
Этот метод является предпочтительным, потому что намного быстрее зашифровать все сообщение с использованием более короткого симметричного ключа, чем шифровать сообщение с применением более длинного асимметричного ключа. Сообщение при этом остается полностью безопасным, так как этот подход совмещает скорость симметричного шифрования с безопасностью
Для обнаружения
S/MIME обеспечивает подпись сообщений путем использования цифровых подписей, что позволяет проводить аутентификацию сообщения (подтверждение того, что отправивший сообщение человек действительно является отправителем), а также обнаружение
(рис 6.27) Используемые в S/MIME цифровые подписиТаким образом, результатом для пользователя является то, что клиент обмена сообщениями отобразит, кто подписал сообщение, если проверка достоверности подписи прошла успешно. В противном случае клиент обмена сообщениями отобразит, что не может проверить достоверность подписи.
Процесс цифровой подписи гарантирует две вещи:
Важно! Здесь не должно быть путаницы с шифрованием сообщения, когда сообщение шифруется с использованием открытого ключа получателя. В случае цифровых подписей сборник шифруется с применением секретного ключа отправителя. Может возникнуть ситуация, когда отправитель желает не только подписать сообщение, но и зашифровать его. В этой ситуации сообщение подвергается процессу шифрования электронной почты с использованием открытого ключа получателя, после чего подвергается шифрованию хеша с применением секретного ключа отправителя. Спецификация S/MIME не определяет порядок, в котором должно происходить шифрование при шифровании и подписании сообщения. Другими словами, соответствующий RFC говорит, что сообщение может быть зашифровано, а затем подписано с применением цифровой подписи либо подписано с применением цифровой подписи, а затем зашифровано.
Давайте более подробно рассмотрим, как отправитель при использовании S/MIME фактически устанавливает подлинность того, что сообщение получено от того, от имени кого оно заявлено.
Как мы говорили, сообщение зашифровано с использованием секретного ключа отправителя. Вместе с подписанным сообщением отправитель также посылает свой сертификат X.509 (собственно сам по себе сертификат не представляет собой ничего другого, как подписанный открытый ключ отправителя). Этот сертификат подписан другой стороной, центром сертификации.
Что произойдет, если центр сертификации ( CA ), который подписал открытый ключ отправителя, не является доверенным? S/MIME решает эту проблему путем применения того, что известно как цепочка доверия (chain of trust). Это означает, что, когда отправитель посылает зашифрованное сообщение вместе с собственным сертификатом отправителя (который содержит его открытый ключ, подписанный CA третьей стороны), он отправляет также сертификат CA третьей стороны. Этот другой сертификат сам может быть подписан другим CA либо на самом деле может являться корневым сертификатом. До тех пор пока можно доверять какому-либо из сертификатов CA в этой иерархии, можно доверять CA, который подписал открытый ключ отправителя.
Итак, как вообще можно доверять CA? В клиенте обмена сообщениями содержится список центров сертификации и их открытых ключей, причем все из них являются доверенными; это встроено в клиент обмена сообщениями для облегчения распространения сертификатов CA (подобно тому, как это встроено в браузер, что мы видели ранее). Соответственно на данный момент мы имеем следующее:
CA, который подписал сертификат отправителя.При наличии этой информации на текущий момент возможна проверка достоверности личности отправителя, так как сертификат отправителя, который был отправлен, может быть расшифрован с помощью открытого ключа CA, который имеется в клиенте обмена сообщениями и является доверенным.
Если такая проверка происходит успешно, то после этого существует возможность подтвердить достоверность сертификата и всего его содержимого, которое составляют имя отправителя, открытый ключ отправителя, название организации, страны и адрес электронной почты. Теперь, когда открытый ключ отправителя является доверенным, можно расшифровать сообщение и посмотреть, было ли оно подписано тем же человеком.
Следует заметить, что в сертификате отправителя существует и еще одна часть информации: адрес электронной почты. Эта информация является решающей в обеспечении уверенности в том, что сообщения электронной почты не были подделаны, даже если сообщение может быть корректно расшифровано с использованием открытого ключа отправителя. Если соответствующий сертификат не имеет сопоставимого адреса электронной почты, это может говорить о том, что сообщение было отправлено другим пользователем. Насколько в таком случае сообщение или отправитель могут заслуживать доверия?
Если такое случается, то в будущем это может вызвать у нас некоторые проблемы, так как люди имеют склонность заводить себе множество адресов электронной почты. Такие люди могут иметь рабочий адрес электронной почты, личный адрес, возможно второй рабочий адрес, если они временно работают по местонахождению клиента.
Означает ли это необходимость содержания трех наборов из пар открытого/секретного ключей и сертификатов? В этом нет необходимости, так как существует возможность экспорта S/MIME из одного клиента обмена сообщениями в другой с использованием стандарта
В случае выполнения попытки отправить подписанное сообщение получателю, который не имеет клиента обмена сообщениями, способного обработать S/MIME, существует два вероятных исхода этой ситуации в зависимости от возможностей отправляющего S/MIME-клиента.
Если сообщение отправлено как непрозрачное (opaque), это означает, что подпись отправлена как тип MIME "application/pkcs7-signature" (приложение/подпись pkcs7). Соответственно несовместимый с S/MIME клиент не будет способен прочесть тип "pkcs7-signature" (подпись pkcs7). Клиент S/MIME сперва разобьет входящее сообщение, после чего проверит достоверность подписи.
Если сообщение отправлено как прозрачное (clear), это означает, что подпись вставлена как часть типа объекта MIME "multipart/signed" (многоэлементный/подписанный). Подпись генерируется из сообщения путем его хеширования, а тип "application/pkcs7-signature" вставляется во вторую часть типа MIME. Это означает, что любой получающий сообщение клиент будет способен получить обе части типа MIME – неподписанное сообщение и в виде прикрепления тип MIME "application/pkcs7-signature".
Стандарт
Соответственно целью стандарта CA как VeriSign, то этот пользователь был бы способен применять его только в связке с Outlook Express. Аналогично если бы пользователь запрашивал сертификат с помощью Netscape Navigator, то этот пользователь был бы способен применять его только в связке с Netscape Messenger.
Чтобы клиент был способен отправлять подписанные и зашифрованные сообщения электронной почты с использованием S/MIME, необходимо иметь сертификат X.509. Нынешнее поколение способных работать с S/MIME клиентов обмена сообщениями обеспечивает возможность генерирования запроса сертификата с помощью находящегося в Сети CA. После того как сертификат клиента был запрошен (и утвержден), он устанавливается в способный работать с S/MIME клиент обмена сообщениями таким образом, что клиент может подписывать и шифровать любые сообщения электронной почты.
Также необходимо сделать сертификат пользователя доступным для любого, кто захочет отправлять зашифрованные сообщения электронной почты этому пользователю. Адресованные пользователю зашифрованные сообщения электронной почты шифруются с применением открытого ключа этого пользователя.
Рис. 6.28 является высокоуровневым представлением процесса запроса и получения сертификатов, а также отправки подписанных и зашифрованных сообщений электронной почты, как это реализовано в нынешнем поколении способных работать с S/MIME клиентов обмена сообщениями.
(рис 6.28) Циркуляция сертификатов и S/MIME-сообщенийШаги, требуемые для запроса сертификата клиента в S/MIME-клиент, как показано на рис. 6.28, приведены далее.
ID для приема в целях использования в том месте, где может быть получен подписанный сертификат клиента.ID для получения и забирает подписанный сертификат клиента.В нынешнем поколении клиентов обмена сообщениями, способными работать с S/MIME, существует несколько методов получения сертификата получателя.
Первый метод заключается в наличии отправленного получателем пользователю подписанного сообщения. Когда пользователь принимает его, клиент обмена сообщениями, способный работать с S/MIME, автоматически добавит сертификат отправителя в список сохраненных сертификатов. Подобным же образом если пользователь отправляет подписанную электронную почту другому пользователю электронной почты, который применяет клиент обмена сообщениями, способный работать с S/MIME, то это лицо получит копию сертификата первого пользователя.
Второй метод заключается в обеспечении доступа к LDAP в целях предоставления пользователям возможностей поиска в онлайновых каталогах (таких, как Four11, Bigfoot, Switchboard и т. д.). Если требуемый сертификат сохранен в одном из этих каталогов, пользователь будет способен добавить его в персональный адресный список клиента обмена сообщениями, способного работать с S/MIME.
Раз в интересах сообщества пользователей Lotus Notes существует инфраструктура на основе CA внутри организации, то для пользователей так же просто отправлять и получать S/MIME-сообщения, как и отправлять и получать почтовые сообщения Notes. В этом разделе мы покажем, как объединены в одно целое клиент Lotus Notes 6, сервер Domino Server 6 и S/MIME.
Для обычных пользователей Notes, которые понимают, что такое сертификаты Notes и файлы Notes ID, понятия шифрования и подписания не представляют собой ничего нового.
В версии 6 файл Notes ID, который содержит собственные сертификаты Notes, также используется в качестве контейнера для хранения сертификатов X.509 v3. Когда сертификат запрашивается Web-центром сертификации (либо центром сертификации Domino, если он реализован внутри организации, либо центром сертификации третьей стороны), он запрашивается через браузер Notes. Когда запрос на сертификат клиента утвержден, он сохраняется в файле ID пользователя Notes.
Notes имеет возможность создания безопасных копий файлов ID пользователей Notes. Безопасная копия представляет собой, по существу, открытый ключ и связанные с ним подписанные сертификаты. В текущей версии Notes не существует возможностей создания безопасных копий сертификатов X.509. Поэтому невозможно осуществлять импорт или экспорт сертификатов S/MIME-клиента в Notes или из него за исключением случаев использования стандарта
Для подписания электронной почты с применением S/MIME пользователь должен установить свой сертификат X.509 в свой файл Notes ID. Для пользователя существует возможность применять либо сертификат, выпущенный Notes, сертификат, выпущенный центром сертификации Domino, либо сертификат, выпущенный любым другим, представляющим третью сторону, коммерческим центром сертификации. Эта процедура в точности соответствует той, которая описана в разделе о центре сертификации Domino.
Перед тем как осуществить шифрование сообщения, как было описано ранее, пользователю необходимо получить сертификат получателя. Клиент Notes зашифрует сообщение с применением открытого ключа получателя. В Lotus Notes 6 сертификаты клиента получателей хранятся в каталоге Domino (Domino Directory).
Когда пользователь Lotus Domino 6 предпринимает попытку отправить зашифрованное сообщение, применяется сертификат X.509 получателя, причем на основе произведенного пользователем выбора относительно того, применять ли формат MIME либо формат Notes для отправки почты напрямую в Интернет или для сообщений, которые адресованы по интернет-адресам. И наоборот, пользователи также могут управлять форматом входящей почты согласно своим пользовательским предпочтениям. Формат сообщения определяет выбор метода шифрования.
Notes использует S/MIME-шифрование для исходящей почты в следующих ситуациях:
Помимо требований, определенных для S/MIME, сертификат X.509 получателя должен быть доступен в персональной адресной книге или в каталоге Domino. Если Notes не может найти сертификат получателя, то пользователь увидит отображенным окно сообщения об ошибке.
Если параметры установлены должным образом, то отправка зашифрованного сообщения сведется только к выполнению пользователем щелчка мыши на кнопке Delivery Options (Опции доставки) и выборе позиции для отметки Encrypt (Шифровать). В противном случае все было бы так, как если бы пользователь отправлял почту Notes.
(рис 6.30) Диалоговое окно безопасности: закладка MailПользователь может также выбрать вариант шифрования всех отправляемых почтовых сообщений. Это выполняется в клиенте Lotus Notes 6 путем выбора пунктов меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), выбора после этого закладки Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее выбора в ней позиции для отметки Encrypt mail that you send (Шифровать почту, которую вы отправляете), как показано на рис. 6.30.
Для пользователей существует возможность подписывать либо отдельные почтовые сообщения, либо все отправляемые ими почтовые сообщения. Перед подписанием сообщений пользователи должны убедиться в том, что ими получены свои собственные сертификаты X.509 в их файлах ID пользователя Notes.
Для осуществления подписи отдельного почтового сообщения при завершении его написания пользователь щелкает мышью на кнопке Delivery Options (Опции доставки) и выбирает позицию для отметки Sign (Подписать).
В качестве альтернативы для подписания всех отправляемых пользователем почтовых сообщений пользователь может выбрать пункты меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), после чего выбрать закладку Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее в ней выбрать позицию для отметки Sign mail that you send (Подписывать почту, которую вы отправляете).
После получения подписанной электронной почты Notes попытается проверить достоверность подписи.
Если пользователь доверяет подписанному сертификату, т. е., если пользователь имеет сертификат подписавшего или перекрестный сертификат Интернета для отправителя, то в строке состояния клиента Notes отобразится сообщение, показывающее достоверность подписи, пример чего мы приводим ниже.
" Signed By: Bob, at 10:52 AM, According To: TestCertAuthority".
Если пользователь не доверяет подписанию сертификата, то он получит приглашение создать перекрестный сертификат Интернета по требованию. Пользователь может выбрать имя субъекта сертификата в сообщении, которому он желает доверять.
Примечание. Подписанные S/MIME-сообщения содержат цепочку сертификатов отправителя и подписавших. Результирующий перекрестный сертификат Интернета сохраняется в персональной адресной книге получателя. При создании перекрестного сертификата пользователь объявляет, что он доверяют сертификату, содержащемуся в подписанном S/MIME-сообщении. После этого проверка подписи может быть продолжена.
Наконец, для пользователя существует также возможность вручную сохранять адрес отправителя и сертификаты X.509 в своей персональной адресной книге. При просмотре подписанной S/MIME-почты пользователь должен выбрать пункты меню Actions – Tools – Add Sender to
Несмотря на то что Интернет позволяет отдельным людям и организациям взаимодействовать на таком уровне как никогда ранее, единственной величайшей проблемой, которая была и есть в Интернете, является проблема кому можно доверять.
Данная лекция показала роль, которую могут играть инфраструктуры открытых ключей в установлении подобного доверия и обеспечении уверенности в его сохранности. Это выполняется путем использования сертификатов X.509 совместно с установленными протоколами (к примеру, SSL) и стандартами обмена сообщениями (к примеру, S/MIME). Также в этой лекции показано, как в Notes и Domino реализованподдержка сертификатов X.509 и то как эти сертификаты запрашиваются, утверждаются, генерируются и устанавливаются в инфраструктуре Notes и Domino.
Мы обратимся не только к конкретной реализации PKI в Notes и Domino, но и к реализации PKI, ориентированной на Web, которая нацелена на предложение служб и технологий обеспечения безопасности, основанных на стандартах и ориентированных на Интернет.
Мы дадим определение центрам сертификации (Certificate Authorities) и центрам регистрации (Registration Authorities), а также укажем различия между ними. Далее мы объясним понятия набора ключей и сертификатов открытых ключей, а также рассмотрим, как их создать с помощью поставляемых с сервером Domino инструментов.
После создания соответствующих наборов ключей и генерирования сертификатов мы опишем, как настроить конфигурацию протокола SSL, и объясним, как SSL работает. Нами также предусмотрены некоторые примеры передового опыта по достижению наибольшей безопасности с использованием SSL при одновременном уменьшении оказываемого всем этим на сервер Domino воздействия.
Начнем наше рассмотрение с конкретной реализации инфраструктуры открытых ключей (PKI) в Lotus Notes и Domino. Для этого существует две причины:
Нам необходимо охватить большой объем информации. В лекции 1 мы обсуждали ключевые службы безопасности, которые должна предлагать безопасная система. Это следующие службы: конфиденциальность (
В этой лекции мы покажем, что встроенная в Notes и Domino инфраструктура открытых ключей предоставляет эти службы. Так как конфиденциальность, обеспечение целостности и невозможность отказа от авторства зависят от аутентификации, то основное внимание мы сосредоточим на этой службе безопасности.
Позже в этом разделе рассмотрены конкретные усовершенствования в Notes версии 6.
Перед тем как мы перейдем к подробному рассмотрению PKI, присутствующей конкретно в Notes и Domino, важно поговорить о регистрации и сертификации, так как эти термины часто путают.
Регистрация является действием, при котором подробная информация о пользователе вносится в каталог. В данном случае каталогом является каталог Domino (Domino Directory). Результатом процесса регистрации в Notes и Domino является идентификатор Notes ID.
Сертификация имеет два значения, которые имеют отношение к этой лекции и к Notes и Domino. Сертифицировать – значит официально подтвердить, что нечто является достоверным, правильным, подлинным и соответствующим стандарту. Сертифицировать также значит выдать лицензию или сертификат. Результатом процесса сертификации в Notes и Domino является создание сертификатов Notes и их запись в Notes ID.
Когда Lotus был впервые представлен, он предлагал только один тип сертификации: линейную сертификацию (flat certification). В Notes Версии 3 была представлена иерархическая сертификация (
Линейные сертификаты являются пережитком ранних времен Lotus Notes, и тот факт, что они все еще поддерживаются в версии 6, свидетельствует о приверженности Lotus принципу обратной совместимости. Обсуждением здесь данных сертификатов мы демонстрируем наше желание разобрать в этом справочнике все аспекты обеспечения безопасности. Однако мы рассмотрим важнейшие различия и интересные моменты. Для подробного ознакомления с линейными сертификатами читатели могут обратиться к ранней документации по Lotus Notes.
Между линейными и иерархическими сертификатами существуют следующие ключевые различия:
ID с линейными именами, которые промаркированы одним или более ID источников сертификации Notes. В отличие от этого иерархические сертификаты создают структурированные имена, которые содержат организованные в строгой иерархии имена идентификаторов ID источников сертификации Notes.Так как 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=.
Для Сэнди ее полностью определенным именем является "cn=Sandy/ou=Switzerland/o=Acme".
Для Дэйва его полностью определенным именем является "cn=Dave/ou=.
При регистрации сервера применяется все то же, с той лишь разницей, что вместо ID пользователя создается ID сервера.
Что касается аутентификации, пользователи и серверы могут осуществлять аутентификацию друг друга только в том случае, если они имеют как минимум один общий унаследованный сертификат. В нашем примере это означает, что все пользователи организации могут осуществлять
Наконец, иерархическая сертификация является решительным шагом вперед, и организации, которые все еще используют линейную сертификацию, должны серьезно рассмотреть переход на иерархическую сертификацию [а соответственно иерархические идентификаторы ( ID ) серверов, пользователей и источников сертификации] по следующим причинам:
Основой инфраструктуры открытых ключей Notes является идентификатор ( ID ) Notes. Notes ID является файлом небольшого размера (всего лишь несколько килобайтов), который содержит множество элементов, необходимых для использования служб, которые обеспечивает встроенная в клиент Notes инфраструктура открытых ключей (PKI). В этом разделе выполним обзор и рассмотрим различные типы Notes ID.
Notes ID является, по существу, "контейнером" для сертификатов и ключей шифрования. Существует три различных типа Notes ID:
ID-источников сертификации организации (О) и ID-источников сертификации подразделений организации (OU) (organizational unit). При генерировании идентификаторов первым создается ID-источника сертификации организации; это главный идентификатор для домена. Этот ID (если организация достаточно большая) используется по очереди для генерирования ID-источников сертификации подразделений организации. Эти источники сертификации используются позднее для генерирования двух других типов ID: ID-серверов и Notes ID пользователей.
Server ID ). Как предполагает их название, используются для серверов, являющихся частью домена Domino. Они уникально идентифицируют каждый сервер в домене.User ID ). Создаются для пользователей, являющихся частью домена Domino. Они уникально идентифицируют каждого пользователя в домене.Идентификаторам источников сертификации по причине способности генерировать ID-пользователей и серверов должна быть предоставлена большая защита, чем идентификаторам других типов. Они должны сохраняться на флоппи-дисках и находится в безопасном месте, отличном от жесткого диска сервера. Если вы применяете Domino 6, у вас имеется возможность использования Domino 6 CA, который позволит избежать распространения ID-источников сертификации Notes при употреблении администраторами.
Domino применяет идентификаторы ID для идентификации пользователей и управления доступом к серверам. ID-пользователей, серверов и источников сертификации содержат следующее:
primary keys ). Этот сертификат упоминается в Notes 6 как многоцелевой сертификат Notes.Наконец, секретный ключ и ключи шифрования в файле ID шифруются с использованием ключа, вычисленного на основе пароля пользователя, и, таким образом, получить доступ к нему может только владелец. Открытая информация, такая, как имя пользователя и открытый ключ, не шифруется.
Рис. 6.2 отображает структуру Notes ID, показывая как стандартную часть (которая создается для каждого Notes ID), так и необязательную часть (которая может быть добавлена в ID позднее).
Здесь необходимо отметить две вещи:
ID. Если секретный ключ Notes изменен, то устаревшая информация также сохраняется в файле ID в целях обратной совместимости (к примеру, вам может понадобиться устаревшая информация для прочтения старого зашифрованного письма электронной почты).ID источника сертификации. Это линейный Notes ID, который содержит минимум информации и не будет никак исприменяться во время попыток соединения клиента Notes с сервером в домене.(рис 6.2) Notes ID
Аутентификация Lotus Notes основана по большому счету на сертификатах Notes, которые хранятся в идентификаторах Notes ID.
Вообще говоря, сертификат является электронной "печатью", которая отображает доверенные взаимоотношения между объектами в мире Notes.
Если более формально, то сертификат является уникальным, обладающим электронной подписью сообщением, добавленным источником сертификации в файл Notes ID, который идентифицирует пользователя или сервер. Наряду с тем что пользователь может хранить и работать как с сертификатами Notes, так и с интернет-сертификатами (в оставшейся части этого раздела упоминаются конкретно сертификаты Notes).
Когда пользователь Lotus Notes пытается соединиться с сервером Lotus Domino, будь то почтовый сервер или другой тип сервера Domino в организации, то для идентификации себя на этом сервере ему необходим сертификат, а серверу необходим сертификат для идентификации данного лица. Соответственно вовлеченные в процесс клиент Notes и сервер Domino представляют друг другу свои сертификаты. Путем проверки сертификатов клиент Notes проведет идентификацию и аутентификацию сервера Domino, а сервер Domino проведет идентификацию и аутентификацию пользователя.
В целях разрешения установления этих доверенных взаимоотношений в сертификатах должно присутствовать определенное число информационных элементов. Сертификат Notes, как и Notes ID, содержит такие элементы, как:
ID. Notes использует открытый ключ для шифрования сообщений, которые посылаются владельцу открытого ключа, и для проверки достоверности подписи владельца ID.Затем все это сертифицируется, что означает – сертификат подписывается цифровой подписью источника сертификации с использованием секретного ключа источника сертификации, в целях подтверждения его аутентичности.
Рис. 6.3 отображает структуру сертификата Notes в составе Notes ID.
(рис 6.3) Сертификат NotesКак уже упоминалось, сертификаты хранятся в файлах Notes ID. Они также хранятся в документах Person (Человек), Server (Сервер) и
Представляя сущность содержимого файлов Notes ID, наилучшим вариантом будет думать о них, как о разновидности специализированной базы данных, которая хранит сертификаты Notes и пары ключей (секретный/открытый). Эта база данных затем шифруется с помощью пароля пользователя.
Когда серверы и пользователи зарегистрированы, Domino автоматически создает сертификат Notes для каждого файла ID сервера и пользователя. Эти сертификаты Notes имеют даты истечения срока действия, что означает необходимость повторного сертифицирования Notes ID по наступлению даты истечения его срока действия.
В дополнение к этому если изменилось имя сервера или пользователя, также должна быть осуществлена повторная сертификация соответствующего Notes ID таким образом, чтобы новый сертификат мог корректно связывать открытый ключ с новым именем.
Примечание. Изменение имени в ID пользователя может также оказать воздействие на представленные в данном файле Notes ID интернет-сертификаты. Мы расскажем об интернет-сертификатах немного позднее; однако заслуживает внимания то, что не только сертификат Notes связан с именем пользователя или сервера в файле Notes ID.
Существует три типа сертификатов Notes, которые могут находиться в вашем ID пользователя:
ID пользователя (User ID), даже если он не применяется.ID пользователя, он уже должен был иметь данный сертификат при модернизации до Notes 5 или выше.Вы можете просмотреть все сертификаты, представленные в ID пользователя Notes путем выбора следующих пунктов меню: File (Файл) – Security (Безопасность) – User Security (Безопасность пользователя) [для пользователей Macintosh будет Notes – Security (Безопасность) – User Security (Безопасность пользователя)]. После этого введите защищающий Notes ID пароль и щелкните мышью на Your Identity (Ваша подлинность) – Your Certificates (Ваши сертификаты). Существует две опции для отображения сертификатов Notes. Выберите опцию "Your Notes Certificates (ваши сертификаты Notes), как показано на рис. 6.4, для просмотра сертификатов, которые могут быть использованы для входа в Notes, для доступа к базам данных Notes и для обмена безопасной почтой с другими пользователями Notes.
(рис 6.5) Сертификаты Notes в Notes ID, опция Your Notes Certificates (Ваши сертификаты Notes)(рис 6.4) Сертификаты Notes при выборе опции All Notes Certificates (Все сертификаты Notes)Для предоставления более полного списка сертификатов Notes выберите опцию All Notes Certificates (Все сертификаты Notes), как показано на рис. 6.5, которая отображает вам все представленные в вашем ID сертификаты Notes, включая ваши сертификаты Notes, а также сертификаты центров сертификации Notes (Notes CA), которые выпустили ваши сертификаты.
Это одно из диалоговых окон, которые значительно изменились со времен R5.0. Отображение информации в вашем Notes ID было значительно упрощено и стало более легким для прочтения. Несмотря на это, потратим некоторое время на обзор списка сертификатов Notes, которые отображены на рис. 6.5.
Два элемента, отмеченные как Frederic Dahm/Switzerland/IBM, являются двумя сертификатами человека по имени Frederic Dahm, причем оба из них подписаны источником сертификации Switzerland/IBM. Один из них является интернациональным ключом с ограниченным размером ключа; другой является полноценным североамериканским ключом. Элемент, отмеченный как /Switzerland/IBM, является источником сертификации швейцарского подразделения, который, в свою очередь, был сертифицирован источником сертификации компании IBM. Наконец, элемент /IBM является источником сертификации IBM (источником сертификации самого высшего уровня в домене).
В сервере Domino и клиенте Notes версии 5.0 добавлена полная поддержка сертификатов x.509 v3. Это значит, что начиная с версии 5 и продолжая в версии 6, для клиента Notes существует возможность запрашивать сертификат у любого центра сертификации, включая центр сертификации Domino 6, и сохранять
Повторно обращая ваше внимание на Notes ID, заметим, что открытый ключ упоминается также как сертифицированный открытый ключ Notes. Он хранится в сертификате Notes. Его дополнение, секретный ключ, хранится в другой части файла Notes ID (как показано на рис. 6.2) и может встречаться только в Notes ID.
Открытые ключи несекретны, отсюда и их название. Любой пользователь может найти открытый ключ другого пользователя и употребить его для отправки пользователю шифрованной почты или для его аутентификации.
Пользователи должны быть способны получить открытый ключ источника сертификации, который выпустил сертификат, еще перед тем, как они смогут провести аутентификацию владельца сертификата. Если пользователь имеет сертификат, выпущенный тем же источником сертификации, который применялся для другого пользователя или сервера, то он может проверить открытый ключ сертификата, после чего достоверно знать, что открытый ключ связан с именем сервера или пользователя. Если пользователь не имеет сертификата, выпущенного тем же источником сертификации, то пользователь нуждается в проведении перекрестной сертификации в целях аутентификации.
Начиная с версии R5.0 существует возможность добавлять в файл Notes ID для пользователя Notes
Альтернативные имена несовместимы с версиями Notes, выпущенными ранее версии 5. В частности, существуют следующие ограничения:
Главной причиной наличия и использования Notes ID является аутентификация. Мы полностью опишем процесс аутентификации с использованием Notes ID в этой лекции позднее; а теперь обратим внимание на пароли.
Пароль, заданный идентификатору ID пользователя Notes во время регистрации, является механизмом защиты файла Notes ID от неавторизованного использования. При попытке применения файла Notes ID пользователю будет нужно ввести пароль для этого файла.
Относительно пароля Notes ID существует некоторая путаница. Он используется исключительно для разблокировки самого файла ID пользователя Notes – и больше ни для чего. Фактически для идентификации пользователя применяется пара ключей, содержащаяся в ID.
Пользователи могут иметь более одной копии своего файла Notes ID, и эти различные копии могут иметь разные пароли. По существу, это означает, что для изменения пароля пользователь должен знать существующий пароль для каждой из копий ID.
Несмотря на то что еще в предыдущей версии Notes была (и остается доступной в версии 6) представлена функциональная возможность восстановления Notes ID, хорошим тоном все еще считается выполнение резервного копирования файлов ID и запоминание их паролей.
Для предотвращения атак методами "подбора по словарю" и "прямого подбора" на пароли файлов ID и для уменьшения риска перехвата пароля в Notes применяется диалоговое окно введения пароля с антиспуфинговой функцией (функцией предотвращения обмана). Данное окно было представлено в версии 4 и получило дальнейшую поддержку в версии 6 Notes.
Если пользователь вводит некорректный пароль, то перед разрешением ему повторной попытки введения пароля Notes несколько секунд ожидает. Эта задержка увеличивается с каждой неудачной попыткой ввода вплоть до своего максимума в 30 секунд. Функция задержки затрудняет попытки ввода множества паролей в быстрой очередности в надежде получить правильную комбинацию.
Антиспуфинговый аспект диалогового окна пароля Notes состоит в изменении шаблона слева от текстового поля ввода пароля.
В версиях 4 и 5 этот шаблон был представлен в виде набора из четырех иероглифических символов. В версии 6 эти иероглифы были заменены на изображение кольца для ключей, к которому прикреплены различные объекты (такие, как ключи, карманный фонарик, карманный нож и т. д.), изменяющиеся после набора пятого символа. Этот новый дизайн показан на рис. 6.6.
(рис 6.6) Диалоговое окно ввода пароля NotesДанные динамические символы делают более затруднительной подмену на фальшивое диалоговое окно, которое перехватывает пароли, выдавая себя за диалоговое окно ввода паролей Notes. Пользователи должны быть осведомлены об особенностях данного окна и о факте изменения символов при вводе ими паролей. Если пользователи замечают, что символы не изменяются или вообще отсутствуют, они должны прекратить введение своих паролей и щелкнуть мышью на Cancel (Отмена). Также они должны запомнить последнее изображение после ввода своего пароля, потому что следующий после выведения символов алгоритм будет всегда вычислять один и тот же символ в конце. (Однако алгоритм достаточно сложен, и поэтому не так легко выяснить пароль, обращая внимание только на символы и на способ их изменения.)
Для обеспечения устойчивой безопасности файлов ID серверов и источников сертификации существующим Notes ID можно задавать составные пароли. При реализации указанного существует возможность потребовать, чтобы при использовании Notes ID действовали совместно более одного человека (как правило, это администраторы).
Здесь важно избежать некоторой, обычно присутствующей, путаницы. Когда к Notes ID применяются составные пароли, исходный пароль для Notes ID (или предыдущий, если пароль отличается от исходного) не является более действительным. Эти составные пароли заменяют исходный пароль и не являются кумулятивными (значит, они не добавляют себя к исходному паролю).
Существует также возможность указать, что для доступа к Notes ID требуется только подмножество заданных паролей. К примеру, существует возможность назначить для доступа к указанному Notes ID четыре пароля, но определено, что для доступа к Notes ID требуются только любые два из четырех паролей. Это свойство полезно, когда должны быть отменены положения политики безопасности, дающие полномочия по работе с ID источника сертификации единственному человеку.
Примечание. Мы рекомендуем, чтобы составные пароли задавались только для идентификаторов ID серверов Notes и идентификаторов ID источников сертификации Notes. Идентификаторы ID пользователей Notes не должны иметь заданных им составных паролей. Для установки составных паролей на Notes ID необходимо присутствие всех людей, которые будут задавать пароль для Notes ID. Для установки составных паролей выполните следующие действия:
Наиболее слабой частью инфраструктуры открытых ключей Notes являются выбираемые пользователями пароли, так как – и это хорошо известный факт – пользователи просто не выбирают хорошие пароли. Пароли, которые придумывает большинство пользователей, являются слишком короткими и слишком простыми для догадки (или, что еще хуже, в некоторых случаях они записываются на клочке бумаги рядом с компьютером).
В предыдущих версиях Notes и Domino при создании или повторной сертификации файлов Notes ID администратор мог указать минимальное количество символов для паролей.
Однако не все идентификационные фразы одинаковой длины являются равными по силе; некоторые из них являются более уязвимыми для атак подбора идентификационных фраз, чем остальные. К несчастью, выбор хороших идентификационных фраз может быть достаточно трудным. Идеальным вариантом будет полностью случайный набор символов алфавита верхнего и нижнего регистров совместно с цифрами и знаками пунктуации (например, Т3-%94#_6!), но подобные идентификационные фразы нелегки в запоминании и могут нуждаться в записывании. В отличие от этого идентификационные фразы, состоящие из одного-единственного слова (к примеру, password), обеспечивают слишком слабую безопасность.
Идентификационные фразы со смешанными регистрами, содержащие цифры и пунктуацию, обычно сильнее посимвольно, чем пароли, полностью содержащие символы нижнего регистра. Пароли, которые содержат слова, находящиеся в словарях проверки орфографии, как правило, намного более уязвимы посимвольно, чем любой другой вид пароля.
В Domino версии 5 было представлено новое свойство, которое было встроено на место замененного свойства ограничения минимальной длины пароля. При регистрации пользователя Notes администраторы систем версии 5 могут указывать уровень качества пароля.
Различие между длиной и качеством пароля является простым:
Уровни качества паролей сохраняются в файле ID как эквивалентные длины паролей, и, таким образом, ID-файл, созданный клиентом Notes 6, может использоваться в предыдущей версии Notes.
Так как пользователи не слишком хороши в создании достаточно сложных паролей для обеспечения устанавливаемого системой уровня качества, эта функциональная возможность породила большое разочарование у пользователей и вызвала появление множества запросов с просьбами восстановить функциональную возможность установки длины пароля.
В Domino 6 администраторы могут теперь требовать либо обеспечения минимальной длины пароля, либо минимального качества пароля. Их больше не обязывают использовать качество пароля для введения в действие паролей, которые незначительно лучше, чем обычно применяемые пользователями. Это может быть реализовано посредством политик, а конкретно с помощью документа параметров установки политик безопасности. (За дополнительной информацией обратитесь к документации на Lotus Domino 6 или к файлу помощи Lotus Domino 6 Administrator Help.)
Когда пользователь изменяет свой пароль с применением Domino 6, то, если введен в действие минимальный уровень качества, качество этого пароля оценивается и затем сравнивается с минимальной длиной пароля, указанной для этого файла ID. Если указанный пароль недостаточно сложен, попытка пользователя установить этот пароль отклоняется и пользователь увидит окно с сообщением об ошибке "Your Password is
Начиная с версии 4.5 в Notes добавлен процесс проверки паролей на сервере, который продолжает поддерживаться в версии 6.
Когда разрешена проверка паролей, то информация, зависящая от пароля пользователя и даты предоставления пароля, хранится на сервере в документе Person.
Для получения доступа к серверу пользователь должен ввести пароль, соответствующий хранимой в документе Person информации. Способность проверки паролей добавляет возможность потребовать установку интервалов изменения паролей пользователя и защищает от повторного применения 50 предыдущих, старых паролей.
Это очень хороший способ убедиться в том, что пользователями поддерживаются должные пароли, которые периодически изменяются. При употреблении в соединении с параметрами качества/длины паролей это свойство гарантирует, что созданные пользователями пароли соответствуют минимальным требованиям, изложенным в политике безопасности организации.
Как мы разъясняем в обсуждении аутентификации позднее в этой лекции, Lotus Notes использует для аутентификации пару ключей RSA. Это означает, что даже если кто-то разгадает пароль пользователя, то для возможности выдачи себя за другого пользователя этому человеку еще необходимо овладеть файлом ID пользователя. Хранимая в Domino Directory информация не является предметом атак с применением словаря, за исключением тех случаев, когда атакующий также имеет ID-файл.
Проверка паролей во время аутентификации требует, чтобы и клиенты Notes, и серверы Domino имели в своем распоряжении версию 4.5 или выше. Если вы разрешите проверку паролей на сервере, имеющем версию более раннюю, чем 4.5, то процесс аутентификации происходит без проверки паролей. Если вы разрешите проверку паролей у клиента, работающего на предыдущей версии, процесс аутентификации потерпит неудачу при осуществлении попыток клиента соединиться с сервером, требующим проверки паролей. Когда пользователь, для которого требуется проверка пароля, проходит процесс аутентификации с сервером в первый раз, 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, которые были сертифицированы с применением ID источника сертификации, который не содержит информации о восстановлении.
Все это ясно и лаконично изложено в разделе "Восстановление ID" документации по администрированию Lotus Domino 6 и в файле помощи Lotus Domino 6 Administrator Help.
После того как восстановление 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.
Информация обо всех идентификаторах Notes ID (включая ID каждого пользователя, сервера и источника сертификации) сохраняется на сервере Domino, а конкретно в базе данных Notes, называемой каталогом Domino (Domino Directory).
Каталог Domino содержит документ Person для каждого пользователя, который, в свою очередь, содержит множество информации о каждом из пользователей Notes. В табл. 6.1 показана структура документа Person.
| Закладка | Элементы |
|---|---|
| Basics (Основная информация) | Имя; Инициал второго имени; Фамилия; Имя пользователя; |
| Mail (Почта) | Почтовая система; Файл почты; Адрес пересылки; Интернетадрес; Шифрование входящей почты |
| Certificates (Сертификаты) | Сертифицированный открытый ключ Notes; Интернетсертификат; Ключ линейного имени |
| Administration (Администрирование) | Администраторы; Проверка пароля; Требуемый интервал изменения; Период льгот (grace period); Дата последнего изменения; Сборник паролей; |
(рис 6.7) Каталог DominoПримечание. В процессе регистрации идентификатору ID пользователя Notes, принадлежащему зарегистрированному пользователю, разрешается прикрепляться к документу Person. Это очень не одобряется, поскольку каталог Domino открыт по своей сущности, а идентификаторы ID пользователей Notes должны храниться безопасным образом.
Как результат процесса регистрации
То же самое верно и для источников сертификации, которые представлены в каталоге Domino документами
Как правило, люди путают концепцию иерархии сертификации с концепцией доменов Domino, полагая, что это одно и то же. На самом деле они полностью различны и независимы друг от друга.
Для простоты понимания домен Domino соответствует каталогу Domino. Домен Domino является совокупностью серверов Domino и пользователей, которые совместно применяют общий каталог Domino.
Каталог Domino является каталогом пользователей, серверов, групп и других элементов. По сути, основной функцией домена Domino является маршрутизация почты. Домены пользователей определяются по расположению их почтовых файлов на сервере.
В этом разделе мы рассмотрим несколько различных видов иерархии сертификации, а именно те из них, в которых существует множественная иерархия сертификации или множество доменов. В первую очередь рассмотрим модель, имеющую две иерархии сертификации в одном домене, а после этого опишем модель, имеющую одну иерархию, распределенную между двумя доменами.
Так как иерархия сертификации и домены Domino независимы друг от друга, внутри домена Domino вполне возможным представляется управление двумя и более иерархиями сертификации. В примере, отображенном на рис. 6.8, корпорации Acme и Widget подвергаются администрированию в пределах одного отдельного домена.
(рис 6.8) Две независимые иерархии сертификацииПримером того, что эта модель может быть подходящей, является ситуация, при которой две организации или компании являются недавно слившимися. Существует возможность продолжать управлять этими организациями независимо, без сворачивания обеих иерархий в одну общую, как показано на рисунке; но в конечном счете вы, возможно, захотите осуществить перекрестную сертификацию этих двух иерархий.
В качестве альтернативы существует возможность управлять одной иерархией сертификации в нескольких доменах Domino, как показано на рис. 6.9. В этом примере корпорация Acme имеет две дочерние компании: корпорацию
(рис 6.9) Одна иерархия сертификации в двух доменахПодобная конфигурация, "одна иерархия/два домена", может быть полезна в той ситуации, когда отдельный домен (или каталог Domino) вырос до очень больших размеров и вы должны настроить производительность сервера. Однако, принимая во внимание масштабируемость Domino, особенно в версии 6, и мощность доступных в наше время серверов, это не самый подходящий сценарий. Несмотря на это, такая возможность существует и заслуживает упоминания здесь.
Domino использует два типа перекрестных сертификатов: перекрестные Notes-сертификаты и перекрестные интернет-сертификаты. Перекрестные сертификаты Notes мы опишем в данном разделе, а перекрестные интернет-сертификаты – в разделе об инфраструктуре открытых ключей в Интернете далее в этой лекции.
Перекрестные сертификаты Notes разрешают аутентификацию и безопасный обмен сообщениями, и этим они дают возможность пользователям из различных организаций со своей иерархией сертификации осуществлять доступ к серверам и получать подписанные почтовые сообщения. Перекрестные сертификаты Интернета, с другой стороны, более сфокусированы на обеспечении безопасного обмена сообщениями, и этим они позволяют пользователям получать подписанные почтовые сообщения и отправлять зашифрованные почтовые сообщения.
Рассматривая уже приведенную нами модель с иерархиями сертификации, отметим, что аутентификация одним пользователем другого пользователя или сервера не будет проводиться, если любой из них находится в другом дереве имен.
Важность этой проблемы возрастает в организациях с динамической структурой, которые в наши дни становятся нормальным явлением (когда обычными являются слияния, приобретения, укрупнения и реорганизации).
В связи с этим регулярно возникает вопрос: "Как мы можем соединить несколько иерархий сертификации или деревьев имен?" Ответ состоит в том, что, хотя и невозможно просто и эффективно соединить несколько существующих деревьев сертификации в одну-единственную иерархию сертификации, возможность достичь успеха в этом направлении существует.
Notes и Domino предоставляют людям и серверам метод проведения аутентификации по отношению к другим серверам из других иерархий сертификации. Также они предоставляют людям из одной иерархии сертификации метод эффективного взаимодействия и обеспечения доверия людям из другой иерархии сертификации.
Это достигается посредством перекрестной сертификации, которая является формой одноранговой доверительной модели (сертификации).
Таким образом, если вкратце, перекрестные сертификаты Notes позволяют пользователям и серверам из различных организаций со своей иерархией сертификации осуществлять доступ к серверам организаций друг друга и проверять цифровые подписи пользователей из другой организации. Серверы Domino хранят перекрестные сертификаты в каталоге Domino. В целях обеспечения доступа к серверам Domino клиенты Notes получают перекрестные сертификаты для этих серверов и хранят их в своих персональных адресных книгах (Personal
Перекрестная сертификация может встречаться в организации на различных уровнях. Существует три возможных типа перекрестной сертификации, как это представлено далее:
Перед тем как мы опишем эти типы в деталях, определим несколько концепций, которые вам необходимо понимать.
Давайте допустим, что произошел типичный для наших дней случай из жизни организаций, при котором две отдельные организации, Widget и Acme, решили объединиться.
В этом случае организациям требуется простейшая форма перекрестной сертификации, при которой все пользователи и серверы обоих организаций способны проводить аутентификацию друг друга.
Для достижения этой цели будут выполнены следующие шаги:
/Acme ) получает перекрестный сертификат для источника сертификации организации Widget ( /Widget ) и сохраняет его в каталоге Domino организации Acme./Widget ) получает перекрестный сертификат для источника сертификации организации Acme ( /Acme ) и сохраняет его в каталоге Domino организации Widget.Как результат этой процедуры устанавливаются специальные отношения (говорят: "Acme и Widget доверяют друг другу" ). Это явление проиллюстрировано на рис. 6.10. В данной модели перекрестной сертификации все пользователи и серверы обоих организаций способны теперь проводить аутентификацию друг друга.
(рис 6.10) Перекрестная сертификация между двумя организациями
В этом случае перекрестная сертификация может осуществляться для двух пользователей, двух серверов или для пользователя и сервера.
Давайте предположим сценарий, при котором организации Acme и Widget желают проводить репликацию базы данных, которая содержит представляющую взаимный интерес информацию, но по своим политикам безопасности не желают иметь ничего общего, кроме взаимодействия друг с другом этих двух серверов.
Здесь организации хотят иметь наиболее ограниченную форму перекрестной сертификации, при которой сервер из одной организации выполняет аутентификацию и репликацию с сервером из другой организации.
Будут выполнены следующие шаги:
Server/Acme ) получает перекрестный сертификат для сервера Widget ( Server/Widget ) и сохраняет его в публичной адресной книге сервера Acme.Server/Widget ) получает перекрестный сертификат для сервера Acme ( Server/Acme ) и сохраняет его в публичной адресной книге сервера Widget.Как результат этой процедуры устанавливаются специальные отношения (говорят: "Сервер Acme и сервер Widget доверяют друг другу"). Это явление проиллюстрировано на рис. 6.11. В данной модели перекрестной сертификации только эти два сервера доверяют друг другу и могут осуществлять репликацию друг с другом.
(рис 6.11) Перекрестная сертификация между двумя пользователями (серверами)
В этом случае перекрестная сертификация может осуществляться для пользователя и всей организации или для сервера и организации.
Давайте предположим сценарий, при котором организации Acme и Widget желают проводить репликацию базы данных, которая содержит представляющую взаимный интерес информацию. Организация Widget намного меньше организации Acme и соответственно не имеет никаких проблем с предоставлением доступа ко всем своим серверам со стороны организации Acme, но так как Acme ведет дела со множеством организаций, являющихся конкурентами Widget, то согласно политике безопасности в этой организации желают предоставить доступ только к определенному серверу Domino.
Здесь одна из организаций желает провести наиболее ограниченную форму перекрестной сертификации, а другую организацию устраивает наиболее либеральная форма перекрестной сертификации, при которой один сервер организации Acme проводит аутентификацию и репликацию с любым сервером организации Widget.
Будут выполнены следующие шаги:
Server/Acme ) получает перекрестный сертификат для источника сертификации организации Widget ( /Widget ) и сохраняет его в публичной адресной книге сервера Acme./Widget ) получает перекрестный сертификат для сервера Acme ( Server/Acme ) и сохраняет его в каталоге Domino организации Widget.(рис 6.12) Перекрестная сертификация между пользователем и организациейКак результат этой процедуры устанавливаются специальные отношения (говорят: "Сервер Acme и организация Widget доверяют друг другу"). Это явление проиллюстрировано на рис. 6.12. В данной модели перекрестной сертификации серверу Acme доверяет вся организация Widget, и соответственно этот сервер Acme может выполнять репликацию с любым сервером организации Widget.
За дополнительной информацией по перекрестной сертификации и реальных стадиях ее выполнения обратитесь к документации на программный продукт Domino 6, либо к файлу помощи администратора Lotus Domino 6.
Аутентификация является наиболее важным аспектом обеспечения безопасности. Она более важна, чем шифрование. Мы затрагивали эту тему в лекции 1, а теперь наступил момент повторно обратиться к этому понятию.
Давайте возьмем Алису и Боба, которые были представлены нами в лекции 1. Предположим также существование Кэрол, которая не обменивается информацией ни с Алисой, ни с Бобом, но вместо этого имеет желание подслушивать и незаконно читать информацию, которой обмениваются первые двое.
Как мы узнали, Алиса и Боб хотят обмениваться данными друг с другом, но при этом желают удостовериться в том, что этот обмен выполняется настолько безопасно, насколько это возможно. В приведенном примере Алиса и Боб обмениваются финансовой информацией. Как люди, добросовестные в плане обеспечения безопасности, они используют безопасный канал связи, в котором применяется шифрование, чтобы таким подслушивающим, как Кэрол, было чрезвычайно трудно расшифровать и понять информацию.
Шифрование является важным элементом по причине существования потенциального ущерба, который мог бы быть нанесен, если бы Кэрол была способна получить понятную копию проходящей между Алисой и Бобом информации.
Тем не менее важно рассмотреть, что могло бы случиться, если бы Кэрол смогла выдать себя за Алису или Боба. В этом случае Кэрол смогла бы получить больше информации, а также смогла бы модифицировать информацию для обмена. Нанесенный в результате ущерб мог бы быть гораздо сильнее, чем ущерб, который мог бы быть нанесен в результате простого прослушивания.
Таким образом, аутентификация является краеугольным камнем эффективной безопасности. Так как она дает системе возможность отличать одного пользователя от другого, аутентификация является также краеугольным камнем безопасности Notes и Domino.
Без проведения аутентификации могли бы появиться следующие проблемы:
Аутентификация является тем элементом, который позволяет администраторам разрешать или запрещать доступ к ресурсам системы. Если лицо получило разрешение на доступ к системе, то этому лицу могут быть предоставлены различные привилегии (обычно называемые уровнями доступа).
Таким образом, аутентификация является ключом к обеспечению ограниченного доступа к ресурсам Notes и Domino.
Как правило, процедуру аутентификации в Notes не понимают. Люди полагают, что это простой ID пользователя/пароля, хотя в реальности эта процедура намного более сложна.
Так как в Notes процедура аутентификации зависима от инфраструктуры открытых ключей, непосредственно встроенной в клиента и сервер, мы займем некоторое время на рассмотрение того, как устроена собственная инфраструктура открытых ключей (PKI) Notes, после чего объясним, как работает аутентификация Notes.
Примечание. Термин "аутентификация Notes" используется потому, что он означает аутентификацию пользователя, применяющего клиент Notes по отношению к серверу Domino. Мы уточним этот термин немного позже, а его использование поможет нам отличать этот тип аутентификации от других ее типов, которые мы обсудим в этом курсе далее.
В этом разделе мы обсудим, как Lotus Notes и Domino проводят аутентификацию друг друга по порту 1352 протокола TCP с использованием протокола вызова удаленных процедур Notes [Notes Remote Procedure Calls (NRPC)]. Целью этого обсуждения является прояснить процесс и объяснить, что на самом деле происходит каждый раз, когда пользователь вводит пароль и получает доступ к серверу Domino с использованием клиента Notes.
При выполнении аутентификации Notes двумя отдельными этапами происходит проверка подлинности пользователя или сервера. Первый этап, называемый проверкой достоверности (validation), является процессом достоверного определения открытого ключа отправителя. Другими словами, проверка достоверности является подготовительным этапом реальной аутентификации.
При принятии решения об оказании доверия открытому ключу Notes использует следующие три правила:
Сейчас мы проведем обзор процесса проверки достоверности и рассмотрим, как эти три правила применяются во время этого процесса. Давайте в качестве примера пользователя возьмем Фреда. Файл ID пользователя для Фреда содержит все, что ему необходимо для своей идентификации, и устанавливает его полномочия. Когда он запрашивает у сервера сеанс, то первым шагом является отправка серверу всех сертификатов из файла Notes ID (как собственного сертификата пользователя, так и последовательности сертификатов источников сертификации, которые его поддерживают). Процесс проверки достоверности проиллюстрирован на рис. 6.13.
(рис 6.13) Процесс проверки достоверности в Notes и DominoПронумерованные на схеме шаги описаны далее.
Widget. Сервер заинтересован в нем, потому что "Восток" является источником сертификации для сертификата Фреда.Widget из своего собственного файла Notes ID сервера. (Согласно правилу 1, сервер будет доверять открытому ключу любого предка, который хранится в его файле Notes ID сервера.)Widget (который является доверенным, так как находится в его файле Notes ID сервера) для проверки того, является ли сертификат Восток/Widget действительным. (Согласно правилу 2, если сервер доверяет открытому ключу предка, то он будет доверять любому открытому ключу, полученному из сертификатов, которые были выпущены предком.)Восток/Widget, который теперь является доверенным, для проверки того, что сертификат Фред/Восток/Widget является действительным. (Согласно правилу 3, доверяем любому открытому ключу, который был сертифицирован любым из доверенных источников сертификации и принадлежит одному из потомков источника сертификации.)Этот же процесс выполняется в обратную сторону, и таким же образом Фред может достоверно ознакомиться с открытым ключом сервера.
Как мы упоминали в предыдущем разделе, аутентификация является доказательством подлинности. На этом этапе данное доказательство еще не осуществлено. Вот поэтому теперь, после завершения процесса проверки, нам необходимо начать процесс аутентификации.
Важно понимать, что процесс проверки, который мы только что описали, еще не полностью подтверждает, кто конкретно является вашим партнером в каждом из сеансов. То, что реально происходит на этапе проверки достоверности, является просто представлением сертификатов. Это взаимное представление сертификатов гарантирует, что как минимум один из сертификатов является общим для пользователей или серверов (или, в случае отсутствия этого, как минимум один сертификат имеет общего предка).
Установив это, сертификат ассоциирует пользователя с открытым ключом и сообщает получателю, что открытый ключ может быть доверенным, после чего в данном примере пользователь и сервер могут доказать, что они реально те, за кого себя выдают, путем демонстрации того, что они хранят секретный ключ, соответствующий открытому ключу в сертификате.
Процесс аутентификации добивается этого с помощью диалога запроса/ответа между рабочей станцией и сервером или между двумя серверами при запуске репликации баз данных либо при пересылке почты.
Процесс аутентификации, который построен на предыдущем примере, в котором Фред пытается получить доступ к серверу, проиллюстрирован на рис. 6.14. Несмотря на то что схема является сильным упрощением действительного процесса, она предназначена для иллюстрации того, что происходит, легким для понимания способом.
(рис 6.14) Процесс аутентификации в Notes и DominoПронумерованные на схеме шаги описаны
7. Сервер генерирует случайное число и
8. Сервер отправляет зашифрованное случайное число Фреду.
9. Фред получает запрос и расшифровывает его с помощью своего секретного ключа.
10. Фред отправляет расшифрованное число обратно серверу.
11. Сервер сравнивает ответ Фреда с исходным случайным числом.
12. Если результат совпадает с исходным случайным числом, то сервер может доверять тому, что Фред действительно тот, за кого себя выдает.
Как и в случае проверки достоверности, аутентификация также является двухсторонней процедурой. Далее Фред проводит аутентификацию сервера с использованием такого же процесса запроса/ответа, но на этот раз в обратном направлении.
Действительный алгоритм является сложным, но эффективным. Он избегает всяческих RSA-операций при последующих проведениях аутентификации между той же парой "клиент-сервер". Алгоритм также устанавливает
Существует возможность избежать процедуры проверки достоверности и сертификации, которые мы только что описали, путем отключения аутентификации на основе сертификатов. По существу, это указывает серверу разрешить анонимный доступ со стороны пользователей и серверов, достоверность которых сервер не проверяет и аутентификацию которых он не проводит.
Недостаток от осуществления этого должен быть очевиден. Сервер Domino, для которого разрешен анонимный доступ, не записывает активность пользователей и серверов. [Обычно это выполняется в файле журнала и в диалоговом окне активности пользователей (User Activity).] При анонимном доступе нет никакой возможности узнать, кто осуществляет доступ к базам данных на сервере. Таким образом, подлин ность пользователя невозможно применить для управления доступом к базам данных и элементам дизайна.
Позитивной стороной разрешения анонимного доступа является то, что он наиболее пригоден для предоставления общего публичного доступа к серверам для пользователей и серверов, с которыми у них не проводилась перекрестная сертификация. Как правило, это применяется для разрешения пользователям и серверам из-за пределов организации получить доступ к серверу без предварительного полученисертификата для организации.
В общем и целом, говоря о преимуществах и недостатках разрешения анонимного доступа к серверам Domino, следует отметить, что этот тип доступа должен рассматриваться только тогда, когда нет необходимости знать, кто осуществляет доступ к базе данных, или когда нет необходимости управлять доступом на основе подлинности клиента. Соответственно это предполагает, что доступная в этих базах данных и на серверах информация имеет низкую чувствительность, если не полностью находится в публичном домене.
Об анонимном доступе существует гораздо больше информации, чем мы можем привести здесь. Анонимный доступ может также быть предусмотрен для пользователей Интернета/интранета в соединении с шифрованием сеанса. Мы опишем это позднее в данной лекции в разделе об инфраструктуре открытых ключей в Интернете.
На данном этапе приведем шаги, которые необходимо выполнить для разрешения анонимного доступа к серверу Domino со стороны пользователей Notes и других серверов Domino.
Anonymous (Анонимный) в списках управления доступом (ACL) всех баз данных, для которых вы желаете разрешить анонимный доступ. Задайте соответствующий уровень доступа – обычно доступ с правами Reader (Читатель). Если вы не добавите Anonymous в качестве элемента в ACL, анонимные пользователи и серверы получат доступ Default (По умолчанию).Наконец, финальное слово об анонимном доступе. Если пользователь находится в среде иерархической сертификации и предпринимает попытки соединиться с сервером, который настроен на анонимный доступ, а сервер не может аутентифицировать пользователя, то в строке состояния этот человек увидит следующее сообщение:
Server X cannot authenticate you because: the server's
В начале курса мы обсуждали службы обеспечения безопасности, которые необходимо предусмотреть. Одной из них является целостность данных (
Когда реплицируются базы данных или по сети направляются сообщения электронной почты, существует определенный риск, что они могут быть модифицированы либо по причине аппаратного сбоя, либо по причине действий неавторизованной третьей стороны [часто упоминаемых как фальсификация (
С целью обнаружения любых подобных изменений используются цифровые подписи. Целостность данных предполагает, что текущее состояние данных идентично исходному "чистому" состоянию. Это гарантирует, что информация не изменена в процессе транзита. Цифровая подпись может подтвердить, что человек, который внес данные, является их автором и что никто не сфальсифицировал данные.
Инициаторы данных могут добавлять свою цифровую подпись к сообщениям электронной почты, а также к полям или разделам документов Notes.
Примечание. Разработчик базы данных настраивает, подписываемы или нет поля и разделы базы данных. Используя эту возможность, отдельные пользователи могут затем осуществить выбор относительно того, подписывать или нет почтовые сообщения.
Для цифровых подписей, применяемых клиентом Notes, применяется та же пара RSA-ключей, что была использована в процессе проверки достоверности и аутентификации. Способ, которым цифровые подписи применяются в Lotus Notes, проиллюстрирован на рис. 6.15.
(рис 6.15) Используемые в Lotus Notes цифровые подписиПронумерованные на схеме шаги описаны далее.
Таким образом, результатом для пользователя является то, что Notes отобразит, кто подписал сообщение, если проверка достоверности подписи прошла успешно. В противном случае Notes отобразит, что не может проверить достоверность подписи.
Процесс цифровой подписи гарантирует две вещи:
В противном случае получатель знает, что данные были сфальсифицированы либо что отправитель не имеет сертификата, которому доверяет читатель.
Другой рассмотренной нами службой обеспечения безопасности, которую необходимо предусмотреть, является конфиденциальность (
При отправке данных по сети, включая почтовые сообщения, любой, кто может перехватить сетевые пакеты [как правило, посредством способов отслеживания (трассировки) или электронного сниффинга] может читать данные без прохождения аутентификации.
Возможно, это не является проблемой для организации, поскольку информация, вероятно, несекретна. Однако данное явление может восприниматься организацией и как проблема, так как это означает, что вся почта, которая отправляется и получается, может быть прочтена другими людьми, которые обычно не имеют на это разрешения.
Недостаток секретности является серьезной проблемой. Несмотря на то что основной объем трафика электронной почты не содержит чувствительных данных, он содержит небольшое, но важное подмножество сообщений. Для этой проблемы существует только два решения: либо убедить пользователей серьезно относиться к безопасности, либо трактовать всю электронную почту как содержащую чувствительную информацию и шифровать все. Опыт показывает, что внесение эффективных изменений в ИT-архитектуру обычно проще, чем изменение сознания людей, поэтому зачастую применяется последний подход. (Однако пользователи должны продолжать серьезно относиться к безопасности, а также должны применяться политики безопасности, чтобы гарантировать, что минимум в обеспечении безопасности соблюдается в организации всеми.)
Выполнение шифрования во всей ИT-инфраструктуре не является тривиальной и простой задачей, за исключением, конечно, случаев использования Notes.
Электронная почта зашифровывается автоматически клиентом Notes и отправляется далее. После того как зашифрованная электронная почта достигнет места назначения, клиент Notes расшифровывает ее, чтобы дать получателю возможность ее прочитать. Этот метод защищает данные от неавторизованного доступа. Для шифрования и расшифровки данных Notes использует механизм группового шифрования, в основе которого лежит секретный ключ. Это также подтверждает, что полученные данные не были прочитаны другими. Принимая во внимание тот факт, что клиенты Notes и серверы Domino обрабатывают огромное множество электронной почты, важно, чтобы используемый алгоритм был эффективным. Для группового шифрования данных Notes использует алгоритмы
Единственный вариант относительно изменения криптостойкости представлен типом имеющейся у пользователя лицензии Notes.
Все Notes ID содержат две пары открытого/секретного ключей. До версии 5.0.4 длины ключей были ограничены в целях шифрования данных, но не в интересах аутентификации и осуществления электронной подписи. Все, что было свыше 512-битового RSA-ключа и 56-битового симметричного ключа, рассматривалось как сильное шифрование, и правительство США запретило это экспортировать. Заказчики были вынуждены соблюдать эти правила и осуществлять выбор среди комплектов программного обеспечения с различными силами криптографии.
По мере смягчения постановлений правительства США относительно экспорта криптографии, программные продукты сервера Domino, Domino Administrator, Domino Designer®, клиента Lotus Notes объединили все предыдущие разновидности криптостойкости – североамериканскую (North American), интернациональную (International) и французскую (France) – в один уровень криптостойкого шифрования в отдельном выпуске "Global (Глобальный)" этих продуктов. Глобальный выпуск принял характеристики шифрования, ранее известные как североамериканские. Криптостойкое шифрование программных продуктов глобальной версии может использоваться по всему миру, за исключением тех стран, в которых это запрещают законы об импорте либо в которые экспорт товаров и услуг запрещен правительством США. Покупателям больше не требуется заказывать программное обеспечение Notes в соответствии с силой криптографии.
Когда организация обновляет программное обеспечение до глобальной версии Domino и Notes, более сильная криптография будет использоваться без требования повторного выпуска существующих ID. Эти изменения безболезненны как для пользователей, так и для администраторов. При взаимодействии двух различных версий программного обеспечения переговоры по шифрованию закончатся переходом к более слабому его уровню. Поэтому все преимущества криптостойкого шифрования будут реализованы только в том случае, когда все программное обеспечение обновлено до глобального уровня (dерсия 5.0.4 и выше). Однако любые смешанные версии программного обеспечения все же будут взаимодействовать друг с другом.
Диалоговое окно Register New User (Регистрация нового пользователя) все еще будет предлагать осуществить выбор между североамериканскими и интернациональными ID. Это было оставлено, потому что администраторы часто используют их различие в административных целях и потому что в некоторых компаниях все еще используются более старые версии программного обеспечения. В дополнение к этому различные страны имеют свои собственные правила импорта. Сохранение этого различия позволит Lotus реагировать на изменения для определенных стран, если это потребуется.
Примечание. Эти предписания касаются только экспорта из США. Для других стран с собственными предписаниями относительно импорта заказчикам необходимо осуществить проверку на предмет соответствия требованиям для определенной страны. Несмотря на то что Lotus предпринимает все шаги для обеспечения согласования правительственных предписаний относительно шифрования по всему миру, компания все же рекомендует, чтобы заказчики ознакомились с местными предписаниями относительно шифрования, чтобы обеспечить соответствие им.
Тот факт, что североамериканский и интернациональный типы ID продолжают существовать и поддерживаются в Notes и Domino, порождает множество вопросов и забот. Последующий разговор коснется некоторых из них.
Наилучшей стратегией при выборе между североамериканскими и интернациональными ID является продолжение использования того способа решения, который применялся для более ранних версий Notes и Domino. В конечном счете по мере обновления клиентов Notes и серверов Domino ваше решение перестанет иметь значение.
Очень важно беречь Notes ID. Соответственно приведем два особых момента, которые достойны запоминания.
ID, как это обсуждалось ранее).Одним из способов, который Lotus Notes предлагает для обеспечения конфиденциальности, является предоставление служб, с помощью которых электронная почта может быть легко и эффективно зашифрована. Метод, с использованием которого это выполняет клиент Lotus Notes, проиллюстрирован на рис. 6.16.
(рис 6.16) Шифрование сообщений электронной почты в Lotus NotesЭто практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на схеме шаги описаны далее.
Важно указать на пару следующих моментов:
Предыдущие примеры применимы к почте Notes, но Lotus Notes предусматривает также другие методы шифрования информации. С использованием различных методов шифрования могут быть защищены базы данных, документы, поля и передача данных по сети.
ID сервера или пользователя путем применения опции безопасности, касающейся шифрования локальной базы данных. Это защитит базы данных, которые используют это свойство безопасности, от доступа со стороны неавторизованного пользователя, получившего доступ к файловой системе рабочей станции, на которой хранится база данных, и сделавшего копию базы данных в файловой системе посредством операционной системы.Мы рассмотрели все важнейшие аспекты инфраструктуры открытых ключей Notes (Notes PKI) и показали, каким образом безопасность Notes и Domino строится на надежной инфраструктуре открытых ключей, которая делает возможным обеспечение аутентификации, целостности данных и конфиденциальности для всех пользователей Notes, воспользовавшихся этими встроенными функциями. Принимая во внимание прозрачность PKI в Lotus Notes, инфраструктуру открытых ключей Notes удобно применять, обеспечивая безопасность без наличия всяких трудностей, свойственны стандартным реализациям инфраструктур открытых ключей, что сделало ее наиболее распространенной PKI в корпоративном мире.
Так как Notes и Domino взаимодействуют также и с людьми, их не использующими, то в оставшихся разделах этой лекции мы обсудим, как Notes и Domino расширили свои возможности в целях представления поддержки интернет-стандартов в вопросах инфраструктуры открытых ключей и служб, которые становятся доступными при ее употреблении.
Исходя из открытости Интернета и того факта, что любой желающий может делать в нем почти все, что угодно, и когда угодно, компаниям необходимо защищать себя в Интернете. В этих целях существует определенное количество стандартов, технологий и инструментов обеспечения безопасности, которые мы рассмотрим в данном разделе.
Как и в случае с безопасностью в Notes, эти стандарты, технологии и инструменты по большей части основаны на технологии сертификатов открытых ключей. Двумя наиболее распространенными форматами сертификатов являются PGP и X.509. Принимая во внимание широкую поддержку со стороны Domino сертификатов X.509, мы сфокусируем ваше внимание на этом формате.
Поддержка подобных встроенных в сервер интернет-стандартов осуществлялась с момента представления в 1996 г. сервера Domino 4.5. Целью этого являлась все большая интеграция данных стандартов в ядро сервера Domino, и результат таких усилий хорошо виден в Domino 6. На протяжении оставшейся части этой лекции мы обсудим необходимые вам основы технологий обеспечения безопасности в Интернете, а более подробное разъяснение новых сервисов и услуг представлено в лекции 11, "Свойства безопасности Domino/Notes 6".
Одно дело использовать Интернет, и совершенно другое выполнять технические работы, основанные на интернет-стандартах. Если построение шаблона достаточно просто, то дальнейшая работа способна обескуражить в плане временных затрат.
При выполнении подобной технической работы упоминаются такие акронимы, как STD и RFC, причем каждый из них идет с определенным номером. Важно знать, откуда происходят эти акронимы, что они означают и каковы различия межу ними.
Интернет-стандарты определяются целевой группой инженерной поддержки Интернета IETF (
Спецификации, которые планируется сделать интернет-стандартами, проходят в своем развитии последовательность уровней зрелости, известных как путь стандартов (standards track). Эти уровни зрелости включают предложенный стандарт (
Спецификация предложенного стандарта (
Спецификация, на основе которой были разработаны как минимум две независимые и взаимодействующие реализации на базе различного кода и для которой был получен достаточно удачный опыт использования, может подняться до уровня чернового стандарта (Draft Standard).
Черновой стандарт обычно рассматривается как финальная спецификация, а изменения в нем можно делать только для решения неожиданно возникших специфических проблем. В большинстве случаев разумным для производителей решением будет помещать реализации черновых стандартов в среды, чувствительные к поломкам.
Спецификация, для которой получены достоверная реализация и успешный опыт работы с ней, может подняться до уровня интернет-стандарта (Internet Standard). Интернет-стандарт [который может упоминаться просто как стандарт (Standard)] характеризуется высокой степенью технической зрелости и в целом предполагает, что указанный протокол или служба предоставляют значительную пользу интернет-сообществу.
Как правило, интернет-стандарты определяют способность к взаимодействию систем путем задания протоколов, форматов сообщений, схем и языков. Наиболее фундаментальные стандарты определяют интернет-протокол IP (Internet Protocol).
Все интернет-стандарты задаются в последовательности STD числом. Первый документ в этой последовательности, STD1, описывает оставшиеся в последовательности документы и содержит список предложенных стандартов. Зачастую документы в последовательности STD являются копиями RFC либо несколькими собранными вместе RFC. Номера STD не имеют номеров версий, так как все обновления выполняются через RFC, а номера RFC являются уникальными. Для четкого указания того, какая версия стандарта упоминается, должны быть точно определены номер стандарта и все RFC, которые он включает.
Запросы на комментарии [requests for comments (RFC)] являются начатой в 1969 г. последовательностью пронумерованных информационных документов и стандартов Интернета, которым в значительной степени следуют разработчики коммерческого и
RFC, выпущенные организацией IFTF и ее предшественниками, являются наиболее известной последовательностью с названием RFC; эта последовательность почти всегда является тем, что означает RFC без последующего уточнения. Однако в прошлом последовательности с названием RFC выпускались также и другими организациями.
RFC необычны тем, что они запускаются в ход техническими экспертами, действующими по своей собственной инициативе, и детально оцениваются в Интернете, причем даже лучше, чем если бы они были официально опубликованы таким институтом, как Национальный институт стандартизации США (ANSI). По этой причине они остаются известными как RFC даже после принятия в качестве стандартов. Эта традиция получения не допускающего возражений, подтвержденного опытом, становящегося таковым после завершения процесса стандарта, написанного отдельными людьми или небольшими рабочими группами, имеет важные преимущества по сравнению с более официальным, проводимым комиссиями процессом. Символичным для этих преимуществ является наличие процветающей традиции выпуска "шуточных" RFC. Обычно такой RFC выпускается как минимум один раз в году, как правило 1 апреля.
Наиболее поразительным является то, насколько хорошо работают RFC; они ухитряются не иметь ни неопределенностей, которыми обычно изобилуют спецификации, ни совершенных комиссиями ошибок, которые часто неотступно преследуют официальные стандарты, и они описывают сеть, которая выросла действительно до общемировых масштабов.
STD и RFC являются свободно доступными, в том числе и в режиме онлайн. Наиболее легким способом получить их является посещение Web-сайта организации IETF, находящегося по следующему URL-адресу:
Полный каталог RFC в текстовом формате доступен на сайте организации по адресу:
http://www.ietf.org/iesg/1rfc_index.txt
Однако по этому каталогу вследствие его длины непрактично осуществлять навигацию. Вместо этого лучшим способом найти и извлечь текст отдельного RFC является ввести его номер, зайдя по следующему адресу:
За более подробным описанием RFC и процесса создания RFC обратитесь к RFC 2026 The Internet Standards Process,
Не все RFC являются документами интернет-стандартов. Многие RFC имеют статус информационных или экспериментальных и не представляют собой никакого стандарта. Вместо этого они содержат информацию, которая может быть полезной или важной для сохранения в качестве части последовательности документов RFC.
Это важно понимать, поскольку недобросовестные специалисты по маркетингу и невнимательная профессиональная пресса иногда ошибочно внушают нам, что каждый RFC представляет собой стандарт или что все стандарты имеют одинаковый вес. Взаимоотношения между техническими спецификациями Интернета зачастую очень сложны. На самом деле существует даже RFC, который разъясняет это, – RFC 1796, называемый Not All RFCs are Standards (Не все RFC являются стандартами), доступ к которому можно получить по адресу:
http://www.faqs.org/rfcs/rfc1796.html
Когда вы будете читать о технологиях, инструментах и службах Интернета, которые поддерживаются и предлагаются сервером Domino для интернет-клиентов, помните об этих отличиях между STD и RFC.
Перед тем как мы подробно коснемся отдельных, предлагаемых PKI служб, в этом разделе мы дадим описание компонентов PKI.
Первоначально "PKI" было общим термином, который просто обозначал набор служб, использующих криптографию на основе открытых ключей. В наши дни "PKI" больше ассоциируется с предоставляемыми инфраструктурой открытых ключей службами либо в виде приложений, либо в виде протоколов. Некоторыми примерами таких служб являются:
Давайте рассмотрим, что необходимо для обеспечения этих служб, а также те компоненты, которые требуются современной инфраструктуре открытых ключей.
Основные компоненты инфраструктуры открытых ключей (PKI), как показано на рис. 6.17, включают:
End Entity (EE) ];Certificate Authority (CA) ];Certificate Repository (CR) ];Registration Authority (RA) ];Digital Certificates (X.509 V3)Далее следуют подробные определения этих компонентов.
(рис 6.17) Компоненты PKIКонечный объект лучше всего определить как
Центр сертификации [ Certificate Authority (CA) ] по существу, является подписчиком сертификатов. Центр сертификации, зачастую совместно с центром регистрации (описанным далее), имеет своей обязанностью обеспечивать надлежащую идентификацию сертификата конечного объекта ( ЕЕ ). Логический домен, в котором СА выпускает сертификаты и управляет ими, называется доменом безопасности (security domain), который может быть реализован для защиты множества различных групп разных размеров, начиная от одного контрольного пользователя вплоть до департамента и далее до уровня всей организации. Основные проводимые СА операции включают: выпуск сертификатов, обновление сертификатов и аннулирование сертификатов.
СА создает цифровой сертификат путем подписывания его цифровой подписью. По существу пара открытого и секретного ключей генерируется запрашивающим клиентом ( ЕЕ ). После этого клиент передает СА на рассмотрение запрос на выпуск сертификата.
Запрос на выпуск сертификата содержит по меньшей мере открытый ключ клиента и некоторую другую информацию, такую, как имя клиента, адрес электронной почты, почтовый адрес или другую относящуюся к делу информацию. Когда установлен центр регистрации ( RA ), СА делегирует ему процесс верификации клиента и другие функции управления. После подтверждения запроса клиента СА создает цифровой сертификат и подписывает его.
В качестве альтернативы СА может генерировать пару ключей клиента, а впоследствии и подписанный сертификат для этого клиента. Однако этот процесс выполняется достаточно редко, так как секретный ключ необходимо пересылать от СА к клиенту, что может стать слабым местом. Как правило, более безопасным представляется случай, когда клиенты генерируют свои собственные пары ключей, при этом секретные ключи никогда не покидают своей зоны полномочий.
В целях обеспечения правильной работы инфраструктуры открытых ключей основным предположением является то, что любая сторона, которая желает проверить сертификат, должна доверять СА, который произвел его цифровую подпись. В инфраструктуре открытых ключей "А доверяет Б" означает, что "А доверяет центру сертификации, который подписал сертификат Б". Соответственно, в общих чертах, "А доверяет центру сертификации" означает, что "А" имеет локальную копию сертификата этого центра сертификации.
К примеру, при установке безопасного HTTP-соединения посредством SSL основные Web-браузеры имеют список сертификатов нескольких, заслуживающих доверия СА (обычно упоминаемых как Trusted Roots или Trusted CA, браузеры будут полностью доверять серверу, за исключением тех случаев, когда пользователь умышленно удаляет сертификат CA-подписчика из списка доверенных СА.
СА способен выпускать определенное количество различных типов сертификатов, таких, как:
СА. Если частью инфраструктуры является центр регистрации RA, то он также должен иметь этот сертификат. Сертификат пользователя может быть ограничен до специфических случаев применения и целей (таких, как безопасная электронная почта, безопасный доступ к серверам и т. д.).СА ). Когда СА выпускает сертификат для самого себя, такой сертификат называется СА. Если СА выпускает сертификат для подчиненного СА, то этот сертификат также называется сертификатом СА.Каждый сертификат имеет период достоверности и связанной с ним датой истечения срока действия. Когда срок действия сертификата истекает, то может быть инициирован процесс его обновления, после одобрения которого для конечного объекта будет выпущен новый сертификат.
Максимальный срок службы сертификата ограничен датой истечения его срока действия. Однако в некоторых случаях возникает необходимость аннулировать сертификаты до наступления этой даты. Когда это случается, CA включает сертификат в CA включает в этот список серийный номер сертификата вместе с некоторой другой информацией. Клиенты, которым необходимо знать о достоверности сертификата, могут осуществлять в
Репозиторий сертификатов [Certificate CR )] является хранилищем выпущенных сертификатов и CR необязательный компонент инфраструктуры открытых ключей, он значительно способствует доступности и управляемости PKI.
Так как формат сертификатов X.509 нормально приспособлен к каталогу X.500, то соответственно наилучшим образом будет реализовать CR как каталог (Directory), который затем может быть доступен посредством наиболее общего протокола доступа – облегченного протокола доступа к каталогам LDAP (
LDAP является наиболее эффективным и наиболее распространенным методом, с помощью которого конечные объекты или СА извлекают или модифицируют хранящиеся в CR сертификаты и информацию bind, search или modify и CR, определены классы объектов и атрибутов [называемые схемами (Schemas)].
Для получения сертификатов или информации CR, существуют альтернативные методы. Однако их применять не рекомендуется, и после рассмотрения требований, которым должен соответствовать CR, все сводится к тому, что каталог на самом деле является лучшим местом для хранения информации CR. Эти требования включают: простую доступность, доступ на основе стандартов, сохранение новейшей информации, встроенную безопасность (если требуется), вопросы управления данными и возможность объединения подобных данных. В случае инфраструктуры открытых ключей в Интернете на основе Domino репозиторием сертификатов является каталог Domino (Domino Directory).
Центр регистрации [Registration Authority ( RA )] является необязательным компонентом инфраструктуры открытых ключей. В некоторых случаях роль RA выполняет CA. Там, где используется отдельный RA, он является доверенным конечным объектом, который сертифицирован CA и действует как CA. CA может делегировать некоторые из своих функций управления RA. К примеру, RA может выполнять персональные задачи аутентификации, сообщать об RA не производит выпуск сертификатов или
Ключевой частью инфраструктуры открытых ключей (и достойной собственного раздела для описания) является сертификат X.509.
Несмотря на то что для сертификатов открытых ключей было предложено несколько форматов, большинство доступных сегодня коммерческих сертификатов основаны на интернациональном стандарте, рекомендации ITU-T X.509 (ранее X.509 организации
Сертификаты X.509 обычно используются в защищенных интернет-протоколах, таких, как те, которые мы рассматриваем в настоящей лекции, а именно:
Первоначально основной целью стандарта X.509 было определить средства для проведения аутентификации на основе сертификатов по отношению к каталогу X.500. Аутентификация каталогов в X.509 может проводиться с использованием либо техники секретных ключей, либо техники открытых ключей. Последняя основана на сертификатах открытых ключей.
В настоящее время определенный в стандарте X.509 формат сертификата открытого ключа широко используется и поддерживается в мире Интернета определенным количеством протоколов. Стандарт X.509 не устанавливает особого криптографического алгоритма, хотя и производит впечатление, что RSA является единственным наиболее широко используемым алгоритмом.
RFC, касающиеся электронной почты повышенной защиты [Privacy Enhanced Mail (
Эти поля предоставляют большую гибкость по причине того, что они могут сообщать дополнительную информацию вдобавок к наличию только ключа и связанного с ним имени. Стандартизация основного формата v3 была завершена в июне 1996 г.
Сертификат X.509 состоит из следующих полей:
Стандартные расширения включают среди прочих атрибуты субъекта и выпускающего сертификат, информацию о политике сертификации, ограничения в использовании ключей. Структура
(рис 6.18) Структура сертификата X.509Данные сертификата записываются согласно правилу синтаксиса системы обозначений для описания
(рис 6.19) Представление сертификата X.509 согласно системе обозначений для описания абстрактного синтаксиса 1 (ASN. 1)После этого они конвертируются в двоичные данные в соответствии с характерными правилами кодирования ASN.1, который является языком описания данных и определен организацией ITU-T как стандарты X.208 и X.209. Эта операция позволяет сделать данные сертификата независимыми от правил кодирования каждой конкретной платформы.
В некоторых полях сертификата для представления специальной последовательности значений параметров используется идентификатор объекта [AlgorithmIdentifier для signatureAlgorithm, который фактически состоит из идентификатора объекта ( СА ). Приложение, которое проверяет подпись сертификата, должно понимать
Несмотря на тему о сертификатах, давайте потратим немного времени для рассмотрения перекрестных сертификатов в Интернете, так как мы уже рассмотрели тему об перекрестных сертификатах в инфраструктуре открытых ключей Notes.
Перекрестный сертификат Интернета, как и обычный интернет-сертификат, является сертификатом, который подтверждает идентичность пользователя или сервера. Этот тип сертификата гарантирует получателю зашифрованного S/MIME-сообщения, что сертификат отправителя может быть доверенным, и то, что используемый для подписи S/MIME-сообщения сертификат является действительным. Также он подтверждает идентичность сервера в том случае, когда клиент Notes использует для доступа к интернет-серверу протокол SSL.
Перекрестный сертификат Интернета сохраняется в документе Certificate персональной адресной книги пользователя и может быть применен только тем пользователем, для которого он был выпущен. Перекрестный сертификат Интернета может быть выпущен для "листового" сертификата (СА.
Создание перекрестного сертификата для листового сертификата отображает доверие только к СА отображает доверие для всех владельцев, которые имеют выпущенный этим СА сертификат.
Если СА перекрестно сертифицировал СА, то этим оказывается доверие СА на выпуск сертификатов для пользователей и серверов, находящихся ниже в иерархическом дереве имен. К примеру, после перекрестной сертификации Sales/Acme доверие оказывается Sales/ABC на выпуск сертификата для Fred/Sales/Acme. В качестве альтернативы после создания перекрестного сертификата для Fred/Sales/Acme доверие оказывается только Fred/Sales/Acme.
За подробной информацией о том, как создать перекрестный сертификат Интернета для СА, обратитесь к разделу "Создание перекрестного сертификата Интернета для СА " базы данных помощи Lotus Domino Administrator 6.
Мы покажем сертификаты X.509 в действии достаточно кратко. Перед тем как мы сможем сделать это, необходимо повторно просмотреть материал об аутентификации, так как она важна в Интернете настолько же, насколько она важна в среде Notes. Для напоминания о том, почему так важна аутентификация, обратитесь к разделу "Аутентификация".
В этом разделе мы опишем различные методы, которые доступны для проведения аутентификации пользователей Интернета и интранета.
Протоколом связи прикладного уровня, используемым в WWW, является протокол HTTP (Hypertext Transfer Protocol). В HTTP включена схема с использованием простого имени пользователя и аутентификации на основе пароля, известная как основная (или базовая) аутентификация. Реализация основной аутентификации является специфической для каждого сервера, но обычно все они используют ее в двух целях:
После того как установлен доступ на основе имени и пароля и для интернет- или интранет-пользователей созданы документы Person, Domino будет осуществлять аутентификацию пользователей в тех случаях, когда:
К примеру, когда пользователь пытается открыть базу данных, которая имеет список управления доступом (ACL) с параметром No Access (Нет доступа) по умолчанию, Domino запрашивает пользователя о действительном имени пользователя и пароле. Аутентификация пройдет удачно только в том случае, если пользователь предоставит имя и пароль, которые соответствуют имени и паролю, хранящимся в документе Person пользователя, и если ACL базы данных предоставит этому пользователю доступ. Аутентификация анонимных пользователей не производится.
Существует возможность использовать доступ по имени и паролю и анонимный доступ вместе с протоколом TCP/IP и протоколом SSL (который мы подробно рассмотрим в следующем разделе). Анонимный доступ и доступ на основе имени и пароля вместе с протоколом TCP/IP описаны здесь.
Этот раздел применим также к Web-клиентам, осуществляющим доступ к Web-серверу Domino, для которого была разрешена аутентификация сеанса.
Аутентификация по имени и паролю, известная также как основная
Когда это настроено, Domino запрашивает имя и пароль только в тех случаях, когда интернет- или интранет-пользователь пытается получить доступ к защищенному ресурсу сервера. Интернет- или интранет-доступ отличается от доступа клиента Notes и сервера Domino тем, что сервер Domino запрашивает клиента Notes или сервер Domino на предмет имени и пароля, когда клиент или сервер осуществляют первоначальные попытки получить доступ к серверу.
Если администратор желает назначить доступ к базе данных со стороны интернет- или интранет-клиента, основываясь на обеспечиваемой ACL безопасности Domino, то данный человек должен создать для этого клиента документ Person в каталоге Domino либо, на свой выбор, во вторичном каталоге Domino или внешнем каталоге LDAP. Клиенты, которые не имеют документов Person, рассматриваются как анонимные и могут получить доступ только к тем серверам и базам данных, к которым разрешен анонимный доступ.
Аутентификация по имени и паролю позволяет Domino определить местоположение документа Person (если он существует) для обеспечения доступа клиента к серверу. Доступ к ресурсам сервера может быть разрешен только после идентификации клиента. К примеру, если мы хотим задать Алисе доступ к базе данных с правами Editor (Редактор), а все остальные осуществляют доступ к базе данных с правами Author (Автор), для Алисы необходимо создать документ Person. Существует возможность настроить список управления доступом (ACL) к базе данных для включения туда Алисы с правами Editor, а анонимных пользователей (Anonymous) с правами Author.
Аутентификацию по имени и паролю можно использовать либо с TCP/IP, либо с SSL на любых серверах, на которых используется интернет-протокол (LDAP, POP3, HTTP, SMTP,
Пример аутентификации по имени и паролю с использованием протокола HTTP показан на рис. 6.20. Сам процесс описан ниже.
(рис 6.20) Аутентификация по имени и паролю с использованием протокола HTTPPrivate (Конфиденциально) из области состояния 401 HTTP). После получения от сервера этого ответа Web-браузер выводит диалоговое окно простой аутентификации и предлагает пользователю ввести его имя и пароль.ID пользователя и пароль (зашифрованные в формате Base64).В общем, на рисунке показано, что, когда клиент запрашивает определенный URL-адрес, сервер проверяет, требуется ли для данного URL-адреса применять аутентификацию. Если да, то сервер отклоняет запрос с кодом состояния 401. На экране пользователя появляется диалоговое окно, запрашивающее ID пользователя и пароль. Когда пользователь представляет их, браузер повторно отправляет первоначальный запрос, но с добавлением в него следующего MIME-элемента с HTTP-заголовком:
Authorization : Basic <user ID and password block>
ID пользователя ( user ID ) и блок пароля ( password block ) сконструированы путем создания строки формы UserID:Password с последующим кодированием ее с помощью алгоритма Base64.
Запрос пароля у пользователей не производится каждый раз повторно при доступе к странице с ограниченным доступом, потому что браузер кеширует в памяти ID пользователя, пароль, имя сервера и название области. Таким образом, если он получает другой код состояния 401 для той же комбинации "сервер/область", браузер может повторно выдать запрос с применением соответствующих ID пользователя и пароля.
Некоторые браузеры идут дальше и просто отправляют ID пользователя и пароль любому URL-адресу, которому это, вероятно, необходимо. Как Opera и Mozilla, Netscape Navigator и Internet Explorer отправляют информацию с любым URL, который находится в том же логическом каталоге.
Целью этих технических приемов является уменьшение сетевого трафика и увеличение быстроты реакции путем исключения определенного количества неверных запросов и ответов с кодом состояния 401. К сожалению, они имеют и нежелательный побочный эффект, заключающийся в повторной передаче ID пользователя и пароля в тех случаях, когда, возможно, в этом нет необходимости.
Однако существуют способы для ослабления этого явления. Для каждого разрешенного на сервере интернет-протокола существует возможность указать метод обеспечения безопасности. К примеру, администратор может разрешить для соединений HTTP аутентификацию клиента с применением сертификата, но для соединений LDAP, которые используют протокол TCP/IP, потребовать обеспечения безопасности с применением имени и пароля. Либо администратор может использовать обеспечение безопасности с применением имени и пароля при анонимном доступе и при аутентификации клиента SSL, например для разрешения пользователям с сертификатами клиентов SSL проводить аутентификацию с использованием аутентификации клиента SSL и для разрешения прочим пользователям вводить имя и пароль, если они не имеют сертификата клиента SSL.
Примечание. Аутентификация с использованием имени и пароля не поддерживается, когда сервер Domino работает как SMTP-клиент, например когда сервер Domino соединяется с SMTP-сервером для передачи почты. Аутентификация с использованием имени и пароля поддерживается только в тех случаях, когда сервер Domino работает как SMTP-сервер, а именно когда SMTP-клиенты получают доступ к серверу Domino.
Существует возможность выбрать уровень ограничения, который Domino применяет при аутентификации пользователей в каталогах Domino и каталогах LDAP. Это применимо ко всем интернет-протоколам (HTTP, LDAP, IMAP, POP3). Использование этой установки делает серверы менее уязвимыми для атак по безопасности путем уточнения того, как Domino осуществляет поиск имен и проводит аутентификацию интернет-клиентов. Domino также применяет эту установку, когда расположенный на сервере Domino Java-апплет производит аутентификацию пользователей по протоколу
Опция Fewer name variations with higher security является установкой по умолчанию и рекомендуется для обеспечения наилучшей безопасности. Этот метод аутентификации менее уязвим для атак, потому что попытка простой аутентификации не порождает так много совпадений, уменьшая вероятность соответствия предполагаемого пароля. Пользователям требуется ввести только те элементы, которые перечислены в табл. 6.2 в диалоговом окне введения имени и пароля Web-браузера или другого интернет-клиента.
| Аутентификация каталога Domino | Аутентификация каталога LDAP |
|---|---|
| Полное иерархическое имя | DN |
Общее имя или общее имя с CN=prefix |
CN или CN с CN=prefix |
| Не применяется | UID или UID с UID=prefix |
Имя псевдонима (имя, приведенное в поле имени пользователя документа Person, за исключением приведенного в поле имени alice .first name ) |
Не применяется |
| Интернет-адрес (адрес электронной почты пользователя, указанный в поле интернет-адреса документа Person пользователя) | Почта |
Domino пытается производить аутентификацию пользователей на основе введенных имен и паролей. Этот метод аутентификации может быть уязвим для хакеров, которые подбирают имена и пароли в попытке применить для доступа к серверу легальную учетную запись пользователя. Эта опция дает возможность пользователям вводить любые из перечисленных в табл. 6.3 элементов в диалоговом окне введения имени и пароля Web-браузера.
| Аутентификация каталога Domino | Аутентификация каталога LDAP |
|---|---|
| Фамилия (Last name) | Фамилия (Surname) |
| Имя человека (First name) | Имя человека (Given name) |
Общее имя или общее имя с cn=prefix |
Общее имя ( CN ) или CN с CN=prefix |
| Полное иерархическое имя (каноническое) | DN |
| Полное иерархическое имя (сокращенное) | DN |
| Короткое имя | UID или UID с UID=prefix |
| Имя псевдонима (имя, приведенное в поле имени пользователя документа Person, за исключением приведенного в поле имени человека – first name) | Не применяется |
| Не применяется | |
| Интернет-адрес (адрес электронной почты пользователя, указанный в поле интернет-адреса документа Person пользователя) | Почта |
Если аутентификация по имени и паролю рассматривается для сервера HTTP, то существует дополнительный метод, который может использоваться совместно с ней: аутентификация на основе сеанса.
Аутентификация по имени и паролю отправляет имя и пароль в незашифрованном формате, причем отправка происходит при каждом запросе. Аутентификация на основе сеанса отличается тем, что имя пользователя и пароль заменяются на cookie.
Имя пользователя и пароль отправляются по сети только один раз, когда пользователь подключается к серверу. Впоследствии для аутентификации применяется cookie.
Аутентификация по имени и паролю на основе сеанса предлагает более лучшее управление взаимодействием с пользователем, чем простая аутентификация по имени и паролю, и позволяет администратору настраивать форму ввода пользователями своих имен и паролей. Она также дает возможность пользователям заканчивать сеанс без закрытия браузера.
Аутентификация по имени и паролю при незащищенных соединениях (не являющихся SSL-соединениями) применяется для идентификации пользователей без обеспечения наилучшей безопасности при доступе к данным на сервере, например когда администратор желает отобразить другую информацию для других пользователей при предоставлении имени пользователя и когда информация в базе данных не является конфиденциальной. Между пользователем и сервером в зашифрованном виде не передается никакая информация, включая имя и пароль. В этом случае аутентификации по имени и паролю некоторые хакеры удерживаются от проведения атак, что, впрочем, не предотвращает действия других по прослушиванию сетевых пересылок и подбору паролей.
При использовании протокола SSL вся информация, включая имя и пароль, зашифрована. SSL обеспечивает пользователям конфиденциальность и целостность данных при проведении аутентификации по имени и паролю. Требование введения имени и пароля в дополнение к предоставляемой протоколом SSL безопасности обеспечивает безопасность для тех пользователей, которые не применяют аутентификацию по сертификату клиента, и позволяет вам идентифицировать отдельных пользователей, которые осуществляют доступ к базе данных.
Программный интерфейс приложений Web-сервера Domino [Domino Web
За дополнительной информацией о DSAPI обратитесь к инструментарию программного интерфейса приложений для криптографии Lotus для Domino и Notes. Этот инструментарий доступен по следующему адресу:
Сеансовая аутентификация по имени и паролю является альтернативой аутентификации по имени и паролю для Web-клиентов, и обеспечивает дополнительные функциональные возможности, которые не доступны при простой аутентификации по имени и паролю.
Сеансом считается время, в течение которого Web-клиент проводит работу на сервере с наличием cookie. Для указания параметров, которые разрешат сеансовую аутентификацию и дадут возможность управлять ею, в зависимости от желаемой конфигурации должен быть отредактирован документ Web Site или документ Server.
Кроме того, при разрешении сеансовой аутентификации существует два варианта выбора: опция использования для отдельного сервера и опция для мультисерверного использования. Выбор опции применения для отдельного сервера вызывает генерирование cookie, который принимается на обработку только тем сервером, который его сгенерировал, тогда как опция для мультисерверного использования генерирует cookie, который позволяет применить принцип единственной подписи при работе с любым сервером, который участвует в совместном употреблении документа конфигурации принципа единственной подписи для Web.
Для применения аутентификации на основе сеанса Web-клиенты должны использовать браузер, который поддерживает cookies.
Использование сеансовой аутентификации по имени и паролю предлагает более хорошее управление взаимодействием с пользователем, чем простая аутентификация по имени и паролю. К примеру, существует возможность осуществлять пользовательскую настройку формы ввода пользователями своих имен и паролей. Она также позволяет пользователям заканчивать сеанс без закрытия браузера.
HTML-форма начала сеанса дает возможность пользователю вводить имя и пароль, после чего применять эти имя и пароль на протяжении всего пользовательского сеанса. Браузер отправляет имя и пароль серверу с использованием набора символов сервера. При сеансовой аутентификации по протоколу HTTP пользователь может ввести имя с применением любых печатаемых символов из кодовой таблицы Unicode. Однако пароль пользователя должен быть введен любыми печатаемыми символами из кода US-ASCII.
Примечание. Диапазон печатаемых символов не допускает наличия управляющих символов.
Domino предусматривает HTML-форму по умолчанию ($$LoginUserForm), которая предоставляется и конфигурируется в базе данных конфигурации Domino (DOMCFG.
Вы можете задать временной период окончания сеанса по умолчанию для отключения Web-клиента от сервера после указанного периода отсутствия его активности. Это приведет к тому, что cookie, который Domino применяет для отслеживания сеанса пользователя, окончит функционирование.
Автоматическое окончание сеанса пользователя на сервере помешает другим применять Web-клиент, выдавая себя за пользователя, если последний покинул рабочую станцию, не завершив сеанс.
Если для сервера разрешена аутентификация по имени и паролю на основе сеанса, то пользователи могут также добавлять в конец URL-адреса ? для окончания сеанса, например:
http://acmeserver/sessions.nsf?logout
Также существует возможность по окончании сеанса осуществлять перенаправление к элементу дизайна или к URL-адресу, для примера приведем следующие адреса:
http://acmeserver/sessions.nsf?logoutredirectto=/logoutDB.nsf/logoutApp?Open http://acmeserver/sessions.nsf?logoutredirectto=http://www.sales.com
Существует возможность встроить такое выражение в приложение (к примеру, используя его в кнопке) или вписать его как URL-адрес.
Вы можете задать максимальное количество параллельных пользовательских сеансов, разрешенных на сервере, только для аутентификации на основе сеанса для отдельного сервера. Если производительность сервера мала, это количество может быть уменьшено.
Domino 6 предусматривает возможности управления интернет-паролями для аутентификации на основе сеанса. Подробно это рассмотрено в документации по администрированию программного продукта Lotus Domino 6 и в файле помощи администратора Lotus Domino 6.
Примечание. Если серверы организации настроены на циклическую (
Мультисерверная сеансовая аутентификация, известная также как
В Web-браузерах пользователей должно быть разрешено использование cookies, так как генерируемый сервером маркер (token) аутентификации передается браузеру в cookie.
Аутентификация на основе сеанса при мультисервером использовании, или принцип единственной подписи, настраивается следующим образом:
Принимая во внимание различные сценарии обеспечения принципа единственной подписи для семейства программных продуктов Lotus, этой теме посвящена целая лекция. За дополнительной информацией по этому вопросу обратитесь к лекции 7, "Принцип единого входа".
Анонимный доступ позволяет интернет- и интранет-клиентам осуществлять доступ к серверам без идентификации себя. Domino не производит запись активности обращения таких клиентов к базам данных. К примеру, в этом случае вхождения не записываются в файле журнала (log file) и в диалоговом окне активности пользователей (User Activity).
Как и в случае анонимного доступа в Notes, при использовании анонимного интернет- или интранет-доступа невозможно узнать, кто осуществляет доступ к базам данных на сервере. Поэтому невозможно установить идентичность клиента, а соответственно имя и пароль клиента, для обеспечения управления их доступом к базам данных и элементам дизайна. Как и в случае анонимного доступа в Notes, анонимный интернет- и интранет-доступ должны использоваться в тех случаях, когда нет необходимости управлять доступом на основе идентичности клиента.
Возможность применять анонимный доступ с протоколами TCP/IP или SSL существует для любого сервера, на котором запущены LDAP, HTTP, SMTP или
Как уже упоминалось, существуют ограничения в плане безопасности при использовании данных механизмов аутентификации без привлечения дополнительных средств. Для того чтобы обойти эти ограничения, следует выполнять процесс аутентификации по защищенным шифруемым соединениям. Хорошим решением может быть использование протокола SSL, который будет описан в следующем разделе.
Как нами уже неоднократно упоминалось, аутентификация – это попытка реализовать два наших основных требования по обеспечению безопасности, а именно: обеспечение управления доступом и проверки подлинности. Как ни прискорбно, аутентификация не обеспечивает других первичных требований безопасности: обеспечения конфиденциальности и целостности данных.
Что еще хуже, аутентификация не является по-настоящему безопасной, потому что пароли отправляются по сети в форме, близкой к открытому тексту, – они закодированы с использованием кода Base64. Здесь надо сделать акцент на том, что пароли закодированы, а не зашифрованы. Base64 является алгоритмом кодирования, а не шифрования, и как таковой подразумевает возможность легкого обратного преобразования. Таким образом, принимая во внимание то, что пароли, как правило, передаются в HTTP-заголовках, в случае их перехвата (к примеру, с использованием пакетного сниффера) они легко могут быть декодированы и применены теми, кто выдает себя за реального пользователя.
Таким образом, необходим протокол, который использует технику криптографии. Существует несколько протоколов, которые могли бы удовлетворить данную потребность, но только один из них реализован универсально: протокол защищенных соединений SSL (Secure Sockets Layer).
Протокол SSL является широко используемым в Интернете, причем не только в связке с HTTP, но и совместно с другими популярными прикладными протоколами, а именно LDAP, POP3, HTTP, SMTP,
Протокол защищенных соединений первоначально был разработан компанией Netscape Inc., но на данный момент он реализован в большинстве клиент-серверного программного обеспечения, используемого в Интернете. В SSL применяется некоторое количество технических приемов криптографии, таких, как шифрование на основе открытого и симметричного ключей, цифровые подписи и сертификаты открытых ключей.
Примечание. Текущей версией протокола SSL является 3.0, однако она была вытеснена новым протоколом защиты транспортного уровня TLS (Transport Layer Security), протоколом стандарта IETF. Впервые TLS был определен в RFC 2246: "The TLS Protocol Version 1.0" ("Протокол TLS версии 1.0"). Так как в Notes и Domino нет поддержки протокола TLS - и нет планов по его поддержке в ближайшем будущем, в этой лекции речь пойдет только о протоколе SSL v3.
Протокол SSL версии 3, который был представлен в 1996 г., является протоколом обеспечения безопасности, который:
Существует две важные части протокола SSL:
Рис. 6.21 отображает упрощенную версию процесса рукопожатия SSL. Вот что происходит на этом этапе:
ClientHello с целью увидеть, сконфигурирован ли на сервере протокол SSL. Вместе с сообщением ClientHello клиент также передает список поддерживаемых клиентом опций шифрования и случайное число, которое будет использовано позднее.ServerHello и отправляет список поддерживаемых сервером опций шифрования. На этой стадии клиент и сервер узнают, какой из видов шифрования является для них общим (выбирается самое криптостойкое шифрование из всех возможных).Если требуется произвести аутентификацию клиента, которая предполагает использование сертификатов клиента, после завершения первых трех шагов происходит следующее:
(рис 6.21) Ведение переговоров об установлении сеанса протокола SSLПо существу, два "hello" сообщения используются, во-первых, для того, чтобы удостовериться в возможности проведения SSL сеанса, а если это возможно, то сервер предоставляет сертификат открытого ключа ( public key certificate ). Если требуется, клиент также предоставит сертификат открытого ключа ( public key certificate ). Это метод, с помощью которого SSL проверяет идентичность ( identity ) и подлинность ( authenticity ) сторон. На рис. 6.21 показаны как шаги по аутентификации сервера, так и шаги по аутентификации клиента.
(рис 6.22) Передача ключа сеанса SSLТак как имеет место аутентификация, то может быть и процесс передачи
На этой стадии "рукопожатия" (
ClientHello с перечнем возможных шифров (или алгоритмов шифрования) для использования в процессе шифрования.ChangeCipherSpec ) для подтверждения того, что они готовы взаимодействовать безопасным образом.Из этого примера вы можете видеть, что по сравнению с обычным HTTP-соединением в начале SSL-сеанса передается значительное количество дополнительных служебных данных. Протокол позволяет избежать некоторых из этих непроизводительных издержек путем разрешения клиенту и серверу сохранять информацию о ключе сеанса и возобновления этого сеанса второй раз без проведения переговоров об установлении сеанса и аутентификации.
Примечание. Важно быть внимательным по отношению к количеству SSL-соединений, которые будут разрешены на сервере, поскольку на стадии "рукопожатия" SSL может отрицательно влиять на производительность, что, соответственно, может неблагоприятно повлиять на производительность Web-сервера, предлагающего этот сервис.
После того как будет определен основной ключ ( master key ), клиент и сервер могут использовать его для шифрования данных приложения. Если требуется проведение аутентификации клиента, каждый обмен включает в себя также хеш содержимого сообщений. Хеш может использоваться для доказательства того, что сообщение является оригинальным, путем проверки его содержимого на предмет идентичности тому, что было отправлено. Алгоритм хеширования является частью выбираемых шифров. Хеш шифруется в обоих направлениях с помощью открытых ключей получателей. Каждый из участников (клиент и сервер) имеет соответствующий секретный ключ, который он использует для расшифровки пересылок по мере их получения.
Обычно в этом случае применяются алгоритмы
Заслуживает внимания тот факт, что, когда создается сертификат X.509, генерируются открытый и секретный ключи, которые никогда не уничтожаются. В отличие от этого
Это является важным преимуществом в обеспечении безопасности. Взлом (или математический вывод)
На практике, перед тем как применять подобную службу обеспечения безопасности на Web-сайте организации, необходимо найти ответы на некоторые вопросы. Вот несколько из этих вопросов:
Эти вопросы сводятся к четырем широким областям рассмотрения, с которыми мы будем иметь дело далее, а именно:
Если клиенты браузера, которые подключаются к Web-серверу, имеют общий с сервером доверенный сертификат или корневой сертификат, это обеспечивает доверие клиента браузера к тому факту, что сервер является тем, за что себя выдает.
Однако если существует необходимость настройки того, что пользователь может видеть на безопасном сайте, то возникает необходимость управлять именами пользователей и паролями для каждого пользователя.
С точки зрения клиента браузера, подключающегося к Web-сайту с использованием SSL, весь процесс ведения переговоров об установлении сеанса и аутентификации может быть полностью прозрачным. Для установления SSL-соединения префикс URL-адреса должен быть заменен с http:// на https://.
После того как SSL-соединение будет установлено, браузер предоставляет пользователю визуальную индикацию этого. Как правило, в большинстве браузеров это принимает форму символа закрытого висячего замка в нижней части окна браузера.
При аутентификации клиента аутентификация продвигается на один шаг далее. В этом случае сервер захочет узнать, можно ли доверять клиенту браузера на основе личности пользователя и его
Браузер производит обмен сертификатом клиента, который подписан центром сертификации [Certificate Authority (CA)], являющимся доверенной третьей стороной или даже внутренним доверенным центром. (Это разъясняется в разделе "Внутренний центр сертификации".)
Это обеспечивает необходимое доверие тому факту, что представленный сертификатом пользователь является тем самым человеком, за которого себя выдает. Данное явление предоставляет также дополнительное преимущество, состоящее в отсутствии необходимости управлять паролями для этих пользователей (что снимает одну из административных нагрузок), так как их аутентичность уже подтверждена центром сертификации.
С точки зрения Web-мастера SSL также достаточно прост. Web-мастеру необходимо только сгенерировать для сервера пару ключей, после чего получить для него сертификат.
Обычно это влечет за собой представление документации центру сертификации и уплату ежегодного взноса, хотя существует также возможность генерирования внутренних сертификатов для тестирования и использования в интранет-сети. Также существует возможность установить центр сертификации для организации. Различие между использованием внутреннего CA или CA третьей стороны, по существу, является предметом доверия. В пределах организации можно принять решение о том, что для служащих организации резонно будет доверять любому серверу интранет-сети, который по своему типу является внутренним сервером организации.
Если в организации принято решение разместить Web-сервер в Интернете, то возникает проблема, связанная с тем, как и почему Web-пользователь Интернета должен доверять организации и кем он является. Это особенно важно, если пользователи активно поддерживаются в проведении электронных транзакций с сервером, таких, как отправка данных кредитной карты при оплате товаров и услуг. Использование внешнего центра сертификации (доверенной третьей стороны), которому доверяет ваш браузер, позволит решить данную проблему.
Как показано на рис. 6.21, на котором отражен процесс "рукопожатия" SSL, аутентификация в SSL зависит от того, способен ли клиент доверять сертификату открытого ключа сервера. Мы уже упоминали об этом несколько раз, но, так как это очень важно, повторим снова. Сертификат связывает описание владельца пары ключей с открытой частью ключа. Достоверность сертификата гарантируется тем фактом, что он подписан некоторой доверенной третьей стороной, центром сертификации [certificate authority (CA)].
Но как сертифицирующий центр становится доверенным? В случае наличия браузера, способного работать с SSL, сертификаты доверенных центров сохраняются в базе данных ключей, иногда называемой файлом связки ключей (key ring file).
Перечень центров высшего уровня предварительно занесен в используемый браузер. Рис. 6.23 отображает доверенные корневые сертификаты (или сертификаты центров сертификации) для браузера Opera, который подобен другим широко распространенным браузерам.
(рис 6.23) Доверенные корневые сертификаты для браузера OperaЭтот подход имеет преимущество, заключающееся в очень простой настройке. Браузер может производить аутентификацию любого сервера, который получил сертификат открытого ключа от одного из центров сертификации из перечня без проведения какой-либо конфигурации или связи с требуемым CA.
Но ничто не безупречно, и при использовании этого метода также возникают некоторые проблемы.
Первая из них заключается в том, что новый CA не будет автоматически распознан до момента обновления браузера (где бы он в мире ни находился).
Вторая проблема заключается в том, что не существует способа обработки CA определяет, что владелец открытого ключа является мошенником, уже после выпуска сертификата, то сертификат все равно будет пригоден к употреблению до момента истечения его срока службы, причем без уведомления конечного пользователя о необходимости проявлять беспокойство.
Производители браузеров имеют состоящую из двух частей схему для решения первой проблемы.
Существует специальный формат MIME, application/x-x509-ca-cert, который позволяет браузеру принимать сертификат нового CA, который был подписан одним из известных CA. Этот формат определен в стандарте
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/
Если сеанс SSL установлен с CA. После этого пользователи могут сами выбрать, доверять ли этому серверу (но не CA, который подписал сертификат сервера).
Примечание. Неразумно, особенно для интернет-сайтов, устанавливать сервер, который предусматривает SSL-соединения, но для которого сертификат сервера выпущен неизвестным CA. При условии, что люди желают покупать у людей, которым они доверяют, получение предупреждения о том, что серверу сайта не может быть оказано доверие, не побудит людей доверять ему. Как правило, наилучшей практикой будет приобретение сертификата у одного из известных центров сертификации, предпочтительнее всего у одного из перечисленных во всех широко распространенных браузерах.
Существуют случаи, когда организация может рассмотреть учреждение внутреннего центра сертификации. По существу, это не такая уж и грандиозная задача, ведь обычно такое рассматривается для внутренних пользователей организации. В этой ситуации возможный риск будет небольшим и поэтому наличие CA вполне приемлемо для организации, так как Web-пользователи организации будут доверять любому серверу организации (даже в случае получения не рекомендующего делать это предупреждения). Также это означает, что организации нет необходимости уплачивать ежегодные отчисления внешнему CA.
Как упоминалось ранее, браузер поставляется с предварительно занесенным перечнем центров сертификации высшего уровня, и таким образом вы будете должны сделать выбор: либо иметь сертификат нового CA для организации, установленный на всех используемых в организации браузерах, либо, как это объяснялось ранее, дать пользователям знать о сообщении, которое они получат от браузера при подключении к сайту, подписанному не опознанным браузером центром сертификации.
На рис. 6.24 отображено предупреждающее сообщение, которое выдает браузер Opera при подключении к сайту, не являющемуся доверенным, и попытке установить с ним SSL-соединение.
В этой ситуации пользователь имеет три варианта выбора:
(рис 6.24) Сообщение, предупреждающее о том, что сайт не является довереннымТакже заслуживает внимания тот факт, что принятие доверия не является постоянным явлением и оно не будет применяться ко всем серверам, аналогично сконфигурированным в той же области. Другими словами, это не делает CA доверенным, и таким образом пользователь увидит те же уведомления, если ко второму серверу осуществляется доступ с сертификатом, подписанным тем же CA.
Примечание. Неразумно, особенно для интранет-сайтов, устанавливать сервер, который предусматривает SSL-соединения, но для которого сертификат сервера выпущен draft-ietf-smime- .
Так как сертификат открытого ключа предоставляет подтверждение личности, разумно предположить, что уровень подтверждения, необходимый для клиента, гораздо ниже уровня, необходимого для сервера.
Перед предоставлением сертификата сервера CA потребует документальное подтверждение законности запроса. Для клиента это доказательство зачастую может быть предоставлено online, потому что в этом случае требуется более низкий уровень проверки. Это особенно справедливо для интранет-среды. Сертификационные серверные продукты первоначально предназначались для тех организаций, которые хотели настроить процесс внутренней аутентификации.
Браузер Netscape для инициирования запроса сертификата клиента использует механизм, отличный от механизмов, применяемых в других браузерах (таких, как Mozilla, IE, Lynx и т. д.).
В случае Netscape ключом механизма является тег <, расширение HTML, которое применяется только в форме. Когда браузер видит этот тег, он генерирует пару ключей и возвращает запрос сертификата (в формате CA обрабатывает запрос сертификата и отправляет его обратно как подписанный
В случае других браузеров, к примеру Internet Explorer, единственным отличием в процессе запроса сертификата является то, что IE требует установки управляющего элемента регистрации сертификатов ActiveX (CERTENR3.DLL для IE 3.0 и XENROLL.DLL для IE 4.0). Этот управляющий элемент ActiveX генерирует открытый/секретный ключи и шифрует их в формат CA точно таким же образом, как это делает Netscape.
Помимо разъяснения понятия центра сертификации (Certificate Authority) в разделе о компонентах PKI, в предыдущем разделе мы увидели, что CA является связующим звеном, которое позволяет серверу и клиенту использовать протокол SSL. CA также является связующим звеном при обмене безопасными сообщениями электронной почты (такими, как S/MIME, которые мы кратко описали).
Существует возможность использовать третью сторону, коммерческий орган сертификации одной из упомянутых ранее компаний. В качестве альтернативы можно использовать центр сертификации Domino как внутренний CA для всей организации. За подробностями о настройке центра сертификации Domino 6 и обо всем процессе генерирования связок ключей, а также о сертификатах X.509 сервера и клиента (используемых для SSL-аутентификации и S/MIME) обратитесь к документу IBM (IBM Redpaper) The Domino Certification Authority, REDP (Центр сертификации Domino).
Бурное развитие применения в Интернете электронной почты является результатом упрощенного характера используемых протоколов. Данный факт является палкой о двух концах: простота в управлении гарантирует, что текущие стандарты обмена сообщениями хорошо подходят для миллионов пользователей; однако простота в исполнении имеет своим результатом множество открытых брешей и уязвимостей в обеспечении безопасности.
В этом разделе мы опишем средства, предлагающие обеспечить безопасный обмен сообщениями между клиентами электронной почты в Интернете, а именно опишем, как реализована эта безопасность обмена сообщениями, когда Lotus Notes используется как интернет-клиент обмена сообщениями, а Domino является интернет-сервером обмена сообщениями.
Перед тем как сделать это, давайте все-таки выполним краткий обзор технологий и стандартов, вовлеченных в основной процесс обмена сообщениями в Интернете.
Для отправки и получения почты в Интернете обычно употребляются следующие интернет-протоколы.
SMTP (Simple Mail Transport Protocol) определяет протокол для отправки сообщений электронной почты между хостами, хотя при использовании службы доменных имен DNS (Domain Name Service) и записей Mail eXchange (MX) он может предлагаться для отправки сообщений электронной почты пользователям между доменами.
Большинство систем электронной почты, которые отправляют почту по Интернету, используют для отправки сообщений с одного сервера на другой протокол SMTP. В дополнение к этому протокол SMTP, как правило, применяется для отправки сообщений от почтового клиента к почтовому серверу. Любой хост, который поддерживает SMTP, может также работать как ретранслятор SMTP, и в этом случае он может пересылать сообщения другому SMTP-хосту.
SMTP поддерживает только 7-битовые символы ASCII, что означает отсутствие поддержки выделенных символов, иностранных символьных наборов, обогащенного текста и чего-либо двоичного по своей сущности, например изображений и видео.
MIME (Multipurpose Internet Mail Extensions) являются спецификацией для форматирования сообщений, которые не являются сообщениями ASCII, для обеспечения возможности их отправки по Интернету.
Как упоминалось ранее, одной из проблем исходной спецификации SMTP было предположение о том, что сообщения электронной почты будут состоять в основном из текста, и соответственно в ней поддерживается только открытый текст ASCII.
MIME расширяет эту спецификацию за счет разрешения "переупаковки" двоичных данных в текстовую форму и передачи их по Интернету в почтовых сообщениях, которые совместимы с исходной спецификацией.
Если проводить сравнение, то сообщение электронной почты, которое поддерживает MIME, будет иметь дополнительную информацию в заголовке после поля Subject. Здесь приведен пример подобного сообщения.
From: frederic.dahm@ch.ibm.com To: roger.guntli@ch.ibm.com Subject: Map of Western Canada… MIME-Version: 1.0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: Content-Description: […JPEG data…]
Практически каждый клиент электронной почты поддерживает стандарт MIME, что позволяет им отправлять и получать графические, аудио- и видеофайлы посредством инфраструктуры обмена сообщениями в Интернете. В дополнение к этому, как уже упоминалось, MIME также поддерживает сообщения, представленные наборами символов, отличных от ASCII.
POP и IMAP (который мы опишем следующим) являются протоколами, которые определяют доступ к почте из почтового ящика в Интернете или с почтовой станции.
Почтовый протокол POP (Post Office Protocol) версии 3 (POP3) используется для приема электронной почты в сети. Не все компьютерные системы, которые применяют электронную почту, подключены к Интернету 24 часа в сутки, 7 дней в неделю. Некоторые пользователи звонят поставщику услуг по мере необходимости, в то время как другие могут быть подключены к ЛВС с постоянным соединением с Интернетом, но их рабочие станции могут быть не всегда включены.
В подобных случаях электронная почта, адресованная пользователям этих систем, отправляется центральной почтовой системе электронной почты, где она сохраняется для пользователей до тех пор, пока они не смогут ее принять.
POP3 дает возможность пользователю подключиться к почтовой системе электронной почты по сети. Почтовая система производит аутентификацию пользователя с применением ID и пароля, после чего позволяет скачать почту и, по выбору, удалить почту, находящуюся в центральной почтовой системе.
IMAP4 (
Последняя версия, IMAP4, подобна POP3, но предлагает дополнительные и более сложные возможности. С помощью IMAP, к примеру, можно работать с электронной почтой на сервере, проводить сортировку и управление электронной почтой, находящейся в папках на сервере.
За дополнительной информацией о IMAP обратитесь к Web-странице Стэнфордского университета, находящейся по следующему адресу:
http://www-camis.stanford.edu/projects/imap/ml/imap.html
Как упоминалось ранее, простота этих протоколов означает, что они создают проблемы в обеспечении безопасности для любого, кто отправляет и принимает почту посредством Интернета.
Протокол SMTP не использует какого-либо процесса аутентификации при установке связи с другим SMTP-хостом для передачи и доставки почты.
По существу, отправляющий хост посылает принимающему SMTP-хосту команду, содержащую информацию о том, кто он такой, и о его желании взаимодействовать. Принимающий хост доверяет тому, кто сказал, кто он такой, и ожидает дальнейших команд. После этого отправляющий хост посылает другую команду, содержащую информацию о том, от кого почта, и эту команду снова получает принимающий SMTP-хост. После этого отправляющий хост посылает другую команду, содержащую информацию о том, кто является вероятным получателем этой почты, и эту команду также получает принимающий SMTP-хост. После этого отправляющий хост посылает команду, сообщающую о том, что следует в текстовом сообщении, причем конец строки сообщения уведомляет о завершении сообщения.
Как можно видеть, при таком сценарии любой, имеющий в своем распоряжении сетевой сниффер, может получить сведения о таком трафике в сети, так как весь он отправляется в виде открытого текста. Что еще хуже, любому человеку достаточно просто сфальсифицировать сообщение на любом SMTP-сервере. Очень легко инициировать связь с SMTP-хостом и представить все так, будто почта была отправлена кем-то другим.
Насколько все это просто, демонстрирует следующий пример. При подключении к SMTP-хосту с использованием TELNET по порту 25 и отправке команд, которые ожидает принимающий SMTP-хост, мы можем сфальсифицировать сообщение электронной почты:
Telnet <SMTP host> 25 HELO foobar.com MAIL FROM: <reverse-path> RCPT TO: <forward-path> DATA SEND FROM: whatever.address@you.like
Исходная спецификация POP3 не определяет каких-либо методов аутентификации. Подобно SMTP, информация между клиентом POP3 и сервером POP3 отправляется открытым текстом. Фактически команды USER и PASS применяются для передачи имени пользователя и пароля при использовании для авторизации при подключении к серверу POP3 в целях получения почты. За дополнительной информацией об этом мы рекомендуем вам обратиться к RFC 1725 – Post Office Protocol – Version 3.
Существуют определенные усовершенствования, сделанные в этих протоколах для преодоления некоторых технических ограничений относительно вопросов обеспечения ИT-безопасности, однако все это еще далеко от совершенства, как мы и покажем в процессе последующего обсуждения.
В протокол были внесены изменения в метод аутентификации между клиентом и сервером, включая более новые и более
IMAP4 также предоставляет дополнительные механизмы аутентификации, такие, как Kerberos V4.
При связи с использованием POP3 или IMAP4 для шифрования сеанса существует возможность применять SSL. Это позволяет решить проблему слабых схем аутентификации, используемых в POP3 и IMAP4.
SASL (Simple Authentication and Security Layer (SASL)) определен в RFC 2222. Он описывает метод добавления поддержки аутентификации к протоколам на основе соединения. Каждый протокол, который использует SASL, включает команду для идентификации и авторизации пользователя на сервере и необязательного проведения переговоров об уровне безопасности при последующих взаимодействиях в рамках протокола.
Разработчики протоколов хотят использовать спецификацию SASL для поддержки аутентификации в своих протоколах (к примеру, расширение SMTP для проведения аутентификации является профилем SASL).
Domino применяет SASL только для служб LDAP. Domino использует SASL автоматически, если SSL – вместе с аутентификацией клиента – настроен на сервере и если клиент LDAP поддерживает протокол. В этом случае дополнительная конфигурация не нужна.
ESMTP, или расширенные службы для простого протокола пересылки электронной почты (
Расширения службы SMTP зарегистрированы в комитете по цифровым адресам в Интернете [Internet Assigned Numbers Authority (IANA)]. Примеры расширений SMTP включают: SMTP по TLS/SSL и уведомления о статусе доставки (Delivery Status notifications).
Когда клиент передает сообщение серверу SMTP, который поддерживает расширение аутентификации SMTP (AUTH=LOGIN), это позволит клиенту произвести аутентификацию пользователя по отношению к серверу. Расширение также защищает подлинность аутентификации в том случае, когда сообщение пересылается от одного SMTP-сервера к другому (предполагая, что оба SMTP-сервера поддерживают расширение). Однако, как упоминалось ранее, эта комбинация имени и пароля закодирована только с использованием base64.
SSL и TLS являются популярными механизмами для усиления TCP-соединений за счет обеспечения конфиденциальности и аутентификации. SSL и TLS широко используются вместе с протоколом HTTP, а также они применяются для дополнения безопасностью множества других общеизвестных протоколов, которые работают по TCP.
TLS и SSL очень подобны и используются одними и теми же способами; различие между ними заключается в применяемых ими алгоритмах шифрования. Вместо использования MD5, TLS употребляет функцию безопасного ключевого сборника сообщений HMAC.
При обеспечении безопасности SMTP с использованием SSL или TLS безопасным является только соединение между двумя хостами. Этот механизм не является механизмом "полного цикла", и транспортировка почты от инициирующего ее агента пользователя к получателю не является безопасной. Доставка отдельной части почты может проходить между более чем двумя SMTP-серверами, и, таким образом, добавление конфиденциальности SSL или TLS для одной пары серверов не означает, что вся цепочка SMTP сделана конфиденциальной.
Примечание. Служба SMTP из состава Domino 6 поддерживает несколько расширений SMTP, включая SSL-передачу по TCP/IP.
Разрешите расширения SMTP, используя Lotus Domino Administrator или клиент Lotus Notes и выполнив следующие действия:
SMTP при поддержке расширений SMTP может гарантировать, что была проведена корректная аутентификация исходного соединения "клиент-сервер". Однако это не гарантирует, что во время транзита при использовании SMTP каждый отдельный двухточечный отрезок пути передачи сообщения будет использовать вышеупомянутую аутентификацию.
Кроме того, само сообщение не зашифровано. Это может быть решено путем использования другого расширения SMTP, которое обеспечивает, что соединения SMTP (клиент/сервер или сервер/сервер) шифруются с использованием пары открытого/закрытого ключей. Однако это снова не гарантирует, что сообщение во время транзита будет зашифрованным на каждом отдельном двухточечном отрезке пути передачи сообщения на всем своем пути по направлению к получателю. Даже если было бы возможным гарантировать, что сообщение электронной почты было корректно аутентифицировано доверенными серверами SMTP и полностью зашифровано на двухточечных отрезках пути передачи сообщения на своем пути от отправителя к получателю, все равно это еще не позволит избежать возможности того, что сообщение не было сфальсифицировано (подделано) кем-то другим.
Таким образом, единственным надежным способом обеспечить конфиденциальность, аутентификацию и целостность сообщения электронной почты является обеспечение уверенности в том, что MIME-контент сообщения обработан криптографическим образом (с использованием различных методов шифрования). До настоящего времени для достижения этого существовало два конкурирующих стандарта: PGP и S/MIME. Первым давайте обсудим PGP.
PGP (Pretty Good Privacy), является высоко безопасной системой шифрования на основе открытых ключей, предназначенной для отправки безопасной почты по всему миру. Она была разработана
Доступна также система GnuPG (Gnu Privacy
Информацию относительно общедоступной лицензии GNU можно найти по адресу:
http://www.gnu.org/copyleft/gpl.html
PGP не имеет ключевых возможностей управления. Фактически структура его сертификатов очень неопределенная, в ней вместо наличия центров, выпускающих сертификаты для отдельных людей, работает модель "инфраструктуры доверия", когда сертификаты приобретают полномочия после подписки их известными или доверенными людьми.
Более новый стандарт, называемый OpenPGP, разрешает иерархический подход для согласования работы центров сертификации, сертификатов X.509 и других уже принятых стандартов. За дополнительной информацией об OpenPGP обратитесь к следующему URL-адресу:
Формат сообщений OpenPGP разъяснен в RFC2440, доступном по адресу:
http://www.ietf.org/rfc/rfc2440.txt
Пока PGP рассматривается как некоторая хорошая альтернатива для принятия по всему миру, большинство корпораций увлечены реализацией протокола S/MIME для обеспечения обмена сообщениями как внутри, так и за пределами организации. Мы рассмотрим S/MIME в последующем разделе и подробно опишем, как он работает совместно с клиентом Lotus Notes и сервером Lotus Domino.
S/MIME (Secure Multipurpose Internet Mail Extension) является технологией обеспечения безопасности электронной почты, разработанной компанией RSA для шифрования и цифрового подписания сообщений электронной почты.
Рабочая группа S/MIME завершила работу по пяти предложенным стандартам, которые были обобщены в спецификации S/MIME версии 3. Они приведены далее.
Lotus Notes и Domino 6 полностью поддерживают S/MIMEv3.
Шифрование сообщения происходит для всего контента сообщения или только для определенных частей MIME путем осуществления прогона их через алгоритм шифрования, который использует открытый ключ получателя. S/MIME применяет алгоритм открытых ключей для обмена ключами и для обеспечения цифровых подписей, предлагая для этого два
В этом разделе мы более подробно рассмотрим то, как работает S/MIME. Нашей целью является помочь вам понять, как в Notes и Domino 6 осуществлена реализация и поддержка S/MIME. S/MIME предоставляет пользователям следующие основные возможности:
С помощью этих возможностей достижимы следующие преимущества:
В целях обеспечения секретности сообщений, или конфиденциальности, S/MIME использует асимметричные ключи (открытый и секретный ключи) для шифрования сообщений. По существу, это тот же метод, который используется в Notes и разъяснен в разделе о Notes PKI.
Для отправки зашифрованного S/MIME-сообщения необходимо получить открытый ключ получателя сообщения и зашифровать сообщение с его использованием. Так как единственным человеком, который имеет связанный с этим ключом секретный ключ, является получатель, сообщение может быть безопасно отправлено с уверенностью в том, что только его получатель будет способен расшифровать это сообщение. Данный метод полностью подобен методу, используемому в Notes, и представлен на рис. 6.16 и 6.26.
Это практическое применение гибридного решения, которое мы рассматривали в лекции об основах безопасности. Пронумерованные на рис. 6.26 шаги описаны далее.
(рис 6.26) Шифрование сообщения электронной почты в S/MIMEЕсли клиент обмена сообщениями Боба не способен расшифровать отправленную Алисой электронную почту, причиной этого возможно будет то, что Боб получил новый сертификат X.509 и открытый ключ в каталоге, к которому осуществляет доступ Алиса, является старым ключом.
Рассматривая показанный на рис. 6.26 процесс, мы увидим, что на самом деле этот метод в S/MIME часто упоминают как "цифровой конверт" (
Этот метод является предпочтительным, потому что намного быстрее зашифровать все сообщение с использованием более короткого симметричного ключа, чем шифровать сообщение с применением более длинного асимметричного ключа. Сообщение при этом остается полностью безопасным, так как этот подход совмещает скорость симметричного шифрования с безопасностью
Для обнаружения
S/MIME обеспечивает подпись сообщений путем использования цифровых подписей, что позволяет проводить аутентификацию сообщения (подтверждение того, что отправивший сообщение человек действительно является отправителем), а также обнаружение
(рис 6.27) Используемые в S/MIME цифровые подписиТаким образом, результатом для пользователя является то, что клиент обмена сообщениями отобразит, кто подписал сообщение, если проверка достоверности подписи прошла успешно. В противном случае клиент обмена сообщениями отобразит, что не может проверить достоверность подписи.
Процесс цифровой подписи гарантирует две вещи:
Важно! Здесь не должно быть путаницы с шифрованием сообщения, когда сообщение шифруется с использованием открытого ключа получателя. В случае цифровых подписей сборник шифруется с применением секретного ключа отправителя. Может возникнуть ситуация, когда отправитель желает не только подписать сообщение, но и зашифровать его. В этой ситуации сообщение подвергается процессу шифрования электронной почты с использованием открытого ключа получателя, после чего подвергается шифрованию хеша с применением секретного ключа отправителя. Спецификация S/MIME не определяет порядок, в котором должно происходить шифрование при шифровании и подписании сообщения. Другими словами, соответствующий RFC говорит, что сообщение может быть зашифровано, а затем подписано с применением цифровой подписи либо подписано с применением цифровой подписи, а затем зашифровано.
Давайте более подробно рассмотрим, как отправитель при использовании S/MIME фактически устанавливает подлинность того, что сообщение получено от того, от имени кого оно заявлено.
Как мы говорили, сообщение зашифровано с использованием секретного ключа отправителя. Вместе с подписанным сообщением отправитель также посылает свой сертификат X.509 (собственно сам по себе сертификат не представляет собой ничего другого, как подписанный открытый ключ отправителя). Этот сертификат подписан другой стороной, центром сертификации.
Что произойдет, если центр сертификации ( CA ), который подписал открытый ключ отправителя, не является доверенным? S/MIME решает эту проблему путем применения того, что известно как цепочка доверия (chain of trust). Это означает, что, когда отправитель посылает зашифрованное сообщение вместе с собственным сертификатом отправителя (который содержит его открытый ключ, подписанный CA третьей стороны), он отправляет также сертификат CA третьей стороны. Этот другой сертификат сам может быть подписан другим CA либо на самом деле может являться корневым сертификатом. До тех пор пока можно доверять какому-либо из сертификатов CA в этой иерархии, можно доверять CA, который подписал открытый ключ отправителя.
Итак, как вообще можно доверять CA? В клиенте обмена сообщениями содержится список центров сертификации и их открытых ключей, причем все из них являются доверенными; это встроено в клиент обмена сообщениями для облегчения распространения сертификатов CA (подобно тому, как это встроено в браузер, что мы видели ранее). Соответственно на данный момент мы имеем следующее:
CA, который подписал сертификат отправителя.При наличии этой информации на текущий момент возможна проверка достоверности личности отправителя, так как сертификат отправителя, который был отправлен, может быть расшифрован с помощью открытого ключа CA, который имеется в клиенте обмена сообщениями и является доверенным.
Если такая проверка происходит успешно, то после этого существует возможность подтвердить достоверность сертификата и всего его содержимого, которое составляют имя отправителя, открытый ключ отправителя, название организации, страны и адрес электронной почты. Теперь, когда открытый ключ отправителя является доверенным, можно расшифровать сообщение и посмотреть, было ли оно подписано тем же человеком.
Следует заметить, что в сертификате отправителя существует и еще одна часть информации: адрес электронной почты. Эта информация является решающей в обеспечении уверенности в том, что сообщения электронной почты не были подделаны, даже если сообщение может быть корректно расшифровано с использованием открытого ключа отправителя. Если соответствующий сертификат не имеет сопоставимого адреса электронной почты, это может говорить о том, что сообщение было отправлено другим пользователем. Насколько в таком случае сообщение или отправитель могут заслуживать доверия?
Если такое случается, то в будущем это может вызвать у нас некоторые проблемы, так как люди имеют склонность заводить себе множество адресов электронной почты. Такие люди могут иметь рабочий адрес электронной почты, личный адрес, возможно второй рабочий адрес, если они временно работают по местонахождению клиента.
Означает ли это необходимость содержания трех наборов из пар открытого/секретного ключей и сертификатов? В этом нет необходимости, так как существует возможность экспорта S/MIME из одного клиента обмена сообщениями в другой с использованием стандарта
В случае выполнения попытки отправить подписанное сообщение получателю, который не имеет клиента обмена сообщениями, способного обработать S/MIME, существует два вероятных исхода этой ситуации в зависимости от возможностей отправляющего S/MIME-клиента.
Если сообщение отправлено как непрозрачное (opaque), это означает, что подпись отправлена как тип MIME "application/pkcs7-signature" (приложение/подпись pkcs7). Соответственно несовместимый с S/MIME клиент не будет способен прочесть тип "pkcs7-signature" (подпись pkcs7). Клиент S/MIME сперва разобьет входящее сообщение, после чего проверит достоверность подписи.
Если сообщение отправлено как прозрачное (clear), это означает, что подпись вставлена как часть типа объекта MIME "multipart/signed" (многоэлементный/подписанный). Подпись генерируется из сообщения путем его хеширования, а тип "application/pkcs7-signature" вставляется во вторую часть типа MIME. Это означает, что любой получающий сообщение клиент будет способен получить обе части типа MIME – неподписанное сообщение и в виде прикрепления тип MIME "application/pkcs7-signature".
Стандарт
Соответственно целью стандарта CA как VeriSign, то этот пользователь был бы способен применять его только в связке с Outlook Express. Аналогично если бы пользователь запрашивал сертификат с помощью Netscape Navigator, то этот пользователь был бы способен применять его только в связке с Netscape Messenger.
Чтобы клиент был способен отправлять подписанные и зашифрованные сообщения электронной почты с использованием S/MIME, необходимо иметь сертификат X.509. Нынешнее поколение способных работать с S/MIME клиентов обмена сообщениями обеспечивает возможность генерирования запроса сертификата с помощью находящегося в Сети CA. После того как сертификат клиента был запрошен (и утвержден), он устанавливается в способный работать с S/MIME клиент обмена сообщениями таким образом, что клиент может подписывать и шифровать любые сообщения электронной почты.
Также необходимо сделать сертификат пользователя доступным для любого, кто захочет отправлять зашифрованные сообщения электронной почты этому пользователю. Адресованные пользователю зашифрованные сообщения электронной почты шифруются с применением открытого ключа этого пользователя.
Рис. 6.28 является высокоуровневым представлением процесса запроса и получения сертификатов, а также отправки подписанных и зашифрованных сообщений электронной почты, как это реализовано в нынешнем поколении способных работать с S/MIME клиентов обмена сообщениями.
(рис 6.28) Циркуляция сертификатов и S/MIME-сообщенийШаги, требуемые для запроса сертификата клиента в S/MIME-клиент, как показано на рис. 6.28, приведены далее.
ID для приема в целях использования в том месте, где может быть получен подписанный сертификат клиента.ID для получения и забирает подписанный сертификат клиента.В нынешнем поколении клиентов обмена сообщениями, способными работать с S/MIME, существует несколько методов получения сертификата получателя.
Первый метод заключается в наличии отправленного получателем пользователю подписанного сообщения. Когда пользователь принимает его, клиент обмена сообщениями, способный работать с S/MIME, автоматически добавит сертификат отправителя в список сохраненных сертификатов. Подобным же образом если пользователь отправляет подписанную электронную почту другому пользователю электронной почты, который применяет клиент обмена сообщениями, способный работать с S/MIME, то это лицо получит копию сертификата первого пользователя.
Второй метод заключается в обеспечении доступа к LDAP в целях предоставления пользователям возможностей поиска в онлайновых каталогах (таких, как Four11, Bigfoot, Switchboard и т. д.). Если требуемый сертификат сохранен в одном из этих каталогов, пользователь будет способен добавить его в персональный адресный список клиента обмена сообщениями, способного работать с S/MIME.
Раз в интересах сообщества пользователей Lotus Notes существует инфраструктура на основе CA внутри организации, то для пользователей так же просто отправлять и получать S/MIME-сообщения, как и отправлять и получать почтовые сообщения Notes. В этом разделе мы покажем, как объединены в одно целое клиент Lotus Notes 6, сервер Domino Server 6 и S/MIME.
Для обычных пользователей Notes, которые понимают, что такое сертификаты Notes и файлы Notes ID, понятия шифрования и подписания не представляют собой ничего нового.
В версии 6 файл Notes ID, который содержит собственные сертификаты Notes, также используется в качестве контейнера для хранения сертификатов X.509 v3. Когда сертификат запрашивается Web-центром сертификации (либо центром сертификации Domino, если он реализован внутри организации, либо центром сертификации третьей стороны), он запрашивается через браузер Notes. Когда запрос на сертификат клиента утвержден, он сохраняется в файле ID пользователя Notes.
Notes имеет возможность создания безопасных копий файлов ID пользователей Notes. Безопасная копия представляет собой, по существу, открытый ключ и связанные с ним подписанные сертификаты. В текущей версии Notes не существует возможностей создания безопасных копий сертификатов X.509. Поэтому невозможно осуществлять импорт или экспорт сертификатов S/MIME-клиента в Notes или из него за исключением случаев использования стандарта
Для подписания электронной почты с применением S/MIME пользователь должен установить свой сертификат X.509 в свой файл Notes ID. Для пользователя существует возможность применять либо сертификат, выпущенный Notes, сертификат, выпущенный центром сертификации Domino, либо сертификат, выпущенный любым другим, представляющим третью сторону, коммерческим центром сертификации. Эта процедура в точности соответствует той, которая описана в разделе о центре сертификации Domino.
Перед тем как осуществить шифрование сообщения, как было описано ранее, пользователю необходимо получить сертификат получателя. Клиент Notes зашифрует сообщение с применением открытого ключа получателя. В Lotus Notes 6 сертификаты клиента получателей хранятся в каталоге Domino (Domino Directory).
Когда пользователь Lotus Domino 6 предпринимает попытку отправить зашифрованное сообщение, применяется сертификат X.509 получателя, причем на основе произведенного пользователем выбора относительно того, применять ли формат MIME либо формат Notes для отправки почты напрямую в Интернет или для сообщений, которые адресованы по интернет-адресам. И наоборот, пользователи также могут управлять форматом входящей почты согласно своим пользовательским предпочтениям. Формат сообщения определяет выбор метода шифрования.
Notes использует S/MIME-шифрование для исходящей почты в следующих ситуациях:
Помимо требований, определенных для S/MIME, сертификат X.509 получателя должен быть доступен в персональной адресной книге или в каталоге Domino. Если Notes не может найти сертификат получателя, то пользователь увидит отображенным окно сообщения об ошибке.
Если параметры установлены должным образом, то отправка зашифрованного сообщения сведется только к выполнению пользователем щелчка мыши на кнопке Delivery Options (Опции доставки) и выборе позиции для отметки Encrypt (Шифровать). В противном случае все было бы так, как если бы пользователь отправлял почту Notes.
(рис 6.30) Диалоговое окно безопасности: закладка MailПользователь может также выбрать вариант шифрования всех отправляемых почтовых сообщений. Это выполняется в клиенте Lotus Notes 6 путем выбора пунктов меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), выбора после этого закладки Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее выбора в ней позиции для отметки Encrypt mail that you send (Шифровать почту, которую вы отправляете), как показано на рис. 6.30.
Для пользователей существует возможность подписывать либо отдельные почтовые сообщения, либо все отправляемые ими почтовые сообщения. Перед подписанием сообщений пользователи должны убедиться в том, что ими получены свои собственные сертификаты X.509 в их файлах ID пользователя Notes.
Для осуществления подписи отдельного почтового сообщения при завершении его написания пользователь щелкает мышью на кнопке Delivery Options (Опции доставки) и выбирает позицию для отметки Sign (Подписать).
В качестве альтернативы для подписания всех отправляемых пользователем почтовых сообщений пользователь может выбрать пункты меню File – Security – User Security (Файл – Безопасность – Безопасность пользователя), после чего выбрать закладку Mail (Почта) в новом диалоговом окне безопасности пользователя (User Security) и далее в ней выбрать позицию для отметки Sign mail that you send (Подписывать почту, которую вы отправляете).
После получения подписанной электронной почты Notes попытается проверить достоверность подписи.
Если пользователь доверяет подписанному сертификату, т. е., если пользователь имеет сертификат подписавшего или перекрестный сертификат Интернета для отправителя, то в строке состояния клиента Notes отобразится сообщение, показывающее достоверность подписи, пример чего мы приводим ниже.
" Signed By: Bob, at 10:52 AM, According To: TestCertAuthority".
Если пользователь не доверяет подписанию сертификата, то он получит приглашение создать перекрестный сертификат Интернета по требованию. Пользователь может выбрать имя субъекта сертификата в сообщении, которому он желает доверять.
Примечание. Подписанные S/MIME-сообщения содержат цепочку сертификатов отправителя и подписавших. Результирующий перекрестный сертификат Интернета сохраняется в персональной адресной книге получателя. При создании перекрестного сертификата пользователь объявляет, что он доверяют сертификату, содержащемуся в подписанном S/MIME-сообщении. После этого проверка подписи может быть продолжена.
Наконец, для пользователя существует также возможность вручную сохранять адрес отправителя и сертификаты X.509 в своей персональной адресной книге. При просмотре подписанной S/MIME-почты пользователь должен выбрать пункты меню Actions – Tools – Add Sender to
Несмотря на то что Интернет позволяет отдельным людям и организациям взаимодействовать на таком уровне как никогда ранее, единственной величайшей проблемой, которая была и есть в Интернете, является проблема кому можно доверять.
Данная лекция показала роль, которую могут играть инфраструктуры открытых ключей в установлении подобного доверия и обеспечении уверенности в его сохранности. Это выполняется путем использования сертификатов X.509 совместно с установленными протоколами (к примеру, SSL) и стандартами обмена сообщениями (к примеру, S/MIME). Также в этой лекции показано, как в Notes и Domino реализованподдержка сертификатов X.509 и то как эти сертификаты запрашиваются, утверждаются, генерируются и устанавливаются в инфраструктуре Notes и Domino.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.