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

Управление интернет-паролями

Domino 6 предусматривает возможности управления интернет-паролями для аутентификации на основе сеанса. Подробно это рассмотрено в документации по администрированию программного продукта Lotus Domino 6 и в файле помощи администратора Lotus Domino 6.

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

Мультисерверная сеансовая аутентификация (Multi-server session-based authentication (SSO))

Мультисерверная сеансовая аутентификация, известная также как single sign-on (SSO), позволяет Web-пользователям зарегистрироваться на сервере Domino или WebSphere лишь один раз, после чего осуществлять доступ к любым другим серверам Domino или WebSphere в том же домене DNS, на которых разрешено использование SSO, без повторного входа в систему (регистрирования).

В Web-браузерах пользователей должно быть разрешено использование cookies, так как генерируемый сервером маркер (token) аутентификации передается браузеру в cookie.

Аутентификация на основе сеанса при мультисервером использовании, или принцип единственной подписи, настраивается следующим образом:

• Создайте в каталоге Domino доменный документ конфигурации (domain-wide configuration document) – документ Web SSO Configuration document. Вы можете иметь в каталоге или домене Domino множество таких документов.
• Установите опцию "Multi-server" для разрешения аутентификации на основе сеанса в документе Web Site или Server.Принцип единственной подписи может быть настроен и разрешен и для множества доменов Domino.

Single sign-on может быть настроен и разрешен и для множества доменов Domino.

Принимая во внимание различные сценарии обеспечения принципа единственной подписи для семейства программных продуктов Lotus, этой теме посвящена целая лекция. За дополнительной информацией по этому вопросу обратитесь к "Принцип единого входа (Single sign-on)" .

Анонимный доступ

Анонимный доступ позволяет интернет- и интранет-клиентам осуществлять доступ к серверам без идентификации себя. Domino не производит запись активности обращения таких клиентов к базам данных. К примеру, в этом случае вхождения не записываются в файле журнала (log file) и в диалоговом окне активности пользователей (User Activity).

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

Возможность применять анонимный доступ с протоколами TCP/IP или SSL существует для любого сервера, на котором запущены LDAP, HTTP, SMTP или IIOP. Для каждого из интернет-протоколов, которые разрешены на сервере, существует возможность указать метод обеспечения безопасности. К примеру, вы можете разрешить SSL для HTTP-соединений, но потребовать аутентификацию по имени и паролю для LDAP-соединений, которые используют TCP/IP.

Являются ли данные механизмы аутентификации безопасными?

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

6.2.5 Протокол защищенных соединений SSL (Secure Sockets Layer)

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

Что еще хуже, аутентификация не является по-настоящему безопасной, потому что пароли отправляются по сети в форме, близкой к открытому тексту, – они закодированы с использованием кода Base64. Здесь надо сделать акцент на том, что пароли закодированы, а не зашифрованы. Base64 является алгоритмом кодирования, а не шифрования, и как таковой подразумевает возможность легкого обратного преобразования. Таким образом, принимая во внимание то, что пароли, как правило, передаются в HTTP-заголовках, в случае их перехвата (к примеру, с использованием пакетного сниффера) они легко могут быть декодированы и применены теми, кто выдает себя за реального пользователя.

Таким образом, необходим протокол, который использует технику криптографии. Существует несколько протоколов, которые могли бы удовлетворить данную потребность, но только один из них реализован универсально: протокол защищенных соединений SSL (Secure Sockets Layer).

Протокол SSL является широко используемым в Интернете, причем не только в связке с HTTP, но и совместно с другими популярными прикладными протоколами, а именно LDAP, POP3, HTTP, SMTP, IIOP или IMAP.

Что такое SSL?

Протокол защищенных соединений первоначально был разработан компанией 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 г., является протоколом обеспечения безопасности, который:

• шифрует информацию, пересылаемую по сети от клиента к серверу, обеспечивая конфиденциальность;
• проверяет достоверность того, что отправленное получателю сообщение не было подделано, обеспечивая целостность данных;
• проводит аутентификацию сервера, используя методы открытых ключей RSA;
• проводит аутентификацию личности клиента (новое в версии 3.0).

Как работает SSL

Существует две важные части протокола SSL:

• рукопожатие (handshake), при котором партнеры в сеансе представляются друг другу и согласовывают характеристики сеанса;
• протокол записи (record protocol), при котором происходит обмен данными сеанса в зашифрованном виде.

Рукопожатие SSL

Рис. 6.21 отображает упрощенную версию процесса рукопожатия SSL. Вот что происходит на этом этапе:

1. Клиент запрашивает сервер о начале сеанса. Это выполняется с помощью сообщения ClientHello с целью увидеть, сконфигурирован ли на сервере протокол SSL. Вместе с сообщением ClientHello клиент также передает список поддерживаемых клиентом опций шифрования и случайное число, которое будет использовано позднее.
2. Если протокол SSL сконфигурирован, сервер отвечает сообщением ServerHello и отправляет список поддерживаемых сервером опций шифрования. На этой стадии клиент и сервер узнают, какой из видов шифрования является для них общим (выбирается самое криптостойкое шифрование из всех возможных).
3. После этого сервер отправляет клиенту свой сертификат X.509, который содержит открытый ключ сервера.

   Если требуется произвести аутентификацию клиента, которая предполагает использование сертификатов клиента, после завершения первых трех шагов происходит следующее:
4. Сервер выдает запрос на сертификат клиента.
5. Для завершения процесса аутентификации клиента последний отправляет серверу свой сертификат.

Рис. 6.21. Ведение переговоров об установлении сеанса протокола SSL

По существу, два "hello" сообщения используются, во-первых, для того, чтобы удостовериться в возможности проведения SSL сеанса, а если это возможно, то сервер предоставляет сертификат открытого ключа ( public key certificate ). Если требуется, клиент также предоставит сертификат открытого ключа ( public key certificate ). Это метод, с помощью которого SSL проверяет идентичность ( identity ) и подлинность ( authenticity ) сторон. На рис. 6.21 показаны как шаги по аутентификации сервера, так и шаги по аутентификации клиента.

Рис. 6.22. Передача ключа сеанса SSL

Так как имеет место аутентификация, то может быть и процесс передачи сеансового ключа SSL. Этот процесс проиллюстрирован на рис. 6.22.

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

1. Клиент отправляет серверу сообщение ClientHello с перечнем возможных шифров (или алгоритмов шифрования) для использования в процессе шифрования.
2. Сервер выбирает сильнейший шифр, который они могут совместно использовать, и отвечает сообщением ServerHello, содержащим выбранный шифр.
3. Так как сеанс еще не является безопасным, сервер отправляет клиенту свои сертификаты для обеспечения безопасности сеансового ключа. Если требуется проведение аутентификации клиента, сервер также запрашивает сертификат клиента и клиент отправляет его (это не показано на рис. 6.22).
4. Клиент генерирует секрет [называемый предосновным (pre-master) секретом], созданный с помощью генератора случайных чисел, и отправляет его серверу, шифруя с помощью открытого ключа сервера (который был получен из сертификата сервера). Этот секрет является начальным значением, которое будет использоваться для генерирования сеансового ключа.
5. Как сервер, так и клиент применяют выбранный алгоритм (из шага 2) и сгенерированный случайным образом секрет (из шага 4) для генерирования одинакового одноразового ключа сеанса. Это симметричный ключ шифрования, потому что он будет использоваться как для шифрования, так и для расшифровки всего трафика на протяжении данного сеанса SSL.
6. Сервер и клиент обмениваются сообщениями (называемыми сообщениями ChangeCipherSpec ) для подтверждения того, что они готовы взаимодействовать безопасным образом.
7. Сервер и клиент шифруют весь трафик данного сеанса с помощью полученного ключа сеанса.

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

Примечание. Важно быть внимательным по отношению к количеству SSL-соединений, которые будут разрешены на сервере, поскольку на стадии "рукопожатия" SSL может отрицательно влиять на производительность, что, соответственно, может неблагоприятно повлиять на производительность Web-сервера, предлагающего этот сервис.

Протокол записи SSL

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

Протокол записи SSL устанавливает формат для этих сообщений. В общем, они включают message digest, используя алгоритм MD5, в целях обеспечения гарантии того, что они не были изменены, после чего всё сообщение шифруется с использованием симметричного шифра.

Обычно в этом случае применяются алгоритмы RC2 или RC4, хотя спецификацией также поддерживаются алгоритмы DES, Triple-DES и IDEA.

Заслуживает внимания тот факт, что, когда создается сертификат X.509, генерируются открытый и секретный ключи, которые никогда не уничтожаются. В отличие от этого ключи сеанса генерируются в начале сеанса SSL и уничтожаются по его окончании. Срок службы ключа сеанса лежит в диапазоне от нескольких секунд до нескольких минут. Ключи сеанса никогда не сохраняются на диске и никогда не используются повторно.

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

Анализ применения SSL

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

• Будет ли использоваться аутентификация сервера?
• Будет ли затребована и реализована аутентификация клиента?
• Откуда будут подключаться пользователи?
• Это интернет-сайт или интранет-сайт?
• Будет ли сервер находиться прямо в Интернете или в более безопасной зоне?
• Доверяют ли клиенты браузера представляющим сайт Web-серверам?
• И что наиболее важно, доверяет ли организация людям, которые подключаются к 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. Этот формат определен в стандарте PKCS #7, как разъяснено в техническом документе по следующему URL-адресу:

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-соединения, но для которого сертификат сервера выпущен сертификатом^{5Здесь ошибка: имеется в виду draft-ietf-smime-ess .}, не являющимся известным и доверенным. Конечно, пользователям может быть сказано принимать доступ к хосту, не являющемуся доверенным, но это будет серьезным прецедентом и может подорвать безопасность организации, если при подключении к Интернету из корпоративной сети пользователи будут предпочитать доверять сайтам, которым не должны. Наилучшей практикой будет приобретение сертификата у одного из известных центров сертификации, такого, как VeriSign.