u20-24teslin 2 years ago
parent
commit
30b745c876

+ 201 - 0
Лекции/1.5.200_Управление_доступом_субъектов_доступа_к_объектам_доступа/5teslinn.md

@@ -0,0 +1,201 @@
+# Управление доступом субъектов доступа к объектам доступа.
+
+Матрица доступа (МД) – это готовая модель, позволяющая регламентировать доступ к информационным ресурсам компании, но основании которой можно оценить состояние и структуру защиты данных в информационных системах.
+
+Матрицы доступа используются с целью упрощения выполнения рутинных работ службы безопасности организации. Например, установка прав доступа пользователям разных групп или подразделений, обновление или отзыв прав, добавление исключений и прочее.
+
+Множество объектов и типов доступа к ним субъекта может изменяться в соответствии с некоторыми правилами, существующими в данной системе. Определение и изменение этих правил также является задачей МД.
+
+При принятии решения о предоставлении доступа обычно анализируется следующая информация:
+
+* идентификатор субъекта (идентификатор пользователя, сетевой адрес компьютера и т.п.). 
+
+* Подобные идентификаторы являются основой произвольного (или дискреционного) управления доступом ; 
+
+* атрибуты субъекта (метка безопасности, группа пользователя и т.п.). 
+
+Метки безопасности – основа принудительного (мандатного) управления доступом. Матрицу доступа, ввиду ее разреженности (большинство клеток – пустые), неразумно хранить в виде двухмерного массива. Обычно ее хранят по столбцам, то есть для каждого объекта поддерживается список "допущенных" субъектов вместе с их правами. 
+
+Элементами списков могут быть имена групп и шаблоны субъектов, что служит большим подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится удалять его имя из всех списков доступа; впрочем, эта операция производится не часто.
+
+Списки доступа – исключительно гибкое средство. С их помощью легко выполнить требование о гранулярности прав с точностью до пользователя. Посредством списков несложно добавить права или явным образом запретить доступ (например, чтобы наказать нескольких членов группы пользователей). Безусловно, списки являются лучшим средством произвольного управления доступом.
+
+Подавляющее большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Основное достоинство произвольного управления – гибкость. Вообще говоря, для каждой пары "субъект-объект" можно независимо задавать права доступа (особенно легко это делать, если используются списки управления доступом ). К сожалению, у "произвольного" подхода есть ряд недостатков. 
+
+Рассредоточенность управления доступом ведет к тому, что доверенными должны быть многие пользователи, а не только системные операторы или администраторы. Из-за рассеянности или некомпетентности сотрудника, владеющего секретной информацией, эту информацию могут узнать и все остальные пользователи. Следовательно, произвольность управления должна быть дополнена жестким контролем за реализацией избранной политики безопасности.
+
+Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл или заменить полезную утилиту ее "троянским" аналогом. Подобная "разделенность" прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности.
+
+Возвращаясь к вопросу представления матрицы доступа, укажем, что для этого можно использовать также функциональный способ, когда матрицу не хранят в явном виде, а каждый раз вычисляют содержимое соответствующих клеток. Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта.
+
+Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС Unix.
+
+### Мандатное управление доступом
+
+Мандатное управление доступом (англ. Mandatory access control, MAC) — разграничение доступа субъектов к объектам, основанное на назначении метки конфиденциальности для информации, содержащейся в объектах, и выдаче официальных разрешений (допуска) субъектам на обращение к информации такого уровня конфиденциальности. Также иногда переводится как Принудительный контроль доступа. Это способ, сочетающий защиту и ограничение прав, применяемый по отношению к компьютерным процессам, данным и системным устройствам и предназначенный для предотвращения их нежелательного использования.
+
+Согласно требованиям ФСТЭК, мандатное управление доступом или «метки доступа» являются ключевым отличием систем защиты государственной тайны РФ старших классов 1В и 1Б от младших классов защитных систем на классическом разделении прав по матрице доступа.
+
+Мандатный контроль доступа имеет две формы:
+
+1) Многоуровневая система безопасности (MLS) - это первая реализация MAC, которую многие называют классической. Она как раз-таки описывает вертикальную структуру уровней безопасности.
+
+Наиболее известным примером MLS является модель Белла - Лападулы, разработанная в 1973 году для U.S.AirForce.
+
+Вся суть этой модели отражена в схеме:
+
+![](extral11.png)
+
+Из схемы видно, что субъект с высоким уровнем доступа имеет право на запись и чтение объекта с высоким уровнем      конфиденциальности. Он также может читать документы с более низким уровнем конфиденциальности, но не изменять.  В свою очередь субъект с низким уровнем доступа может читать и записывать в объект с низким уровнем          конфиденциальности. Чтение объектов с высоким уровнем конфиденциальности ему запрещено, но разрешена запись.
+
+Хоть данная схема и предусматривает возможность субъектом с низким уровнем доступа записи данных в объект с высоким уровнем секретности, фактически это не работает, так как “секретные” файлы попросту не видны в каталоге.
+
+2) Многосторонние системы безопасности (Multilateral security systems)
+
+Эта форма более сложная. Помимо вертикального уровня безопасности с политикой конфиденциальности, накладывается и горизонтальный уровень безопасности. Он нужен для разграничения доступа внутри одного уровня доступа. Зачастую это просто необходимо даже в рамках одного отдела в компании. Имея один уровень доступа к секретным документам, нужно ограничить знания о каких-либо проектах. Для этого используется сегментирование, которое в свою очередь образует группы, или категории. Как показала практика, многосторонняя безопасность во многих случаях имеет большее значение, чем многоуровневая. Пренебрежение рисками утечки информации на одном уровне не раз приводило к громким провалам в мировой практике.
+
+Но, как уже говорилось выше, многосторонняя система безопасности сложнее. За время ее существования был разработан ряд моделей организации безопасного доступа к данным. Три основные из них:
+
+* Модель секционирования (Compartmentation): Данная модель уходит корнями еще во времена Второй Мировой войны. Тогда она использовалась разведкой. Она основана на использовании кодовых слов  и классификаций для разграничения доступа. Такая модель имеет ряд недостатков. Распространение кодовых слов приводит к появлению большого количества секций, особенно на уровнях классификации выше Совершенно секретно. Каждое сочетание кодовых слов дает новую секцию. В итоге их количество может быть огромным, и управление ими становится затруднительным.
+
+* Модель “Китайская стена”. Принципы этой модели строятся на опыте бизнес отношений. Согласно этой модели субъект может иметь доступ к информации, которая не входит в конфликт с информацией, с которой он работал ранее. Но изначально субъект может получить доступ к любой информации. Таким образом информация анализируется на предмет конфликта интересов. Если запрашиваемая информация входит в ту же группу конфликта интересов, что и предыдущая, то субъект получит отказ. 
+
+* Британская медицинская ассоциация (BMA) представила свою модель управления доступом. Суть ее в том, что для определенных категорий субъект данных должен сам давать согласие на доступ, либо - запрет. Таким образом решение по управлению доступом принимает не централизованный орган, а субъект.
+
+##### Основные принципы этой модели:
+
+* У каждого пациента будет несколько записей;
+
+* Каждая запись имеет список контроля доступа;
+
+* Любое изменение в списке контроля доступа возможно с одобрения пациента;
+
+* Должны быть предприняты меры противодействия по сбору личной информации о пациенте (в том числе и здоровье).
+
+#### Преимущества и недостатки MAC
+
+Как и любая система безопасности, MAC имеет плюсы и минусы. Рассмотрим их кратко.
+
+##### Плюсы:
+
+* Высокая степень надежности. Практически исключен взлом;
+
+* Автоматизированная проверка и обеспечение прав доступа;
+
+* Данные не могут быть изменены несанкционированно.
+
+##### Минусы:
+
+* Требует много планирования;
+
+* Так как система MAC достаточно громоздкая, администраторы сильно загружены. Необходимо регулярно проверять назначение прав доступа;
+
+* Долгий и дорогостоящий процесс перехода на MAC, например с DAC. 
+
+Пример: субъект «Пользователь № 2», имеющий допуск уровня «не секретно», не может получить доступ к объекту, имеющему метку «для служебного пользования». В то же время субъект «Пользователь № 1» с допуском уровня «секретно» право доступа (в режиме "только чтение") к объекту с меткой «для служебного пользования» имеет. Для сохранения внесенных изменений субъект "Пользователь № 1" должен сохранить редактируемый объект в каталоге с меткой "секретно". 
+
+##### Особенность 
+
+Мандатная модель управления доступом, помимо дискреционной и ролевой, является основой реализации разграничительной политики доступа к ресурсам при защите информации ограниченного доступа. При этом данная модель доступа практически не используется «в чистом виде», обычно на практике она дополняется элементами других моделей доступа.
+
+Для файловых систем оно может расширять или заменять дискреционный контроль доступа и концепцию пользователей и групп.
+
+Самое важное достоинство заключается в том, что пользователь не может полностью управлять доступом к ресурсам, которые он создаёт.
+
+Политика безопасности системы, установленная администратором, полностью определяет доступ, и обычно пользователю не разрешается устанавливать более свободный доступ к своим ресурсам, чем тот, который установлен администратором пользователю. Системы с дискреционным контролем доступа разрешают пользователям полностью определять доступность своих ресурсов, что означает, что они могут случайно или преднамеренно передать доступ неавторизованным пользователям. 
+
+Такая система запрещает пользователю или процессу, обладающему определённым уровнем доверия, получать доступ к информации, процессам или устройствам более защищённого уровня. Тем самым обеспечивается изоляция пользователей и процессов, как известных, так и не известных системе (неизвестная программа должна быть максимально лишена доверия, и её доступ к устройствам и файлам должен ограничиваться сильнее).
+
+Очевидно, что система, которая обеспечивает разделение данных и операций в компьютере, должна быть построена таким образом, чтобы её нельзя было «обойти». Она также должна давать возможность оценивать полезность и эффективность используемых правил и быть защищённой от постороннего вмешательства. 
+
+### Ролевая модель
+
+В крупной компании, где сотни информационных систем и тысячи пользователей управление доступом будет эффективно и безопасно только если оно основано на использовании ролевой модели.
+
+Роли помогают оптимизировать процесс. Например, специалисту отдела оплаты труда на ежедневной основе требуются одни и те же права в бухгалтерской системе: открыть и закрыть счет, провести начисления или списания, просмотреть или скорректировать данные по сотруднику и т.п. 
+
+В системе документооборота тому же бухгалтеру требуются права по созданию различных отчетов и отправки их в головную организацию. Если в компании много бухгалтеров и много систем в которых они постоянно работают, то все эти права можно объединить в одну роль и тогда, когда придет новый сотрудник на должность бухгалтера, можно будет в один клик назначить ему эту роль со всеми необходимыми полномочиями. Еще лучше если этот процесс будет автоматизирован и роль назначится автоматически, как только вышел приказ о принятии сотрудника на работу.
+
+Через роли удобно менять доступ для сотрудников одной должности. Если поменялся функционал у бухгалтеров и нужно добавить новый отчет в финансовой системе, то достаточно будет за пару минут внести изменения в одну роль, а не менять доступ каждому сотруднику бухгалтерии в отдельности и тратить на это несколько часов или даже дней.
+
+Роли, как правило, создают для определенных должностей или подразделений, включают в них все необходимые полномочия для выполнения сотрудниками должностных или функциональных обязанностей. Матрица, где хранится вся информация по созданным ролям и отношение их к различным должностям и подразделениям называется ролевой моделью (англ. RBAC – role Based Access Control). 
+
+!()[extral12.png]
+
+Управление доступом на основе ролевой модели серьезно упрощает процесс выдачи прав. Количество ролей существенно меньше, чем количество пользователей. Например, в ритейловой компании, которая занимается продажей бытового оборудования и имеет множество филиалов по всей стране числятся тысячи продавцов. Набор прав у них у всех должен быть одинаковый. Для них будет создана одна роль, которая включает все их потребности.
+
+Важным преимуществом ролевого управления доступом является разделение несовместимых полномочий (англ. SoD – Segregation of Duties). Сотрудник, имеющий определенную роль в системе, не может иметь одновременно другую роль, права которой не должны сочетаться с правами в первой. 
+
+Например, кассир, который вводит финансовый платеж не должен иметь возможности подтвердить (проконтролировать) этот платеж. Функция контроля должна быть в руках другого сотрудника: менеджера или руководителя. Создание, внедрение и поддержание ролей в актуальном состоянии может быть сложным.
+
+Процессы и инструменты, необходимые для эффективного создания и управления ролями включают и интеллектуальный анализ, проектирование ролей. Включение полномочий в определенную роль может проводиться на основании потребностей для той или иной должности или на основании существующих и используемых постоянно прав доступа. 
+
+Кроме того, должна регулярно проводиться переаттестация ролей и переаттестация доступа. Например, владелец роли должен каждые шесть месяцев подтверждать актуальность полномочий, которые включены в роль. Руководитель подразделения должен каждые три-шесть месяцев подтверждать правильность и легитимность ролей назначенных его подчиненным сотрудникам. 
+
+##### Преимущества ролевого управления доступом
+
+По сравнению с указанными выше моделями, ролевое управление доступом обладает рядом важных положительных свойств. 
+
+* Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.  
+
+* Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
+
+* При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
+
+* Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.
+
+##### Особенности
+
+При проектировании, внедрении и использовании ролевой модели управления доступом нужно принимать в расчёт факторы, которые могут привести к серьезным потерям времени и средств.
+
+Во-первых, «разнообразие пользователей»: на практике в крупных организациях может оказаться достаточно большое количество пользователей с уникальными правами, при этом некоторые из них могут быть на одной должности, а то и в одном подразделении. 
+Это усложняет построение ролевой модели и может привести к ситуации, когда каждому пользователю необходима своя уникальная роль. 
+
+Такие ситуации могут возникнуть, когда сотрудник «вырос» в рамках своей должности или у него просто есть уникальные функции в рамках своего подразделения. Это может стать серьезной проблемой для системы управления доступом:
+
+* В таком случае трудно определить "разумно малый" набор ролей, которые отвечают за права доступа основной массы пользователей.
+
+* Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.
+
+Во-вторых, «слишком много ролей»: это не всегда так, но может случиться такая ситуация, когда при подключении к системе  управления доступом еще одной управляемой системы, роли, определенные для ранее подключенных систем, необходимо раздробить на несколько других ролей, с учетом всех возможных вариантов использования совместно с новой системой. Если таких новых систем несколько, то может возникнуть ситуация, когда ролей окажется больше чем пользователей.
+
+В-третьих, «изменение обязанностей пользователей и реорганизация бизнеса»: даже если ролевая модель отражает текущую ситуацию в организации, ее необходимо поддерживать в актуальном состоянии, отслеживать изменения обязанностей пользователей и оперативно вносить изменения в ролевую модель.
+
+В-четвёртых, «стоимость»: необходимо учитывать, что разработка и поддержка ролевой модели в итоге может стоить дороже ручного администрирования. Кроме того, управление ролевой моделью требует более квалифицированных специалистов, чем администратор, который предоставляет права. 
+
+## Вывод
+
+В заключение подчеркнем важность управления доступом не только на уровне операционной системы, но и в рамках других сервисов, входящих в состав современных приложений, а также, насколько это возможно, на "стыках" между сервисами. Здесь на первый план выходит существование единой политики безопасности организации, а также квалифицированное и согласованное системное администрирование.
+
+### Вопросы
+
+1. Матрица доступа – это?
+
+A)**готовая модель, позволяющая регламентировать доступ к информационным ресурсам компании, но основании которой можно оценить состояние и структуру защиты данных в информационных системах.**
+
+Б)**управление доступа субъектов к объекту доступа**
+
+B)Принудительный контроль доступа
+
+2.Какие формы имеет мандатная система управления?
+
+A)Многоступенчатая система безопасности 
+
+Б)**Многоуровневая система безопасности**
+
+B)**Многосторонние системы безопасности**
+
+
+## Список литературы
+
+https://intuit.ru/studies/curriculums/18970/courses/10/lecture/314?page=3
+
+https://studfile.net/preview/383022/page:7/
+
+https://rt-solar.ru/products/solar_inrights/blog/3304/
+
+https://www.securitylab.ru/blog/personal/spbsecurity/279575.php
+
+https://rt-solar.ru/events/blog/2815/
+
+https://habr.com/ru/companies/avanpost/articles/482060/

BIN
Лекции/1.5.200_Управление_доступом_субъектов_доступа_к_объектам_доступа/extral11.png.png


BIN
Лекции/1.5.200_Управление_доступом_субъектов_доступа_к_объектам_доступа/extral12.png.png