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

Аналитики Gartner верят, что перспективы облачных средств защиты вполне ясные. По их прогнозам, к 2015 году около 10% корпоративных систем информационной безопасности будут поставляться через облако. Как отмечают аналитики, в условиях конкуренции облачные решения ИБ становятся доступнее, облачные модели позволяют предприятиям получить новые возможности для защиты своих информационных активов. В Gartner полагают, что к 2015 году более 30% средств безопасности, используемых в сегменте малого и среднего бизнеса, будут облачными.

Евгений Дружинин, ведущий эксперт по информационной безопасности компании «Крок», говорит, что через облако можно предоставлять, например, защиту систем персональных данных в соответствии с индивидуальными моделями угроз, а также средства межсетевого экранирования, криптографической защиты каналов связи (IPSec VPN), предотвращения вторжений (IPS). «Минимальные усилия потребуются в отношении тех средств, которые не предполагают регулярного и плотного взаимодействия с ними обслуживающего персонала. Если же средство подразумевает ежедневное взаимодействие, то потребуется больше усилий со стороны заказчика услуги. Однако некоторые провайдеры ИБ-сервисов могут и эти работы взять на себя».

«Сейчас через облако можно получить большой набор услуг — прежде всего защиту от DDоS-атак, антивирусные функции, сервисы IPS/IDS и, конечно, управление событиями информационной безопасности (Security Information and Event Management, SIEM) и возможности центров мониторинга событий и управления инцидентами (Security Operations Center, SOC)», — отмечает Валентин Крохин, заместитель директора центра информационной безопасности компании «Инфосистемы Джет». Антивирусы при этом потребуют от предприятия минимальных усилий, а вот SIEM/SOC — максимальных.

По мнению Артура Гиоева, технического директора HP Software в России и СНГ, с помощью облачного инструментария можно, например, осуществлять контроль исходного кода: «Коды не несут в себе непосредственной угрозы проникновения злоумышленников, поэтому можно благополучно загрузить исходный код в облачную платформу, проанализировать его там и получить результаты». Еще один вариант использования облачного инструментария — выгружать систему из облака, балансируя нагрузку и проверяя ее устойчивость, например, к DDоS-атакам: «Все, что требуется, — это исходный код, его загрузка в платформу и ожидание результатов анализа». Что касается тестирования на устойчивость к нагрузке или DDоS-атакам, то оно, по оценке Гиоева, заметно сложнее: «Необходимо определять потенциальные сценарии, по которым злоумышленники будут пытаться взломать систему, затем планировать нагрузку, создавать сценарии нагрузки и прогонять их применительно к системам».

Александр Буравлев, технический директор компании «Аквариус», выделяет следующие функции ИБ, которые можно было бы приобретать из облака: разграничение прав доступа пользователей; контроль трафика между пользователями и виртуальными машинами; доверенная загрузка операционных систем; регистрация событий, ведение журнала. Что касается усилий со стороны предприятия, то чем сложнее система и чем больше функций она может выполнять, тем больше усилий придется приложить, чтобы она корректно выполняла свою функцию и не требовала постоянного внимания.

По мнению Александра Додохова, руководителя направления защиты баз данных компании «Аладдин Р.Д.», само по себе размещение средств защиты информации в облаке без выноса туда же самой информационной системы представляется нелогичным: «Ряд объективных и субъективных факторов ставят под сомнение возможность использования средств ИБ как облачных сервисов. К объективным, например, можно отнести то, что провайдер облачной инфраструктуры будет управлять множеством систем, включая средства ИБ, возможно, принадлежащим конкурирующим организациям. С точки зрения заказчика таких средств ИБ, ИТ-персонал провайдера рассматривается как потенциальный злоумышленник, имеющий полный доступ к информации. Говоря языком регуляторов, это «группа нарушителей... осуществляющая создание методов и средств реализации атак, а также реализующая атаки...», то есть нарушитель типа Н4 по классификации ФАПСИ 2001 года. Средства защиты от такого нарушителя должны соответствовать высокому классу, их реализация и эксплуатация на стороне провайдера весьма проблематичны». В качестве субъективного фактора Додохов называет менталитет заказчиков: «У них возникает фактор недоверия, который трудно преодолеть, — ведь средства обеспечения ИБ отчуждены от владельца».

Традиция и облака

Как сочетать традиционные и облачные средства информационной безо­пасности в рамках одной ИТ-инфраструктуры и какие организационные меры следует принять?

«Если облачные средства все же необходимо использовать, нужно убедиться в их безопасности и обеспечить возможность быстрой миграции из одного облака в другое, — рекомендует Гиоев. — Все это справедливо лишь для внешнего облака, с частным все намного проще». Следует в первую очередь четко регламентировать правила доступа к облаку, поскольку большинство крупных инцидентов происходит при поддержке инсайдеров. Кроме того, нужно использовать инструменты контроля и мониторинга подозрительных активностей.

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

Дружинин советует исходить из того, где находится ИТ-инфраструктура — в собственном ЦОД или у внешнего провайдера. В первом случае далеко не все средства ИБ могут быть предоставлены из облака, а потому их нужно реализовать в своем ЦОД. Исключение составляют несколько сервисов, которые могут быть независимыми, — например, очистка сетевого трафика от вирусов и спама. Если инфраструктура находится во внешнем облаке, средства защиты должны располагаться «рядом» и быть частью системы защиты в целом. Организационные меры, как отмечает Дружинин, тоже очень сильно зависят от того, где расположена защищаемая система и из чего строится сервис защиты: «Например, если все находится на стороне провайдера, то заказчик должен постоянно отслеживать, что происходит с его системой защиты, — самостоятельно либо договорившись с провайдером (и зафиксировав документально) о периодическом предоставлении подробных отчетов».

Крохин уверен, что традиционные и облачные средства ИБ хорошо сочетаются: «Необязательно все отдавать в облако, часть средств можно и нужно держать у себя. Я, например, с трудом представляю себе DLP в облаке. А технических ограничений нет никаких, все современные технологии позволяют сочетать традиционные и облачные средства ИБ в рамках одной ИТ-инфраструктуры». Главное — правильно составить SLA и самим их придерживаться.

Базовые принципы

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

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

Крохин рекомендует в первую очередь выбрать того провайдера услуг управления безопасностью (Managed Security Service Providers, MSSP), кому можно доверять, затем обязательно протестировать его на пилотных проектах, по их результатам составить четкие и понятные SLA, после чего работать строго по ним. «Не дергайте провайдера сразу после инцидента, если у него по SLA есть еще час. Но если MSSP не предоставляет требуемого уровня, то штрафуйте его и максимально громко об этом говорите», — советует Крохин.

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

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