Без периметра (комментарий Дмитрия Митрофанова, директора по производству 'Сервионики', для журнала ИКС, сентябрь 2012 г.)

21.11.2012

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

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

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

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

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

Неманья НИКИТОВИЧ, управляющий директор, Opti-ma Infosecurity (Группа Opti-ma): В зависимости от требований бизнеса все сетевые компоненты должны быть соответствующим образом защищены, но большинство компаний сегодня более всего сосредоточены на хранении данных и, следовательно, на защите и шифровании внутренних коммуникаций.

Антон ХРИПУНОВ, руководитель направления центров обработки данных, CTI: На первое место надо ставить физическую безопасность, при недостаточности которой никакие программные методы не помогут. Одно из интересных и перспективных решений для тех, кто решился на использование публичных облаков, – создание механизма динамического перемещения ресурсов между ными облачными провайдерами (liquid cloud). Это не панацея в плане обеспечения физической безопасности, но позволит значительно сократить риски за счет того, что даже сам провайдер облака не сможет спрогнозировать наличие у него ресурсов клиента в обозримом будущем. Единственной точкой проникновения к бизнес-данным и приложениям в таком случае становится обслуживающий ИТ-персонал клиента, который контролирует перемещение ресурсов от одного облачного провайдера к другому.

Михаил ГОТАЛЬСКИЙ, руководитель TrueConf: В облачные сервисы будут перекочевывать все корпоративные системы безопасности, а также добавятся сервисы защиты каналов. Основа корпоративной безопасности – безусловное доверие внутренней локальной сети при полном недоверии внешним коннектам. Поэтому максимальный уровень контроля – доступу извне, шифростойкости каналов, аутентификации, авторизации, получению и повышению привилегий. Правило хорошего тона при обеспечении безопасности в облачных вычислениях – полное разделение сред и средств различных сеансов: «персональные песочницы» в java, chroot в linux, jail в freebsd.

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

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

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

В о д и т е л ь с к и е   р и с к и

«ИКС»: Как соотносятся затраты провайдера облачных услуг на внедрение решений ИБ и окупаемость таких проектов? Как минимизировать его риски?

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

А. ГАРУСЕВ: Один из способов минимизировать риски – передать существенную часть защиты (вместе с ответственностью за результаты) в руки самих пользователей. Скажем, сервис синхронизации файлов Dropbox позволяет помещать в облачное хранилище зашифрованные пользователем файлы. «Заметочный» сервис Evernote проводит синхронизацию облачной и локальной баз данных на более детальном «субфайловом» уровне, поэтому здесь разработчики рекомендуют помещать всю БД на шифруемый диск (например, TrueCrypt).

Денис БЕЗКОРОВАЙНЫЙ, технический консультант, Trend Micro в России и СНГ: К затратам провайдера следует также отнести расходы на прохождение аудита и различных сертификаций, на квалифицированный ИБ-персонал, который в дефиците на рынке. Снизить затраты и риски провайдера поможет использование схемы pay-as-you-grow для оплаты решений ИБ. Это относительно новая система отношений с вендорами, при которой провайдер облачных услуг может начать предоставлять своим клиентам решения для защиты облачной инфраструктуры с нулевыми затратами. По мере роста клиентской базы провайдера растет количество защищаемых объектов, и только после этого происходит оплата фактически потребленных провайдером лицензий на средства ИБ.

Д. МАТИЕВ: Затраты на внедрение решений информационной безопасности для провайдера более высоки в случае с SaaS, но, как правило, услуга может быть эксклюзивной и высокомаржинальной. Внедрения систем безопасности окупаются очень быстро, затраты невысоки (не более 5% от стоимости облака), при этом надежная защита всегда привлечет больше потребителей. Минимизация рисков достигается за счет комплексного подхода к обеспечению инфобезопасности, основанного на лучших мировых практиках. Безусловно, при этом необходимо внедрить рабочую систему оценки и управления рисками.

Владимир ТКАЧЕВ, технический директор, VMware Россия и СНГ: Риски нельзя минимизировать, рисками надо управлять. Минимизировать риски можно, только отказавшись от ответственности по рискованным статьям, что приведет к сокращению перечня предоставляемых услуг или оттоку заказчиков из-за снижения качества услуг.

П у т е у к л а д ч и к и   з а   р у л е м

«ИКС»: Роль системных интеграторов на рынке безопасности публичных облачных услуг: в каких случаях привлечение «третьей стороны» неизбежно и почему?

Сергей ЩЕРБИНА, заместитель генерального директора, Esri CIS: Роль системных интеграторов в создании облаков и обеспечении их безопасности в целом аналогична их роли в других ИТ-проектах. Однако в данном случае в силу относительной новизны технологий и особых опасений относительно безопасности заказчикам имеет смысл подумать о проведении независимого аудита степени защиты своих данных и приложений.

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

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

Д. БЕЗКОРОВАЙНЫЙ: На западном рынке уже сформировалась ниша для компаний – «облачных брокеров». Это компании, предоставляющие услуги интеграции сервисов от различных облачных провайдеров и их совместного использования клиентами. Основные плюсы облачного брокера для заказчиков – возможность переключения от одного провайдера к другому в случае сбоев, оптимизация расходов и упрощение биллинга. В России можно ожидать появления облачных брокеров, если провайдеры будут готовы открывать интерфейсы интеграции для сторонних сервисов.

Валерий АНДРЕЕВ, заместитель директора по науке и развитию, ИВК: Все зависит от модели облака. Если вопросы ИБ будет решать пользователь, то интеграторам есть место, а если провайдер – то нет.

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

Антон РАЗУМОВ, руководитель группы консультантов по безопасности, Check Point Software Technologies: Чем сложнее система, тем больший опыт необходимо иметь для грамотного ее проектирования и внедрения. Именно опыт, просто теоретических знаний будет недостаточно. Кроме того, у новичка часто разбегаются глаза от многообразия решений, и для грамотного сравнения, выбора стратегии нужно изучить множество вариантов, в том числе и те, которые ему вовсе не пригодятся. Поэтому помощь системных интеграторов, имеющих опыт разнообразных проектов, позволяет сэкономить значительные средства, время и избежать критичных ошибок.

Михаил БАШЛЫКОВ, руководитель направления информационной безопасности, КРОК: Системный интегратор может сам выступать в роли провайдера публичного облака, обеспечивая безопасность облака в целом или опционально, в зависимости от вида услуг.

В п е р е д и   –   п о в о р о т

«ИКС»: Насколько реальна перспектива появления на рынке продуктов, способных безопасно интегрировать в облаках множество ИТ-приложений от разных поставщиков и провайдеров?

В. АНДРЕЕВ: Пока что совершенно нереальна. Даже на уровне функционала, не говоря уже о проблемах инфобезопасности. Отсутствие облачных стандартов не дает возможности интеграции, но все впереди.

Александр ТРОШИН, технический директор, «Манго Телеком»: Я пока не вижу таких продуктов на рынке. Но в то же время ничего нереального в их создании нет. И когда-нибудь их появление станет очень актуальным, так как множество различных нестандартизованных инструментов управления виртуальными средами могут однажды загнать пользователя в тупик. Думаю, лет через пять на рынок выйдут некие продукты, которые смогут определенным образом (например, с помощью API) взаимодействовать с разными провайдерами и управлять всеми разрозненными виртуальными продуктами.

В. МЕДВЕДЕВ: Необходимо создание резервных локальных сервисов на время недоступности облачных. Появление таких предложений вполне реально, но вот использование их не может быть рекомендовано. Например, антивирусы, использующие сторонние антивирусные ядра, даже при их высоком качестве в тестах на активные заражения показывают во многих случаях не самые высокие результаты.

А. КОЛЫБЕЛЬНИКОВ: На рынке такие продукты уже есть, и они давно и успешно используются. Например, системы сбора и анализа данных журналов событий работают с разными приложениями.

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

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

Источник: ИКС

Назад к разделу "Публикации"