Доклады, выступления, видео и электронные публикации
Мы не доверяем облаку или облако нам?
Облачная инфраструктура — это взаимодействующие ЦОДы, средства доступа и клиентские машины. Защищенная облачная инфраструктура — это защищенные серверы, защищенные ЦОД, защищенные виртуальные машины (ВМ), защищенный доступ.
Облако можно считать защищенным, если, как минимум:
- обеспечена доверенная среда накомпьютерах пользователей;
- защищен доступ пользователей кВМ (WEB или терминальный);
- обеспечен контролируемый старт серверов ЦОД иВМ насерверах;
- защищены ВМ.
Здесь уже получен ответ на вопрос, вынесенный в название статьи — и мы не доверяем облаку, и облако не доверяет нам. Что бы у нас были основания доверять облаку, его владелец должен предпринять серьезные усилия по защите ЦОДов. Чтобы облако доверяло нам — мы должны, как минимум, обеспечить доверенную среду на своих компьютерах.
Эти меры являются необходимыми, но не достаточными, без них говорить о защищенности облачной инфраструктуры нельзя, но они могут сильно расширяться. Но в реальной жизни так присходит не всегда. Значительно чаще недобросовестные «специалисты» создание доверенной среды информационного взаимодействия подменяют имитацией деятельности, а надежные средства замещают на более дешевые, имитирующие выполнение защитных функций.
Вот несколько примеров идей, очевидно недостоверных, но которые высказывались публично и поэтому требуют публичного обсуждения:
- применение токенов обеспечивает достаточный уровень защищенности;
- квалифицированная ЭПможет быть получена внедоверенной среде;
- главный приоритет- удобство клиента, абезопасность- его проблема.
Никакой токен не создает доверенной среды, поэтому первое утверждение недостоверно. В недоверенной среде возможны перехват управления, атака на порты, работа под враждебным гипервизором и так далее. Токен - просто хранилище ключей, которое ничем не лучше, чем дискетка, просто токен легче потерять. Неизвлекаемость ключа — полезное свойство, но оно полезно только при доверенности среды, в другом случае - это имитация защиты, преодолеть которую для злоумышленника не составит никакого труда.
Второе утверждение можно объяснить только дремучей безграмотностью лиц, его придумавших. Недоверенная среда — это «чашка Петри», питательная среда для вирусов и троянов, услужливо посеянных в ней хакерами, готовящимися атаковать Ваш компьютер. Не будем даже говорить о том, что требование доверенности среды прямо связано с требованиями 63-ФЗ — наверное, многие здесь тоже пытаются «суровость» закона компенсировать необязательностью его исполнения. Но вот здесь — точно зря!
Тезис о приоритете удобства над безопасностью — можно обсудить подробнее. Мне, например, кажется, что безопасность важнее. Хотя я и допускаю, что есть люди, для которых важнее удобство — например, потому, что они плохо владеют компьютером. Это вполне весомый аргумент, его не стоит воспринимать с улыбкой. Вспомните, как мы преодолевали первые километры, только получив водительское удостоверение. Было сложно. Но и здесь, хотя особого выбора не было, хотелось управлять безопасным «мерседесом», а не «копейкой».
Личные предпочтения важны, но еще важнее право выбора. Почему кто-то вообще присваивает себе право решать, что лучше для меня? Как нигде, например, защита важна в системах дистанционного банковского обслуживания (ДБО). В этих системах мне предлагают воспользоваться решениями, которые считает достаточными банк. Верю опыту банкиров, но это скорее опыт зарабатывания денег для банка, а не опыт обеспечения безопасности клиента. Это личные предпочтения банкиров, а не забота о клиенте. Мне кажется, что даже из самых благих намерений (которыми, как известно, и вымощена дорога в ад), не нужно навязывать клиенту свои представления о его предпочтениях. Кому-то важно удобство, кому-то - безопасность. Дайте выбрать самому клиенту, уважайте его: вы, банки — сервис для клиента, а не наоборот. Полагаю, что клиенту банка должен быть предложен выбор — Дешево, Быстро, Опасно (ДБО), — или Дороже, но БезОпасно (ДБО). Клиент выберет сам, а банк должен предоставить ему возможность выбора, конечно, зарабатывая на этом. Нужно просто в клиентском договоре предоставить клиенту выбор — дешевый токен — и тогда все риски на стороне клиента, или доверенная среда, и тогда за безопасность отвечает банк. Тогда все будет по-честному.
С этого момента можно не отвлекаться на поиск решения без доверенной среды. Я бы предложил идеи защиты информационного взаимодействия вне доверенной среды рассматривать наряду с идеями по созданию вечного двигателя — в комиссии по лженауке, а не выносить дискуссию на страницы приличных изданий.
Однако практика подсказала, что создать доверенную среду мало - ее нужно поддерживать на всем жизненном цикле. Действительно, если информационная система меняется — а она меняется, - то однажды зафиксированное состояние всегда может измениться, и в нелучшую, с точки зрения информационной безопасности, сторону. Значит, доверенную среду нужно не только создать, но и поддерживать.
Но как же сделать так, что бы доверенность среды поддерживалась постоянно?
Заметим, что любое информационное взаимодействие можно представить как взаимодействие клиентов через сервис. Если со стороны сервиса всегда можно обеспечить достаточный уровень квалификации персонала, и, соответственно, достаточный уровень информационной безопасности, то обучить всех клиентов всех сервисов приемлемому уровню знаний об информационной безопасности решительно невозможно. Пока не удается даже научить всех грамотно писать и говорить.
Оказывается, что так как приемлемый уровень квалификации со стороны клиента недостижим в принципе, то при организации защиты неквалифицированные действия обязательно создадут «дыру» в защищенности. Очевидно, что делать забор все выше и выше бессмысленно, пока в заборе остаются дыры. Бессмысленно все лучше и лучше защищать сервисы, пока «дыра» у клиента.
Что же делать?
Ответ очевиден — средства клиента должны быть ненастраиваемые, а все действия по управлению безопасностью должны быть переданы профессионалам. Простой вывод, но в научный оборот он вводится только сейчас.
А всегда ли клиент какого-либо доверенного сервиса должен работать в доверенной среде? Вряд ли. Это будет слишком высокая цена за удовольствие, например, получить раз в месяц госуслугу в электронном виде. Скорее, клиенту нужно часто работать в недоверенной среде, и лишь иногда организовывать доверенный сеанс связи с доверенным сервисом.
Таким образом, работа в доверенном режиме может осуществляться все время, а может лишь иногда, в относительно небольшие интервалы времени. В первом случае мы создаем доверенную вычислительную среду (ДВС), во втором — организовываем доверенный сеанс связи (ДСС).
ДВС создается однократно, но стоимость создания относительно велика. Действительно, однажды созданная, ДВС должна поддерживаться за счет СЗИ долго, в отдельных случаях - годы. За это время суммарное количество атак может стать огромным, и все эти атаки должны быть отражены защитными механизмами СЗИ. Конечно, такие СЗИ стоят дорого.
ДСС создается каждый раз заново, и это в ряде случаев может быть неудобно — загрузка и проверочные мероприятия продолжаются 10-20 секунд, но средства ДСС стоят гораздо дешевле, так как длительность ДСС не всегда достигает и 20 минут.
Вот в этом и состоит основная идея доверенного сеанса связи и его отличие от традиционного подхода. С этим связана и методика выбора — если вы все время должны быть в доверенной среде — создавайте и поддерживайте ДВС. Если доверенность нужна лишь иногда - достаточно и удобнее применять ДСС.
Для этого случая нужно предложить устройство, которое было бы загрузочным, автономным, отчуждаемым, и не теряло бы своих свойств при атаках из Интернет.
Возможны два варианта такого устройства — специальный носитель доверенной среды и отдельный компьютер. Первый вариант — полупассивное устройство на базе микроконтроллера, функции которого — управление доступом к разделам памяти. Второй вариант — микрокомпьютер с размещенной и исполняемой на нем доверенной средой и обеспечением ее неизменности.
Первый вариант подробно рассматривался неоднократно[1], так что ниже кратко обсудим вариант микрокомпьютера (МК).
Доверенный МК должен, как минимум:
- иметь достаточные ресурсы, чтобы исполнять ОС и СКЗИ
- быть аппаратно защищенным от изменения среды функционирования
- обеспечивать высокий уровень обработки видеопотока — не хуже FullHD
- включать все необходимые средства аппаратные сетевого взаимодействия
- включать все необходимые программные средства взаимодействия с облачными сервисами.
Эти требования кажутся довольно «сильными», но, к удивлению, такие решения появились практически одновременно сначала в России, и затем в США. На мой взгляд, это довольно убедительно доказывает верность подхода.
Почему же МК — правильный выбор?
Это так, потому что:
- состояние критичных компонентов зафиксировано
- вирусы блокированы
- ключи неизвлекаемые
- перехват управления невозможен
- управление безопасностью отчуждено отклиента.
При этом выполняются и все другие требования, включая требования автономности и отчуждаемости.
Представляется, что средства такого класса станут в скором времени весьма популярными при доступе к сервисам защищенного облака. При этом, конечно, у нас появится приемлемый уровень доверия к облаку, а облако станет доверять нам.
[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. N 2 (май). С. 32-33, N 3 (июнь). С. 8-9. Счастный Д. Ю. Защита решений для федеральных органов власти // Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15-18 мая 2012 года, Суздаль (Россия). 2012. С. 229-230. Конявский В. А. Хотят ли банки ДБО? // Национальный банковский журнал. 2012. № 2. С. 86-87. Конявский В. А. Организация безопасного ДБО на основе СОДС «МАРШ!» // Национальный банковский журнал. 2011. № 9. Конявский В. А. «Всегда прав» или «Cам виноват»? // Защита информации. Инсайд. 2011. № 5. С. 70-77. Каннер А. М. Средство организации доверенного сеанса как альтернатива доверенной вычислительной среде // Информационные технологии управления в социально-экономических системах. Вып. 4. М., 2010. С. 140-143. Конявский В. А. Доверенный сеанс связи. Развитие парадигмы доверенных вычислительных систем — на старт, внимание, МАРШ! // Комплексная защита информации.. М., 2010. И мн. др.
Авторы: Конявский В. А.; Акаткин Ю. М.
Дата публикации: 01.01.2014
Библиографическая ссылка: Конявский В. А., Акаткин Ю. М. Мы не доверяем облаку или облако нам? // Information Security/Информационная безопасность. М., 2014. № 1. С. 28–29.
Обратная связь
Отправьте нам сообщение или закажите обратный звонок.