VIII Международная студенческая научная конференция Студенческий научный форум - 2016

В работе приведена классификация облачных сервисов. Рассмотрены основные проблемы обеспечения безопасности в облачных сервисах. Предложены варианты реализации системы безопасности облачных структур

Ключевые слова: Облачные системы, защищенность, требования к обеспечению безопасности.

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

Тем не менее, до сих пор еще нет четкого и однозначного определения, какие системы относятся к облачным. В 2008 году был опубликован документ IEEE «ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing» [1], в котором дается следующее определение (приведем наиболее распространенный перевод): «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в интернет и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и т. д.». Это определение слишком обобщено, поэтому нуждается в дополнительных уточнениях.

Чаще всего говорят о следующем наборе требований к облачным системам:

1. Сетевой доступ к сервисам обеспечивается с использованием стандартных протоколов –обычных и защищенных (универсальность доступа).

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

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

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

Свои рекомендации по организации облачных вычислений предложил National Institute of Standarts and Technology (NIST) [2], [3] . Референтная (эталонная) архитектура облачных вычислений NIST [3] представляет:

• три модели сервиса (Программное обеспечение как услуга -Software as a Service (SaaS), Платформа как услуга - Platform as a service (PaaS), Инфраструктура как услуга - Infrastructure as a Service (IaaS)),

• четыре модели развертывания (частное облако - private cloud, общее облако - community cloud, публичное облако - public cloud, гибридное облако - hybrid cloud)

• пять основных характеристик (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service)

Иногда к классической модели добавляют варианты, например DaaS (Data as a service – Данные как сервис/услуга, когда обеспечивается предоставление данных по требованию пользователя), Caas (Communication as a service – Коммуникации как сервис/услуга, когда предоставляются услуги связи, чаще всего IP-телефония) и т.д.

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

1. Технологические и организационные проблемы:

• необходимость изменения классических (изученных, отработанных и проверенных) подходов к обеспечению безопасности;

• практически полное отсутствие соответствующих стандартов по безопасности (особенно в России);

• отсутствие методик оценки качества, оценки эффективности и оценки защищенности;

• недоработанные модели угроз и модели нарушителя;

• сложность оценки рисков;

• сложности в отслеживании причин нарушения безопасности;

• небезопасные программные интерфейсы (API);

• угроза завладения данными провайдером или его сотрудниками (инсайдерство) либо какой-либо третьей силой,

• отсутствие либо недостаток контроля над серверами и технологическими процессами;

• сомнения в корректности результатов облачных вычислений;

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

• специфические требования к идентификации и аутентификации;

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

2. Юридические проблемы:

• отсутствие стандартов и законодательных актов;

• размытая область ответственности из-за динамически изменяющейся инфраструктуры.

3. Антропогенные проблемы:

• психологические сложности из-за необходимости передачи данных сторонним компаниям;

• сложность оценки уровня доверия провайдеров;

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

• боязнь сокращений IT-персонала, что может привести к повышению риска инсайдерства.

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

1. Централизация ресурсов.

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

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

‒ Сохранение конфиденциальности шифра, или политика, основанная на параметрах шифрования (Privacy Preserving Cipher Policy Attribute-Based Encryption - PP-CP-ABE), что позволяет выполнять операции по кодированию и декодированию данных при передаче их к провайдеру облачных сервисов, не раскрывая содержания данных и используемых ключей безопасности. Сложность шифрования CP-ABE линейно возрастает от параметров политики доступа. Предлагаемая схема PP-CP-ABE построена схем разделения, которые, в частности, используются в механизмах электронного голосования.

‒ Cистема в качестве криптографического механизма контроля доступа (Attribute Based Data Storage - ABDS), которая позволяет минимизировать нагрузку на облачные сервисы: к каждому пользователю привязывается несколько параметров доступа и шифрования, а шифрующее устройство будет самостоятельно определять политику доступа к данным в соответствии с параметрами пользователя. Кроме того, система ABDS должна решать проблему выбора оптимального размера блоков данных, которые шифруются независимо, что облегчает задачу обновления зашифрованных данных.

Кроме того, при использовании стороннего хранилища данных, необходимо обеспечить возможность гарантированного удаления данных при необходимости.

4. Криптографическая защита каналов связи. Телекоммуникационная составляющая доступа к ресурсам центра обработки данных должна подвергаться обязательной защите. При этом возможны два варианта построения структуры: туннелирование трафика с помощью стандартных протоколов либо использование собственного варианта построения виртуальной частной сети с реализацией криптографической подсистемы на основе российских стандартов криптографической защиты данных, включая последние стандарты в области асимметричной и симметричной криптографии. Исследование показало, что при использовании стандартных протоколов связи наиболее эффективным и скоростным, что немаловажно при больших объемах данных, является протокол IPSec (при возможности его использования) – либо в чистом варианте, либо в комбинации с L2TP. В том случае, если использование IPSec невозможно, в качестве базового протокола защиты может быть использован SSL.

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

1) Данные шифруются на промежуточном слое PP-CP-ABE перед отправкой Поставщику облачных услуг (SSP); данные могут быть зашифрованы на стороне клиента, теоретически это является более защищенным вариантом, но устанавливает повышенные требования к клиентской системе, и ряд проведенных исследований показывают, что использование промежуточного слоя в целом не снижает общую защищенности системы при использовании клиентом базовых средств защиты каналов связи. Поставщик службы шифрования (ESP) обеспечивает шифрование, не имея доступа к клиентскому ключу шифрования данных (DEK), и передает результат SSP.

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing Internet Computing, September/October 2008 (vol. 12 no. 5), pp. 96-99 Carl Hewitt, Mas-sachusetts Institute of Technology. [Электронный ресурс]. - URL: http://www.computer.org/csdl/mags/ic/2008/05/mic2008050096-abs.html (дата обращения: 20.12.2015).

2. NIST Cloud Computing Program [Электронный ресурс] // National Institute of Standards and Technology [сайт]. URL: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf (дата обраще-ния: 20.12.2015).

3. NIST Референтная (эталонная) архитектура облачных вычислений (Cloud Computing Reference Architecture) Версия 1.0. [Электронный ресурс] // О Cloud Computing на русском [сайт]. URL: http://cloud.sorlik.ru/reference_architecture.html (дата обращения: 20.12.2015).

8

Код для цитирования: Скопировать