Опубликован: 04.07.2008 | Доступ: свободный | Студентов: 629 / 31 | Оценка: 4.83 / 5.00 | Длительность: 42:11:00
Лекция 11:

Функции безопасности 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).

Таблица 11.15. Условия правила
Компоненты условия Описание
Исследуемый элемент сообщения Определяет элемент сообщения Notes, исследуемый задачей Router при оценке того, нужно ли применять правило. Надо выбрать один из следующих элементов: Sender (Отправитель), Subject (Тема), Body (Тело сообщения), Importance (Важность), Delivery priority (Приоритет доставки), To (Кому), CC, BCC, To or CC (Кому или CC), Body or subject (Тело сообщения или тема), Internet domain (интернет-домен), Size (in bytes) [Размер (в байтах)], All documents (Все документы), Attachment name (Имя вложения), Number of attachments (Количество вложений), From (От), Recipient count (Количество получателей) или Any recipient (Любой получатель). Выберите All Documents (Все документы), чтобы правило действовало на все сообщения, находящиеся в MAIL.BOX
Логический оператор или квалификатор Определяет способ оценки задачей Router содержимого целевого поля. Например, при выборе элемента сообщения Attachment Name (Имя вложения) квалификатор is (равно) определяет правило, действующее для всех сообщений, содержащих вложенный фал с именем, точно совпадающим с заданным вами именем. Следует выбрать один из следующих квалификаторов:
  • contains (содержит, для текстовых значений);
  • does not contain (не содержит, для текстовых значений);
  • is (равно);
  • is not (не равно);
  • is less than (меньше, для числовых значений);
  • is greater than (больше, для числовых значений).
Значение для проверки элемента сообщения Определяет искомое содержимое в целевом элементе сообщения. Например, если для целевого элемента сообщения Attachment Name (Имя вложения) и квалификатора contains (содержит) ввести ".VBS", будет создано правило, действующее для всех сообщений, имеющих вложенный файл с именем, содержащим текст ".VBS", включая LOVE-LETTER.VBS, CLICK-THIS.VBS.TXT и MY.VBS.CARD.EXE. Текстовые поля не поддерживают подстановочные значения, в частности символ звездочки (*). Чтобы указать строку поиска для целевого поля, используйте оператор contains (содержит) и введите строку поиска в соответствующем текстовом поле. Например, как показано в предыдущем примере, для поиска вложенного файла, имя которого содержит строку ".VBS", следует создать условие "Attachment Name contains .VBS", а не "Attachment Name is *.VBS.".

Текст в строке поиска нечувствителен к регистру.

При указании числовых значений следует всегда вводить число, а не текстовый эквивалент (т. е. 2, а не two)

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

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

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

Таблица 11.16. Действия правил
Имя действия Описание
Journal this message (Журналирование сообщения) Router отправляет копию сообщения в сконфигурированную базу данных журналирования почты и продолжает передачу сообщения получателю. Журналирование должно быть включено в Router/SMTP > Advanced (Дополнительно) > Journaling (Журналирование)
Move to database (Перемещение в базу данных) Router удаляет сообщение из MAIL.BOX и изолирует его в базе данных, указанной в соответствующем текстовом поле, например GRAVEYARD.NSF. Указанная база данных должна уже существовать. Сообщение не передается получателю.

Размещение сообщений в базе данных карантина позволяет более тщательно их изучить на наличие вирусов и прочего нежелательного содержимого

Don't accept message (Не принимать сообщение) Domino отклоняет сообщение, но Router не генерирует отчет о невыполненной доставке. В зависимости от источника сообщения отправитель может получить или не получить NDR или другое сообщение о том, что сообщение не было доставлено.

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

Для сообщений, полученных через маршрутизацию Notes, Domino возвращает отчет о невыполненной доставке, указывающий, что сообщение нарушило правило электронной почты.

Для сообщений, сохраненных клиентом Notes, отправляющий клиент выводит ошибку, указывающую, что сообщение нарушило правило электронной почты

Don't deliver message (Не доставлять сообщение) Domino принимает сообщение, но вместо того, чтобы переслать его получателю, обрабатывает сообщение в соответствии с одной из нижеперечисленных опций: Silently delete (Тихое удаление) – Domino удаляет сообщение из MAIL.BOX без уведомления отправителя или получателя;

Send NDR (Отправка NDR) – Domino генерирует отчет о невыполненной доставке и возвращает его отправителю. Версии сообщений в формате MIME и Notes Richtext, отправленные с клиента Notes, вызывают создание отдельных отчетов о невыполненной доставке

Change routing state (Изменение состояния маршрутизации) Domino принимает сообщение, но не доставляет его. Вместо этого сообщение помечается как удерживаемое путем изменения значения элемента RoutingState в сообщении на HOLD. В результате такого изменения состояния маршрутизации сообщения Router оставляет сообщение в MAIL.BOX на неопределенное время, ожидая административного действия. Domino различает сообщения, удерживаемые правилом электронной почты, и сообщения, удерживаемые как недоставленные.

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

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

Документ 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.17. Опции безопасности DOLS
Опция Описание
Tighten access to the database (Усиление защиты доступа к базе данных) Откройте ACL для subscription и добавьте пользователей и группы, которым вы хотите назначить доступ. Учетная запись Anonymous (Аноним) должна иметь уровень доступа No Access (Нет доступа)
Tighten security on the configuration document (Усиление защиты документа конфигурации) Чтобы установить, кто может открывать и редактировать документ Offline Subscription Configuration Profile для определенной подписки, откройте форму DOLS Offline Configuration (Автономная конфигурация DOLS) для subscription в Lotus Domino Designer 6 и измените параметры безопасности в свойствах формы
Tighten security on offline data (Усиление защиты автономных данных) Чтобы обеспечить невозможность доступа несанкционированных пользователей к данным subscription в автономном режиме с применением другого программного продукта, зашифруйте подписки в документе Offline Subscription Configuration Profile
Tighten security for all subscriptions on the server (Усиление защиты для всех подписок на сервере) Для распространения параметров безопасности на все существующие DOLSsubscriptions на сервере убедитесь в том, что для них не установлено наследование изменений дизайна из шаблона DOLS Resource (DOLRES.NTF); измените параметр в DOLRES.NTF; после этого запустите задачу Designer

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), прежде чем включать для них использование смарт-карт.