Технологии защиты облаков. Как снизить риски ИБ

Николай Арефьев, старший инженер-проектировщик по информационной безопасности Центра информационной безопасности компании «Инфосистемы Джет»

Риски и облака

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

Кража аутентификационных данных

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

Помимо случаев, когда клиент пользуется услугами только одного провайдера, возможен вариант, при котором ему необходимы сервисы, предоставляемые сразу несколькими независимыми поставщиками. Дело в том, что любой провайдер реализует ограниченное число сервисов, поэтому клиентам зачастую приходится использовать сразу несколько облаков, составляя требуемый им функциональный набор. Например, клиент может интегрировать в рамках своего web-ресурса облачные сервисы Salesforce для организации CRM-системы, Google Apps для работы с офисными пакетами и WebEx для организации web-конференций.

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

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

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

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

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

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

Доступ привилегированных пользователей

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

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

Уязвимости в ПО оркестрации и предоставления сервисов

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

Любое программное обеспечение содержит в себе ошибки и ПО оркестрации, ПО предоставления сервисов не является исключением. Пользуясь имеющимися в программном коде ошибками, злоумышленник может получить доступ к системе управления cloud-сервисами как отдельного клиента, так и всего облака целиком. К примеру, воспользовавшись уязвимостями в коде портала самообслуживания или применяя методы социальной инженерии, он организует доступ к ресурсам компании. Далее, опираясь на клиентский портал как на базу для развития атаки, злоумышленник способен развить ее в нижестоящем слое облака — ПО оркестрации, в результате чего получить доступ к ресурсам всех клиентов cloud’а.

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

• внедрение процедур контроля качества разрабатываемых провайдером скриптов автоматизации, ПО и программных интерфейсов;
• поддержка процедур установки обновлений системы безопасности платформы, предоставляющей облачные услуги;
• внедрение систем межсетевого экранирования и криптографической защиты каналов связи;
• развертывание систем IDS/IPS, реализующих анализ протоколов сетевого уровня;
• развертывание специализированных IDS/IPS, обеспечивающих контроль прикладных протоколов, в рамках которых выполняются вызовы API-функций ПО оркестрации и предоставления сервисов.

Уязвимости разделяемой среды

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

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

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

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

В зависимости от используемой модели предоставления сервисов из облака (PaaS, IaaS, SaaS) клиенту и провайдеру целесообразно обеспечить процедуры обновления применяемого системного и прикладного ПО.

Кража данных, размещаемых в облаке

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

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

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

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

И напоследок

Применение cloud-технологий по любой из моделей, будь то PaaS, IaaS или SaaS, не избавляет вас от необходимости оценивать и принимать решения по минимизации рисков, присущих классической ИТ-инфраструктуре. Наоборот, переход к использованию облаков добавляет новые риски, снижение которых зависит уже не только от вас, но и от вашего провайдера. В связи с этим и поставщику услуг, и вам очень важно понимать возникающие вопросы информационной безопасности и совместно находить их решения в рамках установленных договоренностей.

Контактная информация

Наши сайты: www.jet.su, www.jetinfo.ru. Электронная почта: info@jet.su.

Другие статьи раздела «От ИБ к безопасности бизнеса»