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

Кроме того, даже в частном облаке имеет смысл ограничить взаимодействие виртуальных машин между собой, разделив облако на отдельные сегменты, что не позволит вредоносным программам беспрепятственно распространяться по облаку. Стоит выделить виртуальные машины критических приложений в отдельные сегменты с повышенными требованиями к надежности и отказоустойчивости, причем, возможно, виртуальные машины из таких сегментов вообще не надо перемещать в публичные облака. Управлением сегментами может заниматься как операционная система, в которой работает гипервизор, как это реализовано в Windows Server 2012, так и сторонние средства защиты, такие как Check Point Virtual Firewall.

Отдельно следует обеспечить контроль информационных потоков — если информационная система предприятия разделена на сегменты, то, скорее всего, имеется информация, которая должна быть локализована внутри критических сегментов. Для того чтобы она не покинула пределы своего домена, нужны механизмы контроля потоков, облачные системы защиты от утечек данных (Data Leak Protection, DLP), которые могли бы определить важную для данного сегмента облака информацию и не выпускать ее наружу. Такая система должна быть встроена в облако на достаточно низком уровне, поскольку она должна уметь влиять на правила перераспределения ресурсов, блокируя перемещение важных данных на слабо защищенные узлы облака.

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

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

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

Скрытый образовательный потенциал хакерских сообществ

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

Грегори Конти, Джон Нелсон, Томас Бэббит

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

Сейчас на рынке появляются продукты в виде готовых виртуальных машин Virtual Appliance, которые достаточно развернуть в облаке и настроить, однако для сложных многокомпонентных продуктов (типа Lync или систем управления сайтами) существует возможность встраивания внешнего компонента, который будет, например, перехватывать телефонный трафик или собирать определенные данные из системы. Методы выявления посторонних или скрытых элементов системы пока даже не изучаются, поэтому вполне возможно, что механизмы аутентификации устройств, предусмотренные стандартом IEEE 802.1x, надо будет использовать в том числе и на уровне распределенных приложений и виртуальных машин.

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

  • Управление идентификацией. Традиционно, как правило, выполнялось средствами Active Directory, однако теперь придется внедрять более функциональные продукты, реализующие как минимум ролевое управление с разделением на домены.
  • Сегментация. С этими функциями вполне справляются межсетевые экраны.
  • Защита от утечек. Предприятие должно контролировать внутренние информационные потоки, чтобы автоматическое перераспределение ресурсов в облаке не унесло вовне важную информацию. Нужны механизмы выявления действительно ценной информации.
  • Хранение данных с дедупликацией. Позволяет сократить объемы данных, вызванных переходом системы на виртуализацию с большим дублированием системных файлов.
  • Контроль виртуальных машин. Поскольку облако управляется автоматически в соответствии с определенными правилами, то нужно обеспечить верификацию этих правил, которая гарантировала бы отсутствие в них вредоносных политик, интегрированных посторонними компаниями. К сожалению, пока таких компонентов на рынке защиты нет, хотя для этих целей можно адаптировать возможности более общих инструментов управления информацией и событиями в области безопасности (Security Information and Event Management, SIEM).

Гибридные облака, передающие часть вычислительной нагрузки компании вовне, должны предоставлять сервисы делегирования административных полномочий клиенту. Однако передача вычислений на сторону означает появление вероятности хотя бы теоретического вмешательства администратора владельца облака в работу корпоративной системы заказчика. При использовании внешних ресурсов нужно обеспечить контроль внешних виртуальных машин и данных. Такой контроль можно реализовать с помощью специального агента, который в корпоративном облаке не активен, а при попадании виртуальной машины на внешние узлы облака активируется и сообщает в центр управления о своем местоположении. Агент позволяет не только обеспечить единое пространство защиты для корпоративных виртуальных машин в гибридном облаке, но и отследить ситуацию, когда машину попытаются «угнать» и запустить во внешней среде. Такую операцию обычно организуют злоумышленники для похищения ее данных или встраивания в облачное корпоративное приложение. Например, такой агент есть в продукте Deep Security 9.

Защита данных может быть организована с помощью развернутого корпоративного облачного сервиса хранения данных и синхронизации мобильных устройств. Этот сервис можно построить, например, на базе SharePoint 2013, где имеются инструменты для организации корпоративного хранилища данных, к которому могут подключаться как внешние пользователи, так и виртуальные машины, работающие во внешних облаках. Если запретить такому сервису перемещаться в публичное облако, то данные не будут в него перетекать, но работающие там виртуальные машины получают доступ к корпоративному хранилищу по защищенному протоколу. Аналогичные решения предлагают и производители NAS-продуктов, такие как QNAP, Synology или Buffalo Technology, позволяющие на базе собственных программно-аппаратных комплексов организовать облачное хранилище, доступное извне, в которое приложения, работающие в облаке, будут помещать свои данные.

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

***

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF