CC BY
209
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.083 Е. С. ГЮНТЕР
Н. Н. НАРУТТА В. Г. ШАХОВ
Омский государственный университет путей сообщения
«ОБЛАЧНЫЕ» ВЫЧИСЛЕНИЯ И ПРОБЛЕМЫ ИХ БЕЗОПАСНОСТИ
В статье авторы раскрывают современные технологии обработки информации — так называемые «облачные» технологии. Приведены основные сведения в этой области, существующие стандарты и возникающие приэтом угрозы информационной безопасности. Также освещены методики анализа безопасности на основе нового направления исследований — управления информационными рисками.
Ключевые слова: облачные вычисления, SOAP, REST, гипервизор, шифрование, угроза безопасности.
«Облачные» (рассеянные) вычисления — технология обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять и не должен заботиться об инфраструктуре, операционной системе и собственно программном обеспечении, с которым он работает [1].
Принято выделять несколько моделей «облачных» сервисов: SaaS, PaaS и IaaS. Первая модель — SaaS, «облачное» приложение в виде сервисов. Организуется таким образом, что клиент получает доступ к приложениям, которых находятся в «облачной» инфраструктуре. Где и на каком оборудовании выполняется приложение, клиент может не знать. Вто-
рой вид «облачных» сервисов — платформа как сервис, PaaS. Клиент может устанавливать и разрабатывать свои приложения на предоставленной платформе, контролирует приложения, имеет частичный контроль над платформой, но не контролирует инфраструктуру. Третья модель — «облачная» инфраструктура как сервис, IaaS (рис. 1). Клиенту предоставляется виртуальная архитектура, состоящая из серверов, рабочих станций и сетевого оборудования, где клиент сам может разворачивать свои собственные операционные системы, базы данных и приложения [2].
Существует два способа организации «облачных» сервисов — SOAP и REST. С этими двумя аббревиатурами ассоциируются два почти диаметрально
Рис. 1
Сравнительная таблица
Характеристика SOAP REST
Применимы для статических Нет Да
ресурсов
Применимы для Да Нет
динамтеских ресурсов
Сохраняет состояние stateless Да Нет
Операции производятся С помощью методов или операции Над объектами или ресурсами
Необходим сервер Да, для разбора ХМ L-запросов Нет
приложении и исполнения программного квда
Затраты на встраивание Большие Малые
Ма с шта б и ру ем ост ь Не большая Больш ая
Загрузка вычислительных Большая Не большая
ресурсов
Изучение дополнительных Требуется Нет, потому что базируется на
спецификаций (WSDL, SOAP) стандартных Web-n ротоколах
Стандартизованный механизм Да, с помощью WSDL Нет, но разрабатывается WADL
доступа к данным -аналог WSDL
Используется шаблон Нет Да -CRUD(4ochobhых метода
проектирования GET/PUT/POST/DELETE]
Кэширование на уровне Нет Да, с по мощью протокол a HTTP
сервера
Возможность работать с Да Нет,только HTTP
любыми протоколами
Быстродействие Нет Да
Работает с представлением в Нет, только XML Да
разл и чн ых фо рм эта х
Обработка ошибок Стандартизована Использует известные коды ошибок HTTP
Рис. 2
противоположных подхода к организации Web-сер-висов. SOAP (Simple Object Access Protocol) — хорошо известный нижний уровень в стеке протоколов. REST (Representational State Transfer) — менее известное явление, называемое его авторами « архитектурным стилем» ( рис. 2).
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов;
в этом их кардинальное отличие от SOAP-сервисов. Если SOAP-клиенты запрашивают выполнение действия на сервере, то REST-клиенты попросту требуют сам ресурс. Например, вместо того чтобы запрашивать удаленное исполнение функции для нахождения нужного вам формуляра заказа, вы просто запрашиваете этот формуляр, примерно так же, как статичную Web-страницу [3].
REST-сервисы проще реализовать, поскольку они базируются на хорошо известных Web-протоколах и не требуют от разработчика изучения WSDL, SOAP и массы других WS-спецификаций, используемых для управления и обеспечения безопасности
SOAP-сервисов. Наипростейший REST-сервис можно реализовать за несколько минут — статичный XML-файл, возвращаемый Web-сервисом, это технически и есть REST-сервис, ведь XML-данные запрашивались через HTTP. Это вряд ли может стать оптимальным способом построения сервисной инфраструктуры, но для статичных или редко меняющихся ресурсов такая возможность весьма привлекательна.
Поскольку технология REST базируется на HTTP, то она несет на себе отпечаток ненадежности этого протокола и невозможности сохранения состояния, что обеспечивают сложные WS-спецификации. Безопасный, надежный обмен сообщениями и поддержка транзакций — вот лишь некоторые задачи, решаемые в масштабе предприятия WS-спецификациями.
SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. SOAP является расширением протокола XML-RPC [4].
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является одним из стандартов, на которых базируются технологии веб-служб.
В целом сервисы «облачных» вычислений представляют собой приложения, доступ к которым обеспечивается через Интернет посредством обычного интернет-браузера или других сетевых приложений, например, FTP-клиента. Это могут быть и развлекательные, и служебные, и специализированные бизнес-приложения. Главное отличие от привычного метода работы с ПО заключается в том, что пользователь использует не ресурсы своего ПК, а компьютерные ресурсы и мощности, которые предоставляются ему как интернет-сервис. При этом пользователь имеет полный доступ к собственным данным и возможность работы с ними, но не может управлять той же операционной системной, программной базой, вычислительными мощностями и т.д., с помощью которых эта работа происходит.
Подобный подход имеет целый ряд плюсов:
— пользователь может задействовать ПК практически любой конфигурации для выполнения ресурсоемких задач;
— «облачные» технологии позволяют работать в любом месте, пользователь не привязан к месту работы, и может использовать любой ПК, имеющий подключение к Интернету;
— пользователь застрахован от сбоев в работе в случае поломки машины, и может легко делиться результатами работы с другими людьми, либо же вести совместную работу.
Но существуют и определенные недостатки.
С точки зрения информационной безопасности, у «облаков» есть несколько проблем. В первую очередь, это проблемы технологические. Статистики по инцидентам мало, и уровень угроз еще непонятен, слабо проработаны или отсутствуют стандарты по безопасности, существующие методы защиты инфраструктуры неприменимы, так как в «облачном» сервисе само понятие инфраструктуры четко не опре-
делено. Второй вид проблем — психологические: в России практически отсутствует культура аутсорсинга, использование сервис-провайдеров. Кроме того, технология новая, сложна и ее использование достаточно рискованно. Третий вид проблем — юридический, то есть выполнение различных требований по безопасности в инфраструктуре, у которой динамически меняются размер, структура и периметр (размытая область ответственности). Государственные регуляторы еще не имеют единого представления и опыта оценки соответствия своим требованиям к технологиям «облачных» вычислений.
C точки зрения оценки провайдера в области обеспечения им информационной безопасности, западными компаниями рекомендовано придерживаться определенной методологии. В первую очередь это аудит по стандарту SAS 70 Type II, плюсом является сертификация провайдера по ISO 27001 или следование практикам ISO 27002. К формальным способам оценки безопасности относится аттестация по требованиям ФСТЭК, наличие сертифицированных средств защиты ( хотя пока непонятно, как применять их для виртуализированных средств защиты), наличие лицензий ФСТЭК и ФСБ, наличие сертификата EIA/TIA-492 для ЦОД.
Безопасности «облачных» услуг могут угрожать некорректный гипервизор, отсутствие ограничительных правил, переполнение механизма выравнивания нагрузки, ненадежное шифрование.
Некорректный гипервизор. Все «облачные» службы работают на виртуальных машинах поверх базового гипервизора, что позволяет нескольким операционными системам использовать общее оборудование. Они доступны разным участникам процесса с разными уровнями доверия: пользователям, арендаторам и администраторам «облака». Например, арендатор может иметь лицензионное соглашение на доступ 1000 пользователей к определенным службам типа « программное обеспечение как услуги».
Если гипервизор некорректен или взломан, под угрозой оказываются все ресурсы экземпляров и очереди запросов данных. Злоумышленники могут изменить ограничительные политики, которые применяются для отслеживания использования ресурсов экземпляров и очередей запросов в периоды повышенной рабочей нагрузки. Средства управления внутренних виртуальных сетей, которые используются для обмена данными между виртуальными машинами, недостаточно видимы для осуществления политики безопасности. Может быть недостаточно четко распределена ответственность за управление сетевыми ресурсами и безопасность виртуальных машин.
Хакер может получить доступ к файлам каталога и переназначить ресурсы экземпляра другой виртуальной машине. Он может также вызвать ошибку в работе механизмов, распределяющих ресурсы хранения данных, памяти, маршрутизации и репутации между арендаторами одной и той же виртуальной машины.
Злоумышленник может извлекать конфиденциальную информацию из остаточных данных, не вычищенных из перераспределенных ресурсов экземпляра внутри виртуальной машины. Он может использовать ущербный гипервизор для определения соседей здоровой виртуальной машины и контролировать их деятельность. Он может проникнуть внутрь соседней виртуальной машины и ввести вредоносный код в PaaS-приложения.
Отсутствие ограничительных правил. Прежде чем вступить в отношения с поставщиком услуг, конечному пользователю следует оценить его поли-
тику безопасности. Нужно сравнить ситуацию с безопасностью в «облачных» вычислениях с ситуацией в локальной среде и убедиться, что в политике безопасности «облака» присутствуют ограничительные правила для ресурсов экземпляра, пользователей и запросов данных.
Ограничительные правила для ресурсов полезны для контроля потребления дополнительных ресурсов экземпляра в периоды повышенных рабочих нагрузок. Ограничительные правила для пользователей проверяют, сколько пользователей работает с «облачной» службой в данный момент и приближается ли их число к максимальное количеству пользователей, указанному в лицензии [5].
Отсутствие этих правил представляет угрозу:
— без ограничительных правил для ресурсов можно не узнать, что ресурсы экземпляра злонамеренно доведены до полной емкости, чтобы вынудить поставщика «облачных» услуг без предупреждения отключить службу;
— без ограничительных правил для пользователей можно не узнать, что количество одновременных пользователей приближается к максимальному, и сколько пользователей не вышли из системы после получения «облачных» услуг. Хакеры могут вычислить этих пользователей;
— без ограничительной политики для запросов данных вы не будете знать размер очереди запросов данных. Хакеры могут переполнить эти очереди, наводнив их вредоносными запросами данных (например, запросами SQL-инъекции) [6].
Переполнение механизма выравнивания нагрузки. Выравнивание нагрузки используется для распределения ресурсов экземпляра и запросов данных. Например, каждый ресурс экземпляра должен быть загружен не более чем на 50 % своей емкости, чтобы в случае отказа одного экземпляра здоровые могли принять на себя его операции.
Каждая очередь должна быть загружена запросами данных не более чем на 50 % своей емкости, чтобы при сбое одной очереди здоровые могли принять запросы данных, первоначально направленные в отказавшую очередь.
Если выравнивание нагрузки ресурсов экземпляра злонамеренно искажается вредоносным приложением в виртуальной машине, это может вызвать наводнение этих ресурсов вредоносными операциями, заполняющими каждый ресурс до 100 % запаса его возможностей.
В этом случае становится невозможным перемещение бизнес-операций из ресурсов отказавшего экземпляра в здоровые. Переполненный механизм выравнивания нагрузки нельзя использовать в целях обеспечения отказоустойчивости, например, с применением ресурсов экземпляра или распределения нагрузки с избыточностью [7].
Ненадежное шифрование. Хакеры могут воспользоваться достижениями в области криптоанализа или ресурсами вредоносного экземпляра для взлома криптографических алгоритмов. Они могут прозондировать криптографический алгоритм на наличие лазеек и злонамеренно модифицировать его, превратив сильное шифрование в слабое.
Они могут пойти еще дальше, взяв последнюю версию криптографических алгоритмов и выполнив их реконструирование на своих собственных машинах, чтобы выяснить, как они работают.
Из всего вышесказанного можно сделать вывод, что существуют значительные риски использования «облачных» технологий и их стоит оценить.
Сегодня существует ряд подходов к измерению рисков — по двум и по трем факторам. Оценка по двум факторам производятся только в простейших случаях, поэтому рассмотрим оценку по трем факторам. Этими факторами являются угроза, уязвимость и цена потери. Угроза — совокупность условий и факторов, которые могут стать причиной нарушения целостности, доступности, конфиденциальности информации. Уязвимость — слабость в системе защиты, которая делает возможным реализацию угрозы.
Вероятность происшествия, которая в данном подходе может быть объективной либо субъективной величиной, зависит от уровней (вероятностей) угроз и уязвимостей:
P =Р хР .
происшествия угрозы уязвимости
(1)
Соответственно, риск рассчитывается следующим образом:
РИСК = Р хР хЦЕНА ПОТЕРИ. (2)
угрозы уязвимости
Данное выражение можно рассматривать как математическую формулу, если используются количественные шкалы, либо как формулировку общей идеи, если хотя бы одна из шкал — качественная. В последнем случае применяются различного рода табличные методы для расчета риска в зависимости от трех факторов.
Рассмотрим пример, когда организация из 20 пользователей использует «облачный» вариант офисных приложений.
В таблице можно наглядно отразить связь факторов негативного воздействия (показателей ресурсов) и вероятностей реализации угрозы с учетом показателей уязвимостей.
На первом шаге оценивается негативное воздействие по заранее определенной шкале, например, от 1 до 5 для каждого ресурса, которому угрожает опасность.
На втором шаге по заданной шкале, например, от 1 до 5, оценивается вероятность реализации каждой угрозы. За угрозы примем:
А — перехват документов;
В — подделку документов;
С — удаление документов;
D — подделку авторизации на ресурсе.
На третьем шаге вычисляется показатель риска. В простейшем варианте методики это делается путем умножения (В х С). Необходимо помнить, что операция умножения определена для количественных шкал. Для ранговых (качественных) шкал измерения показатель риска, соответствующий ситуации В =1, С = 3, совсем не обязательно эквивалентен случаю В = 3, С =1. Соответственно, должна быть разработана методика оценивания показателей рисков применительно к конкретной организации.
На четвертом шаге угрозы ранжируются по значениям их фактора риска (табл. 1).
Данная процедура позволяет сравнивать и ранжировать угрозы с различными негативными воздействиями и вероятностями реализации. В случае необходимости дополнительно могут приниматься во внимание стоимостные показатели [8].
Заключение. «Облако» хранения данных — это интересное направление развития моделей хранения, которое открывает новые возможности для построения, доступа и администрирования систем хранения данных на предприятии. Хотя сегодня «облачная»
Таблица 1
Ранжирование рисков
Угроза Показатель негативного воздействия Вероятность реализации угрозы Показатель риска Ранг риска
A 5 5 25 1
B 5 3 15 3
C 4 4 16 2
D 3 5 15 3
система хранения — преимущественно потребительская технология, она быстро развивается в направлении предприятия. Гибридные модели «облаков» позволят организациям сохранять конфиденциальность своих данных в пределах локальных центров обработки данных, передавая менее конфиденциальные данные в «облако» для экономии затрат и географической защиты.
Библиографический список
1. «Облачные» услуги: Снижение рисков и обеспечение высокой готовности [Электронный ресурс] / Компания IBM. — Электрон. текстовые дан. — М. : Компания IBM, 2012. — Режим доступа: http://www.ibm.com/developerworks/ru/library/ cl-cloudservicerisks/index.html (дата обращения: 04.12.2012).
2. Будущее «облачных» технологий: европейский взгляд [Электронный ресурс] / Бюро Соломатина. — Электрон. текстовые дан. — М. : Бюро Соломатина, 2012. — Режим доступа: http://www.bureausolomatina.ru/ru/themes_in_progress/clouds/? (дата обращения: 04.12.2012).
3. REST как альтернатива SOAP [Электронный ресурс] / Сети и системы связи. — Электрон. текстовые дан. — М. : Сети и системы связи, 2012. — Режим доступа: http://www.ccc. ru/magazine/depot/07_01/read.html?0502.htm (дата обращения: 04.12.2012).
4. «Облачные» вычисления: Вопросы безопасности в виртуальных облаках [Электронный ресурс] / TechNet Magazine. — Электрон. текстовые дан. — М. : TechNet Magazine,
2012. — Режим доступа: http://technet.microsoft.com/ru-ru/ magazine/hh641415.aspx (дата обращения: 05.12.2012).
5. Шахов, В. Г. Основы информационной безопасности /
B. Г. Шахов, В. Ф. Загуляев, Ю. М. Елизарова. — Омск : Изд-во ОмГТУ, 2010. - 230 с.
6. Шахов, В. Г. Анализ и расчет информационной безопасности / В. Г. Шахов, Ю. М. Елизарова. - Омск : Изд-во ОмГТУ, 2010. - 136 с.
7. Анатомия «облачной» инфраструктуры хранения данных [Электронный ресурс] / Компания IBM. — Электрон. текстовые дан. — М. : Компания IBM, 2012. — Режим доступа: http:/ /www.ibm.com/developerworks/ru/library/cl-cloudstorage/index. html (дата обращения: 05.12.2012).
8. Петренко, С. А. Управление информационными рисками. Экономически оправданная безопасность / С. А. Петренко,
C. В. Симонов. — М. : Компания АйТи ; ДМК Пресс, 2004. — 384 с.
ГЮНТЕР Екатерина Сергеевна, аспирантка кафедры «Автоматика и системы управления». НАРУТТА Нина Николаевна, аспирантка кафедры «Автоматика и системы управления». ШАХОВ Владимир Григорьевич, кандидат технических наук, профессор кафедры «Автоматика и системы управления».
Адрес для переписки: gyunther@yandex.ru
Статья поступила в редакцию 26.12.2012 г. © Е. С. Гюнтер, Н. Н. Нарутта, В. Г. Шахов
Книжная полка
Ляшков, А. А. Геометрическое и компьютерное моделирование формообразования поверхностей деталей : моногр. / А. А. Ляшков ; ОмГТУ. - Омск : Изд-во ОмГТУ, 2013. - 89 c. - ISBN 978-58149-1441-5.
Рассматривается геометрическое, компьютерное полигональное и твердотельное моделирование формообразования поверхностей деталей методом центроидного огибания. Геометрическое моделирование основывается на введенных вспомогательных поверхностях, полученных из семейств кривых, связанных с центроидами детали и инструмента.
о
Задорожный В. Н. Имитационное и статистическое моделирование : учеб. пособие для вузов по направлению подгот. 230100 «Информатика и вычислительная техника» / В. Н. Задорожный ; § ОмГТУ. - 2-е изд., испр. и доп. - Омск : Изд-во ОмГТУ, 2013. - 136 c. - ISBN 978-5-8149-1461-3.
Приводятся основные сведения о методах и средствах компьютерного моделирования систем. Основное внимание уделяется теории и технологиям имитационного и статистического моделирования. Учебное пособие предназначено для использования при изучении дисциплины «Моделирование систем» и смежных специальностей студентами, обучающимися по направлениям подготовки «Системный анализ и управление»,
о
в «Информатика и вычислительная техника».
