'Безопасность облачных сред' (PC Week, май 2012 г.)

23.07.2012

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

Согласно прогнозам IDC, использование облачной архитектуры в нашей стране в ближайшие годы будет расти экспоненциально и к 2015 г. объем российского рынка облачных сервисов достигнет 1,2 млрд. долл. Недавнее исследование, инициированное корпорацией Microsoft, показало, что больше половины отечественных владельцев среднего и малого бизнеса (СМБ) считают, что облачные технологии станут основой ИТ-инфраструктуры их компаний в самом ближайшем будущем. Однако при столь оптимистичных оценках перспектив развития облаков вопросы их безопасной эксплуатации по-прежнему вызывают беспокойство у пользователей.

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

Основные факторы влияния на ИБ облачных сред

Как отмечает Валерий Корниенко, руководитель по стратегическому развитию сервисного бизнеса, “IBM в России и СНГ”, постепенно происходит смена концепции информационной безопасности от идеи защищенного периметра к облачной модели защиты приложений, данных и сервисов. На практике при миграции в облака потребуется найти баланс между централизованными мерами обеспечения ИБ, ответственность за которые несет поставщик инфраструктурных услуг, и локальными, обеспечиваемыми клиентом.

Соответственно первое, что нужно сделать при построении защиты облаков, это определить, кто и какие ресурсы облака контролирует. Это обусловлено самой организацией облаков, отмечает системный архитектор центра ИБ компании “Инфосистемы Джет” Юрий Сергеев. Так, предоставляя IaaS-услуги, провайдер не может контролировать действия клиента, связанные с установкой дополнительных программных компонентов и их настройкой с учетом требований ИБ. Провайдер PaaS-услуг не может гарантировать, что клиенты должным образом (с позиции обеспечения ИБ) будут разрабатывать свое ПО на предоставляемой платформе. Провайдер SaaS-услуг, в свою очередь, не может контролировать корректность организации доступа на клиентской стороне.

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

Потребителю облачных ИТ-услуг, как предупреждает директор по ИБ “Microsoft в России” Владимир Мамыкин, по-прежнему нужна сильная собственная ИБ-команда, но с другими, нежели ранее, компетенциями и с более высоким статусом в компании. Она должна уметь:

  • управлять ИБ-рисками в условиях неполного контроля за процессами обработки информации;
  • интегрировать ИБ-контроль во внутренние процессы провайдера и своей организации;
  • взаимодействовать с провайдерами облаков на основе формальных контрактов.

В облаках, как отметил Евгений Царев, начальник отдела решений ИБ компании “Техносерв”, меняется парадигма организации ИБ — с защиты среды на защиту информационных активов, и клиенты хотят иметь требуемый уровень безопасности этих активов. При таких условиях, по его выражению, архитектурные и технологические факторы влияния на ИБ уходят в облаках на второй план на фоне организационных. В облаках большую роль начинают играть правовые аспекты и разделение ответственности между клиентом и провайдером облачных сервисов, что порождает множество вопросов, связанных с организацией процесса предоставления и потребления ИТ-услуг. Когда клиент передает обработку данных на аутсорсинг или инсорсинг, он не в состоянии проконтролировать все процессы обработки информации, которую хочет (или должен) защищать, поэтому разделить ответственность за обеспечение ИБ бывает непросто.

Оба — клиент и провайдер — заинтересованы, как подчеркивает ведущий инженер департамента информационной безопасности “Ай-Теко” Иван Бадеха, в максимальной детализации предоставляемых услуг и формальном закреплении ответственности. Грамотно составленные договор на оказание услуг и соглашение об уровне обслуживания (SLA), по его мнению, могут иметь решающее значение при возникновении спорных ситуаций.

Заместитель руководителя направления “Защита виртуальных инфраструктур” компании “Код безопасности” Мария Сидорова отмечает, что больше всего споров вокруг аспектов облачной ИБ вызывает доверие к провайдеру услуг, с которым клиент разделяет ответственность за ИБ. При выборе провайдера она рекомендует придерживаться мирового опыта, сформировавшегося на сегодняшний день. В числе рекомендаций, какие требования следует предъявлять к облачным провайдерам, она называет документы Cloud Computing Information Assurance Framework (ENISA), Security Recommendations for Cloud Computing Providers (BSI), The Cloud Security Alliance Consensus Assessments Initiative (Cloud Security Alliance) и Security Assessment Provider Requirements and Customer Responsibilities (NIST).

Среди факторов, затрудняющих защиту облачных сред, г-н Сергеев, называет минимальный уровень ответственности по SLA со стороны провайдеров, а также отсутствие:

  • зрелых стандартов, классифицирующих облачные среды и регламентирующих их взаимодействие с другими системами;
  • или недостаточный функционал защиты информации в интерфейсах прикладного программирования (API), предназначенных для взаимодействия с облаком — аутентификации, авторизации, шифрования, аудита и мониторинга;
  • устоявшейся практики реализации в облачных средах действующих ИБ-стандартов;
  • интероперабельности различных облачных сервисов друг с другом;
  • организационной и технической возможности контроля состояния защищенности информации у клиентов.

Критерии ИБ для облачных сервисов

Общие ИБ-критерии — конфиденциальность, целостность и доступность информации — по мнению наших экспертов, остаются неизменными и для облаков; задача заключается в том, как соответствовать этим критериям в новых условиях.

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

Г-н Бескоровайный напоминает, что на сегодняшний день наиболее полное описание основных мер и процессов ИБ, которые должны быть реализованы провайдером облачной услуги и клиентом, дано в документах организации Cloud Security Alliance — Cloud Control Matrix и Consensus Assessments Initiative Questionnaire (последний доступен на русском языке на сайте ассоциации RISSPA — российском отделении Cloud Security Alliance). В этом документе структурированы сведения о мерах защиты и процессах ИБ, интересующих клиента облачных сервисов, затрагивающие основные области: физическую безопасность, управление доступом, проверку персонала, планирование аудита, программу управления ИБ, юридические вопросы, технические средства обеспечения ИБ и защиты данных, вопросы безопасной разработки приложений, обеспечение непрерывности бизнеса и многие другие.

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

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

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

В организацию защиты частных облаков Сергей Рябко, генеральный директор компании S-terra CSP, предлагает закладывать следующие общие принципы. Прежде всего корпоративное облако, несмотря на заявления консультантов о “нечетком” и “размытом” периметре современных корпоративных систем, должно быть периметризовано. При этом следует помнить, что периметр существует только тогда, когда каждый допущенный в облако субъект идентифицирован. Периметр может быть структурированным, многоуровневым, с различными зонами доверия.

Далее, корпоративное облако должно быть если не полностью подконтрольно пользователю, то хотя бы полностью подотчетно. Это означает, что при всей сложности структуры облака, его объектов и цепочек делегирования прав доступа между объектами всегда должна обеспечиваться возможность сквозной обратной трассировки событий, результатом которой должно быть однозначное определение субъекта, инициировавшего то или иное действие.

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

ИБ-риски и угрозы, специфичные для облачной архитектуры

Руководитель направления общесистемного ПО компании CPS Илья Коношевский, напоминает, что облако включает в себя облачные вычисления, облачные сервисы и виртуализацию, представляющую собой технологию, на которой во многом базируют облачные вычисления. 
Если традиционные средства защиты работают на уровне операционных систем и аппаратной части ИТ-среды, то важнейший компонент облака — средства виртуализации — расположен между ними и, как напоминает г-нБадеха, тоже требует защиты, в том числе от администраторов виртуальной инфраструктуры, от перегрузки аппаратных ресурсов, от некорректного обращения с данными разных клиентов при их совместном хранении.

Характеризуя специфику обеспечения ИБ виртуальной среды директор по развитию бизнеса компании “Информзащита” Андрей Степаненко, указывает на то, что традиционными ИБ-средствами невозможно обнаружить нарушение прав доступа к средствам управления виртуальной инфраструктурой. Он также обращает внимание на появление в виртуализованных средах нового слоя привилегированных пользователей — системных администраторов поставщика услуг, которые имеют доступ к данным виртуальных машин.

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

В России провайдеры воспринимают ИБ не как конкурентное преимущество, а как статью расходов, которой лучше избегать до появления более зрелых в вопросах ИБ клиентов. Исключение, по мнению г-на Безкоровайного, составляют частные облака и облака крупных интеграторов. Выход из данной ситуации он видит во взаимодействии ИБ-специалистов клиента и провайдера облачных сервисов, связанном с мониторингом и анализом ИБ-инцидентов, контролем защищенности, оценкой рисков, организацией физической безопасности, непрерывности бизнеса и решением других задач, имеющих отношение к ИБ, которые зачастую не отражаются в SLA и договорах на обслуживание.

Хорошей отправной точкой подготовки к проведению анализа рисков для облачных сред г-н Безкоровайный считает документ “Cloud Computing Security Risk Assessment. Benefits, risks and recommendations for information security”, разработанный агентством European Network and Information Security Agency (ENISA), в котором систематизированы основные риски и уязвимости облачных сред с позиции клиента. В частности, к критическим там отнесены следующие риски:

  • привязка к одному облачному провайдеру, без возможности легко его сменить;
  • ошибки изоляции между ресурсами в облачной архитектуре, из-за чего возможны утечки данных;
  • нарушения требований законодательства в связи с использованием облачных сред;
  • действия злоумышленников из числа привилегированных сотрудников облачного провайдера;
  • неполное удаление данных в облачной инфраструктуре.

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

  • DoS-атаки на сетевую инфраструктуру между облаком и клиентом;
  • перехват аутентификационных данных для доступа к облаку через облачные API;
  • перехват данных, отправляемых и получаемых из облака;
  • использование уязвимостей для получения несанкционированного доступа к данным другими пользователями облака;
  • нарушение изоляции среды, предоставленной клиенту в рамках облачной услуги;
  • атаки на клиентские браузеры;
  • плохую очистку клиентской информации на стороне провайдера облачных услуг.

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

Помочь в снижении ИБ-рисков, с которыми сталкиваются пользователи облаков, могут ИБ-стандарты для облачных сред. Правда, как отмечает г-н Степаненко, они находятся в стадии разработки. Из готовых он называет рекомендации для систем виртуализации в платежных системах, подготовленные организацией PCI Council.

Г-н Рябко указывает на то, что количество информационных объектов, сосуществующих в облаке и взаимодействующих с ним, таково, что никакой прямой и централизованный контроль над ними невозможен, поэтому нужно переходить к косвенному и распределенному контролю. Зачатки подобных защитных технологий он видит в таких системах, как защита от проникновений и утечек (IPS, DLP).

Наиболее уязвимые компоненты облачных сред

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

Г-н Безкоровайный считает, что, чем выше уровень сервисной архитектуры, тем больше ответственности за обеспечение ее ИБ несет провайдер. Так, в SaaS, как наиболее высокоуровневой, провайдер отвечает за безопасность практически на всех уровнях, а заказчику остаются управление паролями, настройки разграничения доступа внутри приложений, настройка усиленной аутентификации. Зато в IaaS провайдер обеспечивает ИБ только до уровня виртуальных машин, а разграничение доступа внутри гостевой ОС — задача клиентов, и здесь у них гораздо больше возможностей по использованию сторонних по отношению к облачному провайдеру средств защиты.

По причине разнородности облачных сред однозначного ответа на этот вопрос, какие компоненты облачных сред являются наиболее уязвимыми и требуют первоочередного внимания со стороны обеспечения ИБ, по мнению г-на Сергеева, нет. Вместе с тем наиболее уязвимыми он считает сервисы, доступные из внешних сетей, особенно при слабой реализации ИБ в интерфейсе взаимодействия с облаком API. Целевым атакам, по его наблюдениям, подвергаются те сервисы, которые обеспечивают изоляцию между данными клиентов услуг облака: для SaaS — это сервер приложений; для PaaS — платформа, которая является средой разработки приложений для данного типа облаков; для IaaS — гипервизор и другие компоненты виртуальной инфраструктуры.

Наиболее актуальными для корпоративных клиентов облачных сервисов г-н Бадеха считает компрометацию клиентских устройств доступа в облако, перехват данных при передаче по незащищённым каналам связи и несанкционированный доступ к среде виртуализации.

Наиболее уязвимым звеном в предоставлении облачной услуги, по мнению г-на Дерюгина, является ее конечный пользователь. Он не сильно задумывается об ИБ-угрозах и нарушает ИБ-политику далеко не всегда по злому умыслу. Именно поэтому при переходе в облака контроль выполнения ИБ-политики становится особенно актуальным.

Заместитель генерального директора компании “Аладдин Р.Д.” Алексей Сабанов рекомендует пользователям облачных сервисов для обеспечения конфиденциальности хранить в облаках обезличенную (зашифрованную) информацию, для обеспечения доступности наладить гарантированную строгую взаимную аутентификацию “пользователь — ресурс” а целостность информации поддерживать с помощью квалифицированных электронных подписей.

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


Готовность ИБ-индустрии к защите облачных ИТ-сред

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

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

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

Согласно наблюдениям г-жи Сидоровой, на российском ИБ-рынке уже существуют проверенные на практике многими российскими компаниями решения, способные не только нейтрализовать специфические облачные угрозы, но и обеспечить соответствие мировым и отечественным стандартам и практикам, а также российскому законодательству.

Г-н Степаненко тоже уверен, что у ИБ-производителей есть широкий спектр готовых продуктов, которые разрабатывались специально для облаков и учитывают угрозы, появившиеся с новыми технологиями. Основное препятствие их распространения — незначительный опыт эксплуатации из-за малого числа внедрений.

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

Влияние и готовность регулятивной базы к переводу ИТ в облака

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

По мнению г-на Сабанова отсутствие нормативной базы и ИБ-стандартов для облачных вычислений переводит сегодня использование облачных сервисов в разряд наиболее рискованных. Вместе с этим он оптимистично оценивает ближайшие перспективы регулирования ИБ в нашей стране, полагая, что ФСБ России и ФСТЭК России, назначенные Указом Президента РФ от 8 февраля 2012 г. № 146 как федеральные органы исполнительной власти, уполномоченные в области обеспечения безопасности данных в информационных системах, созданных с использованием суперкомпьютерных и grid-технологий, являются правильными ответственными за порученное дело структурами. Он надеется, что вскоре появятся нормативные документы, в которых будут должным образом оценены риски и выданы рекомендации по защите интересов государства, бизнеса и граждан.

Как действующий практик г-н Петров считает, что во многом вопросы обеспечения ИБ в облаках закроет сертификация вендорских облачных платформ и построенных облаков провайдеров. Однако сам процесс такой сертификации представляется отдельной большой проблемой. 

По наблюдениям г-на Рябко российское регулирование, как и мировое, все более углубляет разрыв между темпом разработки новых технологий и созданием ИБ-средств и критериев оценки защиты. Он считает, что налицо мировой кризис идей NIST, и ICSA, и сообщества “общих критериев” — сертифицированных облаков в мире сегодня нет. Консерватизм систем оценки усугубляет остроту этого кризиса идей, но не меняет его природу. ИТ-прогресс бежит впереди ИБ, и почти все инновации последнего “писка”, по мнению г-на Рябко весьма сомнительно защищены.

Вместе с тем он отметил, что при всех наблюдаемых методических проблемах российское регулирование не дремлет — документы по облакам уже разрабатываются, а создатели средств защиты примеривают свои решения к облакам. В среднесрочной перспективе и регуляторы, и вендоры, по его прогнозам, выдадут зрелые предложения. 

Источник: PCweek, май 2012, 15.05.2012
Автор: Валерий Васильев

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