CC BY-NC-ND
75
В.Р. Григорьев, В.С. Кузнецов
АДАПТАЦИЯ РОЛЕВОЙ МОДЕЛИ РАЗГРАНИЧЕНИЯ ДОСТУПА В СИСТЕМАХ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ
Предложен подход к адаптации ролевой модели разграничения доступа применительно к системам облачных вычислений. Рассмотрены 3 модели развертывания облачной инфраструктуры: частное облако, публичное облако и гибридное облако. Расширение возможности распространения базовой модели разграничения доступа на облачные вычисления строится на основе предложенной модели угроз облачной системы.
Ключевые слова: ролевая модель разграничения доступа, частное облако, публичное облако, гибридное облако, облачные вычисления, модель угроз.
Введение
Актуальность облачных вычислений связана со снижением затрат, масштабируемостью и гибкостью архитектуры информационных технологий.
Облачные вычисления - это смена парадигмы, которая обеспечивает поддержку вычислений с использованием Интернета. Сервис облачных вычислений состоит из высокооптимизированных и виртуализированных центров обработки данных, обеспечивающих предоставление различных программных, аппаратных и информационных ресурсов, когда их использование оказывается необходимым. Широкое практическое внедрение облачных вычислений в настоящее время во многом связано с отсутствием механизмов гарантированной защиты информации, обрабатываемой в облаках.
На нынешнем этапе развития облачных вычислений выявлен ряд уязвимостей, связанных не только и не столько с классически-
© Григорьев В.Р., Кузнецов В.С., 2013
ми угрозами для распределенных информационных систем, но и с принципиально новыми угрозами, порожденными спецификой виртуализации1. Организация вычислительных процессов в информационной системе на основе механизмов виртуализации предоставляет нарушителю больше возможностей, чем в классической распределенной архитектуре информационной системы предыдущего поколения. Отсюда возникает необходимость разработки новых подходов к анализу уязвимостей виртуальных сред, которые, в свою очередь, во многом опираются на выбранную для защиты политику безопасности. Возникает вопрос о выборе такой политики безопасности, которая бы наиболее адекватно соответствовала характеру обработки информации в виртуализированных ресурсах облачных вычислений.
Ролевая модель безопасности: особенности и преимущества
Следует отметить, что существующие теоретические модели политик безопасности слабо приспособлены к формализации проблем защиты, которые возникают в облачных вычислениях.
В настоящее время появляются некоторые формализованные подходы построения политик безопасности применительно к области облачных вычислений на основе имеющихся наработок для традиционных моделей разграничения доступа2-3. Так, например, в статье4 предложен вариант адаптации для облачных систем наиболее распространенной теоретической модели мандатного доступа Белла-ЛаПадула (МБЛ). Однако известно, что при использовании МБЛ в контексте практического проектирования и разработки реальных компьютерных систем возникает ряд технических вопросов при построении политик безопасности для конкретных типов систем, т. е. на менее абстрактном уровне рассмотрения.
Так, например, функционирование системного администратора подразумевает выполнение в системе таких критических операций, как добавление и удаление пользователей, восстановление системы после аварий, установка программного обеспечения, устранение ошибок и т. п. Очевидно, что такие операции не вписываются в МБЛ, что означает невозможность осуществления правильного администрирования без нарушения правил данной модели.
Одним из потенциальных кандидатов для создания политики безопасности для разграничения доступа к ресурсам облачных вычислений является модель контроля доступа, базирующаяся на ролях5.
Ролевая модель безопасности (также называемая ролевым контролем доступа) построена на условии аутентификации пользователей, то есть на процессе идентификации пользователей. Когда пользователь идентифицирован, ему назначаются роли и разрешения.
Модель контроля доступа, базирующаяся на ролях, наиболее естественным образом соответствует политикам безопасности, принятым в различных организациях, позволяет организовать такие особенности политик безопасности, как иерархия ролей (статических, динамических) и операционное разделение обязанностей6.
Известно, что при применении дискреционного или мандатного контроля доступа информация принадлежит создавшему ее пользователю (принципиальным является то, кто имеет доступ по чтению и по записи к информации). Напротив, контроль доступа, базирующийся на ролях (role based access control, КДБР), рассматривает всю информацию, обрабатывающуюся в вычислительной системе организации, как принадлежащую данной организации.
В системе КДБР пользователи не могут передавать права на доступ к информации другим пользователям, что является фундаментальным отличием КДБР от дискреционного и мандатного доступа. Таким образом, КДБР основывается на принятии решения о доступе на основе информации о функции, которую пользователь выполняет внутри данной организации на основании своей роли.
Определение членства и распределение полномочий роли в КДБР (в отличие от дискреционного доступа) зависит не от системного администратора, а от политики безопасности, принятой в системе. Роль можно понимать как множество действий, которые пользователь или группа пользователей может использовать в контексте организации. Понятие роли включает описание обязанностей, ответственности и квалификации. Функции распределяются по ролям администратором системы. Доступ к роли также определяется администратором системы.
Ролевую политику безопасности нельзя отнести ни к дискреционным, ни к мандатным, потому что управление доступом в ней осуществляется как на основе матрицы прав доступа для ролей, так и с помощью правил, регламентирующих назначение ролей пользователям и их активацию во время сеансов.
Поэтому ролевая модель представляет собой совершенно особый тип политики, основанной на компромиссе между гибкостью управления доступом, характерной для дискреционных моделей, и жесткостью правил контроля доступа, присущей мандатным моделям.
В ролевой модели классическое понятие «субъект» замещается понятиями «пользователь» и «роль». Пользователь - это человек, работающий с системой и выполняющий определенные служебные обязанности. Роль - это активно действующая в системе абстрактная сущность, с которой связан ограниченный, логически связанный набор полномочий, необходимых для осуществления определенной деятельности. Самым распространенным примером роли является присутствующий почти в каждой системе административный бюджет, который обладает специальными полномочиями и может использоваться несколькими пользователями.
Ролевая политика распространена очень широко, потому что она, в отличие от других более строгих и формальных политик, очень близка к реальной жизни. Ведь на самом деле работающие в системе пользователи действуют не от своего личного имени -они всегда осуществляют определенные служебные обязанности, т. е. выполняют некоторые роли, которые никак не связаны с их личностью.
Ролевая политика позволяет распределить полномочия между этими ролями в соответствии с их служебными обязанностями: роль администратора наполняется специальными полномочиями, которые позволяют ему контролировать работу системы и управлять ее конфигурацией, роль менеджера баз данных позволяет осуществлять управление сервером баз данных, а права простых пользователей ограничиваются минимумом, необходимым для запуска прикладных программ.
Кроме того, количество ролей в системе может не соответствовать количеству реальных пользователей - один пользователь, если на нем лежат различные обязанности, требующие различных полномочий, может выполнять (одновременно или последовательно) несколько ролей, а несколько пользователей могут пользоваться одной и той же ролью, если они выполняют одинаковую работу.
При использовании ролевой политики управление доступом осуществляется в две стадии: во-первых, для каждой роли указывается набор полномочий, представляющий набор прав доступа к объектам, и, во-вторых, каждому пользователю назначается список доступных ему ролей.
Полномочия назначаются ролям в соответствии с принципом наименьших привилегий, из которого следует, что каждый пользователь должен обладать только минимально необходимым для выполнения своей работы набором полномочий.
В отличие от других политик ролевая политика управления доступом практически не гарантирует безопасность с помощью
формального доказательства, а только определяет характер ограничений, соблюдение которых и служит критерием безопасности системы. Такой подход позволяет получать простые и понятные правила контроля доступа, которые легко могут быть применены на практике, но лишает систему теоретической доказательной базы. Далее предлагается рассмотреть принципы составления простых правил ролевого управления доступом, которые могут быть использованы в качестве основы формирования политики безопасности для некоторых типов облачных вычислений.
Модель ролевого разграничения доступа для облачных вычислений
В качестве отправной точки для исследования вопроса возможности расширения применимости модели ролевого разграничения доступа к облачным вычислениям выберем 3 модели развертывания «облаков»7:
• Частные облака. Предназначены для исключительного использования одной организацией и обычно контролируются, управляются и хостируются частными центрами данных. Хостинг и управление частными облаками могут быть переданы на аутсорсинг внешнему сервис-провайдеру, но частное облако остается в исключительном пользовании одной организации.
• Публичные облака. Используются многими организациями (пользователями) совместно, обслуживаются и управляются внешними сервис-провайдерами.
• Гибридные облака. Появляются, когда организация использует и частное, и публичное облака для одного и того же приложения, чтобы воспользоваться преимуществами обоих. Например, при «ливневом» сценарии организация в случае стандартной нагрузки на приложение пользуется частным облаком, а когда нагрузка пиковая, например, в конце квартала или в праздничный сезон, задействует потенциал публичного облака, впоследствии возвращая эти ресурсы в общий пул, когда они больше не нужны.
1. Модель ролевого разграничения доступа
Классическая ролевая модель8 разграничения доступа имеет следующие основные элементы:
U - множество пользователей;
R -множество ролей;
P -множество полномочий на доступ к объектам, представленное, например, в виде матрицы прав доступа;
S - множество сеансов работы пользователей с системой.
В качестве критерия безопасности ролевой модели используется следующее правило: система считается безопасной, если любой пользователь системы, работающий в сеансе S, может осуществлять действия, требующие полномочия p только в том случае, если они ему разрешены.
PA: R - > 2P - функция, задающая для каждой роли множество прав доступа, при этом для каждого права доступа peP существует роль reR такая, что pePA(r);
UA: S - >2R - функция, задающая для каждого пользователя множество ролей, на которые он может быть авторизован;
user: S - >U - функция, задающая для каждой сессии пользователя, от имени которого она активизирована;
roles: S - >2R - функция, задающая для пользователя множество ролей, на которые он авторизован в данной сессии, при этом в каждый момент времени для каждой сессии se S выполняется условие roles(s) < UA(user(s)).
Возможно существование ролей, на которые не авторизован ни один пользователь.
В базовой модели ролевого управления доступом предполагается, что множества U, R, P и функции PA, UA не изменяются с течением времени.
Множество ролей, на которые авторизуется пользователь в течение одной сессии, модифицируется самим пользователем. При этом отсутствуют механизмы, позволяющие одной сессии активизировать другую сессию. Все сессии активизируются только пользователем.
Следующим шагом построим модель угроз, которая позволит нам расширить, с учетом специфики систем облачных вычислений, классический набор элементов модели ролевого разграничения доступа.
2. Модель угроз
При построении модели угроз системы облачных вычислений становится ясно, что точки приложения угроз выходят за рамки классической тройки: конфиденциальность, целостность и доступность. Формализуем модель угроз для облачной системы.
1. Конфиденциальность. Классический элемент модели угроз, угроза конфиденциальности данных, может принять множество форм, например, внутренние нарушители: данная угроза очевидна для большинства организаций. В качестве иллюстрации: провайдер может не скрывать способы предоставления доступа к физическим и виртуальным объектам, способы реализации контроля сотрудников или специфику анализа сообщений безопасности. Наиболее актуальной угрозой в условиях распределенной облачной системы являются неизвестные риски, проще говоря, пользователь не имеет представления о том, каким образом обрабатываются его данные в облаке.
2. Целостность. Очевидным примером может послужить уничтожение данных при отсутствии актуального бэкапа. Потеря нескольких записей из большого массива данных может привести к его полной нечитаемости. Потеря ключа шифрования равносильна утрате данных, зашифрованных на нем. Проще говоря, неавторизованные элементы системы не должны иметь никакого доступа к критичным участкам данных.
3. Доступность. Угроза доступности может быть реализована посредством атаки, эксплуатирующей небезопасные интерфейсы и API. Провайдеры облачных вычислений предоставляют набор программных интерфейсов для взаимодействия с их продуктом. Посредством таких интерфейсов реализуется настройка, управление, мониторинг, синхронизация. В итоге доступность облачных сервисов упирается в безопасность базовых API.
4. Функциональная устойчивость. В ситуации с облачными вычислениями данный термин приобретает несколько иной смысл. Например, возможны такие атаки, как кража аккаунта или сервиса9. Идея не нова. Атаки наподобие фишинга, фрода или эксплойтов используемого ПО не теряют актуальности. В условиях облачной системы злоумышленник разом получает доступ ко всем данным/ ресурсам, находящимся в облаке.
5. Управление. Атаки, эксплуатирующие недочеты в данной части системы, могут принять такую форму, как некорректное или незаконное использование облачных систем. IaaS-провайдеры предлагают потребителям иллюзию неограниченных ресурсов, часто сопровождаемую «упрощенной» процедурой регистрации, когда любой человек с валидной кредитной карточкой имеет возможность зарегистрироваться в системе и мгновенно получить доступ к предлагаемым услугам. Некоторые провайдеры предоставляют бесплатный тривиальный период использования своих услуг. Вышесказанное в сочетании с анонимным доступом к сер-
висам «развязывает руки» спамерам, разработчикам вредоносного кода и остальным криминальным элементам. PaaS-провайдеры также страдают от большинства перечисленных проблем. Таким образом, под некорректным или незаконным использованием облачных сервисов подразумевается использование их с целью DDOS, взлома паролей, реализации распределенных атак, создания ботнетов, взлома CAPTCHA. Также в данном пункте следует учитывать управление гипервизорами, жизненным циклом виртуальных объектов, а также проблемы общедоступной среды, потому как IaaS-вендоры предоставляют свои сервисы как динамически изменяемую инфраструктуру. Очень часто базовые компоненты, составляющие эту инфраструктуру (CPU кэш, GPU и т. п.), не приспособлены для реализации требований строгой изоляции, которые актуальны в многозадачной среде.
Построенная модель угроз позволяет выделить участки системы облачных вычислений, не охваченные классическими положениями модели ролевого разграничения доступа. Наличие подобных участков объясняется спецификой облачных вычислений как распределенной системы.
3. Расширение модели ролевого разграничения доступа
Построим расширение базовой ролевой модели для использования ее в условиях облака с учетом построенной выше модели угроз.
Во-первых, введем параметр атрибут, целесообразность которого может быть понятна из следующего примера: пользователю делегирована роль «загрузить данные» в облако. Данное действие возможно и логично для всех пользователей, но размеры вносимой информации могут быть различны. Можно ввести несколько ролей: «загрузить 1 Гб», «загрузить 2 Гб» и т. д. При подобном подходе задача администрирования системы будет значительно усложняться с течением времени. Таким образом, атрибут есть свойство пользователя либо роли. При передаче прав делегирования роли субъекту требуется указать, какие из атрибутов этой роли субъект имеет право изменять и как. Атрибут есть некое уникальное свойство роли или пользователя, являющееся численным значением. Из соображений безопасности при делегировании он либо остается неизменным, либо уменьшается. Данный параметр актуален в условиях всех моделей развертывания из п. 1. Таким образом, наш пример может выглядеть так:
С - облако, Sec - контроллер безопасности системы, C.userl -обычный пользователь, C.user2 - привилегированный пользователь, C.upload - роль на право загрузки, C.size - атрибут облака, накладывающий ограничение на объем загрузки;
• присвоим право пользователю загружать ограниченный объем информации: (C.userl ^ C.upload with C.size=1)Sec (операцию делегирования контролирует наш контроллер безопасности системы);
• присвоим право привилегированному пользователю загружать неограниченный объем информации: (C.userl ^ C.upload with C.size=0)Sec (0 - значит, что ограничений нет).
Во-вторых, введем понятие «период делегирования», т. е. на какой срок делегируются те или иные полномочия. В качестве иллюстрации необходимости подобного понятия выступает идея облака, которая подразумевает частую смену и большое число пользователей. Также периодическое обновление полномочий имеет смысл для усиления безопасности. Данный параметр актуален в условиях всех моделей развертывания. Таким образом, наш пример может выглядеть так:
С - облако, Sec - контроллер безопасности системы, C.userl -обычный пользователь, C.user2 - привилегированный пользователь, C.upload - роль на право загрузки, C.size - атрибут облака, накладывающий ограничение на объем загрузки;
• присвоим право пользователю загружать ограниченный объем информации: (C.userl ^ C.upload<дата истечения полномочий> with C.size=1)Sec;
• присвоим право привилегированному пользователю загружать неограниченный объем информации: (C.userl ^ C.up-load<дата истечения полномочий> with C.size=0)Sec.
В-третьих, поскольку наше облако может быть в ведении организации, чьи филиалы распределены по большой территории, а доступ к ресурсам одного филиала необходимо предоставить другому, то при работе с элементами облака системе необходимо знать, какому филиалу они принадлежат. Для этого каждый элемент облака должен нести информацию о том, какому филиалу он принадлежит и как это проверить. Набор следующих параметров элемента облака, используемых при работе с ним, назовем облачными параметрами:
• сервер филиала, регулирующий доступ;
• дополнительные правила, налагаемые данным узлом облака.
Данный параметр актуален в условиях гибридного облака, в
котором происходит смешивание узлов с различной степенью доверия. Таким образом, наш пример может выглядеть так:
С - облако, Sec - контроллер безопасности системы, C.userl -обычный пользователь, C.user2 - привилегированный пользователь, C.upload - роль на право загрузки, C.size - атрибут облака, накладывающий ограничение на объем загрузки, C.cp - облачные параметры;
• даем право пользователю загружать ограниченный объем информации: ((C.userl ^ C.upload<дата истечения полномочий> with C.size=1)<C.cp>)Sec;
• даем право привилегированному пользователю загружать неограниченный объем информации: ((C.userl ^ C.upload<дата истечения полномочий> with C.size=0)<C.cp>)Sec.
4. Заключение
В данной статье для построения формализованных процедур разграничения доступа в облачных вычислениях предложено использовать модель ролевого разграничения доступа. С учетом введенных параметров наиболее интересным объектом для реализации адаптированной модели ролевого разграничения доступа представляется гибридное облако, которое образуют узлы, обрабатывающие информацию с различными грифами конфиденциальности. Также показано, что технология управления доступом на основе ролей обладает значительным потенциалом в плане адаптации и гибкости перестройки, чтобы смоделировать любую другую модель управления доступом. Предложенная модель, безусловно, не претендует на решение всех проблем в виртуализированной среде облачных вычислений, однако обладает достаточно универсальными механизмами разграничения доступа, которые требуют дальнейших теоретических и прикладных исследований.
1
Примечания
См.: Fang Liu, Jin Tong, Jian Mao, Bohn R.B., Messina J.V., Badger M.L., Leaf D.M. NIST Cloud Computing Reference Architecture [Электронный ресурс] // National Institute of Standards and Technology. URL: http://www.nist.gov/cus-tomcf/get_pdf.cfm?pub_id=909505; Hogan M.D., Fang Liu, Sokol A.W., Tong Jin. NIST Cloud Computing Standards Roadmap [Электронный ресурс] // National Institute of Standards and Technology URL: http://www.nist.gov/customcf/ get_pdf.cfm?pub_id=909024.
См.: Сергеев Ю.К. Использование технологий виртуализации для защиты информации // Вестник РГГУ. Сер. «Информатика. Защита информации. Математика». 2009. № 10.
3 См.: Качко А.К. Формализованная модель безопасности процесса обработки данных в условиях среды облачных вычислений // Проблемы информационной безопасности. Компьютерные системы. 2012. № 2. С. 14-20.
4 Там же.
5 Девянин П.Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: Учеб. пособие для вузов. М.: Горячая линия-Телеком, 2011. С. 227-282.
6 См.: Баранов А.П., Зегжда Д.П., Зегжда П.Д., Ивашко А.М., Корт С.С. Теоретические основы информационной безопасности (дополнительные главы): Учеб. пособие. СПб.: Санкт-Петербургский ГТУ, 1998.
7 См.: Fang Liu, Jin Tong, Jian Mao, Bohn R.B., Messina J.V., Badger ML, Leaf D.M. Op. cit.
8 См.: Качко А.К. Указ. соч.
9 См.: Баранов А.П., Зегжда Д.П., Зегжда П.Д., Ивашко А.М., Корт С.С. Указ. соч.
