Содержание к диссертации
Введение
ГЛАВА 1. Актуальные задачи управления безопасностью облачных сред 17
1.1. Задачи обеспечения защищённости облачных сред 17
1.2. Нарушения безопасности в облачных средах 19
1.3. Архитектура системы безопасности облачных сред и ключевое место системы управления доступом ОСУД в ней
1.3.1. Средства и механизмы распределённого хранения данных 24
1.3.2. Средства и механизмы идентификации и аутентификации 25
1.3.3. Средства и механизмы шифрования данных 27
1.3.4. Средства и механизмы управления правами доступа (разрешениями) и политиками доступа ОСУД 27
1.3.5. Средства и механизмы мониторинга (регистрации) событий 28
1.4. Меры обеспечения информационной безопасности 29
1.4.1. Управление безопасностью облачных сред в рамках существующих нормативных документов (стандартов) 29
1.4.2. Основные задачи разработки политик управления доступом для облачных сред
1.5. Постановка задачи управления безопасностью облачными средами 34
1.6. Выводы по главе 38
ГЛАВА 2. Разработка подходов и моделей управления безопасностью облачных сред 39
2.1. Особенности нормативной базы облачных сред 39
2.1.1. Понятия стандартов и подход к обеспечению безопасности 39
2.1.2. Структура требований безопасности существующих нормативных документов 43
2.1.3. Формирование требований безопасности существующих нормативных документов 48
2.1.4. Взаимосвязь с другими стандартами
2.2. Разработка способа комплексирования подходов управления безопасностью облачными средами 51
2.3. Разработка моделей управления безопасности облачными средами
2.3.1. Разработка нормативной модели безопасности облачных сред 54
2.3.2. Построение сервисо-зависимых моделей безопасности облачных сред 57
2.3.3. Разработка конфигурационной модели безопасности ОСУД
2.4. Разработка обобщённой модели управления безопасностью облачных сред 76
2.5. Выводы по главе 79
ГЛАВА 3. Методы оценки выполнения мер безопасности и эффективности их реализации 81
3.1. Методология осуществления контроля и управления облачной системой управления доступом 81
3.2. Оценка уровня защищённости на основе модели комплекса механизмов защиты
3.2.1. Общий подход к оценке уровня защищённости СОВ 85
3.2.2. Выбор нормативного документа в рамках функционального подхода 86
3.2.3. Оценка уровня защищённости в рамках нормативного подхода 89
3.2.4. Оценка уровня защищённости в рамках конфигурационного подхода
3.3. Оценка сложности приведения облачных сред к приемлемому уровню защищённости 103
3.4. Метод выявления нарушений безопасности облачных сред
3.4.1. Методы оценки эффективности реализации мер и оценка уровня риска 112
3.4.2. Семантические оценки уровня риска 115
3.4.3. Алгоритм проверки выполнения мер безопасности и принятия решений о пересмотре состава мер безопасности в отношении облачных сред 117
3.5. Выводы по главе 120
ГЛАВА 4. Методики проверки выполнения мер безопасности облачных сред 125
4.1. Описание методик проверки выполнения мер безопасности 125
4.1.1. Методика проверки выполнения мер безопасности в рамках начальной конфигурации параметров СОВ 125
4.1.2. Методика проверки выполнения мер безопасности в рамках новых функциональных возможностей СОВ 128
4.1.3. Методика проверки выполнения мер безопасности в рамках новых требований, предъявляемых к СОВ 130
4.1.4. Методика проверки выполнения мер безопасностив рамках реконфигурации параметров безопасности (разрешений), отвечающих предъявляемым к СОВ требованиям 131
4.2. Примеры применения методик проверки выполнения требований 132
4.2.1. Отличительные особенности ОСУД в IaaS модели СОВ на примере Amazon Web Services (AWS) 133
4.2.2. Пример применения методики проверки выполнения мер безопасности на базе IaaS модели СОВ AWS (Amazon Web Services) 134
4.2.3. Отличительные особенности ОСУД в PaaS модели СОВ на примере Azure (Microsoft Azure) 140
4.2.4. Пример применения методики проверки выполнения мер безопасности на базе PaaS модели СОВ Azure (Microsoft Azure) 141
4.2.5. Отличительные особенности ОСУД в SaaS модели СОВ на примере BES (BlackBerry Enterprise Server) 144
4.2.6. Пример применения методики проверки выполнения мер безопасности на базе SaaS модели СОВ BES (BlackBerry Enterprise Server) 145
4.3. Результаты внедрения диссертационной работы 155
4.3.1. Результаты внедрения в ЗАО «Перспективный Мониторинг» 156
4.3.2. Результаты внедрения в ООО «Сертифицированные Информационные Системы» 161
4.3.3. Результаты внедрения в ФГУП «ЦентрИнформ» 162
4.4. Выводы по главе 163
Заключение 165
Список использованной литературы 167
Приложения
- Архитектура системы безопасности облачных сред и ключевое место системы управления доступом ОСУД в ней
- Формирование требований безопасности существующих нормативных документов
- Оценка уровня защищённости на основе модели комплекса механизмов защиты
- Методика проверки выполнения мер безопасностив рамках реконфигурации параметров безопасности (разрешений), отвечающих предъявляемым к СОВ требованиям
Архитектура системы безопасности облачных сред и ключевое место системы управления доступом ОСУД в ней
Резюмируя, можно отметить, что это позволит добиться наилучших показателей в рамках управления безопасностью СОВ, так как корректное управление параметрами ОСУД будет осуществляться на уровне наиболее близком к гипервизору (ядру) СОВ. Расширяемость и управляемость сервиса ОСУД позволит разрабатывать облако-ориентированные решения по безопасности. Также из эксплуатации будут исключены классические СЗИ, применимые с ограничениями, убрав которые, можно будет использовать решения, обеспечивающие недостающую функциональность первых, например, применение HIPS-решений вместо AV-решений вкупе с корректной конфигурацией ОСУД. А управление безопасностью ОСУД на всём жизненном цикле позволяет следовать нотации стандартов о постоянном и непрерывном обеспечении защищённости СОВ.
Защищённость отдельных взятых сервисов СОВ связана с ОСУД, поэтому целесообразно рассмотреть архитектуру последнего (в подглаве вместо ОСУД используется зарубежный термин IAM). Облачная система управления доступом IAM представляет собой набор технологий и механизмов, позволяющим управлять учетными записями, ресурсами в отношении всех сервисов, предоставляемых СОВ. IAM в СОВ представляет собой централизованный сервис, имеющий консольный, веб или иной тип интерфейса, который позволяет управлять политиками безопасности, пользователями и их разрешениями, а также ключами доступа в той или иной СОВ. Однако ряд СОВ, чаще PaaS типа, не поддерживает7 управление количеством пользователей больше одного и требует передачи прав и разрешений одного и того же аккаунта. Также IAM позволяет управлять конечными устройствами, известыми в терминологии зарубежных стандартов как мобильные устройства. Очевидно,
7 Следует иметь ввиду, что такой тип СОВ направлен не на конечных пользователей, а на разработчиков. Здесь один аккаунт используется для размещения программных приложений, функционирующих в рамках этого типа СОВ, внутри которых действует иное разделение прав и пользователей. что на данный момент используются не только стационарные компьютеры, но и мобильные устройства. Класс решений, непосредственно позволяющий управлять мобильными устройствами известен как корпоративное управление мобильными устройствами (EMM), которые также входят в СОВ.
Механизм распределённого хранения данных используется в рамках СОВ в вариантах локального распределения данных и регионального распределения данных. Локальное подразумевает собой распределение внутри одного региона в автоматическом режиме. Региональное никогда не выполняется в автоматическом режиме и требует ручного переноса либо автоматизации процесса. Регион может варьироваться как понятие от вендора к вендору, но типовые варианты — это страна или страна и город. Средства обеспечения целостности для СОВ на данный момент применимы в масштабах выполняемых задач самими ядром и не выносятся на управляемый (прикладной) уровень. Так, например, наиболее полно реализованные механизмы могут включать функции обеспечения целостности ядра виртуальной ОС или хранимого образа виртуальной ОС. Для виртуальной ОС механизмы целостности управляются изнутри самой ОС, либо посредством расширения другими сервисами СОВ или сторонними решениями. Так, использование HIPS решений или механизмов контроля целостности программ, пользовательских файлов, списка разрешённых или запрещённых к запуску программ и процессов.
Cервис ОСУД любого вендора СОВ всегда обладает минимальным набором средств защиты в виде определённого списка учетных записей (аккаунтов), согласно которому организовано разграничение доступа. Очевидно, что конфигурация по умолчанию включает как минимум одну учётную запись администратора или суперпользователя8, если выражаться в привычных терминах. В действительности как таковых пользователей, разделённых по типу пользователя (привилегированный, обычный, суперпользователь и т.п.) не существует; существуют типы доступа. Отдельно стоит выделить аккаунт «Владелец», являющийся аналогом суперпользователя, то есть которому доступны все сервисы СОВ по умолчанию, а также с которым создаётся аккаунт в AWS после первоначального этапа регистрации. Такой аккаунт необходим для дальнейшей конфигурации остальных аккаунтов (пользователей), в то время как любой другой аккаунт с правами, аналогичными правам аккаунта типа «Владелец», может изменить права для этого типа аккаунта. Такому аккаунту доступны все сервисы, включая биллинговый сервис, в связи с чем рекомендуется ограничивать его права на доступ к остальным сервисам с целью предотвращения кражи его пароля. Все остальные типы аккаунтов считаются пользовательскими и могут обладать любыми правами доступа.
Формирование требований безопасности существующих нормативных документов
В рамках проанализированных моделей обработки правил и разрешений СОВ далее в подглаве формализуется общая модель. Логическая модель обработки правил и разрешений, предполагает выполнение обработки нескольких групп условий: базовая логика, контекстная логика, логика явного и неявного разрешения. Базовая логика включает в себя определение факта анонимной авторизации, то есть публичный доступ, и факта пользовательской авторизации, то есть на уровне владельца аккаунта и пользователей аккаунта. Контекстная логика включает блоки условий, состоящие из субъекта, окружения (даты и времени), и ресурсов, к которым осуществляется доступ. Логика явного и неявного разрешения определяет факт доступа (разрешено или запрещено) и включает следующие этапы-правила
По умолчанию всё запрещено (на уровне пользователя аккаунта, самих аккаунтов по отношению друг к друг, и сервису по отношению друг к другу, но не набора действий владельца аккаунта) Явное разрешение отменяет действие по умолчанию Явное запрещение отменяет любое разрешение
Представленная ниже (Рисунок 6) логика работы определяет конечное решение (вердикт) по следующему алгоритму: 1. Изначальное решение - запрещено (запрещение доступа) 2. Обработка всех политик в отношении пользователя и ресурса 3. Поиск явного запрещения, которое, будучи найденным, является финальным решением с вердиктом запрещено. Если такое не найдено, выполняется следующий шаг 4. Поиска явного разрешения по аналогии с предыдущим шагом. Если такое не найдено, выполняется следующий шаг 5. Финальное решение - запрещение доступа
Графическое представление логики управления политиками безопасности Исключение из этой модели составляют СОВ типа SaaS, где обычно работает связка следующих правил: 1. Отдельное запрещение сильнее отдельного разрешения 2. Групповое запрещение сильнее отдельных разрешений 3. Состояние по умолчанию зафиксировано в документации либо в комментариях к параметру «default» в консоли управления сервисом и представлено разрешением или запрещением. 2.3.3.3. Управление правилами, составляющими политики безопасности, в рамках ОСУД Правило политики безопасности ОСУД - правило, задаваемое в отношении ресурсов СОВ при осуществлении доступа к ресурсам СОВ. Описание происходит в соответствии со структурой политики безопасности. В предыдущей главе были описаны проблемы управления политиками безопасности СОВ и выбрана наиболее актуальная из них, связанная с прозрачностью или детализацией доступа. Рассмотрим следующую модель (Рисунок 7) прикладного уровня безопасности СОВ. Модель учитывает разрешения, функциональность СОВ, а также атаки, направленные на противодействие механизмам безопасности (Permissions, Разрешения). Соответствующая модель атак представлена ниже (Рисунок 8).
Цели (атак) - представляют собой набор ресурсов СОВ, которые являются целью атаки и получения доступа. Ресурсы могут разделять на несколько групп; Набор атак - множество методов, выполняемых для совершения различного рода активностей, связанных с угрозами; APIs (API-методы) - «ресурсы», которые доступны разработчикам для выполнения различных активностей (создания файла, отправки сообщений и т.п.); Механизмы безопасности СОВ - набор механизмов, представляющий собой несколько различных групп; Сторонние решения (AV, Firewall, VPN, и прочие другие) -представляют дополнительные инструменты и решения безопасности СОВ, используемые в случае функциональной недостаточности встроенных механизмов защиты;
Требования (нормативные) - наборы правил, которые должны быть реализованы посредством встроенных или сторонних решений в соответствии с тем или иным стандартом, практиками или законодательными требованиями.
Ресурсы могут подразделяться на несколько групп: o Внутренние ресурсы – ресурсы непосредственно на целевом объекте o Внешние ресурсы – ресурсы, непосредственно к которым возможен доступ посредством целевого объекта, ввиду наличия у него разрешений o Учётные данные – «ресурсы», позволяющие опосредованно получать доступ к соответствующему набору ресурсов Механизмы безопасности СОВ представляют собой несколько различных групп o Защита на уровне ядра/гипервизора – представляет собой ключевые механизмы безопасности, управляющие остальными процессами в системе; обычно являются недоступными для приложений o Набор недоступных для приложения механизмов безопасности – это определённый набор настроек, управление которыми невозможно через API приложений, но возможно через отдельные интерфейсы для пользователей или администраторов o Разрешения – наборы механизмов безопасности, которые явно определены для регулирования активностей, порождаемых вызовами API-методов и могут управляться пользователем или централизованно. Успешность выполнения векторов из рассмотренного набора атак открывает доступ к различным данным вплоть до системных. Ключевой аспект проблемы – это программные «прокси-решения» (например, обозреватели файлов), осуществляющие доступ к данным, не имеющие должной детализации прав доступа. Это усугубляется требованиями без специфики СОВ, ввиду чего, требования формально выполнены провайдером СОВ, но в действительности СОВ имеют различную функциональность и реализацию функциональности.
Оценка уровня защищённости на основе модели комплекса механизмов защиты
Сложность конфигурирования параметров безопасности при выполнении доступа к нескольким объектам пользователями со стороны групп где n - количество разрешений необходимых для конфигурирования нескольких объектов, - количество объектов, а - количество групп. Сложность конфигурирования параметров безопасности при выполнении уникального (дополняющего доступа со стороны группы) доступа к нескольким объектам пользователями со стороны пользователей, состоящих в группах где (m - n) - количество уникальных разрешений необходимых для конфигурирования в отношении нескольких объектов, - количество объектов, а - количество пользователей, состоящих в группах.
Общее выражение для конфигурирования параметров безопасности при выполнении доступа со стороны групп, состоящих в группах пользователей и несостоящих в группах пользователей
Как было отмечено ранее, при конфигурации параметров безопасности в отношении приложений, может не использоваться понятие ресурса-объекта, к которому осуществляется доступ. Тогда можно обозначить сложность конфигурирования при выполнении программного доступа в рамках общей политики безопасности для любого приложения где п - количество общесистемных разрешений, подлежащих конфигурированию для любого приложения Сложность конфигурирования при выполнении программного доступа в рамках частной политики безопасности для одного приложения где n - количество частных разрешений, подлежащих конфигурированию для одного приложения Сложность конфигурирования при выполнении программного доступа в рамках частной политики безопасности для нескольких приложений где п - количество частных разрешений, подлежащих конфигурированию для одного приложения, а - количество приложений, для которых необходимо выполнить конфигурирование параметров безопасности
Общее выражение для конфигурирования параметров безопасности при выполнении доступа со стороны приложений в рамках общей и частной политик безопасности для приложений
В случае если приложение осуществляет доступ к ресурсам-объекта, выражения (3.65) и (3.67) необходимо уточнить: Сложность конфигурирования при выполнении программного доступа в рамках общей политики безопасности для любого приложения к нескольким объектам где п - количество общесистемных разрешений, подлежащих конфигурированию для любого приложения, - количество объектов Сложность конфигурирования при выполнении программного доступа в рамках частной политики безопасности для нескольких приложений где n - количество частных разрешений, подлежащих конфигурированию для одного приложения, - количество объектов, а - количество приложений, для которых необходимо выполнить конфигурирование параметров
Общее выражение для конфигурирования параметров безопасности при выполнении доступа со стороны приложений в рамках общей и частной политик безопасности для приложений при доступе к объектам
Общее выражение для конфигурирования параметров безопасности при выполнении доступа со стороны приложений в рамках общей и частной политик безопасности для приложений при доступе к объектам и за его отсутствием
Применяя полученные выражения (3.64) и (3.72) стоит заметить, что выражения оценки сложности определены в зависимости от набора разрешений и требований. Этот набор уже является оптимизированным, за исключением случая, когда необходимо сконфигурировать все параметры безопасности. Стоит заметить, что последний случай не является индикатором выполнения всех требований, так как, часть требований может быть не применима.
Значимость выбора мер для конфигурирования в первую очередь может определяться через выражения (3.46), (3.48), (3.50), (3.51), (3.56), (3.57), при этом предполагается, что коэффициенты неравнозначны, и для них требуется выполнить нормирование. Для этого можно рассмотреть аддитивную функцию
Каждый из методов обладает своими особенностями (Таблица 12). Общим критерием для оптимизации в большинстве случаев является минимизация выполняемых действий при конфигурации разрешений (правил доступа). При этом выполнять оптимизацию необходимо как минимум для различных сервисов. Разработанные методы позволяют выполнять выбор оптимального варианта реконфигурации мер с учётом сложности конфигурации. Здесь наиболее применим метод весовых коэффициентов, что позволяет свести задачу выбора от многокритериальной к однокритериальной. Недостаток сложности назначения весов устраним: вес коэффициентов складывается из частных весов мер. Для решения многокритериальной задачи критерии определяются следующим образом. Область допустимых значений представлена сложностью конфигурации мер безопасности, а область определения - правами доступа. Задача представляет собой векторную систему критериев-функций и их значений как набор векторов min{q(x) = Q}, или после свёртки в супер-критерий С(х) = TXkiCi, где і Є [l,n], ct - сложность конфигурации мер, рассмотренная в данной главе, кь - приоритет конфигурации мер и представляет собой общий вес выбранных мер.
Сложность реконфигурации параметров безопасности зависит количества изменившихся функциональных возможностей, требований, связанных с ними, а также разрешений, необходимых для реализации этих требований. Сложность реконфигурации отражает среднее количество параметров на изменение одного субъекта, объекта, приложения или группы. Также сложность реконфигурации отражает среднее количество параметров на изменение функциональных возможностей и/или набора нормативных требований.
Методика проверки выполнения мер безопасностив рамках реконфигурации параметров безопасности (разрешений), отвечающих предъявляемым к СОВ требованиям
Ниже приведена информация о внедрении результатов теоретического и практического характера, полученных в рамках диссертационной работы в виде:
Модели управления безопасностью публичных СОВ и методики оценки защищённости СОВ и оценки эффективности реализованных мер безопасности, реализованной во внутренних проектах ЗАО «Перспективный Мониторинг». В основу эскизных проектов программного обеспечения класса «Security Awareness», «Decision Support System» легли разработанные методы оценки уровня защищённости и алгоритм принятия решений;
Рекомендаций по выбору вариантов конфигурации мер безопасности при использовании различных публичных облачных сред, внедрённых для выполнения ряда работ во внутренних проектах ООО «Сертифицированные Информационные Системы». Эти результаты, а также разработанные методики проверки выполнения мер безопасности были использованы для разработки методики проведения анализа безопасности публичных облачных сред в рамках рассмотренных существующих нормативных документов и вендорных решений публичных облачных сред;
Подходов к управлению безопасностью СОВ, разработанных и внедрённых для применения в проектах ФГУП «ЦентрИнформ» в виде программного комплекса, управляющего применением средств защиты корпоративной облачной среды. Разработанные методы количественной оценки выполнения мер безопасности были внедрены при реализации в качестве модулей системы мониторинга СОВ.
Результаты внедрения в ЗАО «Перспективный Мониторинг» методы к управлению безопасностью и оценке выполнения мер безопасности и оценки их эффективности были внедрены в ЗАО «Перспективный Мониторинг». При выполнении проектов как внутренних, так и внешних в рамках аудиторских работ требуется разрабатывать для каждой ИС модели безопасности и применять соответствующие методики проведения анализа защищёности ИС. Современные методики ориентированы на проведение анализа защищённости с позиции выявления ошибок бизнес-логики и ошибок реализации программного обеспечения, подверженного определённым уязвимостям. Такие методики ориентированы как на высокоуровневые ошибки, так низкоуровневые; при этом остаётся не рассмотренным в полной мере прикладной уровень как промежуточный, или эксплуатационный. Наибольшее количество ошибок, допускаемых при разграничении доступа, происходит в первую очередь на этом уровне. Разработанный способ комплексирования к управлению безопасностью позволили разработать и внедрить методики для оценки защищённости уровня СОВ и оценки эффективности реализуемых мер безопасности, и модель управления безопасностью СОВ. В рамках экспериментальной проверки получены практические результаты сравнения точности разработанного метода с другими методами и показатели уровней защищённости до и после внедрения разработанных методов. Целью проверки являлась анализ и оценка количествах неклассических случаев применения мер безопасности для СОВ. Рисунок 12 показывает результаты сравнения точности метода оценки выполнения мер безопасности на базе подходов, заложенных в нормативных документах, типовых аддитивных методов оценки, и т.н. «К»-метода – метода, используемого в компании, использующего экспертную оценку в качестве веса меры. На приведённой гистограмме видно значительное изменение точности в сравнении с методами оценки нормативным и «К» методами. Сравнение с аддитивным методом, но использующим разработанный метод для расчёта веса меры, также показывает более высокий уровень точности. Одинаковые значения в этом случае могут быть только при рассмотрении классических случаев, когда для оценки уровня выполнения мер безопасности используется статичный набор мер и функциональных возможностей. В приведённом примере это не так, что говорит о необходимости учёта неклассических случаев (Таблица 6, Таблица 10). Здесь, уровни выполнения мер безопасности, косвенно характеризующие уровень защищённости, полученные разработаными расширенными методами (F0N0, F1N0, Рисунок 13), в сравнении с результатом базового разработанного метода показывают значительный разрыв до 60%. Это говорит о низких показателях выполнения мер безопасности и о большом количестве неклассических случаев, когда ряд мер неприменим и не применяется (F0N0) и применяются (F1N0). Это свидетельствует о необходимости пересмотра состава мер и выявления причин таких расхождений в оценке. Опять же, при рассмотрении классических случаев, базовая оценка и две расширенные оценки будут давать одинаковые результаты (значения). После внесения изменений в рамках разработанного инструментария (Рисунок 14) видно, что количество таких случаев значительно сократилось, однако отдельные случаи ещё имеют место (согласуется с политикой компании). Например, ряд механизмов безопасности задействуется для снижения риска нарушения правил доступа в случае изменений СОВ со стороны вендора в будущем. Таким образом, полученные результаты в рамках диссертационной работы при их внедрении позволили экспериментально подтвердить возможность реализации разработанных методов, минимизировать объемы выполняемых работ, повысить защищённость эксплуатируемых облачных сред и уменьшить количество некорретных элементов в технической составляющей политики безопасности. В свою очередь, это позволило разработать эскизы проектов программного обеспечения класса «Security Awareness» и «Decision Support System» с использованием разработанных методов оценки уровня защищённости и алгоритма принятия решений, и перейти к разработке прототипов отдельных компонентов упомянутого программного обеспечения в рамках системы централизованного мониторинга, направленного на управление осведомленностью сотрудников в области информационной безопасности и быстрым реагированием в условиях возникающих угроз безопасности.