1. Проблемы новых парадигм и необходимости
новых подходов к управлению облачными
ресурсами
Скорость развития технологий заставляет всех отставших цепляться за
прошлое как за еще не разрушенные пласты. Это происходит в связи с
поверхностным анализом технологической сущности, что при попытке
быстрой адаптации приводит к неспособности управлять выстроенными на
основе этих технологий инфраструктурами, тогда как попытка доработки
заканчивается несостоятельностью большинства звеньев от руководящего
состава до программистов.
Юрий Чемеркин
Magazine Hakin9
Обезличивая корпоративность
Облачные вычисления представляют собой технологию обработки данных за счет виртуализации
и гибкого расширения физических сущностей, создавая отдельный поток для балансировки
нагрузки. С точки зрения пользователя данное решение представляется как единый виртуальный
сервер, в котором ранее известные сущности типа "процессор" заменяются на "процессорное
время", сохраняя при этом свойствах ядерности. Так, у кластеров хранения появляется такая
дополнительная характеристика, как количество загрузок и выгрузок.
Данные решения существуют уже около 10 лет, однако нарастающие объемы информации
требуют под рукой наличия сервера на каждую задачу, хостинга (что в условиях России
постоянно сопряжено с бесконечным набором проблем) либо покупкой облака. В последнем
случае фактически можно напрямую, без необходимости контакта с отечественными
представителями, купить корпоративное решение, сравнимое по мощности с уже построенными
во многих компаниях.
"Неразрешаемые" риски
Старые парадигмы показывают, что восприятие, казалось бы, на 101% идентичной технологии
медленно приводит к завершению оказания каких бы то ни было связанных услуг из-за
финансовых проблем, при условии, если вы не является провайдером, который в любом случае
сошлется на приличный по объему пакет документов при выставлении вам счета.

2. Считается, что проприетарность – один из основных рисков. А из-за того что облачные решения
еще не набрали популярности, критика в их сторону наиболее масштабна. Обычно это
выражается в претензиях, описанных ниже.
• Невозможность эффективного управления данными в облаке:
1.
2.
3.
Остановка деятельности облачного провайдера по причине банкротства или длительного
сбоя;
Провайдер изменяет условия соглашения;
Провайдер предлагает арендный тип ПО.
Случаи 1 и 2 рассматривают невозможность смены провайдера, так как "наши решения стали
очень зависимы". В случае 3 с прекращением услуг провайдера заканчивается возможность
использования ПО, которое ранее можно было купить и использовать до скончания века на
сегодняшний день, показывая несостоявшихся игроков. В остальном регулярное резервное
копирование сущностей за пределы одного провайдера более чем практично.
•
Раскрытие данных со стороны провайдера – судебная повестка. Если не рассматривать факт
вовлечения в судебный процесс, то технически судебная повестка, покрывая узкий круг
вопросов, не затрагивает незаинтересованных лиц. Однако ввиду некорректных формулировок
необходимо как минимум использовать полное шифрование данных, не храня при этом ключи
для расшифровки вместе с данными, и четко разграничивать применение предлагаемых со
стороны провайдера инструментов по их непосредственному назначению. Тогда по требованию
суда расшифровка с предоставлением ключей не затронет тех, чьи ключи отсутствуют, то есть
тех, кому она не адресована. Усиления шифрования можно добиться благодаря использованию
доверенного крипто-хранилища, например с использованием ГОСТа, для расшифрования
которого, кроме ключей, потребуется конкретная инструментальная реализация.
Здесь можно заметить, что независимо от открытости решения прекращение деятельности
провайдера выглядит одинаково и показывает лишь несостоятельность решений руководства в
отношении обеспечения жизненного цикла.
•
Ограничения отечественного законодательства:
1.
2.
3.
Обратное проектирование (reverse-engineering);
Трансграничные потоки;
Сертифицированные средства обработки.
Данный случай рассматривает вариант, недоступный для изучения обратного проектирования с
целью обеспечения совместимости. Однако в общем случае облако не является целиком и
полностью закрытым решением, при котором нельзя пользоваться сторонними решениями или
проводить аудит. Например, использование SSL-решений для защиты трафика никогда не
отменяло возможности применения собственных.
Среди прочего возникают вопросы в отношении трансграничной передачи данных при обработке
ПДн. На данный момент есть возможность рассматривать внедрение инструментов обработки за
счет облачных решений, расположенных в еврозоне, учитывая ФЗ-152 (ст. 12, пп1–2) и
международную Конвенцию о защите прав физических лиц при автоматизированной обработке
ПДн, так как это регулирует ряд вопросов касательно SLA и трансграничных потоков. Последняя
принята и одобрена большинством стран-участников ЕС, а также в России в конце 2005 г.
Если не рассматривать государственный сектор, то при условии признания международных
стандартов в области защиты информации в связи с вступлением России в ВТО, значительно
улучшится понимание ряда юридических проблем.
Экономические аспекты
На сегодняшний день нормой считается применение готовых компонентов или решений, тогда
как разработка с нуля является неоправданной тратой, в связи с чем на поддержание
инфраструктуры и существующих приложений расходуется до 90% бюджета, причем
соотношение последних двух выглядит как 1:1,5 или даже 1:2. Рутинные процедуры переноса

3. приложений на выделенный сервер с постоянным мониторингом изменений между тестовыми и
финальными решениями продолжают изрядно отнимать время, вместо того чтобы парой кликов
превратить тестовую версию в готовую к запуску.
Несмотря на затраты, связанные только с эксплуатацией и внедрением облачных решений,
краеугольными камнем является смена видения вопросов разработки приложений в данном
случае. До сих пор эталонными мерками признавались рекомендации ведущих лидеров в области
программирования. Хотя они уже не один раз меняли свои эталоны, смена понимания старых
шаблонов, установившихся в компании, просто необходима для разработчиков, а также порой и
для проектных менеджеров. В противном случае экономические просчеты приведут к
постепенному оттоку целевой аудитории к конкурентам с их более выгодными предложениями. С
одной стороны, вероятными решениями будут являться особые договорные обязательства, а с
другой – эффективная работа продукта по обработке данных. Причем в ряде случаев это можно
организационно разрешить уже на этапе проектирования, изрядно снизив последующие
экономические просчеты.
Вопросы
резервного
копирования
должны
быть
автоматизированы
изначально
и
регламентированы в договоре к продукту, так как частое его использование или отсутствие
может привести к исчерпанию оплаченного лимита запросов и, как следствие, к судебным искам
в отношении компании, как это уже неоднократно было у провайдеров сотовой связи. Тесная
интеграция с методами обеспечения безопасности сущностей, даже при максимально
эффективной и гибкой политике, скорее всего также ляжет бременем на бюджет. Это
объясняется старыми подходами к программированию в минимальном использовании копий
ресурсов ввиду более эффективной траты ресурсов. Возможен логический просчет в том, что
ресурсоемкая часть приложения выносится в облако, освобождая место для написания облачного
кода, в котором количество сетевых запросов также лимитировано. А построение
детализированной политики вместо групповых шаблонов может насчитывать порядка 200
запросов проверки дискреционных полномочий, просчет в которых закончится далеко не
тарифом $4 в день. Несмотря на это, очевидно, что облака к сегодняшнему дню предоставляют
значительный набор инструментов для решения возникающих вопросов безопасности. Однако
ровно так же, как и с обычными продуктами, требующими администрирования, необходимо
эффективно прорабатывать вопросы ведения жизненного цикла облачных решений и искать
альтернативы, в которых возможен перезапуск виртуальных сущностей на случай возникновения
сбоев или проведения атак.
Опубликовано: Журнал
Посещений: 142
"Information
Security/
Автор
Юрий Чемеркин
Magazine Hakin9
Всего статей: 2
Информационная
безопасность"
#1,
2012