Оценка эффективности встроенных механизмов безопасности публичных сред облачных вычислений в рамках сервиса identity and access Management Текст научной статьи по специальности «Компьютерные и информационные науки»

Оценка эффективности встроенных механизмов безопасности публичных сред облачных вычислений в рамках сервиса identity and access management

На основании подходов, изложенных в стандартах, и предъявляемых требований со стороны рынка, поставщики СОВ предлагают модели управления доступом, реализованные в своих продуктах — системах (Identily and Access Management) IAM. Эффективное управление IAM позволяет гарантировать поддержание выполняемых требований к ИБ, что возможно посредством управления параметрами (политики безопасности) и структурой (консоли и инструменты доступа) компонентов различных сервисов IAM в зависимости от возникающих воздействий и происходящих ситуаций. Рассмотрены методы позволяющие выявлять относящиеся к состоянию компонентов IAM и IAM в целом, связанные с неэффективным выполнением функций со сторо-Ключевые слова: публичные среды облачных ны IAM слабые места, методы позволяющие выполнять количественную оценку состояния

вычислений, встроенные механизмы безопасности, безопасности СОВ, дать оценку степени критичности возникающей ситуации риска и опреде-IAM, Identily and Access Management. лить эффективность используемых средств безопасности.

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

аспирант РГГУ, [email protected]

Введение

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

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

• Управление общими ресурсами для совместных проектов.

• Разрешения основанных на группах аккаунтов (реализация RBAC для разделения прав доступа пользователей с позиции их должностных обязанностей).

• Управление сетевыми параметрами (позволяют определить периметр доступа к ресурсам).

• Управление межаккаунтным доступом (аналог междоменного управления).

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

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

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

Управление правилами, составляющими

политики безопасности, в рамках IAM

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

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

■ Цели (атак) - представляют собой набор ресурсов СОВ, которые являются целью атаки и получения доступа. Ресурсы могут разделяться па несколько групп:

о Внутренние ресурсы - ресурсы непосредственно на целевом объекте

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

о Учётные данные - «ресурсы» позволяющие опосредованно получать доступ к соответствующему набору ресурсов

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

• APIs (API-методы) - «ресурсы», которые доступны разработчикам для выполнения различных активностей, создания файла, отправки сообщений и т.п.

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

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

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

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

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

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

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

Д=АиБиГиГг где Л - полный набор разрешений; А - набор контролируемых субъектом разрешений, и А с В . g _ 1!аб0р контроля-

руемых централизованно разрешений, и А <= ® ; Г - набор недостающих разрешений (на отдельные АР1-методы);

^ - набор требований нормативных документов ^ с А При этом Н = Е + 2

1

где Н - полный набор ЛР1-методов; Е - набор АР1-методов,

взаимодействующих с защищаемой информацией, Е^АиВ ■ Z— набор АР1-методов, взаимодействующих с защищаемой информацией.

Рис. 1. Модель безопасности, представляющая взаимосвязь внутренних и внешних механизмов

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

Следует заметить, что в случае достаточной детализации множество Г должно представлять собой пустое множество,

чтобы было выполнимо выражение Е э А и В а >!е рассмотренное ранее выражение Е з А и В Таким образом, важной характеристикой является мощность множества Г и насколько эта величина минимальна. С другой стороны, не менее важной характеристикой также является представленная выражениями V ^ А функция-индикатор степени проработки нормативных требований в случае конкретной СОВ.

Конфигурационная (параметрическая) оценка

уровня безопасности СОВ

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

Существующие API-функции разделяются на API-функции в отношении которых действуют разрешения (Permissions) и наоборот; здесь подразумевается, что существует набор критичных API-функций (как, например, в случае MDM - доступ к звонкам) и некритичных функций (как, например, доступ к графическим объектам пользовательского интерфейса) [2-31. Также важным момент является API-функция создающая новую сущность (new Instance), так как в отношении неё также определяется разрешение; такие виды разрешение в ряде случаев могут быть единственными Определяющими доступ к группе API-функций, например, тип СОВ SaaS, в рамках которого развёрнуто решение типа MDM, может контролировать доступ к звонкам телефона посредством разрешения, выраженного как разрешение/запрещение доступа к аналогичной функциональной возможности без детализации действий (совершить звонок, сбросить вызов и т.п.). API-функции и разрешения могут включаться в группы API-функций и разрешений

-Ъ

API = > API.

'permission

. +

^^ APIpermission-frmmj

(1)

API

где î—о

ptfrmijjiorif

- набор АР1-функций, в отношении кото-

п

^Г А Р1

рых действуют разрешения, ¡=» - набор АР1-

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

п

А Р д ГО— р — у А Р11

Ы (2)

где АР1, — АР1-функция, включённая в группу АР1-функций по определённому признаку

PermissiongrlKip = Permission t

(3)

где Per mis Hon i - разрешение, включённое в группу разрешений по определённому признаку.

Аналогично можно составить выражения для сервисов, содержащих группы API-функций и разрешений

п

API ■ = Т API

А service /

(4)

где APIxi — группа API-функций, включённых в сервис по определённому признаку

Permission,

Permission.

(5)

где PermisLÎongi - группа разрешений, включённых в сервис по определённому признаку

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

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

API (6)

Степень покрытия разрешениями API-функций может быть выражено через проверку всех индикаторов разрешений в отношении соответствующим им API-функциям, Permissions^

(V)

I =

AQn=-

YÏ=BAPI i

где API, - i-я API-функция, в отношении которой (не-) выполняется ;-е разрешение Permisiions;.

Соотношение имеет три возможных значения, что подтверждается практически [4-6]

AQn = 1 (8)

физический смысл которого заключается в факте покрытия отдельно взятым (-М разрешением отдельно взятой ;-й API-функции на множестве выбранных п API-функций и разрешений

AQ„ > 1 (9)

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

AQn< 1 (10)

физический смысл которого заключается в факте отсутствия покрытия отдельно взятым 1-м разрешением отдельно взятой i-й API-функции на множестве выбранных п API-функций и разрешений.

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

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

о ^ р в rmissi ons^ "security № n

¿■-0 л permissibly (11)

где уровень безопасности определяется соотношени-

ях

Та

/j ^permissions^

ем количества применённых разрешений ¿=о к

п

Тд

общему количеству разрешений ;=в

Разрешения могут быть включены в группы, которые, в-свою очередь - в наборы групп по отношению к сервису. Они также могут разделяться на применимые к СОВ и наоборот. Тогда с учётом выражения (1.11) показатель

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

где Л£> - показатель выполнения набора разрешений, соответствующий в уровню безопасности в рамках выбранных разрешений, ЛР1-, - показатель необходимости применения разрешения (или показатель наличия активной ЛР1-фунщии), а — показатель выполнения выбранных и применимых разрешений, 5Р, — коэффициент значимости г-го разрешения, величина которого прямо пропорциональна степени влияния, оказываемого на СОВ, - нормированное значение /-го разрешения. Нормированное значение (Щ) 1-го разрешения определяется через соотношение значимости разрешения к сумме значимостей всех разрешений 5Я

п

к (И)

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

Если разрешение имеет зависимости, то показатель выполнения отдельного разрешения может быть переопределён как Я°БР> (15)

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

Оценка уровня риска СОВ

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

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

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

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

(16)

Тогда показатель невыполнения требований безопасно-

сти можно определить как AQN = 1~AQ

(17)

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

=5>,

, как

Г ГС (18) где «i - í-й показатель невыполнения мер безопасности при реализации ¿-го параметра (например. Атаки), a SA¡ и показатели значимости С, параметра и его нормирование значение.

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

«=П, (18а)

где L- ущерб при невыполнении набора требований безопасности при реализации набора атаки.

Исходя из этого выражения, риск до внедрения средств защиты можно оценить выражением

КяА —

REQi

xL

(19)

где " — ¡-и показатель невыполнения требований безопасности.

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

«л = и(аи х *->) (20)

где

До-

определяется выражением

^oSA¡NsaAQn\

ЕГ=о SA,NMt

х£

(21)

где ^(¿Нр^х — ]-У1 показатель невыполнения разрешений безопасности

Предполагается, что одно требование Дц^д. может быть

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

Якл (22) где /' (0, п) определяет наборы примененных разрешений, а к {0, т) определяет наборы применимых разрешений.

Таким образом, коэффициент эффективности внедрённых средств защиты в рамках данного набора требований определяется выражением для встроенных средств зашиты (разрешений) в сравнении с прогнозируемой оценкой после внедрения требований

„ _ Фрейм

р* ~ лдто (23)

где АОмд — показатель выполнения после внедрения требований (прогнозируемая оценка), АОрг^м - показатель выполнения после реализации (внедрения разрешений) требований (фактическая оценка).

] 1ри изменении набора требований также можно оценить эффективность внедряемых мер в отношении изменившихся требований

г- .

(24)

где ЯКВд - риск после внедрения старого набора требований (прогнозируемая оценка), - риск внедрения нового набора требований (прогнозируемая оценка).

При изменении набора разрешений также можно оценить эффективность внедряемых мер в отношении изменившихся разрешений

Р _ 1 КрЕЕМпы

ЬР = 1 - -5-

(25)

где Ч - риск после внедрения старого набора разре-

шений (фактическая оценка), Дрвкмт. - риск внедрения нового набора разрешений (фактическая оценка)

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

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

Заключение

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

- формализована модель безопасности сервиса СОВ - 1ЛМ;

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

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

Литература

1. "NIST Guide for Conducting Risk Assessments. SP 800-30 Rev. I", [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/ р ubl ie at i о n s/n is tpu bs/800-30- re v 1 /sp800_30_rl.pdf (дата обращения 10.12.2013).

2. Chemerkin Y., "Mobile Security Challenges on Compliance", CTICon-2013(11) - International Conference on «Exploring Global Transformations in Technology & Management», Октябрь 2013.

3. Chemerkin Y., "Mobile Security from the BYOD's Viewpoint", CTICon-2013(11) - International Conference on «Exploring Global Transformations in Technology & Management», Октябрь 2013.

4. Chemerkin )'. "Insecurity of Blackberry Solutions: Vulnerability on The Edge of The Technologies", [Электронный ресурс]. Режим доступа: http://itsec.ru/arlicles2/mobtle-security/bezopasnosl-blackberryreshenii-yyazvimosti-na-stike-tehnologii/ (дата обращения 03.01.2012).

5. Chemerkin Y., "When Developer's API Simplify User-Mode ¡toolkits Developing," Hakin9 Mobile Magazine, Software Press Sp. z o.o. Sp. Komandytowa 02-682 Waiszawa, vol. 2 №2 Issue 02/2012 (3) ISSN 1733-7186, pp. 16-21, Февраль 2012,

6. Chemerkin Y., "When Developers API Simplify User-Mode Rootkits Development - Part 11," Hakin9 OnDemand Magazine, Software Press Sp. z o.o. Sp. Komandytowa 02-682 Warszawa, vol. I №4 Issue 04/2012 (4) ISSN 1733-7186, pp.56-81, Июль 2012.

Estimate of efficiency of native public cloud security toolkit within scope of identity and access management

Yury S. Chemerkin, [email protected]

Abstract

Different control models are based on standard publications and best practices, they depend on various cloud features represented by Identity and Access Management (IAM). Examination of IAM capabilities assures in maintaining chosen cloud security strategy to react incipient issues and insecurities.This research examines methods developed to reveal weak state of IAM components as well as mistakes made during its configuration. These methods help to find out vast amounts of IAM solutions as a significant part of cloud, quantitatively evaluate and estimate effectiveness of native solutions (IAM toolkit) against available activities and functionality; evaluate how critical the emerging risk is.

Keywords: public clouds, internal cloud security toolkit, IAM, Identity and Access Management.