После выполнения идентификации и аутентификации необходимо установить полномочия (совокупность прав) субъекта для последующего контроля санкционированного использования вычислительных ресурсов, доступных в АС. Такой процесс называется разграничением (логическим управлением) доступа.
Обычно полномочия субъекта представляются: списком ресурсов, доступных пользователю, и правами по доступу к каждому ресурсу из списка. В качестве вычислительных ресурсов могут быть программы, информация, логические устройства, объем памяти, время процессора, приоритет и т. д.
Обычно выделяют следующие методы разграничения доступа:
разграничение доступа по спискам;
использование матрицы установления полномочий;
парольное разграничение доступа.
При разграничении доступа по спискам задаются соответствия:
каждому пользователю – список ресурсов и прав доступа к ним или
каждому ресурсу – список пользователей и их прав доступа к данному ресурсу.
Списки позволяют установить права с точностью до пользователя. Здесь нетрудно добавить права или явным образом запретить доступ. Списки используются в большинстве ОС и СУБД.
Использование матрицы установления полномочий подразумевает применение матрицы доступа (таблицы полномочий). В указанной матрице (см. таблицу 2.7) строками являются идентификаторы субъектов, имеющих доступ в АС, а столбцами – объекты (информационные ресурсы) АС. Каждый элемент матрицы может содержать имя и размер предоставляемого ресурса, право доступа (чтение, запись и др.), ссылку на другую информационную структуру, уточняющую права доступа, ссылку на программу, управляющую правами доступа и др.
Таблица 2.7
Фрагмент матрицы установления полномочий
c – создание, d – удаление, r – чтение, w – запись, e – выполнение.
Данный метод предоставляет более унифицированный и удобный подход, т. к. вся информация о полномочиях хранится в виде единой таблицы, а не в виде разнотипных списков. Недостатками матрицы являются ее возможная громоздкость и не совсем оптимальное использование ресурсов (большинство клеток – пустые).
Разграничения доступа по уровням секретности и категориям состоят в том, что ресурсы АС разделяются в соответствии с уровнями секретности или категорий.
При разграничении по уровню секретности выделяют несколько уровней, например,: общий доступ, конфиденциально, секретно, совершенно секретно. Полномочия каждого пользователя задаются в соответствии с максимальным уровнем секретности, к которому он допущен. Пользователь имеет доступ ко всем данным, имеющим уровень (гриф) секретности не выше, чем он имеет.
При разграничении по категориям задается и контролируется ранг категории, соответствующей пользователю. Соответственно, все ресурсы АС декомпозируют по уровню важности, причем определенному уровню соответствует некоторый ранг персонала (типа: руководитель, администратор, пользователь).
Парольное разграничение, очевидно, представляет использование методов доступа субъектов к объектам по паролю. При этом используются все методы парольной защиты. Очевидно, что постоянное использование паролей создает неудобства пользователям и временные задержки. Поэтому указанные методы используют в исключительных ситуациях.
На практике обычно сочетают различные методы разграничения доступа. Например, первые три метода усиливают парольной защитой.
В завершении подраздела заметим, что руководящие документы могут регламентировать два вида (принципа) разграничения доступа:
дискретное управление доступом;
мандатное управление доступом.
Дискретное управление доступом представляет собой разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту. Данный вид организуется на базе методов разграничения по спискам или с помощью матрицы.
Мандатное управление доступом регламентирует разграничение доступа субъектов к объектам, основанное на характеризуемой меткой конфиденциальности информации, содержащейся в объектах, и официальном разрешении (допуске) субъектов обращаться к информации такого уровня конфиденциальности. Иначе, для реализации мандатного управления доступом каждому субъекту и каждому объекту присваивают классификационные метки, отражающие их место в соответствующей иерархии. С помощью этих меток субъектам и объектам должны быть назначены классификационные уровни, являющиеся комбинациями уровня иерархической классификации и иерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа. Ясно, что методы разграничения доступа по уровням секретности и категориям являются примерами мандатного управления доступом.
На своей практике веб-разработки я очень часто сталкивался с ситуациями, в которых заказчики ставили конкретную цель, а именно о разделении частей админки относительно доступности тем или иным пользователям. При этом разработка данного модуля велась в контексте расширяемой системы, а то есть с нефиксированым числом модулей, к которым организовуется доступ, ну и, соответственно, неограниченным числом пользователей системы.
Что ж, сама по себе данная тема довольно грузная, и требует определённого времени на анализ и постанувку задачи.
В контексте данной статьи, мы будем вести разработку в контексте некоторой абстрактной информационной системы, со своей инфраструктурой и архитектурой, при этом данная система предоставляет пользователю возможность расширять функционал, а то есть устанавливать новые модули, и соответственно устанавливать права доступа к ним тому либо иному пользователю, зарегистрированному в качестве администратора системы.
Давайте с самого начала обсудим архитектуру модульной системы на выбранной нами псевдо-системе.
Все модули представлены ввиде подключаемых к главному документу (индекс-файлу) вставок. Запрос модуля происходит из строки запроса 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-отдела ИНПП.
- передатчик;
- приёмник;
- сообщения (цифровые данные определённого формата: файл базы данных, таблица, ответ на запрос, текст или изображение);
- средства передачи (физическая передающая среда и специальная аппаратура, обеспечивающая передачу информации).
- Топология локальных сетей. Под топологией компьютерной сети обычно понимают физическое расположение компьютеров сети относительно друг друга и способ соединения их линиями.
- Топология определяет требования к оборудованию, тип используемого кабеля, методы управления обменом, надежность работы, возможность расширения сети. Существует три основных вида топологии сети: шина, звезда и кольцо.
| Локальные сети (LAN, Local Area Network)объединяют абонентов, расположенных в пределах небольшой территории, обычно не более 2–2.5 км. Локальные компьютерные сети позволят организовать работу отдельных предприятий и учреждений, в том числе и образовательных, решить задачу организации доступа к общим техническим и информационным ресурсам. | Глобальные сети (WAN, Wide Area Network)объединяют абонентов, расположенных друг от друга на значительных расстояниях: в разных районах города, в разных городах, странах, на разных континентах (например, сеть Интернет). Взаимодействие между абонентами такой сети может осуществляться на базе телефонных линий связи, радиосвязи и систем спутниковой связи. Глобальные компьютерные сети позволят решить проблему объединения информационных ресурсов всего человечества и организации доступа к этим ресурсам. |
Достоинства:
простота добавления новых узлов в сеть (это возможно даже во время работы сети);
сеть продолжает функционировать, даже если отдельные компьютеры вышли из строя;
недорогое сетевое оборудование за счет широкого распространения такой топологии.
Недостатки:
сложность сетевого оборудования;
сложность диагностики неисправности сетевого оборудования из-за того, что все адаптеры включены параллельно;
обрыв кабеля влечет за собой выход из строя всей сети;
ограничение на максимальную длину линий связи из-за того, что сигналы при передаче ослабляются и никак не восстанавливаются.
Звезда (star), при которой к одному центральному компьютеру присоединяются остальные периферийные компьютеры, причем каждый из них использует свою отдельную линию связи. Весь обмен информацией идет исключительно через центральный компьютер, на который ложится очень большая нагрузка, поэтому он предназначен только для обслуживания сети.
Достоинства:
выход из строя периферийного компьютера никак не отражается на функционировании оставшейся части сети;
простота используемого сетевого оборудования;
все точки подключения собраны в одном месте, что позволяет легко контролировать работу сети, локализовать неисправности сети путем отключения от центра тех или иных периферийных устройств;
не происходит затухания сигналов.
Недостатки:
выход из строя центрального компьютера делает сеть полностью неработоспособной;
жесткое ограничение количества периферийных компьютеров;
значительный расход кабеля.
Кольцо (ring), при котором каждый компьютер передает информацию всегда только одному компьютеру, следующему в цепочке, а получает информацию только от предыдущего в цепочке компьютера, и эта цепочка замкнута. Особенностью кольца является то, что каждый компьютер восстанавливает приходящий к нему сигнал, поэтому затухание сигнала во всем кольце не имеет никакого значения, важно только затухание между соседними компьютерами.
Достоинства:
легко подключить новые узлы, хотя для этого нужно приостановить работу сети;
большое количество узлов, которое можно подключить к сети (более 1000);
высокая устойчивость к перегрузкам.
Недостатки:
выход из строя хотя бы одного компьютера нарушает работу сети;
обрыв кабеля хотя бы в одном месте нарушает работу сети.
В отдельных случаях при конструировании сети используют комбинированную топологию. Например, дерево (tree)– комбинация нескольких звезд.
Каждый компьютер, который функционирует в локальной сети, должен иметь сетевой адаптер (сетевую карту). Функцией сетевого адаптера является передача и прием сигналов, распространяемых по кабелям связи. Кроме того, компьютер должен быть оснащен сетевой операционной системой.
При конструировании сетей используют следующие виды кабелей:
неэкранированная витая пара. Максимальное расстояние, на котором могут быть расположены компьютеры, соединенные этим кабелем, достигает 90 м. Скорость передачи информации - от 10 до 155 Мбит/с; экранированная витая пара. Скорость передачи информации - 16 Мбит/с на расстояние до 300 м.
коаксиальный кабель. Отличается более высокой механической прочностью, помехозащищённостью и позволяет передавать информацию на расстояние до 2000 м со скоростью 2-44 Мбит/с;
волоконно-оптический кабель. Идеальная передающая среда, он не подвержен действию электромагнитных полей, позволяет передавать информацию на расстояние до 10 000 м со скоростью до 10 Гбит/с.
Понятие о глобальных сетях. Глобальная сеть – это объединения компьютеров, расположенных на удаленном расстоянии, для общего использования мировых информационных ресурсов. На сегодняшний день их насчитывается в мире более 200. Из них наиболее известной и самой популярной является сеть Интернет.
В отличие от локальных сетей в глобальных сетях нет какого-либо единого центра управления. Основу сети составляют десятки и сотни тысяч компьютеров, соединенных теми или иными каналами связи. Каждый компьютер имеет уникальный идентификатор, что позволяет "проложить к нему маршрут" для доставки информации. Обычно в глобальной сети объединяются компьютеры, работающие по разным правилам (имеющие различную архитектуру, системное программное обеспечение и т.д.). Поэтому для передачи информации из одного вида сетей в другой используются шлюзы.
Шлюзы (gateway)– это устройства (компьютеры), служащие для объединения сетей с совершенно различными протоколами обмена.
Протокол обмена– это набор правил (соглашение, стандарт), определяющий принципы обмена данными между различными компьютерами в сети.
Протоколы условно делятся на базовые (более низкого уровня), отвечающие за передачу информации любого типа, и прикладные (более высокого уровня), отвечающие за функционирование специализированных служб.
Главный компьютер сети, который предоставляет доступ к общей базе данных, обеспечивает совместное использование устройств ввода-вывода и взаимодействия пользователей называется сервером.
Компьютер сети, который только использует сетевые ресурсы, но сам свои ресурсы в сеть не отдает, называется клиентом (часто его еще называют рабочей станцией ).
Для работы в глобальной сети пользователю необходимо иметь соответствующее аппаратное и программное обеспечение.
Программное обеспечение можно разделить на два класса:
программы-серверы, которые размещаются на узле сети, обслуживающем компьютер пользователя;
программы-клиенты, размещенные на компьютере пользователя и пользующиеся услугами сервера.
Глобальные сети предоставляют пользователям разнообразные услуги: электронная почта, удаленный доступ к любому компьютеру сети, поиск данных и программ и так далее.
Задание №1.
Создайте в папке «Мои документы» папку под именем Почта_1 (цифра в имени соответствует номеру вашего компьютера).
С помощью текстового редактора Word или WordPad создайте письмо к одногруппникам.
Сохраните данный текст в папке Почта_1 своего компьютера в файле письмо1.doc, где 1 – номер компьютера.
Откройте папку другого компьютера, например, Почта_2 и скопируйте в него файл письмо1 из своей папки Почта_1.
В своей папке Почта_1 прочитайте письма от других пользователей, например письмо2. Допишите в них свой ответ.
Переименуйте файл письмо2 .doc в файл письмо2_ответ1.doc
Переместите файл письмо2_ответ1.doc в папку Почта _2 и удалите его из своей папки
Далее повторите п.2-4 для других компьютеров.
Прочитайте сообщения от других пользователей в своей папке и повторите для них действия п.5-8.
Задание №2. Ответить на вопросы и запишите их в тетрадь:
| |
| |
| |
| |
| |
| |
| |
| |
|
Автоматизированная система АСОМИ предусматривает возможность гибкого разграничения прав доступа пользователей к хранимой метрологической информации. Такой подход обеспечивает защиту хранящейся и обрабатываемой информации, а именно:
- ограничение прав на чтение, изменение или уничтожение;
- возможность хранения и передачи информации между объектами АСОМИ в виде, значительно затрудняющем ее распознавание при несанкционированном доступе или техническом обслуживании (в частности, с использованием технологий шифрования);
- обеспечение целостности информации, а также доступности информации для органов управления и уполномоченных пользователей;
- исключение утечки информации при обработке и передаче между объектами вычислительной техники.
Разграничение доступа для пользователей системы АСОМИ реализовано в разрезе следующих групп сущностей: отчетность и операционные данные (протоколы) справочные данные, журналы истории (логирование действий пользователя и данные по истории изменений сущностей), учетные данные (карточки СИ). Рассмотрим далее подробно каждую из групп.
Доступ к учетным данным определяется через следующие концептуальные понятия:
- Лицо, ответственное за обработку текущего статуса средства измерения - это сотрудник предприятия, который в текущем статусе СИ должен выполнить определенные этим статусом действия и перевести СИ в последующий статус в рамках рабочего цикла одной из метрологических работ. Определяется из параметров текущего статуса СИ. Например, таким лицом является лицо, исполняющее роль диспетчера (далее по тексту Диспетчер), принявшее СИ для выполнения ремонта и обязанное его затем передать лицу, исполняющему роль исполнителя ремонта (далее по тексту Исполнитель ремонта).
- Материально-ответственное за СИ лицо - это сотрудник предприятия, который несет материальную ответственность за средство измерения или эксплуатирует его. Определяется в учетной карточке СИ. Как правило, таким лицом является мастер, в ведении которого находится это СИ.
- Руководители "первых двух" лиц - буквально по определению. Определяются из организационной структуры предприятия по следующему принципу: они являются руководителями лиц из первых двух категорий "Лицо, ответственное за обработку текущего статуса СИ" и "Материально-ответственное за СИ лицо"; либо они являются руководителями вышестоящего подразделения предприятия, в состав которого входит (подчиняется) структурное подразделение, где исполнителями работают лица из первых двух категорий. В рамках АСОМИ этот концептуальный принцип приводит к тому, что информация о СИ доступна как всем вышестоящим руководителям Метролога, так и всем вышестоящим руководителям исполнителей тех или иных МР (например, начальник цеха имеет доступ к информации о СИ, за которые ответственны его мастера).
- Лицо, ответственное за метрологический надзор и контроль - это, например, сотрудник поверочного, ремонтного подразделения или метролог структурного подразделения, исполняющий обязанности по надзору и контролю. В соответствии с его обязанностями, он вправе иметь доступ на чтение учетной информации обо всех СИ, закрепленных за ним.
Таким образом, те сотрудники предприятия, которые попадают в одну из четырех (возможно, сразу в несколько) вышеперечисленных категорий, по отношению к конкретному СИ имеют возможность видеть на своем рабочем месте информацию о текущем статусе каждого СИ и, соответственно, данные учетной карточки СИ, включая данные об истории метрологических работ.
При этом сотрудник предприятия, который в данный момент времени ответственен за обработку текущего статуса СИ, имеет право изменять информацию СИ, связанную с этим статусом, и переводить СИ в последующий статус, соответствующий выполняемому рабочему циклу МР, но не имеет права влиять на историю переходов по Диаграмме статусов СИ.
Теперь рассмотрим Правила и порядок доступа к справочным данным. Такие функции как просмотр и использование справочных данных для выполнения своих обязанностей по метрологическому обеспечению доступны всем пользователям АСОМИ.
При этом доступ на пополнение и редактирование справочных данных разрешается только сотрудникам предприятия, исполняющим в системе АСОМИ роль администратора или контролера. Они полностью ответственны за актуальность и корректность информации, содержащейся в справочниках. При заполнении справочников, касающихся структуры прав доступа в АСОМИ, используются данные из справочников, входящих в справочный блок "Структура прав доступа в АСОМИ". При заполнении специфических (дополнительных) справочников используются данные из НТД (нормативно-технической документации) на СИ, данных Госреестра СИ, допущенных к применению на территории РФ, других достоверных источников.
Правила и порядок доступа к отчетности и операционным данным (протоколам) организован следующим образом. Доступ к реализованной в АСОМИ стандартной отчетности организуется по ролям в системе. При этом для каждой должности указывается тот перечень стандартных отчетов (выборка из общего перечня всех стандартных отчетов АСОМИ), которые может формировать со своего рабочего места сотрудник, занимающий данную должность.
В рамках отчетности может быть организован доступ к специальным функциям. Примером такой функции может являться поиск и получение информации о любом из учтенных в системе СИ по различным его параметрам, к примеру, мастер будет иметь возможность вывести в виде отчета список всех СИ, зарегистрированных в АСОМИ, для того, чтобы, например, подыскать варианты замены своего СИ на такое же СИ, которое находится на консервации в соседнем цехе.
Доступ к операционным данным (протоколам работы пользователей) разрешен только Администраторам АСОМИ и Главному метрологу предприятия.
Правила и порядок назначения и изменения доступа к информационным данным могут быть назначены или изменены только Администратором АСОМИ.
Если Вас заинтересовал данный продукт или возникли вопросы,
которые Вы хотели бы задать, пишите:
С проблемой предоставления доступа в той или иной форме приходилось сталкиваться каждому системному администратору. Это самая трудоемкая задача, хотя бы просто в силу большого количества как ресурсов, так и пользователей, которым требуется такого рода доступ. Дело осложняется разнородным составом ресурсов. Это могут быть папки на файловом сервере или даже отдельные файлы, сетевые принтеры и очереди печати, базы данных, объекты 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. С ним можно связаться по адресу: