Rambler's Top100
Статьи ИКС № 09 2012
Лилия ПАВЛОВА  18 сентября 2012

Бетонный блок на облачном шоссе

Перспективы растущего в разы российского рынка облачных услуг аналитики оценивают оптимистично. Так, согласно IDC, в прошлом году его объем составил $90 млн, в нынешнем удвоится, а в следующем достигнет $360 млн. Две трети этих денег ($60 млн) принадлежат частным облакам и гибридным, а оставшиеся $30 млн – очень скромная по меркам национального рынка сумма – публичным облакам. Это соотношение, вероятно, сохранится и в ближайшие годы при общем росте рынка.

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

Раскручивают маховик облачного рынка три основные силы – разработчики решений, системные интеграторы, провайдеры облачных услуг (порой все три «в одном юрлице»), они же и заинтересованы в преодолении пресловутого «бетонного блока». Что, кстати, хорошо иллюстрирует состав экспертов «ИКС» – огромную заинтересованность проявили представители этой «тройки» (чего никак не скажешь о заказчиках облачных услуг), причем драйверы рынка продемонстрировали конструктивность в критике друг друга.

Кто готов к защите облаков?

По большому счету, готовность большинства участников рынка к защите облаков до сих пор далека от идеала, признают эксперты, но степень ее для каждой из трех сторон оценивают по-разному. Например, А. Гарусев (CDNvideo) считает, что сейчас наиболее готовы именно сервис-провайдеры, поскольку для провайдера нарушение требований безопасности – это огромный репутационный риск, который может обернуться даже выходом из бизнеса. Ни одна другая сторона не мотивирована в такой степени, считает эксперт, отмечая также, что у серьезных провайдеров все аспекты деятельности максимально автоматизированы, все находится под двойным и тройным перекрестным контролем специальных программно-аппаратных комплексов. В то же время, полагают другие эксперты, провайдеры не готовы брать на себя ответственность и давать гарантии сохранности переданной им информации и доступности оказываемых услуг. Они также не стремятся раскрывать свои внутренние процессы по организации информационной безопасности, что тормозит подключение к их услугам крупных компаний.

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

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

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

Б е з о п а с н а я   м и г р а ц и я   в   о б  л а к о

Конспект «дорожной карты»

1. Сервисы коммуникаций

2. Медиа

3. Сервисы услуг

4. Сервисы планирования и контроля проектов

5. Сервисы обмена знаниями по проектам

6. Сервисы предоставления контента по теме

7. Бизнес-приложения.


Источник: рекомендации экспертов по данным опроса «ИКС»

В поисках опоры

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

А сейчас, по мнению экспертов, опорой могут служить стандарты и рекомендации по обеспечению информационной безопасности в облачных средах. Их разработано немало. Одним из самых респектабельных можно назвать набор документов Cloud Security Alliance (CSA). Д. Безкоровайный (Trend Micro) отмечает, что во всем мире лучшие практики CSA уже используются как отправная точка для клиентов и облачных провайдеров, задумывающихся об обеспечении ИБ. Сейчас эта организация ведет активную работу с ISO для расширения более общих стандартов ISO 2700x и включения в них вопросов, касающихся безопасности в облаке. Опираясь на серию ISO 27000, можно уже сейчас построить полноценную систему инфобезопасности и управления ею как для провайдеров облачных услуг, так и для их клиентов, считают эксперты. Кроме того, рекомендации по обеспечению безопасности облаков изложены в документах ряда организаций – ISACA, ENISA, BSI, в стандартах NIST.

Дальнейшее развитие стандартов будет идти по двум направлениям: для технологий (например, предписывающие стандарты самого верхнего уровня, обеспечивающие интеграцию для SOA) и для провайдеров (оценочные стандарты деятельности организации). Кроме того, сейчас разрабатываются международные стандарты инфобезопасности для облачных вычислений и модели SaaS, выход первых версий которых ожидается в 2013 г. По мнению Д. Безкоровайного, в разработке единого стандарта ИБ для всех сфер применения облачных вычислений нет необходимости, поскольку задачи и обрабатываемые данные в облаках могут существенно отличаться; клиенты и провайдеры сами должны выбирать необходимые требования к защите данных, исходя из их критичности, важности обеспечения их целостности и доступности.

Д. Митрофанов считает, что нам нужны стандарты, учитывающие и российскую специфику, и лучшие мировые практики, и требования законодательства. Разрабатывать их должны крупные и авторитетные объединения компаний, центры компетенций, отраслевое лобби. В. Медведев («Доктор Веб») уверен, что не хватает не стандарта по обеспечению безопасности — не хватает общедоступных методик и процедур работы (аналога процедур ITIL); не хватает специалистов на местах, имеющих высокую квалификацию, достаточную для обеспечения безопасности клиентов; не хватает, наконец, некоего сертифицирующего органа — добровольной организации, сертификат которой гарантировал бы клиенту качество услуги. Тем не менее появление специализированного стандарта позволит унифицировать принципы и подходы к защите облаков, а также устранит терминологическую путаницу в понятиях, которая всегда имеет место при появлении новых технологий, уверен М. Башлыков (КРОК). В поддержку этого мнения А.Санин (Avanpost) отмечает, что к настоящему времени в облачной безопасности уже накоплена база знаний, которую требуется структурировать, иначе она станет тормозом дальнейшего развития.

IaaS, PaaS, SaaS:  специфика спроса и безопасности

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

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

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

Наконец, специфика государственных компаний – регулирование их деятельности различными ГОСТами и предписаниями, которые нередко сложно реализовать в рамках облачных структур, особенно если организация имеет дело с гостайной. Этим, по мнению экспертов, и объясняется гораздо более низкий уровень информатизации «определенных ведомственных структур» в сравнении с крупными коммерческими компаниями, для которых нет таких ограничений. Тем не менее с точки зрения инфобезопасности крупные компании и госструктуры роднят повышенные требования к стабильности, пропускной способности и скорости обработки больших объемов данных. Ф. Гриценко («Ай-Теко») отмечает, что поставщики облачных сервисов, предоставляемых госструктурам и крупному бизнесу, должны иметь сертификаты соответствия в основном оценочным стандартам – ISO 27001, SAS 70, PCI DSS, Cobit. Для ИТ-сервисов, предоставляемых через Интернет с использованием шифровальных средств, в ряде случаев требуются и лицензии ФСБ, сертификация средств защиты ФСТЭК. аттестация информационных систем на соответствие определенному уровню информационной безопасности обязательна для систем обработки и передачи данных, составляющих коммерческую или государственную тайну.

Надо сказать, что с созданием национального облака О7 госструктуры становятся полноценными участниками рынка: электронное правительство должно базироваться на облачной платформе (будь то приложения, платформа или инфраструктура). По мнению С. Щербины (Еsri CIS), многие ключевые направления развития государственных ИТ очень органично ложатся в облако (например, СМЭВ). Кроме того, облака способны существенно приблизить реализацию идей стандартизации подходов и технологий ведомственных ИТ-систем, дать доступ к прикладным сервисам и данным пользователям на всех уровнях (федеральном, региональном, муниципальном), считает эксперт.

Таким образом, специфика безопасности для трех облачных моделей обусловлена уровнем контроля над элементами облачной инфраструктуры (к слову, самой непопулярной, по данным IDC, у нас оказалась модель PaaS с 4% общего объема рынка – против 58% у SaaS и 38% у IaaS). Предложенное Д. Матиевым распределение ответственности выглядит следующим образом:

SaaS: пользователь – 1% (конфиденциальность аутентификационных данных), провайдер – 99% (обеспечение всех уровней защиты);

PaaS: пользователь – 20% (защита приложения), провайдер – 80% (защита инфраструктуры и платформ);

IaaS: пользователь – 80% (защита приложений и платформ), провайдер – 20% (защита инфраструктуры).


Другими словами, в SaaS пользователь несет ответственность только за данные, загружаемые в облако, причем за их сохранность тоже отвечает провайдер. Именно поэтому эксперты, считающие провайдеров наиболее готовыми обеспечить защиту в облаках, полагают, что модель SaaS отличается большим уровнем безопасности, нежели PaaS и IaaS, поскольку практически снимается угроза нарушений со стороны пользователей. Однако сама компания, как правило, не имеет никакой возможности повлиять на перечень мер для обеспечения безопасности платформы – это и отталкивает крупные организации, привыкшие полностью контролировать инфраструктуру. При этом, отмечают эксперты, в модели SaaS обеспечить надежную и гарантированную защиту информации при использовании публичных облачных услуг может сильная посредническая организация, которая берет на себя функции регулятора в отношениях поставщиков и получателей услуг и обеспечивает безопасный информационный обмен. Например, в США такой организацией является Global Service Administration. В России аналогичные функции, будучи оператором электронного правительства, взял на себя «Ростелеком» .

Непопулярность PaaS, которая представляет собой основу для миграции в облака не данных, но приложений, эксперты объясняют сложностью четкого разграничения рисков ИБ, поскольку в такой системе возникает два типа контроля доступа: пользователь – приложение (обеспечивается пользователем) и приложение – сервер приложений (обеспечивается провайдером).

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

Таким образом, подходы к обеспечению безопасности в разных облачных моделях весьма различны. При этом эксперты подчеркивают: требования безопасности в них не должны отличаться. Как отметил В. Медведев, по сути все три модели описывают лишь разный уровень доступа администраторов клиентов к предоставляемым ресурсам, но кто бы ни отвечал за те или иные части услуги (виртуальную машину, операционную систему, действующий на базе ОС сервис и др.), требования, предъявляемые к безопасности, в общем не отличаются. Разница состоит лишь в том, кто должен реализовывать те или иные меры безопасности.

Вы еще не в облаке?..

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

Разумеется, задачи обеспечения безопасности облачных сервисов сильно разнятся в зависимости от того, какова их модель облачных вычислений. Как отмечает Д. Безкоровайный, рисков безопасности огромное количество, причем множество из них не являются техническими – привязка к инфраструктуре провайдера и невозможность перехода к другому в случае изменения условий, риск перепродажи (oversell) провайдером своих мощностей и, как следствие, ухудшение качества услуг и влияние на доступность сервиса, невыполнение требований законодательства по защите данных и многое другое. Эти и другие риски хорошо описаны в таких документах, как Cloud Computing Security Risk Assessment от ENISA и Top Threats to Cloud Computing от Cloud Security Alliance, к которым советует обратиться эксперт. Кроме того, в рамках CSA сформирована рабочая группа по вопросам SLA (Service Level Agreement), и в ближайшее время ожидается выпуск рекомендаций для клиентов и на эту тему.

Наши эксперты, со своей стороны, предлагают рекомендации не только по составлению SLA, но и по переходу на облачные модели, а также по миграции сервисов в облако. Конечно, следует учесть, что разные модели облака предусматривают и разные подходы к миграции. Например, при формировании частного облака с моделью IaaS основной уклон сделан в сторону формирования высокодоступного, отказоустойчивого и производительного ЦОДа. В этом случае переносятся в первую очередь информационные сервисы организации (почта, бухгалтерия и пр.). Важно также провести аудит информационных ресурсов организации на предмет необходимости (целесообразности) миграции унаследованных приложений в облако. Кроме того, во многом очередность зависит от отрасли. Тем не менее опыт экспертов позволяет сформулировать рекомендации, применимые для разных компаний, независимо от отраслей и объемов их деятельности.

Хочется верить, что общие усилия пригодятся в деле сдвигания «бетонной плиты».  

С о с т а в л я е м   S L A  

При заключении договора с поставщиком облачных услуг прописываются:

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

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

3. Действия на случай несоблюдения трех правил инфобезопасности (целостность услуг, доступность услуг, конфиденциальность информации клиента).

4. Шифрование каналов.

5. Уровень доступности услуг.

6. Политика резервного хранения данных.

7. Время восстановления после сбоев.

8. Полная анонимизация пользователей и сервисов: у каждого сервиса должен быть свой логин, непохожий на другие распространенные.

9. Свой набор логинов контрагентов с непересекающимися связями (чтобы «по внешним связям не отследить идентичность внутреннего пользователя»).

10. Доступ через анонимизирующие прокси типа сети tor.

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

12. При смене провайдера – меры по обеспечению сохранности данных, сферы ответственности, параметры восстановления систем и доступа к данным.

13. Быстрый разрыв по инициативе клиента без каких-либо санкций и безусловный возврат всех клиентских данных с гарантией удаления из СХД провайдера.


Источник: рекомендации экспертов по данным опроса «ИКС»

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: