Кто распределяет поступающие запросы с возможным разграничение доступа

Обновлено: 18.05.2024

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

Первые шаги

Определить типы пользователей

Разберем на примере классического Отдела продаж:

Имеются младшие специалисты/колл-центр, которые работают с входящими обращениями
Сами специалисты Отдела продаж, которые ведут Клиентов по воронке продаж
Супервайзеры/руководители групп, которые отвечают за контроль работы своих сотрудников
Руководитель Отдела продаж, его заместитель, которые должны видеть общую картину
Специалист по контролю качества, который активно "бегает" по сделкам

Иерархия может быть абсолютно любой, но смысл в том, что Вы должны отчетливо понимать, кто и с какой информацией работает.

Определить функционал для каждой категории пользователей

Как только Вы отчетливо понимаете, кто будет работать в системе, пора настроить доступы к различным возможностям.

Сотрудникам разных типов воронки: запретить доступ в чужую воронку
Если необходимо: запретить редактирование чужой сделки
Разрешить доступ к определенным маркетинговым инструментам: СМС-рассылки и так далее
Доступ в раздел аналитики: насколько это необходимо рядовым сотрудникам?
Распределить администраторские доступы между руководящим составом

И многое другое. Точечные настройки зависят от возможностей конкретной CRM-системы. Главное - не оставляйте как есть, тщательно проработайте настройки.

Закрыть возможность удаления или выгрузки

Первое, что требуется сделать - закрыть возможность удаления чего-либо, неважно, даже если это дубль, даже если свой.

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

Вторые шаги

Презентация сотрудникам их аккаунтов

Обязательно расскажите сотрудникам о типах аккаунтов, возможностях, чтобы потом не возникало вопросов.

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

Тщательное документирование настроек

Сохраните разработанные настройки, чтобы потом не потерять логику принятых решений.
Любым удобным способом: word-документ, гугл-документ, что угодно. Главное, не потеряйте.

Строгое соблюдение установленных доступов

Никаких исключений из правил, права доступа должны строго соответствовать должности конкретного сотрудника!

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

Зачем нужно это делать?

Защита информации

Это основной аргумент в пользу разграничения прав: сохранность Клиентской базы в ее первозданном виде. А также:

Чтобы ее не выкачивали
Чтобы ее не корректировали в ту или иную сторону
Важная информация оставалась в системе
Не портилась статистика из-за манипулирования данными

Запомните: сотрудники очень падки до различных хитрых действий, но Клиентская база - собственность компании, на нее были потрачены существенные деньги.

Защита настроек системы

Еще важный момент: при интеграции Вы платили деньги за настройки CRM. Сотрудник может даже случайно нажать не туда и сделать непоправимое, вплоть до сброса.

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

Общий порядок на портале

Мы часто сталкивались с CRM-системами, где царил откровенный бардак не только в плане информации, но и по части настроек. Не забывайте - обслуживать такую систему будет значительно дороже.

Ухаживайте за своей CRM, используйте встроенные инструменты, чтобы получить максимум, а также поскорее отбить затраты на интеграцию и поддержку.

Мандатная модель управления доступом (Mandatory Access Control, MAC) — способ разграничения доступа с фиксированным набором полномочий. Обычно настоящий MAC используется в системах с повышенным требованиями к безопасности и стоит на службе всевозможных силовых ведомств и организаций, связанных с государственной или служебной тайной.

Модель MAC

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея

Абстрактная модель безопасности, реализуемая в классическом MAC (каким его знают сотрудники силовых ведомств), выглядит следующим образом (классическая картинка, иллюстрирующая модель Белла — Лападулы):

Иерархия уровней доступа, которые обрабатываются в системе (обычно регистрируются в ОС). Для удобства часто задается в виде беззнаковых чисел (от 0 до значения, ограниченного реализацией). В этом случае для сравнения уровней доступа (выше/ниже/равно) используются простейшие арифметические операции (равно, меньше, больше).
Объект с уровнем секретности. Любой файл, каталог в файловой системе, ячейка или запись в таблице БД, таблица в БД, сама БД, сетевой пакет и т.д. Объекту присваивается любое значение из иерархии уровней доступа. Для объекта допускается повышение уровня секретности (изменение до большего значения уровня, чем текущий). Понижение уровня секретности категорически не допускается (хотя вполне реализуемо при помощи определенных уловок).
Субъект с уровнем доступа. Процесс какого-либо приложения либо сеанс пользователя (по сути тоже процесс приложения). Метка уровня доступа наследуется от субъекта всеми создаваемыми данным субъектом объектами.

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

При проверке правомочности доступа субъекта к объекту согласно мандатной модели возможны следующие комбинации:

Ограничения и уязвимости

MAC обладает своими ограничениями и особенностями:

Проектирование приложения с поддержкой MAC

Несмотря на все ограничения модели, для тех, кто работает с госсектором, а в особенности с силовыми ведомствами, вопрос построения приложений с поддержкой мандатной модели управления доступом актуален как никогда. Вдруг завтра именно вам придется поддерживать MAC в своем продукте?

На первый взгляд кажется, что модель примитивна и ее реализация проста как пять копеек, но существует один нюанс: заказчик, который выставляет требование к использованию мандатной модели, имеет ввиду, в первую очередь, сертифицированное средство защиты информации. Обрабатываться в такой ИС будет действительно секретная информация, вплоть до государственной тайны, и сертифицировать на нужный уровень собственную разработку будет очень сложно. Выходом из данной ситуации является использование сертифицированной инфраструктуры, поддерживающей MAC.

Итак, что у нас есть в наборе:

Теперь рассмотрим, каким образом можно воспользоваться этой инфраструктурой при разработке приложения для сохранения функций управления доступом на уровне инфраструктуры.

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

Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает приложение. Процесс приложения наследует мандатную метку.
Приложение взаимодействует с БД на PostgreSQL, отображая пользователю, к примеру, только записи таблиц БД с текущей мандатной меткой.

Мы собрали рецепты по проектированию приложения с поддержкой MAC, сформулированные на основе собственного опыта. За ними стоят бессонные ночи, непрерывный поток тикетов от тестирования, тысячи часов отладки приложения, которое по всем здравым смыслам должно работать правильно, но почему-то работает не так. Рецепты описаны в максимально простой и нейтральной к технологиям и инструментам форме, и по возможности снабжены схемами для улучшения воспринимаемости. Поехали!

Как избежать MAC, когда его уже не избежать

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

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

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

Кроссплатформерность приложения (ограниченную только лишь возможностями языков программирования) и его независимость от среды выполнения.
Возможность использования современных инструментов виртуализации (например, Docker) с целью автоматизации.
Простоту тестирования и отладки функций, которые не связаны непосредственно с MAC.

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

Другой важный шаг при проектировании, который обязательно должен быть выполнен до начала разработки — разделение модулей, в которых требуется поддержка MAC, от модулей, в которых данный механизм управления доступом не требуется. Использование мандатной модели управления доступом почти всегда усложняет бизнес-логику приложения.

Это та самая инфраструктура, абстрагироваться от которой очень сложно, а порой невозможно. Поэтому приложение следует разбить на модули, а уже по каждому модулю произвести анализ потребности в поддержке MAC. Возможно, именно в вашем случае достаточно поддержать MAC только в одном модуле, и нет смысла из-за данного модуля усложнять все приложение?

Рекомендация: Следует разделить приложение на модули и классифицировать их по режимам обработки мандатных меток.

В случае, если мы рассматриваем некий абстрактный модуль (или все приложение, если деление приложения на модули не требуется) возможны следующие парадигмы:

Минимальная метка. Модуль обрабатывает данные в режиме минимальной мандатной метки (минимальная метка, в которой функционируют процессы ОС — например, 0 мандатная метка) либо без мандатной метки.
Одна метка. Модуль работает с данными только одной мандатной метки выше минимальной мандатной метки (любой метки, отличной от той, в которой функционируют процессы ОС).
Несколько меток. Модуль работает с данными сразу нескольких мандатных меток (как метки, в которой функционируют процессы ОС, так и других меток, отличных от метки процессов ОС).

Рекомендация: При проектировании следует обеспечивать минимальную связность (cohesion) модулей, работающих в различных парадигмах обработки мандатных меток.

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

Классификация модулей по режимам обработки MAC

Мотивация для реализации данного механизма в модуле:

Модуль обрабатывает информацию, которая в принципе не может обрабатываться в системе с другими мандатными метками, и не требует особых привилегий для чтения/записи.
Модуль сильно связан с инфраструктурой ОС, которая ограничивает его функционирование в режиме мандатной метки, отличной от минимальной.

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

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

Выбирать только те записи, которые соответствуют текущей мандатной метке, так как в соответствии с моделью Белла – Лападулы пользователь будет видеть записи текущей мандатной метки и всех мандатных меток, расположенных ниже по иерархии.
Проверять мандатную метку перед выполнением какой-либо операции внесения изменений в запись. При попытке внести изменение в запись с мандатной меткой, отличающейся от мандатной метки сеанса, выполнение операции должно быть прервано.

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

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

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

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

С точки зрения реализации пользовательского интерфейса обычно используются следующие шаблоны:

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

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

Для реализации такого режима необходимо заложить следующие функции:

Функция получение мандатной метки текущего процесса приложения (сеанса пользователя).
Функция получения мандатной метки записи (если речь идет о работе с записью в БД) или файла (если речь идет об обработке файлов).
Функция получения мандатной метки записей БД/файлов в коллекции.

Отчетность. Для реализации данного кейса нам необходимо аккумулировать максимум информации по системе, которая доступна для сеанса с текущей мандатной меткой.
Журнал. В этом случае разрабатывается интерфейс просмотра всех доступных для просмотра операций с возможностью фильтрации, в том числе и по мандатной метке.

Взаимодействие приложения с окружающей средой

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

Операционная система:

Параметры мандатной модели:

Иерархия мандатных меток ОС;
Мандатные разрешения (диапазоны меток, которые может использовать определенный пользователь) УЗ пользователей ОС.

СУБД (например, PostgreSQL):

Объекты БД (ячейки, строки, столбцы, схемы, таблицы, БД, кластеры, последовательности, функции и т.д.).

Взаимодействие MAC-совместимого приложения с операционной системой

Чего мы ожидаем от операционной системы в части MAC?

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

Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

Большая часть приложений, которые могут использоваться в ОС с MAC, не умеют обрабатывать MAC.

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

Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

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

Пример популярного приложения с полноценной поддержкой мандатных меток — СУБД PostgresSQL. В определенных вариантах поставки данной СУБД реализована полная поддержка MAC под некоторые ОС с механизмами MAC, например:

Astra Linux: PostgreSQL, идущий в поставке дистрибутива версии SE.
SELinux: расширение sepgsql.

На уровне кластера.
На уровне БД кластера.
На уровне схемы БД кластера.
На уровне таблицы схемы БД кластера.
На уровне столбца таблицы схемы БД кластера.
На уровне записи таблицы схемы БД кластера.

Взаимодействие MAC-совместимого приложения с пользователем

Каким бы странным ни выглядел данный аспект взаимодействия по сравнению с рассмотренными ранее, но не остановиться на нем нельзя. Ведь именно для пользователя чаще всего строятся приложения с поддержкой MAC, не так ли?

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

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

Кейс	Что требуется предусмотреть
Аутентификация и работа пользователя с сессией	Пользователь должен в каждый момент времени понимать, под какой мандатной меткой его видит приложение. Для этих целей приложение должно отображать простой и понятный индикатор мандатной метки сеанса пользователя, который будет доступен на каждом экране приложения.

Кейс

Что требуется предусмотреть

Аутентификация и работа пользователя с сессией

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

Пользователю необходимо дать четко понять, какая мандатная метка имеется у каждой записи.
Пользователь должен иметь возможность отфильтровать список записей по значению мандатной метки.
При выборе одной записи пользователю должно быть понятно, почему с одной записью можно выполнить одну операцию (например, просмотр подробной информации о записи), и нельзя выполнить другую (например, внесение изменений). Желательно, чтобы блок логики, ответственный за данное поведение, располагался где-то в одном месте (например, чтобы backend формировал коллекцию допустимых действий для каждой записи, и не приходилось дублировать данную логику на frontend).
При выборе нескольких записей перечень возможных действий должен быть ограничен минимальным набором действий, допустимым для всей выбранной коллекции.

Здесь возможны следующие варианты:

Выводы

Мы рассмотрели несколько аспектов разработки приложения с поддержкой MAC. Все случаи предусмотреть, разумеется, сложно. Большая часть особенностей мандатной модели зависит от реализации, доступной для применения в выбранной ОС.

При рассмотрении вопросов информационной безопасности используются понятия субъекта и объекта доступа. Субъект доступа может производить некоторый набор операций над каждым объектом доступа. Эти операции могут быть доступны или запрещены определенному субъекту или группе субъектов. Доступ к объектам обычно определяется на уровне операционной системы ее архитектурой и текущей политикой безопасности. Рассмотрим некоторые определения, касающиеся методов и средств разграничения доступа субъектов к объектам.

Метод доступа к объекту – операция, которая определена для данного объекта. Ограничить доступ к объекту возможно именно с помощью ограничения возможных методов доступа.

Владелец объекта – субъект, который создал объект несет ответственность за конфиденциальность информации, содержащейся в объекте, и за доступ к нему.

Право доступа к объекту – право на доступ к объекту по одному или нескольким методам доступа.

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

Модели разграничения доступа

Наиболее распространенные модели разграничения доступа:

дискреционная (избирательная) модель разграничения доступа;
полномочная (мандатная) модель разграничения доступа.

Дискреционная модель характеризуется следующими правилами:

Готовые работы на аналогичную тему

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

В дискреционной модели определение прав доступа хранится в матрице доступа: в строках перечислены субъекты, а в столбцах – объекты. В каждой ячейке матрицы хранятся права доступа данного субъекта к данному объекту. Матрица доступа современной операционной системы занимает десятки мегабайт.

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

каждый объект обладает грифом секретности. Гриф секретности имеет числовое значение: чем оно больше, тем выше секретность объекта;
у каждого субъекта доступа есть уровень допуска.

Допуск к объекту в этой модели субъект получает только в случае, когда у субъекта значение уровня допуска не меньше значения грифа секретности объекта.

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

Методы разграничения доступа

Виды методов разграничения доступа:

Разграничение доступа по спискам

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

Использование матрицы установления полномочий

При использовании матрицы установления полномочий применяется матрица доступа (таблица полномочий). В матрице доступа в строках записываются идентификаторы субъектов, которые имеют доступ в компьютерную систему, а в столбцах – объекты (ресурсы) компьютерной системы.

В каждой ячейке матрицы может содержаться имя и размер ресурса, право доступа (чтение, запись и др.), ссылка на другую информационную структуру, которая уточняет права доступа, ссылка на программу, которая управляет правами доступа и др.

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

Разграничение доступа по уровням секретности и категориям

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

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

Парольное разграничение доступа

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

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

1. Управление доступом . Исходной информацией для создания СРД является решение владельца (администратора) КС о допуске пользователей к определенным информационным ресурсам КС. Так как информация в КС хранится, обрабатывается и передается файлами (частями файлов), то доступ к информации регламентируется на уровне файлов (объектов доступа). Сложнее организуется доступ в базах данных, в которых он может регламентироваться к отдельным ее частям по определенным правилам. При определении полномочий доступа администратор устанавливает операции, которые разрешено выполнять пользователю (субъекту доступа).

Различают следующие операции с файлами):

- выполнение программ (Е).

Операция записи в файл имеет две модификации. Субъекту доступа может быть дано право осуществлять запись с изменением содержимого файла (W). Другая организация доступа предполагает разрешение только дописывания в файл, без изменения старого содержимого (А).

В КС нашли применение два подхода к организации разграничения доступа [6]:

Матричное управление доступом предполагает использование матриц доступа. Матрица доступа представляет собой таблицу, в которой объекту доступа соответствует столбец O_j, а субъекту доступа - строка S_i. На пересечении столбцов и строк записываются операция или операции, которые допускается выполнять субъекту доступа i с объектом доступа j (рис.9.1).

Рис.9.1. Матрица доступа

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

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

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

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

Мандатное управление позволяет упростить процесс регулирования доступа, так как при создании нового объекта достаточно создать его метку. Однако при таком управлении приходится завышать конфиденциальность информации из-за невозможности детального разграничения доступа.

Если право установления правил доступа к объекту предоставляется владельцу объекта (или его доверенному лицу), то такой метод контроля доступа к информации называется дискреционным.

2. Состав системы разграничения доступа . Система разграничения доступа к информации должна содержать четыре функциональных блока:

- блок идентификации и аутентификации субъектов доступа;

- блок криптографического преобразования информации при ее хранении и передаче;

- блок очистки памяти.

Идентификация и аутентификация субъектов осуществляется в момент их доступа к устройствам, в том числе и дистанционного доступа.

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

Запрос на доступ i-го субъекта и j-му объекту поступает в блок управления базой полномочий и характеристик доступа и в блок регистрации событий. Полномочия субъекта и характеристики объекта доступа анализируются в блоке принятия решения, который выдает сигнал разрешения выполнения запроса, либо сигнал отказа в допуске. Если число попыток субъекта допуска получить доступ к запрещенным для него объектам превысит определенную границу (обычно 3 раза), то блок принятия решения на основании данных блока регистрации выдает сигнал "НСДИ" администратору системы безопасности. Администратор может блокировать работу субъекта, нарушающего правила доступа в системе, и выяснить причину нарушений. Кроме преднамеренных попыток НСДИ диспетчер фиксирует нарушения правил разграничения, явившихся следствием отказов, сбоев аппаратных и программных средств, а также вызванных ошибками персонала и пользователей.

Рис.9.2. Диспетчер доступа

Блок криптографического преобразования информации при ее хранении и передаче является надежным способом защиты от НСДИ в распределенных КС. Обусловлено это тем, что криптографическое закрытие информации сегодня одним из самых надежных средств ЗИ. Сущность его изложена в лекции 11.

Блок очистки памяти в СРД должен реализовать функцию очистки оперативной памяти и рабочих областей на ВЗУ после завершения выполнения программы, обрабатывающей конфиденциальные данные. Причем очистка должна производиться путем записи в освободившиеся участки памяти определенной последовательности двоичных кодов, а не удалением только учетной информации о файлах из таблиц ОС, как это делается при стандартном удалении средствами ОС.

3. Концепция построения систем разграничения доступа . В основе построения СРД лежит концепция разработки защищенной универсальной ОС на базе ядра безопасности [6]. Под ядром безопасности понимают локализованную, минимизированную, четко ограниченную и надежно изолированную совокупность программно-аппаратных механизмов, доказательно правильно реализующих функции диспетчера доступа [29]. Правильность функционирования ядра безопасности доказывается путем полной формальной верификации его программ и пошаговым доказательством их соответствия выбранной математической модели защиты.

Применение ядра безопасности требует провести изменения ОС и архитектуры ЭВМ. Ограничение размеров и сложности ядра необходимо для обеспечения его верифицируемости.

Для аппаратной поддержки защиты и изоляции ядра в архитектуре ЭВМ должны быть предусмотрены:

- многоуровневый режим выполнения команд;

- использование ключей защиты и сегментирование памяти;

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

- аппаратная реализация части функций ОС;

- хранение программ ядра в постоянном запоминающем устройстве (ПЗУ);

- использование новых архитектур ЭВМ, отличных от фон-неймановской архитектуры (архитектуры с реализацией абстрактных типов данных, теговые архитектуры с привилегиями и др.).

Обеспечение многоуровневого режима выполнения команд является главным условием создания ядра безопасности. Таких уровней должно быть не менее двух. Часть машинных команд ЭВМ должна выполняться только в режиме работы ОС. Основной проблемой создания высокоэффективной защиты от НСД является предотвращение несанкционированного перехода пользовательских процессов в привилегированное состояние. Для современных сложных ОС практически нет доказательств отсутствия возможности несанкционированного получения пользовательскими программами статуса программ ОС.

Использование ключей защиты, сегментирование памяти и применение механизма виртуальной памяти предусматривает аппаратную поддержку концепции изоляции областей памяти при работе ЭВМ в мультипрограммных режимах. Эти механизмы служат основой для организации работы ЭВМ в режиме виртуальных машин. Режим виртуальных машин позволяет создать наибольшую изолированность пользователей, допуская использование даже различных ОС пользователями в режиме разделения времени.

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

Универсальные ЭВМ и их ОС, используемые ранее, практически не имели встроенных механизмов защиты от НСД. Такие распространенные ОС как IBM System/370, MS-DOS и целый ряд других ОС не имели встроенных средств идентификации и аутентификации и разграничения доступа. Более современные универсальные ОС UNIX, VAX/VMS, Solaris и др.. имеют встроенные механизмы разграничения доступа и аутентификации. Однако возможности этих встроенных функций ограничены и не могут удовлетворять требованиям, предъявляемым к защищенным ЭВМ.

Имеется два пути получения защищенных от НСД КС:

- создание специализированных КС;

- оснащение универсальных КС дополнительными средствами защиты.

Первый путь построения защищенных КС пока еще не получил широкого распространения в связи с нерешенностью целого ряда проблем. Основной из них является отсутствие эффективных методов разработки доказательно корректных аппаратных и программных средств сложных систем. Среди немногих примеров специализированных ЭВМ можно назвать систему SCOMP фирмы "Honeywell", предназначенную для использования в центрах коммутации вычислительных сетей, обрабатывающих секретную информацию. Система разработана на базе концепции ядра безопасности. Узкая специализация позволила создать защищенную систему, обеспечивающую требуемую эффективность функционирования по прямому назначению.

Чаще всего защита КС от НСД осуществляется путем использования дополнительных программных или аппаратно-программных средств. Программные средства RACF, SECURC, TOPSECRET и другие использовались для защиты ЭВМ типа IBM-370.

В настоящее время появились десятки отдельных программ, программных и аппаратных комплексов, рассчитанных на защиту персональных ЭВМ от несанкционированного доступа к ЭВМ, которые разграничивают доступ к информации и устройствам ПЭВМ.

4. Современные системы защиты ПЭВМ от несанкционированного доступа к информации . В качестве примеров отдельных программ, повышающих защищенность КС от НСД, можно привести утилиты из пакета Norton Utilities, такие как программа шифрования информации при записи на диск Diskreet или Secret disk, программа стирания информации с диска Wipehifo, программа контроля обращения к дискам Disk Monitor и др. [32].

Отечественными разработчиками предлагаются программные системы защиты ПЭВМ "Снег-1.0", "Кобра", "Страж-1.1" и др. В качестве примеров отечественных аппаратно-програм-мных средств защиты, имеющих сертификат Гостехкомиссии, можно привести системы "Аккорд-4", "DALLAS LOCK 3.1", "Редут", "ДИЗ-1".

Аппаратно-программные комплексы защиты реализуют максимальное число защитных механизмов:

- идентификация и аутентификация пользователей;

- разграничение доступа к файлам, каталогам, дискам;

- контроль целостности программных средств и информации;

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

- защита процесса загрузки ОС;

- блокировка ПЭВМ на время отсутствия пользователя;

- криптографическое преобразование информации;

Программные СЗИ в качестве идентификатора используют, как правило, только пароль. Пароль может быть перехвачен резидентными программами двух видов. Программы первого вида перехватывают прерывания от клавиатуры, записывают символы в специальный файл, а затем передают управление ОС. После перехвата установленного числа символов программа удаляется из ОП. Программы другого вида выполняются вместо штатных программ считывания пароля. Такие программы первыми получают управление и имитируют для пользователя работу со штатной программой проверки пароля. Они запоминают пароль, имитируют ошибку ввода пароля и передают управление штатной программе парольной идентификации. Отказ при первом наборе пароля пользователь воспринимает как сбой системы или свою ошибку и осуществляет повторный набор пароля, который должен завершиться допуском его к работе. При перехвате пароля в обоих случаях пользователь не почувствует, что его пароль скомпрометирован. Для получения возможности перехвата паролей злоумышленник должен изменить программную структуру системы. В некоторых программных системах защиты ("Страж-1.1") для повышения достоверности аутентификации используются съемные магнитные диски, на которых записывается идентификатор пользователя.

Значительно сложнее обойти блок идентификации и аутентификации в аппаратно-программных системах защиты от НСД. В таких системах используются электронные идентификаторы, чаще всего - Touch Memory.

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

В наиболее совершенных системах реализован механизм контроля целостности файлов с использованием хэш-функции. Причем существуют системы, в которых контрольная характеристика хранится не только в ПЭВМ, но и в автономном ПЗУ пользователя. Постоянное запоминающее устройство, как правило, входит в состав карты или жетона, используемого для идентификации пользователя. Так в системе "Аккорд-4" хэш-функции вычисляются для контролируемых файлов и хранятся в специальном файле в ПЭВМ, а хэш-функция, вычисляемая для специального файла, хранится в Touch Memory.

После завершения работы на ПЭВМ осуществляется запись контрольных характеристик файлов на карту или жетон пользователя. При входе в систему осуществляется считывание контрольных характеристик из ПЗУ карты или жетона и сравнение их с характеристиками, вычисленными по контролируемым файлам. Для того, чтобы изменение файлов осталось незамеченным, злоумышленнику необходимо изменить контрольные характеристики как в ПЭВМ, так и на карте или жетоне, что практически невозможно при условии выполнения пользователем простых правил.

Очень эффективным механизмом борьбы с НСДИ является создание функционально-замкнутых сред пользователей. Суть его состоит в следующем. Для каждого пользователя создается меню, в которое попадает пользователь после загрузки ОС. В нем указываются программы, к выполнению которых допущен пользователь. Пользователь может выполнить любую из программ из меню. После выполнения программы пользователь снова попадает в меню. Если эти программы не имеют возможностей инициировать выполнение других программ, а также предусмотрена корректная обработка ошибок, сбоев и отказов, то пользователь не сможет выйти за рамки установленной замкнутой функциональной среды. Такой режим работы вполне осуществим во многих АСУ.

Защита процесса загрузки ОС предполагает осуществление загрузки именно штатной ОС и исключение вмешательства в ее структуру на этапе загрузки. Для обеспечения такой защиты на аппаратном или программном уровне блокируется работа всех ВЗУ, за исключением того, на котором установлен носитель со штатной ОС. Если загрузка осуществляется со съемных носителей информации, то до начала загрузки необходимо удостовериться в том, что установлен носитель со штатной ОС. Такой контроль может быть осуществлен программой, записанной в ПЗУ ЭВМ.

Способы контроля могут быть разными: от контроля идентификатора до сравнения хэш-функций. Загрузка с несъемного носителя информации все же является предпочтительнее.

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

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

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

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

Важно обеспечивать стирание информации в ОП и в рабочих областях ВЗУ. В ОП размещается вся обрабатываемая информация, причем, в открытом виде. Если после завершения работы пользователя не осуществить очистку рабочих областей памяти всех уровней, то к ней может быть осуществлен несанкционированный доступ.

Каждый ресурс, за исключением объектов Active Directory, расположен на каком-либо компьютере. Для регулирования доступа к этому ресурсу создаются локальные группы на данном компьютере либо локальные доменные группы в домене Active Directory. В списках допусков к объектам, составляющим ресурс, фигурируют только эти локальные группы. Число локальных групп соответствует числу уровней доступа, необходимому для данного ресурса. Таких уровней как минимум два: для администрирования ресурса и для повседневного использования.

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

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

Такой подход хорош, но есть одна беда: для исполнения своих служебных обязанностей пользователю требуется доступ ко множеству объектов, поэтому приходится включать его в несколько глобальных групп, регулирующих доступ к этим объектам. Если же круг обязанностей меняется, при стандартном подходе AGLP необходимо тщательно пересмотреть членство пользователя в группах. Как правило, на практике все сводится к добавлению пользователя в новые группы, чтобы он получил доступ к другим ресурсам.

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

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

Возможные модификации стандартной схемы

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

Можно создать для каждой должности учетную запись пользователя, после чего требовать, чтобы сотрудники при входе в корпоративную сеть регистрировались от имени учетной записи, соответствующей занимаемой должности. Тогда соблюдается традиционный подход AGLP, но не соблюдается другой базовый принцип информационной безопасности — принцип разграничения ответственности. То есть опять-таки возможны недоразумения: при совершении нарушений по журналам регистрации Windows не удастся установить, кто именно из сотрудников нарушил правила.

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

То есть следует:

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

Образуется цепочка взаимоотношений: учетная запись — глобальная группа должностных обязанностей — глобальная группа доступа к ресурсу — локальная группа доступа к ресурсу — разрешения на объекты. Это можно записать в виде аббревиатуры AGGLP, см. рис. 2.

Для того чтобы реализация этой схемы была возможна, в корпоративной сети должна быть развернута служба Active Directory, причем не в режиме совместимости с Windows NT (смешанный режим не допускает вложенного членства в группах, поэтому описанные действия просто невозможны), а в собственном режиме Windows 2000 или режиме Windows Server 2003.

Еще одно ограничение: так, как описано выше, предлагаемый подход будет работать только в пределах одного домена. Дело в том, что в состав доменных глобальных групп разрешается включать только другие доменные глобальные группы из того же домена и пользователей из того же домена. Для сети со множеством доменов, входящих в состав одного леса (а если Active Directory работает в режиме Windows Server 2003, то и нескольких лесов, связанных доверительными отношениями), этот вариант не подходит. Но ничто не мешает использовать вместо доменных глобальных групп универсальные. В силу ограничений в допустимом вложенном членстве (универсальная группа может включать доменную глобальную, но не наоборот) универсальные группы должны быть обязательно на обеих позициях — как для регулирования доступа, так и для описания должностей.

Таким образом, получается следующий вариант регулирования доступа к ресурсам.

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

Получившуюся цепочку взаимоотношений можно записать следующим образом: учетная запись — универсальная группа должности — универсальная группа доступа к ресурсу — локальная доменная группа — разрешения на доступ к объектам. Можно эту цепочку обозначить аббревиатурой AUULP, см. рис. 3.

Вариант AUULP также не лишен недостатков. Информация об универсальных группах распространяется в составе данных глобального каталога, поэтому добавление большого количества универсальных групп автоматически приведет к увеличению трафика репликации. Что касается обработки этих данных контроллерами домена, то с этой стороны проблем возникнуть не должно — вычислительная мощность компьютеров, которые сейчас имеются в продаже, с запасом покрывает необходимые потребности. А вот трафик репликации — это дополнительная статья расходов для территориально распределенной организации, отдельные подсети которой соединены между собой через VPN с использованием публичных каналов.

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

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

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

Размещение объектов и дополнительный контроль

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

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

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

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

Локальные доменные группы и соответствующие им универсальные группы, регулирующие доступ к ресурсам, следует размещать в доменах таким образом, чтобы они располагались вблизи от того ресурса, доступ к которому эти группы регулируют.

Дополнительный контроль всех настроек, устанавливаемых в рамках реализации подхода AUULP/AGUULP, возможен с использованием групповых политик. Если ресурс представляет собой фиксированный набор папок и/или файлов, целесообразно контролировать списки разрешений на эти папки и файлы с помощью групповой политики: раздел Computer Settings — Security Settings — File System. Соответствующий объект групповой политики (GPO) должен применяться к тому серверу, на котором размещается ресурс, но в то же время не затрагивать те серверы, которых данная настройка не касается. Поэтому целесообразно этот объект групповой политики размещать в том объекте — организационном подразделении, где непосредственно размещается данный сервер, и дополнительно настроить на GPO список разрешений, чтобы настройка не затрагивала остальные серверы, расположенные здесь же.

Вложенное членство в группах также можно регулировать через групповые политики. Надо только иметь в виду, что эти политики должны применяться ко всем контроллерам домена, или как минимум к тому из них, который является мастером инфраструктуры. Соответствующие настройки выполняются в разделе Computer Settings — Security Settings — Restricted Groups:

локальная доменная группа, регламентирующая доступ к ресурсу, - настройка Members, включить только соответствующую универсальную группу;
универсальная группа, регламентирующая доступ к ресурсу, - настройка Member of, включить только соответствующую локальную доменную группу;
универсальная группа, описывающая набор прав доступа, необходимых для исполнения должностных обязанностей, - настройка Member of, включить соответствующие универсальные группы, регламентирующие доступ к необходимым ресурсам.

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

Кроме того, при планировании структуры групповых политик, реализующих дополнительные проверки списков доступа к файлам и папкам, а также проверки членства в группах, нужно иметь в виду следующее. Настройки раздела Computer Settings — Security Settings — File System из разных объектов групповых политик суммируются, и правила разрешения конфликтов при наследовании GPO действуют в отношении каждого отдельно взятого файла или папки, упомянутых в этом разделе. Поэтому соответствующие параметры могут настраиваться в любых GPO, действие которых распространяется на компьютер, содержащий ресурс. Желательно, чтобы это был GPO, применяемый к компьютеру последним.

В то же время содержимое раздела Computer Settings — Security Settings — Restricted Groups замещается целиком, и действовать будут только установки, указанные в последнем применяемом GPO. Поэтому необходимо соблюдать следующие ограничения.

В настройках групповой политики Computer Settings - Security Settings - Restricted Groups должна фигурировать вся проверяемая структура членства в группах, касающаяся групп данного домена.
Недопустима ситуация, когда результирующие настройки раздела Computer Settings - Security Settings - Restricted Groups будут разными для разных контроллеров домена. В противном случае синхронизация данных между доменами при попытке определить членство в группах приведет к неопределенному результату.

Рекомендуется действовать следующим образом.

Указать настройки Computer Settings - Security Settings - Restricted Groups в одном и только в одном GPO для каждого домена. Прописать там параметры членства во всех группах, созданных в данном домене.
Привязать этот GPO ко всем объектам - организационным подразделениям, в которых находятся контроллеры домена.
Переместить данный GPO в списке привязок наверх, чтобы он применялся последним и именно его настройки вступали в силу.

Если указывать настройки Computer Settings — Security Settings — Restricted Groups в нескольких GPO, придется следить за тем, чтобы содержимое настроек было всегда одинаковым. При этом любая перестройка будет затруднена и может вызвать проблемы, если новое состояние забыли скопировать в какой-то из задействованных GPO.

Право выбора

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

Могут быть и другие способы, реализующие разграничение доступа на основе должностей сотрудников или их организационных ролей, что с функциональной точки зрения одно и то же. Например, в состав Windows Server 2003 включен компонент Authorization Manager, реализующий похожий подход, но только там для предоставления пользователю необходимого набора прав и разрешений используются наборы сценариев на VBScript или Jscript, из которых вызываются системные API, реализующие работу со списками разрешений и предоставление системных прав. В случае его использования необходимо сначала разработать соответствующие сценарии, зато при подходящем наборе сценариев получается гарантированный результат.

Тем не менее, если администратору затруднительно по какой-либо причине использовать сценарии в Authorization Manager (например, еще не установлена Windows Server 2003 или же Active Directory пока работает в режиме Windows 2000 Native), можно воспользоваться предлагаемым подходом AUULP или придумать что-то свое. В любом случае всем администраторам желаю успехов в нашем нелегком труде!

Читайте также: