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

И. Трифаленков («Ростелеком»): "Мощный набор механизмов защиты будет бесполезен, если на клиентской стороне не контролируется доступ к терминальным устройствам"

В чем разница между "безопасностью в облаке" и "безопасным облаком", и какие участки должен обезопасить сам пользователь облачных сервисов? Читайте полную версию Дискуссионного клуба темы номера "ИКС" №9'2012 "Дорожная карта облачной безопасности". Часть 6.

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

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

Валерий Андреев, заместитель директора по науке и развитию, ЗАО ИВК: Это движение очевидно, так как существует нормативный вакуум. Поэтому решение вопросов ИБ переносится на провайдера. Проблематика ИБ в облаке слишком сложна, чтобы ей занимался конкретный пользователь. Минимизация рисков провайдера ясна - обеспечение гарантии ИБ в облаке. Это реализуется только одним способом - аттестация решения регулятором (аттестованным органом). Но так как пока не решены нормативные вопросы, аттестовать "не на что".

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

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

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

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

Джабраил Матиев, руководитель группы информационной безопасности IBS Platformix: Применение стратегий «безопасности облака» или «безопасности в облаке» зависит только от модели предоставления облака: от IaaS к SaaS растет необходимость обеспечивать «безопасность облака» и падает необходимость обеспечивать «безопасность в облаке». Очевидно, что затраты на внедрение решений по информационной безопасности для провайдера более высоки в случае с SaaS, но, как правило, услуга может быть эксклюзивной и высокомаржинальной. Внедрение систем безопасности окупаются очень быстро, затраты не высоки (не более 5% от стоимости «облака»), при этом надежная защита всегда привлечет больше потребителей. Минимизация рисков достигается за счет комплексного подхода к обеспечению информационной безопасности, основанного на лучших мировых практиках. Безусловно, при этом необходимо внедрить рабочую систему оценки и управления рисками.

Владимир Ткачев, технический директор VMware, Россия и СНГ:  Стоимость обеспечения безопасности равномерно распределяется между всеми потребителями облачных услуг. Затраты на одного или 1000 заказчиков будут одинаковыми с точки зрения перечня организационных и технических средств. Надо понимать, что эти затраты неизбежны даже в случае, если провайдер будет просто предоставлять услуги хостинга или колокейшн - то, что является для провайдера привычным полем деятельности. Очевидно, что и рост количества потребителей услуги позволяет минимизировать затраты на заказчика. Риски нельзя минимизировать, рисками надо управлять. Минимизировать риски можно только отказавшись от ответственности по рискованным статьям, что приведет к сокращению перечня предоставляемых услуг или оттоку заказчиков из-за снижения качества услуг.

Илья Трифаленков, начальник отдела информационной безопасности ОАО «Ростелеком»: Проекты предоставления услуг для провайдеров существуют в целом. Либо услуга предоставляется, либо нет. Предоставить часть услуги нельзя. Поэтому вопрос окупаемости ИБ сам по себе лишен смысла – это часть комплексной услуги.

"ИКС": Какие риски, связанные с переходом к облачной модели предоставления услуг, пользователю облачных сервисов следует предусмотреть, какие «отступные пути» могут быть выбраны в случае несоблюдения трех правил ИБ (конфиденциальность, целостность, доступность)? Какие пункты необходимо отразить в SLA?

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

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

Михаил Готальский, генеральный директор TrueConf: Основное, о чем должны побеспокоиться пользователи облачных сервисов, это защита каналов связи и доступность данных. Возможно имеет смысл резервировать особо критичные сервисы. Естественно, что это все и нужно обязательно отразить в SLA: шифрование каналов; высокий уровень доступности услуг; политика резервного хранения данных; время восстановления после сбоев. Так же должны добавиться и другие пункты специфичные для бизнеса компании, например: полная анонимизация пользователей и сервисов: на каждый сервис свой логин, непохожий на другие распространенные; свой набор логинов контрагентов с непересекающимися связями (чтобы "по внешним связям не отследить идентичность внутреннего пользователя"); доступ через анонимизирующие прокси типа сети tor (если бы еще и качество каналов через tor в отечественном интернете было подобным западному!).

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

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

Денис Безкоровайный, технический консультант Trend Micro в России и СНГ: Задачи по обеспечению ИБ клиентами облачных сервисов сильно рознятся от того, какую модель облачных вычислений они используют – SaaS, PaaS или IaaS.
Рисков ИБ огромное количество, причем множество из них не являются техническими - «привязка» к инфраструктуре провайдера и невозможность перехода к другому в случае изменения условий, риск перепродажи (oversell) провайдером своих мощностей и, как следствие, ухудшение качества услуг и влияние на доступность сервиса, невыполнение требований законодательства по защите данных и многое другое.
Эти и другие риски хорошо описаны в таких документах как Cloud Computing Security Risk Assessment от ENISA и Top Threats to Cloud Computing от Cloud Security Alliance (CSA). Также в рамках CSA сформирована рабочая группа по вопросам SLA (Service Level Agreement), поэтому в ближайшее время будут рекомендации для клиентов и на эту тему.

Владимир Удалов, руководитель направления корпоративных продуктов в странах развивающихся рынков «Лаборатории Касперского»: Важнейшим участком, безопасность которого должен обеспечить сам пользователь, являются конечные устройства – рабочие станции и сервера. Именно на них в первую очередь должна быть установленная надежная защита. Если ее нет, и вредоносная программа находится на так называемом эндпоинте, все вводимые данные могут быть без труда перехвачены злоумышленниками.  Показательным примером является взлом компании HBGary, произошедший в 2011 году. Хакерам удалось получить доступ к корпоративной почте компании, базирующейся на сервисе GoogleAppsforBusiness. В результате весь архив почты был украден и оказался в публичном доступе.

Федор Гриценко, директор управления аутсорсинга ФК СЦ компании "Ай-Теко":  Пользователь облачных сервисов должен обезопасить в первую очередь участки, связанные с конфиденциальностью информации и идентификацией пользователей.Во вторую очередь необходимо обезопасить участки приложений и инфраструктуры. В случае, если провайдер не выполняет требований информационной безопасности, необходимых для данной компании, нельзя снижать планку требований. Необходимо выбирать более добросовестного и компетентного поставщика,обладающего  ресурсами для обеспечения необходимого уровня безопасности и необходимым опытом. При смене провайдера необходимо предусмотреть риски несоответствия форматов и потери данных, зафиксировав в SLA меры по обеспечению сохранности данных, сферы ответственности, параметры восстановления систем и доступа к данным. Важно предусмотреть риски, связанные с доступностью и непрерывностью, и хеджировать их путем резервирования сервисов.
Например, лучшей практикой для финансового сектора является  наличие в пункте SLA, касающемся вопросов информационной безопасности, описаний сертификации ФСТЭК средств защиты и аттестации информационных систем на трех уровнях: приложений, данных и инфраструктуры.

Антон Разумов, Руководитель группы консультантов по безопасности Check Point Software Technologies Ltd: Если поставщик услуг предоставляет выбор между обычным подключением к сервису и использованием защищенных каналов связи (VPN, SSL), разумеется, пользователь должен выбирать более защищенные варианты. Если в локальной сети зачастую достаточно шифровать пароли, но не сами данные, то при удаленных подключениях шифровать необходимо практически все.
Разумеется, обеспечение надежности, отказоустойчивости, сохранности данных - это ответственность поставщика. Однако многие системы позволяют пользователям, к примеру, экспортировать базу клиентов. И подобные дополнительные меры для создания резервных копий, которые пользователь может предпринять самостоятельно, будут совсем не лишними.
SLA, разумеется, должен быть хорошо проработан. Однако следует понимать, что каким бы жестким SLA ни был, рассчитывать на 100% аптайм не стоит. Сбои бывают. И совместно с поставщиком услуг важно предусмотреть различные сценарии, включая определенную финансовую ответственность. Хотя, как правило, максимум, что удается получить - это снижение платы за время простоя.

Александр Бондаренко, технический директор компании LETA: При использовании облачного сервиса потребителю стоит помнить следующее. Вы передаете свою информацию и используете сервисы сторонней компании, а значит от качества и надежности ее работы будет зависеть качество и надежность вашей собственой работы. Поэтому первая рекомендация – это вдумчивый выбор поставщика облачного сервиса. К этому вопросу следует отнестись со всей серьезностью.  Проработав какое-то время с определенным сервис-провайдером, вам будет очень сложно его сменить. Информацию не всегда можно легко переконвертировать в формат другого сервис-провайдера (как правило, это просто невозможно). А что, если сервис-провайдер обанкротится или у него произойдет масштабный сбой с потерей информации ? Идеальный вариант - когда сервис-провайдер предоставляет возможность выгрузки/бекапирования всей информации, а также возможностью развертывания собственной локальной версии (частного облака по сути). Пример – онлайн-система Мегаплан, вы можете воспользоваться ей по модели SaaS, а можете приобрести как программный продукт и развернуть в своей ИТ-инфраструктуре, что может быть резервным вариантом на случай недоступности онлайн-версии. 
 Вопрос соблюдения требований законодательства: если вы планируете использовать сервис для обработки данных кредитных карточек, то необходимо предварительно убедиться, что сервис-провайдер соответствует требованиям международных стандартов PCI DSS и PA DSS. Если мы говорим об отечественном законодательстве, в первую очередь о законе «О персональных данных», то здесь все становится еще сложнее, т.к. по формальным признакам практически ни один облачный сервис в настоящий момент не может полностью выполнять требования законодательства в силу их чрезмерной жесткости (хотя некоторые провайдеры и заявляют, что они соответствуют, но это мягко говоря лукавство).

Неманья Никитович, управляющий директор OptimaInfosecurity (Группа Optima):  В зависимости от того, что именно вы хотите защитить и какой уровень этой защиты предполагаете, зоны ответственности должны быть прописаны сначала в ТКП, а после – в SLA, с учетом уровня сервисной поддержки, оговоренной с заказчиком. В SLA необходимо прописать разграничение зон ответственности и штрафные санкции. Стоит отметить, что в случае с «облачными» сервисами  зачастую в SLA действуют три стороны: заказчик, поставщик «облачных» сервисов и интернет-провайдер. Банальное отключение Интернета по вине магистрального оператора может сделать работу с «облачными» ресурсами невозможной в принципе. Поэтому жесткие условия ответственности в соглашениях с поставщиками — обязательные элементы безопасности в «облаках».

Джабраил Матиев, руководитель группы информационной безопасности IBS Platformix: Если попытаться дать универсальный ответ на вопрос, то можно сказать, что пользователь облачных сервисов (будем говорить о SaaS) должен обеспечить сохранность аутентификационных данных и убедиться в достаточной защищенности устройства, с которого происходит доступ. После недавних заявлений об открытии бот-сети на базе Android-фонов можно понять, что мобильные платформы не являются доверенной средой. Поэтому убедиться в том, что устройство защищено, не так-то просто. На сегодняшний день большинство компаний сталкиваются с рядом типовых рисков: недоступность облачного сервиса (нарушение каналов передачи данных, проблемы на стороне провайдера), перехват передаваемых данных между облаком и пользователем, потеря данных и т.д. Нивелировать все эти риски позволяет использование гибдридных облаков, в частности использование облака в качестве резервной площадки.

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

Владимир Ткачев, технический директор VMware, Россия и СНГ: Рекомендация - очень внимательно отнестись к соглашению с провайдером и учесть в нем абсолютно все аспекты предоставления услуг и именно в том объеме, в котором заказчик ожидает их получать, независимо от того облачный это сервис или нет.

Михаил Башлыков, руководитель направления информационной безопасности компании КРОК: На пользователей ложится задача по обеспечению безопасности объектов и сервисов, которые они настраивают и поддерживают самостоятельно в облаке.

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

Илья Трифаленков, начальник отдела информационной безопасности ОАО «Ростелеком»: Есть элементы, которые в любом варианте остаются на стороне пользователя. Это терминалы в том или ином виде. Можно организовывать мощный набор механизмов защиты, который будет бесполезен в случае, когда на клиентской стороне не контролируется, кто и как получает доступ к терминальным устройствам. Что касается рисков облачной модели, то они известны – это риски, связанные с оператором, и риски, связанные с другими пользователями облачных услуг. Необходимо заметить, что наличие дополнительных типов рисков не обязательно ведет к усилению интегральных рисков, поскольку в облачной архитектуре типовые риски могут быть существенно снижены. Условием этого является четкое распределение зон ответственности оператора и пользователя отражение в SLA максимально конкретных требований и метрик безопасности.