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

КонецПроцедуры

КонецЕсли;

Функция ПровДостПрава(Право)

Запрос = Новый Запрос;

Запрос.Текст = "ВЫБРАТЬ

| ЗначенияДопПрав.Значение

Выборка.Следующий();

Возврат Выборка.Значение;

Возврат Ложь;

КонецЕсли;

КонецФункции

Процедура ПриОткрытии()

КонецПроцедуры

На сегодняшний день, на российском рынке автоматизации учета лидируют прикладные решения разработанные на базе платформы разработанной Российской фирмой «1С». По данным социологических исследований опубликованных в сети Интернет, в России и странах СНГ в 90% организаций для автоматизации учета используются данные системы. Также данные системы не имеют аналогов для полноценной автоматизации бухгалтерского учета по РСБУ. Так как бухгалтерская и налоговая отчетность, обрабатываемая и хранимая в подобных системах составляет из себя конфиденциальную информацию любой организации, то эту информацию необходимо защищать на должном уровне. Кроме бухгалтерского учета, посредством данных систем было автоматизировано много участков учета (например кадровый учет и расчет заработной платы, оперативный и управленческий учет, учет взаимоотношений с клиентами и т.п.).

В данной работе, я хочу описать методы и способы защиты информации в базах данных построенных на основе систем «1С Предприятие».

В настоящий момент активно используются 3 версии «1С», а именно версии 7.7, 8.1 и 8.2. Версия 7.7 уже морально себя изжила и устарела, и я не вижу практического смысла рассматривать данную систему в качестве примера. Так как версия 8.2 поступила в официальную продажу совсем недавно, то я остановился на версии «1С Предприятие 8.1». В качестве примера, была взята разработанная ранее учебная система для автоматизации задач оперативного и бухгалтерского учета и расчета заработной платы.

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

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

Необходимо установить следующие права на доступ к объектам:

Создать права администратора, для полного доступа ко всем данным.

Для руководителя организации предоставить права к отчетам и права на просмотр всех документов.

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

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

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

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

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

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

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

Рисунок 1. Основные объекты конфигурации.

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

На рисунке 2 предоставлен пример установления полных прав для администратора системы.

Рисунок 2. Установка всех прав для роли.

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

Рисунок 3. Пример установления прав для конкретного пользователя.

Разграничение прав на уровне записей.

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

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

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

Процедура ПриНачалеРаботыСистемы()

ПараметрыСеанса.ТекущийИсполнитель= Справочники.Сотрудники.НайтиПоКоду(ИмяПользователя());

КонецПроцедуры

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

Кроме механизма ролей, в программе можно настроить доступ к данным посредством написания процедур и функций на встроенном в «1С Предприятие» языке. В качестве примера можно привести возможность системы открыть форму (визуальный элемент с которым работает пользователь) только для просмотра при выполнении определенных условий, например:

Если ПараметрыСеанса.ТекущийПользователь =

Справочники.Сотрудники.НайтиПоНаименованию(«Иванов») Тогда

ЭтаФорма.ТолькоПросмотр = Истина;

КонецЕсли;

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

Функция ПровДостПрава(Право)

Запрос = Новый Запрос;

Запрос.Текст = "ВЫБРАТЬ

| ЗначенияДопПрав.Значение

| РегистрСведений.ЗначенияДопПрав КАК ЗначенияДопПрав

| ЗначенияДопПрав.Сотрудник = &Сотрудник

| И ЗначенияДопПрав.Право = &Право";

Запрос.УстановитьПараметр("Сотрудник",

ПараметрыСеанса.ТекущийИсполнитель);

Запрос.УстановитьПараметр("Право", Право);

Результат = Запрос.Выполнить();

Если Не Результат.Пустой() Тогда

Выборка = Результат.Выбрать();

Выборка.Следующий();

Возврат Выборка.Значение;

Возврат Ложь;

КонецЕсли;

КонецФункции

На форме документа Расходная накладная есть кнопка «Печать» отвечающая за формирование печатной формы данного документа. При открытии данного документа посредством следующего программного текста установим доступность данной кнопки для пользователя:

Процедура ПриОткрытии()

ЭлементыФормы.ОсновныеДействияФормы.Кнопки.Печать.

Доступность = ПровДостПрава(Перечисления.

ДопПрава.ПечатьНепроведенныхДокументов);

КонецПроцедуры

Назначение ролей и средств идентификации пользователей.

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

Рисунок 5. Список пользователей, роли и средства идентификации.

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

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

Габец А.П., Гончаров Д.И. 1С:Предприятие 8.1. Простые примеры разработки. – М.: ООО «1С-Паблишинг»; СПБ: Питер, 2008. – 383 с.: ил. + CD-ROM.

1С:Предприятие 8.2. Руководство разработчика. Часть 1. – М.: ЗАО «1С», 2009 – 638 с.: ил.

Радченко М.Г. 1С:Предприятие 8.1. Практическое пособие разработчика. Примеры и типовые приемы. М.: ООО «1С-Паблишинг», 2008. 874 с.: ил.

Белоусов П.С. Методические материалы курса обучения «Конфигурирование платформы «1С:Предприятие 8.1». – М.: ЗАО «1С», 2007 – 272 с.: ил.

Пример несанкционированной попытки входа в системы.

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

Пример разграничения прав на уровне записей.

Пример программной реализации недоступности кнопки «Печать» в документе «Расходная накладная».

На просторах России много фирм и мелких предприятий не имеют в штате своего системного администратора на постоянной основе или приходящего время от времени. Фирма растёт и рано или поздно одной расшаренной папки в сети, где каждый может делать что захочет, становится мало. Требуется разграничение доступа для разных пользователей или групп пользователей на платформе MS Windows. Линуксоидов и опытных админов просьба не читать статью.

Самый лучший вариант - взять в штат опытного админа и задуматься о покупке сервера. Опытный админ на месте сам решит: поднимать ли MS Windows Server с Active Directory или использовать что-то из мира Linux.

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

Прежде чем начать хотелось бы разжевать пару моментов:

• Любая операционная система "узнаёт" и "различает" реальных людей через их учётные записи. Должно быть так: один человек = одна учётная запись .
• В статье описывается ситуация, что в фирме нет своего админа и не куплен, к примеру, MS Windows Server. Любая обычная MS Windows одновременно обслуживает по сети не более 10 для WinXP и 20 человек для Win7. Это сделано фирмой Microsoft специально, чтобы клиентские Windows не перебегали дорогу серверам Windows и вы не портили бизнес Microsoft. Помните число 10-20 и когда в вашей фирме будет более 10-20 человек, вам придётся задуматься о покупке MS Windows Server или попросить кого-либо поднять вам бесплатный Linux Samba сервер, у которого нет таких ограничений.
• Раз у вас нет грамотного админа, то ваш обычный комп с клиентской MS Windows будет изображать из себя файловый сервер. Вы вынуждены будете продублировать на нём учётные записи пользователей с других компьютеров, чтобы получать доступ к расшаренным файлам. Другими словами, если есть в фирме ПК1 бухгалтера Оли с учётной записью olya, то и на этом "сервере" (именую его в дальнейшем как WinServer) нужно создать учётную запись olya с таким же паролем, как и на ПК1.
• Люди приходят и уходят. Текучесть кадров есть везде и если вы, тот бедный человек, который не админ и назначен (вынужден) поддерживать ИТ вопросы фирмы, то вот вам совет. Делайте учётные записи, не привязанные к личности. Создавайте для менеджеров - manager1, manager2. Для бухгалтеров - buh1, buh2. Или что-то подобное. Ушёл человек? Другой не обидится, если будет использовать manager1. Согласитесь это лучше, чем Семёну использовать учётную запись olya, так как влом или некому переделывать и уже всё работает 100 лет.
• Забудьте такие слова как: "сделать пароль на папку". Те времена, когда на ресурсы накладывался пароль давным давно прошли. Поменялась философия работы с различными ресурсами. Сейчас пользователь входит в свою систему с помощью учётной записи (идентификация), подтверждая себя своим паролем (аутентификация) и ему предоставляется доступ ко всем разрешённым ресурсам. Один раз вошёл в систему и получил доступ ко всему - вот что нужно помнить.
• Желательно выполнять нижеперечисленные действия от встроенной учётной записи Администратор или от первой учётной записи в системе, которая по умолчанию входит в группу Администраторы.

Приготовление.

В Проводнике уберите упрощённый доступ к нужным нам вещам.

• MS Windows XP. Меню Сервис - Свойства папки - Вид. Снять галочку Использовать мастер общего доступа
• MS Windows 7. Нажмите Alt. Меню Сервис - Параметры папок - Вид. Снять галочку Использовать простой общий доступ к файлам .

Создайте на вашем компьютере WinServer папку, которая будет хранить ваше богатство в виде файлов приказов, договоров и так далее. У меня, как пример, это будет C:\dostup\. Папка обязательна должна быть создана на разделе с NTFS.

Доступ по сети.

На данном этапе нужно выдать в доступ по сети (расшарить - share) папку для работы с ней другими пользователями на своих компьютерах данной локальной сети.

И самое главное! Выдать папку в доступ с полным разрешением для всех! Да да! Вы не ослышались. А как же разграничение доступа?

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

• MS Windows XP. На нужной папке (C:\dostup\) правой клавишей мыши и там Свойства. Вкладка Доступ - Полный доступ .
• MS Windows 7. На нужной папке (C:\dostup\) правой клавишей мыши и там Свойства. Вкладка Доступ - Расширенная настройка. Ставим галочку Открыть общий доступ к этой папке . Заполняем Примечание. Жмём Разрешение. Группа Все должна иметь по сети право Полный доступ .

Пользователи и группы безопасности.

Нужно создать необходимые учётные записи пользователей. Напоминаю, что если на многочисленных ваших персональных компьютерах используются различные учётные записи для пользователей, то все они должны быть созданы на вашем "сервере" и с теми же самыми паролями. Этого можно избежать, только если у вас грамотный админ и компьютеры в Active Directory. Нет? Тогда кропотливо создавайте учётные записи.

• MS Windows XP.
  Локальные пользователи и группы - Пользователи. Меню Действие - Новый пользователь.
• MS Windows 7. Панель Управления - Администрирование - Управление компьютером.
  Локальные пользователи и группы - Пользователи. Меню Действие - Создать пользователя.

Теперь очередь за самым главным - группы! Группы позволяют включать в себя учётные записи пользователей и упрощают манипуляции с выдачей прав и разграничением доступа.

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

• MS Windows XP. Панель Управления - Администрирование - Управление компьютером.
  
• MS Windows 7. Панель Управления - Администрирование - Управление компьютером.
  Локальные пользователи и группы - Группы. Меню Действие - Создать группу.

Нужно включить в нужные группы нужные учётные записи. Для примера, на группе Бухгалтеры правой клавишей мыши и там Добавить в группу или Свойства и там кнопка Добавить. В поле Введите имена выбираемых объектов впишите имя необходимой учётной записи и нажмите Проверить имена . Если всё верно, то учётная запись изменится к виду ИМЯСЕРВЕРА\учётная_запись. На рисунке выше, учётная запись buh3 была приведена к WINSERVER\buh3.

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

Стоит ли заморачиваться с группой, если в ней будет одна учётная запись? Считаю, что стоит! Группа даёт гибкость и маневренность. Завтра вам понадобится ещё одному человеку Б дать те же права, что и определённому человеку с его учётной записью А. Вы просто добавите учётную запись Б в группу, где уже имеется А и всё!

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

Права доступа.

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

Вот и добрались до этапа, где непосредственно и происходит магия разграничения прав доступа для различных групп, а через них и пользователям (точнее их учётным записям).

Итак, у нас есть директория по адресу C:\dostup\, которую мы уже выдали в доступ по сети всем сотрудникам. Внутри каталога C:\dostup\ ради примера создадим папки Договора, Приказы, Учёт МЦ. Предположим, что есть задача сделать:

• папка Договора должна быть доступна для Бухгалтеров только на чтение. Чтение и запись для группы Менеджеров.
• папка УчётМЦ должна быть доступна для Бухгалтеров на чтение и запись. Группа Менеджеров не имеет доступа.
• папка Приказы должна быть доступна для Бухгалтеров и Менеджеров только на чтение.

На папке Договора правой клавишей и там Свойства - вкладка Безопасность. Мы видим что какие-то группы и пользователи уже имеют к ней доступ. Эти права были унаследованы от родителя dostup\, а та в свою очередь от своего родителя С:

Мы прервём это наследование прав и назначим свои права-хотелки.

Жмём кнопку Дополнительно - вкладка Разрешения - кнопка Изменить разрешения .

Сначала прерываем наследование прав от родителя. Снимаем галочку Добавить разрешения, наследуемые от родительских объектов. Нас предупредят, что разрешения от родителя не будут применяться к данному объекту (в данном случае это папка Договора). Выбор: Отмена или Удалить или Добавить. Жмём Добавить и права от родителя останутся нам в наследство, но больше права родителя на нас не будут распространяться. Другими словами, если в будущем права доступа у родителя (папка dostup) изменить - это не скажется на дочерней папке Договора. Заметьте в поле Унаследовано от стоит не унаследовано . То есть связь родитель - ребёнок разорвана.

Теперь аккуратно удаляем лишние права, оставляя Полный доступ для Администраторов и Система. Выделяем по очереди всякие Прошедшие проверку и просто Пользователи и удаляем кнопкой Удалить.

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

Мы ставим галочку Заменить все разрешения дочернего объекта на разрешения, наследуемые от этого объекта и жмём Ок. Возвращаемся назад и снова Ок, чтобы вернуться к простому виду Свойства.

Данное окно позволит упрощённо достигнуть желаемого. Кнопка Изменить выведет окно "Разрешения для группы".

Жмём Добавить. В новом окне пишем Бухгалтеры и жмём "Проверить имена" - Ок. По умолчанию даётся в упрощённом виде доступ "на чтение". Галочки в колонке Разрешить автоматически выставляются "Чтение и выполнение", "Список содержимого папки", "Чтение". Нас это устраивает и жмём Ок.

Теперь по нашему техническому заданию нужно дать права на чтение и запись для группы Менеджеры. Если мы в окне Свойства, то снова Изменить - Добавить - вбиваем Менеджеры - Проверить имена. Добавляем в колонке Разрешить галочки Изменение и Запись.

Теперь нужно всё проверить!

Следите за мыслью. Мы приказали, чтобы папка Договора не наследовала права от свого родителя dostup. Приказали дочерним папкам и файлам внутри папки Договора наследовать права от неё.

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

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

Зайдите в папку Договора и создайте тестовый файл договор1.txt

На нём щелчок правой клавишей мыши и там Свойства - вкладка Безопасность - Дополнительно - вкладка Действующие разрешения.

Жмём Выбрать и пишем учётную запись любого бухгалтера, к примеру buh1. Мы видим наглядно, что buh1 получил права от своей группы Бухгалтеры, которые обладают правами на чтение к родительской папке Договора, которая "распространяет" свои разрешения на свои дочерние объекты.

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

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

Итог.

• Используйте разделы NTFS.
• Когда разграничиваете доступ на папки (и файлы), то манипулируйте группами.
• Создавайте учётные записи для каждого пользователя. 1 человек = 1 учётная запись.
• Учётные записи включайте в группы. Учётная запись может входить одновременно в разные группы. Если учётная запись находится в нескольких группах и какая-либо группа что-то разрешает, то это будет разрешено учётной записи.
• Колонка Запретить (запрещающие права) имеют приоритет перед Разрешением. Если учётная запись находится в нескольких группах и какая-либо группа что-то запрещает, а другая группа это разрешает, то это будет запрещено учётной записи.
• Удаляйте учётную запись из группы, если хотите лишить доступа, которого данная группа даёт.
• Задумайтесь о найме админа и не обижайте его деньгами.

Задавайте вопросы в комментариях и спрашивайте, поправляйте.

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

Основные понятия

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

Определение 1

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

Определение 2

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

Определение 3

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

Определение 4

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

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

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

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

Дискреционная

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание локальной сети

Организация защиты данных в сети

Разграничение прав доступа в сети. Подключение компьютера к сети. Администрирование компьютерной сети.

Практическое занятие №15.

Разграничение прав доступа –это о граничение доступа к данным некоторого слоя информационной системы.

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

«Администрирование» - это папка в панели управления, содержащая средства для системных администраторов и опытных пользователей.

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

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

В локальной сети существует 4 уровня защиты файл-сервера:

• защита именем регистрации и паролем;

· защита правами опекунства К файлам и подкаталогам могут применяться права доступа (чтение, изменение, удаление файла и т.д);

• защита максимальными правами каталога (можно не дать пользователям сети возможность употребить свои права опекунств);

· защита атрибутами файла (одновременный доступ к файлу нескольких пользователей, только один пользователь, чтение, запись, переименование и удаление файла);

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

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

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

Приступаем к их настройке. Жмем правой кнопкой на нужное Локальное подключение - Свойства - Протокол подключения (TCP/IP).

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

IP-адрес: 192.168.1.*

Маска подсети: 255.255.255.0 (оставляем по-умолчанию)

Нажимаем OK. Производим те же действия для остальных компьютеров, изменяя только последнюю цифру IP-адреса в указанном диапазоне.

Все, на этом настройка сетевых плат завершена и следует приступить к настройкам Группы.

Найдите на Рабочем столе значок Мой компьютер и нажмите на него правой клавишей мыши. В открывшемся меню выберите Свойства и перейдите во вкладку Имя компьютера. Здесь вы сможете выбрать название вашего ПК и рабочую группу, к которой он будет принадлежать. Нажимайте Изменить.

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

В итоге у вас должны получиться подобные компьютеры (Имя компьютера - Рабочая группа - IP-адрес - Маска подсети):

COMP1 - GROUP - 192.168.1.1 - 255.255.255.0
COMP2 - GROUP - 192.168.1.2 - 255.255.255.0
COMPX - GROUP - 192.168.1.X - 255.255.255.0

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

Общий доступ

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

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

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

В Сетевом окружении откроется список всех доступных ПК в локальной сети.

Фрагменты.