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

Anonymous (Аноним)

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

Анонимный доступ обычно используется в базах данных, расположенных на общедоступных серверах. Вы можете контролировать уровень доступа к базе данных, назначаемый анонимному пользователю или серверу, введя имя Anonymous (Аноним) в таблицу управления доступом и назначив соответствующий уровень доступа. Обычно анонимным пользователям назначается уровень доступа Reader (Читатель) к базе данных.

Табл. 11.11 описывает различные варианты доступа к базе данных для анонимного пользователя.

Анонимным пользователям [как тем, для которых назначен доступ к базе данных через запись Anonymous (Аноним), так и тем, которые осуществляют доступ через запись -Default-], пытающимся выполнить некоторые действия в базе данных, не разрешенные их уровнем доступа, будет предложено пройти аутентификацию. Например, если для записи Anonymous (Аноним) установлен уровень доступа Reader (Читатель) и анонимный пользователь попытается создать новый документ, ему будет предложено пройти аутентификацию по имени и паролю.

Замечание. Если требуется, чтобы все пользователи проходили аутентификацию в базе данных, убедитесь в том, что ACL содержит запись Anonymous (Аноним) с уровнем доступа No Access (Нет доступа), а также что не включены разрешения Read Public Documents (Чтение открытых документов) и Write Public Documents (Запись открытых документов). Затем следует добавить имя интернет-пользователя в ACL с требуемым уровнем доступа.

Сервер Domino использует имя группы Anonymous (Аноним) исключительно при проверках управления доступом. Например, если запись Anonymous (Аноним) имеет уровень доступа Author (Автор) в ACL базы данных, в поле Authors (Авторы) этого документа будет выводиться действительное имя пользователя. Сервер Domino может отображать только действительные имена анонимных пользователей Notes, но не имена анонимных интернет-пользователей в поле Authors (Авторы) документа. Поле Authors (Авторы) не является средством безопасности, вне зависимости от того, применяется ли анонимный доступ; если в целях безопасности требуется достоверность имени автора, то документ следует подписать.

Идентификаторы реплик

Для того чтобы агент в одной базе данных мог использовать @DbColumn или @DbLookup для извлечения данных из другой базы данных, следует ввести идентификатор реплики базы данных, содержащей агент, в ACL базы данных, содержащей извлекаемые данные. База данных, содержащая агент, должна иметь как минимум уровень доступа Reader (Читатель) к базе данных, содержащей извлекаемые данные. Обе базы данных должны находиться на одном сервере. Пример идентификатора реплики в ACL базы данных имеет следующий вид: 85255B42:005A8fA4. При вводе идентификатора реплики можно использовать символы как верхнего, так и нижнего регистра, но не заключать их в кавычки.

Если вы не добавляете идентификатор реплики в таблицу управления доступом, другая база данных все еще может осуществлять извлечение данных, если для записи -Default- в базе данных установлен уровень доступа Reader (Читатель) или выше.

Порядок оценки записей ACL

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

• ACL сначала проверяет имя пользователя на соответствие явно заданной записи в ACL. ACL проверяет все совпадающие имена пользователей. Например, Sandra E Smith/West/Acme соответствует записям Sandra E Smith/West/Acme/US и Sandra E Smith. В случае, если две разные записи пользователя имеют различные уровни доступа (например, установленные в разное время разными администраторами), пользователю, пытающемуся получить доступ к базе данных, будет назначен более высокий уровень доступа, а также сочетание привилегий доступа по обеим записям для этого пользователя в ACL. Такое может произойти также в том случае, если пользователь имеет альтернативные имена.

  Примечание. Если в ACL введено только общее имя (например, Sandra E Smith ), то совпадение этой записи происходит, только если имя пользователя и сервер базы данных находятся в одной доменной иерархии. Например, если пользователь Sandra E Smith имеет иерархическое имя Sandra E Smith/West/Acme и сервер базы данных имеет имя Manufacturing/FactoryCo, то запись Sandra E Smith не получит корректный уровень доступа для ACL на сервере Manufacturing/FactoryCo. Для того чтобы пользователь мог получить надлежащий уровень доступа к ACL на серверах в других доменах, ввод имени следует осуществлять в полном иерархическом формате.
• Если не найдено соответствий по имени пользователя, ACL проверяет наличие соответствий по записи имени группы. Если пользователь, пытающийся получить доступ к базе данных, соответствует нескольким группам (например, если он является участником группы Sales, а группе Sales соответствует две записи, например Acme Sales и Sales Managers ), то ему назначается наивысший уровень доступа, а также сочетание привилегий доступа по этим записям для группы в ACL.

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

Журнал ACL

Вы можете вывести журнал всех изменений, внесенных в ACL базы данных. Каждая запись в списке показывает, когда произошло изменение, кто сделал изменение и что было изменено. В журнале сохраняется только 20 строк изменений, а не вся история. Только пользователи с уровнем доступа Manager (Менеджер) в ACL могут просматривать журнал ACL.

Примечание. При включении ACL для расширенного доступа (Extended Access) ограничение в 20 строк снимается. Журнал также включает больше информации об изменениях в расширенном доступе.

Максимальный интернет-доступ с использованием имени и пароля

Пользователи, осуществляющие доступ к базе данных через браузер Интернета или интрасети, не могут быть идентифицированы в Notes таким же способом, как и пользователи Notes. Следует применять параметр Maximum Internet name & password access (Максимальный интернет-доступ с использованием имени и пароля) для осуществления контроля над максимальным типом доступа к базе данных через браузер Интернета или интрасети. Список содержит стандартные уровни доступа для пользователей Notes.

Эта опция относится к пользователям, применяющим аутентификацию по имени и паролю или осуществляющим анонимный доступ к серверу через Интернет и подключающимся к серверам через TCP/IP-порт или через SSL-порт. Данная опция не относится к пользователям с идентификаторами SSL-сертификата клиента, осуществляющим доступ к базе данных через Интернет по SSL-порту. Пользователям с клиентским SSL-доступом назначается уровень доступа, определенный в ACL базы данных.

Следует добавить запись для группы Anonymous (Аноним) в ACL базы данных, если это подходит для этой базы данных. Затем следует выбрать максимальный уровень доступа к определенной базе данных, который требуется назначить всем пользователям Интернета и интрасети, применяющим аутентификацию по имени и паролю. Пользователи, осуществляющие доступ к базе данных Notes через Интернет либо анонимно, либо посредством аутентификации по имени и паролю, никогда не будут иметь более высокий уровень доступа, чем определенный параметром Maximum Internet name & password access (Максимальный интернет-доступ с использованием имени и пароля).

Важно! "Максимальный" уровень доступа замещает уровень доступа, явным образом заданный пользователю в ACL базы данных, но только для применения более низкого из двух уровней доступа.

Например, пользователь Sandra Smith/West/Sales/Acme может получить доступ к серверу через Web-браузер с применением имени и пароля. Если пользователю Sandra Smith/West/Sales/Acme в ACL назначен уровень доступа Editor (Редактор), а в параметре Maximum Internet name & password access (Максимальный интернетдоступ с использованием имени и пароля) установлен уровень доступа Reader (Читатель), применяется более низкий из двух уровней доступа и пользователю Sandra разрешается доступ на уровне Reader (Читатель). Подобным же образом, если пользователю Sandra Smith/West/Sales/Acme в ACL назначен уровень доступа Reader (Читатель), а в параметре "максимального" уровня доступа установлен уровень доступа Editor (Редактор), пользователю Sandra разрешается доступ на уровне Reader (Читатель). Однако если пользователь Sandra Smith также применяет клиент Notes для доступа к базе данных, параметр "максимального" уровня доступа игнорируется и пользователю Sandra разрешается доступ на уровне Editor (Редактор).

По умолчанию для этой опции установлен доступ на уровне Editor (Редактор). Такие задачи, как создание папок, представлений и агентов, неприменимы для интернет-пользователей.

Замечание! Этот параметр можно использовать, чтобы не допустить доступ интернетпользователей к базе данных с применением аутентификации по имени и паролю. Если установить уровень доступа No Access (Нет доступа), база данных будет доступна только для пользователей Notes или интернет-пользователей, осуществляющих аутентификацию с применением SSL-сертификатов клиента.

Фактический доступ

Новое в Domino 6

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

Список Effective Access (Фактический доступ) в локальной реплике базы данных может отличаться от списка Effective Access (Фактический доступ) в реплике на сервере. Вы можете не иметь такой же уровень доступа к Domino Directory для чтения групп при работе в локальных репликах.

Для определения фактического доступа пользователя, группы или сервера к базе данных следует выделить соответствующую запись в ACL базы данных и выбрать Effective Access (Фактический доступ). Откроется диалоговое окно, которое показывает:

• фактический уровень доступа к базе данных для выделенного имени, определенный в ACL базы данных.
• права доступа для выделенного имени.
• все записи имен пользователей и групп и роли, которые могут управлять уровнем доступа к документам в базе данных для выделенного имени.
• выполняется ли проверка списка Full Access Administrators (Администраторы с полным доступом), если пользователь, сервер или группа имеют полные права администрирования базы данных.

На данном этапе можно определить уровень доступа других пользователей, выделив новое имя в поле Names (Имена) и выбрав Calculate Access (Определить уровень доступа).

Важно! Пользователь также может получить доступ к базе данных, запустив агент с привилегией Unrestricted with Full Access (Неограниченный полный доступ), даже если его имя не указано в ACL базы данных. Такая привилегия существует, но не отражается в списке Effective Access (Фактический доступ), так как она обходит ACL и списки читателей. Например, администратору может потребоваться запустить агент такого типа для базы данных, к которой у него нет доступа, для обновления полнотекстового индекса этой базы данных.

"Принудительное согласование ACL" и локальная репликация

Новое в Domino 6

До выхода Domino 6 пользователи, выполнявшие локальную репликацию базы данных, в которую не был включен параметр enforce consistent ACL (принудительное согласование ACL), получали полный доступ к базе данных без назначенных ролей. В результате пользователь мог изменять параметры, для которых не выполняется репликация. В R6 при локальной репликации базы данных Domino распространяет параметры доступа пользователя в соответствии со сведениями на сервере и при доступности осуществляет их принудительное применение. Это происходит автоматически для локальной репликации, вне зависимости от того, включен ли параметр Enforce a consistent Access Control List (Принудительное согласование таблицы управления доступом). Поведение системы зависит от списка имен, распространяемого при репликации. Изменение не вступает в силу до первой репликации и получения базой данных доступа пользователя с сервера.

Следует отметить, что локальные реплики с включенным параметром Enforce a consistent access control list (Принудительное согласование таблицы управления доступом) пытаются учитывать информацию в ACL и определяют, кому и что разрешается делать. Однако они имеют некоторые ограничения. Одно ограничение состоит в том, что информация о группах генерируется на сервере, а не в локальной реплике. При локальной репликации базы данных информация об участии в группах пользователя, выполняющего репликацию, сохраняется в базе данных для употребления при проверке ACL. При осуществлении доступа к локальной реплике пользователем, отличным от пользователя, выполнившего репликацию, не будет доступна информация об участии в группах для этого пользователя и ACL сможет применять для проверки доступа только личную информацию пользователя, но не информацию об участии в группах.

При включенном параметре Enforce consistent ACLs (Принудительное согласование ACL):

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

При невключенном параметре Enforce consistent ACLs (Принудительное согласование ACL):

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

Защита ACL базы данных

Записи ACL по умолчанию

• Установите для записи -Default- уровень доступа No access (Нет доступа). Пользователи и серверы получают уровень доступа, установленный для записи -Default-, если им не был назначен другой уровень доступа либо индивидуально, либо как участнику группы, либо по записи-шаблону. Назначение для записи -Default- уровня доступа No Access (Нет доступа) ограничивает доступ к базе данных для пользователей и групп, заданных в ACL (нельзя удалить запись -Default- из ACL).
• По умолчанию пользователю, создающему базу данных (с именем пользователясоздателя базы данных), назначается уровень доступа Manager (Менеджер). Прежде чем переводить базу данных в рабочую среду, убедитесь в том, что этот уровень доступа соответствует запланированному уровню доступа для данного пользователя. Обычно создателям баз данных назначается уровень доступа Designer (Дизайнер), чтобы они могли вносить исправления и изменения в приложение.
• При создании новой базы данных для группы LocalDomainServers (Серверы локального домена) по умолчанию задается уровень доступа Manager (Менеджер). Группа LocalDomainServers (Серверы локального домена) содержит серверы из того же домена, что и сервер, на котором хранится база данных, и создается по умолчанию в каждом каталоге Domino Directory. При создании новой базы данных группа LocalDomainServers (Серверы локального домена) имеет уровень доступа Manager (Менеджер). Для осуществления репликации изменений в дизайне базы данных через домен группа должна иметь доступ по меньшей мере на уровне Designer (Дизайнер).

Другие записи ACL

• Для управления изменениями, получаемых базой данных от реплики базы данных, следует добавить имена серверов в ACL. Для обеспечения более высокого уровня безопасности следует использовать полное иерархическое имя сервера (например, Server1/Sales/Acme ), вне зависимости от того, относится ли имя добавляемого сервера к другой иерархической организации по отношению к серверу, содержащему базу данных.
• Выполните назначение типов пользователей для записей ACL базы данных. Например, назначение типа пользователя Person для имени не позволяет неавторизованному пользователю создать документ Group с таким же именем, добавив свое имя в группу и затем осуществляя доступ к базе данных с использованием имени группы.
• Убедитесь в том, что имена уволенных сотрудников удалены из ACL всех баз данных в вашей организации. Процесс adminp делает это автоматически для большинства баз данных. При удалении имени сотрудника из Domino Directory каждый сервер в домене удаляет имя из ACL баз данных, для которых он является сервером администрирования.
• Определите роли ACL, чтобы ограничить доступ к элементам дизайна базы данных или функциям. Например, если вы имеете базу данных информации о новом продукте, вы можете определить роль с названием Designers (Дизайнеры). Если в базе данных есть документы, которые должны быть доступны только для дизайнеров продукта, можно определить соответствующий уровень доступа к документу. Затем этот уровень доступа назначается с применением роли Designer (Дизайнер) пользователям путем назначения им этой роли в ACL.
• Если возможно, добавляйте новые имена в существующие группы в ACL, вместо того чтобы указывать имена по отдельности. Подумайте, следует ли включать новые имена в роли, связанные с базой данных. Если база данных не использует роли, проверьте наличие списков доступа, связанных с формами, представлениями, полями или разделами, и если они есть, подумайте, следует ли включать новые имена в эти списки.
• Никогда не указывайте отдельные идентификаторы для администраторов непосредствнно в ACL рабочих баз данных. Вместо этого используйте группу Administrators (Администраторы). При увольнении администраторов следует удалить их имена из этой группы и добавить имена новых администраторов.

Общая безопасность базы данных

• При принятии решений о дизайне и управлении следует определить уровни доступа к базе данных, прежде чем перевести базу данных в рабочую среду.
• Отраслевые рекомендации для обеспечения максимальной защиты базы данных состоят в том, чтобы использовать процесс Administration Process на сервере для обеспечения актуальности ACL. Administration Process автоматически переименовывает или удаляет группы, серверы, пользователей, личные представления, личные папки и закрытые агенты, после чего обновляет Domino Directory и все ACL базы данных, в которых указан сервер, выполняющий Administration Process в качестве сервера администрирования. Эта программа также обновляет поля Readers (Читатели) и Authors (Авторы) для всех документов в базе данных. Вы можете выбрать сервер администрирования процесса Administration Process в диалоговом окне Access Control List (Таблица управления доступом) для одиночных баз данных или в диалоговом окне Multi-ACL Management (Управление несколькими ACL) для нескольких баз данных.
• Чтобы пользователи с уровнем доступа Depositor (Депозитор) или No Access (Нет доступа) не могли применять операционную систему для копирования базы данных, следует зашифровать базу данных с использованием идентификатора сервера посредством опции локального шифрования. При этом, даже если скопировать базу данных, пользователь, не имеющий доступа к идентификатору сервера, не сможет ее открыть.
• Выберите параметр Enforce a consistent Access Control List (Принудительное согласование таблицы управления доступом) в реплике базы данных, сервер которой имеет уровень доступа Manager (Менеджер) к другим репликам, чтобы сохранять согласованность таблиц управления доступом по всем репликам базы данных на серверах. Однако принудительное согласование таблицы управления доступом не обеспечивает дополнительную безопасность для локальных реплик. Чтобы обеспечить защиту данных в локальных репликах, следует зашифровать базу данных.
• Требуйте, чтобы пользователи осуществляли доступ к базе данных, применяя защищенное SSL-подключение. Secure Sockets Layer (SSL) представляет собой протокол безопасности, обеспечивающий конфиденциальность подключений и аутентификацию задач сервера Domino, выполняющихся через TCP/IP. Вы можете также потребовать SSL-подключение к одной базе данных или ко всем базам данных на сервере.

11.12 Безопасность почты

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

Функции управления входящей почтой, описанные в этой лекции, включают контроль спама с использованием параметров управления ретрансляцией входящих сообщений (inbound relay controls) и фильтры-"черные списки", а также управление почтовой политикой посредством применения параметров управления получением входящих сообщений (inbound recipient controls) и почтовые правила.

Обеспечение целостности сообщений включает защиту передачи сообщения и защиту содержимого сообщения. Чтобы обеспечить безопасную передачу сообщений между клиентами и серверами, почтовый сервер Domino поддерживает аутентификацию по имени и паролю и протокол Secure Sockets Layer для маршрутизации SMTP-почты, IMAP и доступ POP3. Для шифрования и подписания сообщений клиенты Notes могут использовать шифрование Notes с использованием ID-файлов и открытых-закрытых ключей или защиту электронной почты с применением сертификатов X.509. Клиенты электронной почты могут использовать сертификаты X.509. В Notes для внешней почты (через Интернет) используется S/MIME для цифровых подписей, шифрования сообщений и обеспечения целостности сообщений.

Дополнительные сведения об использовании цифровых подписей и S/MIME в почте Notes см. в "Инфраструктуры открытых ключей" .