Содержание:

Введение

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

В опросе, проведенном Department for Digital, Culture, Media and Sport UK в 2018 году^[2], подавляющее большинство предприятий и благотворительных организаций зависят от онлайн-сервисов, что подвергает их риску. Использование облачных вычислений может помочь в сведении ИТ-затрат к минимуму; они также идеально подходят для сценариев разработки и тестирования приложений. Это самое простое решение для проверки потенциальных концепций без крупных вложений. Системы облачных вычислений предоставляют широкий спектр возможностей информационных технологий (ИТ) в режиме реального времени, используя множество различных типов ресурсов: аппаратное обеспечение, программное обеспечение, виртуальное хранилище после входа в облако. Облачные вычисления также могут быть частью более широкого бизнес-решения, в котором приоритетные приложения используют функциональность облачных вычислений, в то время как другие критически важные приложения поддерживают организационные ресурсы в обычном режиме. Это позволяет экономить средства, сохраняя при этом нужный уровень контроля безопасности системы в рамках организации.

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

Цель исследования – проанализировать угрозы безопасности и уязвимости облачных вычислений. Для достижения данной цели были поставлены следующие задачи:

- Обзор нормативных документов, российских и зарубежных научных публикаций в области информационной безопасности;

- Анализ угроз и рисков информационной безопасности сервисов;

- Сравнительный анализ архитектуры обеспечения информационной безопасности.

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

Глава 1. Обзор нормативных документов, российских и зарубежных научных публикаций в области информационной безопасности

1.1 Процессный подход к построению СУИБ

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

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

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

Процессам разработки и внедрения программного, встроенного и аппаратного оборудования свойственны ошибки или незапланированные инциденты, которые могут быть использованы злоумышленниками. В ИБ эти “лазейки” называются уязвимостями. Компьютерные системы никогда не будут свободны от уязвимостей, так как они разработаны, внедрены и протестированы людьми, которые всегда делают ошибки. Таким образом, уязвимость является угрозой безопасности. Атака — это угроза, которую реализует злоумышленник, обычно используя одну или несколько уязвимостей системы.

Для минимизации количества уязвимостей при разработке компьютерных системы были созданы стандарты, которые имеют рекомендательный характер. Для облачных сервисов актуальны следующие стандарты: в международной практике – ISO/IEC 27001/27002, в российской – ГОСТ Р ИСО/МЭК 27002-2012.

Стандарт ISO 27001^[4] был опубликован в 2005 году под названием «Информационные технологии — Методы обеспечения безопасности — Системы управления информационной безопасностью — Требования». На 42 страницах описываются требования, которым должна соответствовать система управления информационной безопасностью (СУИБ) для получения сертификации.

Рисунок 1. Процессный подход к построению СУИБ^[5].

Основным требованием к ИТ-системам в ISO 27001 является планирование, внедрение, эксплуатация и постоянный мониторинг и улучшение СУИБ. В стандарте говорится о том, что внедрение СУИБ должно быть процессным (рис. 1). Охват и область действия СУИБ должны быть определены на этапе планирования и внедрения; риски – идентифицированы и оценены; конечные цели управления – определены для информации и информационных систем. Из всего, описанного выше, должны быть выявлены подходящие меры для защиты операций и информации.

Требования, которые должны быть применены к документации СУИБ, описаны в основном содержимом стандарта, а также с помощью спецификаций структуры мониторинга, таких как:

• Процессы изменения и утверждения
• Контроль версий
• Правила прав и защиты доступа
• Спецификации файловых систем

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

Улучшение и дальнейшее развитие СУИБ должно осуществляться непрерывно. Кроме того, регулярные внутренние аудиты должны выполняться для улучшения и дальнейшего развития. Адекватное выполнение политики безопасности, а также ее пригодность и полнота должны обеспечиваться посредством ежегодных проверок со стороны руководства.

Требования к СУИБ, описанные в ISO 27001, расширены и объяснены в ISO 27002^[6]. Данный стандарт можно считать руководством по созданию СУИБ. С развитием в ISO 27002 стали включать распространенные практики в качестве процедур и методов, проверенных на практике^[7]. Компании могут адаптировать данные практики под себя и использовать их как пример успешного внедрения СУИБ. Для того, чтобы объяснить важность ИБ для компаний, в этих распространенных практиках изложены риски ИБ компании из примеров и необходимость принятия целевых и согласованных мер в рамках создания и внедрения СУИБ. Также в стандарте описаны необходимые шаги для идентификации и оценки рисков ИБ.

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

Уязвимости ИТ-систем создают угрозы для их безопасности. Заметим, что более 50% всех атак на информационную систему совершаются персоналом компании, однако значительная часть также инициирована совместными действиями персонала и людей со стороны^[8]. Поскольку внутренний персонал имеет доступ к конфиденциальной информации (о внутренних процессах, привычках, слабых местах, социальных отношениях и т.д.), следует учитывать, что они имеют более высокий процент успеха и причинения ущерба. Данные риски могут быть минимизированы при применении кадровых мер: набор персонала, увольнение или перераспределение по позициям. Так, например, права доступа должны быть ограничены только на той информации и элементах системы, которые являются необходимыми для выполнения работы, которая назначена пользователю. При изменении обязанностей или позиции права доступа должны быть перенастроены в соответствии с произошедшими изменениями, а если персонал уволен, то отменены.

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

Стандарт ГОСТ Р ИСО/МЭК 27002-2012^[9] является переводом стандарта ISO 27002, который описан выше^[10].

В 2009 году группа организаций, в которую входят IBM, Intel и Google, разработала Манифест «Open Cloud Manifesto»^[11], в котором данные компании предлагают практические рекомендации по предоставлению услуг облачных вычислений. В «Open Cloud Manifesto» облачные вычисления определены набором характеристик и преимуществ.

Характеристики, изложенные в манифесте:

• Возможность динамического масштабирования и предоставление вычислительной мощности с наименьшими затратами.
• Способность потребителя (конечного пользователя, организации или ИТ-персонала) максимально использовать эту мощность без необходимости непосредственно вникать в структуру технологии.
• Сама облачная архитектура может быть частной (размещенной в брандмауэре организации) или общедоступной (размещенной в Интернете).

Преимущества, перечисленные в манифесте:

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

С другой стороны, в статье ZDNet под названием «The Five Defining Characteristics of Cloud Computing»^[12] описаны следующие пять определяющих характеристик облачных вычислений:

• Динамическая вычислительная инфраструктура – стандартизированная, масштабируемая, динамическая, виртуализированная и безопасная физическая инфраструктура с уровнями избыточности для обеспечения высокого уровня доступности.
• Подход, ориентированный на ИТ-сервисы. В отличие от серверно-ориентированной модели, доступность выделенного экземпляра приложения или услуги.
• Модель использования на основе самообслуживания – возможность загружать, создавать, развертывать, планировать, управлять и предоставлять отчеты по предоставленным бизнес-услугам по требованию.
• Платформа с минимальным или самостоятельным управлением – самостоятельное управление с помощью автоматизации программного обеспечения с использованием следующего:
  • Механизм инициализации для развертывания служб и их разрушения, восстановления ресурсов для высокого уровня повторного использования.
  • Механизмы планирования и резервирования ресурсов.
  • Возможности конфигурирования, управления и отчетности для обеспечения возможности распределения и перераспределения ресурсов среди нескольких групп пользователей.
  • Инструменты для контроля доступа к ресурсам и политики для использования ресурсов или выполнения операций.
  • Биллинг на основе потребления – оплата ресурсов по мере их использования.

1.2 Облачные вычисления

В презентации 2009 года Питера Мелла и Тима Гранса из Лаборатории информационных технологий Национального института стандартов и технологий (NIST) «Эффективное и безопасное использование парадигмы облачных вычислений»^[13] облачные вычисления определяются следующим образом:

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

Эта облачная модель состоит из пяти основных характеристик, трех моделей обслуживания и четырех моделей развертывания^[14] (рис. 2). В первую очередь опишем пять основных характеристик.

Рисунок 2. Облачные вычисления

Самообслуживание по требованию.

Самообслуживание по требованию позволяет пользователям по мере необходимости использовать ресурсы облачных вычислений без участия поставщика облачных услуг. Благодаря самообслуживанию по требованию потребитель может планировать использование облачных сервисов, таких как вычисления и хранение, по мере необходимости. Чтобы быть эффективным и приемлемым для потребителя, интерфейс самообслуживания должен быть удобным для пользователя и обеспечивать эффективные средства управления услугами. Эта простота использования и устранение человеческого взаимодействия обеспечивает эффективность и экономию затрат как для пользователя, так и для поставщика облачных услуг.

Широкий доступ к сети.

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

Независимость от местоположения ресурсов.

Облако должно иметь большой и гибкий пул ресурсов для удовлетворения потребностей пользователей, обеспечения экономии масштаба и соответствия требованиям уровня обслуживания. Приложениям требуются ресурсы для их выполнения, и эти ресурсы должны выделяться эффективно для оптимальной производительности. Ресурсы могут быть физически расположены во многих географических точках и назначаться как виртуальные компоненты вычислений по мере необходимости. Как указано в “The NIST Definition of Cloud Computing” «Существует ощущение независимости местоположения в том смысле, что клиент, как правило, не имеет никакого контроля или знания о точном расположении предоставленных ресурсов, но может иметь возможность указать местоположение на более высоком уровне абстракции (например, страна, штат, или центр обработки данных).»

Быстрая эластичность.

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

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

Измеряемая служба.

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

Представление NIST для измеряемой услуги: «Облачные системы автоматически контролируют и оптимизируют использование ресурсов, используя возможности измерения на некотором уровне абстракции, соответствующем типу службы (например, хранение, обработка, пропускная способность и учетные записи активных пользователей). Использование ресурсов может отслеживаться, контролироваться и сообщаться, обеспечивая прозрачность как для поставщика, так и для потребителя используемой услуги».

Глава 2. Анализ угроз и рисков информационной безопасности

2.1 Классификация угроз и уязвимостей вычислений

Существует большое количество научных публикаций, посвященных безопасности в облачных вычислениях. Несколько рабочих групп постоянно публикуют статьи, касающиеся уязвимостей облачных вычислений и методов их перекрытия. Среди них наиболее значимыми являются CSA (Cloud Security Alliance), ENISA (Европейское агентство по сетевой и информационной безопасности) и NIST (Национальный институт стандартов и технологий). В 2013 году CSA выпустила отчет под названием «The Notorious Nine Cloud Computing Top Threats in 2013»^[15]. Специалисты отрасли провели опрос, чтобы определить основные угрозы и уязвимости в облачных вычислениях, и в итоге было перечислено девять критических угроз. ENISA^[16] определила девять наиболее важных угроз облачных вычислений в своем документе. Аналогичным образом, NIST в своей специальной публикации^[17] выделили критические аспекты безопасности. Среди этих рисков были определены наиболее важные.

• Утечка данных: конфиденциальные внутренние данные организации могут попасть в руки недоброжелателей из-за атак на виртуальные машины, связанные с синхронизацией по боковому каналу. Этот тип атаки может быть разработан для извлечения закрытых криптографических ключей, которые используются в других виртуальных машинах, находящихся на том же физическом сервере.
• Потеря данных: сохраненные данные могут быть потеряны из-за случайного удаления, потери ключа шифрования или, что еще хуже, физической катастрофы, такой как наводнение, землетрясение, пожар и т. Д.
• Перехват трафика учетных записей или сервисов: фишинг, мошенничество и эксплуатация уязвимостей программного обеспечения помогают злоумышленникам получить доступ к учетным данным клиентов, что способствует запуску последующих атак.
• Небезопасные интерфейсы и API: поставщики облачных услуг и третьи стороны используют интерфейсы прикладного программирования, чтобы предлагать клиентам различные услуги. Отсутствие надежной политики идентификации и управления доступом может привести к дополнительным сложностям и может также увеличить риск.
• Отказ в обслуживании: злоумышленники генерируют огромное количество поддельных запросов к определенному облачному серверу, поэтому сервер вынужден потреблять мощность процессора, память, дисковое пространство и пропускную способность сети. В конечном итоге это приводит к недопустимому замедлению работы системы и не позволяет другим клиентам пользоваться услугами.
• Злонамеренные инсайдеры: системные администраторы, нынешние или бывшие сотрудники, подрядчики или другие сторонние поставщики услуг, которые имеют или имели доступ, могут использовать его не по назначению и могут нанести преднамеренный ущерб, что повлияет на конфиденциальность, целостность и доступность конфиденциальных данных организации.
• Недостаточная юридическая проверка: недостаточное понимание среды поставщика услуг и неправильная оценка операционных возможностей могут поставить организацию в критическую ситуацию, если она поспешит с решением принятия технологии.
• Уязвимости совместно используемой технологии: уязвимости гипервизора, атака через боковой канал виртуальной машины, разрастание виртуальной машины и многие другие возможные угрозы из-за общей мультитенантной архитектуры (рис. 3) могут подвергнуть всю среду потенциальному компрометации.

Рисунок 3. Схематичное представление мультитенантной архитектуры^[18]

• Потеря управления: передача данных в облако означает передачу управления поставщику услуг. По ряду вопросов это может иметь последствия для безопасности.
• Блокировка: поскольку нет общепризнанного стандарта переносимости данных и услуг, зависимость от конкретного поставщика облачных услуг часто затрудняет переход клиента от одного поставщика к другому.
• Небезопасное или неполное удаление данных: удаление данных из облачного хранилища не гарантирует их недоступность в будущем. Фактически, если поставщик не удаляет данные надежно, или диск не шифруется клиентом, данные могут быть восстановлены позже.
• Цепочка доступности: поставщик облачных услуг может делегировать часть своей работы третьей стороне или даже может использовать услугу другого поставщика услуг. Таким образом, создается вероятность каскадных сбоев, которые могут повлиять на доступность службы.

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

Таблица 1. Классификация угроз и уязвимостей облачных вычислений

Категория	Угрозы и уязвимости безопасности
Сетевая безопасность	Подпись XML (Атака с обертыванием)
	Флуд-атаки
	Атака вредоносными программами
	Атака-спуфинг метаданных
	Небезопасные API
	Атака с использованием межсайтовых сценариев (XSS)
	Атака SQL-инъекцией
Защита виртуализации и гипервизора	Уязвимости гипервизора
	Выход из виртуальной машины
	Разрастание виртуальных машин
	Атака по боковым каналам виртуальной машины
	Устаревшие пакеты программного обеспечения в виртуальных машинах
	Единственная точка отказа
	Разрастание образа виртуальной машины

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

Подпись XML (Атака с обертыванием)

Подписи XML широко используются для проверки подлинности и целостности сообщений SOAP (Simple Object Access Protocol). Протоколы, использующие подписи XML, страдают от хорошо известной атаки, называемой атакой с использованием XML-подписи или просто атакой с обертыванием^[19]. Это относится к веб-сервисам и, следовательно, к облачным вычислениям. Для обеспечения целостности предварительно определенная часть или части сообщения SOAP подписываются с использованием подписи XML. Сообщение содержит заголовок безопасности с элементом подписи, который ссылается на одну или несколько частей сообщения, которые были подписаны. Атака обертывания подписи XML по существу использует тот факт, что элемент подписи не передает никакой информации о ссылочной части сообщения. Злоумышленник может легко изменить тело сообщения и внедрить вредоносный код без аннулирования подписи. Здесь злоумышленник фактически оборачивает подпись XML вокруг вредоносного кода и передает ее, как если бы это было подлинное сообщение^[20].

Флуд-атаки

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

Атака вредоносными программами

Этот тип атаки включает внедрение вредоносной службы или установки экземпляров виртуальных машин в облачную систему. В среде SaaS или Paas целью злоумышленника является создание собственной реализации службы, содержащей вредоносный код или сценарии, и развертывание этой службы в облаке таким образом, чтобы она выглядела как законная служба. Если злоумышленнику это удалось, то этот вид вредоносного ПО может выполнять любую вредоносную операцию. Таким образом, когда поступают действительные запросы, облачная система автоматически перенаправляет их на реализацию такого вредоносного сервиса. Воздействие этой атаки включает в себя прослушивание, скрытую модификацию данных, несанкционированный доступ к облачным ресурсам, утечку учетных данных пользователя, изменение функциональности и блокировку службы^[21]. Точно так же в среде IaaS злоумышленники могут создавать экземпляры виртуальных машин и внедрять в них вредоносное программное оборудование. Запросы законных пользователей останавливаются до тех пор, пока поддельные услуги не будут завершены. Это может привести к тупику службы, если количество запросов огромно. Ключевой проблемой здесь является не только обнаружение атаки, но и определение экземпляров виртуальной машины, которые используются злоумышленником для реализации вредоносной службы^[22].

Атака-спуфинг метаданных

При взаимодействии с другими веб-службами клиент веб-службы должен получить всю необходимую информацию, касающуюся вызова веб-службы. Эта информация включает адрес веб-службы, формат сообщения, местоположение в сети, требования безопасности и т.д. Эти данные хранятся в документах метаданных, предоставляемых сервером веб-служб. Двумя наиболее распространенными документами метаданных являются файл языка определения веб-служб (WSDL) и WSSecurity-Policy. Поскольку документы метаданных распространяются с использованием протоколов связи, таких как HTTP или электронная почта, они могут открыть возможности для атак-спуфингов^[23]. Злоумышленники могут намеренно изменять содержимое файла WSDL и распространять его по всем клиентам веб-службы. Это имеет серьезные последствия для безопасности. Как объяснено Гробером^[24], злоумышленник может изменить файл WSDL таким образом, что вызов операции deleteUser синтаксически выглядит как операция setAdminRights. Когда пользователю предоставляется этот измененный файл WSDL, каждый из вызовов операции deleteUser будет заменен вызовами операции setAdminRights. Таким образом, пользователи, которые должны быть удалены, теперь становятся активными с правами администратора. Другой способ подделки WSDL – изменить конечные точки сети и ссылки на политики безопасности (WS-Security-Policy). Модифицированные конечные точки сети помогают злоумышленнику легко начать атаку «пользователя в них». Подделка метаданных может быть опасной в среде облачных вычислений, где сама облачная система имеет некоторые функции хранилища WSDL. Предполагается, что новые пользователи могут динамически извлекать файл WSDL службы и распространять вредоносный файл WSDL по всей сети.

Небезопасные API

Клиенты в облаке обычно используют набор интерфейсов прикладного программирования (API) для управления и взаимодействия с облачными сервисами. Предоставление услуг, управление приложениями, мониторинг, включение функций безопасности и т.д. – всё выполняется через эти интерфейсы. Эти API имеют решающее значение для безопасности и доступности облачного сервиса. Если они не разработаны с надежными политиками идентификации и управления доступом, они могут быть легкой целью для злоумышленников. Злоумышленники всегда пытаются использовать уязвимости безопасности в этих API. Более того, организации и третьи стороны часто используют эти API-интерфейсы, чтобы предлагать своим клиентам различные дополнительные услуги. Этот новый многоуровневый API-интерфейс усложняет задачу, поскольку теперь сторонние поставщики услуг могут запросить данные у организации, чтобы подключить эти службы. Это имеет серьезные последствия для безопасности и конфиденциальности с точки зрения организаций. Несмотря на то, что поставщики облачных услуг всегда стремятся обеспечить хорошую интеграцию безопасности в их модели обслуживания, потребители должны понимать и анализировать последствия для безопасности, прежде чем передавать на аутсорсинг любую услугу. Незащищенные и плохо разработанные API могут подвергать организацию различным угрозам безопасности, которые могут повлиять на конфиденциальность, целостность и доступность данных.

Атака с использованием межсайтовых сценариев (XSS)

Атаки с использованием межсайтовых сценариев (XSS) в основном внедряют вредоносные сценарии или коды в веб-содержимое и тем самым заставляют веб-сайт выполнять написанные злоумышленником коды. Конечный пользователь является предполагаемой жертвой, а злоумышленник, использующий уязвимый веб-сайт, выступает в качестве источника для атак такого типа^[25]. Недостаточная проверка введенных пользователем данных является основной причиной XSS-атак. В этом случае могут произойти две вещи: либо веб-сайт не сможет нейтрализовать пользовательский ввод, либо он выполнит проверку неверно. Таким образом, это позволяет злоумышленникам использовать уязвимости. Злоумышленники могут похищать cookie-файлы веб-браузера и захватывать учетные данные пользователей в Интернете, извлекать конфиденциальные пользовательские данные, а также выполнять множество других вредоносных действий. В недавнем исследовании было обнаружено, что злоумышленники XSS могут получить полный контроль над веб-браузером, подобно программам «троянских коней». XSS может повлиять на пользователей двумя способами. Во время работы в Интернете на экране могут открываться некоторые специально созданные ссылки или всплывающие окна, и пользователи могут либо щелкнуть по этой вредоносной ссылке, либо их можно атаковать, во время посещения веб-страницы со встроенным вредоносным кодом. Таким образом, нарушитель получает контроль над личными данными пользователя.

Атака SQL-инъекцией

Атаки SQL-инъекцией – это класс атак, в которых вредоносный код вставляется в поля данных стандартного SQL-запроса. Таким образом, злоумышленники получают несанкционированный доступ к базам данных. Успешный эксплойт позволяет злоумышленникам извлекать личные и конфиденциальные данные из базы данных, подделывать существующие данные, изменяя базу данных с помощью операций вставки, удаления или обновления. Можно даже изменить роли и привилегии пользователей и выполнить операции администрирования, которые могут привести к полному уничтожению данных на сервере базы данных. Использование динамически генерируемого SQL-запроса и недостатки в обработке пользовательского ввода являются ключевыми причинами таких атак^[26].

Виртуализация и безопасность гипервизора

Виртуализация является одним из основных компонентов облачных вычислений, который помогает организациям оптимизировать производительность своих приложений экономически эффективным способом^[27]. Эта технология может также использоваться в качестве компонента безопасности; например, для обеспечения мониторинга виртуальных машин, облегчая задачи управления, такие как управление производительностью, управление облачной инфраструктурой и управление планированием емкости^[28]. Гипервизор действует как уровень абстракции, предоставляя необходимые функции для управления ресурсами, что обеспечивает совместное использование аппаратных ресурсов виртуальными машинами^[29]. Хотя эти технологии приносят большие выгоды, они также создают дополнительные угрозы безопасности, которые обсуждаются далее.

Уязвимости гипервизора

Гипервизор или монитор виртуальной машины предназначен для одновременного запуска нескольких гостевых виртуальных машин и приложений на одном хост-компьютере и обеспечения изоляции между гостевыми виртуальными машинами. Хотя ожидается, что гипервизоры будут надежными и безопасными, они уязвимы для атак. Если злоумышленники получат контроль над гипервизором, все виртуальные машины и данные, к которым они обращаются, будут находиться под их полным контролем для использования^[30]. Еще одна причина, по которой хакеры считают гипервизор потенциальной целью – больший контроль, поддерживаемый нижними уровнями в виртуализированной среде. Компрометация гипервизора также помогает получить контроль над базовой физической системой и размещенными приложениями. Поскольку гипервизор работает под операционной системой хоста, такие виды атак трудно обнаружить с помощью регулярных мер безопасности.

Выход из виртуальной машины

Виртуальные машины предназначены для поддержки сильной изоляции между хостом и виртуальными машинами. Но уязвимости в операционной системе, работающей внутри виртуальных машин, могут помочь злоумышленникам ввести в нее вредоносную программу. Когда эта программа запускается, виртуальная машина нарушает изолированные границы и начинает обмениваться данными с операционной системой, минуя уровень монитора виртуальной машины. Такая эксплуатация позволяет злоумышленникам получить доступ к хост-машине и начать дальнейшие атаки^[31].

Разрастание виртуальных машин

Разрастание виртуальных машин происходит, когда в среде существует большое количество виртуальных машин без надлежащего управления или контроля. Так как они потребляют системные ресурсы (то есть память, диски, сетевые каналы и т. Д.) в течение этого периода, эти ресурсы не могут быть назначены другим виртуальным машинам, и они фактически теряются. Домбровски и соавт.^[32] демонстрируют два обстоятельства, которые могут вызвать разрастание виртуальных машин и способствовать созданию потерянных. Виртуальные машины обычно выделяются и завершаются по запросу пользователей, и система генерирует сообщения подтверждения в ответ. Проблема возникает, когда создание или завершение виртуальной машины завершено, но сообщения теряются при передаче. Пользователи повторяют попытки, генерируя новые запросы до тех пор, пока они не станут успешными, и это приводит к увеличению числа потерянных виртуальных машин. В конечном итоге системные ресурсы истощаются, что приводит к снижению общей производительности системы. Перенос потерянных виртуальных машин на другой слегка загруженный физический сервер может в определенной степени решить эту проблему. Но обеспечение одинакового уровня конфигураций безопасности, качества обслуживания и применения политик конфиденциальности всегда является проблемой.

Атака по боковым каналам виртуальной машины

Чтобы максимизировать использование ресурсов, несколько виртуальных машин обычно размещаются на одном физическом сервере в облачной среде, и такое совместное размещение является потенциальной угрозой для атаки через боковой канал виртуальной машины. Основная идея такова: вредоносная виртуальная машина проникает в изоляцию между виртуальными машинами, а затем получает доступ к общему оборудованию и расположениям кэша для извлечения конфиденциальной информации из целевой виртуальной машины. Ристенпарт^[33] впервые показал, что можно отобразить внутреннюю облачную инфраструктуру и преднамеренно разместить вредоносную виртуальную машину на том же физическом сервере, на котором может находиться целевая виртуальная машина. Поместив вредоносную виртуальную машину вместе с ее жертвой, они продемонстрировали предварительные результаты по различным атакам по боковым каналам между виртуальными машинами, включая отказ в обслуживании (DoS), мониторинг удаленного нажатия клавиш с помощью временного логического вывода и другие. В 2012 году Чан^[34] продемонстрировал, что, запустив атаку по побочному каналу, злонамеренная виртуальная машина может извлечь закрытый ключ из виртуальной машины-жертвы, работающей на том же физическом сервере.

Устаревшие пакеты программного обеспечения в виртуальных машинах

Устаревшие программные пакеты на виртуальных машинах могут создавать серьезные угрозы безопасности в виртуализированной среде. Из-за низкой стоимости и простоты создания пользователи, как правило, создают для различных задач новые виртуальные машины, разветвляют новые виртуальные машины на основе старых или даже откатывают машины до более раннего состояния. Эти операции могут иметь серьезные последствия для безопасности, например, операция отката машины может привести к программной ошибке, которая уже была исправлена^[35].

Единственная точка отказа

Существующие виртуализированные среды основаны на технологии гипервизора, которая контролирует доступ виртуальных машин к физическим ресурсам и важна для общего функционирования системы. Следовательно, отказ гипервизора из-за чрезмерного использования инфраструктуры или программных ошибок приводит к краху всей системы^[36]. Вся система должна быть перезагружена для восстановления после таких сбоев. Но такие сбои приводят к произвольным нарушениям состояния и несоответствиям во всей системе, и, следовательно, все работы, которые выполнялись на всех виртуальных машинах, теряются^[37]. Другой недостаток виртуализированных серверов состоит в том, что они имеют конечное количество точек доступа для всех виртуальных машин. Компрометация этих точек доступа может открыть злоумышленникам возможность использовать виртуальную облачную инфраструктуру, включая виртуальные машины, гипервизор и хост-машину^[38].

Разрастание образа виртуальной машины

Безопасное управление образами виртуальных машин является важным требованием в среде облачных вычислений. Каждый образ виртуальной машины на самом деле представляет собой полный программный стек, содержащий установленные и настроенные приложения, которые используются для загрузки виртуальной машины в исходное состояние или состояние некоторой предыдущей контрольной точки^[39]. Они обрабатываются как данные, и поэтому их легко клонировать, расширять и снимать. Таким образом, образы виртуальных машин растут в количестве и могут вызвать разрастание образов виртуальных машин^[40]. Еще одна критическая проблема заключается в том, что многие образы виртуальных машин предназначены для совместного использования разными и часто несвязанными пользователями. Если хранилища изображений не находятся под тщательным управлением и контролем, совместное использование образов виртуальных машин может создавать угрозу конфиденциальности и безопасности^[41]. Более того, поскольку образ может содержать код и данные о праве собственности, владелец образа рискует непреднамеренно раскрыть конфиденциальную информацию. Злоумышленники будут стремиться изучить образ, чтобы обнаружить лазейки в системе безопасности. Злоумышленники могут также внедрить вредоносные коды в образ виртуальной машины или предоставить совершенно новый образ виртуальной машины, содержащий вредоносное ПО^[42].

Вывод

Угрозы и уязвимости ИБ облачных вычислений пересекаются с угрозами и уязвимостями ИБ традиционных вычислений, однако особенности архитектуры облака добавляют новые точки для атаки злоумышленников. Также факт того, что облачные сервисы доступны из любой точки мира через веб-браузер, делает облачные сервисы более подверженными к атакам.

2.3 Сравнительный анализ архитектуры облачных сервисов с точки зрения обеспечения информационной безопасности

Как уже было описано выше, в облачных вычислениях существуют три модели обслуживания: облачное программное обеспечение как услуга (SaaS – Software as a Service), облачная платформа как услуга (PaaS – Platform as a Service) и облачная инфраструктура как услуга (IaaS – Infrastructure as a Service) (Рис. 4).

Рисунок 4. Модели обслуживания облачных вычислений

Рассмотрим подробнее угрозы и уязвимости каждой модели.

Облачное программное обеспечение как услуга (SaaS)

SaaS предоставляет прикладные услуги по запросу, такие как электронная почта, программное обеспечение для проведения конференций и бизнес-приложения, такие как ERP, CRM и SCM^[43]. Пользователи SaaS имеют наименьший контроль над безопасностью среди трех основных моделей обслуживания в облаке. Интеграция приложений SaaS может вызвать некоторые проблемы безопасности.

Безопасность приложений

SaaS-приложения обычно разворачиваются через Интернет с помощью веб-браузера^[44]. Однако недостатки в веб-приложениях могут создавать уязвимости для приложений SaaS. Злоумышленники используют Интернет для компрометации компьютеров пользователей и выполнения злонамеренных действий, таких как кража конфиденциальных данных^[45]. Проблемы безопасности в SaaS-моделях не отличаются от проблем безопасности в любых веб-приложениях, но традиционные решения данных проблем не обеспечивают эффективной защиты от атак. Возникает необходимость создания новых методов.

Мультитенантность (Мультиарендность)

SaaS-приложения классифицированы как модели зрелости. Классификация основывается на следующих характеристиках: масштабируемость, конфигурируемость с помощью метаданных и мультитенантность ^[46]. В первой модели у каждого пользователя свой собственный экземпляр программы. У данной модели есть свои недостатки, однако при такой конфигурации возникает меньше угроз ИБ. Во второй модели поставщик также предоставляет каждому пользователю свой экземпляр программы, но все экземпляры создаются с помощью одного и того же кода. В данной модели пользователи могут менять некоторые аспекты конфигурации. В третьей модели зрелости используется ​​многопользовательская аренда — один экземпляр обслуживает всех пользователей. Данный подход позволяет более продуктивно распределять ресурсы, однако минусом является ограниченность масштабируемости. Основной проблемой является риск утечки информации между пользователями, так как их данные хранятся в одной базе данных на одном сервере. Необходимо создать и внедрить политики безопасности для обеспечения безопасности данных пользователей. Проблема с масштабированием решается с помощью переноса приложения на другой, более мощный сервер.

Безопасность информации

Любая технология сталкивается с проблемами обеспечения безопасности информации, но они становятся более серьезной проблемой в моделях SaaS, так как пользователям приходится полагаться на поставщика в вопросах обеспечения ИБ. Зачастую в данной модели обслуживания данные пользователей обрабатываются в незашифрованном виде и хранятся на облаке. Вся ответственность за безопасность информации во время обработки и хранения лежит на провайдере. Также необходимо создавать резервные копии данных, но это добавляет уязвимостей ИБ. Еще одной проблемой является то, что поставщики решений SaaS могут обращаться к третьим лицам по вопросам предоставления платформ PaaS или IaaS.

Облачная платформа как услуга (PaaS)

Сервисы PaaS упрощают развертывание облачных приложений. Они сокращают затраты, так как нет необходимости тратить ресурсы на покупку, установки и поддержание работы ПО. Как и в все модели обслуживания, PaaS сильно зависит от обеспечения безопасности сети и браузера. Так как платформы PaaS включают в себя два уровня, то и вопросы безопасности нужно рассматривать касательно этих двух уровней: безопасность самого сервиса, который предоставляет услуги PaaS, и безопасность пользовательских приложений на платформе PaaS^[47]. Соответственно за безопасность самого сервиса и механизма по развертыванию пользовательских приложений отвечает поставщик, за безопасность самих приложений – пользователи.

Третьи лица

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

Жизненный цикл разработки

Одним из основных вопросов при создании веб-приложения является вопрос обеспечения его безопасности. Разработчикам нужно учитывать, что их приложение будет размещено в Интернете, что добавляет уязвимостей ИБ. Скорость изменения приложений будет влиять как на разработку самой системы, так и на средства обеспечения ее безопасности^[48]. Разработчики нужно понимать, что сервисы PaaS часто изменяются и обновляются, при создании приложений нужно учитывать данный аспект и разрабатывать достаточно гибкую конфигурацию, чтобы успевать за изменениями сервиса. Однако разработчики должны осознавать, что изменения в сервисе PaaS могут привести к возникновению новых уязвимостей и угроз безопасности. Помимо разработки приложений с учетом их безопасности, разработчики также должны знать о нормативных аспектах обеспечения ИБ.

Центральная инфраструктура безопасности

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

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

Облачная инфраструктура как услуга (IaaS)

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

Описав угрозы безопасности для каждой модели, проведем сравнительный анализ (табл. 2). Уязвимости и угрозы сравниваются по тому, на ком лежит ответственность за безопасность в каждом конкретном случае, и по сути – как каждая уязвимость отражена в каждой модели.

Таблица 2. Сравнение уязвимостей и угроз облачных вычислений.

Угроза	Аспект сравнения	SaaS	PaaS	IaaS
Безопасность приложений	Ответст- венность	Провайдер	Пользователь	Пользователь
	Суть	Так как в SaaS модели провайдер предоставляет приложения, ответственность за их безопасность лежит на нем	Пользователь сам создает приложения в данной модели, ответственность за их безопасность лежит на нем	Пользователь сам создает приложения в данной модели, ответственность за их безопасность лежит на нем
Мульти-аренды	Ответст-венность	Провайдер	Провайдер	Провайдер
	Суть	Один экземпляр приложения используется несколькими пользователями.	Для сокращения затрат несколько приложений могут быть размещены на одном сервере, что повышает угрозы безопасности	Виртуальные машины могут быть размещены на одном физическом сервере.
Безопасность данных	Ответст-венность	Провайдер	Провайдер / Пользователь	Провайдер / Пользователь
	Суть	Пользователи полагаются на провайдеров в вопросах обеспечения безопасности их данных	Со стороны пользователя данные внутри приложения должны быть защищены, со стороны провайдера должно быть защищено само приложение	Со стороны пользователя данные внутри виртуальной машины должны быть защищены, со стороны провайдера должна быть защищена сама виртуальная машина
Третьи лица	Ответст-венность	Провайдер	Провайдер	Не является проблемой
	Суть	SaaS-модель строится на PaaS, которая в свою очередь основывается на IaaS. Провайдер SaaS может арендовать PaaS у третьих лиц.	PaaS основывается на IaaS. Провайдер PaaS может арендовать IaaS у третьих лиц.
Жизненный цикл разработки	Ответст-венность	Провайдер	Провайдер / Пользователь	Провайдер / Пользователь
	Суть	Облачные сервисы – быстро меняющиеся структуры. С каждым изменением нужно учитывать вопросы безопасности.	Облачные сервисы – быстро меняющиеся структуры. Пользователи при разработке должны учитывать изменения в системе.	Виртуальные машины могут выключены и приостановлены, что затрудняет обнаружение вредоносного ПО.
Основная инфраструктура безопасности	Ответст-венность	Провайдер	Провайдер	Не является проблемой
	Суть	Пользователь может быть уверен в безопасности данных со своей стороны, но не знать о проблемах безопасности со стороны провайдера	Пользователь может быть уверен в безопасности данных со своей стороны, но не знать о проблемах безопасности со стороны провайдера
Виртуализация	Ответст-венность	Провайдер	Провайдер	Провайдер
	Суть	Облачные сервисы имеют большее количество точек доступа чем системы традиционных вычислений, что увеличивает риски.	Облачные сервисы имеют большее количество точек доступа чем системы традиционных вычислений, что увеличивает риски.	Облачные сервисы имеют большее количество точек доступа чем системы традиционных вычислений, что увеличивает риски.
Монитор виртуальной машины	Ответст-венность	Провайдер	Провайдер	Провайдер
	Суть	Если провайдер предлагает несколько приложений, то ответственность за их разделение лежит на нем.	Если провайдер предлагает несколько различных платформ, то ответственность за их разделение лежит на нем	МВМ разделяет виртуальные машины, созданные пользователями. Провайдер должен следить за безопасностью МВМ.
Публичный репозиторий образов виртуальных машин	Ответст-венность	Не является проблемой	Провайдер	Провайдер
	Суть		При создании приложения пользователь может воспользоваться уже имеющимся образом в репозитории провайдера. За безопасность репозитория отвечает провайдер.	При создании виртуальной машины пользователь может воспользоваться уже имеющимся образом в репозитории провайдера. За безопасность репозитория отвечает провайдер.
Откат виртуальной машины	Ответст-венность	Не является проблемой	Не является проблемой	Пользователь / Провайдер
	Суть			При возникновении проблемы пользователь может откатить машину к предыдущему состоянию, однако это может привести к возвращению уже решенных проблем.

Заключение

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

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

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

Каждая модель облачного сервиса имеет свои собственные недостатки безопасности; тем не менее, они также разделяют некоторые проблемы, которые затрагивают их всех. Любая атака на любой уровень облачных сервисов может поставить под угрозу верхние уровни. PaaS, а также SaaS размещаются поверх IaaS; таким образом, любое нарушение в IaaS повлияет на безопасность как PaaS, так и SaaS-сервисов. Также сравнительный анализ моделей обслуживания показал, что в SaaS-моделях ответственность за ИБ облачного сервиса лежит на провайдере, тогда как в IaaS и PaaS-моделях она разделена между пользователем и провайдером.

Список использованной литературы

1. A.S. Ibrahim, J. Hamlyn-Harris, and J. Grundy. Emerging Security Challenges of Cloud Virtual Infrastructure. // APSEC Cloud Workshop. 2016
2. B. Grobauer, T. Walloschek, and E. Stocker. Understanding Cloud Computing Vulnerabilities. IEEE Security & Privacy. 2017
3. C. Dabrowski and K. Mills. VM Leakage and Orphan Control in Open-Source Clouds. // 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom). 2015.
4. Cloud Computing: Benefits, risks and recommendations for information security // European Network and Information Security Agency (ENISA), 2014
5. Cyber Security Breaches Survey 2018: Statistical Release // Department for Digital, Culture, Media and Sport. 2018
6. Cyber Security Breaches Survey 2018: Statistical Release // Department for Digital, Culture, Media and Sport // 2018
7. D. Reimer, A. Thomas, G. Ammons, T. W. Mummert, B. Alpern, and Vasanth Bala. Opening Black Boxes: Using Semantic Information to Combat Virtual Machine Image Sprawl. // VEE. 2014.
8. Disterer G. ISO/IEC 27000, 27001 and 27002 for Information Security Management // Journal of Information Security. - 2013.
9. F. Lombardi and R. D. Pietro. Secure Virtualization for Cloud Computing. // Journal of Network and Computer Applications. 2016.
10. F. Sabahi. Secure Virtualization for Cloud Environment Using Hypervisor-based Technology. // Int. Journal of Machine Learning and Computing. 2017
11. F. Sabahi. Secure Virtualization for Cloud Environment Using Hypervisor-based Technology. // Int. Journal of Machine Learning and Computing. 2017.
12. Ferraiolo D. Cloud Computing [Электронный ресурс] // NIST - URL: https://csrc.nist.gov/projects/cloud-computing (дата обращения: 15.04.2019)
13. ISO 27002 “Информационные технологии - Методы защиты – Свод рекомендуемых правил для управления информационной безопасностью”. Введ. 2013-10-01.
14. ISO/IEC 27001 "Информационные технологии — Методы обеспечения безопасности — Системы управления информационной безопасностью — Требования". Введ. 2005
15. J. Wei, X. Zhang, G. Ammons, V. Bala, and P. Ning. Managing Security of Virtual Machine Images in a Cloud Environment. // CCSW. 20016.
16. J.C. Roberts II, W. Al-Hamdani. Who Can You Trust in the Cloud? A Review of Security Issues Within Cloud Computing // Information Security Curriculum Development Conference. 2016
17. Ju J, Wang Y, Fu J, Wu J, Lin Z: Research on Key Technology in SaaS // In International Conference on Intelligent Computing and Cognitive Informatics (ICICCI), Hangzhou, China. 2015
18. K. Zunnurhain and S. Vrbsky. Security Attacks and Solutions in Clouds // 3rd International Conference on Cloud Computing. 2016
    • 1. Liu, Y. Yuan, and A. Stavrou. QLProb: A Proxybased Architecture towards Preventing SQL Injection Attacks. // SAC. 2015
19. M. Jensen, N. Gruschka, and Ralph Herkenh¨oner. A Survey of Attacks on Web Services // Computer Science - R&D. 2015
    1. M. Khalil, A. Khreishah, and M. Azeem. Cloud Computing Security: A Survey // Computers. 2014
20. M. Le and Y. Tamir. ReHype: Enabling VM Survival Across Hypervisor Failures. // VEE. 2016.
21. M. Pearce, S. Zeadally, and R. Hunt. Virtualization: Issues, security threats, and solutions // ACM Comput. Surv. 2017.
22. M.A. Morsy, J. Grundy, and I. Muller. An Analysis of the Cloud Computing Security Problem. // APSEC Cloud Workshop. 2015
23. Mather T, Kumaraswamy S, Latif S: Cloud Security and Privacy // O’Reilly Media, Inc.; 2017
24. Meiko Jensen, Nils Gruschka, Jörg Schwenk, Luigi Lo Iacono On Technical Security Issues in Cloud Computing // IEEE International Conference on Cloud Computing. 2015.
25. Morsy MA, Grundy J, Müller I: An analysis of the Cloud Computing Security problem. // APSEC 2016 Cloud Workshop. 2016
26. Open Cloud Manifesto - A call to action for the worldwide cloud community. 2009
27. Owens D: Securing elasticity in the Cloud // Commun ACM 2017
28. Peter Mell Effectively and Securely Using the Cloud Computing Paradigm // NIST, Information Technology Laboratory. - 2009
29. Peter Mell, Timothy Grance The NIST Definition of Cloud Computing // National Institute of Standards and Technology. - 2011.
30. R. Bhadauria and S. Sanyal. Survey on Security Issues in Cloud Computing and Associated Mitigation Techniques. 2015.
31. R. Schwarzkopf, M. Schmidt, N. Fallenbeck, and B. Freisleben. Multi-layered Virtual Machines for Security Updates in Grid Environments. // EUROMICRO-SEAA. 2014.
32. Ramgovind S The Management of Security in Cloud Computing // Information Security for South Africa. Sandton, Johannesburg, South Africa: IEEE. 2010
33. Rittinghouse JW, Ransome JF: Security in the Cloud. In Cloud Computing. Implementation, Management, and Security // CRC Press; 2016.
34. S. Luo, Z. Lin, X. Chen, Z. Yang, and J. Chen. Virtualization Security for Cloud Computing Services. // Int. Conf on Cloud and Service Computing. 2015.
35. T. Ristenpart, E. Tromer, H. Shacham, and S. Savage. Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. // ACM Conference on Computer and Communications Security. 2009.
36. The Notorious Nine Cloud Computing Top Threats in 2013 // Cloud Security Alliance, 2013.
37. W. Jansen and T. Grance. Guidelines on Security and Privacy in Public Cloud Computing Special Publication
38. W.A. Jansen. Cloud Hooks: Security and Privacy Issues in Cloud Computing. // 44th Hawaii International Conference on Systems Science. 2015.
39. Wayne Jansen, Timothy Grance Guidelines on Security and Privacy in Public Cloud Computing // NIST, 2014
40. Y. Zhang, M. Ion, G. Russello, and B. Crispo. Cross-VM Side Channels and their Use to Extract Private Keys.
41. Zhang Y, Liu S, Meng X: Towards high level SaaS maturity model: methods and case study // In Services Computing conference. IEEE Asia-Pacific: APSCC; 2016
42. ГОСТ Р ИСО/МЭК 27000-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология. Введ. 2013-12-01
43. ГОСТ Р ИСО/МЭК 27002-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности. Введ. 2014-01-01.
44. Закон Российской Федерации "ФЕДЕРАЛЬНЫЙ ЗАКОН ОБ ИНФОРМАЦИИ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЯХ И О ЗАЩИТЕ ИНФОРМАЦИИ" от 8.07.2006 № N 149-ФЗ
45. Мультитенантная архитектура для SaaS приложений // Habr URL: https://habr.com/ru/company/microsoft/blog/145027/ (дата обращения: 08.05.2019).
46. Родичев Ю.А. Нормативная база и стандарты в области информационной безопасности. Учебное пособие. - СПб.: Питер, 2017.

1. Ramgovind S The Management of Security in Cloud Computing // Information Security for South Africa. Sandton, Johannesburg, South Africa: IEEE. 2010 ↑

2. Cyber Security Breaches Survey 2018: Statistical Release // Department for Digital, Culture, Media and Sport. 2018 ↑

3. Закон Российской Федерации "ФЕДЕРАЛЬНЫЙ ЗАКОН ОБ ИНФОРМАЦИИ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЯХ И О ЗАЩИТЕ ИНФОРМАЦИИ" от 8.07.2006 № N 149-ФЗ ↑

4. ISO/IEC 27001 "Информационные технологии — Методы обеспечения безопасности — Системы управления информационной безопасностью — Требования". Введ. 2005 ↑

5. ГОСТ Р ИСО/МЭК 27000-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология. Введ. 2013-12-01 ↑

6. ISO 27002 “Информационные технологии - Методы защиты – Свод рекомендуемых правил для управления информационной безопасностью”. Введ. 2013-10-01. ↑

7. Disterer G. ISO/IEC 27000, 27001 and 27002 for Information Security Management // Journal of Information Security. - 2013. ↑

8. Cyber Security Breaches Survey 2018: Statistical Release // Department for Digital, Culture, Media and Sport // 2018 ↑

9. ГОСТ Р ИСО/МЭК 27002-2012 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности. Введ. 2014-01-01. ↑

10. Родичев Ю.А. Нормативная база и стандарты в области информационной безопасности. Учебное пособие. - СПб.: Питер, 2017. ↑

11. Open Cloud Manifesto - A call to action for the worldwide cloud community. 2009 ↑

12. Peter Mell, Timothy Grance The NIST Definition of Cloud Computing // National Institute of Standards and Technology. - 2011. ↑

13. Peter Mell Effectively and Securely Using the Cloud Computing Paradigm // NIST, Information Technology Laboratory. - 2009 ↑

14. Ferraiolo D. Cloud Computing [Электронный ресурс] // NIST - URL: https://csrc.nist.gov/projects/cloud-computing (дата обращения: 15.04.2019) ↑

15. The Notorious Nine Cloud Computing Top Threats in 2013 // Cloud Security Alliance, 2013. ↑

16. Cloud Computing: Benefits, risks and recommendations for information security // European Network and Information Security Agency (ENISA), 2014 ↑

17. Wayne Jansen, Timothy Grance Guidelines on Security and Privacy in Public Cloud Computing // NIST, 2014 ↑

18. Мультитенантная архитектура для SaaS приложений // Habr URL: https://habr.com/ru/company/microsoft/blog/145027/ (дата обращения: 08.05.2019). ↑

19. Meiko Jensen, Nils Gruschka, Jörg Schwenk, Luigi Lo Iacono On Technical Security Issues in Cloud Computing // IEEE International Conference on Cloud Computing. 2015. ↑

20. J.C. Roberts II, W. Al-Hamdani. Who Can You Trust in the Cloud? A Review of Security Issues Within Cloud Computing // Information Security Curriculum Development Conference. 2016 ↑

21. K. Zunnurhain and S. Vrbsky. Security Attacks and Solutions in Clouds // 3rd International Conference on Cloud Computing. 2016 ↑

22. I. M. Khalil, A. Khreishah, and M. Azeem. Cloud Computing Security: A Survey // Computers. 2014 ↑

23. M. Jensen, N. Gruschka, and Ralph Herkenh¨oner. A Survey of Attacks on Web Services // Computer Science - R&D. 2015 ↑

24. B. Grobauer, T. Walloschek, and E. Stocker. Understanding Cloud Computing Vulnerabilities. IEEE Security & Privacy. 2017 ↑

25. R. Bhadauria and S. Sanyal. Survey on Security Issues in Cloud Computing and Associated Mitigation Techniques. 2015. ↑

26. A. Liu, Y. Yuan, and A. Stavrou. QLProb: A Proxybased Architecture towards Preventing SQL Injection Attacks. // SAC. 2015 ↑

27. F. Sabahi. Secure Virtualization for Cloud Environment Using Hypervisor-based Technology. // Int. Journal of Machine Learning and Computing. 2017 ↑

28. F. Lombardi and R. D. Pietro. Secure Virtualization for Cloud Computing. // Journal of Network and Computer Applications. 2016. ↑

29. M. Pearce, S. Zeadally, and R. Hunt. Virtualization: Issues, security threats, and solutions // ACM Comput. Surv. 2017. ↑

30. M.A. Morsy, J. Grundy, and I. Muller. An Analysis of the Cloud Computing Security Problem. // APSEC Cloud Workshop. 2015 ↑

31. S. Luo, Z. Lin, X. Chen, Z. Yang, and J. Chen. Virtualization Security for Cloud Computing Services. // Int. Conf on Cloud and Service Computing. 2015. ↑

32. C. Dabrowski and K. Mills. VM Leakage and Orphan Control in Open-Source Clouds. // 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom). 2015. ↑

33. T. Ristenpart, E. Tromer, H. Shacham, and S. Savage. Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. // ACM Conference on Computer and Communications Security. 2009. ↑

34. Y. Zhang, M. Ion, G. Russello, and B. Crispo. Cross-VM Side Channels and their Use to Extract Private Keys.

    // ACM CCCS. 2012. ↑

35. R. Schwarzkopf, M. Schmidt, N. Fallenbeck, and B. Freisleben. Multi-layered Virtual Machines for Security Updates in Grid Environments. // EUROMICRO-SEAA. 2014. ↑

36. F. Sabahi. Secure Virtualization for Cloud Environment Using Hypervisor-based Technology. // Int. Journal of Machine Learning and Computing. 2017. ↑

37. M. Le and Y. Tamir. ReHype: Enabling VM Survival Across Hypervisor Failures. // VEE. 2016. ↑

38. A.S. Ibrahim, J. Hamlyn-Harris, and J. Grundy. Emerging Security Challenges of Cloud Virtual Infrastructure. // APSEC Cloud Workshop. 2016 ↑

39. W.A. Jansen. Cloud Hooks: Security and Privacy Issues in Cloud Computing. // 44th Hawaii International Conference on Systems Science. 2015. ↑

40. D. Reimer, A. Thomas, G. Ammons, T. W. Mummert, B. Alpern, and Vasanth Bala. Opening Black Boxes: Using Semantic Information to Combat Virtual Machine Image Sprawl. // VEE. 2014. ↑

41. J. Wei, X. Zhang, G. Ammons, V. Bala, and P. Ning. Managing Security of Virtual Machine Images in a Cloud Environment. // CCSW. 20016. ↑

42. W. Jansen and T. Grance. Guidelines on Security and Privacy in Public Cloud Computing Special Publication ↑

43. Ju J, Wang Y, Fu J, Wu J, Lin Z: Research on Key Technology in SaaS // In International Conference on Intelligent Computing and Cognitive Informatics (ICICCI), Hangzhou, China. 2015 ↑

44. Rittinghouse JW, Ransome JF: Security in the Cloud. In Cloud Computing. Implementation, Management, and Security // CRC Press; 2016. ↑

45. Owens D: Securing elasticity in the Cloud // Commun ACM 2017 ↑

46. Zhang Y, Liu S, Meng X: Towards high level SaaS maturity model: methods and case study // In Services Computing conference. IEEE Asia-Pacific: APSCC; 2016 ↑

47. Mather T, Kumaraswamy S, Latif S: Cloud Security and Privacy // O’Reilly Media, Inc.; 2017 ↑

48. Morsy MA, Grundy J, Müller I: An analysis of the Cloud Computing Security problem. // APSEC 2016 Cloud Workshop. 2016 ↑