Руслан Рахметов, Security Vision
При управлении информационной безопасностью в компании одним из наиболее важных вопросов становится выбор верной модели управления доступом. В зависимости от применимых нормативных требований и потребностей компании можно выбрать дискреционную, мандатную, ролевую или атрибутную модель управления доступом, а также рассмотреть ряд менее распространенных подходов. В данной статье мы проведем краткий обзор основных моделей контроля доступа, но сосредоточимся на ролевой модели безопасности и её отличиях от атрибутной модели.
Для начала следует познакомиться с базовыми определениями. Так, в руководящем документе Гостехкомиссии России (регулятор-предшественник ФСТЭК России) от 30 марта 1992 г. «Защита от несанкционированного доступа к информации. Термины и определения» даются следующие определения:
· Субъект доступа - это лицо или процесс, действия которого регламентируются правилами разграничения доступа;
· Объект доступа - это единица информационного ресурса автоматизированной системы, доступ к которой регламентируется правилами разграничения доступа;
· Правила разграничения доступа - это совокупность правил, регламентирующих права доступа субъектов доступа к объектам доступа.
Под субъектом может пониматься не только реальный пользователь (в виде учетной записи, закрепленной за определенным работником компании), но и служебный пользователь, который создан для запуска процессов, служб, выполнения технических действий - например, пересылки журналов безопасности или создания резервных копий. В любом случае, служебные пользователи должны быть обязательно закреплены за каким-либо сотрудником компании (например, системным администратором или ИБ-специалистом), создание деперсонализированных (временных или не закрепленных за определенным работником) и разделяемых (пароль для которых известен сразу нескольким сотрудникам) учетных записей не должно допускаться, их пароли должны подчиняться правилам корпоративной парольной политики, а полномочия в системах - регулярно пересматриваться.
И у субъектов, и у объектов доступа есть атрибуты: для субъектов это свойства учетной записи (имя пользователя, должность, отдел, структура подчиненности и т.д.), а для объектов это свойства файла, информационной системы, технического средства. Субъекты доступа обладают привилегиями (полномочиями / пермиссиями / правами доступа) - т.е. правами на осуществление определенных операций с объектам доступа (например, чтение, запись, выполнение, добавление нового пользователя, аудит и т.д.), которые регламентированы правилами разграничения доступа, установленными компанией-владельцем информации в политике доступа, и которые могут быть выполнены только при определенных заданных условиях (например, успешная аутентификация, подключение из определенного VLAN корпоративной сети, доступ в рабочее время). Также существуют атрибуты среды функционирования информационной системы - текущие дата и время, сетевые свойства (беспроводная / проводная сеть, VLAN) и географическая принадлежность (GeoIP) устройства доступа, уровень безопасности устройства (например, наличие неустраненных уязвимостей) и инфраструктуры (например, количество незакрытых киберинцидентов), используемое приложение и сетевой порт и т.д.
Аутентификация - это проверка подлинности предъявляемых субъектом учетных данных (идентификатор / логин, пароль, одноразовый код, биометрия), которая выполняется доверенной стороной (системным процессом, контроллером домена, провайдером аутентификации). Авторизация (контроль доступа) - это процедура принятия решения о предоставлении или отклонении доступа субъекта к защищаемому объекту доступа в зависимости от соблюдения условий и правил разграничения доступа, с дальнейшим предоставлением субъекту необходимых привилегий для выполнения запрашиваемых операций.
Кроме того, важно помнить и 8 принципов безопасной архитектуры системы и реализации защитных механизмов, которые были сформулированы в 1975 году учеными Джеромом Зальцером и Майклом Шрёдером в работе «Защита информации в компьютерных системах»:
1. Простота защитных механизмов: архитектура системы безопасности должна быть максимально простой;
2. Безопасность по умолчанию: доступ субъектам должен быть запрещен по умолчанию, а защитные механизмы должны определять ограниченный набор условий, при которых доступ будет разрешен;
3. Полная опосредованность: каждая попытка доступа к объекту должна проходить через защитные механизмы и проверяться ими;
4. Открытая архитектура: архитектура системы безопасности не должна быть секретной (чего сложно добиться и что усложнило бы аудит системы), а должна базироваться на секретных ключах и паролях (которые проще защитить);
5. Разделение привилегий: для доступа к чувствительным объектам защитный механизм должен запрашивать подтверждение минимум от двух независимых субъектов (что делает невозможным выполнение критичных действий одним лицом);
6. Минимизация привилегий: каждый субъект должен работать в системе лишь с ограниченным набором привилегий, минимально необходимым для выполнения рабочих задач;
7. Минимизация числа общих защитных механизмов: следует минимизировать число разделяемых между субъектами защитных механизмов для снижения числа вероятных точек отказа и потенциальных каналов неконтролируемого обмена информацией между субъектами;
8. Психологическая приемлемость: важно, чтобы пользовательский интерфейс защитных механизмов был понятен и удобен субъектам доступа (что снижает число человеческих ошибок и упрощает работу с системой).
Модель управления доступом (модель контроля доступа / модель разграничения доступа / модель безопасности) - это система контроля соблюдения условий и правил разграничения и предоставления доступа субъектов к объектам, предназначенная для обеспечения информационной безопасности объектов, аудита попыток доступа и предотвращения несанкционированного доступа к ним. Модели управления доступа реализуются в виде защитных механизмов, которые обеспечивают функционал контроля и предоставления доступа на основе правил разграничения доступа. Правила разграничения доступа описывают возможные права доступа субъектов к объектам, которые записываются в виде списка контроля доступа (ACL, access control list), состоящего из записей контроля доступа (ACE, access control entries). ACL-список можно представить в виде набора ACE-записей вида:
· пользователь User1 обладает правами на чтение, запись, выполнение файла File1;
· пользователю User2 запрещена запись в файл File2;
· система с IP-адресом IP1 может получить доступ к системе с IP-адресом IP2 по порту TCP:443 в будни с 9:00 до 18:00.
Наиболее популярными моделями управления доступом являются:
1. Дискреционная модель управления доступом (DAC, Discretionary Access Control), в которой владелец объекта может самостоятельно устанавливать и изменять права доступа субъектов, а также передавать права на управление объектом другому субъекту. В современных информационных системах таким владельцем является, как правило, администратор, который формирует и изменяет матрицу доступа (вариант ACL-списка), в которой перечислены субъекты и определены их полномочия для всех объектов (например, чтение, запись, выполнение). Дискреционная модель разграничения доступа применяется в большинстве современных ОС, но имеет определенные недостатки:
· Сложность контроля доступа к объектам за счет множества ACL, которые могут быть перенастроены владельцами в нарушение политики ИБ, что может привести к несанкционированному доступу и утечке данных;
· Конфиденциальность информации может быть нарушена в случае чтения данных из одного файла и последующей записи в другой файл с менее строгим ACL;
· Если ВПО работает в контексте скомпрометированной учетной записи, обладающей правами администратора или владельца объектов, то конфиденциальность информации может быть легко нарушена;
· Сложность аудита доступа, поскольку необходимо пройти по всем объектам и получить ACL для каждого из них;
· Сложность централизованного управления ACL-листами для всех объектов во всех информационных системах компании.
2. Мандатная модель управления доступом (MAC, Mandatory Access Control), в которой защитный механизм позволяет контролировать и предоставлять доступ на основе меток конфиденциальности объектов и формы допуска субъектов. Таким образом, в мандатной модели безопасности присутствует централизованный независимый механизм управления доступом и отсутствует владелец, который мог бы по своему усмотрению менять права доступа. Правила доступа мандатной модели описываются, например, следующим образом: пользователь User1 с формой допуска Clearance3 обладает правом на чтение файла File1 с меткой конфиденциальности Classification3. Данная модель доступа применяется, как правило, в государственных системах и реализована в Linux (модули безопасности SELinux, AppArmor) и в ряде сертифицированных российских ОС. Преимуществом мандатной модели является высокий уровень защиты информации от утечек, однако к недостаткам можно отнести сложность настройки и трудности при совместной работе с другими моделями управления доступом в одной системе.
3. Ролевая модель управления доступом (RBAC, Role-Based Access Control), в которой права доступа предоставляются не отдельным субъектам, а определенным ролям, соответствующим функционалу бизнес-подразделений и воспроизводящим организационно-штатную структуру компании. В отличие от мандатной модели, ролевая модель безопасности больше ориентирована на контроль доступа к приложениям, бизнес-функциям и информации, чем только к информации. В отличие от дискреционной модели, пользователи не могут предоставить права доступа другим пользователям по своему усмотрению, а для организации доступа администратор системы предоставляет пользователю новую роль - например, включает его в определенную доменную группу пользователей. Поскольку ролевая модель разграничения доступа позволяет оперировать ролями, соответствующими бизнес-структуре компании (дивизионы, департаменты, отделы, группы и т.д.), существенно повышаются возможности и простота администрирования - например, при переходе сотрудника в новое подразделение ему назначается новая роль, которой уже предоставлены все необходимые для работы полномочия. Кроме того, ролевая модель доступа позволяет реализовать статическое разделение полномочий (невозможность одновременного присвоения субъекту нескольких критичных ролей) и динамическое разделение полномочий (субъект может выполнять определенные функции только одной из присвоенных ему ролей в каждый момент времени). Ролевая модель управления доступом позволяет реализовать принципы наименьших привилегий и разделения полномочий, избежать избыточного назначения привилегий (англ. authorization creep / privilege creep / permission drift) при переходе сотрудников в другие подразделения, а также может снизить административную нагрузку при большой текучке кадров.
4. Атрибутная модель управления доступом (ABAC, Attribute Based Access Control), в которой права доступа предоставляются в зависимости от атрибутов субъекта, объекта, среды функционирования системы и запрашиваемого действия в соответствии с заданными администратором правилами. Атрибутами субъекта могут быть его должность, грейд, отдел, проектная роль, форма допуска, а также роль, назначенная в рамках RBAC. Атрибутами объекта могут быть тип файла, приложение, сетевой протокол и порт, метка конфиденциальности файла. Атрибутами среды функционирования могут быть тип сети (проводная или беспроводная), характеристики и местоположение устройства, дата и время, наличие вредоносной активности в сетевом сегменте. Использование атрибутов дает возможность более гибкого разграничения доступа за счет модификации значений атрибутов субъектов и объектов без изменения их взаимосвязей и всей политики доступа - например, доступ пользователя к критичным файлам можно временно запретить, пока он работает с личного устройства не из офиса. Модель ABAC является достаточно гибкой и позволяет использовать язык XACML (eXtensible Access Control Markup Language) для описания правил разграничения доступа, поэтому она всё чаще используется в различных современных приложениях и при API-взаимодействиях. Однако весомым минусом ABAC является сложность проведения аудита эффективных прав доступа пользователей, поскольку они зависят от множества непрерывно изменяющихся атрибутов субъектов, объектов, среды функционирования.
Вкратце описав основные модели управления доступом, перейдем к перечислению характеристик ролевой модели безопасности и к её сравнению с атрибутной моделью. Итак, ролевая модель управления доступом обладает следующими особенностями:
· Для первоначальной настройки и дальнейшей поддержки RBAC потребуется создать и регулярно пересматривать перечень ролей и их привилегий, которые соответствуют организационно-штатной структуре компании (т.н. role engineering). Такой подход оправдан в случае крупных компаний и государственных учреждений, где новые подразделения появляются не очень часто, а должностной функционал работников относительно статичен. В случае, если в компании небольшое число работников с широким функционалом («сотрудники-универсалы») или ведется в основном проектная деятельность, то возможно более подходящей моделью безопасности будет ABAC.
· Модель RBAC в ограниченном формате заложена во многие современные ОС и приложения - как правило, за счет создания ролей или групп пользователей, которым присваиваются те или иные полномочия в системе. Например, в доменной структуре ОС Microsoft Windows по умолчанию присутствует ряд ролей, используемых для административных задач: Enterprise Admins, Domain Admins, DHCP Administrators, DnsAdmins, Backup Operators, Event Log Readers и т.д. При настройке пользовательских ролей в Windows создаются учетные записи для сотрудников, затем они объединяются в группы, затем этим группам пользователей выдаются разрешения на выполнение действий (например, группе "Секретариат" предоставляются права на отправку больших файлов за пределы корпоративной сети по email) и на доступ к каталогам и файлам (например, группе «Отдел корпоративных продаж» предоставляется разрешение на чтение и изменение файлов в папке \\FileServer\SalesDepartment\B2B). При выходе нового сотрудника в отдел корпоративных продаж его сразу включают в соответствующую группу пользователей «Отдел корпоративных продаж», что снижает административную нагрузку и позволяет предоставлять всем пользователям из одного подразделения одинаковые права доступа, минимально необходимые им для выполнения должностных обязанностей. При переходе сотрудника из одного подразделения в другое (например, из продаж в секретари) его учетная запись исключается из старой группы «Отдел корпоративных продаж» и включается в новую группу «Секретариат» - такой подход позволяет легко актуализировать полномочия сотрудников, соблюсти принцип разделения и минимизации полномочий, а также избежать избыточного назначения привилегий (authorization creep). При этом штатный функционал групп пользователей в Windows не позволяет реализовать статическое и динамическое разделение полномочий, а также предоставляет лишь ограниченные возможности по ведению иерархической структуры ролей.
· Ролевая модель управления доступом при точной настройке позволяет избежать как избыточного, так и недостаточного предоставления полномочий. Избыточные полномочия (англ. overentitlement) могут способствовать повышению риска утечки информации или негативного воздействия на инфраструктуру (например, пользователь с избыточными правами может случайно или преднамеренно удалить большой объем информации с файлового сервера). Недостаточные полномочия (англ. underentitlement) также несут определенные риски: сотрудник либо не сможет эффективно трудиться, либо попытается обойти наложенные ограничения (например, попросит логин и пароль у коллеги для выполнения работы) - это, в свою очередь, приведет к снижению контролируемости доступа к информации и к сложностям при аудите.
· Ролевая модель безопасности позволяет улучшить как «бумажную», так и практическую ИБ за счет ведения реестра ролей с описанием их полномочий, назначения прав доступа к приложениям и файловым каталогам для групп (а не для отдельных пользователей), возможности быстрого проведения аудита прав доступа конкретного сотрудника ко всем активами компании (за счет анализа присвоенных ему ролей и включенности его аккаунта в доменные группы), упрощения формирования отчетности для профильных регуляторов, а также соблюдения принципов разделения, минимизации и актуализации полномочий.
· Модель безопасности RBAC позволяет уменьшить затраты на администрирование учетных записей и предоставление прав доступа, снизить время простоя новых сотрудников до начала выполнения ими должностных обязанностей со всеми необходимыми полномочиями, повысить продуктивность работы коллектива.
Проводя сравнение ролевой и атрибутной моделей, следует отметить, что RBAC менее гибкая, однако более простая в настройке при условии относительно статичной организационно-штатной структуры и информационной инфраструктуры, а ABAC - гибче, но и сложнее при настройке и поддержке актуальности. Оптимальным решением может быть комбинация обоих моделей безопасности, например, за счет:
· Учета различных дополнительных атрибутов при назначении ролей - например, путем установки атрибута в виде срока действия для каждой роли, по истечению которого роль становится неактивной;
· Формирования динамических ролей, когда атрибуты определяют роль, которая присваивается пользователю в конкретный момент - например, в зависимости от текущего времени или местоположения субъекта;
· Формирования атрибуто-центричной модели доступа, при которой роль - это не набор разрешений, а всего лишь один из атрибутов;
· Формирования роле-центричной модели доступа, при которой атрибуты только ограничивают права роли, назначенные RBAC, но не могут расширить их.
В заключение приведем список других, чуть менее популярных моделей управления доступом:
· Модель управления доступом на основании правил (RuBAC, Rule-Based Access Control) заключается в предоставлении доступа субъектам в соответствии с задаваемыми администратором системы логическими условиями вида "Если-То". В какой-то степени RuBAC схожа с ABAC, однако по механике применения RuBAC похожа скорее на сетевые правила, устанавливаемые на межсетевом экране и применяемые сразу ко всем пользователям (каждый запрос на доступ любой учетной записи проходит по всему списку условий);
· Риск-ориентированная модель управления доступом (Risk-Based Access Control) заключается в предоставлении доступа в зависимости от риск-профиля субъекта и объекта доступа и уровня риска, оцениваемого для запрашиваемого действия;
· Контентно-зависимая модель управления доступом (CDAC, Content-Dependent Access Control) заключается в предоставлении доступа субъекту в зависимости от содержания объекта (например, доступ может предоставлен только к определенной информации в базе данных);
· Контекстно-зависимая модель управления доступом (Context-Dependent Access Control) заключается в предоставлении доступа субъекту в зависимости от предыдущих запросов доступа к объекту (например, при принятии решения о пропуске или блокировании трафика учитывается состояние сетевого соединения, а при принятии решения о предоставлении доступа к записи в базе данных учитываются предыдущие запросы пользователя, которые могут свидетельствовать о преднамеренном сборе им чувствительной информации);
· Граф-ориентированная модель управления доступом (GBAC, Graph-Based Access Control) заключается в формировании графа связей субъектов и объектов, что позволяет управлять доступом к вложенным структурам данных (например, социальная сеть позволяет разрешить доступ к информации на странице пользователя не только «друзьям», но и «друзьям друзей»);
· Организационно-ориентированная модель управления доступом (OrBAC, Organisation-Based Access Control) заключается в формировании дополнительного уровня абстракции модели безопасности, в котором фигурируют роли (а не отдельные субъекты), деятельность (а не отдельные операции), представление информации (а не отдельные объекты).
