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

27.04.2019

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

Назначение прав доступа к объектам базы данных для учетных записей, хранящихся в файле рабочей группы, выполняется в Access с помощью диалогового окна Разрешения (User and Group Permissions).

Чтобы открыть диалоговое окно для назначения прав доступа к объектам базы данных:

  1. Откройте защищенную базу данных, подключив необходимый файл рабочей группы.
  2. Зарегистрируйтесь с именем пользователя, обладающего административными правами.
  3. Выберите команду Сервис, Защита, Разрешения (Tools, Security, User and Group Permissions). Появится диалоговое окно Разрешения (User and Group Permissions) (рис. 20.6).

В диалоговом окне Разрешения есть две вкладки: Разрешения (Permissions) и Смена владельца (Change Owner). Рассмотрим вкладку Разрешения. (О функциях второй вкладки рассказывается в разд. "Предоставление права на владение объектами базы данных" этой главы.) С помощью данной вкладки можно определить права доступа к конкретным объектам базы данных для конкретных пользователей и групп. В поле Пользователь (Current User) отображается имя пользователя, которое было применено для регистрации в момент открытия базы данных. В зависимости от того, обладает ли текущий пользователь административными правами или нет, ему будут позволены или запрещены просмотр и изменение прав доступа к объектам базы данных.

Рис. 20.6. Диалоговое окно Разрешения

Чтобы назначить права доступа к объектам базы данных конкретной группе:

  1. На вкладке Разрешения выберите переключатель группы (Groups).
  2. В списке Пользователи и группы (User/Group Name) отобразится список всех групп в рабочей группе. Выделите в этом списке группу, права доступа которой нужно изменить.
  3. ОК.

Чтобы назначить права доступа к объектам базы данных конкретному пользователю:

  1. На вкладке Разрешения выберите переключатель пользователи (Users).
  2. В списке Пользователи и группы (User/Group Name) отобразится список всех пользователей в рабочей группе. Выделите в этом списке пользователя, права доступа которого нужно изменить.
  3. Измените права доступа к объектам базы данных и нажмите кнопку ОК.

Чтобы назначить выбранному пользователю или группе права доступа к объекту базы данных:

  1. На вкладке Разрешения в раскрывающемся списке Тип объекта (Object Type) выберите тип объекта (Таблица (Table), Запрос (Query), Форма (Form), Отчет (Report) или Макрос (Macro)).

Замечание

В списке имен объектов не будут отображаться скрытые объекты, если в диалоговом окне Параметры (Options) на вкладке Вид (View) не установлен флажок скрытые объекты (Hidden Objects), позволяющий отображать скрытые объекты.

  1. В списке Имя объекта (Object Name) выделите имя объекта, права доступа к которому требуется изменить.
  2. Чтобы предоставить определенный вид доступа, установите соответствующий флажок в группе Разрешения (Permissions). Чтобы запретить определенный вид доступа, сбросьте соответствующий флажок в этой группе.
  3. Нажмите кнопку Применить (Apply) иначе при выборе другого пользователя, группы или другого объекта появится диалоговое окно, требующее подтверждения сделанных изменений. Чтобы подтвердить изменения, нажмите кнопку ОК.

Чтобы назначить пользователю или группе права доступа к базе данных:

  1. На вкладке Разрешения в раскрывающемся списке Тип объекта (Object Type) выберите элемент База данных (Database).
  2. В списке Имя объекта. (Object Name) отобразится элемент <Текущая база дан-ных> ().
  3. Применить (Apply).

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

  1. На вкладке Разрешения в раскрывающемся списке Тип объекта (Object Type) выберите тип объекта (например, Форма (Form)).
  2. В списке Имя объекта (Object Name) выделите элемент, обозначающий новые объекты заданного типа, права доступа к которым требуется изменить (например, <Новые формы> ()).
  3. Установите необходимые разрешения и нажмите кнопку Применить (Apply).

Замечание

Установка или сброс флажков некоторых разрешений влечет установку или сброс других флажков разрешений, поскольку предоставление или отмена определенного вида доступа может привести к предоставлению или отмене другого вида доступа, связанного с измененным. Например, предоставление доступа к таблице вида Чтение данных (Read Data) влечет предоставление доступа Чтение макета (Read Design), а отмена доступа Обновление данных (Update Data) влечет отмену доступа Изменение макета (Modify Design).



Похожие статьи
Типы
  • Роутеры
  • Жесткие диски
  • Не включается
  • Принтеры
  • Тормозит
  • Зависает
  • Вирусы
  • Планшеты
Популярные статьи
Новые статьи

ДЕЙСТВИЯ \ ПРАВА

Нет доступа

Чтение / Проведение

Просмотр объекта

Запрещен

Разрешен

Разрешен

Разрешен

Редактирование объекта

Запрещен

Запрещен

Запрещен

ДЕЙСТВИЯ \ ПРАВА

Нет доступа

Чтение / Проведение

1. Работа с документами

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

Если среди реквизитов есть недоступные элементы, то документ невидим в журнале (соответственно, нельзя открыть форму документа).

Если нет недоступных реквизитов, но есть с правом Чтение , то проведение, отмена проведения из формы документа запрещены. Если документ проведен, то форма открывается на чтение. Если он не проведен, то форма открывается на редактирование, т.е. можно изменять значения его реквизитов (учитывая пункты 2 и 3) и сохранять его (без проведения).

Если ко всем реквизитам документа право доступа не ниже, чем Чтение/Проведение , то с ним доступны любые действия (учитывая пункты 2 и 3).

Для документов типа Проформа также учитываются права на Вид проформы :

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

Проформы данного вида видны в журнале, но документ открывается только для просмотра. Редактирование, сохранение, ввод нового, пометка удаления, проведение и отмена проведения недоступны.

Дает право проводить проформы данного вида, отменять проведение, изменять значения их реквизитов (учитывая пункты 2 и 3), устанавливать пометку на удаление на документы. При этом менять настройки вида проформы нельзя.

Полный доступ (учитывая пункты 2 и 3).

1.2. ДокументыБюджетная операция и Реестр

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

Примечание1 : Права на все реквизиты (в том числе и на Вид проформы ) объединяются. То есть, если на один реквизит (или на Вид проформы ) право Чтение , а на другой реквизит право Нет доступа , то открыть документ нельзя.

Примечание2: В документах Регламентный документ безопасность отключена, кроме той, что описана в пунктах 2 и 3.

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

1.3. Документы Сессия и Задача

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

2. Просмотр и редактирование реквизитов

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

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

Значение реквизита отображается и его можно изменить (учитывая пункты 3 и 4). При этом доступ к самому объекту, используемому в качестве значения реквизита, остается на уровне чтения.

Все права (учитывая пункты 3 и 4).

3. Выбор значений реквизитов в документах, регламентных процедурах и проводках

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

Значения нельзя выбрать (они просто не отображаются на форме выбора)

Значения можно выбирать

4. Выбор значений для прочих производных объектов

Запрещенные значения нельзя выбрать (они просто не отображаются на форме выбора)

Значения можно выбирать

5. Просмотр и редактирование проводок по документам в Редакторе проводок

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

Если в проводке есть хотя бы одно запрещенное значение, то она открывается только на чтение.

Если в проводке у всех значений право доступа не ниже, чем Чтение/Проведение , то с ней возможны любые действия (учитывая пункты 2 и 3).

6. Просмотр отчетов

6.1 Если в сформированных отчетах Оборотно-сальдовая ведомость по счету , Оборотно-сальдовая ведомость , Карточка счета , Операционный отчет по счету или Управленческом отчете присутствуют значения субконто, ссылающиеся на базовые объекты с настроенными правами, то они будут отображаться следующим образом (в зависимости от прав базовых объектов):

Вместо значения отобразятся системное сообщение "Объект не найден" и уникальный идентификатор этого объекта.

Отобразится значение.

6.2 Во всех отчетах суммы по запрещенным пользователю измерениям не отображаются и становятся полностью "вырезанными" из отчета.

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

6.4 В отчетах нельзя производить фильтрацию по запрещенным значениям.

Если для пользователя указано право на папку Нет доступа , а на элемент в этой папке доступ разрешён (права Чтение и проведение или Чтение и запись ), то доступ к элементу всё равно будет запрещён.

При попытке открыть объект системы, доступный только Администратору , обычному пользователю будет выдано сообщение о нарушении прав доступа.

ЗАМЕЧАНИЕ О РАБОТЕ БЕЗОПАСНОСТИ ПРИ РАСЧЕТЕ ФОРМУЛ В ДОКУМЕНТАХ.

Если в реквизите документа настроен расчет значения по формуле «через точку», а у пользователя нет права доступа ко всем базовым объектам, используемым в формуле, то для него значение реквизита отобразится пустым.

Например , в документе есть два реквизита: А и Б . Реквизит А ссылается на справочник с доп. свойством Х , а Б рассчитывается как А.Х (то есть, должен автоматически заполняться значением доп. свойства выбранного в реквизите А элемента). Тогда, если у пользователя нет доступа к справочнику, на который ссылается А , и/или справочнику, на который ссылается Х , то в документе для него значение реквизита Б не отобразится.

В журналах документов ИНТАЛЕВ присутствует кнопка Проверка прав (работает, когда в системе включена безопасность). Нажав ее, простой пользователь может увидеть свои права на действия с выбранным документом.

См. также:

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

Права в SQL-сервер можно разделить на 3 категории:

    Разрешение для объектов.

Работа с данными и выполнение хранимых процедур требует наличие класса доступа, называемого «разрешением для объектов». Разрешение для объектов контролирует возможность выполнения команд Select, Insert, Update и Delete для таблицы представлений. Действия с хранимыми процедурами контролируются разрешением либо запрещением их выполнения, т.е. предоставлением или запрещением команды EXECUTE.

    Разрешение для команд Transact SQL.

Этот класс разрешений контролирует возможность создания объекта в БД, а также создание самой БД и выполнение процедур резервного копирования (Create view, create table и т.д.).

    Неявное разрешение.

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

В SQL-сервер существует возможность контролировать права доступа не только на уровне таблиц, но и на уровне колонок. Для предоставления прав доступа используется команда GRANT.

{ALL/permissions [..n]}

{[(column [..n])] ON

| ON {stored_procedure}

TO security_account

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

GRANT {ALL/Statement [..n]}

TO security_account [...n]

Запрещение доступа

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

{ALL/permissions [..n]}

{[(column [..n])] ON

| ON {table/view} [(column[..n])]

| ON {stored_procedure}

TO security_account [..n]

Для запрещения выполнения команд Transact SQL:

DENY {ALL/Statement [..n]}

TO security_account [...n]

Неявное отклонение доступа

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

Для неявного отклонения доступа к объектам БД используется команда REVOKE.

{ALL/permissions [..n]}

{[(column [..n])] ON

| ON {table/view} [(column[..n])]

| ON {stored_procedure}

TO security_account [..n]

Для неявного отклонения разрешений на использование команд Transact SQL:

REVOKE {ALL/Statement [..n]}

TO security_account [...n]

Значения параметров команд:

ALL – означает, что пользователю будут предоставлены все возможные разрешения.

Permissions – список доступных операций, которые предоставляются пользователю. Можно предоставлять одновременно несколько разрешений.

Statement – предоставление разрешений на выполнение команд Transact SQL.

Security_account – указывается имя объекта системы безопасности, которую необходимо включить в роль. Это могут быть как учетные записи SQL-сервер, так и группы пользователей Windows.

With Grant Option – использование данного параметра позволяет пользователю, которому предоставляются права, назначать права на доступ к объекту для других пользователей.

As role/group – этот параметр позволяет указать участие пользователя в роли, которому предоставляется возможность предоставлять права другим пользователям.

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

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

Профиль пользователя определяет следующие параметры:

  • класс пользователя - категорию, в зависимости от принадлежности к которой пользователь имеет особые права;
  • принадлежащие и доступные объекты - список объектов, которыми пользователь владеет и к которым имеет доступ;
  • права на объекты - права доступа к объектам из вышеуказанного списка;
  • привилегированные команды и специальные права - информация о всех привилегированных командах и специальных правах пользователя;
  • пароль - код, обязательный для входа в систему при всех уровнях защиты, кроме 10;
  • текущая библиотека - место, куда по умолчанию помещается новый объект, созданный пользователем;
  • начальная программа и меню - поле, задающее программу и меню, активизируемые сразу после входа пользователя в систему;
  • ограничение возможностей - параметр, запрещающий пользователю ввод команд и ограничивающий его возможности выбором пунктов меню;
  • ограничение сессий для устройства - параметр, ограничивающий устройство пользователя одной сессией;
  • максимальный объем памяти - поле, задающее общий объем дискового пространства для объектов, которыми владеет пользователь;
  • максимальный приоритет - поле, задающее максимальный приоритет планировщика, который может применяться пользователем (более подробно будет обсуждаться в "Управление процессами");
  • специальная среда - поле, задающее среду, в которой будет работать пользователь (например, System/36).

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

Класс пользователя

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

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

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

Объекты, принадлежащие и доступные

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

Права доступа к объектам

К каждому объекту AS/400 может быть предоставлено восемь видов доступа, а именно:

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

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

  • "все" (all) - объединяет все восемь прав;
  • "изменение" (change) - объединяет права на оперирование объектом, чтение, добавление, удаление и обновление;
  • "использование" (use) - объединяет права на оперирование объектом и чтение;
  • "исключение" (exclude) - не дает никаких прав на использование объекта; перекрывает наличие общих или групповых в связи с порядком проверки прав доступа (рассматривается далее).

Привилегированные команды и специальные права

Каждый профиль пользователя содержит информацию о привилегированных командах и специальных правах пользователя. Некоторые привилегированные команды MI могут выполняться только теми пользователями, профили которых разрешают это делать. Например, профиль для начальника защиты создается с возможностью исполнять команду "PWRDWNSYS" (Power Down System), останавливающую работу машины. По очевидным причинам эта привилегированная команда не доступна обычным пользователям. Также есть набор специальных прав, которые могут быть предоставлены лишь избранным пользователям. Эти специальные права связаны с такими операциями, как подвешивание объектов, управление процессами, выполнение операций загрузки/ дампа и использование низкоуровневых сервисных средств.

Хотя все привилегированные команды и специальные атрибуты могут быть заданы в профиле пользователя по отдельности, OS/400 объединяет команды и права в шесть групп специальных прав:

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

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

Заимствование прав программой

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

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

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

Группирование прав

На AS/400 есть три метода группирования прав. Списки прав и профили групп упрощают администрирование защиты, устраняют необходимость индивидуального подхода к пользователям или объектам. Держатели прав ( authority holders ) были введены IBM еще в среде System/36.

BC/NW 2009; №2 (15):11

BC / NW 2009; №2 (15): 11 . 4

АНАЛИЗ СРЕДСТВ РАЗГРАНИЧЕНИЯ ДОСТУПА К ОБЪЕКТАМ В ОПЕРАЦИОННЫХ СИСТЕМАХ MICROSOFT WINDOWS И LINUX

Хорев П.Б.

(ГОУВПО «Московский энергетический институт (технический университет)», Россия)

Основу политики безопасности для компьютерной системы любой организации составляют правила разграничения доступа к объектам компьютерной системы. Разграничение доступа к компьютерным ресурсам базируется на различных моделях управления доступом. В данном докладе будут представлены результаты сравнительного анализа средств разграничения доступа к объектам операционных систем Microsoft Windows и Linux .

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

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

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

В операционных системах Microsoft Windows и операционных системах клона Unix обычно применяется дискреционное управление доступом к объектам. Объекты разграничения доступа в Windows имеют дескриптор безопасности, содержащий информацию о владельце объекта (его идентификаторе безопасности SID , Security Identifier ) и дискреционном списке управления доступом к объекту (Discretionary Access Control List , DACL ), правом редактирования которого обладают владелец объекта и администратор. Владелец файла может лишить администратора права изменения разрешений на доступ к объекту. Администратор обладает специальной привилегией смены владельца на другого пользователя, обладающего такой же специальной привилегией (например, на самого себя).

Разграничение доступа к файлам и папкам возможно с помощью Проводника Windows (вкладки Безопасность функций Свойства контекстного меню выделенного объекта), принтеру – с помощью функции Принтеры и факсы Панели управления (вкладки Безопасность функции Свойства выделенного принтера), реестру Windows – с помощью Редактора реестра regedit .exe (функции Разрешения контекстного меню выделенного раздела).

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

- обзор папок (выполнение файлов);

- содержание папки (чтение данных из файла);

- чтение атрибутов;

- чтение дополнительных атрибутов;

- создание файлов (запись данных в файл);

- создание папок (дозапись данных в файл);

- запись атрибутов;

- запись дополнительных атрибутов;

- удаление подпапок и файлов (только для папок).

Стандартные права доступа к объектам операционной системы Windows не зависят от типа объекта. Определены следующие стандартные права доступа;

- удаление;

- чтение разрешений;

- смена разрешений (для реестра это право названо Запись DAC );

- смена владельца;

- синхронизация (для реестра это право названо Уведомление).

Каждое из родовых разрешений представляет собой логическую группу специальных и стандартных разрешений. Например, для файлов и папок родовое право доступа «Изменение» включает все разрешения кроме «Удаление подпапок и файлов», «Смена разрешений» и «Смена владельца».

Существующий в Windows механизм наследования облегчает администраторам задачи назначения разрешений и управления ими. Благодаря этому механизму разрешения, установленные для контейнера, автоматически распространяются на все объекты этого контейнера. Например, файлы, создаваемые в папке, наследуют разрешения этой папки.

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

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

К вновь созданным в сеансе пользователя объектам права доступа в Windows назначаются одним из следующих способов:

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

2. На основе механизма наследования (если при создании объекта дескриптор безопасности не задается);

3. Из полученного при начале сеанса маркера доступа субъекта, создающего объект (если наследование невозможно).

Индекс файла в Linux содержит информацию о владельце файла (его идентификаторе, User Identifier , UID ), его первичной группе (идентификаторе группы, Group Identifier , GID )и векторе доступа к файлу. В отличие от Windows вектор доступа в Linux состоит всегда из трех элементов, определяющих права доступа к объекту трех категорий субъектов (владельца, членов его группы и всех остальных). Суперпользователь в Linux имеет полные, никем не ограничиваемые права доступа к любому объекту.

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

Ограниченность прав доступа к объектам в ОС Linux вынуждает использовать так называемые дополнительные биты доступа в каждой из его частей:

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

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

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

Управлять значением вектора доступа к вновь созданным в сеансе пользователя файлам в ОС Linux администратор может с помощью системной переменной umask , значение которой может устанавливаться в файлах пользователей.login , .cshrc или.profile либо в системном файле / etc / profile . Значение umask определяет сбрасываемые биты в элементах вектора доступа к создаваемому объекту.

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

- Использование привилегии администратора Windows «Овладение файлами или иными объектами» более безопасно, чем работа в Linux с правами суперпользователя , но менее удобна с точки зрения простоты администрирования.

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

- В Linux администратору проще управлять правами доступа к объектам, создаваемым пользователем в ходе своей работы в системе.

- В Windows возможно назначение индивидуальных прав доступа к объекту для любого отдельно взятого пользователя или группы.

В расширении подсистемы разграничения доступа к файлам для операционной системы Linux − Linux ACLs – реализована возможность настроить индивидуальные права доступа к файлам «с точностью» до отдельного пользователя.

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

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

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

Поддержка ролевого разграничения доступа включена в серверные операционные системы Windows и в серверную операционную систему ALT Linux Castle . Программисты и администраторы Windows -систем могут использовать преимущества ролевого разграничения доступа к объектам с помощью оснастки Диспетчер авторизации (Authorization Manager ) .

В соответствии с реализованной в ОС ALT Linux Castle ролевой моделью управления доступом определяются роли и типы, а затем определяется, что может делать та или иная роль с тем или иным типом . Таким образом, создается некоторая абстрактная модель, которая затем связывается к реальным пользователям, программам и файлам. Независимость модели от реальных субъектов и объектов позволяет производить мгновенную перенастройку политики безопасности быстрым изменением связей ролей и (или) типов. Кроме того, это очень удобно для создания готовых решений, например, распределения ролей и типов для защиты содержимого страниц Web-узла. Интересной особенностью является возможность запуска программ с ролью, отличной от роли пользователя, производящего запуск. В результате можно, например, произвести такие настройки, что прямой доступ к диску будут иметь только разрешенные программы, а все остальные пользователи системы (включая администратора) будут лишены такой возможности.

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

Литература

1. SELinux : теория и практика безопасности. http://www.interface.ru/ home.asp?artId=2699.

2. Хорев П.Б. Ролевое управление доступом к ресурсам в операционной системе Microsoft Windows Server 2003. Труды XVI международной научно-технической конференции «Информационные средства и технологии». В 3 томах. Т. 2. М.: Издательский дом МЭИ, 2008. С. 80-88.

3. ALTLinux Castle . Общиесведения. http://www.linuxcenter.ru/ lib/articles/distrib/altlinux/castle.phtml .