Контакты
Подписка
МЕНЮ
Контакты
Подписка

Мы не доверяем облаку или облако нам?

Мы не доверяем облаку или облако нам?

В рубрику "Облака" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Мы не доверяем облаку или облако нам?

Облачная инфраструктура – это взаимодействующие ЦОД, средства доступа и клиентские машины. Защищенная облачная инфраструктура – это защищенные серверы, защищенные ЦОД, защищенные виртуальные машины (ВМ), защищенный доступ.
Валерий
Конявский
Научный руководитель ВНИИПВТИ, научный консультант ОКБ САПР, д.т.н.
Юрий
Акаткин
Директор “ФГУП КБПМ”

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

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

Приведем несколько заблуждений

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

Облако можно считать защищенным, если как минимум:

  • обеспечена доверенная среда на компьютерах пользователей;
  • защищен доступ пользователей к ВМ (Web или терминальный);
  • обеспечен контролируемый старт серверов ЦОД и ВМ на серверах;
  • защищены ВМ.
  • применение токенов обеспечивает достаточный уровень защищенности;
  • квалифицированная ЭП может быть получена в недоверенной среде;
  • главный приоритет – удобство клиента, а безопасность – его проблема.

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

Второе утверждение можно объяснить только дремучей безграмотностью лиц, его придумавших. Недоверенная среда – это "чашка Петри", питательная среда для вирусов и троянов, услужливо посеянных в ней хакерами, готовящимися атаковать ваш компьютер. Не будем даже говорить о том, что требование доверенности среды прямо связано с требованиями 63-ФЗ – наверное, многие здесь тоже пытаются "суровость" закона компенсировать необязательностью его исполнения. Но вот здесь – точно зря!

Об удобстве подробнее

Тезис о приоритете удобства над безопасностью можно обсудить подробнее. Нам, например, кажется, что безопасность важнее. Хотя мы и допускаем, что есть люди, для которых важнее удобство – например, потому, что они плохо владеют компьютером. Это вполне весомый аргумент, его не стоит воспринимать с улыбкой. Вспомните, как мы преодолевали первые километры, только получив водительское удостоверение. Было сложно. Но и здесь, хотя особого выбора не было, хотелось управлять безопасным "Мерседесом", а не "копейкой".

Личные предпочтения важны, но еще важнее право выбора. Почему кто-то вообще присваивает себе право решать, что лучше для меня? Как нигде, например, защита важна в системах дистанционного банковского обслуживания (ДБО). В этих системах нам предлагают воспользоваться решениями, которые считает достаточными банк. Верим опыту банкиров, но это скорее опыт зарабатывания денег для банка, а не опыт обеспечения безопасности клиента. Это личные предпочтения банкиров, а не забота о клиенте. Нам кажется, что даже из самых благих намерений (которыми, как известно, и вымощена дорога в ад), не нужно навязывать клиенту свои представления о его предпочтениях. Кому-то важно удобство, кому-то – безопасность. Дайте выбрать самому клиенту, уважайте его: вы, банки, – сервис для клиента, а не наоборот. Полагаю, что клиенту банка должен быть предложен выбор – Дешево, Быстро, Опасно (ДБО), или Дороже, но БезОпасно (ДБО). Клиент выберет сам, а банк должен предоставить ему возможность выбора, конечно, зарабатывая на этом. Нужно просто в клиентском договоре предоставить клиенту выбор: дешевый токен, и тогда все риски на стороне клиента, или доверенная среда, и тогда за безопасность отвечает банк. Тогда все будет по-честному.

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

Доверенную среду нужно поддерживать

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

Но как же сделать так, чтобы доверенность среды поддерживалась постоянно?

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

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

Что же делать?

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

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

А всегда ли клиент какого-либо доверенного сервиса должен работать в доверенной среде? Вряд ли. Это будет слишком высокая цена за удовольствие, например, получить раз в месяц госуслугу в электронном виде. Скорее, клиенту нужно часто работать в недоверенной среде, и лишь иногда организовывать доверенный сеанс связи с доверенным сервисом.

Таким образом, работа в доверенном режиме может осуществляться все время, а может лишь иногда, в относительно небольшие интервалы времени. В первом случае мы создаем доверенную вычислительную среду (ДВС), во втором – организовываем доверенный сеанс связи (ДСС).

Вот в этом и состоит основная идея доверенного сеанса связи и его отличие от традиционного подхода. С этим связана и методика выбора: если вы все время должны быть в доверенной среде – создавайте и поддерживайте ДВС. Если доверенность нужна лишь иногда – достаточно и удобнее применять ДСС.

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

Рассмотрим варианты

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

Первый вариант подробно и неоднократно рассматривался в различных СМИ1, так что ниже кратко обсудим вариант микрокомпьютера (МК).

Доверенный МК должен как минимум:

  • иметь достаточные ресурсы, чтобы исполнять ОС и СКЗИ;
  • быть аппаратно защищенным от изменения среды функционирования;
  • обеспечивать высокий уровень обработки видеопотока – не хуже FullHD;
  • включать все необходимые аппаратные средства сетевого взаимодействия;
  • включать все необходимые программные средства взаимодействия с облачными сервисами.

Эти требования кажутся довольно "сильными", но, к удивлению, такие решения появились практически одновременно сначала в России2, а затем в США. На наш взгляд, это довольно убедительно доказывает верность подхода.

Почему МК – правильный выбор?

Потому что:

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

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

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

___________________________________________
1 Конявский В.А. Серебряная пуля для хакера // Защита информации. INSIDE. – 2013. – № 4. – С. 54–56; № 5. –С. 69–73; Конявский В.А. Облако ЦОДов, или Сон разума // Защита информации. INSIDE. – 2013. – № 5. – С. 36–37; Конявский В.А. Электронная торговля. Вопросы идентификации и аутентификации // Information Security/Информационная безопасность. – 2013. – № 3. – С. 47; Акаткин Ю.М. Сервисы и решения, обеспечивающие непрерывность бизнес-процессов в ЦОД // Национальный банковский журнал. – 2013. – № 5; Акаткин Ю.М. Интеграция технологий обеспечения ИБ при оказании государственных услуг в электронном виде // Information Security/Информационная безопасность. – 2013. – № 2. С. 6–7; Конявский В.А. ДБО – как сделать это безопасным // Information Security/Информационная безопасность. – 2012. – № 2. – С. 32–33; № 3. – С. 8–9; Счастный Д.Ю. Защита решений для федеральных органов власти / Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15–18 мая 2012 г., Суздаль (Россия). – С. 229–230; Конявский В.А. Хотят ли банки ДБО? // Национальный банковский журнал. – 2012. – № 2. – С. 86–87; Конявский В.А. Организация безопасного ДБО на основе СОДС “МАРШ!" // Национальный банковский журнал. – 2011. – № 9; Конявский В.А. “Всегда прав" или “Cам виноват"? // Защита информации. INSIDE. – 2011. – № 5. – С. 70–77; Каннер А.М. Средство организации доверенного сеанса как альтернатива доверенной вычислительной среде // Информационные технологии управления в социально-экономических системах. Вып. 4. – М., 2010. – С. 140–143; Конявский В.А. Доверенный сеанс связи. Развитие парадигмы доверенных вычислительных систем – на старт, внимание, МАРШ! // Комплексная защита информации. – 2010. – С. 166–169; и др.
2 Акаткин Ю.М., Конявский В.А. Безопасный доступ к корпоративным облачным приложениям // Informatiom Security/Информационная безопасность. – 2014. № – 1. – С. 23.

Опубликовано: Журнал "Information Security/ Информационная безопасность" #1, 2014

Приобрести этот номер или подписаться

Статьи про теме