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

Концепция избирательного управления доступом берёт своё начало в ранних операционных системах с разделением времени. В 1965 году в операционной системе Multics были впервые представлены списки управления доступом (Access Control Lists, ACL). Эта система позволяла владельцам объектов самостоятельно определять права доступа для других пользователей, заложив основу для механизмов избирательного управления^[2].

Формализация и стандартизация модели произошла с выпуском Министерством обороны США стандарта «Критерии оценки доверенных компьютерных систем» (TCSEC, «Оранжевая книга»). Документ, опубликованный в 1983 году и обновлённый в 1985 году, сделал избирательное управление доступом обязательным требованием для базовых классов безопасности компьютерных систем (начиная с уровня C1)^[3].^[4]

На практике значение термина избирательного управления доступом не столь однозначно, как определено в стандарте TCSEC, поскольку определение TCSEC не предписывает конкретных способов реализации. Существует по меньшей мере две реализации: с использованием владельца объекта (распространённый вариант) и с использованием возможностей (capabilities)^[5].

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

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

В операционных системах Windows (включая Windows 11 и Windows Server 2025) механизм передачи прав доступа реализуется через списки управления избирательным доступом (DACL). Владелец объекта обладает неотъемлемым правом изменять DACL, предоставляя или отзывая права доступа другим пользователям, даже если ему самому доступ явно запрещён. Прямой передачи владения в Windows нет, вместо этого используется механизм смены владельца (Take Ownership), позволяющий пользователям с соответствующими разрешениями или привилегиями администратора стать новыми владельцами объекта^[6].

В современных дистрибутивах Linux для более гранулярной передачи прав доступа используются списки контроля доступа POSIX ACL и расширенные атрибуты (xattr). POSIX ACL расширяют стандартную модель прав, позволяя назначать разрешения для конкретных пользователей и групп с помощью утилит setfacl и getfacl, а сами списки доступа хранятся в расширенных атрибутах файловой системы^[7].

Другой пример — безопасность на основе возможностей (capability-based security): такие системы иногда описывают как предоставляющие избирательные средства управления, поскольку они позволяют субъектам передавать свои права другим субъектам, хотя в основе security на возможностях не лежит ограничение по идентичности субъекта. Как правило, такие системы не позволяют передавать права абсолютно любому субъекту: субъект, желающий передать право, должен иметь доступ к принимающему субъекту, причём доступ обычно ограничивается кругом субъектов, соответствующим принципу наименьших привилегий.

Современные примеры реализации модели безопасности на основе возможностей включают как программные, так и аппаратные подходы. Программная реализация применяется в операционной системе Fuchsia (на базе микроядра Zircon), где доступ к объектам осуществляется через защищённые дескрипторы (handles). Аппаратная реализация представлена в архитектуре CHERI, которая заменяет традиционные указатели памяти на токены с заданными границами и разрешениями^[8].^[9]

Для реализации принципа наименьших привилегий в подобных системах применяются механизмы делегирования и ослабления возможностей (capability attenuation). При передаче прав субъект может создать и делегировать другому субъекту не точную копию своей возможности, а её ослабленную версию (например, ограничив доступ с чтения и записи только до чтения)^[10].

Избирательное управление доступом обладает рядом фундаментальных недостатков безопасности. Одной из наиболее значительных проблем является уязвимость к атакам типа «Троянский конь». Если пользователь запускает программу, содержащую вредоносный код, она выполняется с теми же правами доступа, что и сам пользователь. Это позволяет вредоносному ПО без ведома пользователя копировать, изменять или удалять доступные ему файлы, поскольку модель DAC не может достоверно определить истинный источник запроса на доступ к данным^[11].

Неправильная настройка прав доступа может приводить к рискам несанкционированного повышения привилегий. На практике злоумышленники часто используют уязвимости в системных компонентах и драйверах (например, в экосистеме Windows) для обхода механизмов списков управления избирательным доступом (DACL) и получения максимальных прав уровня SYSTEM^[12].^[13]

В крупных системах управление правами доступа с помощью DAC становится сложным и повышает риск ошибок, таких как случайное предоставление избыточных прав. Поскольку владельцы ресурсов сами управляют доступом, в системе отсутствует единый централизованный контроль и политика безопасности. Это затрудняет аудит, отслеживание потоков данных и последовательное применение принципа наименьших привилегий в масштабах всей организации^[14].^[15]

В современных программно-управляемых архитектурах классический принцип избирательного управления доступом (DAC) в чистом виде уступает место концепции «нулевого доверия» (Zero Trust) и более централизованным моделям, таким как управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC)^[1].^[15][14]

В облачных хранилищах традиционные списки контроля доступа (ACL), реализующие DAC, часто отключаются по умолчанию в пользу централизованных политик. Например, в Amazon S3 для новых контейнеров (бакетов) списки ACL отключены, а управление доступом осуществляется через политики бакетов и IAM. В Azure Blob Storage также применяется многоуровневая модель доступа с приоритетом централизованного управления^[16].

Применение DAC ограничено в микросервисных архитектурах и при управлении доступом к API. Использование избирательной модели в таких распределённых средах создаёт риск «разрастания прав» и усложняет аудит. Вместо этого управление доступом централизуется на уровне API-шлюзов с применением политик RBAC или ABAC^[17].

На рынке систем контроля доступа наблюдается тенденция к переходу на облачные платформы (Access Control as a Service, ACaaS), которые также используют ролевое и атрибутное управление^[18]. Эта трансформация подтверждается стратегическими шагами крупных компаний, такими как приобретение корпорацией Honeywell подразделения Global Access Solutions для развития облачных сервисов безопасности^[19].