Пароли находятся на переднем крае непрерывно ведущейся борьбы за безопасность систем. Все-таки человеческий фактор часто является самым слабым звеном в цепи мер и функций, применяемых в системах обеспечения безопасности, поскольку пользователи не слишком хорошо запоминают пароли или у них можно при помощи методов социальной инженерии обманом выманить пароль.
Давно выявив подобные проблемы, связанные с пользовательскими паролями, компания Lotus со временем разработала ряд мер, таких, как изменение знаков в окне входа в Lotus Notes, шкалу качества паролей и методы проверки паролей.
В Notes и Domino 7 компания Lotus расширила возможности политик и параметров политик, добавив в конфигурацию параметров политик безопасности управление паролями.
В данной лекции мы опишем новую опцию, появившуюся в Notes и Domino 7, которая помогает осуществлять контроль и администрировать пароли более эффективно, с повышением общей безопасности инфраструктуры Notes и Domino, и при этом удобную для пользователей.
Мы предложим вам общий обзор того, что представляют собой политики и документы параметров политик и какое развитие они получили в Notes и Domino 7. Затем мы обсудим настраиваемые политики паролей, объясним, как их реализовать и управлять ими, а также расскажем о лучших практических методах и о том, что нельзя сделать с помощью политик.
Поскольку главной темой данной лекции являются политики, давайте рассмотрим, что это такое, чтобы лучше понять новые функции, появившиеся в версии 7.
Не путайте политики Domino с корпоративными политиками безопасности. Это две совершенно разные вещи.
Корпоративная политика безопасности - это набор инструкций и стандартов, используемых в организации для создания и проведения в жизнь практических способов обеспечения безопасности данных.
Политики Domino позволяют администраторам управлять ключевыми аспектами инфраструктуры Notes и Domino, а именно тем, как пользователи работают с Notes.
По сути, политика - это документ, в котором собран набор отдельных документов параметров политик. Как показано на рис. 2.1, документы параметров политик охватывают 6 областей администрирования: параметры регистрации, параметры установки, параметры рабочего стола, параметры почты, параметры архивирования почты и параметры безопасности.
(рис 2.1) Документы политик и параметров политикЭти области лучше всего описать следующим образом:
В каждом из этих документов параметров политик определяется набор значений по умолчанию, которые применяются к тем пользователям и группам, которым назначается политика. После того как политика установлена, администраторы легко могут изменить любой параметр и он автоматически будет изменен для всех пользователей, к которым данная политика применяется.
Существует 2 типа политик: организационные и явные. Важно понимать различие между этими типами, в противном случае вы будете реализовывать эти политики неправильно. Кроме того, существуют исключения, применимые к этим политикам.
Организационная политика автоматически применяется ко всем пользователям, зарегистрированным в определенном подразделении организации. Например, если администратор хочет создать параметры по умолчанию, распространяющиеся на всех пользователей в компании (фиктивной) ITSO Acme, относящихся к подразделению Sales/Acme, администратор должен просто создать организационную политику с именем */Sales/Acme. Если после этого данный администратор будет применять сертификационный ID Sales/Acme для регистрации пользователя, этот пользователь автоматически получит все параметры из соответствующей организационной политики.
Если пользователь перемещается в пределах иерархической структуры
(например, перейдя из отдела продаж в отдел маркетинга), то ему
автоматически присваивается организационная политика, связанная с
соответствующим сертификационным ID. Например, если администратор
переводит пользователя из Sales/Acme в Marketing/ Acme, то данному
пользователю назначаются все параметры, определенные в документах
параметров рабочего стола, архивирования и безопасности, связанных с
организационной политикой */Marketing/Acme. Новые параметры политики
вступают в действие при первой аутентификации пользователя на домашнем
Явные политики присваивают параметры по умолчанию конкретным пользователям и группам. Например, чтобы определить 6-месячный период действия сертификата для сотрудников по контракту во всех подразделениях, администратор просто создает явную политику, а затем присваивает ее каждому контрактнику или группе, в которую входят все контрактники.
Существует 3 способа присвоения явной политики: при регистрации пользователя, путем редактирования пользовательского документа Person или путем употребления инструмента Assign Policy.
Администраторы имеют возможность присвоить атрибут-исключение (exception) организационной или явной политике.
Администратор применяет исключения для того, чтобы пользователь мог изменить параметр политики, который иначе принудительно применяется во всей организации. Если создается политика-исключение, то администратор может указывать в ней только те параметры, которые не будут принудительными. Затем, когда политика исключений будет присвоена, пользователи будут освобождены от обязательного применения этих параметров.
Политики исключений являются способом предоставления какому-нибудь сотруднику организации особых возможностей, что может быть связано с его постом или требованиями работы. Например, в политике */Acme есть параметр политики регистрации, который задает размер квоты почтовой базы данных равным 60 Мб. Однако небольшой группе сотрудников Acme необходимо превысить эту квоту. Решением будет создание политики-исключения, которая будет включать только документ параметров политики регистрации, в котором не будет установлено ограничение на размер почтовой базы данных. Если присвоить эту политику пользователям, она заменит собой параметры квоты. Поскольку политики-исключения имеют преимущество перед принудительными политиками, применяйте их осторожно.
На рис. 2.2 показан порядок применения организационных политик, явных политик и исключений, где исключения имеют наивысший приоритет, а организационные политики - самый низкий.
(рис 2.2) Порядок применения организационных политик, явных политик и исключений
Действующая политика для пользователя - это набор производных параметров политик, которые динамически вычисляются во время выполнения.
Значения в полях действующей политики могут определяться многими разными документами параметров политик. Каждый уровень иерархии имеет связанную с ним политику, поэтому для пользователя может существовать комбинация параметров политик, в которую входят значения, установленные на уровне организационного подразделения (organizational unit, OU), и значения, установленные в родительской политике. Разрешение этих параметров, в направлении вверх по иерархии организации, определяет действующую политику для каждого пользователя.
(рис 2.3) Как работают и интерпретируются политикиНаряду с организационными политиками пользователям могут присваиваться явные политики. В данном случае порядок разрешения такой: все параметры организационных политик разрешаются первыми, после чего разрешаются параметры явных политик.
Например, если администратор хочет, чтобы все пользователи применяли одинаковый формат имени в интернет-почте, он должен задать это значение в документе параметров регистрации самой высокоуровневой политики. После того как этот параметр будет установлен, его не нужно будет заново вводить во все политики-потомки. Это значение просто "наследуется" от родительской политики, если установлена опция inherit (наследование). Однако если существует группа пользователей за границей, для которых такой параметр будет создавать проблемы, то администратор может создать явную политику, применяемую только к этой группе. Комбинация явных и организационных политик обеспечивает необходимый уровень контроля и гибкости.
На рис. 2.3 показана схема, объясняющая, как все это работает.
Кроме того, существует 2 инструмента, которые помогут вам определить
действующую политику для каждого пользователя. Инструмент Policy
Viewer показывает иерархию политик и соответствующих документов
параметров, а инструмент Policy
Наследование играет важную роль в определении параметров политик
для пользователя как в организационных, так и в явных политиках. При
помощи
В иерархии политик документы политик создают взаимосвязи, а документы параметров политик определяют значения полей на основе своего местоположения в иерархии. При помощи наследования полей и используя обязательные параметры, администратор контролирует параметры, заданные по умолчанию.
Для организационных политик иерархия определяется автоматически, на основе иерархической структуры организации. Политика */Sales/Acme является потомком политики */Acme. Поскольку явные политики не подчиняются структуре организации, администратор при создании явных политик может создать иерархию на основе структуры имен. Например, администратор может создать политику с именем /Contractors, включающую несколько параметров, которые применяются только к сотрудникам- контрактникам, которых нанимают на срок от 6 месяцев до года. Однако администратору может понадобиться, чтобы работники с коротким контрактом, сроком 1-2 недели, получили только часть этих параметров. Можно создать явную политику-потомок с именем Short term/Contractors.
Итак, теперь мы готовы к обсуждению настраиваемых политик паролей.
Теперь, после того как мы изучили основы политик и параметров политик, давайте снова обратимся к паролям. Новые возможности Notes и Domino 7, относящиеся к паролям, предназначены как для администраторов, так и для конечных пользователей.
Действительно, и тем и другим нужна более совершенная система управления паролями, поскольку пользователи и администраторы в вопросе паролей ведут постоянную борьбу, находясь по разные стороны баррикады.
Пароли иногда оказываются слишком сложными для конечных пользователей. Именно пароли предоставляют пользователям санкционированный доступ к системам и приложениям, таким, как Lotus Notes, одновременно препятствуя несанкционированному доступу к учетным записям, почте и другой конфиденциальной информации. Поэтому большинство пользователей понимают, что пароли — это хорошо. Однако общеизвестно, что пользователи плохо запоминают пароли, им не нравятся плохо запоминающиеся пароли, их раздражает, что в пароле нельзя указать дату своего рождения или имя домашнего животного, и они недовольны тем, что пароль нельзя записать на бумаге и спрятать под клавиатуру. С точки зрения пользователя пароль должен быть маленькой, простой формальностью, не сложнее чем bob, sailing, password или notes.
Пароли могут создавать трудности и для администраторов. Администратор должен обеспечить, чтобы пароль был достаточно сложным, чтобы системы, которые этот пароль защищает (особенно, Lotus Notes, как система обмена сообщениями на предприятии, служащая основой повседневной работы бизнеса), были защищены в достаточной мере. Нужно, чтобы пароль было непросто угадать и чтобы он предотвращал несанкционированный доступ к учетным записям пользователей. Администраторы считают, что пароль должен быть настоящим вызовом для умственных способностей пользователя, преодолевая который он подтверждает свое желание получить доступ к Lotus Notes, вводя такие пароли, как puttingthe*I*innotesID или streampond#river%lake!sea$ocean.
Все это порождает непрерывный поток жалоб как со стороны пользователей, которые считают, что от них требуют запоминать слишком сложные пароли, так и со стороны администраторов, которые прекрасно понимают, на что жалуются пользователи, но не находят ничего лучше, чем сделать пароли еще сложнее.
Проблемы, которые возникают у пользователей с паролями, несомненно, усугубляются тем, что многие организации начинают внедрять корпоративные политики безопасности относительно длины и сложности пароля. Чтобы еще больше усложнить задачу администраторов, в последние законы по защите информации и обеспечению неприкосновенности данных (например, итальянский закон о приватности) были внесены требования по выбору безопасных паролей, которые должны выполняться на уровне организаций.
Нет такого чудесного лекарства, которое сделало бы пользователей счастливыми, заставило бы администраторов ослабить свою позицию относительно паролей и сделало бы систему соответствующей новым нормативам (корпоративным, определяемым службой безопасности, или диктуемым законами). Однако новые возможности Domino 7 обещают как минимум упростить управление паролями в Notes.
А именно была добавлена настаиваемая политика паролей, помогающая администраторам конфигурировать и обеспечивать использование конкретных параметров паролей, чтобы выбираемые пароли были безопасными. Как минимум эти политики обеспечивают невысокую предсказуемость паролей, что в любом случае будет хорошим методом обеспечения безопасности. Как максимум их можно использовать для того, чтобы организация могла обеспечить выполнение требований к паролям на основе почти любого набора корпоративных или регулируемых законом набора правил и, возможно, для того, чтобы найти такие пароли, которые окажутся золотой серединой для всех вовлеченных в это сторон.
Настраиваемые политики паролей создаются и применяются с использованием документа параметров политики безопасности. При помощи настраиваемой политики паролей администраторы могут разрешать, ограничивать или запрещать использование в паролях следующих элементов:
В настраиваемой политике паролей администраторы также могут потребовать, чтобы пользователи изменяли свой пароль после первого использования.
Другим огромным преимуществом настраиваемых политик паролей является возможность устанавливать разные требования к паролям для разных типов пользователей на основе групп, к которым они принадлежат, их местоположения в дереве организации или их обоснованностью в соответствии с исключениями на основе корпоративных или законодательных требований. Например, финансовой группе необходима очень строгая политика паролей, соответствующая нормативам, введенным государственными организациями для финансовых органов, а группе маркетинга политика, возможно, вообще не нужна.
Наконец, обратите внимание, что некоторые возможности, дающие возможность пользователям Lotus Notes и Domino самостоятельно управлять паролями (например, сроком действия, синхронизацией, периодом отсрочки и историей паролей), существуют в политиках безопасности начиная с Domino 6. Главной целью настраиваемых политик безопасности Domino 7 является определение самого создаваемого пароля, т.е. его надежности, длины и сложности. Тем не менее нужно понимать, что у настраиваемых политик паролей есть ограничения и эти политики:
Настраиваемые политики паролей загружаются в файл Notes ID при первой аутентификации пользователя Lotus Notes на домашнем сервере Domino.
После того как политика сохранена в ID-файле, параметры политики применяются к паролю пользователя в следующий раз, когда пользователь будет входить в систему клиента Notes. Если политика указывает, что пароль должен быть изменен после первого применения, пользователю будет сразу предложено это сделать.
Настраиваемые политики паролей могут применяться при регистрации пользователя или к пользователям и группам, которые уже были зарегистрированы. Обратите внимание, что требование изменить пароль при первом входе в систему применимо только к новым пользователям, к которым политика применяется при регистрации. Если политика применяется к новому пользователю, пользователь сначала должен пройти аутентификацию на сервере и только потом ему будет предложено изменить пароль. Если настраиваемая политика паролей применяется к уже зарегистрированным пользователям, этим пользователям не нужно будет изменять пароль при входе в систему после применения политики.
Когда политика паролей реализована, Domino принудительно обеспечивает ее выполнение. Если пользователь не изменит пароль в соответствии с политикой или закроет окно, в котором ему предлагается изменить пароль, он получит сообщение об ошибке, в котором будет сказано, что пароль не соответствует требованиям политики, после чего клиент Notes прекратит работу.
Этому посвящен запрос
Термин "настраиваемая политика паролей" может несколько
вводить в заблуждение. Эта политика сама по себе не является отдельным
документом политики. Это часть формы Security Settings (Параметры
безопасности). Однако поначалу может возникать путаница при попытке
создать и сконфигурировать настраиваемую политику паролей, поскольку
закладка
Необычность данной формы в том, что существует субподзакладка
Чтобы увидеть закладку Custom Password Policy (Настраиваемая политика паролей), измените значение в поле Use Custom Password Policy for Notes Clients (Использовать настраиваемую политику паролей для клиентов Notes) с No на Yes. Такое действие вызовет динамический ответ, и после изменения значения в поле на Yes (рис. 2.5) закладка появится, а если изменить значение снова на No, опять исчезнет.
На закладке Custom Password Policy (Настраиваемая политика паролей) находятся параметры настраиваемых политик паролей, показанные на рис. 2.6.
(рис 2.5) Форма Security Settings (Параметры безопасности), закладка Password Management (Управление паролями)(рис 2.4) Форма Security Settings (Параметры безопасности), субподзакладка Custom Password Policy (Настраиваемая политика паролей)
(рис 2.6) Форма Security Settings (Параметры безопасности), параметры на закладке Custom Password Policy (Настраиваемая политика паролей) Теперь, когда мы знаем, где в Domino Directory найти эти параметры, давайте рассмотрим их более детально.
Для конфигурирования настраиваемой политики паролей заполните все или часть этих параметров. Снова отметим важность того, чтобы требования имели смысл. Например, если указать максимальную длину пароля 4, это значение будет несовместимо с минимальным качеством пароля 15.
Ниже дается детальное описание всех параметров на закладке Custom Password Policy (Настраиваемая политика паролей) формы Security Settings (Параметры безопасности).
| Качество пароля | Пароль | Качество пароля | Пароль |
|---|---|---|---|
| 3 | dog | 9 | one2 1two |
| password | onetwothree | ||
| pwd | 10 | pAssw0rd | |
| 2d4 | pwd46dwp | ||
| 4 | 5786 | 11 | winD39_BP |
| atof | the way we were | ||
| r2d2 | 12 | PwD46dWp | |
| 5 | d0gs | rtyughjkbnml | |
| doGs | GoneWithTheWind | ||
| scAle | 13 | Gone With The Wind | |
| 6 | sCa1e | 4891spyONu | |
| dogcat | 14 | tree |
|
| pw46wp | thedogisontheporch | ||
| 7 | cat7dog | 15 | thecathidesunderthebed |
| catSrOK | tdiotptchutb | ||
| 8 | tyughvbn | 16 | thecowjumpedoverthemoon |
| one21two | thedishranawaywiththespoon | ||
| rt7uj | stream8pond1river7lake2oceanz |
Поскольку все это несколько сложно, мы проиллюстрируем использование настраиваемой политики паролей парой примеров.
В этих примерах упоминаются две фиктивные корпорации: ITSO Acme Corporation и ITSO Widget Corporation. Эти две компании имеют разные мнения о том, какие пароли пользователи должны вводить в ходе процесса аутентификации.
Компания Acme придерживается либерального подхода к паролям, и ею была реализована настраиваемая политика паролей со следующими параметрами (рис. 2.7):
(рис 2.7) Пример настраиваемой политики паролейТребования к управлению паролями включают следующие параметры (рис. 2.8):
(рис 2.8) Детали настраиваемой политики паролей
ITSO Widget Corporation более строго подходит к паролям, и ею была реализована настраиваемая политика паролей со следующими параметрами (рис. 2.9):
(рис 2.9) Пример настраиваемой политики паролейТребования к управлению паролями включают следующие параметры (рис. 2.10):
(рис 2.10) Детали настраиваемой политики паролейДанная лекция будет неполной, если не упомянуть о параметрах управления паролями, не зависящих от настраиваемых политик паролей. Эти параметры можно конфигурировать в политике безопасности, не реализуя настраиваемую политику паролей.
В Domino 7 появилось 2 новых параметра политики безопасности, позволяющие администраторам осуществлять тонкую настройку срока действия пароля: Warning Period (Время вывода предупреждения) и Custom Warning Message (Собственное предупреждение).
Параметр Warning Period (Время вывода предупреждения) позволяет администратору указать срок перед окончанием действия пароля, когда пользователь получает предупреждающее сообщение (т. е. "Время действия вашего пароля истекает через 10 дней"). По умолчанию значение этого параметра равно нулю, и это значит, что пользователи не получают никаких предупреждений до момента окончания действия пароля. Однако если срок действия пароля ограничен, а значение интервала смены пароля (количество дней действия пароля, по истечении которого его нужно будет сменить) менее 30 дней, значение в этом поле вычисляется автоматически как две трети интервала смены пароля. Если значение вычисляется, изменить его нельзя.
Теперь администраторы также могут указывать значение Custom Warning Message (Собственное предупреждение) в качестве предупреждения пользователям, для паролей которых подошел срок, указанный в поле Warning Period (Время вывода предупреждения). До Domino 7 пользователи получали только стандартное сообщение об ошибке.
Параметр Custom Warning Message (Собственное предупреждение) предназначен только для клиентов Notes, независимо от того, задан ли срок действия пароля для паролей Notes и Интернета или только для интернет-паролей. Пользователи Интернета не получают предупреждающего сообщения.
В IBM Workplace Collaboration Services 2.6 Managed Client имеется опция, позволяющая применять плагин Notes, при помощи которого пользователи IBM Workplace могут обращаться к базам данных и приложениям Notes. Администраторы Domino могут активировать эту возможность в документе параметров безопасности, чтобы клиент Workplace "запомнил" пароль Notes и этот пароль не приходилось многократно вводить при обращении к Notes-приложениям.
Этот параметр можно конфигурировать только при помощи документа параметров политики безопасности. Более того, этот параметр не является обязательным. Пользователи Workplace не обязаны применять эту возможность. Они включают эту опцию при первой попытке обратиться к Notes, когда видят окно Notes User Security (Безопасность пользователя Notes).
На этом заканчивается наш обзор новых возможностей системы безопасности, которые предоставляют настраиваемые политики паролей. В следующей лекции рассматривается восстановление ID.
Пароли находятся на переднем крае непрерывно ведущейся борьбы за безопасность систем. Все-таки человеческий фактор часто является самым слабым звеном в цепи мер и функций, применяемых в системах обеспечения безопасности, поскольку пользователи не слишком хорошо запоминают пароли или у них можно при помощи методов социальной инженерии обманом выманить пароль.
Давно выявив подобные проблемы, связанные с пользовательскими паролями, компания Lotus со временем разработала ряд мер, таких, как изменение знаков в окне входа в Lotus Notes, шкалу качества паролей и методы проверки паролей.
В Notes и Domino 7 компания Lotus расширила возможности политик и параметров политик, добавив в конфигурацию параметров политик безопасности управление паролями.
В данной лекции мы опишем новую опцию, появившуюся в Notes и Domino 7, которая помогает осуществлять контроль и администрировать пароли более эффективно, с повышением общей безопасности инфраструктуры Notes и Domino, и при этом удобную для пользователей.
Мы предложим вам общий обзор того, что представляют собой политики и документы параметров политик и какое развитие они получили в Notes и Domino 7. Затем мы обсудим настраиваемые политики паролей, объясним, как их реализовать и управлять ими, а также расскажем о лучших практических методах и о том, что нельзя сделать с помощью политик.
Поскольку главной темой данной лекции являются политики, давайте рассмотрим, что это такое, чтобы лучше понять новые функции, появившиеся в версии 7.
Не путайте политики Domino с корпоративными политиками безопасности. Это две совершенно разные вещи.
Корпоративная политика безопасности - это набор инструкций и стандартов, используемых в организации для создания и проведения в жизнь практических способов обеспечения безопасности данных.
Политики Domino позволяют администраторам управлять ключевыми аспектами инфраструктуры Notes и Domino, а именно тем, как пользователи работают с Notes.
По сути, политика - это документ, в котором собран набор отдельных документов параметров политик. Как показано на рис. 2.1, документы параметров политик охватывают 6 областей администрирования: параметры регистрации, параметры установки, параметры рабочего стола, параметры почты, параметры архивирования почты и параметры безопасности.
(рис 2.1) Документы политик и параметров политикЭти области лучше всего описать следующим образом:
В каждом из этих документов параметров политик определяется набор значений по умолчанию, которые применяются к тем пользователям и группам, которым назначается политика. После того как политика установлена, администраторы легко могут изменить любой параметр и он автоматически будет изменен для всех пользователей, к которым данная политика применяется.
Существует 2 типа политик: организационные и явные. Важно понимать различие между этими типами, в противном случае вы будете реализовывать эти политики неправильно. Кроме того, существуют исключения, применимые к этим политикам.
Организационная политика автоматически применяется ко всем пользователям, зарегистрированным в определенном подразделении организации. Например, если администратор хочет создать параметры по умолчанию, распространяющиеся на всех пользователей в компании (фиктивной) ITSO Acme, относящихся к подразделению Sales/Acme, администратор должен просто создать организационную политику с именем */Sales/Acme. Если после этого данный администратор будет применять сертификационный ID Sales/Acme для регистрации пользователя, этот пользователь автоматически получит все параметры из соответствующей организационной политики.
Если пользователь перемещается в пределах иерархической структуры
(например, перейдя из отдела продаж в отдел маркетинга), то ему
автоматически присваивается организационная политика, связанная с
соответствующим сертификационным ID. Например, если администратор
переводит пользователя из Sales/Acme в Marketing/ Acme, то данному
пользователю назначаются все параметры, определенные в документах
параметров рабочего стола, архивирования и безопасности, связанных с
организационной политикой */Marketing/Acme. Новые параметры политики
вступают в действие при первой аутентификации пользователя на домашнем
Явные политики присваивают параметры по умолчанию конкретным пользователям и группам. Например, чтобы определить 6-месячный период действия сертификата для сотрудников по контракту во всех подразделениях, администратор просто создает явную политику, а затем присваивает ее каждому контрактнику или группе, в которую входят все контрактники.
Существует 3 способа присвоения явной политики: при регистрации пользователя, путем редактирования пользовательского документа Person или путем употребления инструмента Assign Policy.
Администраторы имеют возможность присвоить атрибут-исключение (exception) организационной или явной политике.
Администратор применяет исключения для того, чтобы пользователь мог изменить параметр политики, который иначе принудительно применяется во всей организации. Если создается политика-исключение, то администратор может указывать в ней только те параметры, которые не будут принудительными. Затем, когда политика исключений будет присвоена, пользователи будут освобождены от обязательного применения этих параметров.
Политики исключений являются способом предоставления какому-нибудь сотруднику организации особых возможностей, что может быть связано с его постом или требованиями работы. Например, в политике */Acme есть параметр политики регистрации, который задает размер квоты почтовой базы данных равным 60 Мб. Однако небольшой группе сотрудников Acme необходимо превысить эту квоту. Решением будет создание политики-исключения, которая будет включать только документ параметров политики регистрации, в котором не будет установлено ограничение на размер почтовой базы данных. Если присвоить эту политику пользователям, она заменит собой параметры квоты. Поскольку политики-исключения имеют преимущество перед принудительными политиками, применяйте их осторожно.
На рис. 2.2 показан порядок применения организационных политик, явных политик и исключений, где исключения имеют наивысший приоритет, а организационные политики - самый низкий.
(рис 2.2) Порядок применения организационных политик, явных политик и исключений
Действующая политика для пользователя - это набор производных параметров политик, которые динамически вычисляются во время выполнения.
Значения в полях действующей политики могут определяться многими разными документами параметров политик. Каждый уровень иерархии имеет связанную с ним политику, поэтому для пользователя может существовать комбинация параметров политик, в которую входят значения, установленные на уровне организационного подразделения (organizational unit, OU), и значения, установленные в родительской политике. Разрешение этих параметров, в направлении вверх по иерархии организации, определяет действующую политику для каждого пользователя.
(рис 2.3) Как работают и интерпретируются политикиНаряду с организационными политиками пользователям могут присваиваться явные политики. В данном случае порядок разрешения такой: все параметры организационных политик разрешаются первыми, после чего разрешаются параметры явных политик.
Например, если администратор хочет, чтобы все пользователи применяли одинаковый формат имени в интернет-почте, он должен задать это значение в документе параметров регистрации самой высокоуровневой политики. После того как этот параметр будет установлен, его не нужно будет заново вводить во все политики-потомки. Это значение просто "наследуется" от родительской политики, если установлена опция inherit (наследование). Однако если существует группа пользователей за границей, для которых такой параметр будет создавать проблемы, то администратор может создать явную политику, применяемую только к этой группе. Комбинация явных и организационных политик обеспечивает необходимый уровень контроля и гибкости.
На рис. 2.3 показана схема, объясняющая, как все это работает.
Кроме того, существует 2 инструмента, которые помогут вам определить
действующую политику для каждого пользователя. Инструмент Policy
Viewer показывает иерархию политик и соответствующих документов
параметров, а инструмент Policy
Наследование играет важную роль в определении параметров политик
для пользователя как в организационных, так и в явных политиках. При
помощи
В иерархии политик документы политик создают взаимосвязи, а документы параметров политик определяют значения полей на основе своего местоположения в иерархии. При помощи наследования полей и используя обязательные параметры, администратор контролирует параметры, заданные по умолчанию.
Для организационных политик иерархия определяется автоматически, на основе иерархической структуры организации. Политика */Sales/Acme является потомком политики */Acme. Поскольку явные политики не подчиняются структуре организации, администратор при создании явных политик может создать иерархию на основе структуры имен. Например, администратор может создать политику с именем /Contractors, включающую несколько параметров, которые применяются только к сотрудникам- контрактникам, которых нанимают на срок от 6 месяцев до года. Однако администратору может понадобиться, чтобы работники с коротким контрактом, сроком 1-2 недели, получили только часть этих параметров. Можно создать явную политику-потомок с именем Short term/Contractors.
Итак, теперь мы готовы к обсуждению настраиваемых политик паролей.
Теперь, после того как мы изучили основы политик и параметров политик, давайте снова обратимся к паролям. Новые возможности Notes и Domino 7, относящиеся к паролям, предназначены как для администраторов, так и для конечных пользователей.
Действительно, и тем и другим нужна более совершенная система управления паролями, поскольку пользователи и администраторы в вопросе паролей ведут постоянную борьбу, находясь по разные стороны баррикады.
Пароли иногда оказываются слишком сложными для конечных пользователей. Именно пароли предоставляют пользователям санкционированный доступ к системам и приложениям, таким, как Lotus Notes, одновременно препятствуя несанкционированному доступу к учетным записям, почте и другой конфиденциальной информации. Поэтому большинство пользователей понимают, что пароли — это хорошо. Однако общеизвестно, что пользователи плохо запоминают пароли, им не нравятся плохо запоминающиеся пароли, их раздражает, что в пароле нельзя указать дату своего рождения или имя домашнего животного, и они недовольны тем, что пароль нельзя записать на бумаге и спрятать под клавиатуру. С точки зрения пользователя пароль должен быть маленькой, простой формальностью, не сложнее чем bob, sailing, password или notes.
Пароли могут создавать трудности и для администраторов. Администратор должен обеспечить, чтобы пароль был достаточно сложным, чтобы системы, которые этот пароль защищает (особенно, Lotus Notes, как система обмена сообщениями на предприятии, служащая основой повседневной работы бизнеса), были защищены в достаточной мере. Нужно, чтобы пароль было непросто угадать и чтобы он предотвращал несанкционированный доступ к учетным записям пользователей. Администраторы считают, что пароль должен быть настоящим вызовом для умственных способностей пользователя, преодолевая который он подтверждает свое желание получить доступ к Lotus Notes, вводя такие пароли, как puttingthe*I*innotesID или streampond#river%lake!sea$ocean.
Все это порождает непрерывный поток жалоб как со стороны пользователей, которые считают, что от них требуют запоминать слишком сложные пароли, так и со стороны администраторов, которые прекрасно понимают, на что жалуются пользователи, но не находят ничего лучше, чем сделать пароли еще сложнее.
Проблемы, которые возникают у пользователей с паролями, несомненно, усугубляются тем, что многие организации начинают внедрять корпоративные политики безопасности относительно длины и сложности пароля. Чтобы еще больше усложнить задачу администраторов, в последние законы по защите информации и обеспечению неприкосновенности данных (например, итальянский закон о приватности) были внесены требования по выбору безопасных паролей, которые должны выполняться на уровне организаций.
Нет такого чудесного лекарства, которое сделало бы пользователей счастливыми, заставило бы администраторов ослабить свою позицию относительно паролей и сделало бы систему соответствующей новым нормативам (корпоративным, определяемым службой безопасности, или диктуемым законами). Однако новые возможности Domino 7 обещают как минимум упростить управление паролями в Notes.
А именно была добавлена настаиваемая политика паролей, помогающая администраторам конфигурировать и обеспечивать использование конкретных параметров паролей, чтобы выбираемые пароли были безопасными. Как минимум эти политики обеспечивают невысокую предсказуемость паролей, что в любом случае будет хорошим методом обеспечения безопасности. Как максимум их можно использовать для того, чтобы организация могла обеспечить выполнение требований к паролям на основе почти любого набора корпоративных или регулируемых законом набора правил и, возможно, для того, чтобы найти такие пароли, которые окажутся золотой серединой для всех вовлеченных в это сторон.
Настраиваемые политики паролей создаются и применяются с использованием документа параметров политики безопасности. При помощи настраиваемой политики паролей администраторы могут разрешать, ограничивать или запрещать использование в паролях следующих элементов:
В настраиваемой политике паролей администраторы также могут потребовать, чтобы пользователи изменяли свой пароль после первого использования.
Другим огромным преимуществом настраиваемых политик паролей является возможность устанавливать разные требования к паролям для разных типов пользователей на основе групп, к которым они принадлежат, их местоположения в дереве организации или их обоснованностью в соответствии с исключениями на основе корпоративных или законодательных требований. Например, финансовой группе необходима очень строгая политика паролей, соответствующая нормативам, введенным государственными организациями для финансовых органов, а группе маркетинга политика, возможно, вообще не нужна.
Наконец, обратите внимание, что некоторые возможности, дающие возможность пользователям Lotus Notes и Domino самостоятельно управлять паролями (например, сроком действия, синхронизацией, периодом отсрочки и историей паролей), существуют в политиках безопасности начиная с Domino 6. Главной целью настраиваемых политик безопасности Domino 7 является определение самого создаваемого пароля, т.е. его надежности, длины и сложности. Тем не менее нужно понимать, что у настраиваемых политик паролей есть ограничения и эти политики:
Настраиваемые политики паролей загружаются в файл Notes ID при первой аутентификации пользователя Lotus Notes на домашнем сервере Domino.
После того как политика сохранена в ID-файле, параметры политики применяются к паролю пользователя в следующий раз, когда пользователь будет входить в систему клиента Notes. Если политика указывает, что пароль должен быть изменен после первого применения, пользователю будет сразу предложено это сделать.
Настраиваемые политики паролей могут применяться при регистрации пользователя или к пользователям и группам, которые уже были зарегистрированы. Обратите внимание, что требование изменить пароль при первом входе в систему применимо только к новым пользователям, к которым политика применяется при регистрации. Если политика применяется к новому пользователю, пользователь сначала должен пройти аутентификацию на сервере и только потом ему будет предложено изменить пароль. Если настраиваемая политика паролей применяется к уже зарегистрированным пользователям, этим пользователям не нужно будет изменять пароль при входе в систему после применения политики.
Когда политика паролей реализована, Domino принудительно обеспечивает ее выполнение. Если пользователь не изменит пароль в соответствии с политикой или закроет окно, в котором ему предлагается изменить пароль, он получит сообщение об ошибке, в котором будет сказано, что пароль не соответствует требованиям политики, после чего клиент Notes прекратит работу.
Этому посвящен запрос
Термин "настраиваемая политика паролей" может несколько
вводить в заблуждение. Эта политика сама по себе не является отдельным
документом политики. Это часть формы Security Settings (Параметры
безопасности). Однако поначалу может возникать путаница при попытке
создать и сконфигурировать настраиваемую политику паролей, поскольку
закладка
Необычность данной формы в том, что существует субподзакладка
Чтобы увидеть закладку Custom Password Policy (Настраиваемая политика паролей), измените значение в поле Use Custom Password Policy for Notes Clients (Использовать настраиваемую политику паролей для клиентов Notes) с No на Yes. Такое действие вызовет динамический ответ, и после изменения значения в поле на Yes (рис. 2.5) закладка появится, а если изменить значение снова на No, опять исчезнет.
На закладке Custom Password Policy (Настраиваемая политика паролей) находятся параметры настраиваемых политик паролей, показанные на рис. 2.6.
(рис 2.5) Форма Security Settings (Параметры безопасности), закладка Password Management (Управление паролями)(рис 2.4) Форма Security Settings (Параметры безопасности), субподзакладка Custom Password Policy (Настраиваемая политика паролей)(рис 2.6) Форма Security Settings (Параметры безопасности), параметры на закладке Custom Password Policy (Настраиваемая политика паролей)Теперь, когда мы знаем, где в Domino Directory найти эти параметры, давайте рассмотрим их более детально.
Для конфигурирования настраиваемой политики паролей заполните все или часть этих параметров. Снова отметим важность того, чтобы требования имели смысл. Например, если указать максимальную длину пароля 4, это значение будет несовместимо с минимальным качеством пароля 15.
Ниже дается детальное описание всех параметров на закладке Custom Password Policy (Настраиваемая политика паролей) формы Security Settings (Параметры безопасности).
| Качество пароля | Пароль | Качество пароля | Пароль |
|---|---|---|---|
| 3 | dog | 9 | one2 1two |
| password | onetwothree | ||
| pwd | 10 | pAssw0rd | |
| 2d4 | pwd46dwp | ||
| 4 | 5786 | 11 | winD39_BP |
| atof | the way we were | ||
| r2d2 | 12 | PwD46dWp | |
| 5 | d0gs | rtyughjkbnml | |
| doGs | GoneWithTheWind | ||
| scAle | 13 | Gone With The Wind | |
| 6 | sCa1e | 4891spyONu | |
| dogcat | 14 | tree |
|
| pw46wp | thedogisontheporch | ||
| 7 | cat7dog | 15 | thecathidesunderthebed |
| catSrOK | tdiotptchutb | ||
| 8 | tyughvbn | 16 | thecowjumpedoverthemoon |
| one21two | thedishranawaywiththespoon | ||
| rt7uj | stream8pond1river7lake2oceanz |
Поскольку все это несколько сложно, мы проиллюстрируем использование настраиваемой политики паролей парой примеров.
В этих примерах упоминаются две фиктивные корпорации: ITSO Acme Corporation и ITSO Widget Corporation. Эти две компании имеют разные мнения о том, какие пароли пользователи должны вводить в ходе процесса аутентификации.
Компания Acme придерживается либерального подхода к паролям, и ею была реализована настраиваемая политика паролей со следующими параметрами (рис. 2.7):
(рис 2.7) Пример настраиваемой политики паролейТребования к управлению паролями включают следующие параметры (рис. 2.8):
(рис 2.8) Детали настраиваемой политики паролей
ITSO Widget Corporation более строго подходит к паролям, и ею была реализована настраиваемая политика паролей со следующими параметрами (рис. 2.9):
(рис 2.9) Пример настраиваемой политики паролейТребования к управлению паролями включают следующие параметры (рис. 2.10):
(рис 2.10) Детали настраиваемой политики паролейДанная лекция будет неполной, если не упомянуть о параметрах управления паролями, не зависящих от настраиваемых политик паролей. Эти параметры можно конфигурировать в политике безопасности, не реализуя настраиваемую политику паролей.
В Domino 7 появилось 2 новых параметра политики безопасности, позволяющие администраторам осуществлять тонкую настройку срока действия пароля: Warning Period (Время вывода предупреждения) и Custom Warning Message (Собственное предупреждение).
Параметр Warning Period (Время вывода предупреждения) позволяет администратору указать срок перед окончанием действия пароля, когда пользователь получает предупреждающее сообщение (т. е. "Время действия вашего пароля истекает через 10 дней"). По умолчанию значение этого параметра равно нулю, и это значит, что пользователи не получают никаких предупреждений до момента окончания действия пароля. Однако если срок действия пароля ограничен, а значение интервала смены пароля (количество дней действия пароля, по истечении которого его нужно будет сменить) менее 30 дней, значение в этом поле вычисляется автоматически как две трети интервала смены пароля. Если значение вычисляется, изменить его нельзя.
Теперь администраторы также могут указывать значение Custom Warning Message (Собственное предупреждение) в качестве предупреждения пользователям, для паролей которых подошел срок, указанный в поле Warning Period (Время вывода предупреждения). До Domino 7 пользователи получали только стандартное сообщение об ошибке.
Параметр Custom Warning Message (Собственное предупреждение) предназначен только для клиентов Notes, независимо от того, задан ли срок действия пароля для паролей Notes и Интернета или только для интернет-паролей. Пользователи Интернета не получают предупреждающего сообщения.
В IBM Workplace Collaboration Services 2.6 Managed Client имеется опция, позволяющая применять плагин Notes, при помощи которого пользователи IBM Workplace могут обращаться к базам данных и приложениям Notes. Администраторы Domino могут активировать эту возможность в документе параметров безопасности, чтобы клиент Workplace "запомнил" пароль Notes и этот пароль не приходилось многократно вводить при обращении к Notes-приложениям.
Этот параметр можно конфигурировать только при помощи документа параметров политики безопасности. Более того, этот параметр не является обязательным. Пользователи Workplace не обязаны применять эту возможность. Они включают эту опцию при первой попытке обратиться к Notes, когда видят окно Notes User Security (Безопасность пользователя Notes).
На этом заканчивается наш обзор новых возможностей системы безопасности, которые предоставляют настраиваемые политики паролей. В следующей лекции рассматривается восстановление ID.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.