Пару лет назад опасения относительно защищенности облачных вычислений считались одной из основных причин недостаточно динамичного развития рынка облачных вычислений. В российских условиях объективные сложности с обеспечением ИБ в облаке были помножены на консерватизм отечественных ИТ-директоров. Основной контраргумент с их стороны состоял в том, что использование любых облачных сервисов ведет к размыванию периметра безопасности корпоративных ИТ. Другими словами, даже небольшой шаг в сторону облачных сервисов (например, перенос системы электронной почты в облако) негативно влияет на информационную безопасность.
ИБ перестает быть внутренней задачей отдельно взятой компании и в числе прочего оказывается в зависимости и от действий провайдера, к которому, скорее всего, нет полного доверия. Впрочем, в этом контексте уместно вспомнить системных интеграторов, почему-то не вызывающих у CIO чувства опасности. Между тем степень открытости всех основных бизнес-процессов компании для посторонних глаз при установке, скажем, ERP-системы несоизмеримо выше. Давайте попробуем разобраться в ситуации. Может, страх по отношению к облачным технологиям — это боязнь собственной тени?
ЗВЕНЬЯ, УРОВНИ, СЛОИ
В обеспечении информационной безопасности облачных услуг участвуют три стороны: разработчик, провайдер и потребитель. Каждый из них вносит свой вклад в защиту сервиса и данных клиента. Основная нагрузка при этом ложится на провайдера облачных услуг. Сами сервисы реализуются на базе собственного или арендуемого (полностью либо частично) центра обработки данных. На данном этапе меры по обеспечению ИБ облачного сервиса мало отличаются от реализуемых хостинг-провайдерами, а потому практически всецело зависят от принятых в центре обработки данных. Поэтому и выбор облачного провайдера во многом похож на выбор хостера и привязан к качеству ЦОД.
Таким образом, при оценке безопасности сервиса того или иного облачного провайдера будет нелишним спросить, в каком ЦОД находится его оборудование. ЦОД должен быть защищен от ?падений? канала связи, от перебоев с электропитанием, от каких-то вероятных для данной местности катастроф (например, центры японского провайдера Tsukaeru.net в Нагано построены с таким расчетом, чтобы не останавливаться даже во время землетрясения средней силы), а также от физического повреждения оборудования в результате аварий, неосторожных действий персонала или диверсии злоумышленников.
Необходимые меры физической защиты (несколько периметров безопасности на территории центра обработки данных, разграничение доступа персонала в зависимости от предоставленных полномочий, разделение гермозон специальными ?клетками?, чтобы в секцию не проник посторонний системный администратор, и т. д.) хорошо известны, поэтому останавливаться на них смысла нет. Несмотря на их очевидность, в России не так много ЦОД, где эти меры реализованы на должном уровне. Выяснив у облачного провайдера, в каком ЦОД располагается его сервис, можно сделать достаточно достоверный вывод о надежности облачной услуги.
DDOS: КАТАКЛИЗМ ЗА МАЛЫЕ ДЕНЬГИ
?Толстый? канал связи для облачного провайдера — насущная необходимость: облачные сервисы принимают и отправляют данные через Сеть, поэтому предусмотреть защиту от сетевых атак так же важно, как обеспечить безопасность физических границ. В ЦОД поставщиков облачных услуг для противодействия атакам эффективно используется опыт все тех же хостеров. В этой связи следует упомянуть одну очень характерную российскую, да и не только, проблему в области сетевой безопасности. Это атаки DDoS, которые, судя по регулярным и шумным историям с LiveJournal, стали чрезвычайно популярны у злоумышленников.
Насколько можно судить по доступной информации, атака продолжительностью два-три дня стоит несколько тысяч долларов. Последствия такой диверсии для облачного провайдера могут оказаться плачевными — вплоть до полного разорения в результате массового обращения клиентов за денежной компенсацией по условиям SLA. Поэтому облачный ЦОД нужно обезопасить от атак DDoS. Делается это аппаратными средствами, в частности с использованием Juniper NetScreen и Cisco Guard DDoS. С их помощью в потоке трафика распознаются и блокируются запросы, похожие на DDoS. Такое оборудование должно быть установлено и в ЦОД, и у провайдера, которому принадлежит канал связи от центра обработки данных. Иначе толку будет мало.
Защита от вторжения через порты TCP/UDP осуществляется с помощью брандмауэров — как программных, так и аппаратных. Эта стандартная и хорошо известная технология применяется даже в домашних маршрутизаторах. Здесь же стоит упомянуть и IDS/IPS — ?поведенческие? системы, которые способны выявлять аномалии трафика, характерные для попыток вторжения, и отсекать их еще на дальних подступах.
По-настоящему эффективная защита достигается только путем применения комплексных мер. Соответствующий арсенал стоит очень дорого —покупка нужного оборудования и ПО может потребовать сотен тысяч, а то и миллионов долларов (без учета расходов на интеграцию). По этой причине публичные ?облака? безопаснее для малых и средних (до 500 человек) компаний, нежели инфраструктура и Web-сервисы, развернутые и поддерживаемые силами внутреннего департамента ИТ. Небольшие предприятия просто не смогут изыскать средства на обеспечение достойного уровня ИБ. В результате столь важная задача будет решена ?как придется? —ar заведомо хуже, чем в облачном центре обработки данных.
ВСЕ ПРОТИВ ВСЕХ
В коммерческих (или в публичных) облаках заключается неявный внутренний риск — клиенты облака представляют потенциальную опасность друг для друга. Кстати, именно поэтому услуги SaaS из публичного облака являются гораздо более безопасными для использования, нежели PaaS и IaaS. (Конечно, при условии, что ПО как услуга не содержит уязвимостей, снабжено базовой защитой от взлома, архитектурно и на уровне кода поддерживает изоляцию учетных записей.) Дело в том, что платформенные и инфраструктурные сервисы позволяют привносить в облако практически любое программное содержимое, вплоть до приложений с обилием уязвимостей и вредоносного кода. ?Чистый? SaaS таких вольностей не предполагает, поскольку работа идет только с пользовательскими данными.
Таким образом, пользователям стоило бы больше остерегаться Amazon EC2 и ему подобных провайдеров (где через бреши в системе безопасности одного Webприложения злоумышленники могут нарушить стабильность всего облака и работающих в нем сервисов клиентов), а не решений наподобие SalesForce или, например, ?Асофт CRM?, где модификация кода исключена, а все операции сводятся только к обработке загружаемых пользователем данных либо (в самом демократичном случае) к использованию клиентами сервиса API.
КАК ГАРМОНИЗИРОВАТЬ КОД В ОБЛАКАХ?
Вольности, допустимые в рамках IaaS и PaaS, умножают риски облачных провайдеров и их клиентов. Во избежание этого, на наш взгляд, облачной индустрии следует как можно скорее принять общий стандарт на облачные приложения. Такой стандарт должен гармонизировать контент, привносимый клиентами в облако, но при этом не должен ставить разработчиков приложений в жесткие рамки и вынуждать применять для создания ПО какие-либо конкретные инструменты.
Работу в этом направлении Parallels начала еще в начале 2000-х. В результате в 2004 году появился Application Packaging Standard (APS) и предложены спецификации, при использовании которых на разработчиков облачного ПО не налагалось бы никаких ограничений, кроме ряда несложных операций при осуществлении так называемой упаковки приложений для их последующего распространения через облака хостеров и телеком-провайдеров, у которых программное обеспечение для автоматизации поддерживает APS.
На данный момент спецификации APS приняты сотнями разработчиков ПО во всем мире. В каталоге представлено больше тысячи приложений. Общее количество загрузок APS-пакетов превысило 1 млн. Процедура сертификации предусматривает проверку готового пакета вместе с включенным в него приложением на качество кода и скрытую функциональность. Конечно, сертификация не гарантирует абсолютной защищенности облачного ПО, но при таком подходе облачное APS-совместимое программное обеспечение оказывается намного безопаснее для провайдера (а значит, и для его клиентов), поскольку при работе в рамках стандарта объединены усилия вендора и контрибьютора APS.
ПОЛЬЗОВАТЕЛЬ — САМОЕ СЛАБОЕ ЗВЕНО
Провайдеры, предлагающие инфраструктуру или платформу в аренду из облака, отнюдь не случайно уделяют повышенное внимание изоляции разных виртуальных сред. Это делается для того, чтобы крушение сервиса у одного клиента никак не сказалось на работоспособности Web-приложения у других. Конечно, самый лучший способ — выделение отдельного физического сервера для каждого клиента. Но на практике облачные провайдеры никогда так не поступают, тем более что в столь радикальных мерах особой необходимости нет. Современные подходы к виртуализации — контейнерной и гипервизорной — обеспечивают практически полную изоляцию.
Другое дело, что к ряду приложений не всегда можно применить виртуализацию и изоляцию. Речь идет о многопользовательских (multi-tenant) сервисах, которые используются главным образом во внутренних облаках. Такие приложения представляют собой, образно говоря, один большой бассейн, откуда пользователи черпают столько воды (читай — ресурсов), сколько им нужно в конкретный момент.
При этом ?бассейн? не поделен поровну между всеми потребителями. Яркий пример такого приложения — СУБД, работающая в большом кластере. Большие размеры и архитектурные особенности не позволяют поместить ее в виртуальную машину. Поэтому клиенты (они же — пользователи этой СУБД) могут разделяться только по имени и паролю — именно в этот момент, при вводе этой информации, клиент облачного сервиса сталкивается с первым звеном цепочки обеспечения ИБ, задача которого — сохранить аутентификационные данные.
Если само приложение и критически важные данные находятся в облаке, а информация для авторизации хранится на офисном или домашнем компьютере, не оснащенном антивирусом, то даже самый мощный арсенал облачной защиты будет бессилен. Данные могут быть украдены или утеряны — практически так же, как банковская карта. Конечно, банк никакой ответственности за инцидент не несет. Максимум, чем он сможет помочь, — заблокировать счет.
В цепи облачной ИБ самым слабым звеном является пользователь. Этот тезис подтверждается исследованием, проведенным организацией Software Engineering Institute: 46% респондентов признают урон от действий инсайдеров намного более существенным, чем внешние угрозы.
ЮРИДИЧЕСКИЕ АСПЕКТЫ
Федеральный закон № 152 ?О защите персональных данных?, который вступил в силу в середине 2011 года, вызвал неоднозначную реакцию в профессиональном ИТ-сообществе. В частности, в рамках мер по сохранению личной информации сотрудников и контрагентов предусматривается сертификация программноаппаратных комплексов для подтверждения безопасности их использования. И хотя сейчас, спустя несколько месяцев, до сих пор нет единого мнения по поводу необходимости данного закона, на наш взгляд, ФЗ-152 — все-таки благо.
Несмотря на то что закон ориентирован на обеспечение сохранности персональных данных, его можно расценивать как шаг в сторону правильной организации защиты информации. Ведь сертификация на соответствие его положениям так или иначе затронет всю ИТ-инфраструктуру компаний и облачных провайдеров. Конечно, нельзя говорить, что один лишь факт наличия сертификата гарантирует полную защищенность облачного сервиса, но по крайней мере вы будете уверены, что компания осознает возможность угроз и приняла какие-то меры к защите данных.
Российский рынок услуг по аренде ресурсов и сервисов из облака растет более чем на 100% в год. Через несколько лет он неминуемо окажется у точки, которую уже прошли облачные рынки Америки, Европы и Азии: конкуренция будет происходить не на уровне услуг и цен (как сейчас), а на уровне предоставления услуг (Service Level Agreement, SLA), то есть провайдеры будут соревноваться в надежности предоставляемых гарантий для клиентов и масштабах компенсаций за остановку сервиса или потерю данных.
В новых условиях будет выигрывать тот, кто предложит самые жесткие по отношению к себе (и, соответственно, самые лояльные по отношению к клиенту) условия SLA. Однако, для того чтобы SLA стал важнейшим фактором при выборе облачного сервиса, рынку нужен первый громкий прецедент. Таковым могла бы стать история с сервисом приема онлайн-платежей ?Ассист?, из-за ?падения? которого ?Аэрофлот? целые сутки не мог продавать свои билеты через Интернет. Ущерб авиаперевозчика тогда оценили почти в 100 млн рублей, но скандала не получилось. ?Аэрофлот? поручил эту работу ?АльфаБанку?, и историю замяли.
Тема SLA может быть воспринята действительно серьезно в случае значительных последствий для всех сторон.
Чем выше возможная сумма выплат, тем больше внимания будет уделяться сервису. Подобные истории обязательно заставят потенциальных клиентов облаков выбирать SaaS не только из-за цены.
Алексей Белкин — директор по работе со стратегическими клиентами в России и СНГ компании Parallels. С ним можно связаться по адресу: abelkin@parallels.com.