Дискреционный контроль доступа windows

Discretionary access control, frequently abbreviated to DAC, is the most widely used access control model. Under discretionary access control, every object in a system has an owner, and this owner can allocate access for the object at their discretion. By default, an object’s owner is usually the person who created it.

Discretionary access control is the backbone of nearly all consumer operating systems, including Windows and macOS. It’s also commonly used for cloud services such as Google Drive. Whether you know it or not, you are almost certainly using some form of discretionary access control in your day-to-day computing life.

The discretionary access control model is popular because of the flexibility it offers. It essentially puts power in the hands of individual object owners. As such, it entails quite a bit less overhead than most other access control models. But discretionary access control can become unmanageable for larger organizations, especially if thousands of individual employees might be object owners.

Under discretionary access control, an objects’ owner is in charge of access to it. Typically, the object’s owner is the person who created it. If you create a Google Doc, for instance, you become the owner of that document. From there, you can hand out access privileges to other people.

But ownership does not always belong to an objects’ creator. You might have a shared folder in which any objects created default to the folder’s owner. And in any case, an object’s owner can always decide to transfer ownership to someone else.

Discretionary access control operates by using access control lists, or ACLs. Every object under DAC has its own access control list, which lists access control entries, or ACEs, for individual users and groups.

The access control list for a document might include entries for Greg, Carrie, and Sylvester. Greg might have permission to read the document, Carrie might have permission to read and modify the document, and Sylvester might have broader administrative powers. Let’s work through another example, showing how access controls work in Windows.

Discretionary Access Control in Windows

You can see the access control list for any object in Windows by right clicking the object, opening its Properties, and then opening the Security tab on this window. You can see an example in the screenshot below.

The upper panel, titled “Group or user names,” lists users. The lower panel lists access rights given to each user. From lowest to highest access level, these include:

• List folder contents: Allows a user to see the file names and subfolders contained in a folder, but permits no further access to view or edit the files themselves.
• Read: Allows a user to view or copy the file or folder, or the items contained within a folder.
• Read and execute: Includes all Read privileges, plus the ability to run applications.
• Write: Includes all Read privileges, plus the ability to add files and subfolders.
• Modify: Includes all Write privileges, plus the ability to modify or delete files and subfolders.
• Full control: Includes all of the above permissions, plus the ability to change permissions for all files and subfolders.

For each of these settings, “Allow” means a user has the privilege in question; “Deny” means they do not. If a user is not listed, they are denied access based on the implicit deny principle: if access isn’t explicitly allowed, it is denied by default.

Permissions can be modified by the object’s owner or by any user with full control. The owner can always change these permissions, even if they have no other access explicitly listed. You can find the objects’ owner by clicking the Advanced button on this panel.

The objects’ owner doesn’t always have unlimited authority. In many systems, administrators and other high level users can supersede the owner and take ownership of the object.

Discretionary access controls form the foundation of access control in Windows. But users can also implement role-based access controls by setting up groups and shared settings. Windows also uses elements of mandatory access control to protect the core of its operating system and security features from malware.

Strengths & Weaknesses of Discretionary Access Control

The biggest strength of discretionary access control is its flexibility. By putting power in the hands of ground level users, DAC makes it easier for the people doing the work to do their jobs and manage access to the work they own.

Discretionary access control’s ubiquity is another major strength: most people use DAC every day, without even realizing it. It’s not hard to implement a basic DAC system – if you don’t have a conscious policy in place, most of your computer systems are probably operating on DAC principles by default.

On the downside, discretionary access control tends to get unwieldy the larger the organization gets. A system that’s light and flexible for a small team can become downright convoluted at an organization where any of a thousand users might be the owner of any given object. There are ways to administer DAC at larger organizations – but many of these methods point to the role-based access control model, in which users are grouped to simplify access control.

Discretionary access control systems can also face security issues, especially if you simply let default DAC systems run their course from the ground up with no administrative guidance. These controls work best as part of a carefully considered access control policy, including security awareness training to make sure you’re putting access control power in the hands of well-educated users.

Alternatives to Discretionary Access Control

All told, discretionary access control is a highly effective and user-friendly access control model. It works perfectly for individuals and small teams; and with the right policies in place, it can even scale up to handle much larger organizations.

You might also consider role-based access control, which allocates access based on specific roles, such as “Accounting”, “HR”, or “C-team”. This group-based model is a natural fit for organizations, and it can greatly simplify access management relative to discretionary access control.

For a high-security option, you might also consider mandatory access control, or MAC. This model gives both users and objects security labels, such as Classified, Secret, and Top Secret. To access a given object, a user must have a security label matching or exceeding that of the object.

Mandatory access control is often considered the most secure access control model, but it’s also highly rigorous to implement. There’s a reason the U.S. Department of Defense uses it, but for most businesses, MAC is too stringent to use for everyday purposes.

That said, you can always implement elements of different access control models. Windows is based on a foundation of discretionary access control, for instance, but includes elements of mandatory access control to shore up critical vulnerabilities, and gives users the tools to readily implement role-based access control. While it’s helpful for an organization to have an overarching access control policy, these models are not mutually exclusive.

To learn more, see our complete guide, which covers eight access control models.

www.volsu.ru

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ И КОМПЬЮТЕРНОЕ МОДЕЛИРОВАНИЕ

СТАТЬИ

УДК 004.451:004.056 ББК 32.927.11

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

Сергей Михайлович Цымбаленко

Студент кафедры информационной безопасности, Волгоградский государственный университет [email protected]

просп. Университетский, 100, 400062 r. Волгоград, Российская Федерация

Аннотация. В данной статье рассматриваются возможности реализации дискреционной модели разграничения доступа в ОС Windows 10 с использованием встроенных политик безопасности. Описаны принципы работы дискреционной модели разграничения доступа в ОС Windows 10. Проанализировано соответствие встроенных возможностей дискреционного разграничения доступа в ОС Windows 10 требованиям по защите от несанкционированного доступа к информации согласно руководящему документу «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», утвержденному решением председателя Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 года.

Ключевые слова: разграничение доступа, контрольный монитор безопасности, -ч дескриптор безопасности, маркер доступа, SID, ACL, DACL, SACL. о

(N

О Для обеспечения информационной бе-

Q

g зопасности, а также контроля выдаваемых

(D

§ прав, которые четко и понятно определяют 1! пользователям или ролям доступ к объек-^ там, были придуманы модели разграниче-® ния доступа.

Согласно требованиям руководящего документа «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», утвержденного решением председателя Госу-

дарственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г. для защиты классов защищенности 1Г, 1В, 1Б, 1А должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа [2].

Матрица доступа — это таблица, которая отражает права субъектов по отношению к объектам, например, она используется для описания того, какие пользователи (субъекты) имеют доступ (права доступа) к каким файлам (объектам) [2; 3]. Этот тип управления доступом обычно используется в качестве атрибутов в моделях DAC (дискреционное разграничение доступа).

В Windows 10 разграничения доступа вступают в силу сразу после авторизация пользователя. Дискреционное разграничение доступа реализуется с использованием возможностей базовой файловой системы в ОС семейства Windows — NTFS, которая поддерживает безопасность на уровне файлов. Администраторы могут использовать NTFS для обеспечения контроля доступа к файлам и папкам, контейнерам и объектам в сети в качестве типа защиты системы, такие возможности предоставляет дескриптор безопасности (Security Descriptor) [1; 6].

SecurityDescriptor (SD) — это специальная структура, которая хранит информацию о правилах управления доступом, он включает себя следующую информацию о безопасности [7]:

1. SID (Securityidentifier) — идентификатор безопасности. В системе Windows 10 все действующие субъекты, такие как пользователи, группы, локальные компьютеры, домены идентифицируются уникальным идентификатором защиты.

2. ACL (Access Control List) — это список записей управления доступом, в котором хранятся субъект или субъекты с указанными правами доступа, либо прошедший аудит для этого доверенного лица [4].

Есть два вида ACL:

— DACL (Discretionary Access Control List) — список прав субъекта, отмечает разрешенные или запрещенные права пользователя (субъекта);

— SACL (System Access Control List) -аудит попыток доступа к защищенному объекту, фиксирует источник и тип попыток доступа к защищенному объекту ACE (запись управления доступом) — это элемент ACL.

На рисунке 1 представлена типовая структура ACL, реализованная в семействе ОС Windows [4-6].

Рис. 1. Структура ACL

3. FLAGS — специальные биты (флаги) определяющие значение SD, либо его отдельных членов.

Процесс реализации дискреционной политики в ОС Windows 10 на примере обращения к файлу text_file.txt, представлен на рисунке 2.

Сначала пользователь (Subject) запускает приложение (в нашем случае это будет notepad.exe), которое считывает содержимое файла (Object), потом ОС загружает в память исполняемый код приложения, библиотеки и т. д., после этого создается процесс, который характеризуется маркером доступа (AT), то есть создается копия основного процесса и в зависимости от условий могут назначаться атрибуты права, группы и привилегии, в нашем случае только SID субъекта, а остальные атрибуты остаются без изменения.

AccessToken (AT) — это объект ОС, который показывает какие права доступа есть у пользователя или группы. В него входят идентификатор и привилегии, которые были присвоены этому аккаунту пользователя, связанные с процессом или потоком. После аутентификации в системе создается маркер доступа пользователя, которому будет присваиваться копия основного маркера доступа при создании процесса с этим пользователем [4; 5].

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

После того, как были вычислены итоговые права пользователя, идет переход в режим ядра оттуда передается AT в SRM (SecurityReferenceMonitor) — контрольный монитор безопасности, который управляет доступом к ресурсам и уточняет привилегии [8].

SRM просматривает SD запрашиваемого соответствующего субъекта, а в нем атрибуты SIDSubject, ACL и FLAGS (см. рис. 2). После этого происходит проверка прав на доступ к объекту:

1) сравнение запрашиваемых прав на доступ к объекту с вычисленными итоговыми правами доступа субъекта;

2) определение владельца файла — если SID владельца файла совпала с SID субъекта, запрашивающего доступ, и запрашивается доступ только на чтение или изменение объекта, то субъекту выдается разрешение (Allow);

Рис. 2. Процесс проверки прав у пользователя на доступ к объекту

3) проверка всех запрещающих правил у объекта на доступ к субъекту — если есть хоть одно такое правило, то выдается запрет (Deny);

4) проверка всех разрешающих правил у объекта на доступ к субъекту — если такие правила есть, то выдается разрешение (Allow), если таких правил не найдено, то выдается запрет (Deny).

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

Как видно из реализации методов дискреционного разграничения доступа встроенными средствами ОС Windows 10, они полностью соответствует стандартам по реализации дискреционного разграничения доступа. Отсюда можно сделать вывод, что для реализации разграничения доступа для классов защищенности 1Г, 1В, 1Б, 1А согласно руководящему документу «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», утв. решением председателя Государственной технической комиссии при Прези-

денте Российской Федерации от 30 марта 1992 г. в О С Windows 10 не требуется использование дополнительного программного обеспечения.

СПИСОК ЛИТЕРА ТУРЫ

1. Гортинский, А. В. Использование идентификатора безопасности для установления обстоятельств создания файлов в NTFS / А. В. Гортинский, А. Л. Гаврилов // Информационная безопасность регионов. — 2017. — №№ 1 (26). — С. 5-10.

2. Руководящий документ «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», утв. решением председателя Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г. — Электрон. текстовые дан. — Режим доступа: https://fstec.ru/tekhnicheskaya-zashchita-informatsii/dokumenty/114-spetsialnye-normativnye-dokumenty/384-rakovodyashchij-dokument-reshenie-predsedatelya-gostekhkomissii-rossii-ot-30-marta-1992-g. — Загл. с экрана.

3. Сизоненко, А. Б. Арифметико-логическое представление матрицы доступа в дискреционной модели разграничения доступа / А. Б. Сизоненко // Вестник Воронежского института МВД России. -2012. — №> 3. — С. 201-206.

4. Access Control List // Документация Майкрософта. — Электрон. текстовые дан. — Режим доступа: https://docs.microsoft.com/en-us/openspecs/

Рис. 3. Вычисление итоговых прав доступа субъекта

windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428. — Загл. с экрана.

5. Access Tokens Physical Structure // Документация Майкрософта. — Электрон. текстовые дан. — Режим доступа: https://docs.microsoft.com/pt-pt/ previous-versions/windows/server/cc783557(v=ws.10) #access-tokens-physical-structure. — Загл. с экрана.

6. NTFS Permissions // Документация NTFS -Электрон. текстовые дан. — Режим доступа: https://www.ntfs.com/ntfs-permissions.htm. — Загл. с экрана.

7. Security descriptor // Документация Майкрософта — Электрон. текстовые дан. — Режим доступа: https://docs.microsoft.com/ru-ru/ windows/win32/secauthz/security-descriptors. -Загл. с экрана.

8. Windows Kernel-Mode Security Reference Monitor // Документация Майкрософта — Электрон. текстовые дан. — Режим доступа: https:// docs.microsoft.com/en-us/windows-hardware/drivers/ kernel/windows-kernel-mode-security-reference-monitor. — Загл. с экрана.

IMPLEMENTATION OF DISCRETIONARY ACCESS CONTROL TO WINDOWS 10 OS USING EMBEDDED SECURITY POLICIES

Sergei M. Tsymbalenko

Student, Department of Information Security, Volgograd State University [email protected]

Prosp. Universitetsky, 100, 400062 Volgograd, Russian Federation

Abstract. The article deals with discretionary model of access differentiation to OS Windows 10 using embedded security policies. The principles of discretionary access control to Windows 10 are described. It analyzes the compliance of embedded discretionary access differentiation features to Windows 10 with the requirements to protection against unauthorized access to information according to the guidance document «Automated Systems. Information Protection from Unauthorized Access. Classification of Automated Systems and Requirements for the Protection of Information», approved by the decision of the chairman of the State Technical Commission under the President of the Russian Federation on March, 30th 1992.

Key words: access control, security reference monitor, security descriptor, access token, SID, ACL, DACL, SACL.

Разграничение доступа пользователей в ОС Windows. ПАК СЗИ НСД «Аккорд-Win64» (8/11)

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

Здравствуйте!

В данной лекции мы поговорим о дискреционном механизме управления доступом, рассмотрим требования этого механизма, понятие используемой в нем матрицы доступа. А также поговорим, как происходит задание правил разграничения доступа с использованием данного механизма в программно-аппаратном комплексе СЗИ от НСД «Аккорд-Win64».

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

Дискреционное управление доступом к объектам КС предполагает выполнение следующих требований:

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

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

Дискреционное управление доступом к объектам КС реализуется обычно в виде матрицы доступа, строки которой соответствуют объектам КС, а столбцы – ее субъектам. Элементы матрицы доступа определяют права доступа субъектов к объектам.

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

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

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

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

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

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

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

При необходимости добавления нового объекта и задания ему ПРД необходимо нажать кнопку «Новый», для редактирования – «Редактировать». Для удаления какого-либо объекта и установленных для него ПРД, нужно нажать кнопку «Удалить».

Для выхода из режима редактирования с сохранением, необходимо нажать кнопку «Сохранить», без сохранения – «Отмена».

В разделе «Объекты» выберем строку с любым именем объекта и нажмем кнопку «Редактировать». Выводится окно для определения правил доступа к объекту.

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

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

R — разрешение на открытие файлов только для чтения.

W — разрешение на открытие файлов для записи.

C — разрешение на создание файлов на диске.

D — разрешение на удаление файлов.

N — разрешение на переименование файлов.

V — видимость файлов. Позволяет делать существующие файлы невидимыми для пользовательских программ. Этот параметр имеет более высокий приоритет, чем R,W,D,N,O.

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

Операции с каталогом:

M — создание каталогов на диске (или подкаталогов в каталоге, для которого устанавливается атрибут).

Е — удаление каталогов на диске (или подкаталогов в каталоге, для которого устанавливается атрибут).

G — разрешение перехода в этот каталог.

n — переименование каталога. В ОС Windows, например, удаление папки в «корзину» – это, на самом деле, переименование каталога.

Атрибуты регистрации:

r — регистрируются все операции чтения файлов диска (каталога) в журнале.

w — регистрируются все операции записи файлов диска (каталога) в журнале.

И прочие атрибуты:

Х — разрешение на запуск программ

Для группового манипулирования параметрами доступа можно пользоваться кнопками внизу окна. Кнопка «Сброс» сбрасывает все параметры. Кнопка «Чтение» устанавливает для выбранного объекта «файл» атрибуты R – открыть для чтения, V – видимость и X – запуск программ. Для объекта «папка» добавляется атрибут G – переход в данную папку и S – наследование. Кнопка «Полный» включает все атрибуты для полного доступа.

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

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

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

1 — параметры доступа текущего каталога наследуется только подкаталогами следующего уровня;

0 — параметры доступа текущего каталога не наследуются подкаталогами.

Например, если для корня дерева каталогов диска C:\ установить атрибут 0, доступными будут только файлы в корневом каталоге, а остальные каталоги для данного пользователя как бы не существуют. Каталог на диске C:\ будет доступен пользователю (с любой непротиворечивой комбинацией атрибутов) только при явном его описании в списке прав доступа. Если для корневого каталога C:\ установить атрибут S, то все его файлы, каталоги и подкаталоги доступны пользователю и правила доступа к ним определяется атрибутами, установленными для диска C:\.

Для сохранения выбранных атрибутов доступа необходимо нажать «Сохранить», для выхода без сохранения – «Отмена». Нажмем «Отмена».

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

Дальше нужно выбрать объект из списка слева, в поле «Имя объекта» мы увидим его имя, а снизу в поле «Тип объекта» — увидим диск это, каталог, файл, реестр, съемный диск, принтер или устройство. Либо можно ввести в поле «Имя объекта» имя объекта вручную. Выберем файл test1.txt из папки TEST.

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

Более подробно действие атрибутов доступа и их комбинаций описано в методических материалах к лекции – в документе «Руководство администратора на комплекс».

Мы сбросим все имеющиеся атрибуты для файла test1.txt с помощью кнопки «Сброс», а затем сделаем его доступным только на чтение с помощью кнопки «Чтение». Сохраним настройки с помощью кнопки «Сохранить». Затем нажмем «Закрыть», видим, что наш файл появился среди объектов с установленными только что атрибутами. 

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

Подведем итог, в данной лекции мы поговорили о дискреционном механизме управления доступом, рассмотрели требования этого механизма, понятие используемой в нем матрицы доступа. А также поговорили о том, как происходит задание правил разграничения доступа с использованием данного механизма в программно-аппаратном комплексе СЗИ НСД «Аккорд-Win64» для дисков, каталогов и файлов. Однако существуют особенности установки ПРД к сетевым ресурсам, съемным и стационарным устройствам,  об этом мы поговорим на следующей лекции.

Спасибо за внимание, до встречи!

Discretionary access control (DAC) is one of many access control methods that secures information systems. DAC is a method that grants users control over the permissions to their resources, enabling information system and data owners to decide who can access the respective resources and what level of access they can have. This approach supports the principle of least privilege, a concept that advocates for giving users the least amount of access necessary to perform their work. Because DAC relies on human decision-making to provision access, the information system or data owner must be rigorous in their reviews of access requests to ensure overly permissive rights aren’t given. 

More From Katlyn GalloAn Introduction to Microsegmentation in Network Security

How Does DAC Work?

At its most fundamental level, DAC uses access control lists (ACLs) to assign permissions to resources. ACLs contain either users or predefined groups of users and their corresponding access levels. These levels typically include read, write, and execute access, which allows a person to view, modify, or run a process or program, respectively. 

For example, imagine that a user attempts to open a file share on a corporate network. When that user requests access, the DAC system checks the authentication information and compares it to the ACL associated with the resource the user is attempting to access. If the information matches the ACL entry, the user is granted the access defined in the ACL, whether it’s read, write, or execute. If the user information doesn’t match an ACL, the request is denied. 

Here’s a step-by-step breakdown of how DAC works from resource creation to access enforcement.

1. Someone creates a resource, such as a file or folder, and the creator is now the owner who can control access permissions. 
2. The owner then configures the ACL for the newly created resource, assigning users and groups who should have access with the required permissions. 
3. One or more users who have been granted permission to the resource attempt to access it, resulting in an access request to the DAC system.
4. The DAC system checks that the user information in the request aligns with an ACL, and then approves or denies the request depending on whether it finds an ACL.
5. The DAC system enforces its decision in real time, allowing the user to view, modify, or run the resource requested so long as the corresponding ACL permits the action.

Implementation of Discretionary Access Control

Implementing DAC requires planning along with consideration of your existing security policies, as the resource owner enforcing permissions must ensure they do so in compliance with company or department expectations. These steps are key to implementing DAC effectively and ensuring it’s properly maintained.

Define Security Policies

Establish clear access control policies for your organization or department. Determine who should have access to which resources and what level of access should be granted.

Classify Resources

Categorize your resources based on their sensitivity and importance. This is essential to ensuring ACLs are appropriately assigned to resources, especially those that are confidential or highly sensitive where access must be carefully controlled.

Set Up User and Group Management

Create and manage user accounts and groups used to assign DAC permissions. Ensure you organize users and groups in a way that aligns with the access control policies that the organization has defined.

Configure ACLs

For each resource, configure ACLs that define which users and/or groups can access the resource and what level of permissions they must have (read, write, or execute).

Conduct Regular Audits

Periodically review and audit DAC policies to ensure there are no non-compliant situations. If identified, non-compliant permissions should be investigated, documented and updated to align with the DAC policy.

Implement Training and Awareness Programs

Educate users about the importance of DAC, their role in maintaining an effective DAC implementation, and the consequences of not complying with access control policies. 

Limitations of DAC

Although discretionary access control offers flexibility and user discretion, it does have some drawbacks and limitations. 

Reliant on Human Judgment

Since DAC relies on resource owners to make access control decisions, a misconfigured ACL or misunderstanding of security requirements can lead to data exposure and unauthorized access.

Not Scalable

DAC is not a scalable access control method, as it can become time-consuming and complex to manage access for many resources and users.

Lacks Centralized Administration

DAC lacks centralized control because access is applied at the resource level. This makes it difficult to enforce specific security policies across an organization and assess the policies that are in place. 

Increased Insider Threat Risk 

DAC doesn’t provide adequate protection against insider threats, where authorized users might misuse their privileges to access or steal sensitive data, grant unauthorized users permissions, or disclose information to unauthorized parties.

Discretionary Access Control (DAC) vs. Mandatory Access Control (MAC)

To further understand DAC and its advantages and disadvantages, let’s compare it to mandatory access control (MAC), which is essentially the opposite of DAC. In a MAC model, access control policies are enforced by the system rather than at the discretion of a resource owner. 

Although MAC offers less flexibility and can be more complex, it features a more secure access control design that’s focused on ensuring access aligns with specified data classification and sensitivity levels. Because of this, MAC is often used for networks and information systems that are processing highly sensitive or confidential information, such as those in government facilities.

Cybersecurity and PhilosophyCan We Control Technology?

Examples and Applications of DAC 

You can find discretionary access control in almost any computing system or environment.

File and Folder Permissions

The most common example is file and folder permissions that exist in Windows and Unix-based operating systems. When a file or folder is created, the owner can then specify who can access it and what rights they have (read, write, execute). 

Cloud Storage Platforms

The same holds true for cloud storage platforms, such as Microsoft OneDrive and SharePoint or Google Drive. If a user wants to share a file or folder that exists on their personal storage account, they must specify to whom it will be shared and what level of access they wish to provide (view or edit). This level of control allows individuals to manage their files according to their preferences, information sensitivity, and security requirements. 

Database Management Systems

Database management systems are another example where DAC is common. To control access to the various databases they maintain, database administrators employ users or groups to define who can access which database and what they can do within them. This ensures that only those authorized to view each database are given access to the data they need to view or modify and nothing more. 

Введение

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

Для построения формальных моделей безопасности принято представлять ИС в виде совокупности взаимодействующих сущностей — субъектов (s) и объектов (o).

Защищаемые объекты Windows включают: файлы, устройства, каналы, события, мьютексы, семафоры, разделы общей памяти, разделы реестра ряд других. Сущность, от которой нужно защищать объекты, называется «субъектом». Субъектами в Windows являются процессы и потоки, запускаемые конкретными пользователями. Субъект безопасности — активная системная составляющая, а объект — пассивная.

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

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

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

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

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

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

Инструментальные средства управления безопасностью

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

Для управления системой безопасности в ОС Windows имеются разнообразные и удобные инструментальные средства. В частности, в рамках данной темы потребуется умение управлять учетными записями пользователей при помощи панели «Пользователи и пароли». Кроме того понадобится контролировать привилегии пользователей при помощи панели «Назначение прав пользователям». Рекомендуется также освоить работу с утилитой просмотра данных маркера доступа процесса WhoAmI.exe, утилитами просмотра и редактирования списков контроля доступа (cacls.exe, ShowACLs.exe, SubInACL,exe, SvcACL.exe), утилитой просмотра маркера доступа процесса PuList.exe и рядом других.

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

Пользователи и группы пользователей

Каждый пользователь (и каждая группа пользователей) системы должен иметь учетную запись (account) в базе данных системы безопасности. Учетные записи идентифицируются именем пользователя и хранятся в базе данных SAM (Security Account Manager) в разделе HKLM/SAM реестра.

Учетная запись пользователя содержат набор сведений о пользователе, такие, как имя, пароль (или реквизиты), комментарии и адрес. Наиболее важными элементами учетной записи пользователя являются: список привилегий пользователя в отношении данной системы, список групп, в которых состоит пользователь, и идентификатор безопасности SID (Security IDentifier). Идентификаторы безопасности генерируются при создании учетной записи. Они (а не имена пользователей, которые могут не быть уникальными) служат основой для идентификации субъектов внутренними процессами ОС Windows.

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

Создание учетной записи пользователя

Основным средством создания учетной записи пользователя служит Win32-функция NetUserAdd, принадлежащая семейству сетевых ( Net ) функций ОС Windows, подробное описание которой имеется в MSDN. При помощи Net -функций можно управлять учетными записями пользователей, как на локальной, так и на удаленной системе (более подробно об использовании Net -функций можно прочитать в
[
Рихтер
]
,
[
Рихтер, Кларк
]
).

Для успешного применения Net -функций достаточно знать следующее. Во-первых, Net -функции входят в состав библиотеки NetApi32.Lib, которую нужно явным образом добавить в проект, а прототипы функций объявлены в заголовочном файле Lm.h. Во-вторых, Net -функции поддерживают строки только в формате Unicode (см.
«Разработка Win32 приложений. Инструментальные средства изучения системы»
). Наконец, информацию об учетной записи Net -функции нужно передавать с помощью специализированных структур, наименее сложная из которых структура USER_INFO_1.

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

Для иллюстрации рассмотрим несложную программу, задача которой — создать новую учетную запись для пользователя «ExpUser».

#ifndef UNICODE
#define UNICODE
#endif

#include <stdio.h>
#include <windows.h> 
#include <lm.h>


BOOL CreateUser(PWSTR pszName, PWSTR pszPassword) {
  USER_INFO_1 ui = {0};
  NET_API_STATUS nStatus;
  ui.usri1_name = pszName;              // имя пользователя
  ui.usri1_password = pszPassword;      // пароль пользователя
  ui.usri1_priv = USER_PRIV_USER;       // обычный пользователь

  nStatus = NetUserAdd(NULL, 1, (LPBYTE)&ui, NULL);
  return (nStatus == NERR_Success);
}


void main() {
   if(!CreateUser(L"ExpUser", L"123"))
      printf("A system error has occurred");
   }

Результат работы программы — создание нового пользователя — можно проконтролировать при помощи апплета панели управления «Локальные пользователи». После создания пользователя целесообразно наделить его минимальным набором прав, например, правом входа в систему. Самое разумное — включить пользователя в какую-либо группу, например, в группу обычных пользователей. В этом случае вновь созданный пользователь получит привилегии члена данной группы. Это можно сделать при помощи того же апплета. О том, как обеспечить пользователя необходимыми привилегиями программным образом, будет рассказано ниже.

Для удаления учетной записи пользователя используется функция NetUserDel.

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

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

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

Идентификатор безопасности SID

Структура идентификатора безопасности

SID пользователя (и группы) является уникальным внутренним идентификатором и представляют собой структуру переменной длины с коротким заголовком, за которым следует длинное случайное число. Это числовое значение формируется из ряда параметров, причем утверждается
[
Руссинович
]
, что вероятность появления двух одинаковых SID практически равна нулю. В частности, если удалить пользователя в системе, а затем создать его под тем же именем, то SID вновь созданного пользователя будет уже другим.

Узнать свой идентификатор безопасности пользователь легко может при помощи утилит whoami или getsid из ресурсов Windows. Например, так:

При помощи команды whoami /all можно получить всю информацию из маркера доступа процесса, см. следующие разделы.