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

Что ж, сама по себе данная тема довольно грузная, и требует определённого времени на анализ и постанувку задачи.

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

Давайте с самого начала обсудим архитектуру модульной системы на выбранной нами псевдо-системе.

Все модули представлены ввиде подключаемых к главному документу (индекс-файлу) вставок. Запрос модуля происходит из строки запроса QUERY_STRING, и название подключаемого модуля передаётся в качестве аргумента act. В некотором месте индекса файла происходит изъятие и обработка данного параметра. После, если у пользователя достаточно прав для доступа к модулю в контексте чтения, происходит проверка существования указанного в строке запроса модуля, и если таковой существует, то происходит его подключение к индекс файлу.

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

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

Значение do буду фиксированными, данная переменная будет принимать следующие значения:

• main - главная часть модуля (доступно в контексте чтения)
• config - раздел настройки модуля (доступно в контексте записи)
• create - произвести некоторые действия, по добавлению информации в БД (доступно в контексте записи)
• delete - доступ к разделу, предоставляющему возможности удалить некоторую информацию, в контексте данного модуля (доступно в контексте записи)
• edit - доступ к редактированию информации в контексте модуля (доступно в контексте записи)

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

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

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

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

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

Что ж, давайте рассмотрим эту особую структуру. Она будет следующей: [ module_indefier: + \: + \;] *

То есть идёт список из пар: имя модуля ":" права чтения "," права записи ";". При этом данная метка обновляется в момент внесения изменений о правах доступа пользователя к системе. Если в системе появляется информация о модуле, который не вошёл в данную метку, то стоит просто произвести процедуру редактирования, и данные сохранятся автоматически.

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

Я не буду добавлять ничего лишнего в неё, но лишь то, что будет использоватся в контексте темы данной статьи. Таблица пользователей будет содержать следующие поля: идентифицатор пользователя (числовой счётчик), логин, пароль (хеш оригинального пароля), профиль безопасности пользователя (идетификатор группы пользователя, относительно прав в системе), и всё. Мне кажется этой информации нам с вами вполне хватит, для реализации поставленной задачи, а уже все остальные надстройки я предоставляю возможность сделать самим.

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

Таблица `modules`:

CREATE TABLE `modules` (`id` bigint(20) NOT NULL auto_increment, `indefier` text collate utf8_unicode_ci NOT NULL, `title` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Таблица `secure_groups`:

CREATE TABLE `secure_groups` (`id` bigint(20) NOT NULL auto_increment, `title` text collate utf8_unicode_ci NOT NULL, `perms` text collate utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

Таблица `users`

CREATE TABLE `users` (`id` bigint(20) NOT NULL auto_increment, `login` text collate utf8_unicode_ci NOT NULL, `passwd` text collate utf8_unicode_ci NOT NULL, `groupId` int(1) NOT NULL default "0", PRIMARY KEY (`id`)) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ;

temp=array(); $this->temp["_result"]=0; $this->temp["_uid"]=explode("::",$_COOKIE["site_hash"]); $this->temp["_uid"]=$this->temp["_uid"]; $this->temp["_gid"]=$this->getUserSecurityAccess($this->temp["_uid"]); $this->temp["_conn_id"]=mysql_connect("host","user","passwd"); mysql_select_db("database"); $this->temp["_q1"]=mysql_query("SELECT perms" ."FROM `secure_groups`" ."WHERE id=".$this->temp["_gid"]); $this->temp["_access_stamp"]=mysql_fetch_assoc($this->temp["_q1"]); $this->temp["_access_stamp"]=$this->temp["_access_stamp"]["perms"]; $this->temp["_access_stamp"]=explode(";",$this->temp["_access_stamp"]); $this->temp["_access_stamp"]=array_slice($this->temp["_access_stamp"],0,-1); foreach($this->temp["_access_stamp"] as $this->temp["v"]){ $this->temp["_mod_access"]=explode(":",$this->temp["v"]); $this->temp["_mod_indefier"]=$this->temp["_mod_access"]; if($this->temp["_mod_indefier"]==$module){ $this->temp["_perms"]=explode(",",$this->temp["_mod_access"]); switch($act){ case "r": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; case "w": $this->temp["_result"]=($this->temp["_perms"]==1)? 1:0; break; } break; } } mysql_close($conn_id); return $this->temp["_result"]; } } ?>

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

Функция secure::getUserId()

Используя данную функцию, мы подразумеваем, что во время авторизации пользователя в системе в переменной среде $_COOKIE была установлена переменная `site_hash`, состоящая из идентификатора пользователя в системе и хеша для проверки аутентичности его в системе. Функция просто изымает значение идентификатора, возращая его значение на выходе.

Функция secure::getUserSecurityAccess($id)

На выходе данная функция возвращает идентификатор профиля безопасности текущего пользователя в системе.

Функция secure::checkUserPermission($module,$act))

Производится запрос к БД, относительно прав пользователя на произведение действий чтения/записи в контексте переданного в качестве параметра модуля.

Осталось лишь описать процедуру формирования переменной в среде $_COOKIE, и тему статьи можно будет считать расскрытой.

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

Для проверки аутентичности данных хранимых в переменной среде $_COOKIE, мы будем использовать функцию EatCookie(), которая будет производить валидацию данных, возвращая булевый результат проверки (истина - ложь).

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

• `ulogin` - логин пользователя
• `upasswd` - пароль пользователя
• `stime` - время сессии, устанавливаемое пользователем (от 1 до 5 часов)
• `auth` - имя кнопки отправки

Вот, в целом и всё. Осталось лишь пробовать, экспериментировать, ошибатся и находить решение, что я всецело и оставляю вам.

Надеюсь, что мы скоро встретимся, а для тех кто имеет ко мне вопрос в отношении статьи, да и не только - писать на [email protected], либо на [email protected].

С уважением Карпенко Кирилл, глава IT-отдела ИНПП.

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

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

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

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

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

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

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

Каждому пользователю – список ресурсов и прав доступа к ним или

Каждому ресурсу – список пользователей и их прав доступа к данному ресурсу.

Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в большинстве ОС и СУБД.

Использование матрицы установления полномочий подразумевает применение матрицы доступа (таблицы полномочий). В указанной матрице (см. таблицу 2.7) строками являются идентификаторы субъектов, имеющих доступ в АС, а столбцами – объекты (информационные ресурсы) АС. Каждый элемент матрицы может содержать имя и размер предоставляемого ресурса, право доступа (чтение, запись и др.), ссылку на другую информационную структуру, уточняющую права доступа, ссылку на программу, управляющую правами доступа и др.

Таблица 2.7

Фрагмент матрицы установления полномочий

		Программа
Пользователь 1
Пользователь 2			w c 9:00 до 17:00

c – создание, d – удаление, r – чтение, w – запись, e – выполнение.

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

Разграничения доступа по уровням секретности и категориям состоят в том, что ресурсы АС разделяются в соответствии с уровнями секретности или категорий.

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

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

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

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

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

Дискретное управление доступом;

Мандатное управление доступом.

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

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

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

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

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

VLAN (Virtual Local Area Network) - это виртуальное разделение сети на части (локальные сети). По умолчанию, коммутатор, считает все свои интерфейсы (порты) в одной и той же локальной сети. С помощью дополнительной конфигурации, можно создавать отдельные подсети и выделять определенные порты коммутатора для работы в этих сетях. Лучшим определением VLAN можно считать то, что VLAN - это один широковещательный домен.

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

Ограничение доступа в социальные сети

Если вы не хотите, чтобы Ваши сотрудники имели доступ к конкретным ресурсам (социальным сетям, запрещенным сайтам), мы можем предложить 4 доступных способа это сделать:

— Запретить доступ локально на конкретном ПК. Сделать это можно через файл /etc/hosts.

— Настройка ACL (Access Control List) на граничном маршрутизаторе. Смысл заключается в запрете доступа из конкретной подсети, к конкретным адресам.

— Настройка DNS (Domain Name System) сервера. Суть метода, в запрете разрешения конкретных доменных имен. Это означает, что при вводе в адресную строку браузера сайта vk.com, например, данное доменное имя не будет преобразовано в IPv4 адрес, и пользователь не сможет зайти на этот сайт.

— Специальное ПО. Мы предлагаем специальное (антивирусное) ПО от наших партнеров.

Сетевая безопасность

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

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

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

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

— Защита информации на персональных компьютерах.

— Обеспечение безопасности хранения данных на серверах.

— Защита информации в рамках облачных решений.

Статистика безопасности

"Лаборатория Касперского" и B2B International провели исследования, согласно которому, 98,5% компаний МСБ (малого и среднего бизнеса) подвергались внешним кибер - угрозам. Из них 82% испытали на себе действие внутренних угроз.

Компании МСБ (малого и среднего бизнеса) теряют 780 тыс. рублей от одного случая нарушения информационной безопасности на предприятии.

Поможем

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

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

План работ

Исследуем Вашу текущую сетевую инфраструктуру

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

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

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

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

• Лицо, ответственное за обработку текущего статуса средства измерения - это сотрудник предприятия, который в текущем статусе СИ должен выполнить определенные этим статусом действия и перевести СИ в последующий статус в рамках рабочего цикла одной из метрологических работ. Определяется из параметров текущего статуса СИ. Например, таким лицом является лицо, исполняющее роль диспетчера (далее по тексту Диспетчер), принявшее СИ для выполнения ремонта и обязанное его затем передать лицу, исполняющему роль исполнителя ремонта (далее по тексту Исполнитель ремонта).
• Материально-ответственное за СИ лицо - это сотрудник предприятия, который несет материальную ответственность за средство измерения или эксплуатирует его. Определяется в учетной карточке СИ. Как правило, таким лицом является мастер, в ведении которого находится это СИ.
• Руководители "первых двух" лиц - буквально по определению. Определяются из организационной структуры предприятия по следующему принципу: они являются руководителями лиц из первых двух категорий "Лицо, ответственное за обработку текущего статуса СИ" и "Материально-ответственное за СИ лицо"; либо они являются руководителями вышестоящего подразделения предприятия, в состав которого входит (подчиняется) структурное подразделение, где исполнителями работают лица из первых двух категорий. В рамках АСОМИ этот концептуальный принцип приводит к тому, что информация о СИ доступна как всем вышестоящим руководителям Метролога, так и всем вышестоящим руководителям исполнителей тех или иных МР (например, начальник цеха имеет доступ к информации о СИ, за которые ответственны его мастера).
• Лицо, ответственное за метрологический надзор и контроль - это, например, сотрудник поверочного, ремонтного подразделения или метролог структурного подразделения, исполняющий обязанности по надзору и контролю. В соответствии с его обязанностями, он вправе иметь доступ на чтение учетной информации обо всех СИ, закрепленных за ним.

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

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

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

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

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

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

Доступ к операционным данным (протоколам работы пользователей) разрешен только Администраторам АСОМИ и Главному метрологу предприятия.

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

Если Вас заинтересовал данный продукт или возникли вопросы,
которые Вы хотели бы задать, пишите:

С проблемой предоставления доступа в той или иной форме приходилось сталкиваться каждому системному администратору. Это самая трудоемкая задача, хотя бы просто в силу большого количества как ресурсов, так и пользователей, которым требуется такого рода доступ. Дело осложняется разнородным составом ресурсов. Это могут быть папки на файловом сервере или даже отдельные файлы, сетевые принтеры и очереди печати, базы данных, объекты Active Directory, ресурсы Internet и т. д. Наконец, необходимо для разных категорий пользователей иметь разный уровень доступа к ресурсам, например, одни пользователи имеют право только обращаться к базе данных справочно-правовой системы («Гарант», «Консультант-Плюс», «Кодекс», «Ваше Право» и т. д.), а другие уполномочены устанавливать получаемые по подписке обновления.

Каждый администратор решал эту задачу по-своему: либо использовал стандартные методы, действуя «как учили», либо вносил в стандартные подходы собственные изменения. Этой проблеме посвящено множество статей, например «Эффективное управление доступом в сетях Windows 2000 и NT» Рэнди Франклина Смита (). Я хочу рассказать еще об одном подходе к решению этой непростой задачи.

«Как учили»

Рис. 1. Стандартный подход к администрированию доступа к ресурсам - AGLP

Стандартный подход, который Microsoft предлагает во всех курсах по администрированию, обозначается аббревиатурой AGLP. Как известно, это сокращение расшифровывается следующим образом: «Учетная запись (Account) - глобальная группа (Global Group) - локальная группа (Local Group) - Разрешения (Permissions)». Данный подход выражается в следующем (см. рис. 1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Администрирование доступа к ресурсам по схеме AGGLP	Рис. 3. Администрирование доступа к ресурсам по схеме AUULP

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

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

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

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

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

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

Более серьезная проблема связана с необходимостью разграничения прав по администрированию полученной структуры в среде с децентрализованным администрированием. Можно выделить особую группу администраторов, уполномоченных управлять членством в группах, описывающих должности, и потребовать, чтобы все администраторы на местах обращались к этим уполномоченным администраторам при каждом переходе с должности на должность пользователей, входящих в их зону ответственности, но тогда в результате получится корпоративная сеть с централизованным управлением. Можно всем администраторам на местах предоставить разрешение Add/remove members на универсальные группы, описывающие должности, чтобы они сами могли вносить соответствующие изменения, но тогда они смогут исключать из такой группы «чужих» пользователей, т. е. пользователей, входящих в зону ответственности другого администратора.

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

Для каждой зоны ответственности «местного» администратора следует:

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

Таким образом, для сетей с децентрализованным управлением предлагается следующая схема взаимоотношений: учетная запись - «местная» глобальная доменная группа - универсальная группа должности - универсальная группа доступа к ресурсу - локальная доменная группа - разрешения на доступ к объектам. Соответствующая аббревиатура - AGUULP, см. рис. 4 .

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

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

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

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

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

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

Дополнительный контроль всех настроек, устанавливаемых в рамках реализации подхода 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 или придумать что-то свое. В любом случае всем администраторам желаю успехов в нашем нелегком труде!

Алексей Сотский - преподаватель учебного центра, имеет сертификаты MCSE, MCT. С ним можно связаться по адресу: