Безопасность публичных сред облачных вычислений в условиях функциональной неопределенности Текст научной статьи по специальности «Компьютерные и информационные науки»

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

Ключевые слова: публичные среды облачных вычислений, встроенные облачные механизмы безопасности, зарубежные модели обеспечения безопасности СОВ, NIST Special Publication 800-53 Revision 4, непрерывное управление безопасностью публичных СОВ.

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

Чемёркин Ю.С.,

yury.s@chemerkin.com

Введение

Публичная среда облачных вычислений (публичная СОВ, англ. public cloud) — инфраструктура, предназначенная для свободного использования широкой публикой, которая физически существует в юрисдикции владельца — поставщика услуг. Особенностью данной модели (развёртывания) СОВ является отсутствие возможности контроля функциональных возможностей СОВ при использовании сервисов СОВ с течением времени. Это возникает по причине того, что СОВ, как и любая ИС, не сохраняет своего изначального состояния в принципе; другими словами, в ней на постоянной основе появляются, как минимум, ресурсы, пользователи и сервисы, статус которых варьируется от новых до устаревших/неактивных. Серьёзным аспектом является постоянное изменение функциональных возможностей, происходящее на стороне поставщика услуг, которые представлены новым набором функционала, набором обновлений и т.п. [4].

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

Модель системы управления безопасностью сред СОВ

в рамках методологии NIST

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

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

Tier 1 Organization

Tier 2

Mission/Business Process

Tier 3 Informatiors System

Рис. 1. Трёхуровневый подход управления рисками

Каждый из трёх уровней решает свои задачи, связанные с организационной составляющей, в то время как Уровень 3 (Tier 3) предлагает следующую модель, целью которой является решение вопросов с проектированием, разработкой, внедрением, управлением и размещением СОВ в среде их целевого функционирования. Документ акцентируется только на шаге 2 - выборе. Как и подход, модель управления безопасностью в рамках NIST действует для всей серии документов

1. Классификация (категорирование) ИС (СОВ).

2. Выбор набора базовых требований обеспечения безопасности для классифицированной СОВ, и расширение этого набора насколько это требуется для поддержания определённого уровня безопасности.

3. Внедрение требований обеспечения безопасности.

4. Управление методами обеспечения безопасности для определения тех, которые внедрены корректно, функционируют с предопределённым результатом и с учётом требований безопасности к СОВ.

5. Запуск с приемлемым риском для организации.

6. Осуществление мониторинга требований обеспечения безопасности в СОВ и окружении на предмет эффектив-

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

Рис. 2. Модель управления безопасностью в рамках NIST

Данные шаги повторяются на постоянной основе, что рассматривается как постоянный мониторинг безопасности ИС. Необходимо отметить, что для шага 2 первоначально рассматриваются (как предварительный выбор) методы обеспечения безопасности, которые будут улучшены на 4 шаге, так как на шаге 4 (в случае первоначального запуска системы и конфигурирования с учётом предъявляемых требований к безопасности) происходит оценка слабых мест после применения предварительного набора методов обеспечения и корректировка.

Расширение NIST модели системы управления

безопасностью публичных сред СОВ

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

Для СОВ возможно отметить ряд присущих угрозам признаков:

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

• Непредсказуемость в определённом интервале времен и. Здесь понимается неопределенность состояния безопасности с течением времени, повышающаяся (изменяющаяся прямо пропорционально) с увеличением количества настроек, их объёма и т.п.

• Взаимосвязанность. Предполагает наличие признаков, в ряде случаев уникальных, которые определяют её природу и последствия; так, отсутствие должного разграничения доступа может привести даже к непреднамеренному

сбою в работе системы, ввиду ошибок конфигурации или других действий, связанных с модификацией ресурса

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

1. Functionality Management Approach - подход к управлению функциональными возможностями.

2. Cloud Security Management Approach - подход к управлению безопасностью.

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

Подход к управлению функциональными возможностями СОВ (Functionality Management Approach) подразумевает формирование требований к компонентам СОВ в соответствии с сервисо-зависимыми моделями безопасности. Очевидно, что реализаций решения задачи может существовать большое количество и стандарты могуг лишь конкретизировать определённые аспекты в этом случае. Этот подход решает задачу устранения причин возникновения нарушений безопасности, что возможно при формировании определённого состояния СОВ как набора параметров, удовлетворяющих требованиям в отношении СОВ, и выявления отклонения от этого набора, что представляет собой нарушение безопасности. Соответственно, анализ параметров позволяет выявлять нарушения, модификация параметров позволяет устранять их. На этом этапе стоит вопрос описания сервисозависимых моделей особенностей их применения [2].

Подход к управлению безопасностью СОВ (Cloud Security Management Approach) подразумевает управление безопасностью СОВ и автоматизацию поддержания безопасности СОВ в неопределённых условиях путём постоянной корректировки параметров (в том числе поиска оптимальных параметров). Иначе говоря, безопасное состояние необходимо поддерживать обязательно с учётом того факта, что, как и любая динамическая система, СОВ претерпевает изменения, изменяются характеристики окружения и функциональные возможности СОВ, и непосредственно механизмы безопасности. Этот факт подтверждает актуальность постоянного управления ИБ и автоматизации процесса анализа параметров, сопоставления с требованиями, реконфигурации и верификации действий и выходных значений с последующим получением результатов о текущем состоянии безопасности СОВ и изменениях окружения СОВ для дальнейшего решения о повторении процесса.

В рамках каждого из подходов формируется модель безопасности:

1. Функциональная модель ставит целью конкретизацию требований под определённый СОВ или наборы сервисов (каждый сервис) СОВ.

2. Модель управления безопасностью СОВ ставит целью управление функциональностью, требованиями и реализацией требований СОВ.

Конкретизация требований под определённый СОВ или наборы сервисов (каждый сервис) СОВ предполагает выбор необходимого набора гребований в рамках определённого

T-Comm #6-2014

S7

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

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

Неконтролнр

уемые

параметры

Устранение

нарушений

Функционал

ьные

возможности

СОВ

\

Выявление

нарушения

безопасности

Требования

беюпасностн

\

/

—ПГСТёШ— оценка СООТВЄТСІІВИЯ

уровня

Параметры

встроенных

механизмов

безопасности

механизмов безопасности каждой СОВ. Для разрешения вопросов необходимо выделить особенности применения требований в отношении СОВ:

• требования разделяются на применимые к сервису СОВ или неприменимые

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

• требования разделяются на базовые и расширенные

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

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

, _ЕГ=чЛ

(1)

-security определяется СООТНОШеНИ-

S?=,Ri

где уровень безопасности Ls,

Рис. 3. Итерации цикла управления безопасностью СОВ

Функциональная оценка уровня безопасности публичных СОВ

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

ем количества применённых требований t=o к общему

. .£*■ количеству требовании i=o .

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

п

AQ = YsRtNSRi

^ (2) где SR— коэффициент значимости i-ro требования, величина которого прямо пропорциональна степени влияния, оказываемого на СОВ, Nsm - нормированное значение /-го требования.

Выражение (1.2) необходимо уточнить с учётом выражения (1.1). Для этого введём уточняющий коэффициент FR = {0| 1}, принимающий два значения (0,1) соответственно, где 0 - индикатор невыполнения гребования, а 1 - наоборот. Также необходимо определить ещё один коэффициент NR = {0| 1}, принимающий два значения (0,1) соответственно, где 0 - индикатор отсутствия необходимости применения требования, а 1 - наоборот.

Таким образом выражение (1.2) в (1.1) с учётом уточняющих коэффициентов, можно переписать в виде ^ T,%0SR1NsrT|

£Г=о SRiNsitiNi (2)

где AQ - показатель выполнения набора требований, соответствующий уровню безопасности в рамках выбранных требований, a F) - показатель выполнения выбранных и применимых требований. Нормированное значение (Nsm) /-го требования определяется через соотношение значимости гребования к сумме значимостей всех требований SR{

(4)

Nsr. -

JYSR, - 1

(5)

Значимость требований (5/?/) можно определить исходя из приоритета ранга и веса экспертной оценки

SR

-Ш

+ ЕЕ,

(6)

где приоритет ранга PR, определяется по аналогии с документами NIST и представляет собой требования, которые применяются к ИС разного уровня критичности (PR = 2 — минимальная критичность, PR = 3 - средняя критичность, PR = 4 - высокая критичность, PR = 5 - экстра критичность (расширенные требования), PR = 1 — некритично (прочие требования)); Qi-r - количество приоритетов ранга (приоритета применения требования для критичных ИС); ЕЕ, - экспертная оценка.

Публикации NIST подразумевают базовые и расширенные требования. Таким образом можно определить показатель выполнения набора базовых требований AQи показатель выполнения набора расширенных требований AQcnhancab Показатель выполнения набора базовых требований AQhasic определяется аналогично выражению (3). Расширенное требование представляет собой составное требование, то есть множество требований; здесь каждое расширенное требование Rj имеет показатель выполнения AQc„i,a„cedу, который можно определить аналогично выражению (3)

ЕU,SR*NSRFk

AQcomposiu Y»='SRkNSRNk

AQc =

Y?='SRtHSRiFi

- • (,0) Так как требования определяются в группы, возможно вычислить показатель выполнения требований в группе, а также значимость группы. Значимость .96’, отдельно взятой группы требований определяется выражением

5"б/ — •

Ус*** +

где <2<;ьш1с - количество базовых требований в группе, Ясеп/юпт/ - количество расширенных требований в группе,

71

^=в - сумма значимостей всех базовых требований /?*, а

п.

к=о - сумма значимостей всех расширенных требова-

ний /?*. Нормированное значение (Ы$а) /-й группы определяется через соотношение значимости группы к сумме значимостей всех групп

л, = 5С.

■ ..........- (12)

Е

(7)

где /•* имеет тот же смысл, что и раньше. Тогда значимость SRJ отдельно взятого расширенного требования необходимо определить как

сп _Ег=.5дк

7 - Он

со тпропн (8)

где флсотрозНе ~ КОЛИЧеСТВО СОСТАВНЫХ требований /?*, форми-

п

рующих одно расширенное требование /?,, а к=в - сумма значимостей всех составных требований /?*, формирующих одно расширенное требование /?,.

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

Y!J=^SRjNSR.AQcomposittJ

А(}епЬапе"11 = (9)

где у (0, п) определяет наборы применённых требований, а к (0, т) определяет наборы применимых требований

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

LNs°i = 1

(13)

Если AQ = 0, то это может говорить о неприменимости ни одного требования (ошибка соотношения стандарта и технологии).

Модель управления безопасностью СОВ в рамках

подхода к управлению безопасностью «Cloud Security

Management Approach»

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

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

Таблица 1

Этапы модели управления безопасностью СОВ

)гаиы оригинальной модели Этапы рассматриваемой МОДе. III Рассматриваемые подходы

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

2. Классификация (категорирова-ние) СОВ по функциональности 1. Подход к управлению нормативной базой.

1. Определение типа СОВ 3. Выбор модели (типа) СОВ исходя из требуемой функциональности 1. Подход к управлению нормативной базой.

2. Выбор модели СОВ 3. Выбор модели (типа) СОВ исходя из требуемой функциональности

3. Выбор уровней СОВ

Этапы оригинальной модели Этапы рассматриваемой модели Рассматриваемые подходы

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

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

5. Применение мер 6. Внедрение требований обеспечения 2. Подход к управлению функциональными возможностями СОВ

6. Оценка мер 7. Оценка выбранных требований. 2. Подход к управлению функциональными возможностями СОВ

8. Реализация требований обеспечения безопасности посредством 1АМ 3. Подход к управлению конфигурацией 1АМ СОВ '

9. Реализация через конфигурирование и управление политиками

10. Оценка методов и механизмов, посредством которых осуществляется реализация требований 3. Подход к управлению конфигурацией 1АМ СОВ

11. Запуск ИС (СОВ) с приемлемым риском для организации 4. Подход к управлению безопасностью СОВ

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

Заключение

В ходе данной работы были решены следующие поставленные задачи:

- разработаны модели безопасности СОВ и её составляющих, отражающие конфшурацию компонентов и позволяющие сформировать набор параметров для реализации предъявляемых к СОВ требований безопасности, в том числе нормативных;

— разработан инструментарий, который включает показатели значимости требований, сформированных на основе

ранжирования требований в рамках методологии NIST, которая была расширена и скорректирована набором экспертных оценок, сформированных на основе проведённого анализа угроз в отношении различных СОВ, что может быть при необходимости скорректировано дополнительно;

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

На основании полученных результатов были сделаны следующие выводы:

- об отсутствии в зарубежных стандартах конкретных предложений по применению требований в отношении тех или иных сервисов публичных СОВ;

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

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

1. Y. Chemerkin, “Security compliance challenges on clouds”, Proceedings of the Fifth International Conference on Internet Technologies and Applications (ITA 13).

2. “Requirements: RANK, EVALUATION & SIGNIFICANCE”, [Электронный ресурс], http://sto-strategy.eom/compliance/20l4/3/19/ requirements-rank-evaluation-significance.

3. Y. Chemerkin, “Increasing Security Guidelines’ Framework Efficiency”, International Journal for Information Security Research (IJISR), Volume 3 Issues 1/2, ISSN 2042-4639.

4. Y. Chemerkin, “AWS Cloud Security from the point of view of the Compliance”, PenTest Magazine, Software Press Sp. z o.o. Sp. Ko-mandytowa Warszawa, vol. 2 №10 Issue 10/2012 (12) ISSN 2084-1116, pp. 50-59.

5. Y. Chemerkin, "Limitations of Security Standards Against Public Clouds”, Proceedings of the International Conference on Information Society (i-Society 2013).

Литература

Security for public cloud computing in terms of functional uncertainty Chemerkin Yu.S., yury.s@chemerkin.com

Abstract

PSB is the next stage in the development of technologies with application virtualization and the use of distributed computing. Obviously, progress in the field of information security is possible with constant improvement and effective study of the requirements to achieve and maintain security. Since today to PSB new requirements for information security, they [PSB] already have built-in security mechanisms, which may be regaided as devoid of known deficiencies implementation. Approaches to monitor and ensure the security of uncertain functionality as a set of insufficient data about the environment of the SOC and decision support for emerging situations. In other words, the solution will allow comply with the main document notation of defining security guarantees PSB performed by continuously maintaining the requirements for information security by controlling the parameters of the components of PSB services depending on emerging impacts occurring and situations.

Keywords: public cloud computing, cloud security mechanisms built, foreign security model SOC, NIST Special Publication 800-53 Revision 4, continuous management of public security PSB.