Виды доступа к объектам компьютерных систем

Обновлено: 26.01.2025

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

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

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

"o" – обозначает разрешение на передачу прав доступа другим пользователям,

"a" – добавление информации

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

Для систем управления реляционными базами данных объект – это база данных, таблица, представление, хранимая процедура. К таблицам применимы операции поиска, добавления, модификации и удаления данных, у других объектов иные виды доступа.

Разнообразие объектов и применимых к ним операций приводит к принципиальной децентрализации логического управления доступом. Каждый сервис должен сам решать, позволить ли конкретному субъекту ту или иную операцию. Теоретически это согласуется с современным объектно-ориентированным подходом, на практике же приводит к значительным трудностям. Главная проблема в том, что ко многим объектам можно получить доступ с помощью разных сервисов (возможно, при этом придется преодолеть некоторые технические трудности). Так, до реляционных таблиц можно добраться не только средствами СУБД, но и путем непосредственного чтения файлов или дисковых разделов, поддерживаемых операционной системой (разобравшись предварительно в структуре хранения объектов базы данных). В результате при задании матрицы доступа нужно принимать во внимание не только принцип распределения привилегий для каждого сервиса, но и существующие связи между сервисами (приходится заботиться о согласованности разных частей матрицы). Аналогичная трудность возникает при экспорте/импорте данных, когда информация о правах доступа, как правило, теряется (поскольку на новом сервисе она не имеет смысла). Следовательно, обмен данными между различными сервисами представляет особую опасность с точки зрения управления доступом, а при проектировании и реализации разнородной конфигурации необходимо позаботиться о согласованном распределении прав доступа субъектов к объектам и о минимизации числа способов экспорта/импорта данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ролевое управление доступом оперирует следующими основными понятиями:

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

Ролям приписываются пользователи и права доступа ; можно считать, что они (роли) именуют отношения "многие ко многим" между пользователями и правами. Роли могут быть приписаны многим пользователям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов.

Между ролями может быть определено отношение частичного порядка , называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям – объекты (экземпляры) классов.

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

Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли "сотрудник", с постепенным уточнением состава пользователей и добавлением прав (роли "системный администратор", "бухгалтер" и т.п.), вплоть до роли "руководитель" (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязанностей). Фрагмент подобной иерархии ролей показан на рис. 10.3.

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

Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей – число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3).

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

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

Рассматриваемый проект стандарта содержит спецификации трех категорий функций , необходимых для администрирования РУД:

• Административные функции (создание и сопровождение ролей и других атрибутов ролевого доступа): создать/удалить роль/пользователя, приписать пользователя/право роли или ликвидировать существующую ассоциацию, создать/удалить отношение наследования между существующими ролями, создать новую роль и сделать ее наследницей/предшественницей существующей роли, создать/удалить ограничения для статического/динамического разделения обязанностей .
• Вспомогательные функции (обслуживание сеансов работы пользователей): открыть сеанс работы пользователя с активацией подразумеваемого набора ролей; активировать новую роль, деактивировать роль; проверить правомерность доступа.
• Информационные функции (получение сведений о текущей конфигурации с учетом отношения наследования). Здесь проводится разделение на обязательные и необязательные функции. К числу первых принадлежат получение списка пользователей, приписанных роли, и списка ролей, которым приписан пользователь.

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

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

Что может быть проще, чем разграничить права на папку в NTFS? Но эта простая задача может превратиться в настоящий кошмар, когда подобных папок сотни, если не тысячи, а изменение прав к одной папке «ломает» права на другие. Чтобы эффективно работать в подобных условиях, требуется определенная договоренность, или стандарт, который бы описывал, как решать подобные задачи. В данной статье мы как раз и рассмотрим один из вариантов подобного стандарта.

Стандарт управления правами доступа к корпоративным файловым информационным ресурсам (далее – Стандарт) регламентирует процессы предоставления доступа к файловым информационным ресурсам, размещенным на компьютерах, работающих под управлением операционных систем семейства Microsoft Windows. Стандарт распространяется на случаи, когда в качестве файловой системы используется NTFS, а в качестве сетевого протокола для совместного доступа к файлам SMB/CIFS.

Информационный ресурс – поименованная совокупность данных, к которой применяются методы и средства обеспечения информационной безопасности (например, разграничение доступа).
Файловый информационный ресурс – совокупность файлов и папок, хранящихся в каталоге файловой системы (который называется корневым каталогом файлового информационного ресурса), доступ к которой разграничивается.
Составной файловый информационный ресурс – это файловый информационный ресурс, содержащий в себе один или несколько вложенных файловых информационных ресурсов, отличающихся от данного ресурса правами доступа.
Вложенный файловый информационный ресурс – это файловый информационный ресурс, входящий в составной информационный ресурс.
Точка входа в файловый информационный ресурс – каталог файловой системы, к которому предоставляется сетевой доступ (shared folder) и который используется для обеспечения доступа к файловому информационному ресурсу. Данный каталог обычно совпадает с корневым каталогом файлового информационного ресурса, но может быть и вышестоящим.
Промежуточный каталог – каталог файловой системы, находящийся на пути от точки входа в файловый информационной ресурс к корневому каталогу файлового информационного ресурса. Если точка входа в файловый информационный ресурс является вышестоящим каталогом по отношению к корневому каталогу файлового информационного ресурса, то она также будет являться промежуточным каталогом.
Группа доступа пользователей – локальная или доменная группа безопасности, содержащая в конечном счете учетные записи пользователей, наделенные одним из вариантов полномочий доступа к файловому информационному ресурсу.

1. Доступ разграничивается только на уровне каталогов. Ограничение доступа к отдельным файлам не проводится.
2. Назначение прав доступа выполняется на базе групп безопасности. Назначение прав доступа на отдельные учетные записи пользователей не проводится.
3. Явно запрещающие полномочия доступа (deny permissions) не применяются.
4. Разграничение прав доступа проводится только на уровне файловой системы. На уровне сетевых протоколов SMB/CIFS права не разграничиваются (Группа «Все» – полномочия «Чтение/Запись» / Everyone – Change).
5. При настройке сетевого доступа к файловому информационному ресурсу в настройках SMB/CIFS устанавливается опция «Перечисление на основе доступа (Access based enumeration)».
6. Создание файловых информационных ресурсов на рабочих станциях пользователей недопустимо.
7. Не рекомендуется размещать файловые информационные ресурсы на системных разделах серверов.
8. Не рекомендуется создавать несколько точек входа в файловый информационный ресурс.
9. Следует по возможности избегать создание вложенных файловых информационных ресурсов, а в случаях, когда имена файлов или каталогов содержат конфиденциальную информацию, это вовсе недопустимо

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

• Доступ «Только на чтение (Read Only)».
• Доступ «Чтение и запись (Read & Write)».

Имена групп доступа пользователей формируются по шаблону:

FILE-Имя файлового информационного ресурса–аббревиатура полномочий

Имя файлового информационного ресурса
должно совпадать с UNC именем ресурса или состоять из имени сервера и локального пути (если сетевой доступ к ресурсу не предоставляется). При необходимости в данном поле допускаются сокращения. Символы «\\» опускаются, а «\» и «:» заменяются на «-».

Аббревиатуры полномочий:

• RO — для варианта доступа «Только на чтение (Read Only)»
• RW — для варианта доступа «Чтение и запись (Read & Write)».

Пример 2
Имя группы доступа пользователей, имеющих полномочия «Чтение и запись» для файлового информационного ресурса, размещенного на сервере TERMSRV по пути D:\UsersData, будет:
FILE-TERMSRV-D-UsersData-RW

Таблица 1 – Шаблон NTFS-прав доступа для корневого каталога файлового информационного ресурса.

Субъекты	Права	Режим наследования
Наследование прав доступа от вышестоящих каталогов отключено
А) Обязательные права
Специальная учетная запись: «СИСТЕМА (SYSTEM)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Локальная группа безопасности: «Администраторы (Administrators)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.1) Полномочия «Только чтение (Read Only)»
Группа доступа пользователей: «FILE-Имя ресурса-RO»	Базовые права: а) чтение и выполнение (read & execute); б) список содержимого папки (list folder contents); в) чтение (read);	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.2) Полномочия «Чтение и запись (Read & Write)»
Группа доступа пользователей: «FILE-Имя ресурса-RW»	Базовые права: а) изменение (modify); б) чтение и выполнение (read & execute); в) список содержимого папки (list folder contents); г) чтение (read); д) запись (write);	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.3) Другие полномочия при их наличии
Группа доступа пользователей: «FILE-Имя ресурса-аббревиатура полномочий»	Согласно полномочиям	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)

Табилца 2 – Шаблон NTFS-прав доступа для промежуточных каталогов файлового информационного ресурса.

Субъекты	Права	Режим наследования
Наследование прав доступа от вышестоящих каталогов включено, но если данный каталог является вышестоящим по отношению к файловым информационным ресурсам и не входит ни в один другой файловый информационный ресурс, то наследование отключено
А) Обязательные права
Специальная учетная запись: «СИСТЕМА (SYSTEM)»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Локальная группа безопасности: «Администраторы»	Полный доступ (Full access)	Для этой папки, ее подпапок и файлов (This folder, subfolders and files)
Б.1) Полномочия «Проход через каталог (TRAVERSE)»
Группы доступа пользователей информационных ресурсов, для которых этот каталог является промежуточным	Дополнительные параметры безопасности: а) траверс папок / выполнение файлов (travers folder / execute files); б) содержимое папки / чтение данных (list folder / read data); в) чтение атрибутов (read attributes); в) чтение дополнительных атрибутов (read extended attributes); г) чтение разрешений (read permissions);	Только для этой папки (This folder only)

1. Создаются группы доступа пользователей. Если сервер, на котором размещен файловый информационный ресурс, является членом домена, то создаются доменные группы. Если нет, то группы создаются локально на сервере.
2. На корневой каталог и промежуточные каталоги файлового информационного ресурса назначаются права доступа согласно шаблонам прав доступа.
3. В группы доступа пользователей добавляются учетные записи пользователей в соответствии с их полномочиями.
4. При необходимости для файлового информационного ресурса создается сетевая папка (shared folder).

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

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

1. Регистрируется вложенный файловый информационный ресурс (согласно процессу А)
2. В группы доступа пользователей вложенного файлового информационного ресурса добавляются группы доступа пользователей вышестоящего составного файлового информационного ресурса.

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

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

Рассмотрим применение данного стандарта на примере гипотетической организации ООО «ИнфоКриптоСервис», где для централизованного хранения файловых информационных ресурсов выделен сервер с именем «FILESRV». Сервер работает под управлением операционной системы Microsoft Windows Server 2008 R2 и является членом домена Active Directory с FQDN именем «domain.ics» и NetBIOS именем «ICS».

Подготовка файлового сервера
На диске «D:» сервера «FILESRV» создаем каталог «D:\SHARE\». Этот каталог будет единой точкой входа во все файловые информационные ресурсы, размещенные на данном сервере. Организуем сетевой доступ к данной папке (используем апплет «Share and Storage Management»):

Создание файлового информационного ресурса
Постановка задачи.
Пусть в составе организации ООО «ИнфоКриптоСервис» имеется Отдел разработки информационных систем в составе: начальника отдела Иванова Сергея Леонидовича ([email protected]), специалиста Маркина Льва Борисовича ([email protected]), и для них нужно организовать файловый информационный ресурс для хранения данных подразделения. Обоим работникам требуется доступ на чтение и запись к данному ресурсу.

• «FILE-FILESRV-SHARE-Отд. разр. ИС-RO»
• «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Предоставление доступа пользователю к файловому информационному ресурсу
Постановка задачи.
Предположим, в отдел разработки приняли еще одного работника – специалиста Егорова Михаила Владимировича ([email protected]), и ему, как и остальным работникам отдела, требуется доступ на чтение и запись к файловому информационному ресурсу отдела.

Решение.
Учетную запись работника необходимо добавить в группу «FILE-FILESRV-SHARE-Отд. разр. ИС-RW»

Создание вложенного информационного ресурса. Расширение доступа
Постановка задачи.
Предположим, Отдел разработки информационных систем решил улучшить качество взаимодействия с Отделом маркетинга и предоставить руководителю последнего — Кругликовой Наталье Евгеньевне ([email protected]) — доступ на чтение к актуальной документации на продукты, хранящейся в папке «Документация» файлового информационного ресурса Отдела разработки информационных систем.

Решение.
Для решения данной задачи необходимо сделать вложенный ресурс «\\FILESRV\share\Отдел разработки информационных систем\Документация», доступ к которому на чтение и запись должен быть (остаться) у всех пользователей, имевших доступ к «\\FILESRV\share\Отдел разработки информационных систем\ и добавиться доступ на чтение для пользователя Кругликовой Натальи Евгеньевне ([email protected])

• «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO»
• «FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW»

Теперь, если Кругликова Наталья Евгеньевна ([email protected]) обратится по ссылке «\\FILESRV\share\Отдел разработки информационных систем\Документация», то она сможет попасть в интересующую ее папку, но обращаться по полному пути не всегда удобно, поэтому настроим сквозной проход к данной паке от точки входа «\\FILESRV\share\» («D:\SHARE\»). Для этого настроим права доступа на промежуточные каталоги «D:\SHARE\» и «D:\SHARE\Отдел разработки информационных систем\».

Проведем настройку «D:\SHARE\»:

Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

и «D:\SHARE\Отдел разработки информационных систем»:

Дамп NTFS разрешений, полученных командой cacls:
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RO:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-Документация-RW:R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RO:(OI)(CI)R
ICS\FILE-FILESRV-SHARE-Отд. разр. ИС-RW:(OI)(CI)C
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F

Создание вложенного информационного ресурса. Сужение доступа
Постановка задачи
В целях организации резервного копирования наработок Отдела разработки информационных систем начальнику отдела Иванову Сергею Леонидовичу ([email protected]), в рамках файлового информационного ресурса отдела, понадобилась сетевая папка «Архив», доступ к которой был бы только у него.

Решение.
Для решения данной задачи в файловом информационном ресурсе отдела требуется сделать вложенный ресурс «Архив» («\\FILESRV\share\Отдел разработки информационных систем\Архив»), доступ к которому предоставить только начальнику отдела.

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

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

Дискреционная модель управления доступом (Discretionary Access Control, DAC, от англ. Discretion – по усмотрению) – владелец объекта сам устанавливает и меняет права доступа субъектов. Минусы данной модели:

• ВПО, работающее в контексте «владельца» объекта, может получить доступ к этому объекту;

• Нет гарантий конфиденциальности информации при чтении данных из одного документа и записи в другой документ с другими правами доступа;

• Игнорирование атрибутов прав доступа при копировании файла на другое устройство (другой домен, другая ОС).

Мандатная модель управления доступом (Mandatory Access Control, MAC, от англ. Mandatory - обязательный) – использование меток/грифов конфиденциальности (англ. Classification) для объектов доступа и формы допуска (англ. Clearance) для субъектов доступа.

Основные правила (для защиты от утечек информации):

• Чтение только объектов, чей уровень безопасности не выше уровня субъекта доступа;

• Запись только в те объекты, чей уровень безопасности не ниже уровня субъекта доступа.

Ролевая модель управления доступом (Role-Based Access Control, RBAC) – предоставление прав доступа ролям (по функционалу), применяется для упрощения администрирования.

RBAC позволяет реализовать:

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

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

Модель управления доступом на основании правил (Rule-Based Access Control, RuBAC) – предоставление доступа в соответствии с логическими правилами «если-то», задаваемыми администратором ИБ, например: размер документа не больше 5Мб, доступ только в будние дни в рабочее время и для сотрудников с формой допуска №3.

Контенто-зависимая модель управления доступом (Content-dependent Access Control) – предоставление доступа субъекту в зависимости от содержания объекта (прообраз DLP-системы предотвращения утечек данных).

Контекстно-зависимая модель управления доступом (Context-dependent Access Control) – предоставление доступа субъекту в зависимости от предыдущего запроса для невозможности агрегировать информацию (не даем субъекту больше, чем он должен знать, анализируя его предыдущие запросы).

Модель управления доступом на основании атрибутов (Attribute Based Access Control, ABAC) – предоставление доступа в зависимости от атрибутов субъекта, объекта, среды функционирования и самого действия в соответствии с логическими правилами «если-то», объединенными в политики. Является развитием модели RuBAC и одной из самых современных моделей управления доступом.

Риск-ориентированная модель управления доступом (Risk-Based/Adaptable Access Control) – предоставление доступа к объекту в зависимости от уровня риска субъекта доступа (IP-адрес, история ранее выполненных действий, скоринговый балл, иные атрибуты) и от ИБ-свойств самого объекта (атрибуты объекта, состояние защищенности, наличие инцидентов/уязвимостей на нем).

Права доступа к объекту описываются в ACL (access control list), состоящем из ACE (access control entries). Права доступа субъекта описываются в его Capability table.

Факторы аутентификации:

1. То, что субъект знает: пароли, парольные фразы, ключевые слова, контрольные вопросы.

2. То, чем субъект владеет: OTP, токены (программные, аппаратные), номер мобильного телефона, смарт-карты.

3. То, чем субъект является: биометрия (отпечатки пальцев, сетчатки глаз, радужной оболочки глаз, голос, изображение, походка).

OTP (one-time password) устройства:

1.1. time-based synchronization (TOTP): OTP получается смешиванием (имитовставкой) секретного ключа и текущего времени, этот OTP отправляется серверу вместе с ID пользователя, сервер сравнивает то, что он сам получил (время+ключ) и то, что пришло от пользователя. Есть некая временная дельта, в пределах которой сработает OTP.

1.2. counter-based synchronization (HOTP - HMAC-based OTP): пользователь нажимает на кнопку на OTP-брелке, OTP получается смешиванием (имитовставкой) секретного ключа и значения счетчика, дальше это значение отправляется для проверки на сервер, который «знает» множество возможных значений счетчика в каждый момент времени.

Модель «запрос-ответ» (challenge-response): сервер отправляет запрос-challenge (или nonce, некая рандомная величина) пользователю, который вводит её в токен, токен с использованием секретного ключа формирует OTP. Далее пользователь вводит свой ID и этот OTP на странице сервера для аутентификации.

Примеры второго фактора: ruToken,RSA SecurID, FIDO U2F, Google/Microsoft Authenticator

FAR - false acceptance rate – уровень ложного предоставления доступа (пустили злоумышленника в помещение).

FRR - false rejection rate – уровень ложного отказа в доступе (не пускаем легитимного пользователя).

CER - crossover error rate – уровень пересечения ошибок (чем он ниже, тем более точная система, т.е. при приемлемом уровне false acceptance/rejection мы сохраняем высокий процент прохода легитимных юзеров).

На графике CER – это точка, в которой кривые false rejection rate и false acceptance rate пересекаются (т.е. когда false rejection rate = false acceptance rate).

Ошибки I рода (False Positive) (ложноположительные срабатывания) – неверно детектируем чистое письмо как спам.

True Positive – спам верно задетектировали как спам.

True Negative – чистое письмо верно задетектировали как чистое.

NTLM - NT LAN Manager, протокол сетевой аутентификации в инфраструктуре Microsoft. Основан на использовании NTLM-хэша пароля пользователя в качестве секретного ключа и на знании сервером NTLM-хэша пароля пользователя для его аутентификации. Старые версии LM, NTLMv1 небезопасны, не применяются.

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

Атака Pass The Hash - возможность использования NTLM-хэша от пароля пользователя для получения доступа к ресурсам из-под его УЗ по NTLM-хэшу, без необходимости получения самого пароля.

Утилиты для атаки Pass The Hash:

• Mimikatz – получение NTLM-хэшей и их повторное использование для имперсонации учетной записи.

• Procdump (официальная утилита Microsoft) – доступ к памяти системного процесса lsass.exe, хранящего NTLM-хэши, для последующего брутфорса или повторного использования.

• Работа с hiberfil.sys (файл, хранящий данные ОЗУ во время гибернации – закрытие крышки ноутбука).

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

1. KDC (key distribution center) - содержит в себе все закрытые ключи (secret key) пользователей и сервисов, они доверяют KDC. KDC - единая точка отказа, должен быть всегда online.

2. AS (authentication service) - компонент KDC, принимает запросы от пользователей.

3. TGS (ticket granting service) - компонент KDC, который принимает запросы на сессионные ключи (TGS-тикеты/мандаты) и выдаёт их.

4. TGT (ticket granting ticket) - тикет/мандат, который выдаётся AS'ом в зашифрованном виде клиенту на некоторое время (Windows default setting - 10 часов), далее клиент его использует для подтверждения того, что он уже был авторизован.

Описание процесса аутентификации с использованием Керберос:

1. Клиент обращается к AS для получения TGT. Клиент пересылает данные (идентификатор клиента, метку времени и идентификатор сервера), зашифрованные NTLM-хэшем от пароля (секретным ключом) клиента. Этот пакет данных называется AS-REQ.

2. AS расшифровывает запрос клиента (связываясь с KDC для получения секретного ключа клиента); если всё ОК, то возвращает клиенту TGT, зашифрованный ключом TGS'а (т.е. NTLM-хэшем служебного пользователя KRBTGT), а также сессионный ключ связи «клиент/TGS», зашифрованный ключом клиента. Этот пакет данных называется AS-REP. Сам TGT может быть открыт и прочитан только сервисом KRBTGT.

3. Когда клиент хочет использовать сервис, то клиент шлёт в TGS свой TGT, идентификатор сервиса и свой зашифрованный сессионным ключом «клиент/TGS» аутентификатор (ID клиента, timestamp). Этот пакет данных называется TGS-REQ.

а) TGS-тикетом, который зашифрован секретным ключом сервиса (т.е. NTLM-хэшем пароля сервисной УЗ) и содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата, сессионный ключ «клиент/сервис»;

б) сессионным ключом «клиент/сервис», зашифрованный сессионным ключом «клиент/TGS».

Этот пакет данных называется TGS-REP.

5. Клиент отправляет сервису этот TGS-тикет и свой новый аутентификатор (тоже метка времени, ID клиента, зашифрован сессионным ключом «клиент/сервис»). Этот пакет данных называется AP-REQ.

6. Сервис расшифровывает тикет своим закрытым ключом, извлекает сессионный ключ «клиент/сервис», потом полученным сессионным ключом «клиент/сервис» расшифровывает аутентификатор клиента, и чтобы себя аутентифицировать перед клиентом отправляет ему значение «метка времени клиента+1», зашифрованное сессионным ключом «клиент/сервис». Этот пакет отправляемых данных называется AP-REP.

7. Клиент расшифровывает «метку времени+1», проверяет, если ОК - начинается обмен инфрмацией.

Схема работы Керберос:

Domain Controller = KDC+AS

Application Server = сервис, требующийся клиенту, работающему на User’s Workstation

Атаки на Kerberos:

• доступ к сессионным ключам;

• доступ к секретным ключам (NTLM-хэшам от паролей пользователей и сервисов).

Старая реализация Керберос-шифрования с шифронабором «RC4_HMAC_MD5» использует «несоленый» (всегда одинаковый) NTLM-хэш от пароля атакуемого пользователя для шифрования запроса, поэтому получив этот хэш можем запросить тикет от имени атакуемой УЗ (атака Skeleton). Более новая реализация Керберос-шифрования с шифронабором «AES256_HMAC_SHA1» использует уже «соленый» NTLM-хэш (хэш каждый раз получается разным, т.к. его значение зависит не только от пароля пользователя, но и от некой переменной – «соли»).

Pass The Ticket - возможность использования пользовательского TGS или TGT-билета Керберос для получения доступа к ресурсам из-под УЗ (например, путем доступа к памяти процесса lsass.exe, в котором хранятся Керберос-тикеты).

Golden Ticket - возможность выдавать себя за любого пользователя в домене, используя NTLM-хэш учетной записи KRBTGT и выдавая любые TGT кому угодно.

Silver Ticket - возможность использования NTLM-хэша от пароля ПК или сервиса для создания TGS/TGT и получения доступа к ресурсам из-под этой УЗ.

Kerberoasting - возможность брутфорса и получения пароля сервисной УЗ в офлайне (без риска блокировки аккаунта).

Overpass The Hash - возможность подделки TGT любого пользователя при наличии NTLM-хэша от его пароля.

Защита учетных записей:

• Identity & Access Management системы

• HR-системы (актуальная информация)

• Системы токенизации (предоставление временного псевдо-пароля)

• Смарт-карты (вход не по паролю, а по сертификату)

• Программы повышения осведомленности

• Фишинговые учебные рассылки

• Работа с пользователями

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

управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Субъект с определенным правом доступа может передать это право любому другому субъекту.

На курсе "Операционные системы" вы работали с этой моделью доступа.

Пример: когда вы расписываете доступ к файлу, вы указываете

1. имя владельца файла (субъект)
2. права на чтение
3. права на запись
4. права на запуск на выполнение

• пользователь
• программа выполняющаяся под именем пользователя

• файлы
• каталоги
• внешние накопители (CD,DVD,USB и т.д.)
• принтер
• сетевой адаптер

Рис. Дискреционное управление доступом

• простата реализации
• гибкость (пользователь может описать доступ к своим ресурсам)

• излишняя детализированность (приводит к запутанности)
• сложность администрирования
• пользователь может допустить ошибку при назначении прав

Пример дискреционного управления доступом к файлам в LINUX.

Мандатное управление доступом ( Mandatory access control, MAC )

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

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

• простата построения общей схемы доступа
• простата администрирования

• проблема разграничения пользователей одного уровня
• пользователь не может назначать доступ к объекту

Мандатная модель не реализована в Windows, но можно поставить дополнительные средства защиты (например: Secret Net, Аккорд и т.д.).

Ролевое управление доступом (Role Based Access Control, RBAC)

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

Читайте также:

  
• Как сменить ip адрес на компьютере для авито
  
• Вылетает cinema 4d при рендере
  
• Как посмотреть память сим карты на мейзу
  
• В чем измеряется компьютер
  
• Как перепрошить телефон blackview a60 через компьютер