Контроль доступа на основе атрибутов и оптимизация управления множеством АПМДЗ

Алтухов А.А.

Закрытое акционерное общество «ОКБ САПР», Москва, Россия.

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

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

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

Одним из возможных вариантов СЗИ может быть (аппаратный) модуль доверенной загрузки (АМДЗ, А(П)МДЗ, МДЗ, модуль) [1. C. 142], задача которого обеспечить доверенную вычислительную среду (ДВС) [2. C. 204].

В парадигму резидентного компонента безопасности (РКБ) [Там же. С. 208], а значит и в его возможные реализации, были заложены принципы «определенности пользователя» (иными словами был заведомо известен перечень пользователей работающих с конкретным средством вычислительной техники (СВТ)) и принцип «самодостаточности» (предполагается, что РКБ обладает всей необходимой информацией для организации ДВС [3]).

В силу того, что «количественный», объединяющий «компонентную» и «территориальную» проблемы, аспект характеризует и подсистему модулей доверенной загрузки, входящей в состав ИС, то единственный способ управления огромным количеством территориально разбросанных модулей — это возможность удаленного централизованного управления. Поэтому система удаленного централизованного управления (СУЦУ) модулями доверенной загрузки, внедренная в ИС, должна решать не только наиболее типовую задачу централизованного аудита, но и более сложные: модификация списка контролируемых элементов[1] или управление учетными данными пользователей, например добавление нового пользователя в определенный модуль или группу модулей[2]. В общем случае СУЦУ должна обеспечивать функциональность не менее чем возможности локальной настройки АМДЗ.

СУЦУ обычно состоит из центрального элемента управления[3] (центр управления, ЦУ), который является ЭВМ с необходимым программным обеспечением (ПО), и из резидентных агентов, которые могут работать как в доверенной ОС и взаимодействовать с АМДЗ, так и в резидентной ОС АМДЗ. Возможны гибридные варианты, в этом случае функциональность разделяется или дублируется.

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

Как отмечалось раньше, в основе традиционной парадигмы АМДЗ лежит принцип «самодостаточности». Предполагается, что АМДЗ оперирует лишь теми данными, которые хранятся в специальной защищенной памяти и которые были получены во время сеанса работы администратора системы. Еще одной особенностью является подход к разграничению доступа пользователей, который традиционно является «пользователя ориентированным».

В данной статье мы уделим внимание существующей концепции управления, аутентификации и авторизацией пользователей модулем доверенной загрузки. Покажем проблемы, возникающие при использовании СУЦУ.

Рассмотрим классический подход к организации управления доступом в модуле доверенной загрузки[4].

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

Для типовой реализации база данных пользователей является белым списком пользователей, которые имеют полномочия что-либо делать (полномочия хранятся вместе со списком). Для каждого пользователя определен набор дополнительный условий и прав (атрибуты), на основе которых осуществляется авторизация. Каждой учетной записи соответствует высчитанный особым образом эталон аутентифицирующей информации пользователя (АИП), который позволяет аутентифицировать пользователя[5].

Из этого описания явно проявляется «пользователя ориентированный» подход к аутентификации и авторизации. Учитывая вышеуказанные аспекты, единственная возможность реализации системы управления пользователями — это надстройка над возможностью управления каждым модулем отдельно. Данный подход является не очень удобным по той простой причине, что мы решили «территориальную проблему» (появился центр управления, не нужно локально администрировать каждый модуль), но не решили «компонентную проблему» (управлять приходиться каждым по отдельности). Последняя проблема решается за счет группового решения типовых задач. Например, нет ничего удивительного в том, что каждый из пользователей принадлежит к конкретной группе (например, в медицинских системах: врач или больной). В случае если все СВТ предназначены для решения определенных типовых задач (например, стационарный терминал в кабинете врача), то в этом случае параметры контроля среды будут одинаковые, и нет смысла настраивать перечень контролируемых объектов среды для каждого модуля отдельно, ведь можно сделать одну общую конфигурацию для целой группы модулей. Для решения проблемы «компонентов» в СУЦУ достаточно добавить еще один уровень абстракции, который будет давать возможность работы с группами и шаблонами. Как можно видеть, в данном случае растет сложность ПО ЦУ и резидентных агентов на клиентских машинах, как следствие – сложность протокола взаимодействия.

Проблема усугубляется при необходимости поддержать не родственный АМДЗ подход – «на определенном ЭВМ может работать лишь N определенных пользователей», а набирающий популярность в различных ИС подход «каждый с каждым», когда каждый пользователь системы может работать в соответствии со своими правами с любым СВТ из системы. Один из очевидных способов решения — это добавить всех необходимых пользователей в базу данных всех необходимых модулей. Неприкрытая неуклюжесть данного метода видна невооруженным глазом.

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

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

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

Для обеспечения большой гибкости и удобства управления данный набор дополнительных параметров проверки также возможно смоделировать в рамках ролевого доступа, однако в этом случае возникает ряд сложностей связанных с управлением и составлением ролей. Для того чтобы избежать нежелательных усложнений и загромождения системы, предлагается воспользоваться парадигмой управления доступом на основе атрибутов [4]. В этой парадигме права на возможность осуществления той или иной операции даются пользователю на основе анализа ряда атрибутов. Более того, в общем случае атрибуты могут относиться не только к пользователю, но и к запрашиваемым ресурсам и вычислительной среде.

Однако остается два открытых вопроса.

1. Как грамотно реализовать аутентификацию атрибутов пользователя, не возвращаясь к «локально-списковой» парадигме?
2. Что делать с идентификаций каждого конкретного пользователя? Для проведения аудита необходимо точно знать, кто конкретно проводил те или иные действия, зафиксированные в журнале.

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

Возникает разумный вопрос: зачем центр управления должен предварительно сообщать информацию о пользователях каждому модулю (клиенту), если центр может хранить у себя всю необходимую базу данных, а модуль может по мере необходимости запрашивать информацию о том или другом пользователе, его атрибуты? Плюсы данного подхода очевидны: нет необходимости настраивать каждый модуль отдельно, не возникает неразумного дублирования баз[6]. Минусы не менее очевидны. Необходимо всегда быть онлайн при попытке аутентифицироваться и авторизовать пользователя, иными словами клиент должен быть подключен к сети, сервер должен работать и быть доступен (сеть должна функционировать). Если необходимо добавить пользователя из другого сегмента, то нужно осуществлять обмен данными между ЦУ (точнее серверами баз данных пользователей) из разных сегментов или иметь один ЦУ на оба сегмента. Кроме того, есть ряд менее очевидных нюансов связанных с особенностью разработки программного обеспечения для модуля доверенной загрузки.

Очевидно, что из трех выше описанных способов реализации агента в данном случае подходит только способ, при котором агент осуществляет запросы ЦУ во время сеанса работы АМДЗ (во время аутентификации и авторизации пользователя), а значит, реализован в составе программного обеспечения модуля доверенной загрузки. Не вдаваясь в детали особенности разработки модулей доверенной загрузки и не делая детального анализа, опираясь только на теорию, можно заключить, что модуль доверенной загрузки, будучи реализацией РКБ, должен быть максимально прост, а с точки зрения эффективности должен быть максимально универсальным (работать на максимально большом количестве средств вычислительной техники). Простота и универсальность влияют на сложность анализа модуля, а тщательный анализ модуля есть один из гарантов его безопасности. Ограничение по аппаратным ресурсам элементной базы модуля также никто не отменял.

В связи с выше описанным, хотелось бы избежать необходимости реализовывать клиентскую часть СУЦУ в ПО АМДЗ и как следствие – не добавлять поддержку возможности работы с сетью для разных платформ (СВТ).

Продолжая рассуждение, задаемся вопросом: если не запрашивать данные у ЦУ, то возможно ли авторизовать пользователя? С авторизацией проблем нет. Пользователь может сам предоставить все необходимые данные (набор атрибутов) для его авторизации, а вот аутентифицировать эти данные в этом случае является проблемой, ведь пользователь может предъявить все что угодно. Очевидно, что нам необходимо воспользоваться помощью того единственного и всезнающего, которому доверяем, – ЦУ, однако мы условились, что не хотим делать запрос во время сеанса работы АМДЗ.

Если мы не можем взаимодействовать «прямо» с ЦУ, то стоит рассмотреть варианты «косвенного» взаимодействия. Один из вариантов реализации можно получить, воспользовавшись методами электронной цифровой подписи (ЭЦП) и инфраструктурой открытых ключей (ИОК). Будем считать, что ЦУ будет выполнять функции удостоверяющего центра (УЦ[7]).

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

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

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

Приведем краткое описание общей схемы аутентификации и авторизации.

В ИС существует множество СВТ, в которые установлены АМДЗ. У каждого пользователя есть аппаратный токен, который поддерживает две роли: администратора информационной безопасности (АИБ) и пользователя. АИБ формирует в соответствии со служебным положением пользователя данные, необходимые для авторизации (различные атрибуты доступа) и регистрации (данные, идентифицирующие пользователя), подписывает их на закрытом ключе УЦ и затем сохраняет данные в аппаратно защищенную, доступную на чтение пользователю после ввода ПИН-кода память на токене. В защищенную память АМДЗ устанавливаются сертификаты открытых ключей УЦ. Пользователь, желающий начать работу с конкретным СВТ, включает его. Запускается сеанс работы АМДЗ. Пользователю предлагается предъявить токен и ввести ПИН-код, после чего проверяется подпись атрибутов доступа и учетной информации. В случае если данные аутентичны, то набор полученных атрибутов используется для авторизации пользователя и предоставления ему возможностей администратора, аудитора, непривилегированного пользователя и т. д.

Данный подход позволяет обеспечить большую гибкость в предоставлении доступа.

Рассмотрим следующий сценарий. Сотрудник некой компании приехал по делам в другое подразделение (своей компании), территориально расположенное на значительном расстоянии от подразделения, в котором он непосредственно работает. В рамках «локально-списковой» парадигмы, для того чтобы иметь возможность пользоваться корпоративными сервисами пользователь должен быть известен той системе, в которой собирается работать. Хорошо, если на все подразделения одна общая база данных или сотрудник заранее сделал запрос на добавление в базу данных. Модель «прямого запроса в базу ЦУ» в данном случае будет лучше и значительно эффективнее работать. Естественно, при одном из двух условий: все подразделения компании используют один сервер или данные между несколькими серверами синхронизируются. Предложенная модель с ЭП более удачна, чем «прямой запрос в базу ЦУ», так как объем данных обмена между подразделениями снижается до размера необходимого сертификата открытого ключа для проверки подписи. Более того, при грамотно построенной системе сертификатов, необходимость явной передачи сертификата между сегментами может отпасть сама собой.

Следует отметить то факт, что использование ИОК все же палка о двух концах: в рамках данной модели происходит перекладывание решения проблемы на другую инфраструктуру. Таким образом, в составе СУЦУ МДЗ появляется новая огромная сущность, функционирование которой нужно обеспечить и от которой напрямую зависит работоспособность СУЦУ. С другой стороны поддержка ИОК – менее затратная задача, чем поддержка синхронизации ЦУ. Также не следует забывать, что ИОК могла уже использоваться в организации для других задач.

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

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

Список литературы

1. 1. Конявский В. А. Управление защитой информации на базе СЗИ НСД «Аккорд». М.: «Радио и связь», 1999. – 325 c.
2. Конявский, В. А., Гадасин В. А. Основы понимания феномена электронного обмена информацией (Библиотека журнала «УЗИ»; Кн. 2). Мн.: «Беллитфонд», 2004. – 282 c.
3. 3. Конявский В. А. Методы и аппаратные средства защиты информационных технологий элктроенного документооборота. Диссертация на соискание ученой степени доктора технических наук. М., 2005.
4. NISTSpecialPublication 800-162. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NationalInstituteofStandardsandTechnology., 2014. – 45 с.
5. Способ защиты от несанкционированного доступа к информации, хранимой на персональной ЭВМ. Патент на изобретение № 2475823. 20.02.2013, бюл. № 5.

[1] Необходимо производить после обновления или модификации компонент вычислительной среды

[2] Типичная бытовая ситуация – это принятие нового сотрудника на работу

[3] Следует отметить, что ЦУ может быть как одним, так и группой серверов выполняющие разные задачи ЦУ, но данное замечание не принципиально для общей схемы

[4] Это не только анализ конкретных решений по их документации и реализации, но моделирование виртуального продукта, удовлетворяющего разливным требованиям регуляторов (мысленный эксперимент).

[5] Обычно применяется двухфакторная аутентификация на основе свертки, полученной из АИП и пароля пользователя.

[6] Обратите внимание, что в худшем случае при традиционном подходе для реализации парадигмы «каждый с каждым» в базе данных каждого модуля в системе должна быть база данных всех пользователей

[7] Очевидно, что в рамках ИОК можно спроектировать более сложные архитектуры, но для данной работы это не очень принципиально.

Автор: Алтухов А. А.

Дата публикации: 01.01.2015

Библиографическая ссылка: Алтухов А. А. Контроль доступа на основе атрибутов и оптимизация управления множеством АПМДЗ // Комплексная защита информации. Материалы XX научно-практической конференции. Минск, 19–21 мая 2015 г. Минск: РИВШ, 2015. С. 55–60.

---