Заказчикам IaaS требуется защита

ОБЛАЧНЫЕ ПРОВАЙДЕРЫ могут предложить своим клиентам несколько видов средств защиты Источник: iStockphoto

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

Опасности для IaaS

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

• Небезопасная ИТ-архитектура провайдера IaaS. Плохо выстроенная инфраструктура облака, если оператор не предпринял определенных усилий по организации защиты, позволяет клиентам оператора атаковать друг друга.

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

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

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

• Уязвимости в сервисах провайдера IaaS. Сервисы облачных провайдеров часто подготовлены ими самостоятельно, и поэтому они могут содержать такие же ошибки, как и при использовании собственных ЦОД.

Алексей Лукацкий, менеджер по развитию бизнеса Cisco, поясняет: «Если посмотреть на стандартные сервисы, предлагаемые провайдерами IaaS, то мы увидим, что инфраструктура в облаке мало чем отличается от обычного центра обработки данных, который есть у любой компании (меняется только масштаб ЦОД). Иными словами, от облачного провайдера мы получаем услуги доступа к виртуальным машинам, серверам, системам хранения, сетевой инфраструктуре. Поэтому и угрозы для этих элементов инфраструктуры будут идентичными — утечки данных, несанкционированный доступ, уничтожение данных и элементов инфраструктуры, атаки на сетевом, прикладном уровне и уровне виртуализации, кража идентификационных данных и т. п.». Для предотвращения этого вида атак традиционно предлагается использовать уже привычные средства корпоративной защиты.

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

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

Приведенный выше список наиболее распространенных угроз для заказчиков IaaS позволяет определить необходимый набор защитных механизмов.

В составе инфраструктуры

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

Облачные провайдеры могут предложить своим клиентам несколько видов средств защиты.

• Антивирусы. Это традиционный защитный продукт, который легко продавать любым способом, в том числе и из облака.

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

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

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

• Защита от утечек. К числу наиболее важных средств защиты относятся системы предотвращения утечек (DLP). Они предназначены для контроля потоков передачи информации и выделения в них важных для безопасности компании сведений.

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

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

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

Архитектура защиты

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

• Облачная защита. Это вариант, при котором собственно аренды вычислительных ресурсов не происходит — компания арендует только защитные средства.

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

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

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

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

• «Распределенные» облака. Совсем не обязательно, чтобы вся корпоративная ИТ-система располагалась на единой облачной платформе. Допустимы ситуации, когда часть ресурсов находится, например, в облаке Microsoft Azure, а другая — в облаке Amazon.

В этом случае межсетевые экраны позволяют объединить части системы, находящиеся в разных облаках, в единое целое при помощи защищенных соединений. При этом можно отдельно хранить базу данных в защищенном сетевом хранилище одного провайдера, веб-сервер с механизмами защиты от вторжений арендовать у другого, а облачную CRM-систему — у третьего. В каждом облаке нужно установить межсетевой экран с целью защиты фрагментов и создания VPN-туннелей для взаимодействия с другими фрагментами. Такая система позволяет распределить данные между облаками различных провайдеров и переносить части системы из одного облака в другое в экстренных случаях. Кроме того, аренда в каждом облаке может выполняться на разных уровнях: где-то арендуется инфраструктура, где-то платформа, а где-то и приложение. Стандарты на защитные технологии, принятые в Интернете, позволяют объединить эти элементы во взаимоувязанную информационную систему. Однако администрировать ее будет достаточно сложно. В защитных решениях для IaaS строится VPN от клиента до провайдера. Тут скрыты два подводных камня. Во-первых, нужно помнить о юридических аспектах трансграничного применения VPN, которые регулируются законодательством тех стран, где находятся клиент и площадки облачного провайдера. Вторая проблема вызвана парадоксом: по оценкам Cisco, свыше 80% клиентов облачных услуг никак не защищают данные на тракте от своего офиса до облачного провайдера, ориентируясь на защиту в самой облачной инфраструктуре. То есть клиенты боятся использовать облака, считая их незащищенными, но сами не стремятся сделать облачные технологии более безопасными. А ведь совсем не обязательно, чтобы услуги по защите предоставлял провайдер — в большинстве случаев и сам клиент, арендуя дополнительные экземпляры виртуальных машин, может защитить арендованную инфраструктуру.