Централизованная система разграничения доступа в облаке

МФТИ (ГУ), Москва, 117303, Россия

Введение

Сложно представить современную IT индустрию без облачных технологий. Они плотно укрепились практически во всех её сферах, и используются повсеместно: от приложений, предоставляющим пользователям возможность хранить и обрабатывать данные удаленно, до платформ, позволяющим полностью разместить инфраструктуру в облаке. К сожалению, такое удобство и гибкость неизбежно влекут за собой новые уязвимости [1], которые могут быть использованы злоумышленниками. Особое место среди них занимают уязвимости в системе разграничения доступа [2]. В данной статье рассмотрены недостатки современных подходов к разграничению доступа и предложено решение, которое позволит от этих недостатков избавится.

Облачная инфраструктура (ОИ) – это совокупность технологий, которые позволяют использовать удаленные вычислительные ресурсы, которые пользователю предоставляет провайдер облачных услуг. По запросу пользователя могут быть выделены дополнительные ресурсы, без непосредственного участия провайдера. Благодаря ОИ стало возможным до некоторой степени абстрагироваться от управления и администрирования вычислительных ресурсов. Уровень абстракции, на котором ресурсы предоставляются пользователю, определяется моделью облачного сервиса (или услуги). Всего их существует три: Приложение-как-сервис, Платформа-как-сервис и Инфраструктура-как-сервис [3].

Приложение как сервис (Software-as-a-Service, SaaS) – это модель облака, в которой пользователю предоставляется специальное приложение, которое на удаленном сервере хранит и/или обрабатывает его данные.

Платформа как сервис (Platform-as-a-Service, PaaS) – это модель облака, на которой провайдер предоставляет специальную платформу, в которой пользователь может запускать свои приложения.

Инфраструктура как сервис (Infrastructure-as-a-Service, IaaS) – это модель облака, в которой пользователю предоставляются различные инфраструктурные ресурсы, такие как сети, вычислительные ресурсы, хранилища данных и т.д. Пользователь в такой модели получает возможность хранить и обрабатывать данные, строить свою собственную инфраструктуру, используя различные сервисы провайдера. Провайдер со своей стороны предоставляет пользователю средства для автоматизации, мониторинга и журналирования событий. Такой функционал позволяет пользователю экономить на покупке ресурсов, их установке и администрировании.

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

В свою очередь модели типа PaaS и IaaS представляют особый интерес с точки зрения разграничения доступа, так как они должны одновременно обеспечивать:

1. Обработку большого количества пользователей.
2. Запуск приложений пользователей на одних и тех же физических ресурсах или разделение этих ресурсов между пользователями.
3. Выделение ресурсов по запросу пользователя, без участия администратора инфраструктуры.
4. Изоляцию приложений/ресурсов пользователей друг от друга.

Все это делает задачу разграничения доступа в данных моделях ОИ уникальной.

Разделение ресурсов в облаке

Прежде чем перейти непосредственно к разграничению доступа, рассмотрим сходства и различия в разделении ресурсов между пользователями в моделях IaaS и PaaS. Существует специфичная вариация модели IaaS, которая называется «голое железо»-как-сервис (Bare-metal-as-a-Service) [4]. В ней пользователю предоставляется удаленный доступ напрямую к физическим ресурсам. За исключением этой вариации, разделение ресурсов провайдера между пользователями в рассматриваемых моделях ОИ реализуется при помощи технологии виртуализации.

• В IaaS пользователь может запрашивать создание новых виртуализированных ресурсов, например, виртуальных машин (ВМ), виртуальных сетей и т.д., сконфигурированных так, как ему это необходимо. Доступ пользователя к полученным ресурсам никак не ограничивается, позволяя ему в дальнейшем настраивать их как угодно.
• В PaaS пользователю предоставляется возможность запускать приложения, упакованные в определенном формате, а также конфигурировать для них окружение. Очень часто [5] изоляция между приложениями реализуется с помощью виртуализации на уровне операционной системы (контейнеризации), однако полного доступа к контейнерам в таком случае пользователям не предоставляется.

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

Разграничение доступа в облаке

Пользователь взаимодействует с ОИ через специальную панель управления (ПУ) [6]. Когда пользователь посылает обращается к ПУ, его запрос перехватывает механизм разграничения доступа, для того чтобы авторизовать. Обычно, для выполнения данного процесса используется механизм, архитектура которого описана в стандарте XACML [7] (таблица 1, рис. 1).

Рисунок 1. Архитектура механизма разграничения доступа по стандарту XACML.

Таблица 1. Пояснения к рис. 1.

PAP	Policy Administration Point (Точка управления политиками)	Модуль, с помощью которого администратор безопасности может управлять политиками доступа.
PDP	Policy Decision Point (Точка принятия решения)	Модуль, который принимает решение о предоставлении доступа с помощью сравнения данных из запроса на доступ с заданными политиками доступа.
PEP	Policy Enforcement Point (Точка применения политик)	Модуль, который перехватывает пользовательский запрос, формирует из него запрос на доступ и перенаправляет полученный запрос в PDP. На основе полученного в ответ решения PDP, изначальный запрос пользователя пропускается далее в систему или отвергается, а в ответ возвращается ошибка.
PIP	Policy Information Point (Точка предоставления информации для применения политик)	Модуль, который хранит значения атрибутов различный сущностей системы (ресурсов, субъектов, переменных окружения и т.д)

Для применения политик доступа используется ролевая модель [8]. В этой модели каждому субъекту доступа (например, пользователю) назначается одна или несколько ролей. Каждая роль состоит из привилегий (или прав доступа), представляющих из себя набор правил: какие действия над каким объектом можно совершать.

Рисунок 2. Ролевая модель разграничения доступа

Для облака эта модель несколько изменяется, так как пользователь – это зачастую уже не отдельный человек, а группа людей, работающих в рамках одной квоты. Такую группу принято называть арендатором или проектом. В рамках одного проекта может существовать своя иерархия ролей [8]. К тому же для администрирования самой ОИ необходим набор различных ролей. Поэтому для удобства администрирования политик используются различные дополнения к ней, например, «пространства». «Пространства» представляют из себя некую абстракцию, внутри которой задана своя изолированная иерархия ролей (например, в пространстве проекта есть роли admin, edit, view, которые отвечают за доступ к сущностям проекта, и в пространстве кластера есть такие же роли admin, edit, view, но уже отвечающие за доступ к сущностям кластера, т.е. сервисам). По сути данный подход просто предоставляет удобные правила именования ролей.

Описанное выше разграничение доступа применимо для взаимодействия пользователя с ОИ через ПУ, однако элементы самой инфраструктуры взаимодействуют между собой по сети, а настройка сетевого взаимодействия в динамически изменяемой системе – достаточно сложная задача. Предположим, пользователь хочет создать ВМ или экземпляр приложения в облаке. В результате этой операции будет получена совершенно новая сущность, и если правила доступа к ней через ПУ описать не сложно (например, ВМ может унаследовать правила от проекта), то с сетевым доступом все сложнее. Очевидно, что арендатор хочет, чтобы сетевой доступ к его ВМ/приложениями был закрыт для любого другого проекта, но как это сделать? Создавать и настраивать для каждого проекта свой сетевой экран – это долго и дорого, а настраивать правила фильтрации на хостах вручную – сложно и неудобно. Для решения этой проблемы в большинстве облачных сред используются специальные сервисы, которые автоматически настраивают правила фильтрации на хостах [9]. Однако такой подход плохо работает с моделью IaaS, так как пользователю предоставлен полный доступ к виртуальным ресурсам, а значит у него есть возможность изменять правила фильтрации внутри этих ресурсов. Для того чтобы полностью изолировать сети пользователей в IaaS используются программно определяемые сети (Software-defined network, SDN) [10]. Проблема в том, что и сущности для автоматической настройки правил фильтрации, и SDN никак не связаны с механизмом разграничения доступа описанным выше, а значит политики доступа для них нужно описывать отдельно, что приводит усложнению процесса администрирования политик.

Помимо этого, вопрос определения хоста, на котором будет запущен ресурс, решается отдельным механизмом – планировщиком. Создание защищенного планировщика (или обеспечение контролируемой миграции [11]) также является актуальной задачей, так как современные решения направлены на обеспечение максимальной эффективности потребления физических ресурсов, а изоляция предполагается только средствами виртуализации. Конечно, с помощью этих решений можно обеспечить некоторый уровень защищенности. Например, некоторые из них работают по принципу, схожему с принципом мандатной модели разграничения доступа: то, на каком хосте будет запущен ресурс, помимо загруженности этого хоста, определяется метками, которые назначаются администратором ресурсам арендатора [12,13]. Эти метки можно настроить так, чтобы обеспечить разграничение доступа объектов арендатора к физическим ресурсам. Проблема здесь та же, что и с сетевыми политиками: этот механизм работает независимо от системы разграничения доступа ОИ, поэтому обеспечение физической изоляции объектов возможно обеспечить, только вручную настроив инфраструктуру.

Централизованная система разграничения доступа

Итого, можно выделить три типа разграничения доступа (РД) в облаке:

1. Авторизация запросов пользователя.
2. РД между ресурсами пользователей на сетевом уровне.
3. РД между ресурсами пользователей на уровне планирования.

Для всех них, как было сказано ранее применяются разные механизмы:

1. Для авторизации запросов пользователя к ПУ применяется ролевая модель и механизм РД описанный в стандарте XACML.
2. Для сетевого уровня это настройка межсетевых фильтров и/или правил SDN.
3. Для планировщика по умолчанию разграничения доступа нет, но есть инструменты, позволяющие настроить его вручную.

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

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

1. Описать формальную модель доступа.
2. Описать метод реализации ЦСРД.
3. Реализовать ЦСРД в облаке в виде IaaS (на примере OpenStack) и PaaS (на примере OpenShift).

Заключение

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

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

1. Subashini S., Kavitha V. A Survey on Security Issues in Service Delivery Models of Cloud Computing // Journal of Network and Computer Applications. – 2011. vol. 34. no.1. – pp. 1-11.
2. Sumitra B. Pethuru C.R., Misbahuddin M. A Survey of Cloud Authentication Attacks and Solution Approaches // International Journal of Innovative Research in Computer and Communication Engineering. – 2014. vol. 2. Issue 10. – pp. 6245-6253.
3. Jansen W., Grance T. NIST Special Publication 800-144: Guidelines on Security and Privacy in Public Cloud Computing. – 2011 . – pp. 4-6.
4. Bare-metal cloud [Электронный ресурс]. – Режим доступа: https://searchstorage.techtarget.com/definition/bare-metal-cloud
5. Dua R., Raja R., Kakadia D. Virtualization vs Containerization to support PaaS // IEEE International Conference on Cloud Engineering. – 2014.
6. Hu F., Qiu M., Li J., Grant T. A Review on Cloud Computing: Design Challenges in Architecture and Security // Journal of Computing and Information Technology. – 2011. – pp. 25–55.
7. Moses T. eXtensible Access Control Markup Language 3 (XACML) Version 2.0. – Committee draft 02. – 30 Sep 2004.
8. Девянин П.М. Модели безопасности компьютерных систем: учебное пособие для студентов высших учебных заведений. – М: Издательский дом “Академия”. – 2005. – 144 c.
9. Foley S., Neville U. A firewall algebra for OpenStack // Conference on Communications and Network Security (CNS). – 2015.
10. Banikazemi M., Olshefski D., Shaikh A., Tracey J. Meridian: An SDN Platform for Cloud Network Services // IEEE Communications Magazine. – February 2013.
11. Конявский В. А. Безопасное облако [Электронный ресурс]. – Режим доступа: http://www.okbsapr.ru/docs/2013/konyavskiy_2013_9.pdf
12. OpenStack documentation: Availability zones [Электронный ресурс]. – Режим доступа: https://docs.openstack.org/newton/networking-guide/config-az.html
13. OpenShift documentation: Advanced Scheduling and Node Selectors [Электронный ресурс]. – Режим доступа: https://docs.openshift.com/container-platform/3.11/admin_guide/scheduling/node_selector.html

Автор: Журов П. М.

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

Библиографическая ссылка: Журов П. М. Централизованная система разграничения доступа в облаке // Комплексная защита информации: материалы ХХIV научно-практической конференции. Витебск. 21– 23 мая 2019 г.: УО ВГТУ. Витебск, 2019. С. 227–232.

---