Облака над Отечеством: сгущаются или растворяются?

, президент группы компаний «С-Терра»

Дадим определения

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

Во-первых, облачные технологии далеко не всегда инновация. Сервис-ориентированным архитектурам с веб-интерфейсом (веб-сервисам), которые лежат в основе облаков, от пятнадцати до двадцати лет от роду. Какая же это инновация?

Вы скажете, что это совсем другие технологии, что нам Тим О’Рэйли объяснил, почему WEB 2.0 – это совсем другое. Другое социальное явление – соглашусь. Но другая технология? – помилуйте! В своей манифестальной статье, переведенной в «Компьютерре» [1], Тим так определяет различия между WEB 1.0 и 2.0:

Сам этот список показывает, что WEB 2.0 – наблюдения из области социального интернет-бихевиоризма, но никак не из области смены, скажем, версий протоколов, операционных систем, форматов данных… Эти технологические компоненты остались, в большинстве случаев, строго теми же, что и ранее.

Что же такое «облачные вычисления»? Нестрогие и эклектичные определения этому термину дают многие, в том числе экзальтированные авторы [2], но мы давайте воспользуемся определением, которое предложил американский институт NIST [3]. Это определение содержит яркие отличительные признаки и всего три модели обслуживания. Это - отрадный консерватизм, поскольку в произведениях перевозбужденных авторов я насчитываю примерно две дюжины услуг в формате *aaS – «что угодно, как сервис». Цитируем определения и характеристики из NIST:

НЕ нашли? Не то? Что вы ищете?

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

Опуская легкую невменяемость определения («…вычисления есть … модель доступа…»), перечислим, по NIST, характеристики облачных вычислений:

§ On-demand self-service – самообслуживание по запросу,

§ Broad network access – (не буквально, поскольку буквальный перевод несколько противоречит последующему пояснению NIST) сетевой доступ с любых терминалов,

§ Resource pooling – консолидация и динамическое перераспределение разнородных ресурсов,

§ Rapid elasticity – высокая эластичность, способность облака экономить ресурсы в простое при их быстром наращивании и неограниченной масштабируемости в нужном количестве в нужное время,

§ Measured service – измеряемый сервис, требуется для его учета и адаптации к потоку запросов,

модели обслуживания:

§ Software as a Service (SaaS) – программное обеспечение, как услуга, Вы не покупаете лицензии на приложения, а дистанционно получаете результаты деятельности временно работающих на Вас приложений провайдера,

§ Platform as a Service (PaaS) – платформа, как услуга, Вы можете расположить Ваши приложения в инфраструктуре провайдера, причем, в отличие от более ранних моделей, типа collocation, Вы не ттраите ни копейки а инфраструктуру; в то время, когда она Вам не нужна, ее использует другой потребитель,

§ Infrastructure as a Service (IaaS) – инфраструктура, как услуга, от PaaS отличается тем, что в этой модели Вы получаете не только вычислительную мощность под приложение, но и всякую прочую IT-всячину (площадку под виртуальную машину, дисковые пространства, полосу коммуникационных каналов и прочие сетевые слуги)

и модели внедрения:

§ Private cloud – частное облако, предоставляется единой (частной) организацией в интересах бизнес-структур, в которых организация-провайдер заинтересована, но которые, впрочем, могут этой организации и не принадлежать,

§ Community cloud – кооперативное облако, предоставляется определенному сообществу аффилированных по неопределенным признакам организаций; провайдером может выступать как любое подмножество членов сообщества, так и третья организация,

§ Public cloud – общественное облако, отличается от Community cloud тем, что не ограничивает состав сообщества потребителей,

§ Hybrid cloud – произвольная суперпозиция всех предыдущих моделей, поставляемая на базе единой технологии (тут у ребят из NIST’а также неуловимо подъехала крыша, поскольку «все предыдущие», вроде бы, последовательно включают друг друга, а суперпозиция вложенных множеств равняется крупнейшему из множеств; следовательно, Hybrid cloud является одним из вышеперечисленных cloud’ов).

Вопросы к определению

NIST, дав относительно четкие определения, сделал безусловно большое дело. Пришел лесник и прекратил бардак, устроенный Тимом О’Рэйли и прочими генераторами ненужных сущностей. Но два вопроса по недоработочкам определений NIST все-таки остались.

Первый – вопрос масштаба.

Метеоявления бывают разные. Крупный циклон (большое скрученное в спираль облако) накрывает Европу от Адриатики до Норвегии. Клочок тумана над подмосковным болотцем также подходит под определение «облако». Если я на домашнем компьютере, подключенном к Интернету по DSL-линии, поставлю виртуальную машину и веб-сервер – то я создал систему, технически подпадающую под все признаки определения NIST’а. Это что ж – мой дохлый Pentium и есть Cloud computing? Видимо, нет. Эффект масштаба, консолидация ресурсов, которая сделала бы модели услуг NIST экономически состоятельными, видимо достигается при несколько больших инвестициях. Поэтому давайте (условно) не будем называть облаком систему, не способную обслуживать, скажем, миллион пользователей.

Второй – вопрос структуры. Он еще менее строг, чем вопрос о форме облака. Техническая риторика вокруг облачных вычислений так и навевает воспоминания о распределенных системах, объектных технологиях и сервис-брокерах. Однако сегодня в подавляющем большинстве случаев речь идет о сугубо централизованных системах. Поэтому, рассуждая о структуре облака, целесообразно иметь в голове ЦОД с виртуализованным ресурсом и веб-доступом к нему с различных, преимущественно тупых (в терминах бизнес-логики) терминалов. Это – сегодня. Но облакам свойственно менять форму. Публика резервирует ЦОДы, а лет через десять их станет много у каждого облачного игрока и тогда, вероятно, вновь заговорят о распределенных вычислениях, но уже с распределением между ЦОДами, а не между серверами. Собственно, уже говорят [4] и даже упоминают старое (новое?) слово GRID, но при этом говорят о «разнице между GRID и Cloud computing».

Российский климат: облака сгущаются…

В мировом сообществе вопрос о применимости облаков, по данным 2008 года, выглядел еще весьма проблематичным:

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

Но Россиянину всегда кажется, что Запад ушел далеко вперед. В работе [4] автор уже в 2009 году горестно сетует: «О том, что на Западе существует прогрессивная модель «программное обеспечение как услуга» (Software-­as-a-Service, SaaS), российские ИТ-специалисты слышали уже давно. SaaS имеет несколько очевидных преимуществ перед классическим лицензированием ПО, но в России эта модель до сих пор практически не применяется». Это наверное, так, хотя не совсем.

Разберем же особенности местной метеообстановки поподробнее.

Начнем с того, что пользователем тех или иных «облаков» является каждый безмозглый фанат Рунета, поскольку Amazon, Google, Facebook и Twitter – безусловные облака как по определению, так и по технологиям. Помянем Яndex, Odnоklassniki, хотя по показателям масштаба и эластичности ресурсов Google смотрит на них очень сверху вниз. Ну какой же русский не любит быстрого Google’а?

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

Беспечность граждан не удивительна, потому что про риски облаков много чего интересного услышишь даже от IT-профессионалов, которые, например в [5], делают такие утверждения:

§ «Подчеркну, что еще существует набор сертификаций по безопасности, то есть, формальная часть вопроса. И если подавляющее большинство заказчиков, пользующихся собственной IT-инфраструктурой, для организации безопасности руководствуются определёнными процедурами, то в облачных системах всё намного серьёзнее» - утверждение «намного серьезнее», отметим, как симптоматический слабо обоснованный оптимизм агитаторов в пользу облака. Цена его ясна из следующей цитаты.

§ «В качестве примера можно привести те же банкоматы: ведь никого же не волнует то, кем они установлены, к какой сети подключены и кем обслуживаются. Почему?» - тут видно, что участники интервью далеки от реальных задач зашиты информационных активов. В 2009 году воровство денег банков и платежных реквизитов владельцев карт через закладки в банкоматах имело уже такие масштабы, что всякий нормальный человек предпочитал абы куда карточку не совать…

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

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

Соображения геополитической безопасности сдерживают реалистически мыслящих деятелей государства от чрезмерных интернет-сервис-восторгов. Мы не имеем контроля над технологиями облаков. Российский рынок «облаков» невидим рядом с мировым, и мы никогда не заработаем на нем денег на разработку своей независимой технологии (хотя, вероятно, построим ряд независимо интегрированных и относительно защищенных облачных решений). Но в [2] есть трогательный рассказ о том, что Google строит ЦОД для обслуживания своих облаков в городке Даллз, при электростанции на 1,8 ГВатт, поскольку для него проблема – электричество. Как Вы считаете – когда Яndex накопит денег, чтобы передвинуть ЦОД к сибирским гидроузлам и потребить там мощность средней гидроэлектростанции? Позлорадствуем, впрочем, что неподконтрольность технологий – не только российская беда, но общая проблема глобализации и лучшие умы – подумать только – в Соединенных Штатах – давно бьют тревогу [6].

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

Суммируем.

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

Облака для обработки критичной информации будут развиваться, преимущественно, в модели Private cloud в сверхкрупных организациях (масштаба Сбербанка РФ) и в модели Community cloud в сфере доступа к государственным услугам и данным. Вероятно, тут можно прогнозировать увеличение облачности в среднесрочном (хорошо, если до 2015 года) горизонте.

Прогноз по прочим метеоявлениям для России: «ясно», или, в лучшем случае, «малооблачно, без осадков»… Частный бизнес в частные облака со всем своим IT-хозяйством вот так, ща, сразу, не попрет. Тормоза примерно те же, что и с пресловутым аутсорсингом (облака и есть аутсорсинг), как говорят, пышно цветущим там и унылым здесь…

Что угрожает облаку?

Как мы уже говорили выше – морфологически типовое облако на сегодня, упрощенно, есть виртуализованный ЦОД с веб-терминалом. В этом отношении это вполне понятный объект, для которого мы имеем довольно значительный опыт и в защите, и даже в оценке защищенности. Не будем сейчас концентрироваться на тривиальных аспектах безопасности известной нам системы клиент-сервер. Зададим себе вопросы по вновь создаваемым аспектам информационной безопасности облаков.

Цена информационного актива растет с его объемом. Вместе с ним растет мотивация злоумышленника к его взлому и гонорар за «слив» информации. При каком объеме данных глобального облака мы должны считать, что перед объемом подкупа не устоит не один смертный?

В облаке «живут» приложения пользователей. В моделях PaaS и IaaS их туда «напихивают» сами пользователи и они, приложения, живут там своей жизнью. Провайдер об этой жизни знает мало и поэтому вряд ли имеет полный набор критериев, чтобы понять – странная жизнь какого-то приложения – это норма или аномалия? И что делать, наблюдая странность? – мочить? так ведь оштрафуют за прерывание моего сверхнадежного сервиса! А как не замочить, если есть подозрение, что пользовательский процесс по всем признакам инициализирует атаку на критически важный государственный ресурс? да еще, пользуясь эластичностью ресурсов облака, гребет, собака, на диверсию невообразимую вычислительную мощность?

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

Это – вопросы из категории философских. Но, наряду с этим, публике на сегодня вполне очевидны и более «земные» риски. Основные – перечислены ниже.

Риски доступности:

§ Не факт, что идеальная эластичность ресурсов достижима. На реальных пиках пользования (праздники, катастрофы, социальные волнения – часто именно когда эти ресурсы нужнее всего) вероятны невосполнимые дефициты ресурсов и облако, вероятно, остановится, как останавливается в этом случае сотовая связь.

§ Потери (по меньшей мене – находящихся в стадии обработки) данных как следствие упомянутого выше дефицита ресурсов.

§ Ошибки в управлении будут тем катастрофичнее, чем больше размер облака. «Человеческий фактор» порождает ошибки с вероятностью, меньшей 99.999%. Так какова, Вы говорите, надежность одлака?

§ Отсутствие/недостаток сетевых ресурсов. DDoS.

Риски информационной безопасности:

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

§ Потеря изоляции пространства индивидуального потребителя. Утечка данных между пользователями. Человечество еще вовсе не осознало критической роли гипервизора виртуальной машины ЦОДа в облаке. Компрометация его катастрофична и равна компрометации облака в полном объеме. Относительно маленький программный модуль станет средоточием внимания всех хакеров, атакующих облако. Устоит?

§ В моделях PaaS и IaaS хакер станет на полных законных основаниях «подсаживать» злонамеренные процессы в облако. Их влияние на гипервизор и друг на друга – совершенно новое, не изученное явление. Вообразите себе эдакое смешение бинарного химического оружия и вакуумной бомбы. Злонамеренный процесс делится на части. Каждая из частей, безобидная сама по себе, проходит через все фильтры безопасности, применяемые для помещения услуги в облако. Но собравшись в облаке 2 (или 10 000 – что в пространстве с эластичной вычислительной мощностью одно и то же) злонамеренных процесса объединяют усилия – и… Причем – отметим – Касперский тут вряд ли поможет. Эти процессы не будут вирусами в том смысле, что не будут иметь массового распространения и на них не будет сигнатур атак. Задача защиты, таким образом, трансформируется из задачи фармакологии, предлагающей лекарство на известную бациллу, в задачу иммунологии – защищай от всего, не знаю наперед от чего… А система иммунитета неизмеримо сложнее фармакологии и сама по себе иногда становится очень опасной.

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

§ Перехват данных при передаче. Особенно критично – для по сю пору применяемых схем защиты, основанных на SSL/TLS с динамически вырабатываемым ключом шифрования и без того или иного разделяемого секрета. Это – классический пример иллюзорной защиты. Следует также понимать, что средний веб-гражданин никогда не проверяет подлинность сайта. Подсунуть ему фишинговый образ его цели и высосать из него всю критическую информацию – милое дело…

§ Риски односторонней аутентификации. В моделях Public cloud она повсеместно распространена. Я утверждаю, что всякая система, допускающая одностороннюю аутентификацию – сервер подтверждает себя сертификатом, а кто такой клиент – неважно, – есть дыра безопасности. Просто для большинства сервисов не требующих аутентификации клиента, например, для заказа пиццы – цена риска ничтожна. Ну, принесли тебе пиццу, которую ты не заказывал, велика беда. Но дыра тут есть всегда. Как пример уже реализованного и вполне серьезного риска таких систем – приведу годичной давности инцидент в Twitter’е, когда лже-Дмитрий Медведев позволял себе вольности в адрес Владимира Путина.

§ Наконец, риски грязи в клиентском парке. Не секрет, что существенная часть домашних сетей граждан бот-поражена. Что это означает? То, что атрибуты их аутентификации, вероятнее всего, доступны хозяину бот-сети. Теперь он решает атаковать их Public cloud. Вероятнее всего, он сможет закачать в облако грязь. Для SaaS-облаков, по типу GMail, это не очень страшно: там работает предельно простое приложение, которое, к тому же, в три слоя защищено от передачи управления на код, содержащийся в приложениях к письмам. Но облака в PaaS- и IaaS моделях такой устойчивостью обладать не будут. Хакер будет в них пытаться вполне традиционными способами из компрометированного им клиента захватить более высокие права управления. И, если это ему вполне удается в клиент-серверных системах, – то отчего же не удастся, когда тот же сервер работает в виде виртуальной машины в IaaS-облаке? Удастся! А получив контроль над множеством виртуальных процессов в облаке, хакер станет атаковать гипервизор. Более того, если он – владелец бот-сети, то он сможет и «качать» загрузку облака, нащупывая пределы его эластичности и эксплуатируя создаваемые дефицитом ресурсов в облаке нештатные ситуации. Сценаристы фильма «Матрица» отдыхают, поскольку у них взбунтовались отдельные передовые атомы в кристалле матрицы, а тут появляется возможность «качнуть» всю кристаллическую решетку!

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

ЦОД и доверенный сеанс

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

Мы долго думали над этим и смогли пока сформулировать для себя следующие тезисы:

1. Настоящая сетевая защита (IPsec) хуже позиционирована по отношению к облаку, нежели достаточно надежный, но не всегда адекватно применяемый SSL/TLS. Но у IPsec есть две интересные позиции:

§ Защита инфраструктуры облака – SSL/TLS не даст ни QoS, ни потребной внутри облака производительности.

§ Надежный, обеспечивающий строгую аутентификацию и полную изоляцию сетевых взаимодействий front end для Private и, возможно, Community cloud’ов.

2. Мы добавили газу по всегда приоритетному для нас направлению «производительность». Даже простые, необлачные объекты защиты на сегодня настоятельно требуют решения на 10 Гбит/с.

3. Наконец, если облако – это способ получить услугу абы кому абы откуда, то мы задумались над «абы кому». Дело в том, что вопрос «абы откуда» относительно прост. «Абы откуда» - это, по-русски, по заданному URI получить сервис виртуализованного ЦОД. Его мы еще кое-как защитим. А вот как быть с многомилионным населением потребителей облачных сервисов, которые работают в несусветной информационной грязи, повсеместно используют пароль, тождественный собственному нику, неправильно сконфигурированы и не защищены, вирусопоражены и работают под контролем бот-руткитов? Тут мы предлагаем среду построения доверенного сеанса, которая должна быть устойчива ко всей этой грязи. Эта интеграционная технология дает новое качество защиты, которое заключается в изоляции процесса доступа к ресурсу (вспомним определение NIST, «Cloud computing – это доступ»). На эту технологию мы возлагаем определенные надежды в области облаков типа Private и Community.

Литература

1. Тим О’Рэйли. «Что такое Веб 2.0», «Компьютерра», 18 октября 2005, www.computerra.ru/think/234100/.

2. Питер Фингар. «DOT.CLOUD. Облачные вычисления – бизнес-платформа XXI века», Москва, «Аквамариновая книга», 2011, 254 стр.

3. Peter Mell, Timothy Grance. «The NIST Definition of Cloud Computing». Special Publication 800-145.

4. Данил Анисимов. «Антикризисный Saas», «КомпьютерПресс», май 2009, *****/article. aspx? id=20333&iid=931/.

5. Андрей Крупин. «Cloud computing: высокая облачность», «Компьютерра», 25 сентября 2009 г., www.computerra.ru/think/461761/.

6. Уэсли Кларк, Питер Левин. «Обеспечение безопасности информационной магистрали», «Россия в глобальной политике», том 8, № 2, март-апрель 2010, стр. 174-185.