Облачные вычисления: Уязвимости облака

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

Дэн Маринеску

Адптированная выдержка из книги «Cloud Computing: Theory and Practice» (Elsevier Science & Technology books).

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

Например, атака на Akamai Technologies, проведенная 15 июня 2004 г., вызвала проблемы с разрешением доменных имен и крупный сбой, затронувший Google Inc., Yahoo! Inc. и многие другие сайты. В мае 2009 г. Google оказался целью серьезной DoS-атаки (denial-of-service), которая вывела из строя на несколько дней такие сервисы как Google News и Gmail.

Молния вызвала длительный простой Amazon.com Inc. 29 и 30 июня 2012. Облако Amazon Web Services (AWS) в восточном регионе Соединенных Штатов, состоящее из десяти центров данных в четырех зонах доступности, сначала испытывало проблемы из-за колебаний электропитания, вероятно, вызванных грозой. 29 июня 2012 гроза на восточном побережье США вывела из строя кое-какую аппаратуру Amazon, расположенную в Виргинии, что нарушило работу компаний, использовавших системы только из этого региона. Как сообщают, одной из жертв этого простоя оказался сервис обмена фотографиями Instagram.

Восстановление после этих происшествий потребовало много времени и было связано с рядом проблем. Например, один из десяти центров не смог переключиться на запасные генераторы до того, как сели источники бесперебойного питания (UPS). AWS применило «плоскости управления» (control planes), чтобы позволить пользователям переключиться на ресурсы в других регионах, но этот программный компонент также отказал.

Процесс начальной загрузки оказался несовершенным и увеличил время, необходимое для перезапуска сервисов Elastic Compute Cloud (EC2) и Elastic Block Store (EBS). Еще одной критической проблемой стал «баг» в Elastic Load Balancing (ELB), который служил для маршрутизации трафика на серверы с доступными ресурсами. Аналогичный «баг» нарушил процесс восстановления Relational Database Service (RDS). Это происшествие выявило «скрытые» проблемы, которые могут произойти только при особых обстоятельствах.

Части облака

Провайдер облачных приложений, провайдер облачного хранилища и провайдер сети могут реализовывать различные политики. Непредвиденное взаимодействие между балансировщиком нагрузки и другими реактивными механизмами может привести к потере динамической устойчивости. Непредусмотренное сопряжение независимых компонентов, управляющих нагрузкой, потреблением энергии и элементами инфраструктуры может привести к возникновению нежелательной обратной связи и нестабильности, аналогично тому, как это может произойти при маршрутизации, основанной на политиках, при использовании Internet Border Gateway Protocol (BGP).

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

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

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

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

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

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

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

В модели Software as a Service (SaaS) возникают те же проблемы, что и в других онлайновых услугах, требующих защиты личной информации, таких как финансовые или медицинские услуги. В этом случае пользователь взаимодействует с облачными сервисами через четко определенный интерфейс. Потому, в принципе, у провайдера сервисов возникает меньше сложностей с перекрытием некоторых каналов атаки (attack channels).

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

Модель Infrastructure as a Service (IaaS), несомненно, самая сложная с точки зрения защиты от атак. В самом деле, пользователь IaaS имеет гораздо больше свободы, чем в двух других моделях предоставления облачных услуг. Дополнительный источник проблем — то, что немалое количество облачных ресурсов можно задействовать для атаки на сеть и инфраструктуру вычислений.

Крайне важной архитектурной особенностью этой модели является виртуализация, но она делает системы подверженными новым видам атак. Доверенная вычислительная база (trusted computing base, TCB) виртуальной среды содержит не только оборудование и гипервизор, но и управляющую ОС. Можно сохранить состояние всей виртуальной машины (VM) в файл, чтобы ее было можно переносить и восстанавливать — поддержка этих двух операций очень желательна.

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

Следующая существенная проблема связана с управлением ресурсами облака. Любое стратегия систематического управления ресурсами (в отличие от управления по ситуации) требует существования управляющих компонентов, предназначенных для реализации нескольких классов политик: управления доступом, выделения ресурсов, балансирования нагрузки, оптимизации энергопотребления и — последнее по порядку, но не по важности — предоставления гарантий качества обслуживания (quality of service, QoS).

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

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

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

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

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

Дэн С. Маринеску (Dan C. Marinescu) — был профессором по информатике в университете Пардью с 1984 по 2001. Затем перешел в департамент информатики университета Центральной Флориды. Работал приглашенным преподавателем в IBM T. J. Watson Research Center, институте информатики в Пекине, Scalable Systems Division Intel Corp., Deutsche Telecom AG и INRIA Rocquancourt во Франции. В сферу его исследовательских интересов входят параллельные и распределенные системы, научные вычисления, квантовые вычисления и квантовая теория информации.

См. информацию об этой и других книгах Elsevier на сайте Elsevier Science & Technology books.