Функции безопасности Domino/Notes 6

Правила электронной почты

Новое в Domino 6

Можно создавать правила фильтрации содержимого для сервера, определяющие, какие действия следует выполнять для определенных сообщений. При записи нового сообщения, соответствующего заданному условию, в MAIL.BOX, Domino автоматически выполняет назначенное действие. Условия, используемые в правилах, основаны на содержимом заголовка сообщения или тела сообщения.

Правила электронной почты позволяют бороться со спамом следующими способами:

• путем отказа принимать или доставлять сообщения с оскорбительным содержимым;
• путем записи сообщений с ключевыми фразами в MAIL.BOX;
• путем перемещения сообщений в карантин или базу данных "захоронения";
• путем изменения состояния маршрутизации сообщения;
• путем записи журналирования сообщений.

Например, можно создать правило, отклоняющее почту с такими темами, как "make money fast", или поступающую от известного поставщика спама. Подобным образом можно ограничить получение пользователями вложений, не связанных с функциями пользователей, установив правило перехвата сообщений, содержащих в качестве вложений определенные типы файлов (EXE, VBS, VBE, SCR и т. д.), и их перенаправления в базу данных карантина, где администратор может их просмотреть и, возможно, отправить целевому получателю.

Если это не задано явным образом в правиле, Domino не уведомляет отправителя или получателя о том, что правило не позволяет сообщению достичь целевого адреса. Например, если правило приводит к перенаправлению сообщения в базу данных захоронения, Domino не генерирует отчет о невыполненной доставке и не сообщает целевым получателям о том, что предназначенное для них сообщение было перехвачено. С другой стороны, если сообщение инициирует правило с двойным действием Don't deliver message/Send NDR (Не доставлять сообщение/Отправлять NDR), отправитель получает отчет о невыполненной доставке, сообщающий о том, что сообщение было отклонено в связи с настройками политики.

Примечание. Хотя Domino не генерирует уведомление для отправителя, когда условие правила инициирует действие don't accept message (не принимать сообщение), так как правила выполняются при записи почты в MAIL.BOX, отправитель все же может получить уведомление о том, что сообщение было отклонено. Например, если SMTP-слушатель Domino отклоняет сообщение в связи с правилом электронной почты, отправляющий SMTP-сервер получает ошибку, сообщающую о том, что транзакция была отклонена в связи с настройками политики. Обычно серверы, получающие такие ошибки, генерируют отчет о невыполненной доставке для пользователя-отправителя. Подобным образом, когда правило электронной почты не позволяет серверу получить сообщение, клиент Notes, пытающийся записать сообщение в MAIL.BOX, выводит ошибку, сообщающую о том, что сообщение не может быть отправлено.

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

Управление и настройка правил электронной почты выполняется в вашем документе Messaging Settings. Domino сохраняет правила электронной почты, созданные в документе Configuration Settings. При запуске каждый сервер извлекает правила из соответствующего документа Configuration Settings и регистрирует их как мониторы для каждой используемой базы данных MAIL.BOX.

Когда MAIL.BOX получает новое сообщение из какого-либо источника (SMTP-процесса, Router на другом сервере или клиента, содержащего сообщение), сервер оценивает различные поля сообщения с зарегистрированными правилами электронной почты. Каждое сообщение оценивается только один раз. Дополнительные изменения, происходящие после добавления сообщения в MAIL.BOX (в частности, обновления, отражающие количество получателей), не вызывают повторную оценку правил.

Создание правил электронной почты

Создание правил электронной почты выполняется в разделе Messaging (Сообщения) документа Configuration Settings для серверов, на которых применяются правила. Для каждого правила можно задать критерии, используемые сервером для определения того, следует ли применять правило к заданному сообщению (табл. 11.15).

Можно дополнительно изменить условие:

• Путем добавления дополнительных условий.
• Путем добавления исключения. Можно добавить только одно исключение в условное выражение.

Кроме того, можно определить действие, которое необходимо выполнять при получении сообщения, соответствующего условному выражению, и нажать Add Action (Добавить действие) (табл. 11.16). Можно задавать одно действие для каждого правила.

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

Документ Configuration Settings отображает новые правила электронной почты, только если документ был предварительно сохранен. Перед добавлением правил в новый документ Configuration Settings следует сохранить и закрыть документ. Для добавления правил следует заново открыть документ.

При добавлении нового правила оно вступает в действие только после перезагрузки сервером правил электронной почты. Перезагрузка инициируется автоматически, если задача Server обнаруживает изменение правила при выполнении стандартной проверки документа Configuration Settings. Такая проверка выполняется приблизительно каждые 5 минут.

Можно выполнить принудительную перезагрузку правил сервером, используя консольную команду set rules.

Правила электронной почты и зашифрованные сообщения

Если MAIL.BOX получает зашифрованное сообщение (с использованием шифрования Notes, S/MIME, PGP и т. д.), правила электронной почты сервера обрабатывают все условия правила, основанные на незашифрованной информации в заголовке сообщения (отправитель, важность и получатели), но не обрабатывает условия, основанные на зашифрованной части тела сообщения. Большинство условий правил основаны на информации в заголовке сообщения. Сервер не регистрирует случаи, когда правила не могут обработать сообщение.

Можно также определить, для каких типов сообщений правило инициирует действие, указав тип формы сообщения в условии правила. При определении типа формы сервер выполняет проверку используемой формы сообщения Notes (элемент Form отображается в свойствах документа); он не использует информацию о форме, определенную в элементах сообщения MIME. Все сообщения, хранящиеся в MAIL.BOX, интерпретируются как документы Notes, включая входящие интернет-сообщения в "родном" формате MIME. По умолчанию сообщения, полученные через SMTP, используют форму Memo, за исключением отчетов о невыполненной доставке SMTP, которые Domino интерпретирует с применением формы NonDelivery Report. Существуют следующие основные формы Notes:

• Appointment,
• Delivery Report,
• Memo,
• NonDelivery Report,
• Notice,
• Reply,
• Return Receipt,
• Trace Report.

11.13 Служба Domino Off-Line Services

Новое в Domino 6

Служба Domino Off-Line Services (DOLS) обеспечивает способ перевода Web-приложений IBM Lotus Domino Release 6 в автономный режим, работы в них и синхронизации изменений с подключенной репликой на сервере Domino. Пользователям необязательно применять клиент IBM Lotus Notes 6, так как доступ к приложениям осуществляется через браузер.

При переводе приложения с поддержкой DOLS (называемого subscription – "подписка") в автономный режим сохраняются почти все функциональные возможности Notes. Пользователи могут выполнять создание, редактирование, удаление, сортировку и категоризацию документов Notes, а также выполнять полнотекстовый поиск. DOLS subscriptions могут осуществлять полноценное использование Java-апплетов, выполнения агентов и потоков заданий. DOLS также поддерживает полную репликацию данных, сохраняет логику приложений и поддерживает полную модель безопас- ности Notes.

Защита DOLS

Для назначения различных политик идентификаторов для пользователей из разных доменов следует использовать документы Offline Security Policy. Например, можно генерировать идентификаторы автоматически для пользователей внутри компании, но требовать, чтобы пользователи из домена за пределами компании предоставляли идентификаторы, которые вы им дали.

Создание документа Offline Security Policy осуществляется в представлении Offline Services в разделе Configuration (Конфигурирование) инструмента Domino Administrator. Раздел Security (Безопасность) содержит следующие опции увеличения безопасности для DOLS subscriptions (табл. 11.17).

11.14 Безопасность клиента Notes

Новое в Domino 6

Функции безопасности Notes позволяют пользователям защищать свою рабочую область и данные. Начиная с Notes 6 большинство функций безопасности, реализованных в Notes, были объединены в одном диалоговом окне с названием User Security (Безопасность пользователя). До Notes 6 пользователи осуществляли доступ к этим функциям через опции меню или через предпочтения пользователей или почты. Диалоговое окно User Security (Безопасность пользователя) дает возможность пользователям:

• осуществлять синхронизацию своего пароля Notes с паролями Windows или Web/интернет-паролями Domino;
• отключить запрос пароля Notes в других программах на основе Notes, а также проверять или запрашивать изменения в своих параметрах пароля;
• восстанавливать идентификаторы пользователей;
• устанавливать и использовать устройство для чтения смарт-карт, что позволяет применять смарт-карты для входа в Notes и сохранения закрытых интернетключей;
• запрашивать сертификаты Notes и интернет-сертификаты;
• использовать сертификаты Notes и интернет-сертификаты для шифрования почты и применять цифровые подписи для подписания почты;
• настроить Notes на локальное шифрование всех новых реплик создаваемых баз данных; осуществлять шифрование документов секретными ключами, чтобы только те люди, которым пользователи отправляют ключ, могли прочесть эти документы;
• установить ограничения активного содержимого, для которого разрешается выполнение на рабочей станции.

Дополнительные сведения об изменении параметров безопасности клиента пользователями через диалоговое окно User Security (Безопасность пользователя) см. в справке Notes 6 Client Help.

Администраторам следует помнить о том, что через это диалоговое окно пользователи могут обойти административные параметры безопасности. Например, пользователи могут:

• Отключить синхронизацию паролей Notes и интернет-паролей, даже если администратор включил ее в документ Person пользователя или через политику параметров безопасности.

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

  Дополнительные сведения о синхронизации паролей Notes и интернет-паролей см. в разделе 11.7, "Синхронизация интернет-паролей и паролей Notes".
• Установить устройство чтения смарт-карт.

  Важно! Крайне важно, чтобы администраторы знали обо всех установках смарт-карт, так как перед установкой устройства чтения смарт-карт необходимо отключить параметры проверки паролей, интервалы изменения/отсрочки и срок действия пароля в документе Person пользователя смарт-карты. В противном случае эти пользователи будут заблокированы и не смогут подключиться к своему домашнему серверу.
• Изменить параметры ECL.

  Оповещения безопасности выполнения (Execution Security Alerts, ESA) часто раздражают пользователей, и поэтому пользователи обычно выбирают простой путь и открывают доступ для активного содержимого, генерирующего оповещения безопасности выполнения. ECL на рабочих станциях могут быстро стать общедоступными. Рекомендуется регулярно обновлять ECL рабочей станции или, в идеале, отключить возможность внесения изменений конечными пользователями.

11.14.1 Смарт-карты

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

Сведения о настройке устройств для чтения смарт-карт пользователями с применением клиента Notes см. в справке Notes 6 Client Help.

Сведения о защите серверной консоли с использованием устройства для чтения смарт-карт см. в руководстве Domino 6 Administration Guide.

Требования для эффективного использования смарт-карт

• Перед установкой устройства чтения смарт-карт необходимо отключить параметры проверки паролей, интервалы изменения/отсрочки и срок действия пароля в документе Person пользователя смарт-карты. В противном случае эти пользователи будут заблокированы и не смогут подключиться к своему домашнему серверу.
• Убедитесь в том, что идентификаторы пользователей подлежат восстановлению с применением средства восстановления ID-файлов (ID File Recovery), прежде чем включать для них использование смарт-карт.