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

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

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

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

При принятии решения о предоставлении доступа обычно анализируется следующая информация:

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

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

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

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

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

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

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

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

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

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

Мандатное управление доступом (англ. Mandatory access control, MAC) — разграничение доступа субъектов к объектам, основанное на назначении метки конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности. Также иногда переводится как Принудительный контроль доступа. Это способ, сочетающий защиту и ограничение прав, применяемый по отношению к компьютерным процессам, данным и системным устройствам и предназначенный для предотвращения их нежелательного использования.

Согласно требованиям ФСТЭК, мандатное управление доступом или «метки доступа» являются ключевым отличием систем защиты государственной тайны РФ старших классов 1В и 1Б от младших классов защитных систем на классическом разделении прав по матрице доступа.

Мандатный контроль доступа имеет две формы:

1) Многоуровневая система безопасности (MLS) - это первая реализация MAC, которую многие называют классической. Она как раз-таки описывает вертикальную структуру уровней безопасности.

Наиболее известным примером MLS является модель Белла - Лападулы, разработанная в 1973 году для U.S.AirForce.

Вся суть этой модели отражена в схеме:

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

Хоть данная схема и предусматривает возможность субъектом с низким уровнем доступа записи данных в объект с высоким уровнем секретности, фактически это не работает, так как “секретные” файлы попросту не видны в каталоге.

2) Многосторонние системы безопасности (Multilateral security systems)

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

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

Модель секционирования (Compartmentation): Данная модель уходит корнями еще во времена Второй Мировой войны. Тогда она использовалась разведкой. Она основана на использовании кодовых слов и классификаций для разграничения доступа. Такая модель имеет ряд недостатков. Распространение кодовых слов приводит к появлению большого количества секций, особенно на уровнях классификации выше Совершенно секретно. Каждое сочетание кодовых слов дает новую секцию. В итоге их количество может быть огромным, и управление ими становится затруднительным.
Модель “Китайская стена”. Принципы этой модели строятся на опыте бизнес отношений. Согласно этой модели субъект может иметь доступ к информации, которая не входит в конфликт с информацией, с которой он работал ранее. Но изначально субъект может получить доступ к любой информации. Таким образом информация анализируется на предмет конфликта интересов. Если запрашиваемая информация входит в ту же группу конфликта интересов, что и предыдущая, то субъект получит отказ.
Британская медицинская ассоциация (BMA) представила свою модель управления доступом. Суть ее в том, что для определенных категорий субъект данных должен сам давать согласие на доступ, либо - запрет. Таким образом решение по управлению доступом принимает не централизованный орган, а субъект.

Основные принципы этой модели:

У каждого пациента будет несколько записей;
Каждая запись имеет список контроля доступа;
Любое изменение в списке контроля доступа возможно с одобрения пациента;
Должны быть предприняты меры противодействия по сбору личной информации о пациенте (в том числе и здоровье).

Преимущества и недостатки MAC

Как и любая система безопасности, MAC имеет плюсы и минусы. Рассмотрим их кратко.

Плюсы:

Высокая степень надежности. Практически исключен взлом;
Автоматизированная проверка и обеспечение прав доступа;
Данные не могут быть изменены несанкционированно.

Минусы:

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

Пример: субъект «Пользователь № 2», имеющий допуск уровня «не секретно», не может получить доступ к объекту, имеющему метку «для служебного пользования». В то же время субъект «Пользователь № 1» с допуском уровня «секретно» право доступа (в режиме "только чтение") к объекту с меткой «для служебного пользования» имеет. Для сохранения внесенных изменений субъект "Пользователь № 1" должен сохранить редактируемый объект в каталоге с меткой "секретно".

Особенность

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

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

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

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

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

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

Ролевая модель

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

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

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

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

Роли, как правило, создают для определенных должностей или подразделений, включают в них все необходимые полномочия для выполнения сотрудниками должностных или функциональных обязанностей. Матрица, где хранится вся информация по созданным ролям и отношение их к различным должностям и подразделениям называется ролевой моделью (англ. RBAC – role Based Access Control).

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

Важным преимуществом ролевого управления доступом является разделение несовместимых полномочий (англ. SoD – Segregation of Duties). Сотрудник, имеющий определенную роль в системе, не может иметь одновременно другую роль, права которой не должны сочетаться с правами в первой.

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

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

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

Преимущества ролевого управления доступом

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

Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.
Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.

Особенности

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

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

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

В таком случае трудно определить "разумно малый" набор ролей, которые отвечают за права доступа основной массы пользователей.
Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.

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

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

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

Вывод

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

Вопросы

Матрица доступа – это?

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

Б)управление доступа субъектов к объекту доступа

B)Принудительный контроль доступа

2.Какие формы имеет мандатная система управления?

A)Многоступенчатая система безопасности

Б)Многоуровневая система безопасности

B)Многосторонние системы безопасности