Особенности контроля взаимодействия клиента VMware vSphere 6.5 с vCenter

Исследование основных проблем в вопросе безопасности виртуальных инфраструктур. Процесс контроля взаимодействия клиента VMware vSphere 6.5 с vCenter. Рассмотрение существующей модели разграничения доступа пользователей. Анализ трафика сетевых клиентов.

Рубрика Программирование, компьютеры и кибернетика
Вид статья
Язык русский
Дата добавления 03.05.2019
Размер файла 94,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

ГУ МФТИ

Особенности контроля взаимодействия клиента VMware vSphere 6.5 с vCenter

Журов П.М.

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

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

Лидером в области виртуализации на данный момент является VMware с продуктом vSphere. Но, даже несмотря на все достоинства данного ПО, в нём есть существенный недостаток с точки зрения безопасности, а именно: администратор отвечает как за управление инфраструктурой, так и за назначение прав доступа пользователям к её элементам. Это влечет за собой высокую трудоёмкость решения следующей проблемы: если в системе есть несколько сегментов, то критически возрастает вероятность преднамеренной или случайной утечки данных из одного сегмента в другой [2, 3, 4]. Для её решения необходимо средство, позволяющее разграничить доступ к элементам инфраструктуры для всех пользователей, включая администратора.

На сегодняшний день на рынке существует всего три продукта с подобным функционалом. Но один из них [5] не имеет сертификата ФСТЭК (а значит, не может применяться в государственных информационных системах), а второй [6] - не работает напрямую с vSphere (использует сторонний клиент), что вынуждает администратора изменить привычный порядок работы.

Третий комплекс [7] соответствует всей нормативной базе и не меняет порядка работы управляющего персонала, но в связи с заявлением VMware о том, что в следующей версии продукта [8] будет использоваться новый клиент управления на основе HTML5, что влечет за собой изменение принципа взаимодействия веб-клиента с сервером, можно сделать вывод, что существующие решения более не применимы, а значит, проблема остается актуальной. Данную проблему так же усугубляет то, что у новой версии нет открытого API, а следовательно, у разработчиков нет возможности быстро переделать существующие решения под новый клиент.

В то же время именно последний случай - ПАК «Сегмент-В.» - представляется наиболее целесообразным для доработки, поскольку в его случае не требуется коренной пересмотр решения. В статье описаны основные аспекты этой доработки, в рамках которой был проведен анализ трафика передаваемого от HTML5 клиента vSphere на vCenter, частично выделен протокол управления, а затем рассмотрены особенности, которые можно использовать для контроля доступа.

Рассмотрение существующей модели разграничения доступа

Прежде всего, стоит описать модель разграничения доступа для виртуальной инфраструктуры vSphere [9], которая используется в ПАК «Сегмент-В.». Для этого выделим несколько ключевых особенностей данной инфраструктуры, которые эта модель использует.

Самым главным элементом vSphere является центральный сервер виртуальной инфраструктуры - VCSA (vCenter Server Appliance). К нему подключаются различные гипервизоры, на нем создаются хранилища и сети и с помощью него же происходит взаимодействие со всеми этими элементами. Для управления этим сервером используется веб-интерфейс.

Данная модель разграничения доступа использует принцип, схожий с принципом атаки man-in-the-middle: веб-клиент рассматривается в качестве внешнего элемента ВИ, сам vCenter - внутреннего, а посередине устанавливается прокси-сервер, который анализирует трафик и пропускает команды управления, основываясь на заранее записанных в него политиках доступа. Это позволяет реализовать принцип «разделяй и властвуй»: настройками политик доступа занимается администратор безопасности инфраструктуры (АБИ), у которого при этом нет прав системного администратора, и наоборот - системный администратор не имеет возможности настраивать политики доступа.

Реализация на данном прокси-сервере, например, мандатной системы разграничения доступа, решит как проблему сегментированности, так и проблему суперпользователя.

Механизм

Какими же качествами должен обладать механизм, который реализует эту модель.

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

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

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

Создание механизма

Для создания данного механизма необходимо сначала провести анализ трафика между веб-клиентом vSphere и VCSA. Для этого, в первую очередь был создан стенд, содержащий в себе все ключевые элементы виртуальной инфраструктуры: несколько гипервизоров, часть которых объединена в различные кластеры, несколько хранилищ, сетей и пользователей. Все это необходимо, чтобы как можно подробнее изучить протокол управления.

Для анализа данных, передаваемых с клиента на сервер, использовался язык python и библиотека mitmproxy, которая позволяет реализовать прокси-сервер для прослушивания трафика. В vSphere используется протокол HTTPS, который исключает возможность прослушивания трафика, но в силу того, что имеется доступ к серверу VCSA, из которого можно взять сертификат и ключ TLS, данное ограничение не помешало реализации.

Новый HTML5 клиент использует для управления протокол JSON RPC, в котором клиент передает команды в формате JSON и в таком же виде получает их от сервера. Эта информация использовалась в дальнейшем для обработки запросов.

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

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

Операции, направленные на получение информации об инфраструктуре, всегда выполняются с помощью GET запроса, и однозначно идентифицируются по своему URL.

Рис. 1 Архитектура прокси-сервера

Информация о пользователе, совершившем действие, всегда хранится в заголовке запроса в открытом виде (обратите внимание, даже не в виде идентификатора сессии).

Информацию об объекте, с которым работает пользователь, можно получить двумя путями:

В большинстве случаев id объекта содержится в URL запроса.

Иногда, например, когда объектов несколько, информация о них содержится в теле запроса.

Эти особенности позволяют однозначно идентифицировать из любого запроса объект, субъект и операцию.

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

Принцип работы прокси-сервера, следующий: Inspector перехватывает запрос и передает его в Handler (обработчик). Тот, пользуясь особенностями протокола управления, описанными выше, получает из запроса данные, необходимые для инициализации объектов, пользователя и операции, затем инициализирует их с помощью модуля Adapter, передает возвращенные адаптером объекты в модуль Logic, который принимает решение о допустимости данной операции. Именно это решение возвращается из Handler'а в Inspector. Под инициализацией здесь подразумевается создание объектов (программных), которые содержат в себе пользователя/элемент ВИ/операцию и все соответствующие ему/ей атрибуты безопасности. Рассмотрим каждый модуль немного подробнее:

Модуль Inspector отвечает за перехват трафика. В нем подключается библиотека mitmproxy, с её помощью перехватывается запрос, который передается в модуль Handler, а тот возвращает в ответ да/нет (пропустить запрос или нет). Если запрос заблокирован (Handler вернул нет), Inspector заменяет ответ сервера на ответ с ошибкой.

Модуль Handler является связующим звеном между остальными модулями. Он отвечает за получение необходимой информации из запроса, которая включает в себя пользователя, операцию, вид операции и объекты, участвующие в операции (их может и не быть).

Модуль Adapter используя локальную базу данных, в которую записаны политики доступа и данные, полученные из Handler'а. Затем он инициализирует объекты и пользователя с соответствующими им атрибутами безопасности (уровни и метки доступа, а также список допустимых операций для пользователя) и операцию. В конце адаптер возвращает инициализированные объекты в Handler.

Модуль Logic получает от Handler'а объекты, пользователя и операцию со всеми соответствующими атрибутами и принимает решение о предоставлении/не предоставлении доступа данному пользователю к данной операции с данными объектами.

Анализ полученного механизма

В первую очередь возникает вопрос к архитектуре - зачем передавать все данные об объектах через Handler, когда можно напрямую передавать их из SQL adapter в Logic, а затем сразу возвращать решение в Inspector.

Это обусловлено тем, что операции бывают нескольких видов: операции без объектов, операции с одним объектом и операции с несколькими объектами. В зависимости от вида операции, данные, передаваемые в модуль Logic, разные, и сделать передачу данных из Adaprter'а в Logic напрямую - значит, добавить в адаптер функцию разделения вида операций, что нарушает принцип модульности (данный модуль должен отвечать только за взаимодействие с базой данных).

Также может возникнуть еще один вопрос - как Handler определяет тип операции, и как он выполняет требование масштабируемости, если при добавлении нового функционала придется менять и сам Handler.

Это реализовано с помощью файла operation keys. Указанный файл включает в себя словари, которые содержат:

Соответствия между ключами из словаря POST запроса и операциями.

Соответствия между URL'ами и операциями.

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

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

Набор операций, в которых не используются объекты.

При обработке запроса Handler пользуется данным файлом для выделения нужной информации из запроса, а именно: название операции и id объекта/объектов. Поэтому при изменении запроса для какой-либо операции, достаточно будет поменять соответствующую запись в одном из словарей данного файла, и, аналогично, при добавлении какой-либо операции - добавить соответствующую запись.

Заключение

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

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

1. “Топ-5 крупнейших утечек c начала года” Kaspersky Lab [Электронный ресурс]. Режим доступа:  https://www.kaspersky.ru/blog/data-leaks-2017/18993/, свободный (дата обращения: 12.04.2018).

2. Приказ №17. Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах: утвержден ФСТЭК России 11 февраля 2013 г.

3. Приказ №21. Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных: утвержден ФСТЭК России 18 февраля 2013 г.

4. Угаров Д. В., Постоев Д. А. Проблемы реализации разграничения доступа к функциям управления виртуальных сред // Вопросы защиты информации: Научно-практический журнал/ФГУП «ВИМИ», М., 2016г., Вып.3, №114. С. 34-35.

5. ESXi Security [Электронный ресурс]. Режим доступа https://www.hytrust.com/solutions/private-cloud-controls/esxi/, свободный (дата обращения: 12.04.2018).

6. vGate [Электронный ресурс]. Режим доступа https://www.securitycode.ru/products/vgate/, свободный (дата обращения: 12.04.2018).

7. ПАК Сегмент-В. [Электронный ресурс]. Режим доступа http://www.accord.ru/segment-v.html/, свободный (дата обращения: 12.04.2018).

8. Goodbye, vSphere Web Client! [Электронный ресурс]. Режим доступа https://blogs.vmware.com/vsphere/2017/08/goodbye-vsphere-web-client.html, свободный (дата обращения: 12.04.2018).

9. Конявская С. В., Угаров Д. В., Постоев Д. А. Инструмент контроля доступа к средствам управления виртуальной инфраструктурой // Information Security/Информационная безопасность. М., 2016. № 2. С. 9.

Размещено на Allbest.ru

...

Подобные документы

  • Требования к аппаратной части компьютера и программному обеспечению. Установка системы VMware. Местонахождение файлов заголовков, соответствующих запущенной версии ядра. Создание виртуальной машины в операционной системе MS Windows XP Professional.

    контрольная работа [1,6 M], добавлен 22.10.2013

  • Інсталяція системи віртуальних машин. Установка ліцензії на використання VMware. Перший сеанс роботи на віртуальному комп’ютері. Застосування системи VMware, виділення оперативної пам’яті, конфігураційні параметри. Встановлення віртуальної Windows Xp.

    курсовая работа [4,2 M], добавлен 25.12.2013

  • Інсталяція системи віртуальних машин, установка ліцензії на використання VMware. Особливості роботи з віртуальним комп'ютером: копіювання і вставка, призупинення, виділення оперативної пам'яті. Підключення фізичних дисків до віртуального комп'ютера.

    курсовая работа [1,1 M], добавлен 05.06.2010

  • Предназначение контроля и учета трафика. Нецелевое использование средств. Общая архитектура серверов контроля корпоративного Интернет доступа. Среда программирования "Delphi 7". Рабочий компьютер администратора сети. Оборудование серверного помещения.

    дипломная работа [1,8 M], добавлен 03.07.2015

  • Формы организации сетевых служб в системе VMware. Назначение MAC-адресов для виртуальных компьютеров. Установка средств сетевой поддержки. Способы создания виртуальной сети на изолированном компьютере. Принцип установки средств сетевой поддержки.

    отчет по практике [3,5 M], добавлен 03.02.2011

  • Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.

    дипломная работа [2,5 M], добавлен 21.12.2012

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

    курсовая работа [118,9 K], добавлен 22.06.2011

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

    курсовая работа [51,4 K], добавлен 10.01.2012

  • Скачивание и установка VMware Workstation 12 Player for Windows 64 – bit operating systems. Скачивание и установка HDP 2.3 on Hortonworks Sandbox for VMware. Настройка конфигурационных файлов. Поддержка целостности данных в HDFS. Проверка работы Hadoop.

    лабораторная работа [10,7 M], добавлен 19.09.2019

  • Характеристика основных способов защиты от несанкционированного доступа. Разработка политики безопасности системы. Проектирование программного обеспечения применения некоторых средств защиты информации в ОС. Содержание основных разделов реестра.

    лабораторная работа [1,9 M], добавлен 17.03.2017

  • Анализ решений по автоматизации аптечной деятельности. Разработка автоматизированной системы формирования заказов. Проектирование многопользовательского доступа к данным. Организация сетевой работы. Реализация протокола взаимодействия сервера и клиента.

    дипломная работа [623,8 K], добавлен 19.01.2017

  • Система мандатного разграничения доступа. Разработка функциональной модели и ее уровни. Разработка информационной и динамической модели. Необходимость использования механизмов. Методология IDEFO. Функциональный блок. Анализ идентификационных данных.

    курсовая работа [1,9 M], добавлен 24.01.2009

  • Анализ существующих систем контроля и управления доступом различных фирм-производителей. Анализ технических и эксплуатационных характеристик различных систем, разработка системы контроля и управления доступом. Предложение плана реализации системы.

    дипломная работа [2,7 M], добавлен 07.06.2011

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

    курсовая работа [37,5 K], добавлен 07.12.2012

  • Основные характеристики и особенности использования прокси-сервера в локальной сети. Способы выхода в Интернет из локальных сетей. Методы аутентификации прокси-сервером пользователя клиента, авторизация клиента для доступа к определенному контенту.

    курсовая работа [887,9 K], добавлен 21.04.2019

  • Основные концепции объединения вычислительных сетей. Базовая эталонная модель взаимодействия открытых систем. Обработка сообщений по уровням модели OSI: иерархическая связь; форматы информации; проблемы совместимости. Методы доступа в ЛВС; протоколы.

    презентация [81,9 K], добавлен 13.08.2013

  • Знакомство с примером реализации ролевой модели контроля доступа на примере Волчанский механический завод филиал АО "Научно-производственная корпорация "Уралвагонзавод". Общая характеристика распространенных моделей безопасности информационных потоков.

    курсовая работа [10,8 M], добавлен 17.09.2019

  • Анализ принципов построения виртуальных сетей. Определение некоторых методов защиты в VPN сетях. Классификация основных методов построения таких сетей. Характеристика основных угроз и рисков в виртуальных сетях. Особенности возможных атак на VPN.

    дипломная работа [1,2 M], добавлен 22.09.2011

  • Потенциальные угрозы защищаемой информации. Обзор направлений защиты информации РАБИС-НП. Реализация разграничения доступа пользователей к объектам подсистем УБР, ТУ и ОИТУ КЦОИ. Обеспечение целостности дистрибутивов и пакетов модификации ТПК "РАБИС-НП".

    курсовая работа [117,2 K], добавлен 03.02.2011

  • Разработка и реализация компонентов "Интерфейс администратора", "Виртуальная лаборатория" системы удаленного доступа к вычислительным ресурсам. Определение функций клиента. Построение ER-модели базы данных системы УД и УРВР; архитектура и требования.

    дипломная работа [5,5 M], добавлен 26.05.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.