Lotus Domino Web Access – это Web-клиент, который дает возможность пользователям обращаться к различным службам Domino при помощи Web-браузера. Пользователь браузера получает доступ к многочисленным передовым клиентским возможностям и функциям, которые обычно были доступны только тем, кто использует не браузеры, а, например, Lotus Notes. Эти передовые возможности значительно повышают удобство работы в таких областях, как обмен сообщениями, календарное планирование и расписания, управление персональной информацией (personal information management, PIM), управление заданиями и личный журнал. Пользователи также могут работать при отсутствии соединения (offline), управляя почтовыми сообщениями, контактами, календарными планами, списками текущих дел и т.п. с помощью пользовательского интерфейса, предоставленного Domino Web Access.
К настоящему моменту Domino Web Access существует уже несколько лет, и он развивается с каждой новой версией сервера Domino. Версия 7 не является исключением. Функциональное соответствие с Lotus Notes в упомянутых выше областях довольно близкое, в том числе интеграция с Lotus Sametime. Однако клиент Notes по-прежнему предоставляет более богатую и более полную среду для конечного пользователя, особенно в том, что касается дизайна, применения репликации приложений, поддержки PDA-устройств и некоторых других возможностей, доступных только для этого клиента.
Клиент Domino Web Access изначально разрабатывался для того, чтобы снабдить браузер большинством возможностей Notes. Он также создавался для пользователей, которых можно назвать бездисковыми. Такими пользователями обычно являются те, которым лишь иногда требуется доступ к электронной почте и календарным планам. Такие пользователи являются мобильными и не имеют фиксированного местоположения, что делает их идеальными потребителями тех возможностей, которые предлагает браузер и Domino Web Access. То же относится и к внешним пользователям, ведущим тесное сотрудничество с организацией, которым требуется доступ к системе обмена сообщениями организации, но которым организация не хочет предоставлять клиент Notes.
Однако появился новый класс пользователей, которые применяют все возможности Domino Web Access. У этих пользователей есть обычный клиент Notes, но они, как правило, работают удаленно и реализация сервера Domino в месте их работы с реализацией индивидуальных клиентов Notes и соответствующей поддержкой обходится слишком дорого. Поэтому этим пользователям обычно предоставляется клиент Domino Web Access, который обеспечивает большую часть функций при существенной экономии.
Учитывая все эти моменты, мы опишем в этой лекции новые возможности системы безопасности Domino 7, которые повышают безопасность Domino Web Access. В книге серии Redbook, посвященной безопасности, "Lotus Security Handbook", SG24-7017, информация, относящаяся к Domino Web Access, описывается под заголовком iNotes $$\text{\texttrademark}$$ (предыдущее название Domino Web Access), в главе 12, "Security features of other Lotus products".
Мы приведем некоторые базовые сведения, которые позволят правильно установить Domino Web Access и обеспечить его корректную работу, а также дадим некоторые практические советы. Кроме того, поскольку данный курс посвящена безопасности, мы рассмотрим здесь следующие функции и усовершенствования:
Поскольку функциональность Domino Web Access лежит в точке пересечения функций Web-браузера и сервера Domino и это является источником заблуждений относительно неоптимальных конфигураций безопасности, мы обсудим, где используются конкретные возможности системы безопасности, в сервере Domino, в Web-браузере или и там и там.
Наконец, чтобы Domino Web Access работал правильно и позже не возникало никаких проблем, необходимо понимать, какие платформы поддерживаются системой.
Domino Web Access 7.0 поддерживает следующие операционные системы сервера:
Domino Web Access 7.0 поддерживает следующие операционные системы клиента:
Domino Web Access 7.0 поддерживает следующие Web-браузеры:
Кроме того, в версии 7.0.2 будет поддержка клиентов Mac с браузером Firefox.
С технической точки зрения Domino Web Access (ранее называвшийся iNotes Web Access) предоставляет пользователям Lotus Notes доступ через браузер к почте Notes, а также к календарным планам и расписаниям. Пользователи Domino Web Access могут посылать и получать почту, просматривать календарные планы, создавать списки дел, вести записную книжку и работать без соединения (offline).
После настройки на доступ к Domino Web Access пользователь может
применять для обращения к своим почтовым файлам как стандартный клиент
Notes, так и Web-браузер. Поскольку и клиент Notes, и клиент Domino
Web Access работают с одним пользовательским почтовым файлом, отметка
"прочитано" или "не прочитано" будет сохраняться в
соответствующем состоянии, независимо от того, с помощью какого
клиента пользователь читал почту. Пользователь также может
осуществлять синхронизацию контактной информации в личной адресной
книге с информацией в списке контактов (
Кроме того, пользователи имеют возможность работать в режиме offline и использовать сервер Sametime. Для работы в режиме offline можно синхронизировать Domino Web Access с Domino Off-Line Services. Domino Off-Line Services дает возможность пользователям работать при отсутствии сетевого соединения, а также предоставляет возможности для репликации, которые пользователь Notes может ожидать встретить при работе с клиентом Notes. Также существует возможность интегрировать Domino Web Access с Lotus Sametime для получения интегрированных возможностей ведения разговоров в реальном времени. Стоит отметить, что ни Domino Off-Line Services, ни Sametime не являются необходимыми для использования Domino Web Access.
С точки зрения безопасности применительно к Domino Web Access следует упомянуть несколько базовых моментов.
Во-первых, для Domino Web Access требуется безопасность входа пользователя в систему (специальный выход из системы обычно не является обязательным, хотя это хорошая практика). Когда пользователи осуществляют вход в Domino Web Access, они должны ввести свое имя и интернет-пароль, как он указан в документе Person. Имена пользователей, которые сервер считает допустимыми, зависят от значения в поле Internet authentication (Интернет-аутентификация) на закладке Security (Безопасность) документа Server.
Во-вторых, хотя пользователям для входа в Domino Web Access требуется только имя и интернет-пароль, для работы с безопасной почтой необходим Notes ID. Администраторы должны создавать Notes ID для каждого пользователя при регистрации новых пользователей при помощи шаблона Domino Web Access.
В оставшейся части лекции мы более подробно изучим передовые концепции безопасности.
Прежде чем начать обсуждать специфику безопасности Domino Web Access, нужно посвятить какое-то время проверке того, правильно ли настроен и корректно ли работает Domino Web Access на сервере Domino.
Мы не собираемся описывать здесь все аспекты конфигурирования сервера Domino и Domino Web Access. За подробными сведениями по этой теме обращайтесь к следующим книгам серии IBM Redbook (которые относятся к версиям 6.5 и 5.0.9 соответственно):
В данном курсе обратите внимание на следующие 3 элемента:
(рис 7.2) Почтовые шаблоны, поставляемые вместе с Domino 7(рис 7.1) Новый внешний вид Domino Web AccessНовых пользователей следует регистрировать при помощи шаблона dwa7.ntf. Для почтовых файлов существующих пользователей при помощи шаблона dwa7.ntf следует изменить структуру почтовой базы данных. Это единственный шаблон, который содержит поддержку почтовых шаблонов клиента Domino Web Access и клиента Notes. На рис. 7.2 показано, как выглядит новый интерфейс.
Теперь, когда мы настроили должным образом сервер, интернет-службы, которые он предоставляет, и обеспечили соответствие дизайна системы электронной почты нужному шаблону, все готово к рассмотрению темы аутентификации в Domino Web Access.
Domino Web Access сходен с другими базами данных Domino, расположенными на сервере, в том, что если список контроля доступа (access control list, ACL) сконфигурирован неправильно, то к базе данных возможен несанкционированный доступ. Если, например, для Anonymous в ACL установлен уровень доступа Author или выше, то любой сможет использовать базу данных Domino Web Access для отправки почты. Однако почта будет посылаться не от имени владельца базы, а от имени Anonymous, и в таком виде будет попадать в почтовые ящики получателей (как показано на рис. 7.3).
(рис 7.3) Почта, полученная от пользователя AnonymousСледовательно, для обеспечения безопасности пользователи Domino Web Access должны проходить аутентификацию. Иными словами, ACL почтового файла пользователя должен быть правильно настроен и пользователи должны правильно осуществлять вход и выход из системы, чтобы применять возможности и функции Domino Web Access.
Когда пользователь входит в Domino Web Access, он должен ввести имя пользователя и соответствующий интернет-пароль, как указано в документе Person. Имена пользователей, которые сервер считает допустимыми, зависят от значения в поле Internet authentication (Интернет-аутентификация) на закладке Security (Безопасность) документа Server.
Способы проведения аутентификации могут быть разными. В Domino Web Access пользователи могут проходить аутентификацию несколькими путями, в зависимости от конфигурации механизмов аутентификации сервера Domino:
Важно отметить, что для обеспечения оптимальной безопасности можно зашифровать канал связи между Web-браузером пользователя и Domino при помощи протокола Secure Sockets Layer (SSL).
Мы коротко опишем специфику каждого из этих механизмов аутентификации и некоторые варианты, которые можно применять для расширения механизмов аутентификации.
Этот тип аутентификации устанавливается по умолчанию при первоначальной настройке сервера Domino. Он запускается, когда пользователь пытается обратиться к базе данных, ACL которой запрещает анонимный доступ, а для предоставления определенных прав доступа требует идентифицировать пользователя. На рис. 7.4 показано диалоговое окно, которое отображает Web-браузер, когда сервер Domino требует аутентификации.
(рис 7.4) Простая аутентификация по имени и паролю
Данный тип аутентификации настраивается при помощи документа Server, на закладке Internet Protocols (Интернет-протоколы), Domino Web Engine (Web-система Domino). В поле Session authentication (Сеансовая аутентификация) нужно заменить значение Disabled (Отключено) (т. е. простая аутентификация по имени и паролю) на Single Server (Один сервер), как показано на рис. 7.5.
(рис 7.5) Установка значения Session authentication (Сеансовая аутентификация) в Single ServerОбратите внимание, что задачу HTTP, чтобы изменения вступили в силу, нужно перезапустить. Делается это при помощи консольной команды tell http restart. При аутентификации пользователя вместо диалогового окна открывается форма Server Login (Вход на сервер), показанная на рис. 7.6.
(рис 7.6) Базовая форма Server Login (Вход на сервер)Пользователь, возможно, сочтет, что эта страница скучно и непрофессионально выглядит. Чтобы улучшить внешний вид данной страницы, создайте базу данных Domino Web Server Configuration (DOMCFG.NSF), как показано на рис. 7.7.
(рис 7.7) Создание базы данных Domino Web Server ConfigurationНа рис. 7.8 показана страница, отображаемая после создания упомянутой базы данных и перезапуска HTTP.
(рис 7.8) Улучшенное окно входа на серверКроме того, вы можете внести дополнительные усовершенствования, чтобы пользователи Domino Web Access увидели все возможности Domino Web Access.
Настройте перенаправление Domino Web Access Redirect при помощи шаблона Domino Web Access Redirect (IWAREDIR.NTF), который находится в директории данных Domino сервера, чтобы применялась новая форма DWALoginForm.
После выполнения этих шагов и перезапуска задачи HTTP вы можете использовать новую форму – DWALoginForm, которая выглядит так, как показано на рис. 7.9.
При использовании сеансовой аутентификации существует 2 метода расширения возможностей аутентификации.
Во-первых, вы можете применить, например, аутентификационные токены RSA Ace/Agent и RSA SecurID для выполнения многофакторной аутентификации.
Во-вторых, вы можете включить систему единой регистрации на серверах, при которой, войдя один раз в систему (например, в портал организации), пользователю больше не нужно выполнять вход снова и снова при обращении к разным серверам, входящим в домен единой регистрации.
(рис 7.9) Форма DWALoginForm для входа на сервер
Наряду с уже описанными функциями существует также возможность дополнить механизмы аутентификации шифрованием коммуникационного канала между Web-браузером пользователя и Domino при помощи SSL. Пользователи могут применять простую аутентификацию по имени и паролю или сеансовую аутентификацию, но вместо HTTP используется HTTPS.
Это означает, что в ходе аутентификации пользователи Domino Web Access имеют
дополнительную возможность аутентифицировать сервер по своему доверенному
корневому сертификату (если он был создан органом по сертификации, являющимся
доверенным, в соответствии с данными в
Серверная аутентификация производится с использованием протокола Secure Sockets Layer (SSL), который настраивается попротокольно. Это означает, что SSL можно включить для всех протоколов или только для некоторых. Для Domino Web Access это означает, что можно включить SSL для HTTP, оставив все остальные протоколы (SMTP, POP3 и IMAP) без изменений. Также необходимо открыть порт для анонимного доступа, в противном случае Domino будет требовать сертификат или имя и пароль от клиента.
Пойдя на немалые затраты, связанные с управлением сертификатами x.509v3 всех пользователей в IT-инфраструктуре, вы также можете использовать аутентификацию на основе сертификата клиента. Объяснения приводятся в прил. "С", "Domino как ис- точник сертификатов". Чтобы включить аутентификацию на основе сертификата клиента, в документе Server перейдите к закладке Ports (Порты) $$\to$$ Internet Ports (Интернет-порты) $$\to$$ Web. Укажите Yes в поле Client certificate (Сертификат клиента), как показано на рис. 7.10.
(рис 7.11) Включение аутентификации на основе сертификата клиента(рис 7.10) Форма запроса к клиентуНезависимо от используемого варианта аутентификации (простая, по имени и паролю или сеансовая), пользователю будет предложено указать не имя и пароль, а сертификат x.509v3, как показано на рис. 7.11.
Чтобы пользователь Domino Web Access мог безопасно выполнить HTTP-аутентификацию на сервере Domino с помощью SSL, ему необходим браузер, поддерживающий SSL, и доверенный корневой сертификат, выпущенный Domino или сторонним источником сертификатов (certificate authority, CA).
Чтобы получить доверенный корневой сертификат для Web-браузера от CA Domino, пользователь интернет-клиента должен выполнить следующие шаги:
Если доверенный корневой сертификат предназначается для стороннего CA, для правильного объединения следуйте установленной сторонним CA процедуре. Если и клиент и сервер уже имеют сертификаты, выпущенные данным CA, или уже имеют общего CA, этот этап проходить необязательно.
Поскольку мы имеем здесь дело только с серверной SSL-аутентификацией, у пользователя есть возможность пропустить этап, связанный с базой CA, и просто применить сам защищенный при помощи SSL сервер. В этом случае пользователь сам решает, нужно ли доверять данному серверу, когда ему будет предложено сделать этот выбор. Этот момент сходен с приглашением на перекрестную сертификацию в Notes при контакте с внешним сервером Domino (Естественно, получить корневой сертификат лучше, поскольку это не придется делать для каждого сервера).
Мы предлагаем полную информацию по настройке CA, созданию доверенного корневого сертификата, включению SSL, созданию клиентских сертификатов и выбору их для использования в Web-браузере в прил. "С", "Domino как источник сертификатов".
Теперь, когда мы объяснили, что происходит, когда пользователь входит в Domino Web Access, давайте рассмотрим, что происходит, когда пользователь выходит из Domino Web Access, в частности расскажем, что можно сделать, чтобы выход из Domino Web Access не создавал уязвимостей.
В предыдущей книге, "Lotus Security Handbook", SG24-7017, мы рассказывали, что функция выхода посылает серверу команду logout для прекращения сеанса, если используется сеансовая аутентификация. Если применяется базовая аутентификация, идентификационная информация входа в систему удаляется из Web-браузера. Также Domino Web Access закрывает окно браузера, чтобы другой пользователь не мог нажать кнопку "Назад" и увидеть предыдущую страницу, которая может содержать важную персональную информацию. Кроме того, Domino Web Access выполняет сложное взаимодействие с алгоритмом кеширования, не давая сохранить в локальном кеше браузера информацию в таком виде, чтобы его мог прочитать кто угодно.
Тем не менее нами было замечено, что функция обеспечения безопасности не очищает локальный кеш браузера. Единственной возможностью обеспечить недоступность информации в кеше для третьих лиц является либо самостоятельная очистка пользователем кеша (этого большинство пользователей не делает, даже если им часто напоминать), либо конфигурирование браузера таким образом, чтобы он не выполнял локальное сохранение информации (т. е. не создавал временных интернет-файлов) после завершения сеанса (а это редко можно сделать на компьютере в интернет-кафе).
Данная проблема ушла в прошлое. С появлением Domino Web Access в Domino 7
при выходе пользователя из системы Domino Web Access наряду с закрытием окна
браузера и удалением идентификационных данных пользователя теперь удаляет
личные данные из кеша браузера. Делается даже больше, чем кажется на первый
взгляд: в Domino 7 при инсталлированной системе управления кешем браузера
(Browser
В Microsoft Internet Explorer вы можете использовать Browser
Не все компьютеры одинаковы, и не всегда у пользователей имеется доступ к высокопроизводительной рабочей станции или к сети с высокой пропускной способностью. Поэтому, несмотря на похвальность намерения организации ограничить сохранение файлов в кеше браузера для обеспечения безопасности, может возникнуть проблема, связанная с необходимостью загружать элементы дизайна Domino Web Access для каждого сеанса, а это плохо влияет на производительность и заставляет пользователя ждать, прежде чем он сможет полностью применить возможности Domino Web Access. Чтобы решить данную проблему, вы можете, например, оставить элементы дизайна Domino Web Access в кеше для увеличения производительности, но удалить все, что было получено из почтовых баз данных для повышения безопасности. Администраторы Domino могут задать уровень очистки кеша, удаляя все элементы кеша или только те, которые относятся к почтовой базе пользователя.
Управление кешем браузера можно настроить в документе
Обратите внимание на раздел Browser
(рис 7.12) Документ Configuration Settings (Параметры конфигурации) сервера Domino Web AccessРаздел Browser
| Уровень | Описание |
|---|---|
| 0 | Этот уровень задан по умолчанию, и он обеспечивает максимальную производительность Domino
Web Access. На этом уровне Browser |
| 1 | На этом уровне Browser |
| 2 | На этом уровне Browser |
| 3 | На этом уровне Browser |
| 4 | На этом уровне (который является безопасным вариантом) Browser |
| 5 | На этом уровне (который является самым безопасным вариантом) Browser |
Как уже говорилось ранее, после включения функции Browser
При автоматической установке, когда пользователь первый раз обращается к
Domino Web Access, открывается окно подтверждения Browser
(рис 7.13) Сообщение для подтверждения установки Browser Cache ManagementЕсли система Browser
Если нажать кнопку
Если функция Browser
В качестве дополнительной меры безопасности администратор Domino может
запретить пользователям, у которых не установлен Browser
После того как функция Browser
Другие параметры в разделе
Параметр Clear history when browser window is closed (Очистить историю при закрытии окна браузера) позволяет очистить историю Web-браузера при закрытии окна, что также предотвращает несанкционированный доступ к ранее отображаемым страницам.
(рис 7.15) Параметры выхода из системы – деинсталляция Browser Cache Management(рис 7.14) Подтверждение деинсталляции Browser Cache ManagementПараметр
(рис 7.16) Параметры: общиеНаконец, конфигурационный параметр Maintain static code archive between sessions (Сохранять архив статического кода между сеансами браузера) дает возможность переместить статические элементы дизайна Domino Web Access из кеша в локальную папку на компьютере, чтобы их можно было восстановить в кеше, когда браузер будет снова запущен. По умолчанию данный параметр включен.
Теперь, когда мы обеспечили правильный вход в систему и сделали так, чтобы при выходе из нее не оставалось ничего лишнего, давайте рассмотрим безопасный обмен сообщениями, который происходит между входом и выходом.
В Domino Web Access безопасный обмен сообщениями появился начиная с версии 6.5. В версии 7.0 его функциональность была расширена. Давайте изучим, что появилось в версии 6.5 и какая надстройка была введена в версию 7.0.
В Domino Web Access поддержка шифрования почты появилась в версии 6.5. Сохраняя файл Notes ID в почтовом файле, пользователи теперь могут посылать и читать зашифрованные почтовые сообщения.
На серверной стороне администратор для этого должен отредактировать доку-
мент
На клиентской стороне, чтобы пользователи Domino Web Access могли шифровать или подписывать свои почтовые сообщения, им нужно внести некоторые изменения в настройки, в частности сделать так, чтобы в почтовом файле хранилась копия Notes ID. Если почтовый файл не содержит копию Notes ID, ее нужно импортировать при помощи пункта Import Notes ID (Импорт Notes ID) на закладке Security (Безопасность) диалогового окна Preferences (Параметры). Далее пользователь должен перейти к закладке Mail (Почта) окна Preferences (Параметры) и выбрать опции, включающие электронную подпись и шифрование почты (с четким указанием на то, что пропущен необходимый этап, а именно импорт Notes ID, является недоступность кнопок). После выполнения данных шагов и сохранения настроек пользователь Domino Web Access сможет подписывать и шифровать почтовые сообщения. Отметим, что это необходимо только в том случае, если пользователь хочет, чтобы шифрование применялось по умолчанию для каждого нового письма. В качестве альтернативы пользователь может выбирать опцию, расположенную справа вверху (под панелью инструментов) окна каждого почтового сообщения.
Применительно к зашифрованной почте в Domino Web Access нужно сделать ряд предостережений. Например, для пользователя Domino Web Access существали ограничения как по дешифровке зашифрованного письма Notes, так и по отправке зашифрованных почтовых сообщений пользователям Notes. Отсутствовала поддержка зашифрованных и подписанных писем S/MIME.
Версия 7.0 Domino Web Access продолжает поддерживать функции безопасного обмена сообщениями, появившиеся в версии 6.5, и теперь имеется полный набор таких функций, с поддержкой S/MIME, что значительно увеличивает возможности системы безопасности Domino Web Access в области обмена сообщениями.
Теперь пользователи могут применять всю функциональность S/MIME, связанную с проверкой цифровой подписи S/MIME на подписанном сообщении. Если у пользователя есть сертификат X.509 в Notes ID, хранящемся в почтовом файле, он может, помимо дешифровки получаемых S/MIME-сообщений, прикреплять цифровую подпись S/MIME к созданным сообщениям. Исходящие сообщения могут быть зашифрованы при помощи S/MIME для получателей, которые имеют сертификат X.509 в Domino Directory, или в контактах Domino Web Access, или в любой директории, доступной через Directory Assistance.
Стоит отметить, что для сертификата X.509, который должен использоваться в Domino Web Access, необходимо выпустить через сертификатор организации перекрестный интернет-сертификат, который сертифицирует источник, выпустивший сертификат X.509. Перекрестный интернет-сертификат должен находиться в Domino Directory. Кроме того, Domino Web Access также позволяет использовать для шифрования недоверенные сертификаты. Администратор должен включить эту возможность в документ Server Configuration, как показано на рис. 7.17.
(рис 7.17) Параметр, разрешающий недоверенные интернет-сертификатыПосле этого пользователь может указать, что нужно доверять всем интернет-сертификатам (или, в качестве альтернативы, выводить для пользователя запрос) при каждой отправке сообщения, применяющего интернет-сертификат, который не имеет своего перекрестного сертификата, как это показано на рис. 7.18.
(рис 7.18) Опция Domino Web Access, означающая "всегда доверять Интернет-сертификатам для отправляемой почты S/MIME"Вы можете дополнить безопасный обмен сообщениями применением SSL. Если SSL-соединение является обязательным для клиента или для клиента и сервера, то пользователи Domino Web Access не смогут читать и отправлять зашифрованные сообщения через HTTP-соединение. Если пользователь имеет HTTP-соединение, для доступа к зашифрованному сообщению на сервере ему нужно переключиться на HTTPS. При отправке зашифрованной почты это переключение производится автоматически. При чтении зашифрованной почты пользователю будет предложено выполнить переключение.
Чтобы пользователи могли посылать зашифрованные и имеющие цифровые подписи сообщения, выполните следующие шаги:
В оставшейся части раздела предлагаются инструкции по каждому из этих шагов.
Чтобы пользователи Domino Web Access могли шифровать и снабжать цифровыми
подписями почтовые сообщения, администратор Domino должен был включать параметры
Encrypted mail support (Поддержка шифрования почты) и Name Resolution
and Validation (Разрешение и проверка имен) на закладке Domino Web Access документа
На рис. 7.12 мы показали весь набор конфигурационных параметров для настройки Domino Web Access.
Важным полем в разделе Mail (Почта) является
Важным полем в разделе Mail Encryption (Шифрование почты) является
К другим интересующим нас полям в разделе Encryption (Шифрование почты) относятся следующие:
Чтобы пользователи Domino Web Access могли шифровать и подписывать электронные сообщения, нужно, чтобы отправитель имел интернет-сертификат получателя в Domino Web Access Contacts, Domino Directory или директории LDAP. Отправитель также должен выпустить перекрестный сертификат для клиента или для сертификатора, с помощью которого был выпущен интернет-сертификат получателя, за исключением случаев, когда были включены соответствующие параметры конфигурации и необходимые настройки.
Если для CA получателя выпущен перекрестный сертификат, отправитель может посылать зашифрованные сообщения всем, у кого есть сертификаты, выпущенные этим CA, при условии, что у отправителя будут интернет-сертификаты получателей. Если интернет-сертификат хранится в Domino Directory другого домена или в директории LDAP, то к этой директории должен быть настроен доступ с помощью Directory Assistance.
Чтобы добавить интернет-сертификат и перекрестный сертификат, получатель должен послать пользователю S/MIME-сообщение с цифровой подписью. Пользователь может ответить на сообщение, если он имеет доступ к общему ключу получателя. Однако здесь необходимо некоторое уточнение. Если пользователь Domino Web Access получает подписанное S/MIME-сообщение и добавляет отправителя в список контактов, в запись базы Contacts добавляется сертификат x.509 отправителя. Особенно важно отметить, что, пока добавление отправителя в список контактов не будет выполнено, сертификат не будет доступен для отправки почты.
В следующем примере показан обмен S/MIME-сообщениями между пользователем Domino Web Access и пользователем Lotus Notes.
На рис. 7.19 пользователь Lotus Notes отправил S/MIME-сообщение с цифровой подписью пользователю Domino Web Access. Теперь у пользователя Domino Web Access есть общий ключ пользователя Notes, который он может применить для отправки зашифрованной почты. Индикатором того, что сообщение зашифровано, является наличие небольшой ленточки справа от имени отправителя.
(рис 7.19) Получение подписанного сообщения S/MIMEОднако в какой-то момент пользователь Domino Web Access решает направить пользователю Lotus Notes S/MIME-сообщение с цифровой подписью, как показано на рис. 7.20.
(рис 7.20) Ответ на S/MIME-сообщение с цифровой подписьюПользователь Lotus Notes получает S/MIME-сообщение с цифровой подписью, как показано на рис. 7.21.
(рис 7.21) Получение S/MIME-сообщения с цифровой подписью Пользователь Lotus Notes решает отправить пользователю Domino Web Access зашифрованное S/MIME-сообщение, как показано на рис. 7.22.
(рис 7.22) Ответ при помощи зашифрованного S/MIME-сообщенияПользователь Domino Web Access получает зашифрованное S/MIME-сообщение от пользователя Lotus Notes, как показано на рис. 7.23. Индикатором того, что сообщение зашифровано, является наличие небольшого значка – замка справа от имени отправителя.
(рис 7.23) Получение зашифрованного S/MIME-сообщенияНа этом этапе пользователь Domino Web Access может послать зашифрованное S/MIME-сообщение. Но мы здесь этого показывать не будем.
Обратите внимание, что, когда доступны как Notes- , так и S/MIME-шифрование и электронная подпись, Domino Web Access использует по умолчанию S/MIME-шифрование и электронную подпись. Это может вызывать проблемы в смешанных средах, включающих одновременно серверы Domino 7 и серверы Domino предыдущих версий. Более ранние серверы Domino не поддерживают S/MIME, поэтому сообщения, зашифрованные и подписанные при помощи S/MIME, не могут быть проверены или дешифрованы.
Мы рекомендуем использовать параметр файла NOTES.INI iNotes_wa_SecMailPreferNotes=1, если пользователи Domino Web Access 7.0 обмениваются зашифрованной почтой с пользователями Domino Web Access 6.x и для этих пользователей были выпущены сертификаты x.509. В режиме offline данный параметр не поддерживается.
В вопросе безопасности Domino Web Access с клиентской стороны существует ряд факторов, сходных с теми, которые имеются в стандартном клиенте Notes. В дополнение к приведенному выше обсуждению выхода из системы заметим, что физическая безопасность машины является очень важным фактором (не оставляйте без присмотра браузер, подключенный к серверу; заблокируйте его замком Кенсингтона или другим сходным устройством). Шифруйте локальные (офлайновые) базы данных и создавайте документы политики offline-безопасности Domino.
Наконец, мы должны обсудить вопрос об обязанностях по соблюдению мер безопасности, связанных с использованием браузера в качестве клиента. Когда пользователи применяют браузерные технологии в качестве основного метода взаимодействия с сервером, существует повышенная опасность попасть под действие злонамеренных программ в виде скриптов JavaScript, агентов Java, элементов управления ActiveX $$\text{\textregistered}$$ и т. п. Чтобы пользователи не запускали такой код, в Domino Web Access по умолчанию применяется фильтр активного содержимого (Active Content Filter), который обрабатывает HTML-код каждого почтового сообщения и переписывает его, прежде чем он будет отображен в браузере. Это может отрицательно повлиять на производительность сервера, поэтому в файле NOTES.INI есть флаг, который можно при желании отключить.
Чтобы отключить фильтр активного содержимого, установите в файле NOTES.INI следующий параметр
iNotes_WA_DisableActCntSecurity=1
и перезапустите HTTP.
Если установить для этого параметра значение 0, поставить перед ним символ комментария или удалить строку из файла NOTES.INI, фильтр будет снова включен.
Существует ряд отличий в размещении клиентов Notes и Domino Web Access, которые следует принимать во внимание.
На этом заканчивается наш обзор новых возможностей безопасности Domino Web Access. В следующей лекции рассматривается тема, интересная как для пользователей Lotus Notes, так и для пользователей Domino Web Access: новая функциональность, которая поможет победить в борьбе со спамом, т. е. несанкционированными почтовыми рассылками.
Lotus Domino Web Access – это Web-клиент, который дает возможность пользователям обращаться к различным службам Domino при помощи Web-браузера. Пользователь браузера получает доступ к многочисленным передовым клиентским возможностям и функциям, которые обычно были доступны только тем, кто использует не браузеры, а, например, Lotus Notes. Эти передовые возможности значительно повышают удобство работы в таких областях, как обмен сообщениями, календарное планирование и расписания, управление персональной информацией (personal information management, PIM), управление заданиями и личный журнал. Пользователи также могут работать при отсутствии соединения (offline), управляя почтовыми сообщениями, контактами, календарными планами, списками текущих дел и т.п. с помощью пользовательского интерфейса, предоставленного Domino Web Access.
К настоящему моменту Domino Web Access существует уже несколько лет, и он развивается с каждой новой версией сервера Domino. Версия 7 не является исключением. Функциональное соответствие с Lotus Notes в упомянутых выше областях довольно близкое, в том числе интеграция с Lotus Sametime. Однако клиент Notes по-прежнему предоставляет более богатую и более полную среду для конечного пользователя, особенно в том, что касается дизайна, применения репликации приложений, поддержки PDA-устройств и некоторых других возможностей, доступных только для этого клиента.
Клиент Domino Web Access изначально разрабатывался для того, чтобы снабдить браузер большинством возможностей Notes. Он также создавался для пользователей, которых можно назвать бездисковыми. Такими пользователями обычно являются те, которым лишь иногда требуется доступ к электронной почте и календарным планам. Такие пользователи являются мобильными и не имеют фиксированного местоположения, что делает их идеальными потребителями тех возможностей, которые предлагает браузер и Domino Web Access. То же относится и к внешним пользователям, ведущим тесное сотрудничество с организацией, которым требуется доступ к системе обмена сообщениями организации, но которым организация не хочет предоставлять клиент Notes.
Однако появился новый класс пользователей, которые применяют все возможности Domino Web Access. У этих пользователей есть обычный клиент Notes, но они, как правило, работают удаленно и реализация сервера Domino в месте их работы с реализацией индивидуальных клиентов Notes и соответствующей поддержкой обходится слишком дорого. Поэтому этим пользователям обычно предоставляется клиент Domino Web Access, который обеспечивает большую часть функций при существенной экономии.
Учитывая все эти моменты, мы опишем в этой лекции новые возможности системы безопасности Domino 7, которые повышают безопасность Domino Web Access. В книге серии Redbook, посвященной безопасности, "Lotus Security Handbook", SG24-7017, информация, относящаяся к Domino Web Access, описывается под заголовком iNotes $$\text{\texttrademark}$$ (предыдущее название Domino Web Access), в главе 12, "Security features of other Lotus products".
Мы приведем некоторые базовые сведения, которые позволят правильно установить Domino Web Access и обеспечить его корректную работу, а также дадим некоторые практические советы. Кроме того, поскольку данный курс посвящена безопасности, мы рассмотрим здесь следующие функции и усовершенствования:
Поскольку функциональность Domino Web Access лежит в точке пересечения функций Web-браузера и сервера Domino и это является источником заблуждений относительно неоптимальных конфигураций безопасности, мы обсудим, где используются конкретные возможности системы безопасности, в сервере Domino, в Web-браузере или и там и там.
Наконец, чтобы Domino Web Access работал правильно и позже не возникало никаких проблем, необходимо понимать, какие платформы поддерживаются системой.
Domino Web Access 7.0 поддерживает следующие операционные системы сервера:
Domino Web Access 7.0 поддерживает следующие операционные системы клиента:
Domino Web Access 7.0 поддерживает следующие Web-браузеры:
Кроме того, в версии 7.0.2 будет поддержка клиентов Mac с браузером Firefox.
С технической точки зрения Domino Web Access (ранее называвшийся iNotes Web Access) предоставляет пользователям Lotus Notes доступ через браузер к почте Notes, а также к календарным планам и расписаниям. Пользователи Domino Web Access могут посылать и получать почту, просматривать календарные планы, создавать списки дел, вести записную книжку и работать без соединения (offline).
После настройки на доступ к Domino Web Access пользователь может
применять для обращения к своим почтовым файлам как стандартный клиент
Notes, так и Web-браузер. Поскольку и клиент Notes, и клиент Domino
Web Access работают с одним пользовательским почтовым файлом, отметка
"прочитано" или "не прочитано" будет сохраняться в
соответствующем состоянии, независимо от того, с помощью какого
клиента пользователь читал почту. Пользователь также может
осуществлять синхронизацию контактной информации в личной адресной
книге с информацией в списке контактов (
Кроме того, пользователи имеют возможность работать в режиме offline и использовать сервер Sametime. Для работы в режиме offline можно синхронизировать Domino Web Access с Domino Off-Line Services. Domino Off-Line Services дает возможность пользователям работать при отсутствии сетевого соединения, а также предоставляет возможности для репликации, которые пользователь Notes может ожидать встретить при работе с клиентом Notes. Также существует возможность интегрировать Domino Web Access с Lotus Sametime для получения интегрированных возможностей ведения разговоров в реальном времени. Стоит отметить, что ни Domino Off-Line Services, ни Sametime не являются необходимыми для использования Domino Web Access.
С точки зрения безопасности применительно к Domino Web Access следует упомянуть несколько базовых моментов.
Во-первых, для Domino Web Access требуется безопасность входа пользователя в систему (специальный выход из системы обычно не является обязательным, хотя это хорошая практика). Когда пользователи осуществляют вход в Domino Web Access, они должны ввести свое имя и интернет-пароль, как он указан в документе Person. Имена пользователей, которые сервер считает допустимыми, зависят от значения в поле Internet authentication (Интернет-аутентификация) на закладке Security (Безопасность) документа Server.
Во-вторых, хотя пользователям для входа в Domino Web Access требуется только имя и интернет-пароль, для работы с безопасной почтой необходим Notes ID. Администраторы должны создавать Notes ID для каждого пользователя при регистрации новых пользователей при помощи шаблона Domino Web Access.
В оставшейся части лекции мы более подробно изучим передовые концепции безопасности.
Прежде чем начать обсуждать специфику безопасности Domino Web Access, нужно посвятить какое-то время проверке того, правильно ли настроен и корректно ли работает Domino Web Access на сервере Domino.
Мы не собираемся описывать здесь все аспекты конфигурирования сервера Domino и Domino Web Access. За подробными сведениями по этой теме обращайтесь к следующим книгам серии IBM Redbook (которые относятся к версиям 6.5 и 5.0.9 соответственно):
В данном курсе обратите внимание на следующие 3 элемента:
(рис 7.2) Почтовые шаблоны, поставляемые вместе с Domino 7(рис 7.1) Новый внешний вид Domino Web AccessНовых пользователей следует регистрировать при помощи шаблона dwa7.ntf. Для почтовых файлов существующих пользователей при помощи шаблона dwa7.ntf следует изменить структуру почтовой базы данных. Это единственный шаблон, который содержит поддержку почтовых шаблонов клиента Domino Web Access и клиента Notes. На рис. 7.2 показано, как выглядит новый интерфейс.
Теперь, когда мы настроили должным образом сервер, интернет-службы, которые он предоставляет, и обеспечили соответствие дизайна системы электронной почты нужному шаблону, все готово к рассмотрению темы аутентификации в Domino Web Access.
Domino Web Access сходен с другими базами данных Domino, расположенными на сервере, в том, что если список контроля доступа (access control list, ACL) сконфигурирован неправильно, то к базе данных возможен несанкционированный доступ. Если, например, для Anonymous в ACL установлен уровень доступа Author или выше, то любой сможет использовать базу данных Domino Web Access для отправки почты. Однако почта будет посылаться не от имени владельца базы, а от имени Anonymous, и в таком виде будет попадать в почтовые ящики получателей (как показано на рис. 7.3).
(рис 7.3) Почта, полученная от пользователя AnonymousСледовательно, для обеспечения безопасности пользователи Domino Web Access должны проходить аутентификацию. Иными словами, ACL почтового файла пользователя должен быть правильно настроен и пользователи должны правильно осуществлять вход и выход из системы, чтобы применять возможности и функции Domino Web Access.
Когда пользователь входит в Domino Web Access, он должен ввести имя пользователя и соответствующий интернет-пароль, как указано в документе Person. Имена пользователей, которые сервер считает допустимыми, зависят от значения в поле Internet authentication (Интернет-аутентификация) на закладке Security (Безопасность) документа Server.
Способы проведения аутентификации могут быть разными. В Domino Web Access пользователи могут проходить аутентификацию несколькими путями, в зависимости от конфигурации механизмов аутентификации сервера Domino:
Важно отметить, что для обеспечения оптимальной безопасности можно зашифровать канал связи между Web-браузером пользователя и Domino при помощи протокола Secure Sockets Layer (SSL).
Мы коротко опишем специфику каждого из этих механизмов аутентификации и некоторые варианты, которые можно применять для расширения механизмов аутентификации.
Этот тип аутентификации устанавливается по умолчанию при первоначальной настройке сервера Domino. Он запускается, когда пользователь пытается обратиться к базе данных, ACL которой запрещает анонимный доступ, а для предоставления определенных прав доступа требует идентифицировать пользователя. На рис. 7.4 показано диалоговое окно, которое отображает Web-браузер, когда сервер Domino требует аутентификации.
(рис 7.4) Простая аутентификация по имени и паролю
Данный тип аутентификации настраивается при помощи документа Server, на закладке Internet Protocols (Интернет-протоколы), Domino Web Engine (Web-система Domino). В поле Session authentication (Сеансовая аутентификация) нужно заменить значение Disabled (Отключено) (т. е. простая аутентификация по имени и паролю) на Single Server (Один сервер), как показано на рис. 7.5.
(рис 7.5) Установка значения Session authentication (Сеансовая аутентификация) в Single ServerОбратите внимание, что задачу HTTP, чтобы изменения вступили в силу, нужно перезапустить. Делается это при помощи консольной команды tell http restart. При аутентификации пользователя вместо диалогового окна открывается форма Server Login (Вход на сервер), показанная на рис. 7.6.
(рис 7.6) Базовая форма Server Login (Вход на сервер)Пользователь, возможно, сочтет, что эта страница скучно и непрофессионально выглядит. Чтобы улучшить внешний вид данной страницы, создайте базу данных Domino Web Server Configuration (DOMCFG.NSF), как показано на рис. 7.7.
(рис 7.7) Создание базы данных Domino Web Server ConfigurationНа рис. 7.8 показана страница, отображаемая после создания упомянутой базы данных и перезапуска HTTP.
(рис 7.8) Улучшенное окно входа на серверКроме того, вы можете внести дополнительные усовершенствования, чтобы пользователи Domino Web Access увидели все возможности Domino Web Access.
Настройте перенаправление Domino Web Access Redirect при помощи шаблона Domino Web Access Redirect (IWAREDIR.NTF), который находится в директории данных Domino сервера, чтобы применялась новая форма DWALoginForm.
После выполнения этих шагов и перезапуска задачи HTTP вы можете использовать новую форму – DWALoginForm, которая выглядит так, как показано на рис. 7.9.
При использовании сеансовой аутентификации существует 2 метода расширения возможностей аутентификации.
Во-первых, вы можете применить, например, аутентификационные токены RSA Ace/Agent и RSA SecurID для выполнения многофакторной аутентификации.
Во-вторых, вы можете включить систему единой регистрации на серверах, при которой, войдя один раз в систему (например, в портал организации), пользователю больше не нужно выполнять вход снова и снова при обращении к разным серверам, входящим в домен единой регистрации.
(рис 7.9) Форма DWALoginForm для входа на сервер
Наряду с уже описанными функциями существует также возможность дополнить механизмы аутентификации шифрованием коммуникационного канала между Web-браузером пользователя и Domino при помощи SSL. Пользователи могут применять простую аутентификацию по имени и паролю или сеансовую аутентификацию, но вместо HTTP используется HTTPS.
Это означает, что в ходе аутентификации пользователи Domino Web Access имеют
дополнительную возможность аутентифицировать сервер по своему доверенному
корневому сертификату (если он был создан органом по сертификации, являющимся
доверенным, в соответствии с данными в
Серверная аутентификация производится с использованием протокола Secure Sockets Layer (SSL), который настраивается попротокольно. Это означает, что SSL можно включить для всех протоколов или только для некоторых. Для Domino Web Access это означает, что можно включить SSL для HTTP, оставив все остальные протоколы (SMTP, POP3 и IMAP) без изменений. Также необходимо открыть порт для анонимного доступа, в противном случае Domino будет требовать сертификат или имя и пароль от клиента.
Пойдя на немалые затраты, связанные с управлением сертификатами x.509v3 всех пользователей в IT-инфраструктуре, вы также можете использовать аутентификацию на основе сертификата клиента. Объяснения приводятся в прил. "С", "Domino как ис- точник сертификатов". Чтобы включить аутентификацию на основе сертификата клиента, в документе Server перейдите к закладке Ports (Порты) $$\to$$ Internet Ports (Интернет-порты) $$\to$$ Web. Укажите Yes в поле Client certificate (Сертификат клиента), как показано на рис. 7.10.
(рис 7.11) Включение аутентификации на основе сертификата клиента(рис 7.10) Форма запроса к клиентуНезависимо от используемого варианта аутентификации (простая, по имени и паролю или сеансовая), пользователю будет предложено указать не имя и пароль, а сертификат x.509v3, как показано на рис. 7.11.
Чтобы пользователь Domino Web Access мог безопасно выполнить HTTP-аутентификацию на сервере Domino с помощью SSL, ему необходим браузер, поддерживающий SSL, и доверенный корневой сертификат, выпущенный Domino или сторонним источником сертификатов (certificate authority, CA).
Чтобы получить доверенный корневой сертификат для Web-браузера от CA Domino, пользователь интернет-клиента должен выполнить следующие шаги:
Если доверенный корневой сертификат предназначается для стороннего CA, для правильного объединения следуйте установленной сторонним CA процедуре. Если и клиент и сервер уже имеют сертификаты, выпущенные данным CA, или уже имеют общего CA, этот этап проходить необязательно.
Поскольку мы имеем здесь дело только с серверной SSL-аутентификацией, у пользователя есть возможность пропустить этап, связанный с базой CA, и просто применить сам защищенный при помощи SSL сервер. В этом случае пользователь сам решает, нужно ли доверять данному серверу, когда ему будет предложено сделать этот выбор. Этот момент сходен с приглашением на перекрестную сертификацию в Notes при контакте с внешним сервером Domino (Естественно, получить корневой сертификат лучше, поскольку это не придется делать для каждого сервера).
Мы предлагаем полную информацию по настройке CA, созданию доверенного корневого сертификата, включению SSL, созданию клиентских сертификатов и выбору их для использования в Web-браузере в прил. "С", "Domino как источник сертификатов".
Теперь, когда мы объяснили, что происходит, когда пользователь входит в Domino Web Access, давайте рассмотрим, что происходит, когда пользователь выходит из Domino Web Access, в частности расскажем, что можно сделать, чтобы выход из Domino Web Access не создавал уязвимостей.
В предыдущей книге, "Lotus Security Handbook", SG24-7017, мы рассказывали, что функция выхода посылает серверу команду logout для прекращения сеанса, если используется сеансовая аутентификация. Если применяется базовая аутентификация, идентификационная информация входа в систему удаляется из Web-браузера. Также Domino Web Access закрывает окно браузера, чтобы другой пользователь не мог нажать кнопку "Назад" и увидеть предыдущую страницу, которая может содержать важную персональную информацию. Кроме того, Domino Web Access выполняет сложное взаимодействие с алгоритмом кеширования, не давая сохранить в локальном кеше браузера информацию в таком виде, чтобы его мог прочитать кто угодно.
Тем не менее нами было замечено, что функция обеспечения безопасности не очищает локальный кеш браузера. Единственной возможностью обеспечить недоступность информации в кеше для третьих лиц является либо самостоятельная очистка пользователем кеша (этого большинство пользователей не делает, даже если им часто напоминать), либо конфигурирование браузера таким образом, чтобы он не выполнял локальное сохранение информации (т. е. не создавал временных интернет-файлов) после завершения сеанса (а это редко можно сделать на компьютере в интернет-кафе).
Данная проблема ушла в прошлое. С появлением Domino Web Access в Domino 7
при выходе пользователя из системы Domino Web Access наряду с закрытием окна
браузера и удалением идентификационных данных пользователя теперь удаляет
личные данные из кеша браузера. Делается даже больше, чем кажется на первый
взгляд: в Domino 7 при инсталлированной системе управления кешем браузера
(Browser
В Microsoft Internet Explorer вы можете использовать Browser
Не все компьютеры одинаковы, и не всегда у пользователей имеется доступ к высокопроизводительной рабочей станции или к сети с высокой пропускной способностью. Поэтому, несмотря на похвальность намерения организации ограничить сохранение файлов в кеше браузера для обеспечения безопасности, может возникнуть проблема, связанная с необходимостью загружать элементы дизайна Domino Web Access для каждого сеанса, а это плохо влияет на производительность и заставляет пользователя ждать, прежде чем он сможет полностью применить возможности Domino Web Access. Чтобы решить данную проблему, вы можете, например, оставить элементы дизайна Domino Web Access в кеше для увеличения производительности, но удалить все, что было получено из почтовых баз данных для повышения безопасности. Администраторы Domino могут задать уровень очистки кеша, удаляя все элементы кеша или только те, которые относятся к почтовой базе пользователя.
Управление кешем браузера можно настроить в документе
Обратите внимание на раздел Browser
(рис 7.12) Документ Configuration Settings (Параметры конфигурации) сервера Domino Web AccessРаздел Browser
| Уровень | Описание |
|---|---|
| 0 | Этот уровень задан по умолчанию, и он обеспечивает максимальную производительность Domino
Web Access. На этом уровне Browser |
| 1 | На этом уровне Browser |
| 2 | На этом уровне Browser |
| 3 | На этом уровне Browser |
| 4 | На этом уровне (который является безопасным вариантом) Browser |
| 5 | На этом уровне (который является самым безопасным вариантом) Browser |
Как уже говорилось ранее, после включения функции Browser
При автоматической установке, когда пользователь первый раз обращается к
Domino Web Access, открывается окно подтверждения Browser
(рис 7.13) Сообщение для подтверждения установки Browser Cache ManagementЕсли система Browser
Если нажать кнопку
Если функция Browser
В качестве дополнительной меры безопасности администратор Domino может
запретить пользователям, у которых не установлен Browser
После того как функция Browser
Другие параметры в разделе
Параметр Clear history when browser window is closed (Очистить историю при закрытии окна браузера) позволяет очистить историю Web-браузера при закрытии окна, что также предотвращает несанкционированный доступ к ранее отображаемым страницам.
(рис 7.15) Параметры выхода из системы – деинсталляция Browser Cache Management(рис 7.14) Подтверждение деинсталляции Browser Cache ManagementПараметр
(рис 7.16) Параметры: общиеНаконец, конфигурационный параметр Maintain static code archive between sessions (Сохранять архив статического кода между сеансами браузера) дает возможность переместить статические элементы дизайна Domino Web Access из кеша в локальную папку на компьютере, чтобы их можно было восстановить в кеше, когда браузер будет снова запущен. По умолчанию данный параметр включен.
Теперь, когда мы обеспечили правильный вход в систему и сделали так, чтобы при выходе из нее не оставалось ничего лишнего, давайте рассмотрим безопасный обмен сообщениями, который происходит между входом и выходом.
В Domino Web Access безопасный обмен сообщениями появился начиная с версии 6.5. В версии 7.0 его функциональность была расширена. Давайте изучим, что появилось в версии 6.5 и какая надстройка была введена в версию 7.0.
В Domino Web Access поддержка шифрования почты появилась в версии 6.5. Сохраняя файл Notes ID в почтовом файле, пользователи теперь могут посылать и читать зашифрованные почтовые сообщения.
На серверной стороне администратор для этого должен отредактировать доку-
мент
На клиентской стороне, чтобы пользователи Domino Web Access могли шифровать или подписывать свои почтовые сообщения, им нужно внести некоторые изменения в настройки, в частности сделать так, чтобы в почтовом файле хранилась копия Notes ID. Если почтовый файл не содержит копию Notes ID, ее нужно импортировать при помощи пункта Import Notes ID (Импорт Notes ID) на закладке Security (Безопасность) диалогового окна Preferences (Параметры). Далее пользователь должен перейти к закладке Mail (Почта) окна Preferences (Параметры) и выбрать опции, включающие электронную подпись и шифрование почты (с четким указанием на то, что пропущен необходимый этап, а именно импорт Notes ID, является недоступность кнопок). После выполнения данных шагов и сохранения настроек пользователь Domino Web Access сможет подписывать и шифровать почтовые сообщения. Отметим, что это необходимо только в том случае, если пользователь хочет, чтобы шифрование применялось по умолчанию для каждого нового письма. В качестве альтернативы пользователь может выбирать опцию, расположенную справа вверху (под панелью инструментов) окна каждого почтового сообщения.
Применительно к зашифрованной почте в Domino Web Access нужно сделать ряд предостережений. Например, для пользователя Domino Web Access существали ограничения как по дешифровке зашифрованного письма Notes, так и по отправке зашифрованных почтовых сообщений пользователям Notes. Отсутствовала поддержка зашифрованных и подписанных писем S/MIME.
Версия 7.0 Domino Web Access продолжает поддерживать функции безопасного обмена сообщениями, появившиеся в версии 6.5, и теперь имеется полный набор таких функций, с поддержкой S/MIME, что значительно увеличивает возможности системы безопасности Domino Web Access в области обмена сообщениями.
Теперь пользователи могут применять всю функциональность S/MIME, связанную с проверкой цифровой подписи S/MIME на подписанном сообщении. Если у пользователя есть сертификат X.509 в Notes ID, хранящемся в почтовом файле, он может, помимо дешифровки получаемых S/MIME-сообщений, прикреплять цифровую подпись S/MIME к созданным сообщениям. Исходящие сообщения могут быть зашифрованы при помощи S/MIME для получателей, которые имеют сертификат X.509 в Domino Directory, или в контактах Domino Web Access, или в любой директории, доступной через Directory Assistance.
Стоит отметить, что для сертификата X.509, который должен использоваться в Domino Web Access, необходимо выпустить через сертификатор организации перекрестный интернет-сертификат, который сертифицирует источник, выпустивший сертификат X.509. Перекрестный интернет-сертификат должен находиться в Domino Directory. Кроме того, Domino Web Access также позволяет использовать для шифрования недоверенные сертификаты. Администратор должен включить эту возможность в документ Server Configuration, как показано на рис. 7.17.
(рис 7.17) Параметр, разрешающий недоверенные интернет-сертификатыПосле этого пользователь может указать, что нужно доверять всем интернет-сертификатам (или, в качестве альтернативы, выводить для пользователя запрос) при каждой отправке сообщения, применяющего интернет-сертификат, который не имеет своего перекрестного сертификата, как это показано на рис. 7.18.
(рис 7.18) Опция Domino Web Access, означающая "всегда доверять Интернет-сертификатам для отправляемой почты S/MIME"Вы можете дополнить безопасный обмен сообщениями применением SSL. Если SSL-соединение является обязательным для клиента или для клиента и сервера, то пользователи Domino Web Access не смогут читать и отправлять зашифрованные сообщения через HTTP-соединение. Если пользователь имеет HTTP-соединение, для доступа к зашифрованному сообщению на сервере ему нужно переключиться на HTTPS. При отправке зашифрованной почты это переключение производится автоматически. При чтении зашифрованной почты пользователю будет предложено выполнить переключение.
Чтобы пользователи могли посылать зашифрованные и имеющие цифровые подписи сообщения, выполните следующие шаги:
В оставшейся части раздела предлагаются инструкции по каждому из этих шагов.
Чтобы пользователи Domino Web Access могли шифровать и снабжать цифровыми
подписями почтовые сообщения, администратор Domino должен был включать параметры
Encrypted mail support (Поддержка шифрования почты) и Name Resolution
and Validation (Разрешение и проверка имен) на закладке Domino Web Access документа
На рис. 7.12 мы показали весь набор конфигурационных параметров для настройки Domino Web Access.
Важным полем в разделе Mail (Почта) является
Важным полем в разделе Mail Encryption (Шифрование почты) является
К другим интересующим нас полям в разделе Encryption (Шифрование почты) относятся следующие:
Чтобы пользователи Domino Web Access могли шифровать и подписывать электронные сообщения, нужно, чтобы отправитель имел интернет-сертификат получателя в Domino Web Access Contacts, Domino Directory или директории LDAP. Отправитель также должен выпустить перекрестный сертификат для клиента или для сертификатора, с помощью которого был выпущен интернет-сертификат получателя, за исключением случаев, когда были включены соответствующие параметры конфигурации и необходимые настройки.
Если для CA получателя выпущен перекрестный сертификат, отправитель может посылать зашифрованные сообщения всем, у кого есть сертификаты, выпущенные этим CA, при условии, что у отправителя будут интернет-сертификаты получателей. Если интернет-сертификат хранится в Domino Directory другого домена или в директории LDAP, то к этой директории должен быть настроен доступ с помощью Directory Assistance.
Чтобы добавить интернет-сертификат и перекрестный сертификат, получатель должен послать пользователю S/MIME-сообщение с цифровой подписью. Пользователь может ответить на сообщение, если он имеет доступ к общему ключу получателя. Однако здесь необходимо некоторое уточнение. Если пользователь Domino Web Access получает подписанное S/MIME-сообщение и добавляет отправителя в список контактов, в запись базы Contacts добавляется сертификат x.509 отправителя. Особенно важно отметить, что, пока добавление отправителя в список контактов не будет выполнено, сертификат не будет доступен для отправки почты.
В следующем примере показан обмен S/MIME-сообщениями между пользователем Domino Web Access и пользователем Lotus Notes.
На рис. 7.19 пользователь Lotus Notes отправил S/MIME-сообщение с цифровой подписью пользователю Domino Web Access. Теперь у пользователя Domino Web Access есть общий ключ пользователя Notes, который он может применить для отправки зашифрованной почты. Индикатором того, что сообщение зашифровано, является наличие небольшой ленточки справа от имени отправителя.
(рис 7.19) Получение подписанного сообщения S/MIMEОднако в какой-то момент пользователь Domino Web Access решает направить пользователю Lotus Notes S/MIME-сообщение с цифровой подписью, как показано на рис. 7.20.
(рис 7.20) Ответ на S/MIME-сообщение с цифровой подписьюПользователь Lotus Notes получает S/MIME-сообщение с цифровой подписью, как показано на рис. 7.21.
(рис 7.21) Получение S/MIME-сообщения с цифровой подписьюПользователь Lotus Notes решает отправить пользователю Domino Web Access зашифрованное S/MIME-сообщение, как показано на рис. 7.22.
(рис 7.22) Ответ при помощи зашифрованного S/MIME-сообщенияПользователь Domino Web Access получает зашифрованное S/MIME-сообщение от пользователя Lotus Notes, как показано на рис. 7.23. Индикатором того, что сообщение зашифровано, является наличие небольшого значка – замка справа от имени отправителя.
(рис 7.23) Получение зашифрованного S/MIME-сообщенияНа этом этапе пользователь Domino Web Access может послать зашифрованное S/MIME-сообщение. Но мы здесь этого показывать не будем.
Обратите внимание, что, когда доступны как Notes- , так и S/MIME-шифрование и электронная подпись, Domino Web Access использует по умолчанию S/MIME-шифрование и электронную подпись. Это может вызывать проблемы в смешанных средах, включающих одновременно серверы Domino 7 и серверы Domino предыдущих версий. Более ранние серверы Domino не поддерживают S/MIME, поэтому сообщения, зашифрованные и подписанные при помощи S/MIME, не могут быть проверены или дешифрованы.
Мы рекомендуем использовать параметр файла NOTES.INI iNotes_wa_SecMailPreferNotes=1, если пользователи Domino Web Access 7.0 обмениваются зашифрованной почтой с пользователями Domino Web Access 6.x и для этих пользователей были выпущены сертификаты x.509. В режиме offline данный параметр не поддерживается.
В вопросе безопасности Domino Web Access с клиентской стороны существует ряд факторов, сходных с теми, которые имеются в стандартном клиенте Notes. В дополнение к приведенному выше обсуждению выхода из системы заметим, что физическая безопасность машины является очень важным фактором (не оставляйте без присмотра браузер, подключенный к серверу; заблокируйте его замком Кенсингтона или другим сходным устройством). Шифруйте локальные (офлайновые) базы данных и создавайте документы политики offline-безопасности Domino.
Наконец, мы должны обсудить вопрос об обязанностях по соблюдению мер безопасности, связанных с использованием браузера в качестве клиента. Когда пользователи применяют браузерные технологии в качестве основного метода взаимодействия с сервером, существует повышенная опасность попасть под действие злонамеренных программ в виде скриптов JavaScript, агентов Java, элементов управления ActiveX $$\text{\textregistered}$$ и т. п. Чтобы пользователи не запускали такой код, в Domino Web Access по умолчанию применяется фильтр активного содержимого (Active Content Filter), который обрабатывает HTML-код каждого почтового сообщения и переписывает его, прежде чем он будет отображен в браузере. Это может отрицательно повлиять на производительность сервера, поэтому в файле NOTES.INI есть флаг, который можно при желании отключить.
Чтобы отключить фильтр активного содержимого, установите в файле NOTES.INI следующий параметр
iNotes_WA_DisableActCntSecurity=1
и перезапустите HTTP.
Если установить для этого параметра значение 0, поставить перед ним символ комментария или удалить строку из файла NOTES.INI, фильтр будет снова включен.
Существует ряд отличий в размещении клиентов Notes и Domino Web Access, которые следует принимать во внимание.
На этом заканчивается наш обзор новых возможностей безопасности Domino Web Access. В следующей лекции рассматривается тема, интересная как для пользователей Lotus Notes, так и для пользователей Domino Web Access: новая функциональность, которая поможет победить в борьбе со спамом, т. е. несанкционированными почтовыми рассылками.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.