Более близкий взгляд на защиту службы каталогов

При работе в NetWare 4.0 существует три аспекта защиты: доступ к DIB, защита с помощью пароля и защита файловой системы. Защита файловой системы не является частью службы каталогов Directory Services, поэтому в данной главе мы ее обсуждать не будет.

Защита доступа к DIB

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

Тем, кто уже работал с базой объектов Bindery, полномочия доступа могут быть знакомы. Bindery имеет пять уровней защиты: Attached, Logged in, Object, Supervisor и Bindery. Эти уровни реализуют полезную и простую системы защиты Bindery.

Защита доступа DIB служит тем же целям, но она гораздо более гибкая и ориентированная на объекты, чем защита, реализованная для Bindery. Она значительно более мощная и позволяет вам управлять доступом практически любым нужным вам способом. Если вы знакомы с тем, как в NetWare 4.0 реализована защита файловой системы, вам не следует беспокоиться об изучении наследования полномочий доступа к DIB. Нужно только не забывать о разделении двух типов защиты. Защита каталога предназначена для ограничения доступа к каталогу, а защита файловой системы - для ограничения доступа к файлам.

Bindery организует доступ по уровням защиты. Неважно, к какому объекты вы пытаетесь обратиться, важно только, что этот объект имеет определенный уровень защиты. Защита Bindery достаточно эффективна, но она не такая гибкая как защита DIB. С помощью каталога отдельной группе пользователей можно предоставить полномочия доступа к объектам, отдельным атрибутам объекта или всем атрибутам.

Полномочия доступа DIB, допускающие обращение к объектам, отличны от тек, которые допускают обращение к атрибутам. Для объектов это следующие полномочия:

 

Просмотр (Browse)

 

Добавление (Add)

 

Удаление (Delete)

 

Переименование (Rename)

 

Супервизор (Supervisor)

 

а для атрибутов:

 

Сравнение (Compare)

 

Чтение (Read)

 

Запись (Write)

 

Сам (Self)

 

Супервизор (Supervisor)

 

Есть четыре способа получить любое из этих полномочий или их все: с помощью прямого назначения, путем наследования от родителей в дереве, из эквивалентных присваиваний полномочий и по членству в группе (Group Membership). Существует процесс фильтрации, который применяется к каждому из этих типов назначений для конкретного объекта. Давайте познакомимся с каждым из них поближе.

Назовем в нашем обсуждении те объекты, которым присваиваются полномочия доступа, субъектами. Субъект - это то, чему (или кому) дается право на действие, и часто это объект пользователя, объект сервера или объект группы, однако этом может быть любой объект в дереве. Целью является то, над чем этот субъект выполняет действия. Целью может быть заданный объект, конкретный атрибут объекта или все его атрибуты. Полномочия доступа назначаются с помощью атрибута целевого объекта, который называется списком управления доступом - ACL (Access Control List). ACL содержит список назначений полномочий доступа.

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

Полномочия наследуются на основе структуры дерева каталога. Подчиненные объекты наследуют привилегии, которые даны их родительским объектам. На основе их взаимосвязей в древовидной структуре они используют полномочия, предоставленные родительским объектам (независимо от того, насколько удаленными они являются). Предположим, например, что подчиненными объектами в дереве объектов Novell являются Olga и Julia. Если мы предоставляем полномочия Novell, то Olga и Julia также будут иметь эти полномочия. Как это работает, показано на Рис. 3.2.

 

+----------------+

 

¦ Popurri ¦

 

+-----+-----+----+

 

+-----------+ +----------+

 

+--------+-------+ +--------+-------+

 

¦ Researching ¦ ¦ Marketing ¦

 

+--------+-------+ +-----+-----+----+

 

+-------+ +-----------+ +---+

 

+--------+-------+ +--------+-------+ +--------+-------+

 

¦ Olga ¦ ¦ Julia ¦ ¦ Kirill ¦

 

+----------------+ +----------------+ +----------------+

 

Access Control List =

 

права чтения Popurri

 

Olga и Kirill могут считывать атрибуты Julia

Некоторые типы объектов имеют атрибут равной защиты, который указывает, что в смысле полномочий доступа один объект равен другому (или другим). Таким образом, объект получит все назначения полномочий, присвоенный тому объекту, к которому он приравнен. Аналогично, объект получает все полномочия той группы, членом которой он является. Если объект Dina равен по защите объекту Lina, которому присвоены полномочия на Printserver, Dina имеет на Printserver те же полномочия, что и Lina.

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

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

Метод присваивания полномочий доступа предусматривает указание имени защищенного атрибута и предоставляемых полномочий. Эти три элемента образуют запись в списке ACL. Записи в ACL объекта ограничивают доступ к этому объекту и атрибутам этого объекта и подчиненных объектов.

Именем защищенного атрибута должно быть конкретное имя атрибута или [Entry Rights], [All Attributes Rights], либо [SMS Rights]. Если используется [Entry Rights], то полномочия будут влиять на объект и все подчиненные ему объекты. Если используется [All Attributes Rights], то полномочия влияют на все атрибуты объекта и атрибуты подчиненных ему объектов. При использовании [CMS Rights] полномочия влияют на объект, все атрибуты объекта, а также на подчиненные объекты и атрибуты подчиненных объектов. Если используется имя конкретного атрибута, то затрагивается конкретный атрибут.

Записи ACL можно использовать для ограничения тех полномочий, которые могут наследоваться. Это делается с помощью задания в качестве имени субъекта маски наследования [Inheritance Mask]. В качестве имени субъекта могут использоваться и другие значения. Эти значения применяют полномочия к определенным объектам, но не именуют объекты конкретно. Возможные значения: [Public] - для всех объектов, [Root] - для корня дерева каталога, [Creator] для создателя объекта и [Self] - для самого объекта. После создания объекта полномочия [Creator] и [Self] вы присваивать не можете. Эти назначения возможны только при добавлении объекта к дереву каталога.

К счастью, пошаговый процесс определения действующих полномочий для данного субъекта может выполняться службой каталога. Если вам нужно знать какие у вас действующие права, вы можете использовать функцию API NWDSGetEffectiveRights для получения прав уровня объекта и NWDSListAttrsEffectiveRights для получения действующих полномочий для всех атрибутов объекта.

Обеспечение защиты пароля

Обеспечение надежной защиты пароля - не всегда легкая задача. NetWare 4.0 реализует средства защиты пароля, помогающие защититься от запросов и подключений злоумышленника.

Чтобы обеспечить защиту пароля, NetWare использует кодирование RSA с ключевой парой (личный и общий ключ). Это означает, что каждый пользовательский объект, найденный в дереве каталога, имеет личный и общий ключ, которые используются для кодирования и декодирования данных с проверкой подлинности. Такой метод применяется для проверки подлинности сообщений, передаваемых между клиентом и сервером. Для создания ключевой пары используется ваш пароль. Следовательно, без пароля проверка пользователя невозможна.

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

Если вы чувствуете, что ваша пользовательская защита недостаточна, можно пойти еще дальше, чем простое изменение пароля. Вы можете сменить также ключевую пару. Это делается с помощью функции NWDSGenerateObjectKeyPair. К моменту написания данной книги полномочия на генерацию новой ключевой пары определялись вашей возможностью модифицировать общий и личный ключевые атрибуты объекта, для которого вы хотите задать новую ключевую пару.

Канонизация имен

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

Например, CN=Olga.OU=Researching.O=Alpha - это полное имя с заданными типами. Olga - это безтиповое сокращенное имя того же объекта, если контекстом является OU=Researching.O=Alpha. Если задается канонизация, и имя контекста устанавливается в OU=Researching.O=Alpha, то при спецификации объекта можно использовать Olga. По умолчанию такие сокращения разрешаются. Они задаются с помощью флага DCV_CANONICALIZE_NAMES.

Не путайте сокращения канонических имен с использование кратких форм объектных типов. Common Name - это имя атрибута с краткой формой CN. Независимо от установок флагов, вместо Common Name вы всегда можете использовать CN. Если вы выберите полный тип спецификации имен, таких как Common Name, то следует убедиться в действии канонизации. Это связано с тем, что Directory Server при работе с полными именами использует краткую форму имени атрибута (такую как CN). Маршрут кода для выполнения канонизации - это маршрут кода, преобразующий длинные имена атрибутов в их краткую форму. Если длинные имена атрибутов, такие как Common Name, не конвертируются в краткую форму (в данном случае CN), то Directory Server не будет знать, как обрабатывать полное имя.

Если используется сокращенное имя, такое как Olga, и выполняется канонизация, то при расширении имени до полной формы соблюдаются определенные правила. Используемые по умолчанию правила для типизации объектов в полную именную форму, когда не задаются имена атрибутов, имеют следующий вид:

• Старшим (наиболее значимым) именем всегда является организация - Organization (O).
• Если имеется более одного имени, то младшим именем является Common Name (CN).
• Все промежуточные имена - это подразделения организации Organizational Units (OU).

Если типы специфицируются, то данные используемые по умолчанию правила не применяются. Каноническое имя, такое как Olga.Researching.Aplha, может быть безтиповым, а используемые по умолчанию правила типизации применяются, если задан флаг контекста для безтиповых имен.

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

⇐ Предыдущая1234Следующая ⇒

Поделиться: