Обзор и выводы по сценариям безопасности в облачной среде

Из редакции 3.0 «Белой книги случаев практического применения облачных вычислений»

В этой статье рассматривается раздел безопасности редакции 3.0 «Белой книги случаев практического применения облачных вычислений» ― составленной Группой по обсуждению случаев практического применения облачных вычислений, ― чтобы выделить те проблемы безопасности, которые архитекторам и разработчикам следует рассмотреть при переходе в облако.

developerWorks редакция облачных вычислений, редакция developerWorks, IBM

Редакция облачных вычислений developerWorks хотела бы услышать от вас о том, какие типы технических ресурсов вам нужны, чтобы сделать перенос приложений в облако более легким и эффективным. Пишите по адресу: dwcloud@us.ibm.com.



15.10.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Облачные вычисления: введение в программное обеспечение как услуги

В этой статье рассматривается раздел безопасности редакции 3.0 «Белой книги случаев практического применения облачных вычислений» ― энциклопедии, составленной Группой по обсуждению случаев практического применения облачных вычислений, открытым Web-сообществом, объединяющим свыше 900 участников. Оно началось с группы сторонников "Манифеста открытого облака" и теперь объединяет представителей крупных и мелких компаний, государственных учреждений, консультантов, поставщиков и пользователей.

Группа проповедует три принципа:

  • пользователи облаков должны сотрудничать;
  • стандарты разработки облаков должны быть открытыми и ориентированными на клиента;
  • по возможности должны использоваться существующие стандарты.

Цель редакции 3.0 «Белой книги случаев практического применения облачных вычислений»

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

Мы не будем пытаться охватить в одной статье всеобъемлющую «Белую книгу случаев практического применения облачных вычислений» целиком. В этом обзоре мы сосредоточимся на сделанной Группой оценке проблем и сценариев безопасности в облаке, поскольку безопасность - один из первых вопросов, которые возникают в связи с облачными вычислениями корпоративного уровня.

Темы облачной безопасности в целом

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

Допустим, что существует одно важное различие в подходе к обеспечению безопасности в облаке и в других средах. В чем оно заключается? Это не совсем техническая проблема... это ощущение предприятием потери контроля над конфиденциальными данными и приложениями, поскольку инфраструктуру контролирует поставщик облачных услуг. Эта проблема обсуждается в дискуссиях на следующие темы:

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

Благодаря кому все это стало возможным?

Участие в составлении редакции 3.0 «Белой книги случаев практического применения облачных вычислений» приняли: Dustin Amrhein, Patrick Anderson, Andrew de Andrade, Joe Armstrong, Ezhil Arasan B, James Bartlett, Richard Bruklis, Ken Cameron, Reuven Cohen, Tim M. Crawford, Vikas Deolaliker, Andrew Easton, Rodrigo Flores, Gaston Fourcade, Thomas Freund, Valery Herrington, Babak Hosseinzadeh, Steve Hughes, William Jay Huie, Nguyen Quang Hung, Pam Isom, Sam Johnston, Ravi Kulkarni, Anil Kunjunny, Thomas Lukasik, Bob Marcus, Gary Mazzaferro, Craig McClanahan, Meredith Medley, Walt Melo, Andres Monroy-Hernandez, Dirk Nicol, Lisa Noon, Santosh Padhy, Greg Pfister, Thomas Plunkett, Ling Qian, Balu Ramachandran, Jason Reed, German Retana, Bhaskar Prasad Rimal, Dave Russell, Matt F. Rutkowski, Clark Sanford, Krishna Sankar, Alfonso Olias Sanz, Mark B. Sigler, Wil Sinclair, Erik Sliman, Patrick Stingley, Robert Syputa, Doug Tidwell, Kris Walker, Kurt Williams, John M Willis, Yutaka Sasaki, Michael Vesace, Eric Windisch, Pavan Yara и Fred Zappert.

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

Средства контроля безопасности

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

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

Шифрование: управление ключами и сертификатами. Каждому, кто работал в сфере Web-разработки, очевидно, что должна быть возможность использовать стандартизованные функции для обеспечения безопасности информации, находящейся в покое и в движении. Стандарт: KMIP, ASIS Key Management Interoperability Protocol.

Безопасность хранения данных. Должна быть возможность хранения данных в зашифрованном виде. Важно признать, что некоторые пользователи захотят, чтобы их данные хранились физически изолированно от данных других потребителей. Стандарт: IEEE P1619, разработанный рабочей группой IEEE Security in Storage.

Безопасность конечных точек. Пользователи должны быть в состоянии защитить конечные точки своих облачных ресурсов (то есть ограничить допустимые конечные точки по сетевому протоколу и типу устройств).

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

Удостоверения, роли, управление доступом и атрибуты. Это непосредственно связано с федеративными аспектами облачных вычислений. Как облако не может существовать без того, чтобы все ресурсы были доступны как в единой системе взаимодействующих элементов, так и безопасность в облаке не может быть эффективной до тех пор, пока атрибуты отдельных лиц и услуг не определены «согласованным, машиночитаемым способом». Стандарты: SAML, OASIS Security Assertion Markup Language и сертификаты X.509, часть ITU Public Key and Attribute Certificate Frameworks Recommendation.

Безопасность сети. Должна быть возможность обеспечить сетевой трафик на уровне коммутатора, маршрутизатора и пакетов; сам IP-стек должен быть безопасным.

Правила безопасности. Чтобы управление доступом и распределение ресурсов было эффективным, должна быть возможность определить, проанализировать и применять правила безопасности согласованным и надежным способом. Согласованным и надежным настолько, чтобы их можно было применять автоматически. Стандарт: XACML, OASIS eXtensible Access Control Markup Language.

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

Управление рабочими нагрузками и услугами. Должна быть возможность настройки, развертывания и контроля услуг в соответствии с определенными правилами безопасности и клиентскими лицензионными соглашениями. Стандарт: SPML, OASIS Service Provisioning Markup Language.

Модели федерации безопасности

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

Доверительные отношения. Орган проверки подлинности предоставляет двум сторонам возможность определить доверительные отношения. Орган должен иметь возможность обмениваться верительными данными (такими как сертификаты X.509), а затем защищать сообщения и создавать подписанные маркеры безопасности (такие как маркеры SAML) с использованием этих верительных данных. Это основа для всех моделей федерации безопасности.

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

Управление доступом. Позволяет указывать правила (например, на языке XACML) для изучения маркеров безопасности, тем самым создавая возможность управлять доступом к ресурсам. Можно использовать несколько факторов для определения нескольких уровней доступа к ресурсам.

Единый вход и единый выход. Возможность объединять процедуры предоставления доступа на основе верительных данных от доверенного органа. Эту возможность предоставляет модель управления удостоверениями.

Проверка и соответствие. Нужны федеративные проверки нормативно-правового соответствия данных, распределенных между несколькими доменами, для документального подтверждения соблюдения соглашения об уровне обслуживания и других нормативных актов.

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

Существующие рекомендации по обеспечению безопасности буквально соответствуют значению английской фразы: «security best practices» (лучшие приемы обеспечения безопасности). Поскольку практические рекомендации обычно в конечном итоге приводят к стандартам, авторы полагают, что в качестве механизма обеспечения моделей федерации проектировщик или разработчик должен в первую очередь использовать существующие стандарты.

Сценарии практического применения

Авторы редакции 3.0 «Белой книги облачных вычислений» разработали общие сценарии, которые охватывают широкий спектр типов приложений, моделей развертывания, шаблонов и ролей для предоставления следующих возможностей:

опыт заказчика в сфере облачных вычислений + требования безопасности = успешное применение облака

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

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

Каждый раздел начинается с общего сценария и содержит:

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

Конфиденциальные данные, перегруженность частной инфраструктуры

Сценарий

Страховая компания использует приложение для сбора данных о своих страхователях и ущербе, который они понесли. По прогнозам, ураган в регионе побережья Мексиканского залива США, скорее всего, причинит массовые разрушения. Это приведет к наплыву исковых заявлений, который, в свою очередь, создаст повышенную нагрузку на корпоративную ИТ-инфраструктуру.

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

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

Компании нужно надежно передавать любые данные, созданные в облачных экземплярах приложения, в корпоративную сеть.

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

Решение: общедоступное облако позволит компании справиться с нагрузками, которые могут быть на порядок выше, чем обычно. Капитальные затраты на это единовременное событие гораздо ниже, чем в случае приобретения физических ресурсов для обработки этой нагрузки в долгосрочной перспективе.

Требования и средства контроля:

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

Федеративные модели: доверительные отношения, управление доступом, управление конфигурацией.

Ограниченные ресурсы, потребность в новых приложениях

Сценарий

Интернет-магазину необходимо разработать новое приложение витрины Web 2.0, но он не хочет обременять свой ИТ-персонал и нагружать имеющиеся ресурсы.

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

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

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

Тестирование с более интерактивным интерфейсом Web 2.0 (вместо статической Web-страницы) позволит лучше определить эластичность приложения в реальных ситуациях (способность растягиваться и принимать повышенные нагрузки, а также более широкий спектр образов виртуальных машин).

Требования и средства контроля:

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

Федеративные модели: доверительные отношения, управление удостоверениями, управление доступом, единый вход, проверка и нормативно-правовое соответствие, управление конфигурацией.

Хранение коммерческой тайны и получение доступа к ней

Сценарий

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

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

Компания решила использовать поставщика хранилища данных в общедоступном облаке для организации безопасного хранения и распространения потокового видео.

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

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

Требования и средства контроля:

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

Федеративные модели: доверительные отношения, управление удостоверениями, управление доступом, проверка и нормативно-правовое соответствие.

Сопоставление средств контроля, моделей федерации и сценариев

В следующих двух таблицах суммируются соотношения между средствами контроля, моделями федерации и сценариями. Первая обобщает соотношение между средствами контроля и сценариями клиентов, а вторая ― между моделями федерации и сценариями.

Таблица 1. Средства контроля и сценарии
Средства контроляПиковые нагрузки/ СтрахованиеРазработка и тестирование/ Розничная торговляБезопасное хранение/ Финансы
Управление ресурсами+++
Шифрование ++
Безопасность хранения данных  +
Безопасность конечных точек ++
Контроль событий и отчетность + 
Удостоверения, роли, управление доступом и атрибуты+++
Безопасность сети+ +
Правила  +
Автоматизация услуг + 
Управление рабочими нагрузками и услугами++ 
Таблица 2. Сопоставление моделей федерации и сценариев
Модель федерацииПиковые нагрузки/ СтрахованиеРазработка и тестирование/ Розничная торговляБезопасное хранение/ Финансы
Доверительные отношения+++
Управление учетными записями ++
Управление доступом+++
Единый вход + 
Проверка и соответствие ++
Управление конфигурацией++ 

Заключение

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

Выводы редакции 3.0 «Белой книги случаев практического применения облачных вычислений» в отношении безопасности в облачной среде очевидны:

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

Этот обзор содержит базовую модель и сценарии, иллюстрирующие правила и средства достижения безопасности в облаке. Мы рекомендуем изучить оригинальный документ «Белая книга случаев практического применения облачных вычислений» в полном объеме, потому что это проведенный Группой по обсуждению случаев практического применения облачных вычислений анализ того, что должны требовать разработчики и специалисты по планированию от своих поставщиков облачных услуг, чтобы обеспечить безопасную среду для своих драгоценных данных и приложений.

Ресурсы

  • Оригинал статьи: Review and summary of cloud security scenarios.
  • Исходный документ — от экспертов, входящих в Группу по обсуждению случаев практического применения облачных вычислений. Последняя версия этого документа доступна в формате PDF на английском | традиционном китайском | упрощенном китайском языках. На этом сайте могут быть доступны и другие форматы.
  • Манифест открытого облака ― заявление о принципах сохранения открытости в сфере облачных вычислений.
  • KMIP, OASIS Key Management Interoperability Protocol ― единый, всеобъемлющий протокол для связи между системами шифрования и широким спектром новых и традиционных корпоративных приложений, включая электронную почту, базы данных и устройства хранения данных.
  • IEEE P1619 - проект стандартизации методов шифрования хранимых данных, но более обобщенно относится к работе группы IEEE P1619 Security in Storage Working Group (SISWG) над семейством стандартов для защиты хранимых данных и соответствующих средств управления ключами шифрования.
  • SAML, OASIS Security Assertion Markup Language ― основанная на XML среда для передачи информации по аутентификации пользователей, их правах и атрибутах.
  • Сертификаты X.509, часть ITU Public Key and Attribute Certificate Frameworks Recommendation, ― стандарт ITU-T инфраструктуры с открытым ключом (PKI) для единого входа (single sign-on - SSO) и инфраструктуры управления привилегии (Privilege Management Infrastructure - PMI). X.509 указывает, среди прочего, стандартные форматы сертификатов с открытым ключом, списков отзыва сертификатов, сертификатов атрибутов и алгоритм проверки источника сертификации.
  • XACML, OASIS eXtensible Access Control Markup Language ― основная XML-схема представления правил авторизации и назначения прав.
  • SPML, OASIS Service Provisioning Markup Language ― среда на основе XML для обмена информацией о пользователях, ресурсах и предоставлении услуг.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Open source
ArticleID=840382
ArticleTitle=Обзор и выводы по сценариям безопасности в облачной среде
publish-date=10152012