Угрозы безопасности в облачных технологиях. Угрозы безопасности облачных вычислений
ГРИГОРЬЕВ1 Виталий Робертович, кандидат технических наук, доцент КУЗНЕЦОВ2 Владимир Сергеевич
ПРОБЛЕМЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ В МОДЕЛИ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ
В статье приведен обзор подходов к построению концептуальной модели облачных вычислений, а также проведено сравнение существующих взглядов к выявлению уязвимостей, которые присущи системам, построенным на основе данной модели. Ключевые слова: облачные вычисления, уязвимость, ядро угроз, виртуализация.
Целью данной статьи является обзор подходов к построению концептуальной модели облачных вычислений, приведенной в документе «NIST Cloud Computing Reference Architecture», и сравнение взглядов ведущих в этой области организаций на уязвимости в условиях данной модели вычислений, а также основных игроков на рынке создания облачных систем.
Облачные вычисления - это модель, обеспечивающая удобный сетевой доступ по требованию к общим конфигурируемым вычислительным ресурсам (сетям, серверам, хранилищам данных, приложениям и сервисам), который оперативно предоставляется с минимальными усилиями по управлению и взаимодействию с сервис-провайдером. Это определение Национального института стандартов (NIST) широко распространено во всей отрасли. Определение облачных вычислений включает пять основных базовых характеристик, три сервисные модели и четыре модели развертывания.
Пять основных характеристик
Самообслуживание по требованию
Пользователи способны получать, контролировать и управлять вычислительными ресурсами без помощи системных администраторов. Широкий сетевой доступ - вычислительные сервисы предоставляются через стандартные сети и гетерогенные устройства.
Оперативная эластичность - 1Т-
ресурсы могут оперативно масштабироваться в любую сторону по мере надобности.
Пул ресурсов - 1Т-ресурсы совместно используются различными приложениями и пользователями в несвязанном режиме.
Расчет стоимости услуги - использование 1Т-ресурса отслеживается по каждому приложению и пользователю, как правило, чтобы обеспечить биллинг по публичному облаку и внутренние расчеты за использование частных облаков.
Три сервисных модели
ПО как услуга (SaaS) - обычно приложения предоставляются конечным пользователям как услуга через веб-браузер. На сегодня имеются сотни предложений SaaS, от горизонтальных приложений предприятий до специализированных предложений по отдельным отраслям, а также потребительские приложения, такие как электронная почта.
Платформа как услуга (PaaS) - платформа для разработки и развертывания приложений предоставляется как услуга разработчикам для создания, развертывания и управления приложениями SaaS. Обычно платформа включает в себя базы данных, ПО среднего слоя и инструменты для разработки, причем все это предоставляется как услуга через Интернет. PaaS часто ориентируется на язык программирования или API, например, Java или Python. Виртуализованная кластерная архитектура распределенных вычислений часто служит базой для систем
1 - МГТУ МИРЭА, доцент кафедры Информационная безопасность;
2 - Московский Государственный Университет Радиоэлектроники и Автоматики (МГТУ МИРЭА), студент.
РааЯ, так как грид-структура сетевого ресурса обеспечивает необходимую эластичную масштабируемость и объединение ресурсов. Инфраструктура как услуга (IaaS) - серверы, хранилища данных и сетевое аппаратное обеспечение предоставляются как услуга. Это инфраструктурное оборудование часто вир-туализовано, поэтому виртуализация, управление и ПО операционной системы также являются элементами 1ааЯ.
Четыре модели развертывания
Частные облака - предназначены для исключительного использования одной организацией и обычно контролируются, управляются и хостиру-ются частными центрами данных. Хостинг и управление частными облаками могут быть переданы на аутсорсинг внешнему сервис-провайдеру, но част-
ное облако остается в исключительном пользовании одной организации. Публичные облака - используются многими организациями (пользователями) совместно, обслуживаются и управляются внешними сервис-провайдерами.
Групповые облака - используются группой родственных организаций, желающих воспользоваться общей облачной вычислительной средой. Например, группу могут составить различные рода вооруженных сил, все университеты данного региона или все поставщики крупного производителя.
Гибридные облака - появляются, когда организация использует как частное, так и публичное облако для одного и того же приложения, чтобы воспользоваться преимуществами обоих. Например, при «ливневом» сценарии организация-пользователь в случае стандартной нагрузки на приложение
пользуется частным облаком, а когда нагрузка пиковая, например, в конце квартала или в праздничный сезон, задействует потенциал публичного облака, впоследствии возвращая эти ресурсы в общий пул, когда необходимость в них отсутствует.
На рис. 1 представлена концептуальная модель облачных вычислений согласно документу «NIST Cloud Computing Reference Architecture». Согласно представленной на рис. 1 модели в стандарте выделяются основные участники облачной системы: облачный потребитель, облачный провайдер, облачный аудитор, облачный брокер, облачный посредник. Каждый участник - это человек или организация, выполняющий (ая) свои функции по реализации или предоставлению облачных вычислений. Облачный потребитель - лицо или организация, которая поддерживает бизнес-взаимодействие с другими ак-
Облачный потребитель
Облачный аудитор
С Аудит Л I безопасности J
I Аудит конфи- Л I денциальности J
(Аудит предостав- | ляемых услуг J
Облачный провайдер
Комплекс уровней
Пользовательский уровень
^ Сервис как услуга ^ ^ Платформа как услуга ^ Инфраструктура как услуга)
Уровень абстракции
Физический уровень
Облачный сервис
^ Поддержка J ^ Настройка J
Переносимость
Облачный брокер
Облачный посредник
Рис. 1. Концептуальная модель, разработанная специалистами NIST
торами сети и использует услуги от облачных провайдеров. Облачный провайдер - лицо, организация или кто угодно, отвечающий за доступность услуг, предоставляемых заинтересованным потребителям. Облачный аудитор - участник, который может проводить независимые оценки облачных сервисов, услуг и безопасности облачной реализации. Облачный брокер - это участник, который управляет использованием, текущими характеристиками и доставкой потребителю облачных сервисов, а также согласовывает взаимодействие между облачными провайдерами и облачными потребителями. Облачный посредник - посредник, который предоставляет связь и доставку облачных сервисов между облачными провайдерами и облачными потребителями.
Достоинства и проблемы облачных вычислений
Последние опросы специалистов в области 1Т-технологий показывают, что облачные вычисления предлагают два главных плюса при организации распределенных услуг - скорость и стоимость. Благодаря автономному доступу к пулу вычислительных ресурсов пользователи могут включаться в интересующие их процессы в считанные минуты, а не через недели или месяцы, как это было ранее. Изменение вычислительного потенциала также производится быстро благодаря эластично масштабируемой грид-архитектуре вычислительной среды. Так как в облачных вычислениях пользователи платят только за то, что используют, а возможности масштабирования и автоматизации достигают высокого уровня, соотношение стоимости и эффективности предоставляемых услуг является также весьма привлекательным фактором для всех участников обменных процессов.
Те же опросы показывают, что существует ряд серьезных соображений, которые удерживают некоторые компании от перехода к облаку. Среди этих соображений с большим отрывом лидируют вопросы обеспечения безопасности облачных вычислений.
Для адекватной оценки безопасности в облачных системах имеет смысл исследовать взгляды на угрозы данной области основных игроков рынка. Мы сравним существующие подходы к угрозам в облачных системах, представленные в документе NIST Cloud Computing Standards Roadmap с подходами, которые предлагают компании IBM, Oracle и VmWare.
Стандарт безопасности облачных вычислений, принятый Национальным институтом стандартов ^ВД США
Стандарт безопасности облачных вычислений (NIST Cloud Computing Standards Roadmap), принятый в NIST, охватывает возможные потенциальные типы атак на сервисы облачных вычислений:
♦ компрометация конфиденциальности и доступности данных, передаваемых облачными провайдерами;
♦ атаки, которые исходят из особенностей структуры и возможностей среды облачных вычислений для усиления и увеличения ущерба от атак;
♦ неавторизированный доступ потребителя (посредством некорректной аутентификации или авторизации, или уязвимостей, внесенных по-средствам периодического технического обслуживания) к ПО, данным и ресурсам, используемым автори-зированным потребителем облачного сервиса;
♦ увеличение уровня сетевых атак, таких как DoS, эксплуатирующих ПО, при разработке которого не учитывалась модель угроз для распределенных ресурсов интернета, а также уязвимости в ресурсах, которые были доступны из частных сетей;
♦ ограниченные возможности по шифрованию данных в среде с большим количеством участников;
♦ переносимость, возникающая в результате использования нестандартных API, которые усложняют облачному потребителю возможность перехода к новому облачному провайдеру, когда требования доступности не выполняются;
♦ атаки, эксплуатирующие физическую абстракцию облачных ресурсов, и эксплуатирующие недостатки в записях и процедурах аудита;
♦ атаки на виртуальные машины, которые не были соответствующим образом обновлены;
♦ атаки, эксплуатирующие нестыковки в глобальных и частных политиках безопасности.
Также стандарт выделяет основные задачи безопасности для облачных вычислений:
♦ защита пользовательских данных от неавторизированного доступа, раскрытия, модификации или просмотра; подразумевает поддержку сервиса идентификации таким образом, что потребитель имеет возможность выполнить идентификацию и политику контроля доступа на авторизованных пользователях, имеющих доступ к сервисам облачным; такой подход подразумевает возможность потребителя предоставить доступ к его данным выборочно другим пользователям;
♦ защита от «цепных» (supply chain threats) угроз; включает в себя подтверждение степени доверия и надежности сервис провайдера в той же степени, что и степень доверия используемого ПО и «железа»;
♦ предотвращение неавторизирован-ного доступа к ресурсам облачных вычислений; включает в себя создание защищенных доменов которые логически отделены от ресурсов (например, логическое разделение рабочих нагрузок, запущенных на одном и том же физическом сервере посредством гипервизора в среде с мультиарендованием) и использование безопасных по умолчанию конфигураций;
♦ разработка веб-приложений, развернутых в облаке, для модели угроз распределенных ресурсов интернета и встраивание функций по обеспечению безопасности в процесс разработки ПО;
♦ защита интернет-браузеров от атак для смягчения слабых мест безопасности конечного пользователя; включает в себя принятие мер для защиты интернет-соединения персональных компьютеров на основе использования безопасного ПО, межсетевых экранов (файр-волов) и периодической установки обновлений;
♦ развертывание контроля доступа и технологий обнаружения вторже-
ний у облачного провайдера и проведение независимой оценки, для проверки наличия оных; включает в себя (но этим не ограничивается) традиционные меры по безопасности периметра в сочетании с моделью безопасности домена; традиционная безопасность периметра включает в себя ограничение физического доступа к сети и устройствам, защита индивидуальных компонент от эксплуатации посредствам развертывания обновлений, установкой по умолчанию большинства настроек безопасности, отключением всех неиспользуемых портов и сервисов, использованием ролевого управления доступом, мониторингом записей аудита, минимизированием используемых привилегий, использованием антивирусных пакетов и шифрованием соединений;
♦ задание доверенных границ между сервис-провайдером (ами) и потребителями для того, чтобы убедиться в ясности авторизованной ответственности за предоставление безопасности;
♦ поддержка переносимости, осуществляемой для того, чтобы потребитель имел возможность сменить облачного провайдера в тех случаях, когда у него возникает необходимость в части удовлетворения требований по целостности, доступности, конфиденциальности; это включает в себя возможность закрыть акаунт в данный момент и копировать данные от одного сервис-провайдера к другому.
Таким образом, Стандарт безопасности облачных вычислений (NIST Cloud Computing Standards Roadmap), принятый в NIST, определяет базовый список атак на облачные системы и список основных задач, которые должны
решаться посредством применения
соответствующих мер.
Сформулируем угрозы информационной безопасности облачной системы:
♦ У1 - угроза (компрометации, доступности, etc...) данным;
♦ У2 - угрозы, порождаемые особенностями структуры и возможностями архитектуры реализации распределенных вычислений;
♦ У4 - угрозы, связанные с некорректной моделью угроз;
♦ У5 - угрозы, связанные с некорректным использованием шифрования (необходимо использование шифрования в среде, где существуют несколько потоков данных);
♦ У6 - угрозы, связанные с использованием нестандартных API при разработке;
♦ У7 - угрозы виртуализации;
♦ У8 - угрозы, эксплуатирующие нестыковки в глобальных политиках безопасности.
Взгляд на проблемы обеспечения безопасности облачных вычислений, принятый в компании IBM
Документ Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security позволяет нам сделать выводы о взглядах на обеспечение безопасности, сформированных специалистами компании IBM. На основе этого документа мы можем расширить предложенный ранее список угроз, а именно:
♦ У9 - угрозы, связанные с доступом сторонних лиц к физическим ресур-сам\системам;
♦ У10 - угрозы, связанные с некорректной утилизацией (жизненный цикл) персональной информации;
♦ У11 - угрозы, связанные с нарушением региональных, национальных и интернациональных законов, касающихся обрабатываемой информации.
Подходы компаний IBM, Oracle и VmWare к обеспечению безопасности облачных вычислений
Документация, предоставляемая данными компаниями и описывающая взгляды на обеспечение безопасности в их системах, не дает принципиально отличных от приведенных выше угроз.
В табл. 1 приводятся основные классы уязвимостей, сформулированные компаниями в своих продуктах. Табл. 1 позволяет увидеть отсутствие полного покрытия угроз у исследованных компаний и сформулировать «ядро угроз», созданное компаниями в своих облачных системах:
♦ угроза данным;
♦ угрозы, основанные на структуре\ возможностях распределенных вычислений;
♦ угрозы, связанные с некорректной моделью угроз;
♦ угрозы виртуализации.
Заключение
Обзор основных классов уязвимостей облачной платформы позволяет сделать вывод, что в настоящее время не существует готовых решений для полноценной защиты облака в силу разнообразия атак, использующих данные уязвимости.
Следует отметить, что построенная таблица классов уязвимостей (табл. 1), интегрирующая подходы ведущих в
Таблица 1. Классы уязвимостеи
Источник Декларируемые угрозы
У1 У2 У3 У4 У5 У6 У7 У8 У9 У10 У11
NIST + + + + + + + + - - -
IBM + + + + + - + - + + +
Sun/Oracle + + + + - - + - - + -
VmWare + + + + - - + - - - -
этой отрасли игроков, не исчерпывается представленными в ней угрозами. Так, например, в ней не отражены угрозы, связанные со стиранием границ между средами с разными уровнями конфиденциальности данных, а также со стиранием границ ответственности за информационную безопасность между потребителем услуг и облачным провайдером.
Становится очевидным, что для реализации сложной облачной системы защиту необходимо разрабатывать под конкретную реализацию. Также важную роль для реализации безопасных вычислений в виртуальных средах играет отсутствие стандартов ФСТЭК и ФСБ для облачных систем. Выделенное в работе «ядро угроз» имеет смысл использовать при иссле-
довании задачи построения унифицированной модели классов уязвимо-стей. Данная статья носит обзорный характер, в последующем планируется подробно проанализировать классы угроз, связанные с виртуализацией, разработать подходы к созданию системы защиты, потенциально предотвращающей реализацию данных угроз
Литература
1. Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security, ibm.com/redbooks, November 2, 2009.
2. http://www.vmware.com/technical-resources/security/index.html.
3. NIST Cloud. Computing Reference Architecture, National Institute of Standards and. Technology, Special Publication. 500-292, September 2011.
4. NIST Cloud. Computing Standards Roadmap, National Institute of Standards and. Technology, Special Publication. 500-291, July 2011.
5. http://www.oracle.com/technetwork/indexes/documentation/index.html.
Неделю назад, относительно приоритезации устранения уязвимостей. Никита Ремезов в Фейсбуке справедливо заметил, что она ориентирована в первую очередь на госов и надо признать, что это так. К этой схеме он предложил добавить привязку к критичности сканируемых ресурсов для бизнеса. Да, и это тоже верно и контекстные метрики в CVSSv3 могут помочь это сделать. Преимуществом данной методики является ее простота. Чтобы ею воспользоваться не нужно ничего, кроме сканера безопасности, поддерживающего CVSS. Хотя даже он не нужен. Идентифицировать уязвимости можно либо путем анализа сетевого трафика
| Список уязвимостей, идентифицируемых NGFW |
В последних двух случаях останется только выгрузить все данные об уязвимостях и провести их приоритезацию по описанной методике (это можно легко автоматизировать через обычный Excel).
Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).
Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.
А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).
Но даже это число уязвимостей может быть еще больше сокращено, если привязать дыры к векторам атаки, то есть проанализировать возможные пути, которыми злоумышленники могут воспользоваться для проникновения внутрь.
По сути речь идет о построении графа атак, который опирается на данные об уязвимостях, которые могут быть использованы для попадания из Интернет во внутреннюю сеть компании.
Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.
Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером. Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама:-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.
Методика из прошлой заметки дешева и не требует дополнительных затрат, но плохо работает в крупных инфраструктурах. Подход, описанный сегодня, более практичен, но и требует больших ресурсов / усилий по реализации. Зато полностью автоматизирован. Однако у него есть и еще один недостаток. Он предполагает, что мы не имеем других способов проникновения в корпоративную сеть или можем их минимизировать. Однако, если в сети есть незащищенный Wi-Fi, пользователи падки на подброшенные флешки, а руководство может безконтрольно приносить свои домашние ноутбуки и подключать их к внутренней сети, то второй подход может создать ложное чувство защищенности. Ищите баланс...
Существует несколько методов построения корпоративной IT-инфраструктуры. Развертывание всех ресурсов и сервисов на базе облачной платформы - лишь один из них. Однако преградой на этом пути часто становятся предрассудки, касающиеся безопасности облачных решений. В этой статье мы разберемся, как устроена система безопасности в облаке одного из самых известных российских провайдеров - Яндекса.
Сказка - ложь, да в ней намек
Начало этой истории можно рассказывать, как известную сказку. Было в фирме три админа: старший умный был детина, средний был и так и сяк, младший вовсе был… стажером-эникейщиком. Заводил юзеров в Active Directory и крутил хвосты цискам. Пришло время компании расширяться, и призвал царь, то есть босс, свое админское воинство. Желаю, говорит, новые веб-сервисы для наших клиентов, собственное файловое хранилище, управляемые базы данных и виртуальные машины для тестирования софта.
Младшенький с ходу предложил создать с нуля собственную инфраструктуру: закупить серверы, установить и настроить софт, расширить основной интернет-канал и добавить к нему резервный - для надежности. И фирме спокойнее: железо всегда под рукой, в любой момент чего-нибудь заменить или перенастроить можно, и самому ему представится отличная возможность прокачать свои админские скиллы. Подсчитали и прослезились: не потянет компания таких затрат. Крупному бизнесу подобное под силу, а вот для среднего и малого - слишком накладно получается. Это ж нужно не просто оборудование приобрести, серверную оборудовать, кондиционеры повесить да противопожарную сигнализацию наладить, требуется еще и посменное дежурство организовать, чтобы денно и нощно за порядком следить и отражать сетевые атаки лихих людей из интернета. А по ночам и в выходные админы работать почему-то не захотели. Если только за двойную оплату.
Старший админ поглядел задумчиво в окошко терминала и предложил поместить все сервисы в облако. Но тут его коллеги принялись пугать друг друга страшилками: дескать, облачная инфраструктура имеет незащищенные интерфейсы и API, плохо балансирует нагрузку разных клиентов, из-за чего могут пострадать твои собственные ресурсы, а еще неустойчива к краже данных и внешним атакам. Да и вообще, боязно передавать контроль над критичными данными и ПО посторонним лицам, с которыми ты не съел пуд соли и не выпил ведро пива.
Средненький подал идею разместить всю IT-систему в дата-центре провайдера, на его каналах. На том и порешили. Однако тут нашу троицу поджидало несколько неожиданностей, не все из которых оказались приятными.
Во-первых, любая сетевая инфраструктура требует обязательного наличия средств защиты и безопасности, которые, конечно, были развернуты, настроены и запущены. Только вот стоимость используемых ими аппаратных ресурсов, как оказалось, должен оплачивать сам клиент. А ресурсы современная система ИБ потребляет немалые.
Во-вторых, бизнес продолжал расти и построенная изначально инфраструктура быстро уперлась в потолок масштабируемости. Притом для ее расширения простой смены тарифа оказалось недостаточно: многие сервисы в этом случае пришлось бы переносить на другие серверы, перенастраивать, а кое-что и вовсе перепроектировать заново.
Наконец, однажды из-за критической уязвимости в одном из приложений вся система упала. Админы быстро подняли ее из резервных копий, только вот оперативно разобраться в причинах случившегося не удалось, поскольку для сервисов логирования резервное копирование настроить забыли. Ценное время было потеряно, а время, как гласит народная мудрость, - это деньги.
Подсчет расходов и подведение итогов привели руководство компании к неутешительным выводам: прав был тот админ, который с самого начала предлагал воспользоваться облачной моделью IaaS - «инфраструктура как сервис». Что же касается безопасности таких платформ, то об этом стоит поговорить отдельно. И сделаем мы это на примере самого популярного из подобных сервисов - Яндекс.Облака.
Безопасность в Яндекс.Облаке
Начнем, как советовал девочке Алисе Чеширский Кот, с начала. То есть с вопроса разграничения ответственности. В Яндекс.Облаке, как и в любых других подобных платформах, провайдер отвечает за безопасность предоставляемых пользователям сервисов, в то время как в сферу ответственности самого клиента входит обеспечение правильной работы разрабатываемых им приложений, организация и разграничение удаленного доступа к выделенным ресурсам, конфигурирование баз данных и виртуальных машин, контроль над ведением логов. Впрочем, для этого ему предоставляется весь необходимый инструментарий.
Безопасность cloud-инфраструктуры Яндекса имеет несколько уровней, на каждом из которых реализованы собственные принципы защиты и применяется отдельный арсенал технологий.
Физический уровень
Ни для кого не секрет, что Яндекс располагает собственными дата-центрами, которые обслуживают собственные же отделы безопасности. Речь идет не только о видеонаблюдении и службах контроля доступа, призванных предотвратить проникновение в серверные посторонних, но и о системах поддержания климата, пожаротушения и бесперебойного питания. От суровых охранников мало толку, если стойку с вашими серверами однажды зальет водой из противопожарных оросителей или они перегреются после отказа кондиционера. В дата-центрах Яндекса такого с ними точно не случится.
Кроме того, аппаратные средства Облака физически отделены от «большого Яндекса»: они расположены в разных стойках, но в точности так же проходят регулярное регламентное обслуживание и замену комплектующих. На границе этих двух инфраструктур используются аппаратные файрволы, а внутри Облака - программный Host-based Firewall. Кроме того, на коммутаторах Top-of-the-rack применяется система управления доступом ACL (Access Control List), что значительно повышает безопасность всей инфраструктуры. Яндекс на постоянной основе проводит сканирование Облака извне в поисках открытых портов и ошибок в конфигурации, благодаря чему потенциальную уязвимость можно распознать и ликвидировать заранее. Для работающих с ресурсами Облака сотрудников реализована централизованная система аутентификации по ключам SSH с ролевой моделью доступа, а все сессии администраторов логируются. Такой подход является частью повсеместно применяемой Яндексом модели Secure by default: безопасность закладывается в IT-инфраструктуру еще на этапе ее проектирования и разработки, а не добавляется потом, когда все уже запущено в эксплуатацию.
Инфраструктурный уровень
На уровне «аппаратно-программной логики» в Яндекс.Облаке используются три инфраструктурных сервиса: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А теперь о каждом из них чуть подробнее.
Compute Cloud
Этот сервис предоставляет масштабируемые вычислительные мощности для различных задач, таких как размещение веб-проектов и высоконагруженных сервисов, тестирование и прототипирование или временная миграция IT-инфраструктуры на период ремонта либо замены собственного оборудования. Управлять сервисом можно через консоль, командную строку (CLI), SDK или API.
Безопасность Compute Cloud базируется на том, что все клиентские виртуальные машины используют минимум два ядра, а при распределении памяти не применяется overcommitment. Поскольку в этом случае на ядре исполняется только клиентский код, система не подвержена уязвимостям вроде L1TF, Spectre и Meltdown или атакам на побочные каналы.
Кроме того, Яндекс использует собственную сборку Qemu/KVM, в которой отключено все лишнее, оставлен только минимальный набор кода и библиотек, необходимых для работы гипервизоров. При этом процессы запускаются под контролем инструментария на базе AppArmor, который с использованием политик безопасности определяет, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor, работающий поверх каждой виртуальной машины, уменьшает риск того, что клиентское приложение сможет получить доступ из ВМ к гипервизору. Для получения и обработки логов Яндекс выстроил процесс поставки данных от AppArmor и песочниц в собственный Splunk.
Virtual Private Cloud
Сервис Virtual Private Cloud позволяет создавать облачные сети, используемые для передачи информации между различными ресурсами и их связи с интернетом. Физически этот сервис поддерживается тремя независимыми ЦОД. В этой среде логическая изоляция осуществляется на уровне многопротокольного взаимодействия - MPLS. При этом Яндекс постоянно проводит fuzzing стыка SDN и гипервизора, то есть со стороны виртуальных машин во внешнюю среду непрерывно направляется поток неправильно сформированных пакетов с целью получить отклик от SDN, проанализировать его и закрыть возможные бреши в конфигурации. Защита от DDoS-атак при создании виртуальных машин включается автоматически.
Yandex Managed Services
Yandex Managed Services - это программное окружение для управления различными сервисами: СУБД, кластерами Kubernetes, виртуальными серверами в инфраструктуре Яндекс.Облака. Здесь большую часть работы по обеспечению безопасности сервис берет на себя. Все резервное копирование, шифрование резервных копий, Vulnerability management и так далее обеспечивается автоматически программными средствами Яндекс.Облака.
Инструменты реагирования на инциденты
Для своевременного реагирования на инциденты, связанные с информационной безопасностью, требуется вовремя определить источник проблемы. Для чего необходимо использовать надежные средства мониторинга, которые должны работать круглосуточно и без сбоев. Такие системы неизбежно будут расходовать ресурсы, но Яндекс.Облако не перекладывает стоимость вычислительных мощностей инструментов безопасности на пользователей платформы.
При выборе инструментария Яндекс руководствовался еще одним важным требованием: в случае успешной эксплуатации 0day-уязвимости в одном из приложений злоумышленник не должен выйти за пределы хоста приложения, в то время как команда безопасности должна моментально узнать об инциденте и среагировать нужным образом.
И последнее, но не самое маловажное пожелание заключалось в том, чтобы все инструменты имели открытый исходный код. Этим критериям полностью соответствует связка AppArmor + Osquery, которую и решено было использовать в Яндекс.Облаке.
AppArmor
AppArmor уже упоминался выше: это программный инструмент упреждающей защиты, основанный на настраиваемых профилях безопасности. Профили используют технологию разграничения доступа на основании меток конфиденциальности Mandatory Access Control (MAC), реализуемую с помощью LSM непосредственно в самом ядре Linux начиная с версии 2.6. Разработчики Яндекса остановили свой выбор на AppArmor по следующим соображениям:
- легкость и быстродействие, поскольку инструмент опирается на часть ядра ОС Linux;
- это решение с открытым исходным кодом;
- AppArmor можно очень быстро развернуть в Linux без необходимости писать код;
- возможна гибкая настройка с помощью конфигурационных файлов.
Osquery
Osquery - это инструмент мониторинга безопасности системы, разработанный компанией Facebook, сейчас он успешно применяется во многих IT-отраслях. При этом инструмент кросс-платформенный и имеет открытый исходный код.
С помощью Osquery можно собирать информацию о состоянии различных компонентов операционной системы, аккумулировать ее, трансформировать в стандартизированный формат JSON и направлять выбранному получателю. Этот инструмент позволяет писать и направлять приложению стандартные SQL-запросы, которые сохраняются в базе данных rocksdb. Можно настроить периодичность и условия выполнения или обработки этих запросов.
В стандартных таблицах уже реализовано много возможностей, например можно получить список запущенных в системе процессов, установленных пакетов, текущий набор правил iptables, сущности crontab и прочее. «Из коробки» реализована поддержка получения и парсинга событий из системы аудита ядра (используется в Яндекс.Облаке для обработки событий AppArmor).
Сам Osquery написан на C++ и распространяется с открытыми исходниками, можно их модифицировать и как добавлять новые таблицы в основную кодовую базу, так и создавать свои расширения на C, Go или Python.
Полезная особенность Osquery - наличие распределенной системы запросов, с помощью которой можно в режиме реального времени выполнять запросы ко всем виртуальным машинам, находящимся в сети. Это может быть полезно, например, если обнаружена уязвимость в каком-либо пакете: с помощью одного запроса можно получить список машин, на которых установлен этот пакет. Такая возможность широко используется при администрировании больших распределенных систем со сложной инфраструктурой.
Выводы
Если мы вернемся к истории, рассказанной в самом начале этой статьи, то увидим, что опасения, заставившие наших героев отказаться от развертывания инфраструктуры на облачной платформе, оказались беспочвенны. По крайней мере, если речь идет о Яндекс.Облаке. Безопасность созданной Яндексом cloud-инфраструктуры имеет многоуровневую эшелонированную архитектуру и потому обеспечивает высокий уровень защиты от большинства известных на сегодняшний день угроз.
При этом за счет экономии на регламентном обслуживании железа и оплате ресурсов, потребляемых системами мониторинга и предупреждения инцидентов, которые берет на себя Яндекс, использование Яндекс.Облака заметно экономит средства малому и среднему бизнесу. Безусловно, полностью отказаться от отдела IT или департамента, отвечающего за информационную безопасность (особенно если обе эти роли объединены в одной команде), не получится. Но Яндекс.Облако существенно снизит трудозатраты и накладные расходы.
Поскольку Яндекс.Облако предоставляет своим клиентам защищенную инфраструктуру со всеми необходимыми инструментами обеспечения безопасности, они могут сосредоточиться на бизнес-процессах, оставив задачи сервисного обслуживания и мониторинга железа провайдеру. Это не устраняет необходимости текущего администрирования ВМ, БД и приложений, но такой круг задач пришлось бы решать в любом случае. В целом можно сказать, что Яндекс.Облако экономит не только деньги, но и время. А второе, в отличие от первого, невосполнимый ресурс.
Под облачными вычислениями в совокупности понимается большой пул легко используемых и легкодоступных виртуализованных ресурсов (таких как аппаратные комплексы, сервисы и др.). Эти ресурсы могут быть динамически перераспределены (масштабированы) для подстройки под динамически изменяющуюся нагрузку, обеспечивая оптимальное использование ресурсов. Этот пул ресурсов обычно предоставляется по принципу «оплата по мере использования». При этом владелец облака гарантирует качество обслуживания на основе определенных соглашений с пользователем.
В соответствии со всем вышесказанным, можно выделить следующие основные черты облачных вычислений:
1) облачные вычисления представляют собой новую парадигму предоставления вычислительных ресурсов;
2) базовые инфраструктурные ресурсы (аппаратные ресурсы, системы хранения данных, системное программное обеспечение) и приложения предоставляются в виде сервисов;
3) данные сервисы могут предоставляться независимым поставщиком для внешних пользователей по принципу «оплата по мере использования», основными особенностями облачных вычислений являются виртуализация и динамическая масштабируемость;
4) облачные сервисы могут предоставляться конечному пользователю через веб-браузер или посредством определенного программного интерфейса API (Application Programming Interface) .
Общая модель облачных вычислений состоит из внешней и внутренней частей. Эти два элемента соединены по сети, в большинстве случаев через Интернет. Посредством внешней части пользователь взаимодействует с системой; внутренняя часть - это собственно само облако. Внешняя часть состоит из клиентского компьютера или сети компьютеров предприятия и приложений, используемых для доступа к облаку. Внутренняя часть представляет собой приложения, компьютеры, серверы и хранилища данных, создающие облако сервисов посредством виртуализации (рис. 1).
При перемещении существующих физических виртуальных машин (ВМ) из центра обработки данных (ЦОД) во внешние облака или предоставление IT-сервисов вне безопасного периметра в частных облаках, приводит к тому, что периметр сети полностью теряет смысл, а общий уровень безопасности становится довольно низким.
Если в традиционных ЦОД, доступ инженеров к серверам строго контролируется на физическом уровне, то в облачных вычислениях доступ инженеров происходит через интернет, что приводит к появлению соответствующих угроз. Соответственно, критически важным является строгий контроль доступа для администраторов, а так же обеспечение контроля и прозрачность изменений на системном уровне
Виртуальные машины динамичны. Изменчивость ВМ очень сильно усложняет создание и поддержание целостной системы безопасности. Уязвимости и ошибки в настройках могут бесконтрольно распространяться. Кроме этого, весьма непросто зафиксировать для последующего аудита состояния защиты в какой-либо определённый момент времени.
Серверы облачных вычислений используют те же ОС и те же веб-приложения, что и локальные виртуальные, и физические сервера. Соответственно, для облачных систем угроза удаленного взлома или заражения вредоносным кодом так же высока.
Ещё одной угрозой является угроза целостности данных: компрометации и кражи данных. Целостность операционной системы и файлов приложений, а так же внутренняя активность должны контролироваться.
Использование многопользовательских облачных сервисов усложняет следование требованиям стандартов и законов, включающих в себя требования использования криптографических средств, для защиты важной информации, такой как информация о владельце кредитной карты и информации идентифицирующей человека. Это в свою очередь, порождает непростую задачу обеспечения надёжной защиты и безопасного доступа к важным данным .
Основываясь на анализе возможных угроз в облачных вычислениях, предложен возможный программно-аппаратный комплексный защиты безопасности облачных вычислений, включающий в себя 5 технологий: брандмауэр, обнаружение и предотвращение вторжений, контроль целостности, анализ журналов и защита от вредоносного программного обеспечения.
Провайдеры облачных вычислений используют виртуализацию для представления своим клиентам доступ к недорогим вычислительным ресурсам. При этом ВМ клиентов разделяют одни и те же аппаратные ресурсы, что необходимо для достижения наибольшей экономической эффективности. Корпоративные заказчики, которые интересуются облачными вычислениями для расширения своей внутренней IT-инфраструктуры, должны учитывать угрозы, которые порождает подобный шаг. Кроме традиционных механизмов сетевой защиты центров обработки данных, использующих такие подходы безопасности как: пограничный брандмауэр, выделение демилитаризованных зон, сегментацию сети, средства контроля состояния сети, системы обнаружения и предотвращения вторжений, так же должны использоваться программные механизмы защиты данных на серверах виртуализации или на самих ВМ, так как с переносом ВМ на публичные облачные сервисы периметр корпоративной сети постепенно теряет смысл и на общий уровень безопасности начинают значительно влиять наименее защищённые узлы. Именно невозможность физического разделения и применения аппаратных средств безопасности для отражения атак между ВМ приводит к потребности размещения механизма защиты на сервере виртуализации или на самих ВМ. Внедрение на самой виртуальной машине комплексного метода защиты, включающего в себя программную реализацию брандмауэра, обнаружения и предотвращения вторжений, контроля целостности, анализа журналов и защиты от вредоносного кода, является наиболее эффективным способом защиты целостности, соответствия требованиям регуляторов, соблюдение политик безопасности при перемещении виртуальных ресурсов из внутренней сети в облачные среды.
Литература:
1. Радченко Г.И. Распределённые вычислительные системы // Учебное пособие. - 2012. - С. 146-149.
2. Кондрашин М. Безопасность облачных вычислений // Storage News. - 2010. - №1.
Сегодня поговорим об угрозах облачной безопасности, рассмотрев ТОП-12, с которыми сталкиваются те или иные организации, использующие облачные сервисы. Как известно, количество облачных миграций с каждым годом растет, а вопрос безопасности по-прежнему остается серьезной темой.
Первым шагом к минимизации рисков в облаке является своевременное определение ключевых угроз безопасности. На конференции RSA , прошедшей в марте этого года, CSA (Cloud Security Alliance) представила список 12 угроз облачной безопасности, с которыми сталкиваются организации. Рассмотрим их более подробно.
Угроза 1: утечка данных
Облако подвергается тем же угрозам, что и традиционные инфраструктуры. Из-за большого количества данных, которые сегодня часто переносятся в облака, площадки облачных хостинг-провайдеров становятся привлекательной целью для злоумышленников. При этом серьезность потенциальных угроз напрямую зависит от важности и значимости хранимых данных.
Раскрытие персональной пользовательской информации, как правило, получает меньшую огласку, нежели раскрытие медицинских заключений, коммерческих тайн, объектов интеллектуальной собственности, что наносит значительный ущерб репутации отдельно взятой компании. При утечке данных организацию ожидают штрафы, иски или уголовные обвинения, а также косвенные составляющие в виде ущерба для бренда и убытков для бизнеса, которые приводят к необратимым последствиям и затяжным процедурам восстановления имиджа компании. Поэтому облачные поставщики стараются обеспечивать должный контроль и защиту данных в облачном окружении. Чтобы минимизировать риски и угрозы утечки данных, CSA рекомендует использовать многофакторную аутентификацию и шифрование.
Угроза 2: компрометация учетных записей и обход аутентификации
Утечка данных зачастую является результатом небрежного отношения к механизмам организации проверки подлинности, когда используются слабые пароли, а управление ключами шифрования и сертификатами происходит ненадлежащим образом. Кроме того, организации сталкиваются с проблемами управления правами и разрешениями, когда конечным пользователям назначаются гораздо бо льшие полномочия, чем в действительности необходимо. Проблема встречается и тогда, когда пользователь переводится на другую позицию или увольняется. Мало кто торопится актуализировать полномочия согласно новым ролям пользователя. В результате учетная запись содержит гораздо бо льшие возможности, чем требуется. А это узкое место в вопросе безопасности.
CSA рекомендует использовать механизмы многофакторной аутентификации, включая одноразовые пароли, токены, смарт-карты, USB-ключи. Это позволит защитить облачные сервисы, поскольку применение озвученных методов усложняет процесс компрометации паролей.
Угроза 3: взлом интерфейсов и API
Сегодня облачные сервисы и приложения немыслимы без удобного пользовательского интерфейса. От того, насколько хорошо проработаны механизмы контроля доступа, шифрования в API, зависит безопасность и доступность облачных сервисов. При взаимодействии с третьей стороной, использующей собственные интерфейсы API, риски значительно возрастают. Почему? Потому что требуется предоставлять дополнительную информацию, вплоть до логина и пароля пользователя. Слабые с точки зрения безопасности интерфейсы становятся узким местом в вопросах доступности, конфиденциальности, целостности и безопасности.
CSA рекомендует организовать адекватный контроль доступа, использовать инструменты защиты и раннего обнаружения угроз. Умение моделировать угрозы и находить решения по их отражению - достойная профилактика от взломов. Кроме того, CSA рекомендует выполнять проверку безопасности кода и запускать тесты на проникновение.
Угроза 4: уязвимость используемых систем
Уязвимость используемых систем - проблема, встречающаяся в мультиарендных облачных средах. К счастью, она минимизируется путем правильно подобранных методов управления ИТ, отмечают в CSA. Лучшие практики включают в себя регулярное сканирование на выявление уязвимостей, применение последних патчей и быструю реакцию на сообщения об угрозах безопасности. Согласно отчетам CSA, расходы, затраченные на снижение уязвимостей систем, ниже по сравнению с другими расходами на ИТ.
Распространена ошибка, когда при использовании облачных решений в модели IaaS компании уделяют недостаточно внимания безопасности своих приложений, которые размещены в защищенной инфраструктуре облачного провайдера . И уязвимость самих приложений становится узким местом в безопасности корпоративной инфраструктуры.
Угроза 5: кража учетных записей
Фишинг, мошенничество, эксплойты встречаются и в облачном окружении. Сюда добавляются угрозы в виде попыток манипулировать транзакциями и изменять данные. Облачные площадки рассматриваются злоумышленниками как поле для совершения атак. И даже соблюдение стратегии «защиты в глубину» может оказаться недостаточным.
Необходимо запретить «шаринг» учетных записей пользователей и служб между собой, а также обратить внимание на механизмы многофакторной аутентификации. Сервисные аккаунты и учетные записи пользователей необходимо контролировать, детально отслеживая выполняемые транзакции. Главное - обеспечить защиту учетных записей от кражи, рекомендует CSA.
Угроза 6: инсайдеры-злоумышленники
Инсайдерская угроза может исходить от нынешних или бывших сотрудников, системных администраторов, подрядчиков или партнеров по бизнесу. Инсайдеры-злоумышленники преследуют разные цели, начиная от кражи данных до желания просто отомстить. В случае с облаком цель может заключаться в полном или частичном разрушении инфраструктуры, получении доступа к данным и прочем. Системы, напрямую зависящие от средств безопасности облачного поставщика, - большой риск. CSA рекомендует позаботиться о механизмах шифрования и взять под собственный контроль управление ключами шифрования. Не стоит забывать про логирование, мониторинг и аудит событий по отдельно взятым учетным записям.
Угроза 7: целевые кибератаки
Развитая устойчивая угроза, или целевая кибератака, - в наше время не редкость. Обладая достаточными знаниями и набором соответствующих инструментов, можно добиться результата. Злоумышленника, задавшегося целью установить и закрепить собственное присутствие в целевой инфраструктуре, не так легко обнаружить. Для минимизации рисков и профилактики подобных угроз поставщики облачных услуг используют продвинутые средства безопасности. Но помимо современных решений, требуется понимание сущности и природы такого вида атак.
CSA рекомендует проводить специализированное обучение сотрудников по распознаванию техник злоумышленника, использовать расширенные инструменты безопасности, уметь правильно управлять процессами, знать о плановых ответных действиях на инциденты, применять профилактические методы, повышающие уровень безопасности инфраструктуры.
Угроза 8: перманентная потеря данных
Поскольку облака стали достаточно зрелыми, случаи с потерей данных без возможности восстановления по причине поставщика услуг крайне редки. При этом злоумышленники, зная о последствиях перманентного удаления данных, ставят целью совершение подобных деструктивных действий. Облачные хостинг-провайдеры для соблюдения мер безопасности рекомендуют отделять пользовательские данные от данных приложений, сохраняя их в различных локациях. Не стоит забывать и про эффективные методы резервного копирования. Ежедневный бэкап и хранение резервных копий на внешних альтернативных защищенных площадках особенно важны для облачных сред.
Кроме того, если клиент шифрует данные до размещения в облаке, стоит заранее позаботиться о безопасности хранения ключей шифрования. Как только они попадают в руки злоумышленнику, с ними становятся доступны и сами данные, потеря которых может быть причиной серьезных последствий.
Угроза 9: недостаточная осведомленность
Организации, которые переходят в облако без понимания облачных возможностей, сталкиваются с рисками. Если, к примеру, команда разработчиков со стороны клиента недостаточно знакома с особенностями облачных технологий и принципами развертывания облачных приложений, возникают операционные и архитектурные проблемы.
CSA напоминает о необходимости понимать функционирование облачных сервисов, предоставляемых поставщиком услуг. Это поможет ответить на вопрос, какие риски берет на себя компания, заключая договор с хостинг-провайдером.
Угроза 10: злоупотребление облачными сервисами
Облака могут использоваться легитимными и нелегитимными организациями. Цель последних - использовать облачные ресурсы для совершения злонамеренных действий: запуска DDoS-атак, отправки спама, распространения вредоносного контента и т. д. Поставщикам услуг крайне важно уметь распознавать таких участников, для чего рекомендуется детально изучать трафик и использовать инструменты мониторинга облачных сред.
Угроза 11: DDoS-атаки
Несмотря на то что DoS-атаки имеют давнюю историю, развитие облачных технологий сделало их более распространенными. В результате DoS-атак может сильно замедлиться или вовсе прекратиться работа значимых для бизнеса компании сервисов. Известно, что DoS-атаки расходуют большое количество вычислительных мощностей, за использование которых будет платить клиент. Несмотря на то что принципы DoS-атак, на первый взгляд, просты, необходимо понимать их особенности на прикладном уровне: они нацелены на уязвимости веб-серверов и баз данных. Облачные поставщики, безусловно, лучше справляются с DoS-атаками, чем отдельно взятые клиенты. Главное - иметь план смягчения атаки до того, как она произойдет.
Угроза 12: совместные технологии, общие риски
Уязвимости в используемых технологиях - достаточная угроза для облака. Поставщики облачных услуг предоставляют виртуальную инфраструктуру , облачные приложения, но если на одном из уровней возникает уязвимость, она влияет на все окружение. CSA рекомендует использовать стратегию «безопасности в глубину», внедрять механизмы многофакторной аутентификации, системы обнаружения вторжений, придерживаться концепции сегментирования сети и принципа предоставления наименьших привилегий.
