• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

А. Санин (Avanpost): "Периметр безопасности в облаке все же есть, просто он немного отличается от привычных нам понятий"

Большинство решений облачной безопасности перекочевало из корпоративных сетей в публичные и гибридные (межсетевые экраны, антивирусы, шифрование данных, резервное копирование и др.). А в чем ее особенности?   Читайте полную версию Дискуссионного клуба темы номера "ИКС" №9'2012 "Дорожная карта облачной безопасности". Часть 4.

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

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

Алексей Лукацкий, бизнес-консультант по безопасности Cisco Systems: Если в облаке используется виртуализация, то в защите нуждается гипервизор. Это что-то дополнительное. Но специфику облачных вычислений нужно учесть и в других элементах инфраструктуры – виртуальные машины, облачный frontend, взаимодействие с облаком и т.д.

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

Алексей Филатенков, начальник отдела ИБ, Открытые Технологии:  Особое внимание следует уделить системе мониторинга на предмет соответствия данных об облаке реальной картине. Решения для обеспечения безопасности облачных инфраструктур, по всей видимости, должны учитывать изменения самой вычислительной платформы, наличие систем виртуализации.

Антон Хрипунов, руководитель направления Центров обработки данных компании CTI: Клиент понимает, что при перемещении бизнес-данных и систем из собственного ЦОД в коммерческий ЦОД или облако уровня IaaS встает вопрос о сохранности данных и механизмах защиты от попыток давления на бизнес путем остановки работы бизнес-приложений или их порчи (или утечки информации к конкурентам). Технических программных инструментов безопасности на уровне передачи данных и их хранения достаточно. Однако на первое место надо ставить физическую безопасность, так как при недостатках в этой области никакие программные методы не помогут. Одним из интересных и перспективных решений для клиентов, решившихся к использованию публичных облаков, способных значительно обезопасить на физическом уровне ресурсы, является создание механизма динамического перемещения ресурсов между различными облачными провайдерами. Таким образом, мы реализуем идею liquid cloud. Безусловно, такое решение не является панацеей к обеспечению физической безопасности, но позволит значительно сократить риски за счет того, что даже сам провайдер облака не сможет спрогнозировать наличие у него ресурсов клиента в обозримом будущем. Единственной точкой проникновения к бизнес-данным и приложениям в таком случае становится только обслуживающий ИТ-персонал клиента, который контролирует перемещение ресурсов от одного облачного провайдера к другому.

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

Михаил Готальский, генеральный директор TrueConf: Использование облачных сервисов в корпоративой среде накладывает на них те же необходимые требования по безопасности, как и на корпоративные сервисы. В связи в этим, в облачные сервисы будут перекочевывать все корпоративные системы безопасности и, кроме того, добавятся сервисы защиты каналов.

Основа корпоративной безопасности: безусловное доверие внутренней локальной сети при полном недоверии внешних коннектов. Поэтому максимальный уровень контроля - доступу извне, шифростойскости каналов, аутентификации, авторизации, получению и повышению привилегий. Если же злоумышленник "уже вошел", то при работе с облаками, как показывает опыт, абсолютно доверенных коннектов не бывает, поэтому правило хорошего тона при обеспечении безопасности в облачных вычислениях - полное разделение сред и средств различных сеансов - "персональные песочницы" в java, chroot в linux, jail в freebsd - это "по максимуму", по минимуму - стремление приблизиться к этому.

Александр Санин, коммерческий директор компании Avanpost: Многие, говоря об облаках, постоянно ссылаются на избитую фразу – периметра безопасности больше нет. С одной стороны это выражение верно, но если смотреть глубже, то периметр все же есть, просто он немного отличается от привычных нам понятий. Происходит изменение самого понятия периметра безопасности от некой контролируемой зоны, до частично контролируемой зоны. И даже физические границы можно как-то описать, ведь у каждого облака можно выделить его «облачный периметр» – и ограничивается этот периметр той точкой, где в ЦОД приходит кабель интернет-провайдера.

Что касается вопросов защиты элементов инфраструктуры, которые сейчас «стоят ребром», то, в первую очередь, надо отметить несколько моментов. Всех очень волнует вопрос управления доступом. Кто кроме меня имеет доступ к сервису? Кто обслуживает его работу и т.п.? Есть ли возможность получить доступ к моим данным у других участников облака? Другими словами, необходимо продумывать такие модели этой подсистемы безопасности, которые вызывали бы у заказчиков доверие. Безусловно, сейчас очень активно применяются различные принципы разделения виртуальной инфраструктуры, но на мой взгляд, они применимы далеко не всегда и далеко не каждый провайдер идет на это. Ну и еще один очень важный вопрос, который хочется отметить. Связан он, в первую очередь, с утечками конфиденциальной информации и с непрерывностью. Представьте себе, работаете вы в облаке, ничего не нарушаете, а параллельно с вами работает какая-то другая компания, и у нее случаются проблемы с надзорными органами. Приходит ФСБ или кто-то еще, например БСТМ (бюро специальных технических мероприятий) и изымают сервера из ЦОДа… А ведь на этих серверах вполне может быть часть в том числе и вашей инфраструктуры и информации. Вопрос, конечно, специфичный, но все такие его надо как то решать.

Артем Гарусев, исполнительный директор компании CDNvideo: Есть очевидные вещи, например, защита гипервизора или системы биллинга. Но есть и важные темы, которым почему-то уделяется меньше внимания. Я бы хотел обратить внимание  на вопросы безопасности микрокода процессора, который, собственно, выполняет все гостевые ОС. Если процессор (микрокод) разделяется между несколькими клиентами, он может послужить причиной утечек данных между «облаками». Еще я бы отметил, что объектом нападения могут становиться сами подсистемы ИБ. Причем не только те, которые использует провайдер, но и те, которыми его серовис дополняет заказчик. Нарушив работу системы управления правами доступа или, например, систему аутентификации, киберпреступник может добраться до информации под видом легального пользователя, т. е. без каких-то сложнейших «инновационных» разработок. Я не специалист, но, вероятно, это самый экономичный способ, а значит им будут активно пользоваться.

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

Денис Безкоровайный, технический консультант Trend Micro в России и СНГ: Защищенность любой инфраструктуры определяется наименее защищенным ее звеном, это же правило применимо и к облачным сервисам. Нет абсолютно никакого смысла во внедрении передовых решений по контролю за утечками или шифрованию данных, если эти же самые данные может вынести любой администратор из хранилища незашифрованных резервных копий. С точки зрения безопасности отдельно можно выделить: защиту данных в облаке самими клиентами и защиту облачной инфраструктуры на стороне провайдера. Специфика облачных сред присутствует и организациям, их использующим, следует обратить особое внимание на существующие процессы управления учетными записями и используемые системы аутентификации. Также следует особенно защищать и контролировать реквизиты доступа к облачным сервисам, например, ключи аутентификации. Для защиты конфиденциальности данных существуют решения по их шифрованию в облачных средах, которые, в том числе, учитывают архитектуру облака – будь то IaaS или SaaS. Главное, клиентам следует воспринимать облачную среду как в определенной степени недоверенную среду, и, не перекладывая задачи по обеспечению ИБ на провайдера, стараться самим защищать свои данные и системы в облаке. Для защиты IaaS подходят средства ИБ, реализованные по агентской технологии и которые, в отличие от аппаратных или виртуализованных сетевых средств ИБ, не требует установки и вмешательства со стороны облачного провайдера. Клиент может самостоятельно устанавливать и контролировать свои средства защиты, такие как системы предотвращения атак и межсетевые экраны уровня хоста, системы контроля целостности и продукты, реализующие другие необходимые подсистемы ИБ. 

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

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

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

Юрий Сергеев, системный архитектор Центра информационной безопасности компании «Инфосистемы Джет» : Однозначного мнения о том, какие компоненты облачных сред являются наиболее уязвимыми, нет. Это объясняется разнородностью облачных сред. Традиционно наиболее уязвимы те сервисы, к которым возможен доступ из внешних сетей. Это особенно критично, когда функционал ИБ при реализации API взаимодействия с облаком реализован недостаточно – это может стать предпосылкой к успешной реализации атак злоумышленников. Также в «зону риска» попадают сервисы, обеспечивающие изоляцию между данными подписчиков услуг облака: сервер приложений (для SaaS), платформа, являющаяся средой разработки приложений для данного типа облаков (в случае PaaS), а для IaaS - это,  зачастую, гипервизор и другие компоненты виртуальной инфраструктуры. Например, добавление элемента в управлении виртуальными инфраструктурами может стать причиной того, что злоумышленник, взломавший систему, получит доступ ко всей информации, циркулирующей в виртуальной среде. Но  взлом конкретного сетевого узла одного подписчика может привести не только к его компрометации. Результатом этого становятся локальные escape-атаки на узлы других пользователей облака, направленные на преодоление изоляции гипервизора.

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

Антон Разумов, Руководитель группы консультантов по безопасности Check Point Software Technologies Ltd: Разумеется, виртуальные системы требуют ничуть не меньшего уровня безопасности по сравнению с физическими собратьями. Более того, поскольку добавляются новые элементы (гипервизор), новая специфика (потеря сегментации), все это накладывает дополнительные требования.

Вячеслав Медведев, аналитик компании "Доктор Веб":  Даже в случае полного перевода всех сервисов компании в облако сложно представить, что машины сотрудников будут подсоединяться к облаку непосредственно. Как минимум, в локальной сети должен остаться шлюз сети Интернет. Должна быть система защиты от атак и брандмауэр: несмотря (а во многом и благодаря) на вынос сервисов наружу — «остаток» локальной сети — рабочие станции пользователей — это лакомый кусок для хакеров. По тем же причинам должны быть защищены рабочие станции — требование о наличии на них антивируса, системы ограничения доступа и брандмауэра отменить невозможно — другой вопрос, что управляться эти системы могут из облака. В связи с необходимостью минимизации рисков — на случай недоступности сети Интернет или плановых ремонтов на стороне провайдера услуг — желательно наличие резервного почтового сервера, сервера Active Directory и т. д. Как уже говорилось, облако — это по сути территориально распределенная локальная сеть компании, часть из которой отдана на обслуживание сторонним организациям. Плюс часть или все сервисы компании виртуализированы. Таким образом, защита облака сама по себе не представляет ничего особенного. Но при переходе в облако клиентам услуг нужно особое внимание обратить на гарантии поставщика в области обеспечения непрерывности работы и процедуры, связанные с хранением, обработкой и уничтожением данных клиента, в том числе в резервных копиях.

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

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

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

Владимир Ткачев, технический директор VMware, Россия и СНГ: Есть разные модели предоставления услуг. В общем случае они отличаются тем, кто является хозяином инфраструктуры. Потребляя IaaS, компания берет все риски на себя, но при этом понимает, что просто виртуальные или виртуальные и удаленно расположенные (облачные) серверы не сильно отличаются от физических с точки зрения ИБ. Соответственно, перечень мер, которые надо предпринять для обеспечения безопасности, в общем смысле очень близок к традиционному. В случае же потребления PaaS, компания отдает административные функции поставщику услуг и ожидает от него выполнения большинства мер по обеспечению безопасности. То же относится и к SaaS. В этих моделях надо акцентировать внимание на зависимости бизнеса от каналов связи, как собственных, так и провайдерских, а также на сохранность данных, расположенных на чужих (провайдерских) площадках.