Archive | November 2013

Чем защитить “облако”?

“А что у McAfee есть для защиты облаков?” – такой вопрос был задан на прошедшей конференции. Чтобы ответить детально необходимо, прежде всего, понимать о каком уровне доступа к “облаку” мы говорим. Давайте рассмотрим два основных сценария построения облачных сервисов и особенности их безопасности.

public-cloud-iconВариант первый – Public Cloud.

Если заказчик, мигрируя в “чужое” (public) облако, получает только интерфейс для работы с информацией, без доступа к “внутренностям” самого сервиса, в таком случае возможности контроля ИБ со стороны заказчика минимальны, большая часть задач по безопасности ложится на плечи сервис-провайдера. Я весьма скептически отношусь к безопасности Public Cloud, потому что осознаю, что после передачи своих данных сервис-провайдеру я полностью теряю над ними контроль. Использование Public Cloud предполагает сокрытие внутренних механизмов сервиса от заказчиков. Такой подход привлекателен для бизнеса в силу простоты использования, однако с точки зрения ИБ мы получаем серьезные риски, вот лишь некоторые из них:

  • зачастую пользователь Public Cloud абсолютно не имеет представления о том, где физически размещена его информация (страна/сервер) – отсюда вытекают вопросы выдачи информации;
  • при передаче данных в Public Cloud заказчик теряет контроль доступа к ней;
  • при юридическом давлении сервис-провайдер может предоставить доступ к информации заказчика третьим лицам, не утруждая себя уведомлением заказчика;
  • вопрос о гарантированном удалении данных по запросу клиента остается открытым (у пользователя нет возможности убедиться, что удаленная информация была действительно удалена с носителей и резервных копий, а не только из интерфейса);
  • и наконец, самое главное – не видя “внутренностей” услуги, у клиента нет возможности провести аудит систем, из которых состоит “облако”, т.е. невозможно оценить эффективность мер по безопасности, средств аутентификации и резервного копирования. Таким образом, заказчику приходится полностью полагаться на совесть хозяина “облака”.

Свежий, наглядный пример рисков передачи приватных/конфиденциальных данных в “чужое” облако (Public Cloud) –  Microsoft обвинила Google в чтении писем  В данном случае речь идет о контекстном анализе частной переписки пользователей сервиса. При чем Google и Microsoft в равной степени получают доступ к содержимому электронной корреспонденции своих подписчиков, не важно под каким предлогом – защита от спама или таргетированная реклама. Важен тот факт, что такое беспардонное вмешательство в тайну переписки юридически обосновано соглашением о предоставлении услуг (которое 90% пользователей принимают не читая). Фактически, у конечного пользователя нет возможности контроля использования его переписки третьими лицами (не важно с какой целью).

Я немного увлекся, свои мысли по поводу этой новости я изложу в отдельной заметке.

Несмотря на очевидные недостатки Public Cloud, количество пользователей услуг такого типа растет. Причиной того, что люди идут на риск, может быть как отсутствие бюджета на построение своего “облака” (Private Cloud) так и не понимание рисков. Я лишь хочу отметить, что при использовании Public Cloud критически важно отдавать данные сервис-провайдеру в зашифрованном виде, это позволит обезопасить информацию в случае НСД со стороны недобросовестных сотрудников сервис-провайдера или третьих лиц.

private-cloudВариант второй – Private Cloud.

Если заказчик руководствуется известной поговоркой “Хочешь сделать хорошо – сделай это сам”, он приходит к необходимости построения своего “облака”. В таком случае у технических специалистов есть полный доступ к инфраструктуре “облака”. Это значит, что они могут на 100% контролировать коммуникации внутри “облака”, процесс установки и конфигурации ПО, вопросы резервного копирования критически важной информации, а главное – аспекты контроля доступа к системам обработки и хранения данных.

Когда я говорю о модели Private Cloud, это не обязательно должен быть отдельный ЦОД. Минимальный уровень – аренда серверных стоек или VDS. Главное условие – возможность доступа к ОС и эксклюзивные привилегии конфигурирование серверов, установку ПО. При таком сценарии построения инфраструктуры компания несет больше затрат, чем при использовании чужого “облака”. Возрастают требования к квалификации специалистов компании, которым необходимо осуществлять сопровождение такой инфраструктуры.

В любом случае, выбор типа “облака” зависит от ценности данных, которые будут в нем обрабатываться и от механизмов защиты, которые необходимо использовать (часть решений предназначены только для использования в Private Cloud).

mcafeeИнструменты защиты “облаков”

Если мы говорим о Public Cloud, прежде всего, по возможности, необходимо использовать McAfee Endpoint Encryption на конечных точках сотрудников – для того, чтобы шифровать документы перед тем, как они будут загружены в облако. Для этих же целей можно воспользоваться облачной услугой McAfee Email Protection SaaS, которая позволит шифровать корпоративную переписку и защищать ее от вирусов и спама. Web запросы работающих в «облаке» можно перенаправлять на McAfee Web Protection SaaS, это позволит обеспечить фильтрацию Web контента и защиту от зловредных скриптов. По договоренности с сервис-провайдером можно задействовать One Time Password для усиления аутентификации сотрудников при доступе к корпоративным сервисам, развернутым в «чужом» облаке. Частичный (из-за неполного доступа к инфраструктуре) аудит облачных сервисов можно будет проводить с помощью Vulnerability Manager. Для защиты рабочих станций персонала можно применить Endpoint Protection Suite управляемый из локально развернутой консоли ePO либо из «облака», используя Endpoint Protection SaaS. Для защиты от утечек понадобится развернуть на конечных точках McAfee DLP Endpoint, по договоренности с сервис-провайдером клиентскую часть DLP также можно развернуть на облачных ВМ, однако из-за ограниченного доступа к платформе и отсутствия эксклюзивных привилегий администратора угроза утечки или НСД остается реальной. С другой стороны, обезопасить бизнес построенный на Public Cloud сервисах от утечек частично можно перенаправив сетевой трафик на McAfee Network DLP (может быть развернут локально или на VDS). Чтобы получить контроль над BYOD стоит использовать EMM, который может быть установлен локально либо на VDS.

Однако следует всегда помнить про ограничения Public Cloud. Прежде чем выгружать в него корпоративную информацию стоит сопоставить ее ценность и риск от ее утери с ценой построения своего приватного «облака». При планировании использования мер обеспечения безопасности в Public Cloud стоит несколько раз пройти всю цепочку бизнес-процессов от начала и до конца, учитывая на каждом этапе степень контроля над информацией и уровень доступа к ней владельца облака. Другими словами, нужно четко представлять что может сделать с информацией владелец “облака” на каждом из этапов (может ли перехватить, может ли исказить или подменить).

Теперь перейдем к рассмотрению построения системы безопасности в случае использования Private Cloud. Поскольку у заказчика есть полный эксклюзивный доступ к ВМ, ОС и привилегии на установку ПО в плане ИБ мы получаем свободу маневра. Заказчик может концентрировать модули защиты вокруг источников данных (сетевые хранилища, БД), контролировать каналы передачи внутри Private Cloud, защищать системы обработки информации. При этом получая возможность полного аудита с целью оценки эффективности работы всех систем.

Что и как стоит использовать для защиты бизнеса который построен на базе Private Cloud:

Безопасность периметра от сетевых атак можно обеспечить использованием IPS, который может быть развернут в виде ВМ либо аппаратного устройства. Использование IPS с расширениями анализа поведения позволят противодействовать атакам “нулевого” дня. Поскольку облачные вычисления подразумевают широкое использование виртуализации, для антивирусной защиты серверов и VDI стоит вместо обычного антивируса воспользоваться оптимизированным MOVE. Для усиления защиты конечных точек понадобиться развернуть на ВМ решения из пакета Endpoint Protection Suite. Для защиты от НСД, в случае изъятия серверов или доступа к накопителям информации (особенно если мы говорим об VDS или аренде серверных стоек) на серверах должен быть установлен McAfee Endpoint Encryption. Имя доступ к БД, которые используются при работе сервисов “облака” имеет смысл применить решения из перечня Database Security. Так,  Vulnerability Manager for Databases позволит проводить аудит уязвимостей, Virtual Patching for Databases обеспечит защиту от обнаруженных “дырок” без необходимости остановки БД для установки патчей, а McAfee Database Activity Monitoring позволит разграничивать и контролировать доступ сотрудников к отдельным объектам БД. Если заказчик вынес в Private Cloud почтовый сервер и Web proxy, будет весьма полезным развернуть в “облаке” в виде ВМ Email Gateway и Web Gateway. Такой ход позволит, во-первых, обеспечить защиту этих каналов передачи, а во-вторых, даст возможность легко расширить систему безопасности, дополнив его Network DLP, с целью контроля сетевого трафика и анализа контента, который пользователи генерируют в “облаке” и передают в Интернет по каналам почты и Web.

Кроме перечисленных решений стоит отметить, что заказчик в Private Cloud может полноценно использовать “большую тройку”:

McAfee Policy Auditor;

McAfee Risk Advisor;

McAfee Vulnerability Manager.

для комплексного аудита систем и проверки соответствия их нормам ИБ.

Очевидно, за безопасность BYOD будет отвечать McAfee Enterprise Mobility Management (McAfee EMM), который позволит защитить корпоративную информацию, обрабатываемую на мобильных устройствах от НСД. Перенаправив трафик с мобильных устройств сотрудников на Email и Web Gateway мы получим защиту этих каналов передачи, а подключив Network DLP получим анализ контента, отправляемого с мобильных устройств.

Важно!

Перечень решений указанных выше далеко не полный. Конкретный набор компонентов будет зависеть от ТЗ заказчика и может включать гораздо больше модулей, благо выбирать есть из чего. Я лишь привел примеры использования отдельных решений McAfee в комплексе для обеспечения безопасности бизнес процессов в “облаках”. Вместо эпилога хочу еще раз обратить внимание на тот факт, что подход McAfee Security Connected позволяет не только комбинировать отдельные защитные модули, но также интегрировать их между собой для максимальной эффективности. При этом комплексная система собранная под ТЗ заказчика будет управляться из единой Web консоли ePolicy Orchestrator.

На этом у меня все. Спасибо за внимание!

Advertisements